Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On Mon, Apr 20, 2020 at 09:57:30AM +0200, Thomas Goirand wrote: > On 4/20/20 4:36 AM, peter green wrote: > > Funcsigs is a backport of the PEP 362 function signature features from > Python 3.3's inspect module. Python 2 has never been removed from this > package. Though instead, we shall remove this source package entirely > from Debian. > > Traceback2 *already* has Python 2 support removed in Sid. I uploaded > this on the 21st of march, pressured by its potential autoremoval. > > > 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. > > There's no other choice but to fix nipype at this point, or wait until > it gets autoremoved from Testing. IMO, it'd be fine to NMU a new > upstream release if you contact the current maintainer and/or using the > delayed queue. JFTR, nipype is removed from testing since August last year, so this is totally not a blocker :-) Cheers, Moritz
Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On 21/04/2020 22:20, Thomas Goirand wrote: So, if I'm following correctly, what you seem to propose, is to remove Python 2 from unittest2. If that's the case, then I agree with such a plan. I just didn't dare to do it yet. Yes, whichever approach is taken to dealing with funcsigs, unittest2 will need to drop it's python2 packages. Though in fact, I already worked on that, but stopped, also because unittest2 FTBFS when I try building it on my laptop. So I've pushed it in its normal Git repo [1] under a py2-removal branch. If anyone has some time available to look at it, that'd be nice (I currently don't...). It appears that this was fixed in a NMU, but the NMU changes were never imported into the packaging repository, once I imported the NMU changes the package built fine here.
Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On 4/22/20 6:23 AM, Valentin Vidić wrote: > On Tue, Apr 21, 2020 at 11:20:16PM +0200, Thomas Goirand wrote: >> You can remove all of the python-oslo* from the list. The versions in >> Experimental, which are the next version of OpenStack, are fixed. In 2 >> weeks of time, I'll upload all what I staged in Experimental to Sid >> (maybe 150 packages?) and that's going to fix it all. > > Will the new OpenStack version also fix this issue? > > #955116 python-murano-pkg-check: FTBFS with Sphinx 2.4: AttributeError: > 'Sphinx' object has no attribute 'info' Hopefully yes. As I understand, the issue is in oslo-sphinx, which is deprecated. I checked, and the master branch of murano-pkg-check doesn't use oslo-sphinx (and is therefore fixed). I'm waiting for it to be released, hopefully this week or the next one. Cheers, Thomas Goirand (zigo)
Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On Tue, Apr 21, 2020 at 11:20:16PM +0200, Thomas Goirand wrote: > You can remove all of the python-oslo* from the list. The versions in > Experimental, which are the next version of OpenStack, are fixed. In 2 > weeks of time, I'll upload all what I staged in Experimental to Sid > (maybe 150 packages?) and that's going to fix it all. Will the new OpenStack version also fix this issue? #955116 python-murano-pkg-check: FTBFS with Sphinx 2.4: AttributeError: 'Sphinx' object has no attribute 'info' -- Valentin
Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
Hi Thomas (2020.04.21_21:20:16_+) > > But that still leaves the question of what to do about the dependency of > > pytest on pypy-funcsigs ? should pypy modules be removed from pytest and > > it's reverse-dependencies in the same way that regular python2 modules > > were? how feasible is that? are pypy-* packages only useful with python2 > > pypy or are they also useful with python3 pypy? Pretty much, yes. pypy itself (the python 2.7 pypy) will continue to exist for the foreseeable future, to support building pypy3. But we don't need to ship modules for it. I'd be pretty happy if we had working virtualenv, and nothing else. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On 4/20/20 2:51 PM, peter green wrote: > On 20/04/2020 08:57, Thomas Goirand wrote: >>> 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. >> Funcsigs is a backport of the PEP 362 function signature features from >> Python 3.3's inspect module. > Thanks for the info. >> Python 2 has never been removed from this >> package. Though instead, we shall remove this source package entirely >> from Debian. > # Broken Depends: > nipype: python-nipype > pytest: pypy-pytest > python-logfury: python3-logfury > python-oslo.utils: python3-oslo.utils > > # Broken Build-Depends: > beaker: python3-funcsigs > kombu: python3-funcsigs > nipype: python-funcsigs > pagure: python3-funcsigs > pytest: pypy-funcsigs > python-oslo.log: python3-funcsigs > python-oslo.utils: python3-funcsigs (>= 0.4) > ripe-atlas-cousteau: python3-funcsigs You can remove all of the python-oslo* from the list. The versions in Experimental, which are the next version of OpenStack, are fixed. In 2 weeks of time, I'll upload all what I staged in Experimental to Sid (maybe 150 packages?) and that's going to fix it all. For the others, probably I should start filling bugs... > If what you say is correct then it sounds like the python3-funcsigs > revese depedencies could be dealt with fairly easily. > > But that still leaves the question of what to do about the dependency of > pytest on pypy-funcsigs ? should pypy modules be removed from pytest and > it's reverse-dependencies in the same way that regular python2 modules > were? how feasible is that? are pypy-* packages only useful with python2 > pypy or are they also useful with python3 pypy? I really don't know about pypy. Probably the pypy-pytest should indeed go away, as the initial plan was to switch to pypy3. Maybe tumbleweed (Stefano Rivera) would be able to answer. I'm adding him as Cc. >> Traceback2 *already* has Python 2 support removed in Sid. I uploaded >> this on the 21st of march, pressured by its potential autoremoval. > > Sorry it seems I got my package names mixed up when writing the list of > options. I said traceback2 where I meant unittest2. So, if I'm following correctly, what you seem to propose, is to remove Python 2 from unittest2. If that's the case, then I agree with such a plan. I just didn't dare to do it yet. Though in fact, I already worked on that, but stopped, also because unittest2 FTBFS when I try building it on my laptop. So I've pushed it in its normal Git repo [1] under a py2-removal branch. If anyone has some time available to look at it, that'd be nice (I currently don't...). Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/python-team/modules/unittest2/
Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On 20/04/2020 08:57, Thomas Goirand wrote: 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. Funcsigs is a backport of the PEP 362 function signature features from Python 3.3's inspect module. Thanks for the info. Python 2 has never been removed from this package. Though instead, we shall remove this source package entirely from Debian. # Broken Depends: nipype: python-nipype pytest: pypy-pytest python-logfury: python3-logfury python-oslo.utils: python3-oslo.utils # Broken Build-Depends: beaker: python3-funcsigs kombu: python3-funcsigs nipype: python-funcsigs pagure: python3-funcsigs pytest: pypy-funcsigs python-oslo.log: python3-funcsigs python-oslo.utils: python3-funcsigs (>= 0.4) ripe-atlas-cousteau: python3-funcsigs If what you say is correct then it sounds like the python3-funcsigs revese depedencies could be dealt with fairly easily. But that still leaves the question of what to do about the dependency of pytest on pypy-funcsigs ? should pypy modules be removed from pytest and it's reverse-dependencies in the same way that regular python2 modules were? how feasible is that? are pypy-* packages only useful with python2 pypy or are they also useful with python3 pypy? Traceback2 *already* has Python 2 support removed in Sid. I uploaded this on the 21st of march, pressured by its potential autoremoval. Sorry it seems I got my package names mixed up when writing the list of options. I said traceback2 where I meant unittest2. There's no other choice but to fix nipype at this point, or wait until it gets autoremoved from Testing. It already was autoremoved from testing. IMO, it'd be fine to NMU a new upstream release if you contact the current maintainer and/or using the delayed queue. A new upstream release for a package I do not use is not something I feel comfortable NMUing. I was hoping that my initial mail would prompt action on the parts of the nipype maintainers but if they don't respond then I tend towards ignoring breakage of sid-only packages that need non-trivial fixes. IMO, we should get unittest2 free of Py2 support ASAP, and open an FTP team bug to get funcsigs removed from Debian. Cheers, Thomas Goirand (zigo)
