Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #14719 > unrolled thread

Python 3.11 for bookworm?

Back to article view | Back to linux.debian.maint.python

Contents

  Python 3.11 for bookworm? Graham Inggs <ginggs@debian.org> - 2022-12-13 01:00 +0100
    Re: Python 3.11 for bookworm? Andrius Merkys <merkys@debian.org> - 2022-12-13 08:20 +0100
      Re: Python 3.11 for bookworm? Graham Inggs <ginggs@debian.org> - 2022-12-13 19:50 +0100
    Re: Python 3.11 for bookworm? Timo Röhling <roehling@debian.org> - 2022-12-13 10:20 +0100
      Re: Python 3.11 for bookworm? c.buhtz@posteo.jp - 2022-12-13 11:00 +0100
        Re: Python 3.11 for bookworm? Dmitry Shachnev <mitya57@debian.org> - 2022-12-13 11:10 +0100
        Re: Python 3.11 for bookworm? Thomas Goirand <zigo@debian.org> - 2022-12-15 16:10 +0100
          Re: Python 3.11 for bookworm? Dmitry Shachnev <mitya57@debian.org> - 2022-12-15 17:20 +0100
    Re: Python 3.11 for bookworm? Julian Gilbey <julian@d-and-j.net> - 2022-12-13 13:40 +0100
      Re: Python 3.11 for bookworm? Thomas Goirand <zigo@debian.org> - 2022-12-15 16:20 +0100
        Re: Python 3.11 for bookworm? Julian Gilbey <julian@d-and-j.net> - 2022-12-18 19:10 +0100
          Re: Python 3.11 for bookworm? Julian Gilbey <julian@d-and-j.net> - 2022-12-19 10:50 +0100
            Re: Python 3.11 for bookworm? Jochen Sprickerhof <jspricke@debian.org> - 2022-12-19 17:00 +0100
              Re: Python 3.11 for bookworm? Julian Gilbey <julian@d-and-j.net> - 2022-12-19 21:30 +0100
    Re: Python 3.11 for bookworm? Louis-Philippe Véronneau <pollo@debian.org> - 2022-12-13 17:10 +0100
    Re: Python 3.11 for bookworm? Thomas Goirand <zigo@debian.org> - 2022-12-15 16:20 +0100
      Re: Python 3.11 for bookworm? Thomas Goirand <zigo@debian.org> - 2022-12-16 10:50 +0100

#14719 — Python 3.11 for bookworm?

Dear Python Team

Looking at the current state of the 'adding Python 3.11 as a supported
version' transition [1], the tracker [2] shows only 12 red packages
(excluding unknowns and packages not in testing) remaining, copied
below for reference.

We believe all FTBFS and autopkgtest regression bugs have already been
filed and tagged.

The current state of bugs tagged 'python3.11' [3] is 116 resolved and
49 still open.  Many thanks to everyone who has contributed to fixing
these, and especially to the organizers of the recent Python sprint
[4].

As this transition is non-blocking (i.e. uploaded packages are able to
migrate ahead of python3-defaults), we could wait for the remaining
bugs to be fixed, or for auto-removal to take its course.  However,
with the bookworm transition freeze only one month away [5], we'd like
to hear from the Python Team within the next week whether they wish to
proceed with Python 3.11 being the only supported version for bookworm
(in which case we will allow python3-defaults to migrate right now)
or, revert the changes in python3-defaults and have Python 3.10 as the
only supported version for bookworm.

Should it be the former, we'd like an undertaking from the Python Team
that they will help resolve the remaining bugs against key packages
[6], as these cannot easily be avoided by manual or auto-removals.

On behalf of the Release Team
Graham


[1] https://bugs.debian.org/1021984
[2] https://release.debian.org/transitions/html/python3.11-add.html
[3] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.11&users=debian-python@lists.debian.org
[4] https://veronneau.org/debian-python-team-2022-sprint-report.html
[5] https://release.debian.org/bookworm/freeze_policy.html
[6] https://udd.debian.org/bugs/?release=bookworm&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=python3.11&fusertaguser=debian-python%40lists.debian.org&rc=1&ckeypackage=1&sortby=id&sorto=asc&format=html#results



