Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. Nov 13, 2023
    • Philippe Mathieu-Daudé's avatar
      tests/vm/netbsd: Use Python v3.11 · 00ac955b
      Philippe Mathieu-Daudé authored 
      
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: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: default avatarThomas Huth <thuth@redhat.com>
Message-ID: <20231109150900.91186-1-philmd@linaro.org>
Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      00ac955b
  3. Nov 07, 2023
  5. Oct 31, 2023
  7. Oct 27, 2023
  9. Oct 17, 2023
  11. Oct 12, 2023
  13. Sep 08, 2023
  15. Aug 28, 2023
    • Paolo Bonzini's avatar
      tests/docker: add python3-tomli dependency to containers · 7ace2193
      Paolo Bonzini authored 
      
Instead of having CI pick tomli from the vendored wheel at configure
time, place it in the containers.

Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      7ace2193
    • Paolo Bonzini's avatar
      Revert "tests: Use separate virtual environment for avocado" · c03f57fd
      Paolo Bonzini authored 
      This reverts commit e8e4298f.

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: default avatarPaolo Bonzini <pbonzini@redhat.com>
      c03f57fd
  17. Jul 18, 2023
  19. Jun 06, 2023
    • Paolo Bonzini's avatar
      tests: Use separate virtual environment for avocado · e8e4298f
      Paolo Bonzini authored 
      
This reverts commits eea2d141 ("Makefile: remove $(TESTS_PYTHON)",
2023-05-26) and 9c6692db ("tests: Use configure-provided pyvenv for
tests", 2023-05-18).

Right now, there is a conflict between wanting a ">=" constraint when
using a distro-provided package and wanting a "==" constraint when
installing Avocado from PyPI; this would provide the best of both worlds
in terms of resiliency for both distros that have required packages and
distros that don't.

The conflict is visible also for meson, where we would like to install
the latest 0.63.x version but also accept a distro 1.1.x version.
But it is worse for avocado, for two reasons:

1) we cannot use an "==" constraint to install avocado if the venv
includes a system avocado.  The distro will package plugins that 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 this error:

   ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
   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.
   make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'

2) we cannot use ">=" either if the venv does _not_ include a system
avocado, because that would result in the installation of v101.0 which
is the one we've just reverted.

So the idea is to encode the dependencies as an (acceptable, locked)
tuple, like this hypothetical TOML that would be committed inside
python/ and used by mkvenv.py:

  [meson]
  meson = { minimum = "0.63.0", install = "0.63.3", canary = "meson" }

  [docs]
  # 6.0 drops support for Python 3.7
  sphinx = { minimum = "1.6", install = "<6.0", canary = "sphinx-build" }
  sphinx_rtd_theme = { minimum = "0.5" }

  [avocado]
  avocado-framework = { minimum = "88.1", install = "88.1", canary = "avocado" }

Once this is implemented, it would also be possible to install avocado in
pyvenv/ using "mkvenv.py ensure", thus using the distro package on Fedora
and CentOS Stream (the only distros where it's available).  But until
this is implemented, keep avocado in a separate venv.  There is still the
benefit of using a single python for meson custom_targets and for sphinx.

Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      e8e4298f
  21. May 26, 2023
  23. May 18, 2023
  25. Apr 20, 2023
    • Thomas Huth's avatar
      tests/vm/freebsd: Update to FreeBSD 13.2 · ec6fb1c8
      Thomas Huth authored 
      
According to QEMU's support policy, we stop supporting the previous
major release two years after the the new major release has been
published. So we can stop testing FreeBSD 12 now and should switch
our FreeBSD VM to version 13 instead.

Some changes are needed for this update: The downloadable .ISO images
do not use the serial port as console by default anymore, so they
are not usable in the same way as with FreeBSD 12. Fortunately, the
FreeBSD project now also offers some pre-installed CI images that
have the serial console enabled, so we can use those now, with the
benefit that we can skip almost all parts of the previous installation
process.

Message-Id: <20230419144553.719749-1-thuth@redhat.com>
Reviewed-by: default avatarWarner Losh <imp@bsdimp.com>
Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      ec6fb1c8
  27. Apr 04, 2023
  29. Mar 22, 2023
  31. Feb 02, 2023
  33. Jan 18, 2023
  35. Jan 09, 2023
  37. Dec 15, 2022
  39. Oct 31, 2022
  41. Oct 28, 2022
  43. Sep 20, 2022
  45. Sep 19, 2022
  47. Aug 29, 2022
  49. Jul 18, 2022