This is already a primary architecture in Ubuntu, and more distributions
are adding support for it. It's too slow for emulation, but we can at
least verify that compilation works.
Use the arm worker, for two reasons:
- it is already set up with ports.ubuntu.com so we don't have to muck
with apt sources manually
- it is used a lot less than the x86 worker
arm64 hosts support running armv7 (armhf) binaries, so we can
cross compile and run the unit tests without performance issues.
armv7 (armhf) is a primary architecture on Ubuntu, so build
regressions block new version updates, and adding coverage
helps to avoid introducing regressions.
Checking for pefile required that module to be made available for the
Python used to build systemd, even though it's only used at runtime,
potentially via a different Python installation.
Furthermore, Meson's Python module doesn't do the right thing when cross
compiling and looking up a Python for the host system, so this would end
up uselessly checking whether the build Python had the pefile module,
which is not needed. Even if it were made to check the host Python using
find_program, it still relies on being able to run its Python, which in
a cross scenario it probably wouldn't be able to do.
All in all, this check does more harm than good, and prevents building
ukify in valid configurations, so remove it.
Jammy's kernel is too old at this point, and doesn't even provide a
vmlinux.h, so disable the feature in the build smoketests to let us
add new features
Co-developed-by: Luca Boccassi <luca.boccassi@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
In CI we get spurious failures about unitialized variables with gcc
versions older then (depending on the case) 12, 13, or 14. Let's only
try to do this check with newer gcc which returns more useful results.
At the same time, do compile with both gcc and clang at -O2, just
disable the warning.
The old logic seems to have been confused. We compile with -Wall, at
least in some cases, which includes -Wmaybe-unitialized. So if we
_don't_ want it, we need to explicitly disable it.
Use the same trickery we do in the package build and search for
the actual bpftool binary. For the CI job any one we find is
good enough.
When we switch all jobs to 26.04 we can drop all of this.
This reverts commit cc814110af.
/usr/sbin/bpftool is completely broken inside containers on
Ubuntu which makes meson blow up so disable the bpf-framework
stuff to avoid the issue.
TODO: Drop when we move off Ubuntu Noble as this will be fixed
in the next Ubuntu LTS release.