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

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

Python 3.13 addition as a supported Python version started

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

Contents

  Python 3.13 addition as a supported Python version started Matthias Klose <doko@debian.org> - 2024-11-13 10:50 +0100
    Re: Python 3.13 addition as a supported Python version started PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2024-11-13 11:30 +0100
      Re: Python 3.13 addition as a supported Python version started Matthias Klose <doko@debian.org> - 2024-11-13 11:50 +0100
        Re: Python 3.13 addition as a supported Python version started PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2024-11-13 12:10 +0100
          Re: Python 3.13 addition as a supported Python version started Andrey Rakhmatullin <wrar@debian.org> - 2024-11-13 12:20 +0100
      Re: Python 3.13 addition as a supported Python version started c.buhtz@posteo.jp - 2024-11-13 11:50 +0100
        Re: Python 3.13 addition as a supported Python version started buhtz@posteo.de - 2024-11-13 13:30 +0100
          Re: Python 3.13 addition as a supported Python version started Stefano Rivera <stefanor@debian.org> - 2024-11-13 15:50 +0100
      Re: Python 3.13 addition as a supported Python version started Stefano Rivera <stefanor@debian.org> - 2024-11-13 16:10 +0100
        Re: Python 3.13 addition as a supported Python version started Stefano Rivera <stefanor@debian.org> - 2024-11-13 16:10 +0100
    Re: Python 3.13 addition as a supported Python version started Colin Watson <cjwatson@debian.org> - 2024-12-16 03:00 +0100
      Re: Python 3.13 addition as a supported Python version started Julian Gilbey <julian@d-and-j.net> - 2024-12-17 14:00 +0100
        Re: Python 3.13 addition as a supported Python version started Colin Watson <cjwatson@debian.org> - 2024-12-20 04:30 +0100
          Re: Python 3.13 addition as a supported Python version started Julian Gilbey <julian@d-and-j.net> - 2024-12-20 10:50 +0100
      Re: Python 3.13 addition as a supported Python version started Colin Watson <cjwatson@debian.org> - 2024-12-20 04:40 +0100

#16448 — Python 3.13 addition as a supported Python version started

python3-defaults in unstable now adds Python 3.13 as a supported Python 
3.13 version.  You might see some additional build failures, until the 
binNMUs for this addition are done [1]. This might take some days for 
some architectures.  We will most likely also see some more issues once 
the lower levels of this addition are done.

Matthias

[1] https://release.debian.org/transitions/html/python3.13-add.html

[toc] | [next] | [standalone]

#16449

do we know how long we will have to fix all the FTBFS and autopkgtest before the freeze ?

I am a bit worrying for the scientific stack , will we have enough time to work with our upstream in order to fix all these FTBFS. In the scientific stack, things are going slowly....

We are not 100% of our time dedicated to Debian work... so I hope that it will not ruine the effort of the trixie cycle for scientific softwares.

moving to Python 3.12 was not that simple...

Cheers

Frédéric

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

#16450

On 13.11.24 11:04, PICCA Frederic-Emmanuel wrote:
> do we know how long we will have to fix all the FTBFS and autopkgtest before the freeze ?

no. the freeze date is not yet announced.

> I am a bit worrying for the scientific stack , will we have enough time to work with our upstream in order to fix all these FTBFS. In the scientific stack, things are going slowly....
> 
> We are not 100% of our time dedicated to Debian work... so I hope that it will not ruine the effort of the trixie cycle for scientific softwares.
> 
> moving to Python 3.12 was not that simple...

this is the same as we did for the Python 3.12 transition.  Please note 
that we don't enable any of the experimental features in Python 3.12 (no 
GIL, JIT compilation), so assuming there are currently no other RC 
issues in your packages, there should plenty of time to fix any 3.13 
related issues.

Matthias

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

#16452

> this is the same as we did for the Python 3.12 transition.  Please note
> that we don't enable any of the experimental features in Python 3.12 (no
> GIL, JIT compilation), so assuming there are currently no other RC
> issues in your packages, there should plenty of time to fix any 3.13
> related issues.


the plenty of time is not only my time or Debian time but also upstream time.

I just wanted  to express my concern because we rely at work on the scientific stack.

So we try hard to maintain our packages in testing, and it it always a deception to see them (part of) expelled from testing due to an FTBFS with a new Python or a failing autopkgtest.

amicalement,

