Re: Bug#949312: txsocksx: should this package be removed?

[Adrian Bunk <bunk@debian.org>]

On Sat, Feb 08, 2020 at 08:25:35PM -0500, Sandro Tosi wrote:
> On Fri, Feb 7, 2020 at 6:37 AM Adrian Bunk <bunk@debian.org> 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 <bunk@debian.org> 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 worse for our users than 
continuing to use python2.

> Regards,

cu
Adrian