Re: [Distutils] problems with sdist upload since CDN update
sorry, here's the direct branch link : http://bazaar.launchpad.net/~leo-editor-team/leo-editor/trunk3/files and nightly snapshots: http://www.greygreen.org/leo/ -matt On Fri, May 31, 2013 at 11:30 PM, Matt Wilkie map...@gmail.com wrote: Matt, is your code available online anywhere? yes: https://code.launchpad.net/leo-editor thanks for looking at this. -matt ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On Fri, May 31, 2013 at 15:18 +0200, Lennart Regebro wrote: On Fri, May 31, 2013 at 3:09 PM, holger krekel hol...@merlinux.eu wrote: I think there should be a PEP regulating the removal and the taking over process for packages. Your considerations make sense to me there. ASFAIK Perl has such policies a decade or so. Probably makes sense to use their provisions as a blue print. Such a PEP should contain a list of projects that are to be removed retro-actively if they don't comply within 6 months or so. I think the barrier shouldn't be too high, a valid email address and/or release activity are a good minimum. And it should be a short PEP :) I'd be OK with after six months automatically removing packages that has only one owner/maintainer, and that owner/maintainer has no other packages, and the package has no available downloads, and no contact information on either package nor registered user. For other cases there should also be a manual way or removing packages on the discretion of PyPI maintainers, as well as giving owner access to packages whose owner is unreachable (I think there may already exist a process for that). I'd like to argue in the same direction. While technical means to detect unmaintained or empty registrations are worthwhile to consdier i believe we should put emphasize on the human process. If you look at perl's guidelines for taking over maintenance here: http://www.cpan.org/misc/cpan-faq.html#How_adopt_module it's focused on the human communication process which i think is the right way to go about it. Any technical automated solution can probably be abused easily, given ill intentions, see the DNS for reference. A PEP should list criteria but leave decisions ultimately to a trusted board/admins which should maintain a public changelog of their actions. Those criteria should of course be automatically analyzed and used as input for the human process if possible. best, holger //Lennart ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] problems with sdist upload since CDN update
Matt, is your code available online anywhere? yes: https://code.launchpad.net/leo-editor thanks for looking at this. -matt ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] problems with sdist upload since CDN update
On Jun 1, 2013, at 2:33 AM, Matt Wilkie map...@gmail.com wrote: sorry, here's the direct branch link : http://bazaar.launchpad.net/~leo-editor-team/leo-editor/trunk3/files and nightly snapshots: http://www.greygreen.org/leo/ -matt On Fri, May 31, 2013 at 11:30 PM, Matt Wilkie map...@gmail.com wrote: Matt, is your code available online anywhere? yes: https://code.launchpad.net/leo-editor thanks for looking at this. -matt As far as I can tell your issue is unrelated to the CDN. I don't know how to use Launchpad very well, but you hit a path in the code that, as far as I know, only gets hit when you don't have a long_description. This bit of code attempts to extract a long_description from a README file. It explicitly checks for certain extensions and TXT (instead of txt) is not one of them. However it returns a singular None when the calling code expects a 2 item tuple to be returned. I'm guessing that you didn't have a long_description when it wasn't working, and your README file was named README.TXT, and between when it wasn't working and when it was you added a long_description. Is my guess correct? The bit of code in question is https://bitbucket.org/pypa/pypi/src/0fd0fd89b791bc2641382f81dcc677ae4742abf7/description_utils.py?at=default#cl-202 - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On 31/05/2013 21:45, Noah Kantrowitz wrote: On May 31, 2013, at 1:34 PM, Tres Seaver wrote: On 05/31/2013 09:18 AM, Lennart Regebro wrote: I'd be OK with after six months automatically removing packages that has only one owner/maintainer, and that owner/maintainer has no other packages, and the package has no available downloads, and no contact information on either package nor registered user. Why all the extras: if somebody wants to claim a project name, but can't upload a release for six months, they should just lose. I would actually be willing to have that cut down to a day: trying to grab the name before registering / uploading a release should result in loss of the claim. +1, I think this should just be treated as a form validation thing. It is a detail of the protocol that you upload a dist definition before the files, but I don't think we should consider it a valid PyPI entry until a file is uploaded (especially now that the default mode is to not scrape external sites). As we switch to not scraping, anything with no files should just vanish IMO, at which point it is available for registration again. If someone happens to ninja-upload between the setup.py register and setup.py upload, I think we can just throw an error message since chances of that happening are so amazingly low. I'm afraid I need to -1 on this. If I'm developing a new package, I try and avoid putting a release on PyPI until I have something stable, but I'll often put up an entry on PyPI explaining where the code is being developed. Working on a project for a year only to find that someone else has stolen your package name on PyPI (playing devils advocate here, lets say they saw the development of GitHub and knew a release was brewing, etc) and having to go through and rename everything seems unfairly painful... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
In the Python community, we've been pretty laid back about how we name packages. When we were small, this made sense. It doesn't make sense any more. We should not have to come up with a process for recognizing squatters on simple package names. We should have something more systematic, IMO. Unfortunately, I think the sanest way of avoiding most package name issues is to base them on domains, as is done in the Java world. This goes against the Python philosophy of preferring flat to nested, but I still think it's better than trying to police squatters, or to encouraging races to claim top-level names. For a while, many of us have been pretty careful to use namespaces for new packages to mitigate this issue. For example, the zc namespace is a shorter version of com.zope, but at some point, it won't be fair for us to claim zc for ourselves. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
On Jun 1, 2013, at 11:57 AM, Jim Fulton j...@zope.com wrote: In the Python community, we've been pretty laid back about how we name packages. When we were small, this made sense. It doesn't make sense any more. We should not have to come up with a process for recognizing squatters on simple package names. We should have something more systematic, IMO. Unfortunately, I think the sanest way of avoiding most package name issues is to base them on domains, as is done in the Java world. This goes against the Python philosophy of preferring flat to nested, but I still think it's better than trying to police squatters, or to encouraging races to claim top-level names. For a while, many of us have been pretty careful to use namespaces for new packages to mitigate this issue. For example, the zc namespace is a shorter version of com.zope, but at some point, it won't be fair for us to claim zc for ourselves. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig I am opposed to this. Requiring someone to have purchased a domain adds a significant to publishing a project. If there are no requirements that they have purchased the domain then it's nothing more than a convention and something that anyone who wants to do this can do. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
On Jun 1, 2013, at 2:01 PM, Donald Stufft don...@stufft.io wrote: I am opposed to this. Requiring someone to have purchased a domain adds a significant to publishing a project. If there are no requirements that they have purchased the domain then it's nothing more than a convention and something that anyone who wants to do this can do. Herp derp I can word good, obviously I mean a significant barrier to publishing. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
On Sat, Jun 1, 2013 at 2:02 PM, Donald Stufft don...@stufft.io wrote: On Jun 1, 2013, at 2:01 PM, Donald Stufft don...@stufft.io wrote: I am opposed to this. Requiring someone to have purchased a domain adds a significant to publishing a project. If there are no requirements that they have purchased the domain then it's nothing more than a convention and something that anyone who wants to do this can do. Fair enough. A common variation on this scenario, which avoids purchasing a domain, is to use a code hosting domain and project name, so, for example: org.bitbucket.j1m.foo. Of course, using a domain name without owning it is a form of squatting. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
On Jun 1, 2013, at 11:09 AM, Jim Fulton wrote: On Sat, Jun 1, 2013 at 2:02 PM, Donald Stufft don...@stufft.io wrote: On Jun 1, 2013, at 2:01 PM, Donald Stufft don...@stufft.io wrote: I am opposed to this. Requiring someone to have purchased a domain adds a significant to publishing a project. If there are no requirements that they have purchased the domain then it's nothing more than a convention and something that anyone who wants to do this can do. Fair enough. A common variation on this scenario, which avoids purchasing a domain, is to use a code hosting domain and project name, so, for example: org.bitbucket.j1m.foo. Of course, using a domain name without owning it is a form of squatting. All that means is either we move the problem (instead of one shared namespace we two or three common ones) or we do it github-style and just prepend usernames at which point you can skip the whole URI thing because usernames must be unique for reasons of general sanity and I don't think it is a huge deal that a single person can't have two packages of the same name. Github-style namespacing just means that either names all suck (django/django, kennethreitz/requests) or you need to come up with some way to map un-namespaced names to their canonical form and we are more or less back at square one. If people don't mind the sucky names, they can already put that in their package name if the bare version is taken, so QED this is already doable in the current system, it just looks so ugly that no one wants to do it and enforcing the ugly seems like a poor option. --Noah signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On 1 June 2013 16:00, Chris Withers ch...@simplistix.co.uk wrote: I'm afraid I need to -1 on this. If I'm developing a new package, I try and avoid putting a release on PyPI until I have something stable, but I'll often put up an entry on PyPI explaining where the code is being developed. Working on a project for a year only to find that someone else has stolen your package name on PyPI (playing devils advocate here, lets say they saw the development of GitHub and knew a release was brewing, etc) and having to go through and rename everything seems unfairly painful... I'd say that at a minimum, no deletion should happen without the author being contacted. As long as there's an author email, and the author actually replies to emails saying do you mind if I take over this project name. I'm -1 on anything that doesn't involve at least a minimal level of human involvement (possibly excepting an initial clean up exercise for projects with no author email) Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
On Sat, Jun 01, 2013 at 11:57 -0400, Jim Fulton wrote: In the Python community, we've been pretty laid back about how we name packages. When we were small, this made sense. It doesn't make sense any more. I've heart this sentiment before, but would like to read more clearly stated problems. We should not have to come up with a process for recognizing squatters on simple package names. We should have something more systematic, IMO. Unfortunately, I think the sanest way of avoiding most package name issues is to base them on domains, as is done in the Java world. This goes against the Python philosophy of preferring flat to nested, but I still think it's better than trying to police squatters, or to encouraging races to claim top-level names. I am not sure that tying to DNS namespacing is the only solution here (whatever the problem is exactly :). For a while, many of us have been pretty careful to use namespaces for new packages to mitigate this issue. For example, the zc namespace is a shorter version of com.zope, but at some point, it won't be fair for us to claim zc for ourselves. I wonder if we could allow people/groups to apply (to humans) for a namespace which they can subsequently control, like the zc.* one. Everyone could continue to push non-namespaced (flat) packages to pypi like now but the names couldn't take the form of namespaced ones. So for example if the django community wants to introduce the concept of vetted plugins/addons, they could move to manage dj.* or so. I don't think we would suddenly drown in namespace regs if we make it a pre-condition that there need to be a couple of existing real packages that would go into it. cheers, holger Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
On Jun 1, 2013, at 3:21 PM, holger krekel hol...@merlinux.eu wrote: On Sat, Jun 01, 2013 at 11:57 -0400, Jim Fulton wrote: In the Python community, we've been pretty laid back about how we name packages. When we were small, this made sense. It doesn't make sense any more. I've heart this sentiment before, but would like to read more clearly stated problems. We should not have to come up with a process for recognizing squatters on simple package names. We should have something more systematic, IMO. Unfortunately, I think the sanest way of avoiding most package name issues is to base them on domains, as is done in the Java world. This goes against the Python philosophy of preferring flat to nested, but I still think it's better than trying to police squatters, or to encouraging races to claim top-level names. I am not sure that tying to DNS namespacing is the only solution here (whatever the problem is exactly :). For a while, many of us have been pretty careful to use namespaces for new packages to mitigate this issue. For example, the zc namespace is a shorter version of com.zope, but at some point, it won't be fair for us to claim zc for ourselves. I wonder if we could allow people/groups to apply (to humans) for a namespace which they can subsequently control, like the zc.* one. Everyone could continue to push non-namespaced (flat) packages to pypi like now but the names couldn't take the form of namespaced ones. So for example if the django community wants to introduce the concept of vetted plugins/addons, they could move to manage dj.* or so. I don't think we would suddenly drown in namespace regs if we make it a pre-condition that there need to be a couple of existing real packages that would go into it. I've long thought about allowing people to claim a namespace. It certainly provides a carrot to get people to namespace their packages and thus not take up the top level names. cheers, holger Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
On Sat, Jun 1, 2013 at 9:20 PM, Paul Moore p.f.mo...@gmail.com wrote: I'm -1 on anything that doesn't involve at least a minimal level of human involvement (possibly excepting an initial clean up exercise for projects with no author email) This is why I basically said I'm OK with automatic deletion after a time if there are no downloadable packages and no contact information. Otherwise the owner should be contacted. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
From: Distutils-SIG [mailto:distutils-sig-bounces+jaraco=jaraco@python.org] On Behalf Of Donald Stufft Sent: Saturday, 01 June, 2013 15:30 To: holger krekel Cc: distutils sig Subject: Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages. On Jun 1, 2013, at 3:21 PM, holger krekel hol...@merlinux.eu mailto:hol...@merlinux.eu wrote: On Sat, Jun 01, 2013 at 11:57 -0400, Jim Fulton wrote: For a while, many of us have been pretty careful to use namespaces for new packages to mitigate this issue. For example, the zc namespace is a shorter version of com.zope, but at some point, it won't be fair for us to claim zc for ourselves. I wonder if we could allow people/groups to apply (to humans) for a namespace which they can subsequently control, like the zc.* one. So for example if the django community wants to introduce the concept of vetted plugins/addons, they could move to manage dj.* or so. I think this example highlights some of the challenges with registering/controlling namespaces - who owns what and what is the meaning of a (distribution) package name? For example, what is the namespace used for an endorsed django plugin written by zope corporation? This problem is not present now, as the author can choose the domain which is most relevant to that plugin and its users. If there's some expectation that it should appear in a namespace managed by another organization, that necessitates a coordination between the namespace owner/manager and the project author. I think more people would claim namespaces when namespaces are better supported in Python. My expectation is Python 3.3 namespace package support will ease that challenge (when it becomes a dominant version). My inclination is to say it's not a huge problem, and later is preferable than sooner. smime.p7s Description: S/MIME cryptographic signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [ANN] pypiserver 1.1.1 - minimal private pypi server
holger krekel hol...@merlinux.eu writes: How does it compare to http://pypi.python.org/pypi/devpi-server? the main differences as i see them (note i am the devpi-server author, though): - pypiserver supports uploading to private indexes, devpi-server not yet (but next week / on trunk already :) I still consider that a bug. scp works much better. I'm not sure if devpi-server maintains some kind of database, but I consider it a big plus to be able to just copy files and directories to the package directory and serve them instantly. - pypiserver has no dependencies (ships bottle inline), devpi-server depends on redis (to be dropped next week for no-dep fs-storage) and bottle, requests, py, all proven libraries. nice, I'll try it if the redis dependency is gone. - pypiserver redirects the lookup of pypi packages to pypi.python.org, that's related to a weak point of pypiserver: you currently have to parse the log files and look for HTTP redirects if you like to know what packages are missing in the local package directory. you also can't install a specific version of a package if the package directory doesn't have that specific version but a different version. this may or may not be good depending on your use case. redirects can also be completely disabled, so pip/easy_install only see the packages in the package directory. devpi-server caches them and serves everything (including #egg-links) through itself, allowing complete offline operations (including caching/serving of 3rd party site's packages) using the extended PEP381 mirror protocol - pypiserver has a good and simple implementation, devpi-server is little more complex mostly due to its caching/crawling logic. - both are very well tested and maintained but pypiserver is out there for a longer time already, so has seen more RL-testing. Ralph, please add/comment as you see fit. pypiserver exhibits it's WSGI application and might be easier to deploy using different WSGI servers. -- Cheers Ralf ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
On 1 June 2013 16:57, Jim Fulton j...@zope.com wrote: In the Python community, we've been pretty laid back about how we name packages. When we were small, this made sense. It doesn't make sense any more. I'd like to see some evidence that this is the case. It doesn't seem so to me - most package names are relatively discoverable and/or intuitive, and we currently have basically no namespacing. There's a long way to go before something like your suggestion is needed, in my view. Unfortunately, I think the sanest way of avoiding most package name issues is to base them on domains, as is done in the Java world. This goes against the Python philosophy of preferring flat to nested, but I still think it's better than trying to police squatters, or to encouraging races to claim top-level names. No, no, no... There's the point Donald made that you require people to own a domain (or you create some sort of hack like org.bitbucket.username/com.github.username/...) but it also makes package names unreasonably deep, and requires an explosion of namespace packages at the top level. And it's ugly :-) Perl manages with a relatively flat namespace and relatively informal rules for managing package names (AIUI). I'm sure Python can, too. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
On Sat, Jun 1, 2013 at 6:00 PM, Paul Moore p.f.mo...@gmail.com wrote: On 1 June 2013 16:57, Jim Fulton j...@zope.com wrote: In the Python community, we've been pretty laid back about how we name packages. When we were small, this made sense. It doesn't make sense any more. I'd like to see some evidence that this is the case. It doesn't seem so to me - most package names are relatively discoverable and/or intuitive, and we currently have basically no namespacing. There's a long way to go before something like your suggestion is needed, in my view. Unfortunately, I think the sanest way of avoiding most package name issues is to base them on domains, as is done in the Java world. This goes against the Python philosophy of preferring flat to nested, but I still think it's better than trying to police squatters, or to encouraging races to claim top-level names. No, no, no... There's the point Donald made that you require people to own a domain (or you create some sort of hack like org.bitbucket.username/com.github.username/...) but it also makes package names unreasonably deep, and requires an explosion of namespace packages at the top level. And it's ugly :-) Perl manages with a relatively flat namespace and relatively informal rules for managing package names (AIUI). I'm sure Python can, too. Paul There's also the fact that our module namespace is separate from our distribution names namespace... ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.
I'm with Jason in the maybe eventually, but not right now camp. Namespace collisions are indeed a possibility and a potential concern, both in the distribution namespace and the top level import namespace. The fact there is no 1to1 mapping between distribution names and the import namespace means that informal conflict avoidance is already possible - prepending qualifier- to the desired package name makes it possible to publish it alongside another distribution using the same name without having to change the top level import location. If the distributed packages use explicit relative imports appropriately, an integrator may even be able to use them side by side by dropping them into higher level namespace packages. Java's use the domain name approach simply outsources the conflict resolution to a third party, by *requiring* that publishers acquire a domain name prior to publication. I prefer our model of initially *assuming* a lack of conflict to lower barriers to publication. I do think we need to better handle cases where the assumption breaks down, but we shouldn't forget namespacing is already possible. Cheers, Nick. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A process for removal of PyPi entries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2013 06:41 PM, Jim Fulton wrote: I hope no one is proposing removing a project simply because someone hasn't released a new (after initial) release in some period of time. Certainly not I: I'd just like to prevent squatters (no matter how well-intentioned, Withers!) from tying up a project name indefinitely. Code talks, as it were: release something or take your marbles and go home. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGqky0ACgkQ+gerLs4ltQ74iwCgqSr4TqKC/ktgU0XlsDKedp2i 3ZwAnRnuuEX2imZlVs2CT54faUZFYo6l =qReS -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