Dependency level 2
omniorb-dfsg
python-pgmagick
pythonmagick
xdmf

Dependency level 7
boost1.74
guiqwt
python-line-profiler
python-xmlsec

Dependency level 8
cypari2
renpy

Dependency level 10
pybdsf

Dependency level 13
sunpy

[toc] | [next] | [standalone]

#14720

Hello,

On 2022-12-13 01:51, Graham Inggs wrote:
> As this transition is non-blocking (i.e. uploaded packages are able to
> migrate ahead of python3-defaults), we could wait for the remaining
> bugs to be fixed, or for auto-removal to take its course.  However,
> with the bookworm transition freeze only one month away [5], we'd like
> to hear from the Python Team within the next week whether they wish to
> proceed with Python 3.11 being the only supported version for bookworm
> (in which case we will allow python3-defaults to migrate right now)
> or, revert the changes in python3-defaults and have Python 3.10 as the
> only supported version for bookworm.

Am I right that whichever the choice, there will be only one supported 
Python version in bookworm? I believe there are many packages that will 
FTBFS with Python 3.11 as default (i.e., packages that use only the 
default Python). Was there an attempt to rebuild the archive with that 
setting?

> [1] https://bugs.debian.org/1021984
> [2] https://release.debian.org/transitions/html/python3.11-add.html
> [3] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.11&users=debian-python@lists.debian.org
> [4] https://veronneau.org/debian-python-team-2022-sprint-report.html
> [5] https://release.debian.org/bookworm/freeze_policy.html
> [6] https://udd.debian.org/bugs/?release=bookworm&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=python3.11&fusertaguser=debian-python%40lists.debian.org&rc=1&ckeypackage=1&sortby=id&sorto=asc&format=html#results

Best,
Andrius

[toc] | [prev] | [next] | [standalone]

#14726

Hi Andrius

On Tue, 13 Dec 2022 at 07:13, Andrius Merkys <merkys@debian.org> wrote:
> Am I right that whichever the choice, there will be only one supported
> Python version in bookworm?

Yes, I believe that was the decision made at DebConf 22.

> I believe there are many packages that will
> FTBFS with Python 3.11 as default (i.e., packages that use only the
> default Python). Was there an attempt to rebuild the archive with that
> setting?

A typical test rebuild will only catch FTBFS in dependency level one
(and maybe level two) of the transition tracker.  In the higher
levels, you'll get false positives due to failed imports of the
modules that need rebuilding.  Similarly, uploading python3-defaults
to experimental and checking for autopkgtest failures will also result
in false positives.

For reference, the python3.11-add tracker lists 594 packages
(excluding unknowns), and the python3.11-default tracker lists 351.
With the ben files currently used in the trackers, packages still red
on the first tracker also appear on the second.

For what it's worth, an incremental test rebuild of the first three
dependency levels was done in an Ubuntu PPA [3].  Roughly 80% of the
packages involved in the python3.11-default transition were tested,
and roughly 80% of the builds were successful.  All build failures are
counted here, including dependency-wait and architectures that have
never had a successful build.  A similar test rebuild was done in
January 2022 for Python 3.10 [4] and I think the numbers indicate we
are in a very similar state.

Regards
Graham


[1] https://release.debian.org/transitions/html/python3.11-add.html
[2] https://release.debian.org/transitions/html/python3.11-default.html
[3] https://launchpad.net/~pythoneers/+archive/ubuntu/python3.11-default
[4] https://launchpad.net/~pythoneers/+archive/ubuntu/python3.10-default

[toc] | [prev] | [next] | [standalone]

#14721

[Multipart message — attachments visible in raw view] — view raw

* Graham Inggs <ginggs@debian.org> [2022-12-12 23:51]:
>with the bookworm transition freeze only one month away [5], we'd like
>to hear from the Python Team within the next week whether they wish to
>proceed with Python 3.11 being the only supported version for bookworm
>[...]
>Should it be the former, we'd like an undertaking from the Python Team
>that they will help resolve the remaining bugs against key packages