Fred

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

#16453

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

On Wed, Nov 13, 2024 at 11:46:21AM +0100, PICCA Frederic-Emmanuel wrote:
> > this is the same as we did for the Python 3.12 transition.  Please note
> > that we don't enable any of the experimental features in Python 3.12 (no
> > GIL, JIT compilation), so assuming there are currently no other RC
> > issues in your packages, there should plenty of time to fix any 3.13
> > related issues.
> 
> 
> the plenty of time is not only my time or Debian time but also upstream time.

I agree that it's unfortunate that for many upstream the time to fix 3.13
failures starts not when betas are available and not even when the final
release happens (which was a month ago) but when somebody files a bug
report.


-- 
WBR, wRAR

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

#16451

Hello,

I am an upstream maintainer and ask just because I want to learn.

It was a similar case before the Debian 12 release introducing Python 
3.12 near to the freeze. Why are fresh Python releases introduced so 
early and near to the next Debian release?

This is not how I do experience Debian at all. This is not "rock solid". 
Python 3.13 is very fresh, no one needs it yet. I see no problem 
introducing it with Debian 14 in 2027.

For my project it does not matter directly. I do support 3.13. But this 
process does bind a lot of resources on Debian which could be used more 
productive into other problems.

Who decide which Python version is introduced in Debian? Isn't there a 
council for heavy decisions like this?

Regards,
Christian Buhtz

Am 13.11.2024 11:04 schrieb PICCA Frederic-Emmanuel:
> do we know how long we will have to fix all the FTBFS and autopkgtest
> before the freeze ?
> 
> I am a bit worrying for the scientific stack , will we have enough
> time to work with our upstream in order to fix all these FTBFS. In the
> scientific stack, things are going slowly....
> 
> We are not 100% of our time dedicated to Debian work... so I hope that
> it will not ruine the effort of the trixie cycle for scientific
> softwares.
> 
> moving to Python 3.12 was not that simple...
> 
> Cheers
> 
> Frédéric

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

#16454

Hello Jonathan,

thank you for the reply.

Am 13.11.2024 12:15 schrieb Jonathan Carter:
> This was discussed at the Python BoF at DebConf in ROK earlier this
> year.

OK, nice to know that there was a discussion before. Did I missed the 
announcement of the results of this discussion in this mailing list?

- Christian

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

#16455

Hi buhtz (2024.11.13_12:06:33_+0000)
> > This was discussed at the Python BoF at DebConf in ROK earlier this
> > year.
> 
> OK, nice to know that there was a discussion before. Did I missed the
> announcement of the results of this discussion in this mailing list?

The BoF was mentioned on the list, but I think we forgot to feed the
conclusions back. Here is the recording:
https://debconf24.debconf.org/talks/31-python-bof/

Link to the notes at the bottom (etherpad).

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

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

#16456

Hi PICCA (2024.11.13_10:04:26_+0000)
> I am a bit worrying for the scientific stack , will we have enough
> time to work with our upstream in order to fix all these FTBFS. In the
> scientific stack, things are going slowly....

The reality here is that Python has a 6-month release cycle, these days.

If upstreams can't stay on top of new Python releases, we are stuck with
doing the porting work or dropping them from Debian. We can't fix them
all in 6 months. There are still a lot of open 3.11 and 3.12 bugs, for
example.

If we don't have the latest stable version of Python in our stable
release, I think a large number of our users will be very disappointed.
It would certainly cement the view that Debian ships ancient software.
I don't think the users who would be upset would have any motivation to
help improve the situation (working on old scientific packages).

If we have to drop large numbers of scientific packages in our stable
releases, I imagine a small number of users would be disappointed, and
hopefully able to see how they can help avoid this situation in the
future. Sorry, but I see that as the less bad outcome. I'm not saying
I want it, but I think it's the approach we have to take, in the face of
unmaintained software.

The alternative would be to carry multiple Python releases in a Debian
stable release, which is something we haven't wanted to do.

We try to start the detection process as early as possible.

I have been doing archive wide rebuilds (as much as I could, on arm64)
since 3.13 rc2. I announced it, and our planned migration to 3.13 in
trixie, in:

https://lists.debian.org/msgid-search/20240920072725.mkhi575oydnr67sh@satie.tumbleweed.org.za

I'm hoping to have even better tooling for this kind of rebuild in the
future.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

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

#16457

