Hi folks,
The NFV SiG has successfully built its packages against s390x arch [1]. Thank you Fabian for adding support of s390x architecture on CBS and for your help on building/merging those builds.
[1] https://mirror.stream.centos.org/SIGs/9-stream/nfv/s390x/openvswitch-2/
Cheers, Joel
On Wed, Oct 2, 2024 at 1:53 PM Fabian Arrotin arrfab@centos.org wrote:
As discussed last week ( https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/S3X32... ) I reached out to openmainframeproject to see if there would be a possibility to remotely use at least one s390x VM for SIGs.
I'm proud to announce that such infra is ready to be used within CBS build infra (https://cbs.centos.org/koji/hostinfo?hostID=22)
# What does that mean ? If your SIG wants to start building against/for s390x architecture, please just open a infra ticket on https://pagure.io/centos-infra/issues (usual way) and for which SIG/tags you'd like to see the s390x arch being added.
As usual, SIGs can build against rhel8/rhel9/CentOS Stream 9 and CentOS Stream 10, including for s390x (internal mirror is now ready too)
# How to proceed There are basically multiple ways to add the s390x architecture :
- when you'll create new tag, you can ask for s390x arch to be included
by default for your new build tag
- for existing tags, you can also ask for the s390x arch to be added,
but that also means that builds you'll submit as usual will have to find all build dependencies, including for s390x. It can be that you have yourself built some BuildRequires: dependencies for your RPM packages in your tags, but so probably just for x86_64, aarch64 and eventually ppc64le.
How can that specific problem be solved :
- either bump nvr for your build chain/order, rebuild in order to
include from now on s390x, and then it will be BAU (Business as Usual) once s390x will be at same level for all pkgs.
- other possibility (what I just used for the infra tags) : it's
possible to just resubmit scratch builds for same package NVR (which koji would refuse you to do as "normal" build) : cbs build --scratch --arch-override s390x <target> <src.rpm/dist-git url> After each successfully scratch build, you can use the build id and then communicate (either through ticket or irc) us the build id, so that we can use a specific (admin right required, reason why SIGs can do that themselves) koji api call, to "merge" the newly s390x build with the existing one (with same pkg NVR, so nothing to do at the src.rpm/git level at all)
- other option (if you have plenty of packages in the build chain, and
don't want to block other builds for your existing -release tags) : we can create a specific "bootstrap" tag, with only s390x, in which we can just do the scratch+merge dance, until it's all resolved/equal to other tag, and only then, add the s390x arch to your existing tags (that will then automatically find the s390x packages, as existing in koji)
One example : I had to rebuild cvs (one of many pkgs I rebuilt), itself a dep for koji-builder (needed to bootstrap the new infra) :
- scratch build : https://cbs.centos.org/koji/taskinfo?taskID=4235422
- promoted to existing build :
https://cbs.centos.org/koji/buildinfo?buildID=43020 (see s390x artifacts now part of a previous build ID)
# Worth knowing We'd like to thank again openmainframeproject for the VM, but also worth knowing that because it's a remote (and locked down) VM, all koji/mirror traffic goes through an encrypted tunnel , and so that has a small impact on the needed time to init a buildroot. Based on my tests, it's still pretty fast to build, but just a little bit slower to init the buildroot, when downloading all needed packages
Happy building and let us know which SIG wants to be next SIG (Infra SIG started to rebuild packages for our own usage already)
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org] _______________________________________________ devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org