One remaining problem is the unmaintained nose package, which is not
compatible with Python 3.11 and still a dependency of 200+ packages,
including ~40 key packages [1]. I've seen that crusoe has done some work
patching up nose, but AFAICT it is not building yet.

Is this something we can resolve in time, either by fixing nose or
removing it altogether?

If yes, +1 for Python 3.11


Cheers
Timo


[1] https://udd.debian.org/bugs/?release=bookworm&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=nose-rm&fusertaguser=python-modules-team%40lists.alioth.debian.org&allbugs=1&ckeypackage=1&sortby=id&sorto=asc&format=html#results

-- 
⢀⣴⠾⠻⢶⣦⠀   ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling                                       │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

[toc] | [prev] | [next] | [standalone]

#14722

Am 13.12.2022 10:15 schrieb Timo Röhling:
> One remaining problem is the unmaintained nose package
> [...]
> done some work patching up nose

This question is just for my learning: Why is nose patched? Upstream 
nose is unmaintained for years.

I understand that you cannot drop nose from Debian in the current 
situation of a freeze in one months and so many dependencies.

But isn't there a Debian process/workflow to "warn" package maintainers 
about an upcoming package drop of one of there dependend packages to put 
some pressure into it? Looking into the list of over 200 packages I see 
this also as a chance to clean out some other unmaintained (and maybe 
not so important) packages from the Debian repo.

[toc] | [prev] | [next] | [standalone]

#14723

[Multipart message — attachments visible in raw view] — view raw

Hi all,

On Tue, Dec 13, 2022 at 10:15:37AM +0100, Timo Röhling wrote:
> One remaining problem is the unmaintained nose package, which is not
> compatible with Python 3.11 and still a dependency of 200+ packages,
> including ~40 key packages [1]. I've seen that crusoe has done some work
> patching up nose, but AFAICT it is not building yet.
>
> Is this something we can resolve in time, either by fixing nose or
> removing it altogether?

I will try to fix nose. The remaining problem is just failing doctest.

On Tue, Dec 13, 2022 at 09:57:57AM +0000, c.buhtz@posteo.jp wrote:
> This question is just for my learning: Why is nose patched? Upstream nose is
> unmaintained for years.
>
> I understand that you cannot drop nose from Debian in the current situation
> of a freeze in one months and so many dependencies.
>
> But isn't there a Debian process/workflow to "warn" package maintainers
> about an upcoming package drop of one of there dependend packages to put
> some pressure into it? Looking into the list of over 200 packages I see this
> also as a chance to clean out some other unmaintained (and maybe not so
> important) packages from the Debian repo.

There are bugs filed against every package:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-modules-team@lists.alioth.debian.org;tag=nose-rm

--
Dmitry Shachnev

[toc] | [prev] | [next] | [standalone]

#14728

On 12/13/22 10:57, c.buhtz@posteo.jp wrote:
> Am 13.12.2022 10:15 schrieb Timo Röhling:
>> One remaining problem is the unmaintained nose package
>> [...]
>> done some work patching up nose
> 
> This question is just for my learning: Why is nose patched? Upstream 
> nose is unmaintained for years.
> 
> I understand that you cannot drop nose from Debian in the current 
> situation of a freeze in one months and so many dependencies.
> 
> But isn't there a Debian process/workflow to "warn" package maintainers 
> about an upcoming package drop of one of there dependend packages to put 
> some pressure into it? Looking into the list of over 200 packages I see 
> this also as a chance to clean out some other unmaintained (and maybe 
> not so important) packages from the Debian repo.

It's unfortunately sometimes a bit harder than what one may think. 
Removing Nose from (build-)depends in some cases is hard, and IMO we 
started this process a way too late. Hopefully, Trixie will be 
nose-free! In the mean time, it is unfortunately my opinion that it's 
too late for Bookworm and that we must keep Nose for one more release.

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#14731

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 15, 2022 at 04:08:29PM +0100, Thomas Goirand wrote:
> It's unfortunately sometimes a bit harder than what one may think. Removing
> Nose from (build-)depends in some cases is hard, and IMO we started this
> process a way too late. Hopefully, Trixie will be nose-free! In the mean
> time, it is unfortunately my opinion that it's too late for Bookworm and
> that we must keep Nose for one more release.

