Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Thomas Goirand]

On 10/15/19 7:08 PM, Sandro Tosi wrote:
> On Tue, Oct 15, 2019 at 12:55 PM Thomas Goirand  wrote:
>>
>> On 10/15/19 5:00 AM, Craig Small wrote:
>>>
>>>
>>> On Tue, 15 Oct. 2019, 1:04 pm Thomas Goirand, >> > wrote:
>>>
>>> Please re-read the excellent contribution from Neil Williams
>>> in this thread, and explain again why we have a special case... :)
>>>
>>> I just did re-read it; especially about it's RC bugs not a total removal
>>> RM so these packages will sit in unstable and not move into testing.
>>>
>>> That works for me.
>>
>> Hi Craing,
>>
>> I'm not sure if that helps, but here's a patch... :)
> 
> did you test your patch?
> 
> +-print "v1 snmpset result: ", res, "\n"
> ++print9"v1 snmpset result: ", res, "\n")

I have not, because Craig said he would remove Py2, though I had it
written already, so I though I would send it anyways...

Thomas

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Sandro Tosi]

On Tue, Oct 15, 2019 at 12:55 PM Thomas Goirand  wrote:
>
> On 10/15/19 5:00 AM, Craig Small wrote:
> >
> >
> > On Tue, 15 Oct. 2019, 1:04 pm Thomas Goirand,  > > wrote:
> >
> > Please re-read the excellent contribution from Neil Williams
> > in this thread, and explain again why we have a special case... :)
> >
> > I just did re-read it; especially about it's RC bugs not a total removal
> > RM so these packages will sit in unstable and not move into testing.
> >
> > That works for me.
>
> Hi Craing,
>
> I'm not sure if that helps, but here's a patch... :)

did you test your patch?

+-print "v1 snmpset result: ", res, "\n"
++print9"v1 snmpset result: ", res, "\n")


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Thomas Goirand]

On 10/15/19 5:00 AM, Craig Small wrote:
> 
> 
> On Tue, 15 Oct. 2019, 1:04 pm Thomas Goirand,  > wrote:
> 
> Please re-read the excellent contribution from Neil Williams
> in this thread, and explain again why we have a special case... :)
> 
> I just did re-read it; especially about it's RC bugs not a total removal
> RM so these packages will sit in unstable and not move into testing.
> 
> That works for me.

Hi Craing,

I'm not sure if that helps, but here's a patch... :)

Thomas
diff -Nru net-snmp-5.7.3+dfsg/debian/changelog 
net-snmp-5.7.3+dfsg/debian/changelog
--- net-snmp-5.7.3+dfsg/debian/changelog2019-01-05 06:16:10.0 
+0100
+++ net-snmp-5.7.3+dfsg/debian/changelog2019-10-15 04:25:31.0 
+0200
@@ -1,3 +1,9 @@
+net-snmp (5.7.3+dfsg-5.1) UNRELEASED; urgency=medium
+
+  * Add Python 3 support.
+
+ -- Thomas Goirand   Tue, 15 Oct 2019 04:25:31 +0200
+
 net-snmp (5.7.3+dfsg-5) unstable; urgency=medium
 
   * Use debhelper macros for shlibs Closes: #912685
diff -Nru net-snmp-5.7.3+dfsg/debian/control net-snmp-5.7.3+dfsg/debian/control
--- net-snmp-5.7.3+dfsg/debian/control  2019-01-05 06:16:10.0 +0100
+++ net-snmp-5.7.3+dfsg/debian/control  2019-10-15 04:25:31.0 +0200
@@ -8,6 +8,7 @@
 Build-Depends: debhelper (>= 11),
  libtool, libwrap0-dev, libssl-dev, perl (>=5.8), libperl-dev,
  python-all (>= 2.6.6-3~), python-setuptools (>=0.6b3), python2.7-dev,
+ python3-all-dev, python3-setuptools,
  autoconf, automake, debianutils (>=1.13.1),
  dh-python,
  bash (>=2.05), findutils (>=4.1.20), procps,
