The --quiet command is used with docker unless V=1 is passed to make,
and as a result stdout from docker is never visible by default, making
it hard to diagnose failures building / running containers.
Meanwhile passing V=1 is undesirable as that makes the entire build
system verbose.
Introduce a $(DOCKER_V) make variable which is initialized from $(V)
It is thus possible to display docker output without also enabling
make verbose output.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260210163556.713841-4-berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
When a developer's environment is already within a podman container it
is not possible to use 'podman' again to create containers. It will
usually result in wierd errors such as:
Error: fatal error, invalid internal status, unable to create a new pause process: cannot re-exec process to join the existing user namespace. Try running "podman system migrate" and if that doesn't work reboot to recover
Podman offers the ability to talk to a daemon outside the container,
however, which could be leveraged by QEMU.
This can be used by invoking "podman --remote", or equivalently the
separate "podman-remote" binary:
https://github.com/containers/podman/blob/main/docs/tutorials/remote_client.md
The current 'podman version' check is insufficient to detect the
inability to launch containers, so it is replaced with the stronger
'podman info' check.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260210163556.713841-3-berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The docker.py script has logic to guess the container command and
detects one of
* docker
* sudo -n docker
* podman
but the "docker.py probe" command then throws away the detected argv
and prints a slightly different argv based solely on the detected
argv[0]. The result is that 'probe' will print
* docker
* sudo docker
* podman
which means that if sudo was detected & the result of 'probe' were
used directly, it would end up prompting for password interaction
every time.
The 'configure' script, however, runs 'probe' and then throws away
the printed argv again, reporting only 'podman' or 'docker', which
is used to set the $(RUNC) variable for tests/docker/Makefile.include
which is in turn used to pass --engine to docker.py. So the docker.py
command will re-detect the need for 'sudo -n' and use it correctly
The problem with this is that some commands in Makefile.include do
not call docker.py at all, they invoke $(RUNC) directly. Since
configure threw away the 'sudo' command prefix Makefile.in won't
be adding either 'sudo' or 'sudo -n', it'll just run plain 'docker'
which is wrong.
This commit sanitizes things so that the 'docker.py probe' prints
out the exact detected ARGV, and configure fully preserves this
ARGV when setting $(RUNC). Since "$(RUNC)" is no longer just a bare
engine name, however, we must now also set the $(CONTAINER_ENGINE)
variable for Makefile.include so it can pass something sane to
the --engine arg for docker.py
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260210163556.713841-2-berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The bugs have evidently been fixed in the latest release so we can
migrate the laggards into how all-test-cross container and remove the
legacy hacks. They are also packaged for the main architectures so we
don't need to jump through the amd64 hoops.
Suggested-by: John Snow <jsnow@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260226185303.1920021-3-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Debian 11 was EOL in 2024, and Debian 12 will be EOL this June. This
patch moves all but one of our tests, debian-legacy-test-cross, onto
Debian 13.
This patch does the bare minimum to upgrade these tests and doesn't make
any attempt at optimization or cleanup that may or may not be possible
with this upgrade.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
[AJB: tweak summary line]
Message-ID: <20260226185303.1920021-2-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Installing local dependencies while offline, without PyPI access,
requires the python3-setuptools and python3-wheel packages. Most
distributions have these available anyway for one reason or another, but
not all of them.
If you are asking yourself "Wait, aren't these packages guaranteed via
installation of pip, via the ensurepip module, which mkvenv takes
immense pains to provide for us?" - Well... since Python 3.13, "pip"
does not actually come with "setuptools" or "wheel" anymore, and so if
we want to build and install a python package, we actually need these
available in the host environment.
(Note that you don't need these packages just to install a pre-built
package, you only need them to *build* a package. With cutting edge
setuptools and pip, all locally installed packages, even in editable
mode, must be "built" first before being installed. Thus, these
dependencies are being added specifically to facilitate installing
qemu.git/python/qemu to the configure-time venv.)
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260218213416.674483-12-jsnow@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Update to latest lcitool master and refresh tests. Fedora is upgraded to
Fedora 43 and Alpine from 3.21 to 3.23 as a result.
This is being done in this series primarily to ensure that MacOS
installs python-setuptools, which is now separate from the core python
package, and which is needed for this series to work correctly.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260218213416.674483-11-jsnow@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Now we are 64 bit only there is no need to keep the generic name. This
also fixes a check failure in the weekly container build which was
checking containers based on the expansion of DOCKER_IMAGES which is
based of the dockerfile names.
Remove the DOCKERFILE bits that were added to handle multiple
containers from the same dockerfile.
Fixes: 4203ea0247 (gitlab-ci: Add build tests for wasm64)
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260128105839.3487840-2-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
We will no longer build wasm32, so drop the docker config.
Streamline the dockerfile to hardcode TARGET_CPU as wasm64.
Reviewed-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
We use this container to build system images in CI which do not honour
QEMU_CONFIGURE_OPTS. Drop the --disables from the container so
developers don not need to jump through hoops trying to replicate that
on their workstations.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20251204194902.1340008-8-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
While we are at it bump up to debian-13. As we use this container in
the CI runs this also has the benefit of ensuring our qemu-minimal
dependencies project really has just what we need to build a basic
QEMU.
We add a few extra packages so we can build with clang as well as what
we need to probe for the available cross-compilers in the image.
Message-ID: <20251204194902.1340008-7-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
This will hopefully catch containers that break because of upstream
changes as well as keep the container cache fresh.
As we have all the container jobs as dependants we tweaks the
container template to allow scheduled runs. Because we added a new
rules stanza we also need to make sure we catch the normal runs as
well.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20251117115523.3993105-19-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Ubuntu is now including updated versions of Rust (up to 1.85) for
its LTS releases. Adjust the CI containers and re-add --enable-rust
to the Ubuntu jobs.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
It turns out you can't easily expand an ENV var across multiple steps
in a dockerfile. This meant we silently dropped the architectures we
should have even on amd64 hosts. As the updated AVAILABLE_COMPILERS is
only needed for the following apt install line just merge them.
Fixes: 6da616bb17 (tests/docker: handle host-arch selection for all-test-cross)
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-ID: <20250804104308.250949-1-alex.bennee@linaro.org>
rustdoc is effectively a custom version of rustc, and it is necessary to
specify it in order to run doctests from Meson. Add the relevant configure
option and environment variables.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
On Debian, the rustc-web package provides a newer Rust compiler (1.78)
for all architectures except mips64el.
On Ubuntu, Rust versions up to 1.80 (?) are available as of this writing
for both Jammy (22.04) and Noble (24.04). However, the path to rustc
and rustdoc must be provided by hand to the configure script using
either command line arguments or environment variables.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Python 3.8 went "end of life" in October 2024 and Fedora 42 dropped
this version already, so the "python" CI job is currently failing.
Thus it's time to drop support for this Python version in QEMU, too.
While we're at it, also look for "python3.13" in the configure script.
Message-ID: <20250425120710.879518-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Although riscv64 isn't going to be a release architecture for trixie
the packages are still built while it is testing. Moving from sid will
also avoid some of the volatility we get from tracking the bleeding
edge.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20250108121054.1126164-26-alex.bennee@linaro.org>
Code checks, as well as documentation generation, are not yet tied
to "make check" because they need new version of the Rust toolchain
(even nightly in the case of "rustfmt"). Run them in CI using the
existing nightly-Rust container.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This updates the libvirt-ci submodule to pull in various fixes,
the most notable reducing native package sets in cross builds.
Some packages were mistakenly marked as native, rather than
foreign, in libvirt-ci. Fixing this causes our dockerfiles to
pick up the cross arch package instead of native one, thus
improving our test coverage in a few areas.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20241106123525.511491-1-berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Because Ubuntu 22.04 has a very old version of bindgen, that
does not have the important option --allowlist-file, it will
not be able to use --enable-rust out of the box. Instead,
install the latest version of bindgen-cli via "cargo install"
in the container, following QEMU's own documentation.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
libcbor dependecy is necessary for adding virtio-nsm and nitro-enclave
machine support in the following commits. libvirt-ci has already been
updated with the dependency upstream and this commit updates libvirt-ci
submodule in QEMU to latest upstream. Also the libcbor dependency has
been added to tests/lcitool/projects/qemu.yml.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Link: https://lore.kernel.org/r/20241008211727.49088-2-dorjoychy111@gmail.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Although we're not enabling rust by default yet, we can still add
rust and bindgen to the CI package list.
This demonstrates that we're not accidentally triggering unexpected
build behaviour merely from Rust being present. When we do dev work
to enable rust by default, this will show we're building correctly
on all platforms we target.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Link: https://lore.kernel.org/r/20241015133925.311587-2-berrange@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
