For reasons still not clear to me passing the single dashed
-interactive would confuse the argument parsing enough we tried to
pass "nterative" as a string to the launch command causing failure and
head scratching.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-ID: <20260226185303.1920021-6-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
With the qemu.qmp and qemu.machine dependencies now installed by default
at configure time and additional dependencies required by functional
testing installed on demand, we do not need the explicit "check-venv" target.
...However, to facilitate running VM tests without running configure, we
move some of the former logic into tests/vm/Makefile.include to create a
new venv (vm-venv) on-demand when running VM tests from the source tree.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260218213416.674483-17-jsnow@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
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>
The haiku VM bitrotted in the course of time. Make sure to use the
latest version of the repositories here and install missing pieces
like "pip" and "tomli" now.
Since we nowadays also install our own version of meson in our venv,
this also requires a change to our configure script: On Haiku, the
meson binary shows up as pyvenv/non-packaged/bin/meson here, and not
in the expected location pyvenv/bin/meson. Adjust the "meson" variable
to point to that Haiku-specific location to fix this issue. See also:
https://github.com/haiku/haiku/blob/r1beta5/docs/user/storage/storageintro.dox
And finally, with the new toolchain from the beta 5, we also have to
compile with "-pie", otherwise the linker complains about bad relocations
in the object files, so allow compiling with PIE in the configure script
now.
Reviewed-by: Prasad Pandit <pjp@fedoraproject.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260123184429.5278-1-thuth@redhat.com>
NetBSD 10.1 has been released since more than a year, so it's time to
update our VM to that version.
Apart from the usual changes in the installation process, we also have
to disable the installation of the "jpeg" package now, otherwise the
package installation fails with an error message like this:
pkg_add: jpeg-9fnb1: conflicts with `libjpeg-turbo-[0-9]*', and
`libjpeg-turbo-3.1.3' is installed.
We also have to drop the executable bits from scripts/qemu-plugin-symbols.py
to force meson to use the detected Python interpreter instead of executing
the file directly (which tries to use the Python interpreter from the file's
shebang line).
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260113193554.123082-1-thuth@redhat.com>
The README file in tests/vm/ points to a non-existent file,
docs/devel/testing.rst. Update the README to point to
docs/devel/testing/main.rst, which now contains information
about VM testing.
Signed-off-by: Haseung Bong <hasueng@gmail.com>
Fixes: ff41da5030 ("docs/devel: Split testing docs from the build docs and move to separate folder")
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250607060456.28902-1-hasueng@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
We will shortly need this to build our riscv64 cross container.
However to keep the delta down just do the bump first. As ccache4 is
now preferred for FreeBSD to get the latest version there is a little
update in the FreeBSD metadata.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20250108121054.1126164-25-alex.bennee@linaro.org>
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>
Seems like the server now reports the right time again, so we have
to drop the workaround to get the installer working again.
Message-ID: <20241023072414.827732-1-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@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>
Remove tomli as Python has been updated to 3.11.
[thuth: The "Time appears wrong" line is now necessary since the server
seems to provide a wrong timestamp. We likely have to remove that again
later once the server is running with the correct time again]
Signed-off-by: Brad Smith <brad@comstyle.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Message-ID: <ZwtmfVlWgFRF9G8W@humpty.home.comstyle.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
RHEL 9 (and thus also the derivatives) have been available since two
years now, so according to QEMU's support policy, we can drop the active
support for the previous major version 8 now.
Another reason for doing this is that Centos Stream 8 will go EOL soon:
https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/
"After May 31, 2024, CentOS Stream 8 will be archived
and no further updates will be provided."
Thus upgrade our CentOS Stream container to major version 9 now.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20240418101056.302103-5-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The "check" target by itself is not enough to ensure we build the user
mode binaries. While we can't test them with check-tcg we can at least
include them in the build.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Gustavo Romero <gustavo.romero@linaro.org>
The main problem is that "check-venv" is a .PHONY target will always
evaluate and trigger a full re-build of the VM images. While its
tempting to drop it from the dependencies that does introduce a
breakage on freshly configured builds.
Fortunately we do have the otherwise redundant --force flag for the
script which up until now was always on. If we make the usage of
--force conditional on dependencies other than check-venv triggering
the update we can avoid the costly rebuild and still run cleanly on a
fresh checkout.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2118
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240227144335.1196131-4-alex.bennee@linaro.org>
After console_sshd_config(), the SSH server needs to be nudged to pick
up the new configs. The scripts for the other BSD flavors already do
this with a reboot, but a simple reload is sufficient.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-ID: <20240206002344.12372-3-iii@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
make vm-build-freebsd sometimes fails with "Connection timed out during
banner exchange". The client strace shows:
13:59:30 write(3, "SSH-2.0-OpenSSH_9.3\r\n", 21) = 21
13:59:30 getpid() = 252655
13:59:30 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
13:59:32 read(3, "S", 1) = 1
13:59:32 poll([{fd=3, events=POLLIN}], 1, 3625) = 1 ([{fd=3, revents=POLLIN}])
13:59:32 read(3, "S", 1) = 1
13:59:32 poll([{fd=3, events=POLLIN}], 1, 3625) = 1 ([{fd=3, revents=POLLIN}])
13:59:32 read(3, "H", 1) = 1
There is a 2s delay during connection, and ConnectTimeout is set to 1.
Raising it makes the issue go away, but we can do better. The server
truss shows:
888: 27.811414714 socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 5 (0x5)
888: 27.811765030 connect(5,{ AF_INET 10.0.2.3:53 },16) = 0 (0x0)
888: 27.812166941 sendto(5,"\^Z/\^A\0\0\^A\0\0\0\0\0\0\^A2"...,39,0,NULL,0) = 39 (0x27)
888: 29.363970743 poll({ 5/POLLRDNORM },1,5000) = 1 (0x1)
So the delay is due to a DNS query. Disable DNS queries in the server
config.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-ID: <20240206002344.12372-2-iii@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Since the pkgsrc-2023Q3 release [*], the py-expat package has been
merged into the base 'python' package:
- Several packages have been folded into base packages. While the
result is simpler, those updating may need to force-remove the
secondary packages, depending on the update method. When doing
make replace, one has to pkg_delete -f the secondary packages.
pkgin handles at least the python packages correctly, removing the
split package when updating python. Specific packages and the
former packages now included:
* cairo: cairo-gobject
* python: py-cElementTree py-curses py-cursespanel py-expat
py-readline py-sqlite3
Remove py311-expat from the package list in order to avoid:
### Installing packages ...
processing remote summary (http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/9.3/All)...
database for http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/9.3/All is up-to-date
py311-expat is not available in the repository
...
calculating dependencies.../py311-expat is not available in the repository
pkg_install error log can be found in /var/db/pkgin/pkg_install-err.log
[*] https://mail-index.netbsd.org/netbsd-announce/2024/01/01/msg000360.html
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2109
Tested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240117140746.23511-1-philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
We requiere the 'ninja-build', which depends on 'python311':
$ pkgin show-deps ninja-build
direct dependencies for ninja-build-1.11.1nb1
python311>=3.11.0
So we end up installing both Python v3.10 and v3.11:
[31/76] installing python311-3.11.5...
[54/76] installing python310-3.10.13...
[74/76] installing py310-expat-3.10.13nb1...
Then the build system picks Python v3.11, and doesn't find
py-expat because we only installed the 3.10 version:
python determined to be '/usr/pkg/bin/python3.11'
python version: Python 3.11.5
*** Ouch! ***
Python's pyexpat module is not found.
It's normally part of the Python standard library, maybe your distribution packages it separately?
Either install pyexpat, or alleviate the need for it in the first place by installing pip and setuptools for '/usr/pkg/bin/python3.11'.
(Hint: NetBSD's pkgsrc debundles this to e.g. 'py310-expat'.)
ERROR: python venv creation failed
Fix by installing py-expat for v3.11. Remove the v3.10
packages since we aren't using them anymore.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20231109150900.91186-1-philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
libfdt is installed in /usr/local on FreeBSD, and since this
library does not have a pkg-config file, we have to specify the
paths manually. This way we can avoid that Meson has to recompile
the dtc subproject each time.
Message-ID: <20231016161053.39150-1-thuth@redhat.com>
Reviewed-by: Warner Losh <imp@bsdimp.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
This is an error in Python 3.12; fix it by using a raw string literal
or by double-escaping the backslash.
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Install dtc as it is now a mandatory external dependency in order to build QEMU.
Co-developed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
with some rewording in
tests/qemu-iotests/298
tests/qtest/fuzz/generic_fuzz.c
tests/unit/test-throttle.c
as suggested by Eric.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Eric Blake <eblake@redhat.com>
Instead of having CI pick tomli from the vendored wheel at configure
time, place it in the containers.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This reverts commit e8e4298fea.
ensuregroup allows to specify both the acceptable versions of avocado,
and a locked version to be used when avocado is not installed as a system
pacakge. This lets us install avocado in pyvenv/ using "mkvenv.py" and
reuse the distro package on Fedora and CentOS Stream (the only distros
where it's available).
ensuregroup's usage of "(>=..., <=...)" constraints when evaluating
the distro package, and "==" constraints when installing it from PyPI,
makes it possible to avoid conflicts between the known-good version and
a package plugins included in the distro.
This is because package plugins have "==" constraints on the version
that is included in the distro, and, using "pip install avocado==88.1"
on a venv that includes system packages will result in an error:
avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 88.1 which is incompatible.
But at the same time, if the venv does not include a system distribution
of avocado then we can install a known-good version and stick to LTS
releases.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1663
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