@@ -160,6 +161,18 @@
  The Net-SNMP Python support files provide the Python functions for
  integration of SNMP into applications written in Python.
 
+Package: python3-netsnmp
+Section: python
+Architecture: any
+Depends: ${python3:Depends}, ${shlibs:Depends}, ${misc:Depends}
+Description: SNMP (Simple Network Management Protocol) Python 3 support
+ The Simple Network Management Protocol (SNMP) provides a framework
+ for the exchange of management information between agents (servers)
+ and clients.
+ .
+ The Net-SNMP Python support files provide the Python functions for
+ integration of SNMP into applications written in Python 3.
+
 Package: tkmib
 Architecture: all
 Depends: libsnmp-perl (>=${source:Version}), perl-tk, ${misc:Depends}
diff -Nru net-snmp-5.7.3+dfsg/debian/patches/fix-space-vs-tabs.patch 
net-snmp-5.7.3+dfsg/debian/patches/fix-space-vs-tabs.patch
--- net-snmp-5.7.3+dfsg/debian/patches/fix-space-vs-tabs.patch  1970-01-01 
01:00:00.0 +0100
+++ net-snmp-5.7.3+dfsg/debian/patches/fix-space-vs-tabs.patch  2019-10-15 
04:25:31.0 +0200
@@ -0,0 +1,16 @@
+Description: Fix space vs tabs
+Author: Thomas Goirand 
+Forwarded: no
+Last-Update: 2019-10-15
+
+--- net-snmp-5.7.3+dfsg.orig/python/setup.py
 net-snmp-5.7.3+dfsg/python/setup.py
+@@ -10,7 +10,7 @@ args = sys.argv[:]
+ for arg in args:
+ if arg.find('--basedir=') == 0:
+ basedir = arg.split('=')[1]
+-  sys.argv.remove(arg)
++sys.argv.remove(arg)
+ intree=1
+ 
+ if intree:
diff -Nru net-snmp-5.7.3+dfsg/debian/patches/py3-compat.patch 
net-snmp-5.7.3+dfsg/debian/patches/py3-compat.patch
--- net-snmp-5.7.3+dfsg/debian/patches/py3-compat.patch 1970-01-01 
01:00:00.0 +0100
+++ net-snmp-5.7.3+dfsg/debian/patches/py3-compat.patch 2019-10-15 
04:22:51.0 +0200
@@ -0,0 +1,419 @@
+Description: Py3 compat
+Author: Thomas Goirand 
+Forwarded: no
+Last-Update: 2019-10-15
+
+--- net-snmp-5.7.3+dfsg.orig/python/netsnmp/client.py
 net-snmp-5.7.3+dfsg/python/netsnmp/client.py
+@@ -2,7 +2,7 @@ import client_intf
+ import string
+ import re
+ import types
+-from sys import stderr
++import sys
+ 
+ # control verbosity of error output
+ verbose = 1
+@@ -37,10 +37,10 @@ def _parse_session_args(kargs):
+ }
+ keys = kargs.keys()
+ for key in keys:
+-if sessArgs.has_key(key):
++if key in sessArgs:
+ sessArgs[key] = kargs[key]
+ else:
+-print >>stderr, "ERROR: unknown key", key
++print("ERROR: unknown key", key, file=sys.stderr)
+ return sessArgs
+ 
+ def STR(obj):
+--- net-snmp-5.7.3+dfsg.orig/python/netsnmp/tests/test.py
 net-snmp-5.7.3+dfsg/python/netsnmp/tests/test.py
