Bug#949312: txsocksx: should this package be removed?
On Sat, 8 Feb 2020 20:25:35 -0500 Sandro Tosi wrote: > There *are* cases where it makes sense, the one that comes to mind is > moin: wiki.d.o uses that software and we're in no position to switch > to a different wiki engine; moin hasnt been ported to python3 yet > (likely it wont) so it is justifiable to mark it as py2keep. FYI, the moin switch to Python 3 is done in Moin 2 but Moin 2 isn't yet suitable for production use according to upstream. https://moinmo.in/Python3 https://github.com/moinwiki/moin-1.9/issues/5 https://github.com/moinwiki/moin/pull/845/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#949312: txsocksx: should this package be removed?
There doesn't seem to be any interest in actually working on this package, so I'm going to go ahead with the removal. If the rdepends are going to make it back into Testing, it should be after switching to python3, so this package won't be needed. Scott K
Bug#949312: txsocksx: should this package be removed?
On Monday, February 17, 2020 5:58:14 PM EST Adrian Bunk wrote: > On Mon, Feb 17, 2020 at 12:05:59PM -0500, Scott Kitterman wrote: > > Here's a thought: > > > > Given the concern Adrian has expressed relative to tahoe-lafs, how about > > if > > someone uploads the relevant packages to experimental: > > > > python-txsocksx -> foolscap -> tahoe-lafs > > > > Then the Unstable rm can go forward, but in the event python2 stays in the > > bullseye release, it's easy to re-introduce. It wouldn't even need to go > > through New. You'd probably want to upload any other depends that might > > drop python2 support as well with a sufficiently high version that they > > won't get removed due to NVIU. > > How would this bring any advantage? > > Sandro seems to be working mainly on testing, and RC bugs already exist > that prevent re-migration to testing. It would allow for packages to remain in the archive without complicating other removal efforts. Since he is working from Testing (and to a lesser extent Unstable), if the package is in Experimental, it'd be out of the way and unlikely to be futzed with. > > BTW: The Christmas Eve removal in #937449 a few days after removal > from testing and despite maintainer objection might be a good > example how early removal from unstable makes people not happy. We're certainly not perfect. In cases where a package was removed when it shouldn't be, people can ping me on IRC in #debian-ftp and I'll be glad to give it a priority look to get it back in the archive. Scott K signature.asc Description: This is a digitally signed message part.
Bug#949312: txsocksx: should this package be removed?
On Mon, Feb 17, 2020 at 12:05:59PM -0500, Scott Kitterman wrote: > Here's a thought: > > Given the concern Adrian has expressed relative to tahoe-lafs, how about if > someone uploads the relevant packages to experimental: > > python-txsocksx -> foolscap -> tahoe-lafs > > Then the Unstable rm can go forward, but in the event python2 stays in the > bullseye release, it's easy to re-introduce. It wouldn't even need to go > through New. You'd probably want to upload any other depends that might drop > python2 support as well with a sufficiently high version that they won't get > removed due to NVIU. How would this bring any advantage? Sandro seems to be working mainly on testing, and RC bugs already exist that prevent re-migration to testing. > Scott K cu Adrian BTW: The Christmas Eve removal in #937449 a few days after removal from testing and despite maintainer objection might be a good example how early removal from unstable makes people not happy.
Bug#949312: txsocksx: should this package be removed?
Here's a thought: Given the concern Adrian has expressed relative to tahoe-lafs, how about if someone uploads the relevant packages to experimental: python-txsocksx -> foolscap -> tahoe-lafs Then the Unstable rm can go forward, but in the event python2 stays in the bullseye release, it's easy to re-introduce. It wouldn't even need to go through New. You'd probably want to upload any other depends that might drop python2 support as well with a sufficiently high version that they won't get removed due to NVIU. Scott K signature.asc Description: This is a digitally signed message part.
Bug#949312: txsocksx: should this package be removed?
On Sat, Feb 08, 2020 at 08:25:35PM -0500, Sandro Tosi wrote: > On Fri, Feb 7, 2020 at 6:37 AM Adrian Bunk wrote: > > On Thu, Feb 06, 2020 at 09:20:31PM -0500, Sandro Tosi wrote: > > > On Sun, Feb 2, 2020 at 6:51 AM Adrian Bunk wrote: > > > > On Tue, Jan 28, 2020 at 04:06:28PM -0500, Sandro Tosi wrote: > > > > >... > > > > > python-txsocksx -> foolscap -> tahoe-lafs > > > > > > > > > > both foolscap and tahoe-lafs were removed from testing, so to my > > > > > script python-txsocksx appears as a leaf package (as its removal wont > > > > > break already broken/RC packages not in testing). not sure what we > > > > > want to do here, none of the 2 other packages will get fix anytime > > > > > soon and may get removed from debian entirely at some point. > > > > >... > > > > > > > > The latter statement is not true. > > > > > > > > Both tahoe-lafs and foolscap have substantial upstream activities > > > > towards Python 3 porting, > > > > > > my statement says "none of the 2 other packages will get fix anytime > > > soon and may get removed from debian entirely at some point" -- what > > > do you find un-true about it? > > > > > > i did not say those projects python3 port is not being worked on, but > > > i say that they are not close to finishing it, which includes both > > > porting the code *and* testing it and finally release a version that > > > has the python3 port. > > > > To me it looks likely to be finished in time for the bullseye freeze. > > that'd be great, so they could be easily re-introduced in Debian once > they are ready. Even greater would be to no have all the package removal effects like "sorry that your package has been removed from Debian" bug closure emails to users. >... > > working hard on Python 3 porting which is already 89% completed. > > (no blaming, just stating facts) > > i'm afraid you got facts mixed up: i asked for the removal of > txsocksx, while it's tahoe-lafs port that's at 89% completion. >... You asked the ftp team to recommend filing a removal bug for tahoe-lafs. It is hard to see any other purpose behind your "Let me know how you want me to proceed" since the alternative would have been that you just close your bug. >... > > What always strikes me as weird is the py2keep option, why are you > > offering that some packages can use Python 2.7 for an additional > > *Debian release*? > > well, you need to ask that to who crafted the bug template. > > There *are* cases where it makes sense, the one that comes to mind is > moin: wiki.d.o uses that software and we're in no position to switch > to a different wiki engine; moin hasnt been ported to python3 yet > (likely it wont) so it is justifiable to mark it as py2keep. And users who use tahoe-lafs might not be in a position to switch to a different file storage - same situation, except that you are not be among the users. > > Much of the python2 removal only makes sense when the point is to not > > have to ship and security support Python 2.7 in Debian 11. > > the level of security support will be decided by the security team in > concert with the release team, if i remember correctly how it was done > in the part (f.e. with chromium and node?) Did DSA agree to run wiki.d.o with an interpreter without security support? Shipping the software running wiki.d.o in bullseye only makes sense after security support for the interpreter it uses has been secured. >... > If we end up with 2/300 python2 modules/apps in bullseye (for > important packages) that's already a good win, and the security and > infrastructural implications of having such a small subset of packages > will be entirely different than (say) 1500 still pending. >... In many of the more scientific areas of the archive it is normal that important software for some specific field (and therefore with low popcon) was written as part of a scientific project or thesis and is not maintained afterwards. In many cases the only choice for the Debian maintainers to fix your bugs has been to upload whatever 2to3 produced, and hope that it works. If the python2.7 interpreter cannot be shipped in bullseye because it is not supportable this is the best option available. If the python2.7 interpreter is shipped and supported in bullseye this is bad, since it gives our users worse software for no good reason. Plenty of bugs like #948706 pop up for buggy python3 conversions. The security implication of many of the Python 3 conversions might be a disaster, people who do not know the code somehow trying to get it ported sounds like a perfect recipe for Debian-specific CVEs. Please do not get me wrong, I do appreciate your overall work on moving Debian towards Python 3 and for a large part of the archive this move will not be a problem for bullseye. But if the python2.7 interpreter ends up being shipped in bullseye then reducing the number of python2 using packages is not a value itself, and removals or buggy python3 conversions will for many packages be
Bug#949312: txsocksx: should this package be removed?
On Fri, Feb 7, 2020 at 6:37 AM Adrian Bunk wrote: > > On Thu, Feb 06, 2020 at 09:20:31PM -0500, Sandro Tosi wrote: > > On Sun, Feb 2, 2020 at 6:51 AM Adrian Bunk wrote: > > > > > > On Tue, Jan 28, 2020 at 04:06:28PM -0500, Sandro Tosi wrote: > > > >... > > > > python-txsocksx -> foolscap -> tahoe-lafs > > > > > > > > both foolscap and tahoe-lafs were removed from testing, so to my > > > > script python-txsocksx appears as a leaf package (as its removal wont > > > > break already broken/RC packages not in testing). not sure what we > > > > want to do here, none of the 2 other packages will get fix anytime > > > > soon and may get removed from debian entirely at some point. > > > >... > > > > > > The latter statement is not true. > > > > > > Both tahoe-lafs and foolscap have substantial upstream activities > > > towards Python 3 porting, > > > > my statement says "none of the 2 other packages will get fix anytime > > soon and may get removed from debian entirely at some point" -- what > > do you find un-true about it? > > > > i did not say those projects python3 port is not being worked on, but > > i say that they are not close to finishing it, which includes both > > porting the code *and* testing it and finally release a version that > > has the python3 port. > > To me it looks likely to be finished in time for the bullseye freeze. that'd be great, so they could be easily re-introduced in Debian once they are ready. > > for tahoe-lafs the effort is tracked at > > https://tahoe-lafs.org/trac/tahoe-lafs/milestone/Support%20Python%203 > > which is currently marked at 89% completed; it was marked to be > > completed by Dec 1, 2019, so they are 2 months behind their own > > schedule (again, no blaming, just stating facts) > >... > > You are pushing strongly for the removal of a package where upstream is "pushing strongly"? I opened a bug against a package that's not actively maintained upstream, waited a week (without any objection or reply), and then reassigned it to ftp.d.o. It may be quicker than usual Debian processes, but definitely not "strongly" > working hard on Python 3 porting which is already 89% completed. > (no blaming, just stating facts) i'm afraid you got facts mixed up: i asked for the removal of txsocksx, while it's tahoe-lafs port that's at 89% completion. Please also consider this: right now, txsocksx has no python3 support; so either the new port of tahoe-lafs to python3 has removed the dependency on txsocksx or they are gonna have to wait for a port to be available. In any case, txsocksx can be removed right now and reintroduced when ported to python3 (or even never, if that wont happen) > It has happened that a removal bug was filed for a Python2 using package > that was executed by the ftp team despite objection from the Debian > maintainer. > (again, no blaming, just stating facts) is this the case? according to PTS you're not part of the maintainers/uploaders for txsocksx, tahoe-lafs or foolscap, and to my knowledge none of them objected here. What am i missing? > For many maintainers the approaching bullseye freeze is the deadline > when they get all their packages into shape. Some people have enough > spare time to work on Debian continuously, others don't. and that's why there are people helping out, what's your point here? > Many upstream developers also have priorities that can make it a > challenge to find the time to do a proper conversion to Python 3, and > made it lower priority when the conversion didn't bring any benefits. > (again, no blaming, just stating facts) right, but according to https://www.python.org/doc/sunset-python-2/ there has been plenty of time to migrate to python3, so i do understand the human nature to procrastinate until the very last moment (i do that all the time!) but that moment is now. It's also a good indication if that upstream project is still maintained or not, which consequently allow Debian to drop such projects, which i believe is the case for txsocksx. > Removal from testing is not really problematic, but removal from Debian > is something that should not be done too aggressively. are you referring to this specific example or any other of *my* activities towards the py2removal effort? i dont see how this removal request is aggressive. just realize removing txsocksx will allow `src:parsley` to drop its python2 support, since it's the only remaining rdep. > > > the reasonable way forward would be to close > > > this RM bug and watch how it all will get resolved in a few months with > > > new upstream versions. > > > > We've been known the end of python2 support would be in 2020 since > > years, i'm not sure it's fair for the projects that took the time > > earlier and to the debian maintainers to ask to keep supporting > > python2 packages for (relatively) old software for additional *few months*. > >... > > What always strikes me as weird is the py2keep option, why are you > offering that some packages can use Python 2.7
Bug#949312: txsocksx: should this package be removed?
On Thu, Feb 06, 2020 at 09:20:31PM -0500, Sandro Tosi wrote: > On Sun, Feb 2, 2020 at 6:51 AM Adrian Bunk wrote: > > > > On Tue, Jan 28, 2020 at 04:06:28PM -0500, Sandro Tosi wrote: > > >... > > > python-txsocksx -> foolscap -> tahoe-lafs > > > > > > both foolscap and tahoe-lafs were removed from testing, so to my > > > script python-txsocksx appears as a leaf package (as its removal wont > > > break already broken/RC packages not in testing). not sure what we > > > want to do here, none of the 2 other packages will get fix anytime > > > soon and may get removed from debian entirely at some point. > > >... > > > > The latter statement is not true. > > > > Both tahoe-lafs and foolscap have substantial upstream activities > > towards Python 3 porting, > > my statement says "none of the 2 other packages will get fix anytime > soon and may get removed from debian entirely at some point" -- what > do you find un-true about it? > > i did not say those projects python3 port is not being worked on, but > i say that they are not close to finishing it, which includes both > porting the code *and* testing it and finally release a version that > has the python3 port. To me it looks likely to be finished in time for the bullseye freeze. > for tahoe-lafs the effort is tracked at > https://tahoe-lafs.org/trac/tahoe-lafs/milestone/Support%20Python%203 > which is currently marked at 89% completed; it was marked to be > completed by Dec 1, 2019, so they are 2 months behind their own > schedule (again, no blaming, just stating facts) >... You are pushing strongly for the removal of a package where upstream is working hard on Python 3 porting which is already 89% completed. (no blaming, just stating facts) It has happened that a removal bug was filed for a Python2 using package that was executed by the ftp team despite objection from the Debian maintainer. (again, no blaming, just stating facts) For many maintainers the approaching bullseye freeze is the deadline when they get all their packages into shape. Some people have enough spare time to work on Debian continuously, others don't. Many upstream developers also have priorities that can make it a challenge to find the time to do a proper conversion to Python 3, and made it lower priority when the conversion didn't bring any benefits. (again, no blaming, just stating facts) Removal from testing is not really problematic, but removal from Debian is something that should not be done too aggressively. > > the reasonable way forward would be to close > > this RM bug and watch how it all will get resolved in a few months with > > new upstream versions. > > We've been known the end of python2 support would be in 2020 since > years, i'm not sure it's fair for the projects that took the time > earlier and to the debian maintainers to ask to keep supporting > python2 packages for (relatively) old software for additional *few months*. >... What always strikes me as weird is the py2keep option, why are you offering that some packages can use Python 2.7 for an additional *Debian release*? Much of the python2 removal only makes sense when the point is to not have to ship and security support Python 2.7 in Debian 11. There are plenty of older unsupported interpreters and libraries for various languages in Debian, if Debian 11 ends up shipping Phyton 2.7 then most python2 users are not a problem and using python2 is better for our users than some of the blind 2to3 conversions to Python3 that have been done resulting in broken packages. > Regards, cu Adrian
Bug#949312: txsocksx: should this package be removed?
On Sun, Feb 2, 2020 at 6:51 AM Adrian Bunk wrote: > > On Tue, Jan 28, 2020 at 04:06:28PM -0500, Sandro Tosi wrote: > >... > > python-txsocksx -> foolscap -> tahoe-lafs > > > > both foolscap and tahoe-lafs were removed from testing, so to my > > script python-txsocksx appears as a leaf package (as its removal wont > > break already broken/RC packages not in testing). not sure what we > > want to do here, none of the 2 other packages will get fix anytime > > soon and may get removed from debian entirely at some point. > >... > > The latter statement is not true. > > Both tahoe-lafs and foolscap have substantial upstream activities > towards Python 3 porting, my statement says "none of the 2 other packages will get fix anytime soon and may get removed from debian entirely at some point" -- what do you find un-true about it? i did not say those projects python3 port is not being worked on, but i say that they are not close to finishing it, which includes both porting the code *and* testing it and finally release a version that has the python3 port. for tahoe-lafs the effort is tracked at https://tahoe-lafs.org/trac/tahoe-lafs/milestone/Support%20Python%203 which is currently marked at 89% completed; it was marked to be completed by Dec 1, 2019, so they are 2 months behind their own schedule (again, no blaming, just stating facts) for foolscape the effort is tracked at https://github.com/warner/foolscap/issues/48 which received some attention at the beginning on 2020 (holiday break?) and none since Jan 5. So, can you explain what you find misrepresented in my statement? > the reasonable way forward would be to close > this RM bug and watch how it all will get resolved in a few months with > new upstream versions. We've been known the end of python2 support would be in 2020 since years, i'm not sure it's fair for the projects that took the time earlier and to the debian maintainers to ask to keep supporting python2 packages for (relatively) old software for additional *few months*. Please also note that txsocksx is not python3 ready yet, nor there's any progress in porting it. How keeping the old python2 package in Debian is gonna help with that port? It would the py2removal effort in debian by removing an old package with no py3k port available, Happy to hear what your thoughts are on this. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#949312: txsocksx: should this package be removed?
On Tue, Jan 28, 2020 at 04:06:28PM -0500, Sandro Tosi wrote: >... > python-txsocksx -> foolscap -> tahoe-lafs > > both foolscap and tahoe-lafs were removed from testing, so to my > script python-txsocksx appears as a leaf package (as its removal wont > break already broken/RC packages not in testing). not sure what we > want to do here, none of the 2 other packages will get fix anytime > soon and may get removed from debian entirely at some point. >... The latter statement is not true. Both tahoe-lafs and foolscap have substantial upstream activities towards Python 3 porting, the reasonable way forward would be to close this RM bug and watch how it all will get resolved in a few months with new upstream versions. > Thanks, cu Adrian
Bug#949312: txsocksx: should this package be removed?
Source: txsocksx Severity: serious Hello, i think txsocksx should be removed from debian: * python2-only * upstream is not progressing on the py3k porting: https://github.com/habnabit/txsocksx/issues/19 * leaf package if i dont hear back within a week with a good reason to keep this package, i'll file for its removal. Regards, Sandro -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
