Hi all, Here's a short progress report of how things are going, plus an open question that still needs to be agreed upon.
## Building against 3.15 status update I continue to send patches to as many packages as possible to get them to build. Lately, more and more build failures are caused by non-Python-3.15 breakages, but it's still good to fix them. From my large selection of 7k packages, 210 packages are still failing to build. From the release team's smaller transition selection, 5 are failing to build and 46 are failing their autopkg tests (although many of them are just the autodep8 tests). On the uploading front, there has also been some progress, with 82 resolved bugs as of today. Thanks to everyone that is giving a hand there! Please continue to do so, there are currently 87 patches waiting to be applied [1]. ## Testing with 3.15 as the default version In parallel, I've started testing packages setting Python 3.15 as the default Python version. This catches other problems, in particular for packages that only build against the default. For this case, I've selected a subset of 1180 packages. Out of those, 872 packages have already been built successfully, 67 failed to build and the rest are blocked by build-dependencies. I've started filing bugs for this using the python3.15-default tag [2]. The list is currently small and not as urgent. To get this going, I had to make a couple of changes to the tooling, like the contents of the python3.15 package [3] (thanks Matthias for applying it!), or updating dh-python to stop using glob1 [4]. ## Discussion point: free-threaded / -nogil packages As I had mentioned in my initial email [5], we need to somehow modify our tooling to allow packages to declare that they support building against the no-gil variant. I've been working on a proposal that creates the -nogil packages from the python3.15 package [6]. This would add the python3.15t interpreter and its corresponding standard library. The MR is a work in progress, there are some decisions I'm not certain of, like whether we should ship a completely separate standard library (like upstream expects), or only the .so files (to avoid duplicating ~20MB of .py files). And this doesn't solve the open question of how packages can indicate whether they support -nogil or not. As mentioned before, these are the options that I can think of: - We could use something similar to XS-Python-Versions (like XS-Python-Variants), but this comes with some parsing challenges. - We could rely on having a build dependency on python3-nogil-dev or python3-nogil-all-dev, for packages that support the variant. - We could add a parameter to py3version so that it also lists the -nogil variant as a separate version. This should make it easier for packages where we need to explicitly handle multiple python versions. We probably will need to implement a combination of those. It would be good if we could discuss and agree on how we are going to manage this soon. Happy Hacking, [1]: https://bugs.debian.org/cgi-bin/[email protected]&tag=python3.15 [2]: https://bugs.debian.org/cgi-bin/[email protected]&tag=python3.15-default [3]: https://salsa.debian.org/cpython-team/python3/-/merge_requests/45 [4]: https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/91 [5]: https://lists.debian.org/debian-python/2026/08/msg00065.html [6]: https://salsa.debian.org/cpython-team/python3/-/merge_requests/46 -- "Can you imagine what I would do if I could do all I can?" -- Sun Tzu Saludos /\/\ /\ >< `/
signature.asc
Description: PGP signature