+@@ -8,7 +8,7 @@ import time
+ 
+ class BasicTests(unittest.TestCase):
+ def testFuncs(self):
+-print ""
++print("")
+ var = netsnmp.Varbind('sysDescr.0')
+ var = netsnmp.Varbind('sysDescr','0')
+ var = netsnmp.Varbind(
+@@ -19,67 +19,67 @@ class BasicTests(unittest.TestCase):
+ 
+ var = netsnmp.Varbind('.1.3.6.1.2.1.1.1','0')
+ 
+-print "---v1 GET tests -\n"
++print("---v1 GET tests -\n")
+ res = netsnmp.snmpget(var,
+   Version = 1,
+   DestHost='localhost',
+  

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Sandro Tosi]

On Mon, Oct 14, 2019 at 10:14 PM Thomas Goirand  wrote:
>
> On 10/14/19 3:54 PM, Sandro Tosi wrote:
> >>> But in both cases, it's going to take a very long time. Do we really
> >>> want to get stuck on these packages for like forever, or would it feel
> >>> ok to raise the severity to serious, so that the package gets
> >>> auto-removed and then we can work on removing Python 2 from its
> >>> dependencies?
> >>
> >> for me it's perfectly fine to rise severity to serious of all leaf 
> >> packages with py2remove bug as soon as possible. And let's do it 
> >> "automatically" everytime any package gets leaf state.
> >
> > i think it's a bit premature to raise severity to RC (we should also
> > check with the release team): these bugs have been opened since just 2
> > months and a half, and the development cycle for bullseye started not
> > longer before. there's still a lot of time.
>
> It's not as if it has been 10 years we know about this transition, right? :)

definitely 10 years ago we did not know python2 upstream maintenance
would terminate on jan 1, 2020; nor that debian will push to remove
python2 from bullseye.

> How many months do you want to add? Do you seriously think it's going to
> significantly change something about an eventual situation where
> upstream hasn't done the work? If upstream did the work, then what's
> blocking us?
>
> If we see a package where upstream has Py3 support, we don't need to
> raise the severity, we can just do the work instead.

you are trying to generalize the situation of ~3000 packages, it just
doesnt work; every situation is different. There are cases where
upstream release a py3k compatible version and it's not packaged in
debian, or someone forked a py3k version, which is now incompatible
with the py2 version, and so many other different variations.

put the work in, and when we are close to a stall situation and/or
close to the freeze we can evaluate what to do, with drastic decisions
too.

> > (and removing a py2
> > package from a leaf pkg takes 5 minutes, usually, so if everyone in
> > this thread had done that instead of writing an email, we'd be down 5
> > bugs already :D )
>
> I probably have done hundreds of them already. And I do not agree that

lol including
https://tracker.debian.org/news/1065995/accepted-cherrypy3-891-3-source-all-into-unstable/
which broke calibre

you're approach is sometimes reckless and you should re-evaluate it.

Sadly many others did the same, and reverse dependencies broke because
maintainers dropped packages without verify if they were leaf pkgs
first.

Debian is not about speed, is about quality, if you cannot see that,
there's no amount of emails that will change it.

> it takes just 5 minutes. For a trivial leaf package, probably, but when
> you're trying to fix a long chain of dependencies, it can sometimes be a
> non-trivial work. Going from the leaf package and rewinding can
> sometimes lead to mistakes.

even a long chain starts from a leaf package. you fix that and then
you move one step closer. it does not add complexity (as it's the same
set of actions, generally) just time.

> > I think it's also extremely premature (and just a bad idea in general)
> > to consider breakage of reverse dependencies but just dropping py2
> > packages. the Release Team is extremely unhappy with this approach for
> > dealing with the py2removal bugs, so let's not even consider that
> > option.
>
> Yes. Which is why we should raise severity of bugs to RC, and probably
> even remove packages if we need to. Otherwise, this process will take
> forever (ie: longer than a Debian release cycle).

you're missing the point. what is and is not RC is the release team
decision. there is no release goal for the removal of python2 so how
can it be release critical? what belongs or doesnt belong in testing
is again the release team decision. so what would it give us to remove
those packages from testing?

as of now, there are still 1800+ bugs opened tagged py2removal, do you
think it's sane to mark them as RC? please also note there are several
bugs missing too (i'm working on figuring them out, and current count
is ~400 still to report, i'll do so when i finished verifying they are
accurate).

I believe it's unthinkable to raise so many bugs to RC at this stage.
remember also there's always a chance we're gonna release python2 with
bullseye, we'll see when we're close to the release.

