As discussed last week
(https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/S3X32LZILY3MZEVZZCR6I43DQE54YMKK/
) 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