Python 3.13 addition as a supported Python version started

[Matthias Klose]

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

[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

[Matthias Klose]

Post by PICCA Frederic-Emmanuel
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.

Post by PICCA Frederic-Emmanuel
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

[PICCA Frederic-Emmanuel]

Post by Matthias Klose
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

[Charles Plessy]

Post by PICCA Frederic-Emmanuel
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.

On days where my thoughts are dark, I sometimes imagine some smart
people planning the future in a meeting room and saying "and the great
thing with open source is that if you push your change in a major
distribution, they will propagate patches upstream for free!"…

It is time that Python, GCC, etc. leverage AI to send patches upstream
by themselves and free us from that burden.

Bonne soirée,

[Stefano Rivera]

Hi debian-python (2024.11.13_15:01:31_+0000)

Hi PICCA (2024.11.13_10:04:26_+0000)

Post by PICCA Frederic-Emmanuel
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]

Hi PICCA (2024.11.13_10:04:26_+0000)

Post by PICCA Frederic-Emmanuel
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/***@satie.tumbleweed.org.za

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

Stefano