Re: Investigating the reverse dependencies of python-monotonic.
Thank you! I just uploaded oz with python 3 dependencies. If any python Debian packager want to take a look and suggest improvements that would be great, as I’m mostly guessing how to package python apps in Debian. /Simon > 14 aug. 2019 kl. 09:20 skrev Thomas Goirand : > >> On 8/13/19 9:58 PM, Simon Josefsson wrote: >> Once python3-m2crypto is in Debian, I will port oz to python3. >> >> /Simon > > Well, it's in unstable already... > > Thomas Goirand (zigo)
Re: Investigating the reverse dependencies of python-monotonic.
On 8/13/19 9:58 PM, Simon Josefsson wrote: > Once python3-m2crypto is in Debian, I will port oz to python3. > > /Simon Well, it's in unstable already... Thomas Goirand (zigo)
Re: Investigating the reverse dependencies of python-monotonic.
Once python3-m2crypto is in Debian, I will port oz to python3. /Simon > 13 aug. 2019 kl. 21:46 skrev Thomas Goirand : > >> On 8/13/19 12:38 PM, peter green wrote: >> Hi >> >> I've been looking at various python 2 cruft packages (packages no longer >> built by the corresponding source packages) and why they can't be >> cleaned up, I have been looking in a derivative but many of my results >> are also relevant to debian proper. Where relevant I have been filing >> bugs against the reverse-dependencies of these cruft packages, so they >> can be fixed or ultimately removed. >> >> Most such packages have been part of upstream projects that have dropped >> python 2 support, notablly django and openstack. In such cases it is >> pretty clear that the only reasonable way forward is for the reverse >> dependencies to be either removed or migrated to python 3. >> >> One package that stood out from the rest was python-monotonic. >> python-monotonic is maintained by the Debian openstack team, but it >> doesn't seem to be in any way openstack specific, nor does upstream seem >> to have dropped python2 support. It seemed to have a fair few reverse >> dependencies. >> >> python-humanfriendly (has rdeps) >> oz (rc bug filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933509 ) >> python-fasteners (has rdeps) >> python-futurist (has rdeps, cruft) >> python-octaviaclient (assumed to be openstack related) >> python-oslo.log (assumed to be openstack related) >> python-oslo.messaging (assumed to be openstack related) >> python-oslo.service (assumed to be openstack related) >> python-oslo.utils (assumed to be openstack related) >> python-tenacity (has rdeps, cruft) >> >> There are also indirect reverse dependencies, (i'm not investigating >> reverse dependencies of packages that are clearly openstack specific here) >> >> python-coloredlogs (via python-humanfriendly, no reverse dependencies) >> python-datalad (via python-fasteners, no reverse dependencies) >> duplicity (via python-fasteners) >> python-oauth2client (via python-fasteners) >> python-oslo.concurrency (via python-fastners, openstack related) >> python-taskflow (via python-fasteners, cruft) >> python-tooz (via python-fasteners, openstack related, cruft) >> python-googleapi (via python-oauth2client) >> python-pypowervm (via python-taskflow, openstack related, cruft) >> python-googleapi-samples (via python-googleapi) >> python-etcd3gw (no rdeps) >> python-gnocchiclient (openstack related, cruft) >> >> If we ignore openstack stuff, python modules and an examples package the >> two main packages left seem to be oz and duplicity, oz seems to have >> very low popcon, but duplicity seems to have a popcon of around 3000 and >> growing. >> >> So the main question seems to be can duplicity be reasonably migrated to >> python 3 and if not is it worth reinstating the python-monotonic binary >> package to save duplicity? > > What happened is that I simply uploaded the latest version of OpenStack > from Experimental to Sid. This includes monotonic. It's been a long time > I maintain monotonic because it's used in OpenStack, then other packages > started using it. You may have noticed that it was in Experimental with > Python 2 removed for at least 6 months, just like for Django, giving the > sign that Py2 would soon go away. However, maybe bugs should have been > filled, sorry that I didn't do it in time. > > Let's take a look at the situation. > > As per Andrey's reply, we can fix duplicity. > > From your report above, if I remove all the OpenStack stuff (which at > this time, should all be only Python 3), the only affected packages > would be: > >> python-humanfriendly (has rdeps) >> oz (rc bug filed #933509) >> python-coloredlogs (via python-humanfriendly, no reverse dependencies) >> python-datalad (via python-fasteners, no reverse dependencies) >> duplicity (via python-fasteners) >> python-oauth2client (via python-fasteners) >> python-googleapi-samples (via python-googleapi) > > According to the setup.py of python-googleapi in the Github repo, latest > upstream version supports Python 3, so it should be doable to upload a > new version to fix this. > > I will remove Python 2 suport from python-oauth2client and > python-fasteners tomorrow. > > So, this leaves us only: humanfriendly, oz, python-coloredlogs, > python-datalad. I've uploaded humanfriendly and coloredlogs Py2 removal. > BTW, I believe python-coloredlogs was there as a build-depends of > cyvcf2, which has been fixed on the 1st of august by Andreas Tille. > > By all means, let's not play the dance of re-introducting Python 2 when > we can move forward on the right direction. > > Thanks for taking the time to investigate this, this is very useful, and > I have to admit that, even though I know how to do the work, I am a bit > lost into knowing from were to begin. The release tracker is not very > helpful in this regard. > > Cheers, > > Thomas Goirand (zigo)
Re: Investigating the reverse dependencies of python-monotonic.
On 8/13/19 3:30 PM, peter green wrote: > IMO python-monotonic should be reinstated until it's reverse > dependencies are sorted out. There's now only oz, googleapi and duplicity. The last 2 both have Py3 support upstream in a newer version. Let's fix these, as I fixed all the rest already. If nobody does the work for googleapi and duplicity, ping me and I'll do it. While I do agree it's preferable to do things in order, without breaking things, I very much prefer if we move forward, toward removing Py2, rather than backward. Thomas
Re: Investigating the reverse dependencies of python-monotonic.
On 8/13/19 12:38 PM, peter green wrote: > python-fasteners (has rdeps) > python-oauth2client (via python-fasteners) FYI, I removed Python 2 support from these 2 today! :) Hopefully, Laszlo Boszormenyi (GCS) will do the work for googleapi, and then we'll get another chain of Py2 removed. :) Thomas
Re: Investigating the reverse dependencies of python-monotonic.
On 8/13/19 12:38 PM, peter green wrote: > Hi > > I've been looking at various python 2 cruft packages (packages no longer > built by the corresponding source packages) and why they can't be > cleaned up, I have been looking in a derivative but many of my results > are also relevant to debian proper. Where relevant I have been filing > bugs against the reverse-dependencies of these cruft packages, so they > can be fixed or ultimately removed. > > Most such packages have been part of upstream projects that have dropped > python 2 support, notablly django and openstack. In such cases it is > pretty clear that the only reasonable way forward is for the reverse > dependencies to be either removed or migrated to python 3. > > One package that stood out from the rest was python-monotonic. > python-monotonic is maintained by the Debian openstack team, but it > doesn't seem to be in any way openstack specific, nor does upstream seem > to have dropped python2 support. It seemed to have a fair few reverse > dependencies. > > python-humanfriendly (has rdeps) > oz (rc bug filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933509 ) > python-fasteners (has rdeps) > python-futurist (has rdeps, cruft) > python-octaviaclient (assumed to be openstack related) > python-oslo.log (assumed to be openstack related) > python-oslo.messaging (assumed to be openstack related) > python-oslo.service (assumed to be openstack related) > python-oslo.utils (assumed to be openstack related) > python-tenacity (has rdeps, cruft) > > There are also indirect reverse dependencies, (i'm not investigating > reverse dependencies of packages that are clearly openstack specific here) > > python-coloredlogs (via python-humanfriendly, no reverse dependencies) > python-datalad (via python-fasteners, no reverse dependencies) > duplicity (via python-fasteners) > python-oauth2client (via python-fasteners) > python-oslo.concurrency (via python-fastners, openstack related) > python-taskflow (via python-fasteners, cruft) > python-tooz (via python-fasteners, openstack related, cruft) > python-googleapi (via python-oauth2client) > python-pypowervm (via python-taskflow, openstack related, cruft) > python-googleapi-samples (via python-googleapi) > python-etcd3gw (no rdeps) > python-gnocchiclient (openstack related, cruft) > > If we ignore openstack stuff, python modules and an examples package the > two main packages left seem to be oz and duplicity, oz seems to have > very low popcon, but duplicity seems to have a popcon of around 3000 and > growing. > > So the main question seems to be can duplicity be reasonably migrated to > python 3 and if not is it worth reinstating the python-monotonic binary > package to save duplicity? What happened is that I simply uploaded the latest version of OpenStack from Experimental to Sid. This includes monotonic. It's been a long time I maintain monotonic because it's used in OpenStack, then other packages started using it. You may have noticed that it was in Experimental with Python 2 removed for at least 6 months, just like for Django, giving the sign that Py2 would soon go away. However, maybe bugs should have been filled, sorry that I didn't do it in time. Let's take a look at the situation. As per Andrey's reply, we can fix duplicity. >From your report above, if I remove all the OpenStack stuff (which at this time, should all be only Python 3), the only affected packages would be: > python-humanfriendly (has rdeps) > oz (rc bug filed #933509) > python-coloredlogs (via python-humanfriendly, no reverse dependencies) > python-datalad (via python-fasteners, no reverse dependencies) > duplicity (via python-fasteners) > python-oauth2client (via python-fasteners) > python-googleapi-samples (via python-googleapi) According to the setup.py of python-googleapi in the Github repo, latest upstream version supports Python 3, so it should be doable to upload a new version to fix this. I will remove Python 2 suport from python-oauth2client and python-fasteners tomorrow. So, this leaves us only: humanfriendly, oz, python-coloredlogs, python-datalad. I've uploaded humanfriendly and coloredlogs Py2 removal. BTW, I believe python-coloredlogs was there as a build-depends of cyvcf2, which has been fixed on the 1st of august by Andreas Tille. By all means, let's not play the dance of re-introducting Python 2 when we can move forward on the right direction. Thanks for taking the time to investigate this, this is very useful, and I have to admit that, even though I know how to do the work, I am a bit lost into knowing from were to begin. The release tracker is not very helpful in this regard. Cheers, Thomas Goirand (zigo)
Re: Investigating the reverse dependencies of python-monotonic.
On 13.08.19 15:30, peter green wrote: > IMO python-monotonic should be reinstated until it's reverse dependencies are > sorted out. I agree with that.
Re: Investigating the reverse dependencies of python-monotonic.
(note for people reading on bug 934333, the start of this thread can be found at https://lists.debian.org/debian-python/2019/08/msg00070.html ) On 13/08/2019 11:54, Andrey Rahmatullin wrote: This is worrying, a package with revdeps shouldn't have been dropped. AIUI a "go cleanly" approach was agreed at the Python BoF, but by that time an aggressive removal process was already well underway for django and openstack related packages. By the way, you checked only deps, not build-deps, as at least python-coloredlogs and python-datalad has reverse build-deps. I took a look at the build-rdeps, also this time I used unstable whereas my previous analysis had been looking at buster (yeah, this made little sense, I was probablly meaning to use bullseye but mixed the words up in my head, not that I think it made any difference). Again i'm not investigating openstack related stuff. This seems to add a few more packages to our set python-jira (via python-tenacity) cyvcf2 (via python-coloredlogs, sid version has dropped the python2 stuff, but it's blocked from having old versions cleaned up and migrating to testing by build failures on mips*) heudiconv (via python-datalad, sid only, never been in testing or a stable release, WTF was someone doing uploading a new python2 only package in 2019?!) python-googlecloudapis (via python-oauth2client, sid only) python-google-auth(via python-oauth2client, sid only) rekall(via python-oauth2client) python-oslo.cache (via python-etcd3gw, openstack related) elastalert (via python-jira, also depends on python-croniter) I've also noted https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934333 ccing this mail there. As for duplicity, the latest upstream version (not packaged) support Python 3. There is a bug report for it, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929949 In a response to bug 934333 Ondrej Novy wrote: just my two cents: correct solution is to add Python 3.x support to python-m2crypto and migrate oz to Python 3. I agree that is the correct long term soloution, however as mentioned in this mail and in https://lists.debian.org/debian-python/2019/08/msg00070.html it's not just oz that is involved here. Reintroduction Python2 support to python-monotonic is not good idea, we are going to drop Python 2 completly from Debian. I understand that dropping python 2 is the goal, but my understanding of https://lists.debian.org/debian-python/2019/07/msg00069.html and https://lists.debian.org/debian-python/2019/07/msg00080.html is the plan was to do it cleanly, starting with leaf stuff and working down the dependency stack. IMO python-monotonic should be reinstated until it's reverse dependencies are sorted out.
Re: Investigating the reverse dependencies of python-monotonic.
On Tue, Aug 13, 2019 at 11:38:33AM +0100, peter green wrote: > One package that stood out from the rest was python-monotonic. > python-monotonic is maintained by the Debian openstack team, but it doesn't > seem to be in any way openstack specific, nor does upstream seem to have > dropped python2 support. It seemed to have a fair few reverse dependencies. > > python-humanfriendly (has rdeps) > oz (rc bug filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933509 ) > python-fasteners (has rdeps) > python-futurist (has rdeps, cruft) > python-octaviaclient (assumed to be openstack related) > python-oslo.log (assumed to be openstack related) > python-oslo.messaging (assumed to be openstack related) > python-oslo.service (assumed to be openstack related) > python-oslo.utils (assumed to be openstack related) > python-tenacity (has rdeps, cruft) > > There are also indirect reverse dependencies, (i'm not investigating reverse > dependencies of packages that are clearly openstack specific here) > > python-coloredlogs (via python-humanfriendly, no reverse dependencies) > python-datalad (via python-fasteners, no reverse dependencies) > duplicity (via python-fasteners) > python-oauth2client (via python-fasteners) > python-oslo.concurrency (via python-fastners, openstack related) > python-taskflow (via python-fasteners, cruft) > python-tooz (via python-fasteners, openstack related, cruft) > python-googleapi (via python-oauth2client) > python-pypowervm (via python-taskflow, openstack related, cruft) > python-googleapi-samples (via python-googleapi) > python-etcd3gw (no rdeps) > python-gnocchiclient (openstack related, cruft) > > If we ignore openstack stuff, python modules and an examples package the two > main packages left seem to be oz and duplicity, oz seems to have very low > popcon, but duplicity seems to have a popcon of around 3000 and growing. > > So the main question seems to be can duplicity be reasonably migrated to > python 3 and if not is it worth reinstating the python-monotonic binary > package to save duplicity? This is worrying, a package with revdeps shouldn't have been dropped. By the way, you checked only deps, not build-deps, as at least python-coloredlogs and python-datalad has reverse build-deps. I've also noted https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934333 As for duplicity, the latest upstream version (not packaged) support Python 3. -- WBR, wRAR signature.asc Description: PGP signature
