Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #11883 > unrolled thread

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

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream Nicholas D Steeves <nsteeves@gmail.com> - 2019-10-14 05:50 +0200
    Re: Raising severity to serious for some Python 2 leaf packages with  no Python 3 support upstream Neil Williams <codehelp@debian.org> - 2019-10-14 09:20 +0200
      Re: Raising severity to serious for some Python 2 leaf packages with  no Python 3 support upstream Gregor Riepl <onitake@gmail.com> - 2019-10-14 20:20 +0200
        Re: Raising severity to serious for some Python 2 leaf packages  with no Python 3 support upstream Neil Williams <codehelp@debian.org> - 2019-10-14 21:30 +0200
      Re: Raising severity to serious for some Python 2 leaf packages with  no Python 3 support upstream Gregor Riepl <onitake@gmail.com> - 2019-10-14 20:30 +0200
        Re: Raising severity to serious for some Python 2 leaf packages  with no Python 3 support upstream Neil Williams <codehelp@debian.org> - 2019-10-14 21:30 +0200
    Re: Raising severity to serious for some Python 2 leaf packages with  no Python 3 support upstream Craig Small <csmall@dropbear.xyz> - 2019-10-14 23:30 +0200
      Re: Raising severity to serious for some Python 2 leaf packages with  no Python 3 support upstream Craig Small <csmall@debian.org> - 2019-10-15 05:00 +0200
      Re: Raising severity to serious for some Python 2 leaf packages with  no Python 3 support upstream Craig Small <csmall@dropbear.xyz> - 2019-10-15 05:20 +0200
        Re: Raising severity to serious for some Python 2 leaf packages with  no Python 3 support upstream Sandro Tosi <morph@debian.org> - 2019-10-15 19:10 +0200

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

[Multipart message — attachments visible in raw view] — view raw

Hi Thomas and Python Team,

Thomas Goirand <zigo@debian.org> 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

[toc] | [next] | [standalone]

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

On Sun, Oct 13, 2019 at 11:41:38PM -0400, Nicholas D Steeves wrote:
> Hi Thomas and Python Team,
> 
> Thomas Goirand <zigo@debian.org> 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

[toc] | [prev] | [next] | [standalone]

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

> 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.

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Mon, 14 Oct 2019 20:18:10 +0200
Gregor Riepl <onitake@gmail.com> 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 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.

Again, nothing to do with raising the severity of the bug to RC.

Calibre is nothing special - it's a Python2 leaf package like vland
and tftpy and any one of far too many others. It should be removed from
testing on the basis that a Python3 version is not forthcoming and
there are dependencies which will be able to drop their Python2 support
(or be removed from Debian entirely) once calibre is no longer
considered in the rm-python2 transition due it to not being present
in testing.

Calibre can stay in unstable - it will go FTBFS, of course, but that
isn't a problem either, IMHO. It's calibre's problem - not Debian's
problem. There's always the option of users installing the old Python2
stuff from Buster to keep calibre hobbling along.

Debian is the higher priority here. Calibre would be a nice to have but
it does not deserve to cause delays on anybody else's voluntary
effort. No package has that right.

-- 


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

[toc] | [prev] | [next] | [standalone]

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

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.

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Mon, 14 Oct 2019 20:22:40 +0200
Gregor Riepl <onitake@gmail.com> 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/

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Tue, 15 Oct. 2019, 1:04 pm Thomas Goirand, <zigo@debian.org> 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


>

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Tue, 15 Oct. 2019, 1:04 pm Thomas Goirand, <zigo@debian.org> 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.

[toc] | [prev] | [next] | [standalone]

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

On Tue, Oct 15, 2019 at 12:55 PM Thomas Goirand <zigo@debian.org> wrote:
>
> On 10/15/19 5:00 AM, Craig Small wrote:
> >
> >
> > On Tue, 15 Oct. 2019, 1:04 pm Thomas Goirand, <zigo@debian.org
> > <mailto:zigo@debian.org>> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web