Hi debian-python (2024.11.13_15:01:31_+0000)
> Hi PICCA (2024.11.13_10:04:26_+0000)
> > I am a bit worrying for the scientific stack , will we have enough
> > time to work with our upstream in order to fix all these FTBFS. In the
> > scientific stack, things are going slowly....
> 
> The reality here is that Python has a 6-month release cycle, these days.

I mean 12-month, of course.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

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

#16573

On Wed, Nov 13, 2024 at 10:29:06AM +0100, Matthias Klose wrote:
> python3-defaults in unstable now adds Python 3.13 as a supported Python 3.13
> version.  You might see some additional build failures, until the binNMUs
> for this addition are done [1]. This might take some days for some
> architectures.  We will most likely also see some more issues once the lower
> levels of this addition are done.
[...]
> [1] https://release.debian.org/transitions/html/python3.13-add.html

While there are a few bits of that transition tracker still red, the
current target is to work on the list of autopkgtest failures shown on
https://tracker.debian.org/pkg/python3-defaults in order to get the
addition of 3.13 as a supported version into testing.  As usual, this
page can be a little hard to interpret because it shows test failures of
the versions of those packages in testing, and you have to click through
to each corresponding package (sometimes through multiple levels of
failures) to see whether it's been fixed in unstable.  But with ~35
packages left there, it's getting easier to wade through and we're
getting pretty close.

Here's the current state, with my comments:

 * audioread: #1082047; apparently needs packaging of a couple of pieces
   removed from the standard library.  Reverse-dependencies are eartag,
   puddletag, and python3-acoustid.

 * dask/dask.distributed: #1088234 and #1088286, but also #1085947 in
   sphinx-book-theme.  I sank a bunch of time into trying to fix this
   last month and didn't really get anywhere very satisfying.  Can
   anyone with more experience with these packages figure this out?

 * datalad-next: #1088038.  Probably not too hard if you can figure out
   how that test is supposed to work.

 * deepdiff: #1088239, blocked by orderly-set in NEW.  I poked
   #debian-ftp.

 * hyperkitty: #1088312.  Should be fairly easy.

 * ipykernel: Fixed in unstable.

 * ironic-python-agent: #1089531.  Should be fairly easy; zigo said on
   IRC that this is a leaf package and doesn't need to block migration.

 * jinja2: Fixed in unstable.

 * jupyter-server: Fixed in unstable.

 * mdp: Fixed in unstable.

 * ovn-octavia-provider: #1088762.  zigo said on IRC that this is a leaf
   package and doesn't need to block migration.

 * pocketsphinx-python: #1088764.  Apparently difficult.

 * pytest-jupyter: Fixed by new ipykernel in unstable.

 * python-attrs: Fixed in unstable; blocked on python-cattrs.

 * python-beartype: #1089017.  Apparently fixed upstream, though I don't
   know exactly where.

 * python-cattrs: #1073406/#1086614.

 * python-omegaconf: #1089049.

 * python-oslo.messaging: I believe this is fixed in unstable
   (#1089050) and waiting for python-eventlet to migrate to testing.

 * python-pure-python-adb: #1082251/#1084618; apparently just needs a
   dependency on python3-zombie-telnetlib?

 * python-voip-utils: #1088827 fixed in unstable, but has an autopkgtest
   regression on s390x (#1089826).

 * rich: #1082290; seems to be fixed upstream.

 * smart-open: #1089053; upstream fix in progress.

 * spyder: #1088068/#1089054.

 * twisted: Fixed in unstable, just waiting for matrix-synapse to
   migrate first (which should be soon).

There are also a number of architecture-specific failures showing up
there.  Some might go away with a few more retries I guess, but we'll
likely need to work out what to do about the rest.  I haven't looked at
these in any depth.

Can anyone help with any of the remaining problems here?  This would be
especially useful for packages that aren't maintained by the Python
team.

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]

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

#16577

On Mon, Dec 16, 2024 at 01:58:14AM +0000, Colin Watson wrote:
> [...]
>  * spyder: #1088068/#1089054.

I'm struggling with this one; I've asked at
https://github.com/spyder-ide/spyder/issues/23074
for help, but nothing so far.  I've just pushed my current work to
salsa (git@salsa.debian.org:science-team/spyder.git), and if anyone
has time to look into this, I'd really appreciate it.

Here's the little I've found so far:

* I'm trying to update to spyder 6.0.2

* In an lxc container with Debian unstable and all the test-time
  packages installed, the tests fail in the way described, both with
  Python 3.12 and Python 3.13.

* In the same lxc container, if I build a virtual Python 3.12 or 3.13
  environment following the upstream testing scripts (in
  .github/workflows) and test the package there, all works smoothly.

Perhaps it's an updated version of python3-pytestqt or something like
that?

Best wishes,

   Julian

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

#16593

On Tue, Dec 17, 2024 at 12:53:42PM +0000, Julian Gilbey wrote:
> On Mon, Dec 16, 2024 at 01:58:14AM +0000, Colin Watson wrote:
> > [...]
> >  * spyder: #1088068/#1089054.
> 
> I'm struggling with this one; I've asked at
> https://github.com/spyder-ide/spyder/issues/23074
> for help, but nothing so far.  I've just pushed my current work to
> salsa (git@salsa.debian.org:science-team/spyder.git), and if anyone
> has time to look into this, I'd really appreciate it.

I poked around a bit in pdb.  I think the problem is that one plugin is
calling the icon machinery at class creation time, before a QApplication
or equivalent has been set up, so font loading doesn't happen.  Since
pytest goes through and loads all the Python files to look for tests,
this causes it problems.

This patch helps (borrowed from similar code in a different plugin);
feel free to send it upstream if you think it makes sense:

diff --git a/spyder/plugins/preferences/widgets/configdialog.py b/spyder/plugins/preferences/widgets/configdialog.py
index c3f6bb3..d822431 100644
--- a/spyder/plugins/preferences/widgets/configdialog.py
+++ b/spyder/plugins/preferences/widgets/configdialog.py
@@ -28,11 +28,11 @@ class ConfigDialog(SidebarDialog):
 
     # Constants
     TITLE = _("Preferences")
-    ICON = ima.icon('configure')
     MIN_WIDTH = 940 if MAC else (875 if WIN else 920)
     MIN_HEIGHT = 700 if MAC else (660 if WIN else 670)
 
     def __init__(self, parent=None):
+        self.ICON = ima.icon('configure')
         SidebarDialog.__init__(self, parent)
 
         # Attributes

With that, the tests are able to actually start up, although there are
some other failures.  It might be worth experimenting with whether
upgrading yapf to a more recent upstream version would help with the
rest?  And it's a rather slow set of tests so I didn't wait for them to
finish before sending this email.

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]

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

