On Wed, Feb 18, 2026 at 1:42 PM John Snow <[email protected]> wrote:
> On Wed, Feb 18, 2026 at 3:26 PM Paolo Bonzini <[email protected]> wrote: > > > > > > > > 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? > > Hm, I guess no reason, beyond my recalcitrance on breaking docs on a > supported build platform unless absolutely necessary. It'd still be my > preference to align with the native distro repo/ports versions if at > all possible, but I suppose if FreeBSD doesn't fix itself by June or > so that we can consider dropping docs support with ports packages at > that time. > > (I think I just have Stockholm Syndrome from arguing for "unnecessary > version bumps to get shiny new toys" and prefer to let those arguments > come from my seniors ... so I stick with very safe changes when at all > possible.) > When I asked a week or two ago, the FreeBSD python maintainers were busy upgrading, but there was too much fallout still going from 3.11 to 3.12, but they'd hope to work through it soon... I didn't press them for a more refined version of 'soon'. Warner > > > > 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 > >>> > > >