if we need more visibility, i can extend some of the tools i already
have (f.e. to create the tracking webpage) to tags bugs, add/update
blocks, and/or any other kind of bugs management.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Craig Small]

On Tue, 15 Oct. 2019, 1:04 pm Thomas Goirand,  wrote:

> Please re-read the excellent contribution from Neil Williams
> in this thread, and explain again why we have a special case... :)

I just did re-read it; especially about it's RC bugs not a total removal RM
so these packages will sit in unstable and not move into testing.

That works for me.

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Craig Small]

On Tue, 15 Oct. 2019, 1:04 pm Thomas Goirand,  wrote:

>
> Either we don't have enough details about net-snmp, or you're trying to
> push for not-valid-yet-another-exception.
>

It's more if a source package makes multiple binary packages, one of those
being a python 2 package, and there are other temporary reasons why that
python package cannot be updated yet.

The perl problem has nothing to do with python, except that problem holds
up the update of net-snmp.  The goal is to fix the other problem and remove
the python module, but it will take time possibly.

I'm pretty sure net-snmp is not the only situation where the python binary
package is one of the many from a single source.  In fact these will
probably be the problem ones because  they're often a case of "make python
bindings once then ignore" situation.

 - Craig


>

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Thomas Goirand]

On 10/14/19 3:54 PM, Sandro Tosi wrote:
>>> But in both cases, it's going to take a very long time. Do we really
>>> want to get stuck on these packages for like forever, or would it feel
>>> ok to raise the severity to serious, so that the package gets
>>> auto-removed and then we can work on removing Python 2 from its
>>> dependencies?
>>
>> for me it's perfectly fine to rise severity to serious of all leaf packages 
>> with py2remove bug as soon as possible. And let's do it "automatically" 
>> everytime any package gets leaf state.
> 
> i think it's a bit premature to raise severity to RC (we should also
> check with the release team): these bugs have been opened since just 2
> months and a half, and the development cycle for bullseye started not
> longer before. there's still a lot of time.

It's not as if it has been 10 years we know about this transition, right? :)

How many months do you want to add? Do you seriously think it's going to
significantly change something about an eventual situation where
upstream hasn't done the work? If upstream did the work, then what's
blocking us?

If we see a package where upstream has Py3 support, we don't need to
raise the severity, we can just do the work instead.

> (and removing a py2
> package from a leaf pkg takes 5 minutes, usually, so if everyone in
> this thread had done that instead of writing an email, we'd be down 5
> bugs already :D )

I probably have done hundreds of them already. And I do not agree that
it takes just 5 minutes. For a trivial leaf package, probably, but when
you're trying to fix a long chain of dependencies, it can sometimes be a
non-trivial work. Going from the leaf package and rewinding can
sometimes lead to mistakes.

> I think it's also extremely premature (and just a bad idea in general)
> to consider breakage of reverse dependencies but just dropping py2
> packages. the Release Team is extremely unhappy with this approach for
> dealing with the py2removal bugs, so let's not even consider that
> option.

Yes. Which is why we should raise severity of bugs to RC, and probably
even remove packages if we need to. Otherwise, this process will take
forever (ie: longer than a Debian release cycle).

Thomas Goirand (zigo)

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Thomas Goirand]

On 10/14/19 11:05 PM, Craig Small wrote:
> Hi All,
>   Just be careful with the bugs severity on complicated packages. I
> totally get the python only packages that produce a single binary, go
> for it for those.
> 
> However consider the net-snmp python module. It's python 2 only and
> upstream isn't changing it. In fact I am pretty sure they don't support it.
> 
> So get rid of it right? Yes, except that I cannot get a new version of
> net-snmp into the archive due to a perl module bug.

Hi Craig,

Either we don't have enough details about net-snmp, or you're trying to
push for not-valid-yet-another-exception.

Could you explain exactly what this perl module bug is? How is this
related to a Python package? Why would we make an exception with
net-snmp? Please re-read the excellent contribution from Neil Williams
in this thread, and explain again why we have a special case... :)

Thomas

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Craig Small]

Hi All,
  Just be careful with the bugs severity on complicated packages. I totally
