aboutsummaryrefslogtreecommitdiff
path: root/pythondeps.toml
AgeCommit message (Collapse)AuthorFilesLines
2024-09-04python: Install pycotap in our venv if necessaryThomas Huth1-0/+1
The upcoming functional tests will require pycotap for providing TAP output from the python-based tests. Since we want to be able to run some of the tests offline by default, too, let's install it along with meson in our venv if necessary (it's size is only 5 kB, so adding the wheel here should not really be a problem). The wheel file has been obtained with: pip download --only-binary :all: --dest . --no-cache pycotap Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20240830133841.142644-8-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-09-04Bump avocado to 103.0Cleber Rosa1-1/+1
This bumps Avocado to latest the LTS release. An LTS release is one that can receive bugfixes and guarantees stability for a much longer period and has incremental minor releases made. Even though the 103.0 LTS release is pretty a rewrite of Avocado when compared to 88.1, the behavior of all existing tests under tests/avocado has been extensively tested no regression in behavior was found. To keep behavior of jobs as close as possible with previous version, this version bump keeps the execution serial (maximum of one task at a time being run). Reference: https://avocado-framework.readthedocs.io/en/103.0/releases/lts/103_0.html Signed-off-by: Cleber Rosa <crosa@redhat.com> Tested-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Message-ID: <20240806173119.582857-2-crosa@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240830133841.142644-5-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-07-12Python: bump minimum sphinx version to 3.4.3John Snow1-1/+1
With RHEL 8 support retired (It's been two years since RHEL9 released), our very oldest build platform version of Sphinx is now 3.4.3; and keeping backwards compatibility for versions as old as v1.6 when using domain extensions is a lot of work we don't need to do. This patch is motivated by my work creating a new QAPI domain, which unlike the dbus documentation, cannot be allowed to regress by creating a "dummy" doc when operating under older sphinx versions. Easier is to raise our minimum version as far as we can push it forwards, reducing my burden in creating cross-compatibility hacks and patches. A sampling of sphinx versions from various distributions, courtesy https://repology.org/project/python:sphinx/versions Alpine 3.16: v4.3.0 (QEMU support ended 2024-05-23) Alpine 3.17: v5.3.0 Alpine 3.18: v6.1.3 Alpine 3.19: v6.2.1 Ubuntu 20.04 LTS: EOL Ubuntu 22.04 LTS: v4.3.2 Ubuntu 22.10: EOL Ubuntu 23.04: EOL Ubuntu 23.10: v5.3.0 Ubuntu 24.04 LTS: v7.2.6 Debian 11: v3.4.3 (QEMU support ends 2024-07-xx) Debian 12: v5.3.0 Fedora 38: EOL Fedora 39: v6.2.1 Fedora 40: v7.2.6 CentOS Stream 8: v1.7.6 (QEMU support ended 2024-05-17) CentOS Stream 9: v3.4.3 OpenSUSE Leap 15.4: EOL OpenSUSE Leap 15.5: 2.3.1, 4.2.0 and 7.2.6 RHEL9 / CentOS Stream 9 becomes the new defining factor in staying at Sphinx 3.4.3 due to downstream offline build requirements that force us to use platform Sphinx instead of newer packages from PyPI. Signed-off-by: John Snow <jsnow@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-id: 20240703175235.239004-2-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2024-07-03meson: Pass objects and dependencies to declare_dependency()Akihiko Odaki1-1/+1
We used to request declare_dependency() to link_whole static libraries. If a static library is a thin archive, GNU ld keeps all object files referenced by the archive open, and sometimes exceeds the open file limit. Another problem with link_whole is that suboptimal handling of nested dependencies. link_whole by itself does not propagate dependencies. In particular, gnutls, a dependency of crypto, is not propagated to its users, and we currently workaround the issue by declaring gnutls as a dependency for each crypto user. On the other hand, if you write something like libfoo = static_library('foo', 'foo.c', dependencies: gnutls) foo = declare_dependency(link_whole: libfoo) libbar = static_library('bar', 'bar.c', dependencies: foo) bar = declare_dependency(link_whole: libbar, dependencies: foo) executable('prog', sources: files('prog.c'), dependencies: [foo, bar]) hoping to propagate the gnutls dependency into bar.c, you'll see a linking failure for "prog", because the foo.c.o object file is included in libbar.a and therefore it is linked twice into "prog": once from libfoo.a and once from libbar.a. Here Meson does not see the duplication, it just asks the linker to link all of libfoo.a and libbar.a into "prog". Instead of using link_whole, extract objects included in static libraries and pass them to declare_dependency(); and then the dependencies can be added as well so that they are propagated, because object files on the linker command line are always deduplicated. This requires Meson 1.1.0 or later. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-ID: <20240524-objects-v1-1-07cbbe96166b@daynix.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-04-23pythondeps.toml: warn about updates needed to docs/requirements.txtPaolo Bonzini1-0/+1
docs/requirements.txt is expected by readthedocs and should be in sync with pythondeps.toml. Add a comment to both. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-24buildsys: Bump known good meson version to v1.2.3Philippe Mathieu-Daudé1-1/+1
We need meson v1.2.3 to build QEMU on macOS Sonoma. It also builds fine all our CI jobs (as tested by also bumping "accepted" in pythondeps.toml), so let's use it as our "good enough" packaged wheel. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1939 Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231109160504.93677-2-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-11-24docs: document what configure does with virtual environmentsPaolo Bonzini1-1/+2
Given the recent confusion around how QEMU detects the system Meson installation, and/or decides to install its own, it is time to fill in the "Python virtual environments and the QEMU build system" section of the documentation. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-08-28Revert "tests: Use separate virtual environment for avocado"Paolo Bonzini1-0/+7
This reverts commit e8e4298feadae7924cf7600bb3bcc5b0a8d7cbe9. 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>
2023-08-28configure: switch to ensuregroupPaolo Bonzini1-0/+8
Using the new ensuregroup command, the desired versions of meson and sphinx can be placed in pythondeps.toml rather than configure. The meson.install entry in pythondeps.toml matches the version that is found in python/wheels. This ensures that mkvenv.py uses the bundled wheel even if PyPI is enabled; thus not introducing warnings or errors from versions that are more recent than the one used in CI. The sphinx entries match what is shipped in Fedora 38. It's the last release that has support for older versions of Python (sphinx 6.0 requires Python 3.8) and especially docutils (of which sphinx 6.0 requires version 0.18). This is important because Ubuntu 20.04 has docutils 0.14 and Debian 11 has docutils 0.16. "mkvenv.py ensure" is only used to bootstrap tomli. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-08-28python: mkvenv: add ensuregroup commandPaolo Bonzini1-0/+17
Introduce a new subcommand that retrieves the packages to be installed from a TOML file. This allows being more flexible in using the system version of a package, while at the same time using a known-good version when installing the package. This is important for packages that sometimes have backwards-incompatible changes or that depend on specific versions of their dependencies. Compared to JSON, TOML is more human readable and easier to edit. A parser is available in 3.11 but also available as a small (12k) package for older versions, tomli. While tomli is bundled with pip, this is only true of recent versions of pip. Of all the supported OSes pretty much only FreeBSD has a recent enough version of pip while staying on Python <3.11. So we cannot use the same trick that is in place for distlib. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>