Re: Python 3.9 for bullseye
On 10/18/20 12:13 PM, Matthias Klose wrote:
> Python 3.9 as a supported Python3 version is now in unstable, and all binNMUs
> are done (thanks to Graham for the work). Bug reports should be all filed
> for
> all known problems [1], and the current state of the 3.9 addition can be seen
> at
> [2] (a few of the "bad" are false packages with b-d n python3-all-dev, but not
> building for 3.9, bug reports also filed).
>
> The major outstanding issue is the pandas stack, all other problems are found
> in
> leaf packages (leaf in the sense of that no other package for the 3.9 addition
> is blocked).
>
> Please help fixing the remaining issues!
>
> Matthias
Hi Matthias,
I don't know if that was on purpose, but you happen to upload Python 3.9
in Unstable the day OpenStack was released. I then rebuilt all of
OpenStack to upload from Experimental to Unstable, and to my surprise,
it went very well (note: all packages in the OpenStack team are running
unit tests at build time on all available Python versions). Only 2
issues happened multiple times:
- base64.{en,de}codestring removal (easy fix: s/string/bytes/)
- Threading.isAlive removal (easy fix too: s/isAlive/is_alive/)
This happened
This is on a set of 200+ packages which I manually rebuilt.
I do expect that there will be more packages with the same issue, so
it'd be nice to have all Python-using packages rebuilt. As Lucas
Nussbaum proposed such a service, should we ask him to do such a massive
rebuilt? Or maybe you have other plans?
Cheers,
Thomas Goirand (zigo)
Re: help with FTBFS bug due to python3.8/3.9 confusion
On Mon, Oct 26, 2020 at 08:54:37AM +0100, Stephen Sinclair wrote: > The recommendations are to change the build-dep on "python-dev" to > "python-all-dev", and I can confirm that this does allow the package > to build. (Is this the right thing to do?) Building a module for all supported Python versions is a right thing to do. > However, autopkgtest tests still fail. The commenter in that bug > report claims, "the lack of 3.8 modules in the package also explains > your problem." However, I do not understand that claim -- wouldn't it > be counter-productive to specify which minor version of Python the > package depends on? I would need to update this manually when the > default switches to Python 3.9. If you are packaging a public module you need to provide it for all supported Python versions. Not sure which tests fail and how, I don't think this is described anywhere? > Although the CMake build is quite complicated and therefore I can > expect such problems, but I am nonetheless confused why it would > select the wrong Python version, as I do specify the Python executable > via the command, > > > -DPYTHON_EXECUTABLE=$(shell which python3)" > > Is there a better way to find the path to the default python interpreter? When building a public module you don't need to care about the default version. -- WBR, wRAR signature.asc Description: PGP signature
python-team/packages repo move request
Hello Julien sent a request to move/archive the redundant ipython repo about two weeks ago, but it looks like it got missed by anyone with admin. Could someone with powers: 1. Archive python-team/packages/ipython 2. Rename python-team/packages/ipython4 -> python-team/packages/ipython The split naming is left over from an old transition years ago and it would be good to just have the repo "ipython" instead of "ipython4", since we're now up to version 7 and the naming no longer makes any sense. More general question - is there a better way of requesting this sort of thing other than ML/IRC? Maybe we could create a pseudopackage in the BTS, or a dummy salsa repo where we can open issues? Thanks Gordon
help with FTBFS bug due to python3.8/3.9 confusion
Hello Debian Python members, I am looking into a bug in a Debian Science package that I maintain and need some information. It is a C++ library with a complicated CMake setup that also produces a Python binding via swig. Recently a FTBFS bug was filed against the package because apparently it does not select the right Python after the introduction of Python 3.9. The bug report can be found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972394 The recommendations are to change the build-dep on "python-dev" to "python-all-dev", and I can confirm that this does allow the package to build. (Is this the right thing to do?) However, autopkgtest tests still fail. The commenter in that bug report claims, "the lack of 3.8 modules in the package also explains your problem." However, I do not understand that claim -- wouldn't it be counter-productive to specify which minor version of Python the package depends on? I would need to update this manually when the default switches to Python 3.9. Although the CMake build is quite complicated and therefore I can expect such problems, but I am nonetheless confused why it would select the wrong Python version, as I do specify the Python executable via the command, > -DPYTHON_EXECUTABLE=$(shell which python3)" Is there a better way to find the path to the default python interpreter? kind regards, Steve
