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.
[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
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
[...]
done some work patching up nose
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?
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.
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.
[...]
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?
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.
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
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
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.
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)
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?
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.
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.
While I can agree that it may be harsh, and that some packages wont be fixed in time, I can't let you say that there was only 1 month given, and that all of this comes as a surprise. We've been talking about this since last
summer.
Well, that's not the first time we are trying to push the latest interpreter close to a release.
I also very much would appreciate help on these (which all look like
probably related to py3.11):
#1026524 ironic-inspector: FTBFS: AttributeError: '_thread.RLock' object has no attribute 'is_locked'
#1026547 python-pypowervm: FTBFS: AssertionError: Expected 'warn' to be called once. Called 2 times.
#1026549 python-pytest-xprocess: FTBFS: tests failed
#1026591 cinder: FTBFS: make[1]: pyversions: No such file or directory #1026595 python-murano-pkg-check: FTBFS: TypeError: load_all() missing 1 required positional argument: 'Loader'
#1026610 horizon: FTBFS: tests failed
#1026691 bandit: FTBFS: TypeError: load() missing 1 required positional argument: 'Loader'
#1026693 cloudkitty: FTBFS: touch: cannot touch '/<<PKGBUILDDIR>>/debian/cloudkitty-doc/usr/share/doc/cloudkitty-doc/html/_static/toggle.js':
No such file or directory
#1026702 python-cursive: FTBFS: AttributeError: '_RSAPrivateKey' object has no attribute 'signer'
#1026705 python-pecan: FTBFS: E AttributeError: 'code' object has no attribute 'co_endlinetable'
#1026707 jenkins-job-builder: FTBFS: E: pybuild pybuild:386: test: plugin custom failed with: exit code=1: PYTHON=python3.10 stestr run
To sum-up: while I'm not 100% on the side of breaking things that close to a release, and would also feel it very painful if one of the above bugs isn't fixed in time, I don't feel like you guys are giving good point of argumentation, or a solution to improve the process. Doko already explained that switching the interpreter (the hard way) is the only viable way to find out the remaining bugs. Do you have a better solution in mind?
True, I remember the DebConf Python BoF. My memory tells me that the
plan was to keep 3.10 as default. Thus Python 3.11 would be really a surprise. From a maintainers team with lots of Python packages that
will need heavy work I can't say I'd be happy about a "migrate and see
what might happen afterwards" strategy as it was proposed here. We have
lots to do even without such an experiment.
Well, that's not the first time we are trying to push the latest interpreter >> close to a release.
The fact that we did so before does not make the idea better.
I also very much would appreciate help on these (which all look like
probably related to py3.11):
#1026524 ironic-inspector: FTBFS: AttributeError: '_thread.RLock' object has >> no attribute 'is_locked'
#1026547 python-pypowervm: FTBFS: AssertionError: Expected 'warn' to be
called once. Called 2 times.
#1026549 python-pytest-xprocess: FTBFS: tests failed
#1026591 cinder: FTBFS: make[1]: pyversions: No such file or directory
#1026595 python-murano-pkg-check: FTBFS: TypeError: load_all() missing 1
required positional argument: 'Loader'
#1026610 horizon: FTBFS: tests failed
#1026691 bandit: FTBFS: TypeError: load() missing 1 required positional
argument: 'Loader'
#1026693 cloudkitty: FTBFS: touch: cannot touch '/<<PKGBUILDDIR>>/debian/cloudkitty-doc/usr/share/doc/cloudkitty-doc/html/_static/toggle.js':
No such file or directory
#1026702 python-cursive: FTBFS: AttributeError: '_RSAPrivateKey' object has >> no attribute 'signer'
#1026705 python-pecan: FTBFS: E AttributeError: 'code' object has no
attribute 'co_endlinetable'
#1026707 jenkins-job-builder: FTBFS: E: pybuild pybuild:386: test: plugin
custom failed with: exit code=1: PYTHON=python3.10 stestr run
If I would create a list mine whould be way longer.
We are constantly beaten by removal from testing warnings
even with Python3.11 as an option and sometimes we simply need to remove
that option as a temporary means for bookworm.
No better solution but better timing which means after bookworm release.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 384 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 63:07:17 |
| Calls: | 8,174 |
| Calls today: | 6 |
| Files: | 13,113 |
| Messages: | 5,864,696 |