On Thu, Jun 26, 2025 at 09:22:58AM -0400, Solomon Peachy wrote: > On Thu, Jun 26, 2025 at 08:50:48AM +0100, Daniel P. Berrangé wrote: > > Yes, I can understand the benefit of testing 64 vs 32 bit in general, > > as that's a frequent source of bugs in many apps still, alongside > > big endian vs little endian, which s390x gives coverage of. > > > > Would containers mitigate this use case well enough ? > > Question: How are said containers to be constructed (much less > maintained) when working within the Fedora/RHEL ecosystem?
Thanks to Debian multi-arch it is possible to build cross envs for many archs, from any Linux system with podman/docker. This gets you a build env, though you do need qemu-user emulation (or native HW) for most combinations if you need to actually execute the binaries you build. Just having the build envs though is a massive win in reducing maint burden across distros & arches. To limit the dockerfile maint overheads long term, auto-generating dockerfiles is pretty important IME. This is one such example (auto-generated) dockerfile from libvirt's primary git repo: https://gitlab.com/libvirt/libvirt/-/blob/master/ci/containers/debian-12-cross-i686.Dockerfile for cross compilers, we have the basic Debian native toolchain installed the first layer (this content is common to all cross containers), then add the cross-arch toolchain and libraries into a second layer. Using it goes approximately like this: $ cd $HOME/src/virt/libvirt $ podman --remote run -v `pwd`:/libvirt --security-opt label=disable -it registry.gitlab.com/libvirt/libvirt/ci-debian-12-cross-i686 root@f8a173b98d5b:/# cd /libvirt root@f8a173b98d5b:/libvirt# echo $MESON_OPTS --cross-file=i686-linux-gnu root@f8a173b98d5b:/libvirt# meson build-i686 $MESON_OPTS The Meson build system Version: 1.0.1 Source dir: /libvirt Build dir: /libvirt/build-i686 Build type: cross build Project name: libvirt Project version: 11.5.0 C compiler for the host machine: /usr/bin/i686-linux-gnu-gcc (gcc 12.2.0 "i686-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0") C linker for the host machine: /usr/bin/i686-linux-gnu-gcc ld.bfd 2.40 Compiler for language c for the build machine not found. Build machine cpu family: x86_64 Build machine cpu: x86_64 Host machine cpu family: x86 Host machine cpu: i686 Target machine cpu family: x86 Target machine cpu: i686 ...snip... root@f8a173b98d5b:/libvirt# ninja -C build-i686 ...snip... We auto-generate all our dockerfiles across 30+ project git repos, for 20 different distro versions, and 11 different linux arches and 2 mingw targets. The number of possible variants is enourmous. In CI we limit what we generate by default to remain within our CI budget, but locally a dev can create any of the combinations they might need. A repo declares what it needs using a list of generic package names https://gitlab.com/libvirt/libvirt/-/blob/master/ci/lcitool/projects/libvirt.yml we then have a centralized mapping file which translates generic names to distro specific names https://gitlab.com/libvirt/libvirt-ci/-/blob/master/lcitool/facts/mappings.yml The 'lcitool' command takes the two and spits our dockerfiles for a project. We can spit out individual dockerfiles on demand, but for CI we have a manifest to declare our overall standard target set for CI purposes https://gitlab.com/libvirt/libvirt/-/blob/master/ci/manifest.yml this bulk emits the common dockerfiles we need, along with all the gitlab CI yml rules to use them. NB, the FreeBSD/macOS bits there don't use containers, they use a gross hack where we call out to Cirrus CI from GitLab CI, to use Cirrus' free hardware resources while keeping GitLab as a single dashboard. That's probably way more info than you wanted :-) Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