I forgot to reply here, but I uploaded fixed nose on Tuesday:

https://tracker.debian.org/news/1398350/accepted-nose-137-9-source-into-unstable/

--
Dmitry Shachnev

[toc] | [prev] | [next] | [standalone]

#14724

Hi Graham,

On Mon, Dec 12, 2022 at 11:51:11PM +0000, Graham Inggs wrote:
> Dear Python Team
> 
> Looking at the current state of the 'adding Python 3.11 as a supported
> version' transition [1], the tracker [2] shows only 12 red packages
> (excluding unknowns and packages not in testing) remaining, copied
> below for reference.
> [...]

If Python 3.11 is the default, then it is highly likely that Spyder
will not be included: debugpy, which is a dependency of Spyder and
python3-ipykernel (and lots of things that depend on that) seems to
require major work upstream to make it fully compatible with Python
3.11.  This is work in progress, but I don't know whether it will be
ready in time for the freeze.  At the moment, I have worked around
this problem by just skipping the failing tests, but that is far from
an ideal solution.

Best wishes,

   Julian

[toc] | [prev] | [next] | [standalone]

#14729

On 12/13/22 13:34, Julian Gilbey wrote:
> Hi Graham,
> 
> On Mon, Dec 12, 2022 at 11:51:11PM +0000, Graham Inggs wrote:
>> Dear Python Team
>>
>> Looking at the current state of the 'adding Python 3.11 as a supported
>> version' transition [1], the tracker [2] shows only 12 red packages
>> (excluding unknowns and packages not in testing) remaining, copied
>> below for reference.
>> [...]
> 
> If Python 3.11 is the default, then it is highly likely that Spyder
> will not be included: debugpy, which is a dependency of Spyder and
> python3-ipykernel (and lots of things that depend on that) seems to
> require major work upstream to make it fully compatible with Python
> 3.11.  This is work in progress, but I don't know whether it will be
> ready in time for the freeze.  At the moment, I have worked around
> this problem by just skipping the failing tests, but that is far from
> an ideal solution.
> 
> Best wishes,
> 
>     Julian

Hi Julian,

It's probably ok if it's a *TEMPORARY* solution until upstream fixes 
everything in time for the release (which is months after the freeze). 
The question is: do you believe this may happen for let's say next March?

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#14744

On Thu, Dec 15, 2022 at 04:10:05PM +0100, Thomas Goirand wrote:
> On 12/13/22 13:34, Julian Gilbey wrote:
> > If Python 3.11 is the default, then it is highly likely that Spyder
> > will not be included: debugpy, which is a dependency of Spyder and
> > python3-ipykernel (and lots of things that depend on that) seems to
> > require major work upstream to make it fully compatible with Python
> > 3.11.  This is work in progress, but I don't know whether it will be
> > ready in time for the freeze.  At the moment, I have worked around
> > this problem by just skipping the failing tests, but that is far from
> > an ideal solution.
> 
> It's probably ok if it's a *TEMPORARY* solution until upstream fixes
> everything in time for the release (which is months after the freeze). The
> question is: do you believe this may happen for let's say next March?

The truth is that I don't know.  Upstream is very good, but the Python
3.11 internal changes are very significant, and debugpy (along with
pydevd, which is part of debugpy) are deeply affected by this, as they
work at the level of Python's internals.  So I don't know how long it
will take them to make the required changes (and it's far beyond my
capability or capacity to do myself).  I can hope they'll do it in
time for the freeze, but I wouldn't like to place a bet on it.

Best wishes,

   Julian

[toc] | [prev] | [next] | [standalone]

#14751