get the python only packages that produce a single binary, go for it for
those.

However consider the net-snmp python module. It's python 2 only and
upstream isn't changing it. In fact I am pretty sure they don't support it.

So get rid of it right? Yes, except that I cannot get a new version of
net-snmp into the archive due to a perl module bug.

So while I agree on the general approach, just look out for those multiple
binary type packages.

 - Craig

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Neil Williams]

On Mon, 14 Oct 2019 20:22:40 +0200
Gregor Riepl  wrote:

> Oh, and by the way, I just saw this:
> https://github.com/kovidgoyal/calibre/blob/master/README.python3
> 
> Perhaps a working Py3 port is not so far off after all.
> 

Then it can be introduced as a new upload when it is ready.

It's not ready for release from upstream yet, so it doesn't affect the
decision to raise an RC bug against calibre in current testing.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpbb7BZVbZZO.pgp
Description: OpenPGP digital signature

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Neil Williams]

On Mon, 14 Oct 2019 20:18:10 +0200
Gregor Riepl  wrote:

> > As of now, calibre is not of sufficient quality to be part of a
> > Debian release and until it drops all Python2 requirements, it must
> > be considered RC buggy.  
> 
> Is your quality argument based on the Calibre author's shenanigans?
> https://www.reddit.com/r/linux/comments/9wodtq/calibre_wont_migrate_to_python_3_author_says_i_am/

No. It is based just on the removal of Python2 from Debian and
avoiding special cases. Right now, any and every package in Debian
testing which requires Python2 and has no Python3 alternative in
Debian or ready for upload is of poor quality for no other reason than
that. All such packages are of such poor quality that the package should
be removed from testing - in an orderly manner, leaf packages first.
That is in the best interests of all users, despite what may or may not
happen to any particular subset(s) of users.

The decision flow is easy - if the answer in each case is "no", then
move on to the next and if you get to the bottom, the bug should be RC.

* Has the package already been removed from testing?
* Is a Python3-only version already in Debian?
* Is a Python3-only version available upstream?
* Does the package have any reverse dependencies?
* If you get here, it is already too late, there have already been
  enough warnings. Upgrade the bug to RC and get the package
  auto-removed from testing.

Step and repeat to get to the next packages in the dependency chain.

No special pleading. No whining. No excuses.

No buts and no exceptions. No "middle ground".

Get the packages which have done the work into Debian testing to get us
a clean Python3 package list ready for the next release.

Volunteer time is our most precious resource and it cannot be wasted on
packages which fail to meet release criteria. Requiring Python2 is RC
buggy - simple as that. The only manageable way to implement that is to
make all leaf packages RC, step and repeat down the chain until this
enormous task is complete.

Python2 removal is a huge task and I'm only too aware that I don't have
the free time now to do much to actually help it. This is the only way
to get the removal done and get to the next Debian release - which
after all, is the purpose of the testing suite in Debian.

I'm aware of the history of calibre but I really don't care about what
happens to calibre per se. I just care that calibre is not a special
case that ends up blocking fixes to it's dependencies. For example, if
any one of the current Python2 dependencies of calibre is able to drop
Python2 support and calibre is the only reverse dependency then
nothing about the upload removing Python2 support from the dependency
should be prevented just because it's used by calibre as opposed to any
other random Python2 leaf package. To do that, calibre should be
removed from testing as soon as it is clear that a Python3 version of
calibre is not available and BEFORE a Python3 version of any one of
it's dependencies gets delayed.

None of the arguments about users going to other sources apply. This
isn't about removing calibre from unstable - only from testing. That's
what raising the severity means - autoremoval, not RM. Even if the
package was removed from unstable, it's still in Buster and can be
installed from there. If that's not good enough then, sorry - I really
don't care.

The calibre package - as it exists currently in Debian testing - is not
of sufficient quality to remain in Debian testing and should be
removed as soon as is practical. As it is a leaf package, that should
be now, there is no benefit to Debian in any further delay.

Precisely the same applies to tftpy and vland and a range of others
which I personally care about much more than I care about calibre. Many
of those other packages have already been removed from testing and that
was the correct step to take for all the right reasons.

