CentOS 9, Python, and other Fairytales

CentOS 9, Python, and other Fairytales

[John Snow]

FYI,

bash-5.1# cat /etc/centos-release
CentOS Stream release 9
bash-5.1# python3 --version
Python 3.9.25
bash-5.1# dnf install python3.12-setuptools python3.12-wheel python3.12-pip
Last metadata expiration check: 0:02:24 ago on Tue Feb 17 22:39:26 2026.
Dependencies resolved.
==================================================================================================================================================
 Package                                    Architecture
 Version                              Repository
Size
==================================================================================================================================================
Installing:
 python3.12-pip                             noarch
 23.2.1-5.el9                         appstream
3.2 M
 python3.12-setuptools                      noarch
 68.2.2-5.el9                         appstream
1.6 M
 python3.12-wheel                           noarch
 0.41.2-3.el9                         appstream
166 k
Installing dependencies:
 libnsl2                                    x86_64
 2.0.0-1.el9                          appstream
31 k
 libtirpc                                   x86_64
 1.3.3-9.el9                          baseos
94 k
 mpdecimal                                  x86_64
 2.5.1-3.el9                          appstream
86 k
 python3.12                                 x86_64
 3.12.12-3.el9                        appstream
25 k
 python3.12-libs                            x86_64
 3.12.12-3.el9                        appstream
9.7 M
 python3.12-pip-wheel                       noarch
 23.2.1-5.el9                         appstream
1.5 M

Transaction Summary
==================================================================================================================================================
Install  9 Packages

Total download size: 16 M
Installed size: 66 M
Is this ok [y/N]:

...

So we actually probably have decent movement we can make as soon as
Ubuntu 22.04 is dropped; enough to do:

Python 3.9 -> 3.11
pip 21.3.1 -> 23.0.1
setuptools 53.0.0 -> 63.1.0
wheel 0.36.2 -> 0.38.4

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.

That's enough to delete a large amount of the horrid crap in
docs/sphinx/compat.py, though not all of it - version 6.2.0 is the
version that would allow me to delete the *entire* thing.

When Debian 12 is dropped (June), we're waiting on just FreeBSD to
modernize their stack and we could make that final leap, too.

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

Updated version dashboard:
https://gitlab.com/jsnow/repology-dashboard#results-overview-as-of-2026-02-16

--js

Re: CentOS 9, Python, and other Fairytales

[Markus Armbruster]

John Snow <jsnow@redhat.com> writes:

> FYI,
>
> bash-5.1# cat /etc/centos-release
> CentOS Stream release 9
> bash-5.1# python3 --version
> Python 3.9.25
> bash-5.1# dnf install python3.12-setuptools python3.12-wheel python3.12-pip
> Last metadata expiration check: 0:02:24 ago on Tue Feb 17 22:39:26 2026.
> Dependencies resolved.

[...]

> Transaction Summary
> ==================================================================================================================================================
> Install  9 Packages
>
> Total download size: 16 M
> Installed size: 66 M
> Is this ok [y/N]:
>
> ...
>
> So we actually probably have decent movement we can make as soon as
> Ubuntu 22.04 is dropped; enough to do:
>
> Python 3.9 -> 3.11
> pip 21.3.1 -> 23.0.1
> setuptools 53.0.0 -> 63.1.0
> wheel 0.36.2 -> 0.38.4

Accomodating a wide range of Python versions (language proper and
tooling) is costly.  Few projects go as far back as we do.  Narrowing
our range is good.

> 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.

Same for FreeBSD, to be frank.

> That's enough to delete a large amount of the horrid crap in
> docs/sphinx/compat.py, though not all of it - version 6.2.0 is the
> version that would allow me to delete the *entire* thing.

That thing is an achievement in more than one way.  It makes something
work well that has no right to work at all.  It reaches vertiginous
heights of ugliness.  It was disgustingly expensive to write, and it
will be disgustingly expensive to fix if it ever breaks, more so if the
fixer isn't John Snow.  The sooner we get rid of it, the better.

> When Debian 12 is dropped (June), we're waiting on just FreeBSD to
> modernize their stack and we could make that final leap, too.
>
> 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

Makes sense to me.

> Updated version dashboard:
> https://gitlab.com/jsnow/repology-dashboard#results-overview-as-of-2026-02-16
>
> --js

Re: CentOS 9, Python, and other Fairytales

[Paolo Bonzini]

>> 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.

Paolo

Re: CentOS 9, Python, and other Fairytales

[John Snow]

[-- Attachment #1: Type: text/plain, Size: 3632 bytes --]

On Wed, Feb 18, 2026, 6:48 AM Paolo Bonzini <pbonzini@redhat.com> 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. 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
>
>

[-- Attachment #2: Type: text/html, Size: 4903 bytes --]

Re: CentOS 9, Python, and other Fairytales

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 3907 bytes --]

Il mer 18 feb 2026, 18:10 John Snow <jsnow@redhat.com> ha scritto:

>
>
> On Wed, Feb 18, 2026, 6:48 AM Paolo Bonzini <pbonzini@redhat.com> 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
>>
>>

[-- Attachment #2: Type: text/html, Size: 5821 bytes --]

Re: CentOS 9, Python, and other Fairytales

[John Snow]

On Wed, Feb 18, 2026 at 3:26 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
>
> Il mer 18 feb 2026, 18:10 John Snow <jsnow@redhat.com> ha scritto:
>>
>>
>>
>> On Wed, Feb 18, 2026, 6:48 AM Paolo Bonzini <pbonzini@redhat.com> 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.)

>
> 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
>>>

Re: CentOS 9, Python, and other Fairytales

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 5263 bytes --]

On Wed, Feb 18, 2026 at 1:42 PM John Snow <jsnow@redhat.com> wrote:

> On Wed, Feb 18, 2026 at 3:26 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> >
> >
> > Il mer 18 feb 2026, 18:10 John Snow <jsnow@redhat.com> ha scritto:
> >>
> >>
> >>
> >> On Wed, Feb 18, 2026, 6:48 AM Paolo Bonzini <pbonzini@redhat.com>
> 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
> >>>
>
>
>

[-- Attachment #2: Type: text/html, Size: 7324 bytes --]

Re: CentOS 9, Python, and other Fairytales

[Markus Armbruster]

Warner Losh <imp@bsdimp.com> writes:

> 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'.

Thanks, Warner!

Re: CentOS 9, Python, and other Fairytales

[Markus Armbruster]

John Snow <jsnow@redhat.com> writes:

> On Wed, Feb 18, 2026 at 3:26 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il mer 18 feb 2026, 18:10 John Snow <jsnow@redhat.com> ha scritto:
>>> On Wed, Feb 18, 2026, 6:48 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>> Markus Armbruster <armbru@redhat.com> writes:
>>>>
>>>> > John Snow <jsnow@redhat.com> writes:

[...]

>>>> >> 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.)

You do.  Please consider going to 7.x really, really seriously.

>>
>> 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
>>>>