On Sun, Dec 18, 2022 at 06:02:58PM +0000, Julian Gilbey wrote:
> On Thu, Dec 15, 2022 at 04:10:05PM +0100, Thomas Goirand wrote:
> > On 12/13/22 13:34, Julian Gilbey wrote:
> > > If Python 3.11 is the default, then it is highly likely that Spyder
> > > will not be included: debugpy, which is a dependency of Spyder and
> > > python3-ipykernel (and lots of things that depend on that) seems to
> > > require major work upstream to make it fully compatible with Python
> > > 3.11.  This is work in progress, but I don't know whether it will be
> > > ready in time for the freeze.  At the moment, I have worked around
> > > this problem by just skipping the failing tests, but that is far from
> > > an ideal solution.
> > 
> > It's probably ok if it's a *TEMPORARY* solution until upstream fixes
> > everything in time for the release (which is months after the freeze). The
> > question is: do you believe this may happen for let's say next March?
> 
> The truth is that I don't know.  Upstream is very good, but the Python
> 3.11 internal changes are very significant, and debugpy (along with
> pydevd, which is part of debugpy) are deeply affected by this, as they
> work at the level of Python's internals.  So I don't know how long it
> will take them to make the required changes (and it's far beyond my
> capability or capacity to do myself).  I can hope they'll do it in
> time for the freeze, but I wouldn't like to place a bet on it.

Quick update: with the updating of python3-bytecode from 0.13 to 0.14
in unstable/testing, which allows it to handle Python 3.11, something
has changed and now pydevd doesn't even pass the tests on Python
3.10.  The python3-bytecode underwent a major restructuring, so it is
entirely possible that something has changed that wasn't part of the
advertised API or something like that.  But that's for upstream pydevd
developers to deal with.

One possibility is that we revert to the situation in bullseye if
pydevd is not ready in time for the freeze.  Bullseye didn't have
bytecode/pydevd/debugpy, and it meant that debugging was limited in
Spyder: we remove python3-debugpy from the dependencies of
python3-ipykernel and then the rest of the dependency chain will be
OK.  It's certainly not an ideal solution, but it may be the best we
can do if we're sticking with Python 3.11.  It may actually be worth
doing that at this point so that Spyder can stay in testing for the
time being, even though pydevd and debugpy won't.

Best wishes,

   Julian

[toc] | [prev] | [next] | [standalone]

#14754

[Multipart message — attachments visible in raw view] — view raw

Hi Julian,

* Julian Gilbey <julian@d-and-j.net> [2022-12-19 09:41]:
>Quick update: with the updating of python3-bytecode from 0.13 to 0.14
>in unstable/testing, which allows it to handle Python 3.11, something
>has changed and now pydevd doesn't even pass the tests on Python
>3.10.  The python3-bytecode underwent a major restructuring, so it is
>entirely possible that something has changed that wasn't part of the
>advertised API or something like that.  But that's for upstream pydevd
>developers to deal with.

I've uploaded 0.14.0-2 that should fix this. As far as I've found that 
was only a minor fix in the Debian specific offset patch, sorry for the 
trouble.

Cheers Jochen

[toc] | [prev] | [next] | [standalone]

#14755

Hi Jochen,

On Mon, Dec 19, 2022 at 04:53:58PM +0100, Jochen Sprickerhof wrote:
> Hi Julian,
> 
> * Julian Gilbey <julian@d-and-j.net> [2022-12-19 09:41]:
> > Quick update: with the updating of python3-bytecode from 0.13 to 0.14
> > in unstable/testing, which allows it to handle Python 3.11, something
> > has changed and now pydevd doesn't even pass the tests on Python
> > 3.10.  The python3-bytecode underwent a major restructuring, so it is
> > entirely possible that something has changed that wasn't part of the
> > advertised API or something like that.  But that's for upstream pydevd
> > developers to deal with.
> 
> I've uploaded 0.14.0-2 that should fix this. As far as I've found that was
> only a minor fix in the Debian specific offset patch, sorry for the trouble.

Phew!  I didn't think to check that.  Unfortunately, though, there are
still numerous pydevd test errors even with 0.14.0-2, so I think
something has changed in bytecode that the pydevd maintainers will
have to adapt to.  So either I skip 14 newly failing tests on Python
3.10 (they're mostly skipped on 3.11 as the current pydevd version
skips bytecode tests on Python 3.11) or wait for a new version of
pydevd.  Hmmm.

