Re: Investigating the reverse dependencies of python-monotonic.

2019-08-13 Thread Simon Josefsson
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.

2019-08-13 Thread Thomas Goirand
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.

2019-08-13 Thread Thomas Goirand
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.

2019-08-13 Thread 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: Please help fix pydoctor

2019-08-13 Thread Guido Günther
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: Side effect of dropping python2 with -doc packages

2019-08-13 Thread Andrey Rahmatullin
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: Side effect of dropping python2 with -doc packages

2019-08-13 Thread Joseph Herlant
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

2019-08-13 Thread Andrey Rahmatullin
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: Investigating the reverse dependencies of python-monotonic.

2019-08-13 Thread Matthias Klose
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.

2019-08-13 Thread peter green

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

2019-08-13 Thread Andrey Rahmatullin
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


Investigating the reverse dependencies of python-monotonic.

2019-08-13 Thread peter green

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: Joining Python Modules Team

2019-08-13 Thread Ondrej Novy
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ý


Bug#934667: RFP: aioftp -- ftp client/server library for Python asyncio

2019-08-13 Thread Helmut Grohne
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