Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream
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
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
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
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
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
Request to (re)join the team
Hi everyone, I'd like to migrate my current membership of the debian-python DPMT and PAPT teams on salsa to use my shiny, new DD account \o/. My salsa account is nickm. Thank you for your help, guidance, mentorship and sponsored uploads so far! Cheers, Nick
Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream
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
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
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
> 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.
Bug#942327: RM: sclapp -- RoQA; orphaned; dead upstream; no Python 3 support and no reverse deps
Package: ftp.debian.org Severity: normal User: debian-python@lists.debian.org Usertags: py2removal http://www.alittletooquiet.net/software/sclapp/ is dead. The current upstream code was uploaded to Debian in 2008. Reverse deps checked with dak rm -Rnb python-sclapp -- WBR, wRAR signature.asc Description: PGP signature
Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream
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:Streamlining the use of Salsa CI on team packages
Hello, and if at the end the upstream could take care of the Debian packaging, by adding a .salsa-ci.yml in the upstream directory, in order to have a feedback with nice badges ? Cheers
Re: Streamlining the use of Salsa CI on team packages
On 9/16/19 10:03 PM, Hans-Christoph Steiner wrote: >>> I know the Ruby team also decided to use debian/salsa-ci.yml instead of >>> debian/gitlab-ci.yml [2]. I guess we should also do the same. > This is still an open question: > https://salsa.debian.org/salsa-ci-team/pipeline/issues/86 > > Debian has a bad habit of customizing things that do not need to be > customizing. That raises the barrier for contributors ever higher, in a > "death by a thousand papercuts" kind of way. I think we should stick to > the standard file name for GitLab CI. The issue is that, from a packaging standpoint, we cannot add a file if it's not in the debian folder, because this makes change to the upstream files. So, no choice... Thomas Goirand (zigo)
Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream
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
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
