Learn more about these different git repos.
Other Git URLs
For the work that we are doing to support Cloud images, including Vagrant images and WSL support, we are using the Kiwi tool to build the images while the os-build tools to support these environments are still in development.
Need by date 2023-11-1 We are working on finalizing the change proposals for F40 and would like to backport to F39 as soon as possible.
When is this no longer needed or useful? When other fedora tools support the creation of configs for custom composes, WSL and vagrant we are doing in Cloud without requiring manual configuration and updates after build.
If we cannot complete your request, what is the impact? We will be forced to continue using Imagefactory for builds.
Related work by @arrfab: https://pagure.io/centos-infra/issue/696 Related work that requires this plugin: https://pagure.io/fedora-kiwi-descriptions
More concretely, we need specifically the following:
kiwi
kiwi-cli
kiwi-systemdeps
distribution-gpg-keys
kiwi-build
kiwiBuild
This needs to be wired up for us to be able to use composes as an input for image builds with kiwi.
cc: @dcavalca @salimma @tdawson
Not a super fan of adding yet another way to do things... but sure.
We can look at this after f39 release. Unless you need it before then? I don't like the idea of making a lot of koji changes while we are in final freeze.
We could of course deploy to staging before then.
Also, is this just for doing scratch builds? Or do you intend to make official images with it? If you do, we need a place for config for these to live and pungi config needs to support firing off those builds.
We don't need it before then.
We do intend to make official images. The kiwi descriptions are here: https://pagure.io/fedora-kiwi-descriptions
pungi will need the ability to run kiwiBuild tasks. I'm happy to help with that if someone can point the way.
The goal is to kill imagefactory for this, so it's not "another way" strictly speaking, mainly a replacement way.
Metadata Update from @phsmoura: - Issue tagged with: low-gain, low-trouble, ops
The change was approved, can we please get this deployed?
Also, @arrfab did this on the CentOS CBS in centos-infra#696 and would be able to guide on how to enable this on the Fedora Koji instance.
So, I have things setup in staging, but...
https://koji.stg.fedoraproject.org/koji/taskinfo?taskID=120000662
DEBUG util.py:463: Last metadata expiration check: 0:00:02 ago on Sat Feb 17 19:45:42 2024. DEBUG util.py:461: Error: DEBUG util.py:461: Problem 1: package kiwi-systemdeps-core-9.25.21-4.fc40.s390x from build requires zypper, but none of the providers can be installed DEBUG util.py:461: - package kiwi-systemdeps-9.25.21-4.fc40.s390x from build requires kiwi-systemdeps-core = 9.25.21-4.fc40, but none of the providers can be installed DEBUG util.py:461: - package zypper-1.14.59-2.fc39.s390x from build requires libzypp(s390-64) >= 17.31.7, but none of the providers can be installed DEBUG util.py:461: - package zypper-1.14.59-2.fc39.s390x from build requires libzypp.so.1722()(64bit), but none of the providers can be installed DEBUG util.py:461: - package zypper-1.14.59-2.fc39.s390x from build requires libzypp.so.1722(ZYPP_plain)(64bit), but none of the providers can be installed DEBUG util.py:461: - conflicting requests DEBUG util.py:461: - nothing provides libboost_thread.so.1.81.0()(64bit) needed by libzypp-17.31.8-2.fc39.s390x from build DEBUG util.py:461: Problem 2: package python3-kiwi-9.25.21-4.fc40.noarch from build requires kiwi-systemdeps-core = 9.25.21-4.fc40, but none of the providers can be installed DEBUG util.py:461: - package kiwi-systemdeps-core-9.25.21-4.fc40.s390x from build requires zypper, but none of the providers can be installed DEBUG util.py:461: - package kiwi-cli-9.25.21-4.fc40.noarch from build requires python3-kiwi = 9.25.21-4.fc40, but none of the providers can be installed DEBUG util.py:461: - package zypper-1.14.59-2.fc39.s390x from build requires libzypp(s390-64) >= 17.31.7, but none of the providers can be installed DEBUG util.py:461: - package zypper-1.14.59-2.fc39.s390x from build requires libzypp.so.1722()(64bit), but none of the providers can be installed DEBUG util.py:461: - package zypper-1.14.59-2.fc39.s390x from build requires libzypp.so.1722(ZYPP_plain)(64bit), but none of the providers can be installed DEBUG util.py:461: - conflicting requests DEBUG util.py:461: - nothing provides libboost_thread.so.1.81.0()(64bit) needed by libzypp-17.31.8-2.fc39.s390x from build DEBUG util.py:463: (try to add '--skip-broken' to skip uninstallable packages) DEBUG util.py:610: Child return code was: 1
I think we need this sorted in rawhide/f40? Or am I doing something wrong here...
No, it does need sorting out... :person_frowning:
I've broken out the zypper dependency into a subpackage that isn't pulled in by default: https://src.fedoraproject.org/rpms/kiwi/c/e385d1b686d99773468810d0c40a94b36364b2f4
It's building for f40+ right now:
Thanks. I built the f41 one in staging and things got further. :)
i686 still isn't happy, but since we don't care about that, not sure it's too big a deal. ( https://koji.stg.fedoraproject.org/koji/taskinfo?taskID=120001049 if you want to look)
Then, x86_64/aarch64 got much futher: https://koji.stg.fedoraproject.org/koji/taskinfo?taskID=120002320 oddly, it's hitting:
[ ERROR ]: 16:27:13 | KiwiInstallPhaseFailed: System package installation failed: Module or Group 'cloud-server-environment' is not available.
I'm not sure why. ;( I am not sure I can look more today, and I am on PTO tomorrow, but can look tuesday... or we can just debug in prod on wed.
One thing we will have to do is make a new build tag for these because it requires old mock chroot. ;( I'm not sure if that might complicate the pungi side of things.
It's because that Koji doesn't import environment groups. We need to pass in a compose repo URL in order to have full comps data.
See: https://pagure.io/koji/issue/3626
Ah, ok. ;(
This is all done now at this point, so can we close this?
Yes, we discussed this in releng weekly today and we have most of the things done here! Thanks @ngompa and everyone working on this to land it in 40 :D
Metadata Update from @jnsamyak: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.