None of the above relates specifically to calibre either. Any other
package in the same position can be substituted without any change in
the correctness of the result.

> 
> And in particular: https://bugs.launchpad.net/calibre/+bug/1714107
> 
> One thing to consider here is the relatively large user base of
> Calibre that doesn't know much or care about the Python 2
> deprecation. They will simply perceive dropping Calibre as a bad move
> on Debian's side and rush towards other packages of significantly
> lower quality. PPAs, Snap and the like do more harm than keeping
> compatibility in some way for the time being.

Raising the severity of the bug doesn't change any of this.
 
> While I agree that Debian should not put up with stubborn developers,
> I also don't agree that end users should take the fall for Debian
> maintainer's decisions.
> 
> Perhaps a middle ground has to be found until a viable Py3 fork of
> Calibre is available, or someone steps up and writes Py3
> compatibility patches without dropping Py2 support? This here seems
> like a good starting to 

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Gregor Riepl]

Oh, and by the way, I just saw this:
https://github.com/kovidgoyal/calibre/blob/master/README.python3

Perhaps a working Py3 port is not so far off after all.

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Gregor Riepl]

> As of now, calibre is not of sufficient quality to be part of a Debian release
> and until it drops all Python2 requirements, it must be considered RC buggy.

Is your quality argument based on the Calibre author's shenanigans?
https://www.reddit.com/r/linux/comments/9wodtq/calibre_wont_migrate_to_python_3_author_says_i_am/

And in particular: https://bugs.launchpad.net/calibre/+bug/1714107

One thing to consider here is the relatively large user base of Calibre that
doesn't know much or care about the Python 2 deprecation. They will simply
perceive dropping Calibre as a bad move on Debian's side and rush towards
other packages of significantly lower quality. PPAs, Snap and the like do more
harm than keeping compatibility in some way for the time being.

While I agree that Debian should not put up with stubborn developers, I also
don't agree that end users should take the fall for Debian maintainer's 
decisions.

Perhaps a middle ground has to be found until a viable Py3 fork of Calibre is
available, or someone steps up and writes Py3 compatibility patches without
dropping Py2 support? This here seems like a good starting to achieve what
Calibre's author wants:
https://github.com/plone/Products.CMFPlone/issues/2184#issuecomment-359445243

Though, in the long run, somebody will have to convince Kovid that writing Py3
code is worthwhile... Or take over maintenance.

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Andrey Rahmatullin]

On Mon, Oct 14, 2019 at 09:54:18AM -0400, Sandro Tosi wrote:
> i think it's a bit premature to raise severity to RC (we should also
> check with the release team): these bugs have been opened since just 2
> months and a half, and the development cycle for bullseye started not
> longer before. there's still a lot of time. (and removing a py2
> package from a leaf pkg takes 5 minutes, usually, so if everyone in
> this thread had done that instead of writing an email, we'd be down 5
> bugs already :D )
> 
> I think it's also extremely premature (and just a bad idea in general)
> to consider breakage of reverse dependencies but just dropping py2
> packages. the Release Team is extremely unhappy with this approach for
> dealing with the py2removal bugs, so let's not even consider that
> option.

I agree with this.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Sandro Tosi]

>> But in both cases, it's going to take a very long time. Do we really
>> want to get stuck on these packages for like forever, or would it feel
>> ok to raise the severity to serious, so that the package gets
>> auto-removed and then we can work on removing Python 2 from its
>> dependencies?
>
> for me it's perfectly fine to rise severity to serious of all leaf packages 
> with py2remove bug as soon as possible. And let's do it "automatically" 
> everytime any package gets leaf state.

i think it's a bit premature to raise severity to RC (we should also
check with the release team): these bugs have been opened since just 2
months and a half, and the development cycle for bullseye started not
longer before. there's still a lot of time. (and removing a py2
package from a leaf pkg takes 5 minutes, usually, so if everyone in
this thread had done that instead of writing an email, we'd be down 5
bugs already :D )