#16595

On Fri, Dec 20, 2024 at 03:22:57AM +0000, Colin Watson wrote:
> On Tue, Dec 17, 2024 at 12:53:42PM +0000, Julian Gilbey wrote:
> > On Mon, Dec 16, 2024 at 01:58:14AM +0000, Colin Watson wrote:
> > > [...]
> > >  * spyder: #1088068/#1089054.
> > 
> > I'm struggling with this one; I've asked at
> > https://github.com/spyder-ide/spyder/issues/23074
> > for help, but nothing so far.  I've just pushed my current work to
> > salsa (git@salsa.debian.org:science-team/spyder.git), and if anyone
> > has time to look into this, I'd really appreciate it.
> 
> I poked around a bit in pdb.  I think the problem is that one plugin is
> calling the icon machinery at class creation time, before a QApplication
> or equivalent has been set up, so font loading doesn't happen.  Since
> pytest goes through and loads all the Python files to look for tests,
> this causes it problems.
> [...]

Hi Colin,

That's amazing, thank you!  I'm still curious why it succeeds with the
upstream version in a virtual environment but not with our setup.
I'll try it out when I'm better and submit it upstream.  (And in the
meantime, spyder has an autorm date of 2024-12-25, if I recall
correctly, so this should not hold up the Python 3.13 transition.)

Also, I'm used to having lots of new test failures with newer versions
of Spyder, so what you observed about several tests failing doesn't
surprise me!

Best wishes,

   Julian

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

#16594

On Mon, Dec 16, 2024 at 01:58:14AM +0000, Colin Watson wrote:
> While there are a few bits of that transition tracker still red, the
> current target is to work on the list of autopkgtest failures shown on
> https://tracker.debian.org/pkg/python3-defaults in order to get the
> addition of 3.13 as a supported version into testing.  As usual, this
> page can be a little hard to interpret because it shows test failures of
> the versions of those packages in testing, and you have to click through
> to each corresponding package (sometimes through multiple levels of
> failures) to see whether it's been fixed in unstable.  But with ~35
> packages left there, it's getting easier to wade through and we're
> getting pretty close.

