The macOS jobs in our CI recently started failing, complaining that
the distutils module is not available anymore. And indeed, according to
https://peps.python.org/pep-0632/ it's been deprecated since a while
and now likely got removed in recent Python versions.
Fortunately, we only use it for a version check via LooseVersion here
which we don't really need anymore - according to Repology.org, these
are the versions of sphinx-rtd-theme that are currently used by the
various distros:
centos_stream_8: 0.3.1
centos_stream_9: 0.5.1
fedora_38: 1.1.1
fedora_39: 1.2.2
freebsd: 1.0.0
haikuports_master: 1.2.1
openbsd: 1.2.2
opensuse_leap_15_5: 0.5.1
pkgsrc_current: 2.0.0
debian_11: 0.5.1
debian_12: 1.2.0
ubuntu_20_04: 0.4.3
ubuntu_22_04: 1.0.0
ubuntu_24_04: 2.0.0
So except for CentOS 8, all distros are using a newer version of
sphinx-rtd-theme, and for CentOS 8 we don't support compiling with
the Sphinx of the distro anymore anyway, since it's based on the
Python 3.6 interpreter there. For compiling on CentOS 8, you have
to use the alternative Python 3.8 interpreter which comes without
Sphinx, so that needs the Sphinx installed via pip in the venv
instead, and that is using a newer version, too, according to our
pythondeps.toml file.
Thus we can simply drop the version check now to get rid of the
distutils dependency here.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
v2: Updated the commit description (it's about sphinx-rtd-theme,
not the Sphinx program itself)
docs/conf.py | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/docs/conf.py b/docs/conf.py
index e84a95e71c..1b2afa241c 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -29,7 +29,6 @@
import os
import sys
import sphinx
-from distutils.version import LooseVersion
from sphinx.errors import ConfigError
# The per-manual conf.py will set qemu_docdir for a single-manual build;
@@ -165,11 +164,10 @@
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
-if LooseVersion(sphinx_rtd_theme.__version__) >= LooseVersion("0.4.3"):
- html_theme_options = {
- "style_nav_header_background": "#802400",
- "navigation_with_keys": True,
- }
+html_theme_options = {
+ "style_nav_header_background": "#802400",
+ "navigation_with_keys": True,
+}
html_logo = os.path.join(qemu_docdir, "../ui/icons/qemu_128x128.png")
--
2.44.0Thomas Huth <thuth@redhat.com> writes: > The macOS jobs in our CI recently started failing, complaining that > the distutils module is not available anymore. And indeed, according to > https://peps.python.org/pep-0632/ it's been deprecated since a while > and now likely got removed in recent Python versions. > > Fortunately, we only use it for a version check via LooseVersion here > which we don't really need anymore - according to Repology.org, these > are the versions of sphinx-rtd-theme that are currently used by the > various distros: > > centos_stream_8: 0.3.1 > centos_stream_9: 0.5.1 > fedora_38: 1.1.1 > fedora_39: 1.2.2 > freebsd: 1.0.0 > haikuports_master: 1.2.1 > openbsd: 1.2.2 > opensuse_leap_15_5: 0.5.1 > pkgsrc_current: 2.0.0 > debian_11: 0.5.1 > debian_12: 1.2.0 > ubuntu_20_04: 0.4.3 > ubuntu_22_04: 1.0.0 > ubuntu_24_04: 2.0.0 > > So except for CentOS 8, all distros are using a newer version of > sphinx-rtd-theme, and for CentOS 8 we don't support compiling with > the Sphinx of the distro anymore anyway, since it's based on the > Python 3.6 interpreter there. For compiling on CentOS 8, you have > to use the alternative Python 3.8 interpreter which comes without > Sphinx, so that needs the Sphinx installed via pip in the venv > instead, and that is using a newer version, too, according to our > pythondeps.toml file. > > Thus we can simply drop the version check now to get rid of the > distutils dependency here. > > Signed-off-by: Thomas Huth <thuth@redhat.com> Queued to testing/next, thanks. -- Alex Bennée Virtualisation Tech Lead @ Linaro
On Mon, 4 Mar 2024 at 21:15, Alex Bennée <alex.bennee@linaro.org> wrote: > > Thomas Huth <thuth@redhat.com> writes: > > > The macOS jobs in our CI recently started failing, complaining that > > the distutils module is not available anymore. And indeed, according to > > https://peps.python.org/pep-0632/ it's been deprecated since a while > > and now likely got removed in recent Python versions. > > > > Fortunately, we only use it for a version check via LooseVersion here > > which we don't really need anymore - according to Repology.org, these > > are the versions of sphinx-rtd-theme that are currently used by the > > various distros: > > > > centos_stream_8: 0.3.1 > > centos_stream_9: 0.5.1 > > fedora_38: 1.1.1 > > fedora_39: 1.2.2 > > freebsd: 1.0.0 > > haikuports_master: 1.2.1 > > openbsd: 1.2.2 > > opensuse_leap_15_5: 0.5.1 > > pkgsrc_current: 2.0.0 > > debian_11: 0.5.1 > > debian_12: 1.2.0 > > ubuntu_20_04: 0.4.3 > > ubuntu_22_04: 1.0.0 > > ubuntu_24_04: 2.0.0 > > > > So except for CentOS 8, all distros are using a newer version of > > sphinx-rtd-theme, and for CentOS 8 we don't support compiling with > > the Sphinx of the distro anymore anyway, since it's based on the > > Python 3.6 interpreter there. For compiling on CentOS 8, you have > > to use the alternative Python 3.8 interpreter which comes without > > Sphinx, so that needs the Sphinx installed via pip in the venv > > instead, and that is using a newer version, too, according to our > > pythondeps.toml file. > > > > Thus we can simply drop the version check now to get rid of the > > distutils dependency here. > > > > Signed-off-by: Thomas Huth <thuth@redhat.com> > > Queued to testing/next, thanks. I've applied this directly upstream to fix CI (give or take the homebrew side of it). thanks -- PMM
On Mon, 4 Mar 2024 at 13:04, Thomas Huth <thuth@redhat.com> wrote: > > The macOS jobs in our CI recently started failing, complaining that > the distutils module is not available anymore. And indeed, according to > https://peps.python.org/pep-0632/ it's been deprecated since a while > and now likely got removed in recent Python versions. This doesn't seem to be sufficient to fix the macos CI: something in glib seems to still be using it. https://gitlab.com/qemu-project/qemu/-/jobs/6313212803 [281/6553] Generating ui/dbus-display gdbus-codegen with a custom command FAILED: ui/dbus-display1.h ui/dbus-display1.c /opt/homebrew/Cellar/glib/2.78.4/bin/gdbus-codegen ui/dbus-display1.xml --glib-min-required 2.64 --output-directory /private/var/folders/xc/tpssff9959345bnqq4c6tlww0000gn/T/cirrus-ci-build/build/ui --interface-prefix org.qemu. --c-namespace QemuDBus --generate-c-code dbus-display1 Traceback (most recent call last): File "/opt/homebrew/Cellar/glib/2.78.4/bin/gdbus-codegen", line 53, in <module> from codegen import codegen_main File "/opt/homebrew/Cellar/glib/2.78.4/share/glib-2.0/codegen/codegen_main.py", line 29, in <module> from . import dbustypes File "/opt/homebrew/Cellar/glib/2.78.4/share/glib-2.0/codegen/dbustypes.py", line 22, in <module> from . import utils File "/opt/homebrew/Cellar/glib/2.78.4/share/glib-2.0/codegen/utils.py", line 22, in <module> import distutils.version ModuleNotFoundError: No module named 'distutils' thanks -- PMM
On 04/03/2024 17.56, Peter Maydell wrote: > On Mon, 4 Mar 2024 at 13:04, Thomas Huth <thuth@redhat.com> wrote: >> >> The macOS jobs in our CI recently started failing, complaining that >> the distutils module is not available anymore. And indeed, according to >> https://peps.python.org/pep-0632/ it's been deprecated since a while >> and now likely got removed in recent Python versions. > > This doesn't seem to be sufficient to fix the macos CI: > something in glib seems to still be using it. > > https://gitlab.com/qemu-project/qemu/-/jobs/6313212803 > > [281/6553] Generating ui/dbus-display gdbus-codegen with a custom command > FAILED: ui/dbus-display1.h ui/dbus-display1.c > /opt/homebrew/Cellar/glib/2.78.4/bin/gdbus-codegen > ui/dbus-display1.xml --glib-min-required 2.64 --output-directory > /private/var/folders/xc/tpssff9959345bnqq4c6tlww0000gn/T/cirrus-ci-build/build/ui > --interface-prefix org.qemu. --c-namespace QemuDBus --generate-c-code > dbus-display1 ... > ModuleNotFoundError: No module named 'distutils' Looking at the glib sources, I think this has been fixed here: https://gitlab.gnome.org/GNOME/glib/-/commit/6ef967a0f930ce37a8c9b5aff96969 The fix will be in glib 2.79, unfortunately homebrew still seems to use glib 2.78 ... We could maybe temporarily work-around the problem by disabling the dbus code in the CI job? Or just wait for homebrew to update the package? Thomas
On Mon, Mar 04, 2024 at 06:11:58PM +0100, Thomas Huth wrote: > On 04/03/2024 17.56, Peter Maydell wrote: > > On Mon, 4 Mar 2024 at 13:04, Thomas Huth <thuth@redhat.com> wrote: > > > > > > The macOS jobs in our CI recently started failing, complaining that > > > the distutils module is not available anymore. And indeed, according to > > > https://peps.python.org/pep-0632/ it's been deprecated since a while > > > and now likely got removed in recent Python versions. > > > > This doesn't seem to be sufficient to fix the macos CI: > > something in glib seems to still be using it. > > > > https://gitlab.com/qemu-project/qemu/-/jobs/6313212803 > > > > [281/6553] Generating ui/dbus-display gdbus-codegen with a custom command > > FAILED: ui/dbus-display1.h ui/dbus-display1.c > > /opt/homebrew/Cellar/glib/2.78.4/bin/gdbus-codegen > > ui/dbus-display1.xml --glib-min-required 2.64 --output-directory > > /private/var/folders/xc/tpssff9959345bnqq4c6tlww0000gn/T/cirrus-ci-build/build/ui > > --interface-prefix org.qemu. --c-namespace QemuDBus --generate-c-code > > dbus-display1 > ... > > ModuleNotFoundError: No module named 'distutils' > > Looking at the glib sources, I think this has been fixed here: > > https://gitlab.gnome.org/GNOME/glib/-/commit/6ef967a0f930ce37a8c9b5aff96969 > > The fix will be in glib 2.79, unfortunately homebrew still seems to use glib > 2.78 ... > > We could maybe temporarily work-around the problem by disabling the dbus > code in the CI job? Or just wait for homebrew to update the package? File a bug against homebrew. IME they are very quick (1-3 days) at putting out fixes for things like this, especially if you point them to the upstream solution. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 04/03/2024 19.04, Daniel P. Berrangé wrote: > On Mon, Mar 04, 2024 at 06:11:58PM +0100, Thomas Huth wrote: >> On 04/03/2024 17.56, Peter Maydell wrote: >>> On Mon, 4 Mar 2024 at 13:04, Thomas Huth <thuth@redhat.com> wrote: >>>> >>>> The macOS jobs in our CI recently started failing, complaining that >>>> the distutils module is not available anymore. And indeed, according to >>>> https://peps.python.org/pep-0632/ it's been deprecated since a while >>>> and now likely got removed in recent Python versions. >>> >>> This doesn't seem to be sufficient to fix the macos CI: >>> something in glib seems to still be using it. >>> >>> https://gitlab.com/qemu-project/qemu/-/jobs/6313212803 >>> >>> [281/6553] Generating ui/dbus-display gdbus-codegen with a custom command >>> FAILED: ui/dbus-display1.h ui/dbus-display1.c >>> /opt/homebrew/Cellar/glib/2.78.4/bin/gdbus-codegen >>> ui/dbus-display1.xml --glib-min-required 2.64 --output-directory >>> /private/var/folders/xc/tpssff9959345bnqq4c6tlww0000gn/T/cirrus-ci-build/build/ui >>> --interface-prefix org.qemu. --c-namespace QemuDBus --generate-c-code >>> dbus-display1 >> ... >>> ModuleNotFoundError: No module named 'distutils' >> >> Looking at the glib sources, I think this has been fixed here: >> >> https://gitlab.gnome.org/GNOME/glib/-/commit/6ef967a0f930ce37a8c9b5aff96969 >> >> The fix will be in glib 2.79, unfortunately homebrew still seems to use glib >> 2.78 ... >> >> We could maybe temporarily work-around the problem by disabling the dbus >> code in the CI job? Or just wait for homebrew to update the package? > > File a bug against homebrew. IME they are very quick (1-3 days) at > putting out fixes for things like this, especially if you point them > to the upstream solution. Ok, while I was writing my mail, I was looking at https://brew.sh/ and didn't see a link to a bug tracker there ... but now I realized that they are simply using the github tracker, so I went ahead and filed a bug there: https://github.com/Homebrew/brew/issues/16823 Let's see how it goes... Thomas
On Tue, 5 Mar 2024 at 10:39, Thomas Huth <thuth@redhat.com> wrote: > > On 04/03/2024 19.04, Daniel P. Berrangé wrote: > > On Mon, Mar 04, 2024 at 06:11:58PM +0100, Thomas Huth wrote: > >> On 04/03/2024 17.56, Peter Maydell wrote: > >>> On Mon, 4 Mar 2024 at 13:04, Thomas Huth <thuth@redhat.com> wrote: > >>>> > >>>> The macOS jobs in our CI recently started failing, complaining that > >>>> the distutils module is not available anymore. And indeed, according to > >>>> https://peps.python.org/pep-0632/ it's been deprecated since a while > >>>> and now likely got removed in recent Python versions. > >>> > >>> This doesn't seem to be sufficient to fix the macos CI: > >>> something in glib seems to still be using it. > >>> > >>> https://gitlab.com/qemu-project/qemu/-/jobs/6313212803 > >>> > >>> [281/6553] Generating ui/dbus-display gdbus-codegen with a custom command > >>> FAILED: ui/dbus-display1.h ui/dbus-display1.c > >>> /opt/homebrew/Cellar/glib/2.78.4/bin/gdbus-codegen > >>> ui/dbus-display1.xml --glib-min-required 2.64 --output-directory > >>> /private/var/folders/xc/tpssff9959345bnqq4c6tlww0000gn/T/cirrus-ci-build/build/ui > >>> --interface-prefix org.qemu. --c-namespace QemuDBus --generate-c-code > >>> dbus-display1 > >> ... > >>> ModuleNotFoundError: No module named 'distutils' > >> > >> Looking at the glib sources, I think this has been fixed here: > >> > >> https://gitlab.gnome.org/GNOME/glib/-/commit/6ef967a0f930ce37a8c9b5aff96969 > >> > >> The fix will be in glib 2.79, unfortunately homebrew still seems to use glib > >> 2.78 ... > >> > >> We could maybe temporarily work-around the problem by disabling the dbus > >> code in the CI job? Or just wait for homebrew to update the package? > > > > File a bug against homebrew. IME they are very quick (1-3 days) at > > putting out fixes for things like this, especially if you point them > > to the upstream solution. > > Ok, while I was writing my mail, I was looking at https://brew.sh/ and > didn't see a link to a bug tracker there ... but now I realized that they > are simply using the github tracker, so I went ahead and filed a bug there: > > https://github.com/Homebrew/brew/issues/16823 > > Let's see how it goes... Seems to be going slowly. I notice that there's a comment in there saying that "brew install python-setuptools" is a workaround to get glib 2.78 working -- that seems like it would be good to get our CI back to green. Is there a way to test changes to the cirrus config short of committing it and seeing if it helps? I don't see the jobs available on a pipeline in my personal gitlab repo... thanks -- PMM
On Sat, 9 Mar 2024 at 17:27, Peter Maydell <peter.maydell@linaro.org> wrote: > > On Tue, 5 Mar 2024 at 10:39, Thomas Huth <thuth@redhat.com> wrote: > > Ok, while I was writing my mail, I was looking at https://brew.sh/ and > > didn't see a link to a bug tracker there ... but now I realized that they > > are simply using the github tracker, so I went ahead and filed a bug there: > > > > https://github.com/Homebrew/brew/issues/16823 > > > > Let's see how it goes... > > Seems to be going slowly. ...but they've just rolled out the glib 2.80 version, so our CI job is passing again now. Yay! -- PMM
On 9/3/24 18:27, Peter Maydell wrote: > On Tue, 5 Mar 2024 at 10:39, Thomas Huth <thuth@redhat.com> wrote: >> >> On 04/03/2024 19.04, Daniel P. Berrangé wrote: >>> On Mon, Mar 04, 2024 at 06:11:58PM +0100, Thomas Huth wrote: >>>> On 04/03/2024 17.56, Peter Maydell wrote: >>>>> On Mon, 4 Mar 2024 at 13:04, Thomas Huth <thuth@redhat.com> wrote: >>>>>> >>>>>> The macOS jobs in our CI recently started failing, complaining that >>>>>> the distutils module is not available anymore. And indeed, according to >>>>>> https://peps.python.org/pep-0632/ it's been deprecated since a while >>>>>> and now likely got removed in recent Python versions. >>>>> >>>>> This doesn't seem to be sufficient to fix the macos CI: >>>>> something in glib seems to still be using it. >>>>> >>>>> https://gitlab.com/qemu-project/qemu/-/jobs/6313212803 >>>>> >>>>> [281/6553] Generating ui/dbus-display gdbus-codegen with a custom command >>>>> FAILED: ui/dbus-display1.h ui/dbus-display1.c >>>>> /opt/homebrew/Cellar/glib/2.78.4/bin/gdbus-codegen >>>>> ui/dbus-display1.xml --glib-min-required 2.64 --output-directory >>>>> /private/var/folders/xc/tpssff9959345bnqq4c6tlww0000gn/T/cirrus-ci-build/build/ui >>>>> --interface-prefix org.qemu. --c-namespace QemuDBus --generate-c-code >>>>> dbus-display1 >>>> ... >>>>> ModuleNotFoundError: No module named 'distutils' >>>> >>>> Looking at the glib sources, I think this has been fixed here: >>>> >>>> https://gitlab.gnome.org/GNOME/glib/-/commit/6ef967a0f930ce37a8c9b5aff96969 >>>> >>>> The fix will be in glib 2.79, unfortunately homebrew still seems to use glib >>>> 2.78 ... >>>> >>>> We could maybe temporarily work-around the problem by disabling the dbus >>>> code in the CI job? Or just wait for homebrew to update the package? >>> >>> File a bug against homebrew. IME they are very quick (1-3 days) at >>> putting out fixes for things like this, especially if you point them >>> to the upstream solution. >> >> Ok, while I was writing my mail, I was looking at https://brew.sh/ and >> didn't see a link to a bug tracker there ... but now I realized that they >> are simply using the github tracker, so I went ahead and filed a bug there: >> >> https://github.com/Homebrew/brew/issues/16823 >> >> Let's see how it goes... > > Seems to be going slowly. I notice that there's a comment in there > saying that "brew install python-setuptools" is a workaround to > get glib 2.78 working -- that seems like it would be good to get > our CI back to green. Is there a way to test changes to the cirrus > config short of committing it and seeing if it helps? I don't see > the jobs available on a pipeline in my personal gitlab repo... Yes, but you need to grant cirrus-ci some permissions you weren't ready to give last time. I just tested it and it is still failing for me: https://gitlab.com/philmd/qemu/-/jobs/6357526794
On Sat, 9 Mar 2024 at 18:29, Philippe Mathieu-Daudé <philmd@linaro.org> wrote: > > On 9/3/24 18:27, Peter Maydell wrote: > > On Tue, 5 Mar 2024 at 10:39, Thomas Huth <thuth@redhat.com> wrote: > >> Ok, while I was writing my mail, I was looking at https://brew.sh/ and > >> didn't see a link to a bug tracker there ... but now I realized that they > >> are simply using the github tracker, so I went ahead and filed a bug there: > >> > >> https://github.com/Homebrew/brew/issues/16823 > >> > >> Let's see how it goes... > > > > Seems to be going slowly. I notice that there's a comment in there > > saying that "brew install python-setuptools" is a workaround to > > get glib 2.78 working -- that seems like it would be good to get > > our CI back to green. Is there a way to test changes to the cirrus > > config short of committing it and seeing if it helps? I don't see > > the jobs available on a pipeline in my personal gitlab repo... > > Yes, but you need to grant cirrus-ci some permissions you weren't > ready to give last time. > > I just tested it and it is still failing for me: > https://gitlab.com/philmd/qemu/-/jobs/6357526794 That job doesn't seem to have tried to install python-setuptools ? It did: - brew install bash bc bison bzip2 capstone ccache cmocka ctags curl dbus diffutils dtc flex gcovr gettext git glib gnu-sed gnutls gtk+3 jemalloc jpeg-turbo json-c libepoxy libffi libgcrypt libiscsi libnfs libpng libslirp libssh libtasn1 libusb llvm lzo make meson mtools ncurses nettle ninja pixman pkg-config python3 rpm2cpio sdl2 sdl2_image snappy socat sparse spice-protocol swtpm tesseract usbredir vde vte3 xorriso zlib zstd -- PMM
04.03.2024 16:04, Thomas Huth пишет:
> The macOS jobs in our CI recently started failing, complaining that
> the distutils module is not available anymore. And indeed, according to
> https://peps.python.org/pep-0632/ it's been deprecated since a while
> and now likely got removed in recent Python versions.
>
> Fortunately, we only use it for a version check via LooseVersion here
> which we don't really need anymore - according to Repology.org, these
> are the versions of sphinx-rtd-theme that are currently used by the
> various distros:
>
> centos_stream_8: 0.3.1
> centos_stream_9: 0.5.1
> fedora_38: 1.1.1
> fedora_39: 1.2.2
> freebsd: 1.0.0
> haikuports_master: 1.2.1
> openbsd: 1.2.2
> opensuse_leap_15_5: 0.5.1
> pkgsrc_current: 2.0.0
> debian_11: 0.5.1
> debian_12: 1.2.0
> ubuntu_20_04: 0.4.3
> ubuntu_22_04: 1.0.0
> ubuntu_24_04: 2.0.0
>
> So except for CentOS 8, all distros are using a newer version of
> sphinx-rtd-theme, and for CentOS 8 we don't support compiling with
> the Sphinx of the distro anymore anyway, since it's based on the
> Python 3.6 interpreter there. For compiling on CentOS 8, you have
> to use the alternative Python 3.8 interpreter which comes without
> Sphinx, so that needs the Sphinx installed via pip in the venv
> instead, and that is using a newer version, too, according to our
> pythondeps.toml file.
>
> Thus we can simply drop the version check now to get rid of the
> distutils dependency here.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Thanks once again,
/mjt
> ---
> v2: Updated the commit description (it's about sphinx-rtd-theme,
> not the Sphinx program itself)
>
> docs/conf.py | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/docs/conf.py b/docs/conf.py
> index e84a95e71c..1b2afa241c 100644
> --- a/docs/conf.py
> +++ b/docs/conf.py
> @@ -29,7 +29,6 @@
> import os
> import sys
> import sphinx
> -from distutils.version import LooseVersion
> from sphinx.errors import ConfigError
>
> # The per-manual conf.py will set qemu_docdir for a single-manual build;
> @@ -165,11 +164,10 @@
> # Theme options are theme-specific and customize the look and feel of a theme
> # further. For a list of options available for each theme, see the
> # documentation.
> -if LooseVersion(sphinx_rtd_theme.__version__) >= LooseVersion("0.4.3"):
> - html_theme_options = {
> - "style_nav_header_background": "#802400",
> - "navigation_with_keys": True,
> - }
> +html_theme_options = {
> + "style_nav_header_background": "#802400",
> + "navigation_with_keys": True,
> +}
>
> html_logo = os.path.join(qemu_docdir, "../ui/icons/qemu_128x128.png")
>
On 04/03/2024 14.04, Thomas Huth wrote: > The macOS jobs in our CI recently started failing, complaining that > the distutils module is not available anymore. And indeed, according to > https://peps.python.org/pep-0632/ it's been deprecated since a while > and now likely got removed in recent Python versions. > > Fortunately, we only use it for a version check via LooseVersion here > which we don't really need anymore - according to Repology.org, these > are the versions of sphinx-rtd-theme that are currently used by the > various distros: > > centos_stream_8: 0.3.1 > centos_stream_9: 0.5.1 > fedora_38: 1.1.1 > fedora_39: 1.2.2 > freebsd: 1.0.0 > haikuports_master: 1.2.1 > openbsd: 1.2.2 > opensuse_leap_15_5: 0.5.1 > pkgsrc_current: 2.0.0 > debian_11: 0.5.1 > debian_12: 1.2.0 > ubuntu_20_04: 0.4.3 > ubuntu_22_04: 1.0.0 > ubuntu_24_04: 2.0.0 > > So except for CentOS 8, all distros are using a newer version of > sphinx-rtd-theme, and for CentOS 8 we don't support compiling with > the Sphinx of the distro anymore anyway, since it's based on the > Python 3.6 interpreter there. For compiling on CentOS 8, you have > to use the alternative Python 3.8 interpreter which comes without > Sphinx, so that needs the Sphinx installed via pip in the venv > instead, and that is using a newer version, too, according to our > pythondeps.toml file. FWIW, here's a CI run with CentOS 8: https://gitlab.com/thuth/qemu/-/jobs/6309310171#L65 As you can see, it uses Python 3.8 with sphinx_rtd_theme 2.0.0, so I think we should be fine here, indeed. Thomas
© 2016 - 2024 Red Hat, Inc.