Container image builds have started failing because zlib.net no longer
hosts the 1.3.1 tarball. Move to the 1.3.2 release from February 17,
2026.
$ make docker-image-emsdk-wasm64-cross
changing dir to build for make "docker-image-emsdk-wasm64-cross"...
make[1]: Entering directory 'qemu/build'
BUILD emsdk-wasm64-cross
...
xz: (stdin): File format not recognized
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Error: building at STEP "RUN curl -Ls https://zlib.net/zlib-$ZLIB_VERSION.tar.xz | tar xJC /zlib --strip-components=1": while running runtime: exit status 2
make[1]: *** [qemu/tests/docker/Makefile.include:43: docker-image-emsdk-wasm64-cross] Error 2
make[1]: Leaving directory 'qemu/build'
make: *** [GNUmakefile:6: build] Error 2
Cc: Kohei Tokunaga <ktokunaga.mail@gmail.com>
Cc: Brian Cain <brian.cain@oss.qualcomm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-id: 20260625193320.260312-1-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Update the hexagon cross-compiler Docker container to use toolchain
version 22.1.0, replacing the previous 12.Dec.2023 release.
Changes to accommodate the new toolchain:
- Add libc++1, libc++abi1, libunwind-19 runtime deps for the new
LLVM-based toolchain
- Add zstd for the new .tar.zst archive format
- Update artifact URL domain to artifacts.codelinaro.org
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Glusterfs has been marked as deprecated since QEMU v9.2, and as far
as I know, nobody spoke up 'til today that it should be kept.
The listed e-mail address integration@gluster.org in our MAINTAINERS
file seems to be bouncing nowadays, and looking at their website
https://www.gluster.org/ the most recent news are from 2020 / 2021 ...
so it seems like there is really hardly any interest in Glusterfs
anymore. Thus it's time to remove the code now from QEMU.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260511063013.39805-1-thuth@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
nmap / ncat has a somewhat problematic license (e.g. saying claiming
that derived work is also considered for software that "is designed
specifically to execute Covered Software and parse the results", e.g.
by executing ncat from your own program, you might already fall into
this category) - so for example in openSUSE 16, you can only find it
in the "non-OSS" repository.
We are currently only using it in the migration functional test, and
that likely does not fall into this "derived work" category yet (since
it is also doing some other stuff), but still, to be safe, we should
move away from using it now.
Unfortunately, switching to one of the other flavors of netcat is
also not a real option (see commit f700abbbeb),
but socat should be a solid replacement here instead.
To avoid that someone else easily uses ncat again, let's also remove
it from our container files now.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260316183016.239526-1-thuth@redhat.com>
Message-ID: <20260320155107.2143191-9-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Without the option, cargo will try using the latest version of the
dependencies of bindgen-cli. While it will obviously respect the
constraints in Cargo.toml, old versions of Cargo do not have
version-constrained resolution and will choke on dependencies
that need Rust 2024.
Cc: Daniel P. Berrangé <berrange@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@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>
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>
