Bug#934667: RFP: aioftp -- ftp client/server library for Python asyncio
Package: wnpp Severity: wishlist Tags: patch * Package name: python-aioftp Version : 0.10.1 Upstream Author : pohmelie * URL : https://github.com/aio-libs/aioftp * License : Apache-2.0 Programming Lang: Python Description : ftp client/server library for Python asyncio python-aioftp is a module for using a ftp client or server together with asyncio. If asyncio is not required, pyftpdlib should be considered as an alternative and is already packaged in Debian. This library can complement parfive, which is being packaged for Debian (see #929438). It can be used independently of course. There is not currently an asyncio ftp server in Debian. The library is very simple and does not have any runtime dependencies outside the standard library. I'm also attaching the debian tree for aioftp-0.10.1.tar.gz as obtained from pypi. Likely, the package should be maintained in the DPMT. Helmut python-aioftp_0.10.1-1.debian.tar.xz Description: application/xz
Re: Joining Python Modules Team
Hi, po 12. 8. 2019 v 23:19 odesílatel Moritz Mühlenhoff napsal: > Sure, I've read the policy and acking it, my Salsa login is "jmm". > welcome :) -- Best regards Ondřej Nový
Investigating the reverse dependencies of python-monotonic.
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?
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
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 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.
Side effect of dropping python2 with -doc packages
Hi guys, While tidying up some packages before taking some time off I realized that some packages like django-tables had binary packages that took the convention of creating -doc packages using -doc (a very long time ago). The result was the location of the doc changed from /usr/share/doc/python-django-tables2-doc to /usr/share/doc/python-django-tables2 with the bump to compat 11. But now that we dropped the python2 binary package we end up with the "main package" not being detected anymore and the doc moved back to /usr/share/doc/python-django-tables2-doc. The way I read the policy, it seems the -doc package should be -doc. Am I correct to read it this way? (it's not specified that it's binary but not source package either so I just want to make sure I get it right) I see several possibilities on how to handle that: * leave it as is and it's fine (but doesn't match Policy 12.3) * overwrite dh_installdocs to pass --doc-main-package * rename the -docs package to match -doc and have the ftp-master rm the old one * have dh_installdocs translate python into python3 package names when looking for the main package Which one do you think would be preferable? (I know there are multiple python package in this case so it would be interesting to have a consensus on how to handle it) Other preferable solutions? Thanks for your help, Joseph
Re: Side effect of dropping python2 with -doc packages
On Tue, Aug 13, 2019 at 10:16:28AM -0700, Joseph Herlant wrote: > While tidying up some packages before taking some time off I realized > that some packages like django-tables had binary packages that took > the convention of creating -doc packages using -doc (a > very long time ago). > > The result was the location of the doc changed from > /usr/share/doc/python-django-tables2-doc to > /usr/share/doc/python-django-tables2 with the bump to compat 11. > > But now that we dropped the python2 binary package we end up with the > "main package" not being detected anymore and the doc moved back to > /usr/share/doc/python-django-tables2-doc. Yes, this is the third email on this in the last month, previous two didn't get any replies. > The way I read the policy, it seems the -doc package should be package name>-doc. Am I correct to read it this way? I don't think 12.3 mentions source packages or describes what to do when there are multiple main subpackages. > I see several possibilities on how to handle that: > * leave it as is and it's fine (but doesn't match Policy 12.3) > * overwrite dh_installdocs to pass --doc-main-package > * rename the -docs package to match -doc and have the > ftp-master rm the old one > * have dh_installdocs translate python into python3 package names > when looking for the main package Note that there are two questions here, about the package name and about the file path. For the first question the answer is in https://lists.debian.org/debian-python/2019/07/msg00080.html: "Please keep the python-foo-doc package. Do not rename it to python3-foo-doc. If python-foo was providing documentation: move it to python3-foo or create python-foo-doc (not python3-foo-doc!) binary package." For the second question, I'm keeping the things as is if the docs are installed into /python-foo-doc/ and change /python-foo/ to /python3-foo/ otherwise. I'm not bumping the compat level so no /python-foo-doc/ to /python-foo/ changes occur. -- WBR, wRAR signature.asc Description: PGP signature
Re: Side effect of dropping python2 with -doc packages
Hi Andrey, Thanks for your reply. On Tue, Aug 13, 2019 at 10:40 AM Andrey Rahmatullin wrote: > Yes, this is the third email on this in the last month, previous two > didn't get any replies. Sorry I didn't mean to anger you or be disrespectful in any way. My apologies if I did. I was off the list for a bit (because I unsubscribed from all of them for personal reasons) and didn't find what I was looking for while searching in the archive. > I don't think 12.3 mentions source packages or describes what to do when > there are multiple main subpackages. That's what I wanted to clarify as there are mention of "package" and "binary package" I wanted to make sure that package (as not "binary package") was referring to source package. > > I see several possibilities on how to handle that: > > * leave it as is and it's fine (but doesn't match Policy 12.3) > > * overwrite dh_installdocs to pass --doc-main-package > > * rename the -docs package to match -doc and have the > > ftp-master rm the old one > > * have dh_installdocs translate python into python3 package names > > when looking for the main package > Note that there are two questions here, about the package name and about > the file path. For the first question the answer is in > https://lists.debian.org/debian-python/2019/07/msg00080.html: "Please keep > the python-foo-doc package. Do not rename it to python3-foo-doc. If > python-foo was providing documentation: move it to python3-foo or create > python-foo-doc (not python3-foo-doc!) binary package." Thanks for pointing out this one, I missed it during my research, > For the second question, I'm keeping the things as is if the docs are > installed into /python-foo-doc/ and change /python-foo/ to /python3-foo/ > otherwise. I'm not bumping the compat level so no /python-foo-doc/ to > /python-foo/ changes occur. Thanks for the explanation. Have a nice day, Joseph
Re: Side effect of dropping python2 with -doc packages
On Tue, Aug 13, 2019 at 11:05:33AM -0700, Joseph Herlant wrote: > > Yes, this is the third email on this in the last month, previous two > > didn't get any replies. > > Sorry I didn't mean to anger you or be disrespectful in any way. My > apologies if I did. I wasn't angered, the second of those was mine and I didn't notice the first one. > I was off the list for a bit (because I unsubscribed from all of them > for personal reasons) and didn't find what I was looking for while > searching in the archive. > > > I don't think 12.3 mentions source packages or describes what to do when > > there are multiple main subpackages. > > That's what I wanted to clarify as there are mention of "package" and > "binary package" I wanted to make sure that package (as not "binary > package") was referring to source package. I don't think it means the source package, and several things there suggest it's a binary one. This includes the file path clause itself, as "/usr/share/doc/package" definitely means using the binary package name. -- WBR, wRAR signature.asc Description: PGP signature
Re: Please help fix pydoctor
Hi, On Sun, Jul 28, 2019 at 02:00:56PM +0100, Ian Jackson wrote: > Hi, Python folks. > > I think help is needed regarding > > #932584 python-pydoctor: Epydoc will be removed > > It seems to be languishing rather. What I don't understand is why > pydoctor depends on epydoc given that, in the words of the > Description: > > [Pydoctor] was written primarily to replace epydoc ... > > I had a quick look through the source but I don't know enough about > pydoctor to make immediate sense of the results of my grep. Maybe > some person who knows more about pydoctor can help ? > > (I'm CCing this to the gbp maintainers because this came to my > attention due to an autoremoval bug where a package of mine has a > dependency chain via gbp.) epydoc only seems to be used for formatting and README.Debian confirms this: ...and looking at the bug it seems it was already dealt with by dropping the epydoc dependency. Thanks! -- Guido > > Thanks, > Ian. > > -- > Ian JacksonThese opinions are my own. > > If I emailed you from an address @fyvzl.net or @evade.org.uk, that is > a private address which bypasses my fierce spamfilter. >
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 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 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.
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)