Anyway, thanks so much for all your work updating this package - it's
been really helpful, as I've been a bit overloaded and Spyder 5.4.0
together with the Python 3.11 transition has been a lot to handle.  I
also learnt a lot from your changes!

Best wishes,

   Julian

[toc] | [prev] | [next] | [standalone]

#14725

[Multipart message — attachments visible in raw view] — view raw

On 2022-12-12 18 h 51, Graham Inggs wrote:
> Dear Python Team
> 
> Looking at the current state of the 'adding Python 3.11 as a supported
> version' transition [1], the tracker [2] shows only 12 red packages
> (excluding unknowns and packages not in testing) remaining, copied
> below for reference.
> 
> We believe all FTBFS and autopkgtest regression bugs have already been
> filed and tagged.
> 
> The current state of bugs tagged 'python3.11' [3] is 116 resolved and
> 49 still open.  Many thanks to everyone who has contributed to fixing
> these, and especially to the organizers of the recent Python sprint
> [4].
> 
> As this transition is non-blocking (i.e. uploaded packages are able to
> migrate ahead of python3-defaults), we could wait for the remaining
> bugs to be fixed, or for auto-removal to take its course.  However,
> with the bookworm transition freeze only one month away [5], we'd like
> to hear from the Python Team within the next week whether they wish to
> proceed with Python 3.11 being the only supported version for bookworm
> (in which case we will allow python3-defaults to migrate right now)
> or, revert the changes in python3-defaults and have Python 3.10 as the
> only supported version for bookworm.
> 
> Should it be the former, we'd like an undertaking from the Python Team
> that they will help resolve the remaining bugs against key packages
> [6], as these cannot easily be avoided by manual or auto-removals.
> 
> On behalf of the Release Team
> Graham

I still feel the move to 3.11 so late in the release cycle was cavalier 
and we should have used our energies to fix issues we had in the archive 
instead of trying to fix 3.11 bugs.

I've said it already here, but it's very frustrating to work on 
packaging python libraries and apps for a whole release cycle, just to 
see all that work put in the bin at the last minute because upstream 
doesn't support 3.11.

I hate to be put in a position where I have to tell upstreams (some with 
whom I've been collaborating for years) "ahem, by the way, you have 2 
months to fix this or it won't be in the next Debian stable release".

That said, 3.11 proponents certainly walked the walk and fixed a lot of 
stuff already. Kudos to them.

I don't feel like I can take position on this. I'm certainly biased by 
one of the packages I really care about not being 3.11 compatible (and 
probably won't be before the release).

All I know is this late transition leaves a bitter taste in my mouth.

-- 
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
   ⠈⠳⣄

[toc] | [prev] | [next] | [standalone]

#14730

On 12/13/22 00:51, Graham Inggs wrote:
> Dear Python Team
> 
> Looking at the current state of the 'adding Python 3.11 as a supported
> version' transition [1], the tracker [2] shows only 12 red packages
> (excluding unknowns and packages not in testing) remaining, copied
> below for reference.
> 
> We believe all FTBFS and autopkgtest regression bugs have already been
> filed and tagged.
> 
> The current state of bugs tagged 'python3.11' [3] is 116 resolved and
> 49 still open.  Many thanks to everyone who has contributed to fixing
> these, and especially to the organizers of the recent Python sprint
> [4].
> 
> As this transition is non-blocking (i.e. uploaded packages are able to
> migrate ahead of python3-defaults), we could wait for the remaining
> bugs to be fixed, or for auto-removal to take its course.  However,
> with the bookworm transition freeze only one month away [5], we'd like
> to hear from the Python Team within the next week whether they wish to
> proceed with Python 3.11 being the only supported version for bookworm
> (in which case we will allow python3-defaults to migrate right now)
> or, revert the changes in python3-defaults and have Python 3.10 as the
> only supported version for bookworm.
> 
> Should it be the former, we'd like an undertaking from the Python Team
> that they will help resolve the remaining bugs against key packages
> [6], as these cannot easily be avoided by manual or auto-removals.
> 
> On behalf of the Release Team
> Graham


Hi Graham,

For OpenStack, I believe I was able to fix all Python 3.11 bugs (often 
with the help of upstream, a few times, on my own but very trivial fixes 
like the easy getargspec -> getfullargspec). The remaining filled RC 
bugs because of Python 3.11, I don't really mind (even if these 5 
packages are AUTORM, I'm fine with that, they aren't key packages from 
the OpenStack perspective).

However, there's still one very annoying bug in flask-restful that makes 
it not rebuild under Python 3.11. Keystone needs flask-restful, so I 
*must* fix it.

Note here that #1024913 is because of another issue (ie: the autopkgtest 
functional test doesn't support more than one available Python 
interpreter, though it's easy to fix: simply kill the server between 
runs...). Though it hides the real FTBFS issue (failure in unit tests), 
which I believe is probably due to my upgrade of werkzeug 2.2.2 rather 
than Python 3.11.