I think it's also extremely premature (and just a bad idea in general)
to consider breakage of reverse dependencies but just dropping py2
packages. the Release Team is extremely unhappy with this approach for
dealing with the py2removal bugs, so let's not even consider that
option.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Ondrej Novy]

Hi,

po 14. 10. 2019 v 4:52 odesílatel Thomas Goirand  napsal:

> But in both cases, it's going to take a very long time. Do we really
> want to get stuck on these packages for like forever, or would it feel
> ok to raise the severity to serious, so that the package gets
> auto-removed and then we can work on removing Python 2 from its
> dependencies?
>

for me it's perfectly fine to rise severity to serious of all leaf packages
with py2remove bug as soon as possible. And let's do it "automatically"
everytime any package gets leaf state.

But to do this correctly, we need release goal. Do we have one?

-- 
Best regards
 Ondřej Nový

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Neil Williams]

On Sun, Oct 13, 2019 at 11:41:38PM -0400, Nicholas D Steeves wrote:
> Hi Thomas and Python Team,
> 
> Thomas Goirand  writes:
> 
> > For example, today I looked into removing Python 2 from python-cogent.
> > Running sixer on all files lead to a huge log of problems to solve by
> > hand. There's no upstream support for Python 3 on that one.
> >
> > For this kind of package, I see no way out except:
> > - Upstream works on Python 3 support
> > - Someone in Debian makes the effort
> >
> > But in both cases, it's going to take a very long time. Do we really
> > want to get stuck on these packages for like forever, or would it feel
> > ok to raise the severity to serious, so that the package gets
> > auto-removed and then we can work on removing Python 2 from its
> > dependencies?
> 
> It seems to me that a fair and conservative solution is to send an
> announcement once a month that all Python 2 packages will have an RC bug
> filed against them on 1 January 2020.  I work on the Calibre package,
> and depend on it for my daily work.  I do not believe that its reverse
> deps should be removed before 1 Jan 2020.

That doesn't mean that the rest of Debian should be held up by your personal 
usage.
It is trivial for you to arrange a local build and even a local repo to meet 
your
local needs. The package does not need to be in the archive blocking other 
people's
work just because you personally need it. Calibre is not a special case. If that
logic was applied everywhere, nothing would ever get done. It's a shame, for me,
that lava and associated packages have already been removed from testing as I
used to work on those. I changed jobs, changed workspace and no longer have
time to get the remaining (small) issues fixed to keep the packages in testing
and the remaining team have made their own choices on how to publish new 
releases
due to the reduced team size.

I could make the same argument as you about tftpy but I've put my personal 
situation
into the bug report and if I don't get time to fix it, then tftpy will need to
be removed from testing.

There have been enough conservative notifications and announcements about 
Python2
from every organisation with even the most remote connection to Python. 

I think all Python2 bugs should be escalated to RC to have automatic removal 
from
unstable and testing at the earliest opportunity.

As of now, calibre is not of sufficient quality to be part of a Debian release
and until it drops all Python2 requirements, it must be considered RC buggy.

Accept that there has already been enough time for announcements, put the
current status - as you see it - into the bug report and raise the severity
to RC yourself. That's my recommendation for Calibre and all the other
leaf packages with any dependency on Python2.

There has already been enough time for delay.
 
> As far as the maximum number of announcements, how about: the first
> announcement ASAP, the second one 1 Nov, then 1 Dec.  Lets CC this
> announcement to devel, -python, -med, and any other teams with a
> significant number of Python packages.
> 
> The issue is similar to global warming.  People will hide their head in
> the sand singing "nah nah nah, it's not real, I don't have to deal with
> it" until a tipping point occurs.

That tipping point has already been reached. The Python2 removal transition
is in full flow and has been since DebConf. No more delays.

> 
> Honestly part of me wonders if RedHat/IBM is going to maintain Python 2,
> like they did with Java.
> 
>   
> https://developers.redhat.com/blog/2018/09/24/the-future-of-java-and-openjdk-updates-without-oracle-support
> 
> Barring that hypothetical possibility, I still think the right thing to
> do is file RC bugs the 1 of January.  What happens then?  My guess is
> upstreams start containerising their py2 software and someone will write
> a helper script like py2-zombie-flatpack.
> 
> 
> Cheers,
> Nicholas

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Scott Kitterman]