We've dealt with on the order of half of those one way or another, so
here's an update:

>  * audioread: #1082047; apparently needs packaging of a couple of pieces
>    removed from the standard library.  Reverse-dependencies are eartag,
>    puddletag, and python3-acoustid.

I poked #debian-ftp about maybe getting python-deadlib through NEW.

>  * dask/dask.distributed: #1088234 and #1088286, but also #1085947 in
>    sphinx-book-theme.  I sank a bunch of time into trying to fix this
>    last month and didn't really get anywhere very satisfying.  Can
>    anyone with more experience with these packages figure this out?

Currently exchanging email with Nilson about the state of
sphinx-book-theme.  It might also be worth somebody seeing if it's
practical to temporarily detach dask/dask.distributed from its
documentation theme.

>  * datalad-next: #1088038.  Probably not too hard if you can figure out
>    how that test is supposed to work.

Fixed.

>  * deepdiff: #1088239, blocked by orderly-set in NEW.  I poked
>    #debian-ftp.

ftpmaster processed orderly-set through NEW, so Emmanuel fixed this in
unstable.  There's currently an i386 autopkgtest failure, but Fabian
fixed rust-associative-cache to build on i386, and that should sort it
out once it reaches testing.

>  * hyperkitty: #1088312.  Should be fairly easy.

No progress - anyone?

>  * ironic-python-agent: #1089531.  Should be fairly easy; zigo said on
>    IRC that this is a leaf package and doesn't need to block migration.
> 
>  * ovn-octavia-provider: #1088762.  zigo said on IRC that this is a leaf
>    package and doesn't need to block migration.

Thomas fixed these two in unstable.

>  * pocketsphinx-python: #1088764.  Apparently difficult.

No progress as far as I know.  (I guess we could wait for autoremoval
from testing, which is currently scheduled for 29 December.)

>  * python-attrs: Fixed in unstable; blocked on python-cattrs.
> 
>  * python-beartype: #1089017.  Apparently fixed upstream, though I don't
>    know exactly where.
> 
>  * python-cattrs: #1073406/#1086614.
> 
>  * python-omegaconf: #1089049.

No progress on this lot as far as I know.

>  * python-oslo.messaging: I believe this is fixed in unstable
>    (#1089050) and waiting for python-eventlet to migrate to testing.

Fixed.

>  * python-pure-python-adb: #1082251/#1084618; apparently just needs a
>    dependency on python3-zombie-telnetlib?

Emmanuel fixed this in unstable.

>  * python-voip-utils: #1088827 fixed in unstable, but has an autopkgtest
>    regression on s390x (#1089826).

No progress.  I poked Edward on IRC.

>  * rich: #1082290; seems to be fixed upstream.

I investigated this (with help from debusine's new reverse-dependency
autopkgtest workflow) and concluded that upgrading rich and textual
should fix it; details in the bug.  Waiting for feedback from Sandro.

>  * smart-open: #1089053; upstream fix in progress.

Fixed in unstable.

>  * spyder: #1088068/#1089054.

See replies to this email thread.  There's clearly some more work to do
here, but it looks somewhat tractable.

>  * twisted: Fixed in unstable, just waiting for matrix-synapse to
>    migrate first (which should be soon).

Fixed.

> There are also a number of architecture-specific failures showing up
> there.  Some might go away with a few more retries I guess, but we'll
> likely need to work out what to do about the rest.  I haven't looked at
> these in any depth.

I chased down a few of these.  dipy is fixed in unstable; fenics-basix
is #1090766; I fixed pytest-forked and pytest-mpi in unstable.

python-libtmux/s390x (e.g.
https://ci.debian.net/packages/p/python-libtmux/testing/s390x/55551127/)
looks as though it needs investigation.

statsmodels/armel (e.g.
https://ci.debian.net/packages/s/statsmodels/testing/armel/55559166/)
probably just requires skipping some slow tests, since the test takes
twice as long while we have two supported Python versions and it's not
very fast on armel to begin with.  Somebody who knows the package better
than I do can probably make a guess at which tests are most reasonable
to exclude.

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]

[toc] | [prev] | [standalone]

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

csiph-web