Il mer 18 feb 2026, 18:10 John Snow <[email protected]> ha scritto: > > > On Wed, Feb 18, 2026, 6:48 AM Paolo Bonzini <[email protected]> wrote: > >> >> With most of the new sticking points being debian 12 (EOL in June) or >> >> FreeBSD (timeline uncertain for when they'll re-modernize their python >> >> stack) >> >> >> >> One edge case here, however, is Sphinx, which does not actually have a >> >> modern package in centOS stream 9. >> >> >> >> CentOS currently ships 3.4.3, but it would not be usable if using the >> >> optional 3.12 upgrade. If we ignore this, both FreeBSD and Debian 12 >> >> have sphinx 5.3.0 to offer us, which is a reasonable version jump, but >> >> it means that CentOS would not be able to build docs unless you >> >> enabled `--online` for configuring QEMU or sideloaded Sphinx >> >> otherwise. >> > >> > CentOS 9 reaches end of life on May 31 next year. I do not think >> > keeping its ability to build bleeding edge docs offline out of the box >> > for its final year (give or take) is worth your time, or anybody's. >> >> That's exactly the reason why we (John and I) introduced mkvenv.py, >> except it was CentOS 8 and SLES 15 at the time >> (https://www.qemu.org/2023/03/24/python/): >> >> "Some of these tools are run through the python3 executable, while >> others are invoked directly as sphinx-build or meson, and this can >> create inconsistencies. For example, QEMU’s configure script checks for >> a minimum version of Python and rejects too-old interpreters. However, >> what would happen if code run by Sphinx used a different version? >> >> This situation has been largely hypothetical until recently; QEMU’s >> Python code is already tested with a wide range of versions of the >> interpreter, and it would not be a huge issue if Sphinx used a different >> version of Python as long as both of them were supported. This will >> change in version 8.1 of QEMU, which will bump the minimum supported >> version of Python from 3.6 to 3.8. While all the distros that QEMU >> supports have a recent-enough interpreter, the default on RHEL8 and >> SLES15 is still version 3.6, and that is what all binaries in /usr/bin >> use unconditionally." >> >> So yeah, there's precedent for doing this, and it's the right thing to >> do anyway. >> >> >> My plan: >> >> - Wait and see what happens after the current QEMU release >> >> - Gleefully drop Ubuntu 22.04 in April (Allows Python 3.11+) >> >> - Gleefully drop Debian 12 in June >> >> - Hold my breath and see if FreeBSD happens to modernize by this point >> >> (They have until October 2027 to do so, so it's a dice roll if they >> >> will or not) >> >> - Do a big round of Python modernization all at once; either to 3.11 >> >> or 3.12 depending, and either to Sphinx 5.x or 7.x depending, pray for >> >> forgiveness that I am removing CentOS stream 9's ability to build docs >> >> offline so I don't have to wait another six months and then do another >> >> big cleanup round >> >> The main nice features of 3.12 are improved f-strings, which are nice >> but not really a necessity. >> >> If I read it correctly, https://www.freshports.org/lang/python says it >> has 3.9 on PPC and 3.11 elsewhere, but >> https://www.freshports.org/lang/python311 says 3.11 exists on PPC as >> well. >> >> I'd go for 3.11 and Sphinx 7. For FreeBSD we can require Python from >> Ports. >> > > freebsd ports is currently at 3.11, which is the main reason I am saying > "see what freebsd does by June" > > if they update, we can have Python 3.12 and Sphinx 7.x. If they don't, we > get 3.11 and 5.x >
Why can't we do 3.11 and 7.x, and let freebsd also get sphinx from pypi until they update? Paolo . Both are good jumps, but on the chance I can make the bigger jump, I'd > rather do it in one round instead of two. > > >> Paolo >> >>