On Sunday, October 13, 2019 10:52:17 PM EDT Thomas Goirand wrote:
> Hi,
> 
> In some cases I've seen, particularly in the med or science team,
> switching some packages to Python 3 requires a significant effort.
> 
> For example, today I looked into removing Python 2 from python-cogent.
> Running sixer on all files lead to a huge log of problems to solve by
> hand. There's no upstream support for Python 3 on that one.
> 
> For this kind of package, I see no way out except:
> - Upstream works on Python 3 support
> - Someone in Debian makes the effort
> 
> But in both cases, it's going to take a very long time. Do we really
> want to get stuck on these packages for like forever, or would it feel
> ok to raise the severity to serious, so that the package gets
> auto-removed and then we can work on removing Python 2 from its
> dependencies?

There are two python2 only packages that I maintain.  I don't intend to keep 
them in bullseye, so I filed "should not be in bullseye" RC bugs against them.  
They and their rdepends will be out of Testing shortly. 

If you are the maintainer of a package, I think that's something that doesn't 
need to wait.

In the case of things that aren't ported to python3 yet they are mostly dead 
upstream.  For the dead ones, I don't think anyone in Debian should port them 
unless they are willing to take over as upstream (I've done this in a few 
cases).  If there's no upstream, they ought to just be removed.  The sooner 
the better.

Scott K

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Nicholas D Steeves]

Hi Thomas and Python Team,

Thomas Goirand  writes:

> For example, today I looked into removing Python 2 from python-cogent.
> Running sixer on all files lead to a huge log of problems to solve by
> hand. There's no upstream support for Python 3 on that one.
>
> For this kind of package, I see no way out except:
> - Upstream works on Python 3 support
> - Someone in Debian makes the effort
>
> But in both cases, it's going to take a very long time. Do we really
> want to get stuck on these packages for like forever, or would it feel
> ok to raise the severity to serious, so that the package gets
> auto-removed and then we can work on removing Python 2 from its
> dependencies?

It seems to me that a fair and conservative solution is to send an
announcement once a month that all Python 2 packages will have an RC bug
filed against them on 1 January 2020.  I work on the Calibre package,
and depend on it for my daily work.  I do not believe that its reverse
deps should be removed before 1 Jan 2020.

As far as the maximum number of announcements, how about: the first
announcement ASAP, the second one 1 Nov, then 1 Dec.  Lets CC this
announcement to devel, -python, -med, and any other teams with a
significant number of Python packages.

The issue is similar to global warming.  People will hide their head in
the sand singing "nah nah nah, it's not real, I don't have to deal with
it" until a tipping point occurs.

Honestly part of me wonders if RedHat/IBM is going to maintain Python 2,
like they did with Java.

  
https://developers.redhat.com/blog/2018/09/24/the-future-of-java-and-openjdk-updates-without-oracle-support

Barring that hypothetical possibility, I still think the right thing to
do is file RC bugs the 1 of January.  What happens then?  My guess is
upstreams start containerising their py2 software and someone will write
a helper script like py2-zombie-flatpack.


Cheers,
Nicholas


signature.asc
Description: PGP signature

Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Thomas Goirand]

Hi,

In some cases I've seen, particularly in the med or science team,
switching some packages to Python 3 requires a significant effort.

For example, today I looked into removing Python 2 from python-cogent.
Running sixer on all files lead to a huge log of problems to solve by
hand. There's no upstream support for Python 3 on that one.

For this kind of package, I see no way out except:
- Upstream works on Python 3 support
- Someone in Debian makes the effort

But in both cases, it's going to take a very long time. Do we really
want to get stuck on these packages for like forever, or would it feel
ok to raise the severity to serious, so that the package gets
auto-removed and then we can work on removing Python 2 from its
dependencies?

Cheers,

Thomas Goirand (zigo)