[Python-modules-team] Bug#938756: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).

peter green plugwash at p10link.net
Mon Apr 20 03:36:00 BST 2020


(using -quiet aliases where multiple involved packages have the same maintainer listed.

Hi

I have just been running some self-contained buildability tests on bullseye and these tests indicated that the python-linecache2 and python-traceback2 source packages have been unbuildable in testing for 170+ days. Both are fixed in unstable by removing python 2 support, but can't migrate to testing because the python-unittest2 binary package depends on the python-traceback2 binary package. The python2 removal bug for python-traceback2 lists python-funcsigs as a blocker. The python2 removal bug for python-traceback2 lists nipype and numba as blockers.

unittest2 and python-funcsigs seem to be just module packages, so dropping python2 support should be simple. numba seems to be a case of leftover recommends and test-triggers so that should be a pretty easy job to clean up too.

nipype on the other hand looks like it needs a new upstream release. It seems this was previously blocked on a package passing new, but said package has now passed new.

python-funcsigs seems to have a build-dependency on python-traceback2 but not a binary dependency, this suggests that the dependency is only used to run tests at build time.

nipype and numba are not currently in testing.

This IMO leaves three potential ways forward

Option 1: fix all four packages to be python 2 free.

Option 2: Remove python2 stuff from traceback2, python-funcsigs and numba. Break the dependencies of nipype in sid.

Option 3: Remove python2 stuff from traceback2, modify python-funcsigs so it still builds the python2 package but does not run tests with python 2.

If the maintainers of nipype are willing to upload a python 3 version soon, then option 1 is IMO the preffered way forward, but a new upstream version is not something I would be prepared to NMU.

Otherwise I am inclined towards option 2. Depending on what responses I get to this mail I may implement this option through NMUs later.



More information about the Python-modules-team mailing list