Help would be greatly appreciated fixing this bug. Hopefully, I can get 
this done during my holidays (and avoid any other work...).

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#14733

On 12/15/22 16:18, Thomas Goirand wrote:
> On 12/13/22 00:51, Graham Inggs wrote:
>> Dear Python Team
>>
>> Looking at the current state of the 'adding Python 3.11 as a supported
>> version' transition [1], the tracker [2] shows only 12 red packages
>> (excluding unknowns and packages not in testing) remaining, copied
>> below for reference.
>>
>> We believe all FTBFS and autopkgtest regression bugs have already been
>> filed and tagged.
>>
>> The current state of bugs tagged 'python3.11' [3] is 116 resolved and
>> 49 still open.  Many thanks to everyone who has contributed to fixing
>> these, and especially to the organizers of the recent Python sprint
>> [4].
>>
>> As this transition is non-blocking (i.e. uploaded packages are able to
>> migrate ahead of python3-defaults), we could wait for the remaining
>> bugs to be fixed, or for auto-removal to take its course.  However,
>> with the bookworm transition freeze only one month away [5], we'd like
>> to hear from the Python Team within the next week whether they wish to
>> proceed with Python 3.11 being the only supported version for bookworm
>> (in which case we will allow python3-defaults to migrate right now)
>> or, revert the changes in python3-defaults and have Python 3.10 as the
>> only supported version for bookworm.
>>
>> Should it be the former, we'd like an undertaking from the Python Team
>> that they will help resolve the remaining bugs against key packages
>> [6], as these cannot easily be avoided by manual or auto-removals.
>>
>> On behalf of the Release Team
>> Graham
> 
> 
> Hi Graham,
> 
> For OpenStack, I believe I was able to fix all Python 3.11 bugs (often 
> with the help of upstream, a few times, on my own but very trivial fixes 
> like the easy getargspec -> getfullargspec). The remaining filled RC 
> bugs because of Python 3.11, I don't really mind (even if these 5 
> packages are AUTORM, I'm fine with that, they aren't key packages from 
> the OpenStack perspective).
> 
> However, there's still one very annoying bug in flask-restful that makes 
> it not rebuild under Python 3.11. Keystone needs flask-restful, so I 
> *must* fix it.
> 
> Note here that #1024913 is because of another issue (ie: the autopkgtest 
> functional test doesn't support more than one available Python 
> interpreter, though it's easy to fix: simply kill the server between 
> runs...). Though it hides the real FTBFS issue (failure in unit tests), 
> which I believe is probably due to my upgrade of werkzeug 2.2.2 rather 
> than Python 3.11.
> 
> Help would be greatly appreciated fixing this bug. Hopefully, I can get 
> this done during my holidays (and avoid any other work...).
> 
> Cheers,
> 
> Thomas Goirand (zigo)

FYI, I have just uploaded a new Debian release of this package that 
fixes all the issues, thanks to a colleague of mine that had time to 
help (which I didn't really have...).

So, I believe I'm all good regarding OpenStack packages right now (even 
if that last one was werkzeug 2.2.2 related, not python 3.11).

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web