From amos@digicool.com Thu Apr 5 01:31:14 2001 From: amos@digicool.com (Amos Latteier) Date: Wed, 04 Apr 2001 17:31:14 -0700 Subject: [Catalog-sig] Catalog Server Prototype Progress Message-ID: <3ACBBCD2.50A531E2@digicool.com> Hi Guys, I just wanted to let folks know that I've made some more progress on my catalog server prototype. http://63.230.174.230:8080/archive Now you can use OpenPGP signatures with source and binary distributions. Also authors can include their pubic keys on their info pages. I've uploaded the lasted version of the server code to the catalog server (hey, it's even signed). I'm getting pretty close to being able to support PEP 243. The missing pieces are detailed in the TODO.txt file. As always, feedback is most welcome! -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From martin@loewis.home.cs.tu-berlin.de Mon Apr 9 10:46:31 2001 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 9 Apr 2001 11:46:31 +0200 Subject: [Catalog-sig] _checkversion.py Message-ID: <200104090946.f399kVT01362@mira.informatik.hu-berlin.de> Is anybody (besides PyXML) using the _checkversion.py script, and the Tools/versioncheck mechanism? It appears to me that this ought to be superceded by a more general repository of installed packages, and a way to find out what updates to these packages are available. If so, I think it should be removed from the Python distribution. Regards, Martin From guido@digicool.com Mon Apr 9 15:00:52 2001 From: guido@digicool.com (Guido van Rossum) Date: Mon, 09 Apr 2001 09:00:52 -0500 Subject: [Catalog-sig] _checkversion.py In-Reply-To: Your message of "Mon, 09 Apr 2001 11:46:31 +0200." <200104090946.f399kVT01362@mira.informatik.hu-berlin.de> References: <200104090946.f399kVT01362@mira.informatik.hu-berlin.de> Message-ID: <200104091400.JAA01002@cj20424-a.reston1.va.home.com> > Is anybody (besides PyXML) using the _checkversion.py script, and the > Tools/versioncheck mechanism? It appears to me that this ought to be > superceded by a more general repository of installed packages, and a > way to find out what updates to these packages are available. If so, I > think it should be removed from the Python distribution. I agree; it never caught on (probably because it doesn't quite do what's needed). I would ask Jack Jansen though, since he created it; I bet he's using it for MacPython. What's the harm in leaving it there (with an added comment about obsolescence)? --Guido van Rossum (home page: http://www.python.org/~guido/) From martin@loewis.home.cs.tu-berlin.de Mon Apr 9 16:49:35 2001 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 9 Apr 2001 17:49:35 +0200 Subject: [Catalog-sig] _checkversion.py In-Reply-To: <200104091400.JAA01002@cj20424-a.reston1.va.home.com> (message from Guido van Rossum on Mon, 09 Apr 2001 09:00:52 -0500) References: <200104090946.f399kVT01362@mira.informatik.hu-berlin.de> <200104091400.JAA01002@cj20424-a.reston1.va.home.com> Message-ID: <200104091549.f39FnZ602151@mira.informatik.hu-berlin.de> > I agree; it never caught on (probably because it doesn't quite do > what's needed). I would ask Jack Jansen though, since he created it; > I bet he's using it for MacPython. What's the harm in leaving it > there (with an added comment about obsolescence)? I have a PyXML bug report that the _checkversion there is outdated, so I wonder whether I should continue to maintain it, or kill it. Leaving it, marked as obsolete, is fine with me. Regards, Martin From jack@oratrix.nl Tue Apr 10 08:29:09 2001 From: jack@oratrix.nl (Jack Jansen) Date: Tue, 10 Apr 2001 09:29:09 +0200 Subject: [Catalog-sig] _checkversion.py In-Reply-To: Message by "Martin v. Loewis" , Mon, 9 Apr 2001 17:49:35 +0200 , <200104091549.f39FnZ602151@mira.informatik.hu-berlin.de> Message-ID: <20010410072914.04FFCEA11D@oratrix.oratrix.nl> I'm ok with scrapping _checkversion. I never even got around to using it all of the time myself:-) And the distutils metainfo should be a good place to store this information in the future. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From el_negrito_1999@yahoo.com Tue Apr 10 17:06:15 2001 From: el_negrito_1999@yahoo.com (ANGEL STEELE) Date: Tue, 10 Apr 2001 09:06:15 -0700 (PDT) Subject: [Catalog-sig] Re: Catalog-sig digest, Vol 1 #34 - 2 msgs In-Reply-To: Message-ID: <20010410160615.15806.qmail@web3703.mail.yahoo.com> unsubscribe me please --- catalog-sig-request@python.org wrote: > Send Catalog-sig mailing list submissions to > catalog-sig@python.org > > To subscribe or unsubscribe via the World Wide Web, > visit > http://mail.python.org/mailman/listinfo/catalog-sig > or, via email, send a message with subject or body > 'help' to > catalog-sig-request@python.org > > You can reach the person managing the list at > catalog-sig-admin@python.org > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of Catalog-sig digest..." > > > Today's Topics: > > 1. Re: _checkversion.py (Martin v. Loewis) > 2. Re: _checkversion.py (Jack Jansen) > > --__--__-- > > Message: 1 > Date: Mon, 9 Apr 2001 17:49:35 +0200 > From: "Martin v. Loewis" > > To: guido@digicool.com > CC: catalog-sig@python.org, jack@cwi.nl > Subject: Re: [Catalog-sig] _checkversion.py > > > I agree; it never caught on (probably because it > doesn't quite do > > what's needed). I would ask Jack Jansen though, > since he created it; > > I bet he's using it for MacPython. What's the > harm in leaving it > > there (with an added comment about obsolescence)? > > I have a PyXML bug report that the _checkversion > there is outdated, so > I wonder whether I should continue to maintain it, > or kill it. Leaving > it, marked as obsolete, is fine with me. > > Regards, > Martin > > > > --__--__-- > > Message: 2 > To: "Martin v. Loewis" > > Cc: guido@digicool.com, catalog-sig@python.org, > Jack.Jansen@cwi.nl > Subject: Re: [Catalog-sig] _checkversion.py > Date: Tue, 10 Apr 2001 09:29:09 +0200 > From: Jack Jansen > > I'm ok with scrapping _checkversion. I never even > got around to using > it all of the time myself:-) > > And the distutils metainfo should be a good place to > store this > information in the future. > -- > Jack Jansen | ++++ stop the execution of > Mumia Abu-Jamal ++++ > Jack.Jansen@oratrix.com | ++++ if you agree copy > these lines to your sig ++++ > www.oratrix.nl/~jack | see > http://www.xs4all.nl/~tank/spg-l/sigaction.htm > > > > --__--__-- > > _______________________________________________ > Catalog-sig mailing list > Catalog-sig@python.org > http://mail.python.org/mailman/listinfo/catalog-sig > > > End of Catalog-sig Digest __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From 045521104@telia.com Thu Apr 12 09:49:01 2001 From: 045521104@telia.com (Martin Johansson) Date: Thu, 12 Apr 2001 10:49:01 +0200 Subject: [Catalog-sig] HTML Message-ID: <002a01c0c32d$6c7670e0$0100a8c0@Martin> This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C0C33E.2F30F460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have done this to take away htmlcodes from a textfile but in will not = work. What can be wrong? while s !=3D '' or '': if s =3D=3D '<': if s !=3D '>': s =3D string.replace(s, "a", "")=20 s =3D string.replace(s, "b", "") s =3D string.replace(s, "t", "") ------=_NextPart_000_0027_01C0C33E.2F30F460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have done this to take away htmlcodes = from a=20 textfile but in will not work. What can be wrong?
 
 
while s !=3D '</HTML>' or=20 '</html>':
        if s = =3D=3D=20 '<':
          &n= bsp; if=20 s !=3D=20 '>':
          &n= bsp;    =20 s =3D string.replace(s, "a", "")=20
           &nb= sp;   =20 s =3D string.replace(s, "b",=20 "")
           =     =20 s =3D string.replace(s, "t", "")
------=_NextPart_000_0027_01C0C33E.2F30F460-- From 045521104@telia.com Fri Apr 20 15:03:19 2001 From: 045521104@telia.com (Martin Johansson) Date: Fri, 20 Apr 2001 16:03:19 +0200 Subject: [Catalog-sig] time Message-ID: <00f501c0c9a2$a8398240$0100a8c0@Martin> This is a multi-part message in MIME format. ------=_NextPart_000_00F2_01C0C9B3.6B003AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! I have a program I will to start one time everey hour. How could I do this? It should start by itself. It=B4s a program that will download homepages. /Martin Johansson 045521104@telia.com ------=_NextPart_000_00F2_01C0C9B3.6B003AC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi!
I have a program I will to = start one time=20 everey hour.
How could I do this?
It should start by itself.
It=B4s a program that will download=20 homepages.
/Martin Johansson
045521104@telia.com
------=_NextPart_000_00F2_01C0C9B3.6B003AC0-- From akuchlin@mems-exchange.org Fri Apr 20 18:10:10 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 20 Apr 2001 13:10:10 -0400 Subject: [Catalog-sig] Moving forward Message-ID: Now that Python 2.1 is out, I think it's time to begin moving the Catalog-SIG forward again. To recap where we stand: PEP 241 made it into Python 2.1. PEP 243 didn't, but I don't know if there are any further changes that need to go into it. We have two server prototypes: Amos's, and Sean's. (BTW, Sean, I'd like to link to it from the SIG's status page, but can't figure out a URL for the prototype.) I'm planning to wrap up and release version 1.0.2 of the Distutils, and then try to chew through the feature requests and other patches that have accumulated on SourceForge, so they can be in the next Distutils release. (1.1, 1.0.3, whatever.) So, what now? The only things I can really think of are: * Look at PEP 243 and finish off the specification. (Or is it done?) * The prototypes need to begin evolving toward being production-usable. What else should we be doing? --amk From ljohnson@resgen.com Fri Apr 20 20:00:36 2001 From: ljohnson@resgen.com (Lyle Johnson) Date: Fri, 20 Apr 2001 14:00:36 -0500 Subject: [Catalog-sig] RE: time In-Reply-To: Message-ID: > Hi! > I have a program I will to start one time everey hour. > How could I do this? > It should start by itself. > It=B4s a program that will download homepages. > /Martin Johansson > 045521104@telia.com Well, on Unix operating systems (including Linux) you'd use a cron job; see the manual pages for cron for more details. Under Windows NT I think you can use the AT command but I'm completely unfamiliar with how that works. Of course this has absolutely nothing at all to do with the Python Catalog SIG ;) From johann@egenetics.com Mon Apr 23 11:44:52 2001 From: johann@egenetics.com (Johann Visagie) Date: Mon, 23 Apr 2001 12:44:52 +0200 Subject: [Catalog-sig] From a BSD point of view... Message-ID: <20010423124452.A11086@fling.sanbi.ac.za> Hi there, Apologies for being a johnny-come-lately; I only found out about this SIG when I read the Slashdot interview. :-) My interest in the discussion here is simple: I currently maintain the FreeBSD ports of a couple of Python tools (the one with the highest profile probably being PyXML), and what happens here will determine how easy or difficult that task will be in future. I note that the FreeBSD ports system was listed under "other systems to look at" in the very first posting to the SIG's list by Andrew Kuchling (2000-11-08). Here are a few documents you may wish to look at, and/or add to the list of "other catalog systems" on the SIG's web pages: The FreeBSD porter's handbook: http://www.freebsd.org/doc/en_US.ISO_8859-1/books/porters-handbook/ The Open Packages project, currently still in a very early stage, aims to provide a unified packaging system across all BSD-derived operating systems (including MacOS X). I believe their aim is also to make it flexible enough to be adopted by other operating systems, distributions or projects: http://www.openpackages.net/ (It seems everyone and their maiden aunt is building a packaging system nowadays. :-) Finally, an interesting recent addition to FreeBSD has been "BSDPAN". Basically a number of extensions to Perl's MakeMaker, BSDPAN causes perlmods installed via CPAN.pm (or via "perl Makefile.PL && make install") to register themselves with the FreeBSD package database exactly as if they had been installed from a port (and are therefore simple to uninstall, and can satisfy dependency requests, etc.) In summary, it "merges" Perl and FreeBSD's packaging systems from the user's point of view. The following mailing list posting is relevant: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1253580+1258568+/usr/local/www/db/text/2001/freebsd-ports/20010204.freebsd-ports Ideally (for me), it would be nice to have BSDPAN-like functionality for Python ports/packages in FreeBSD one day. I've only skim-read the SIG archives and PEPs. I'm about to go on leave for a week; when I return I hope to have the time to look at the proposed catalog system(s) in considerably more detail. If there's enough info to go on I may try to implement a BSDPAN-like prototype, if only for my own edification. Hopefully I can give some useful feedback then. -- Johann From 045521104@telia.com Mon Apr 23 15:19:26 2001 From: 045521104@telia.com (Martin Johansson) Date: Mon, 23 Apr 2001 16:19:26 +0200 Subject: [Catalog-sig] Homepages? Message-ID: <001001c0cc00$67a35e80$0100a8c0@Martin> This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C0CC11.2A5DE200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! I have a program that will take down a homepage and it works. But I want = the program to take down all the pages that are listed and linked at one = page.=20 Anyone have a great tip? /Martin ------=_NextPart_000_000D_01C0CC11.2A5DE200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi!
I have a program that will take down a = homepage and=20 it works. But I want the program to take down all the pages that are = listed and=20 linked at one page.
Anyone have a great tip?
/Martin
------=_NextPart_000_000D_01C0CC11.2A5DE200-- From ljohnson@resgen.com Mon Apr 23 17:24:38 2001 From: ljohnson@resgen.com (Lyle Johnson) Date: Mon, 23 Apr 2001 11:24:38 -0500 Subject: [Catalog-sig] RE: Homepages? (Martin Johansson) In-Reply-To: Message-ID: >
I have a program that will take down a = > homepage and=20 > it works. But I want the program to take down all the pages that are = > listed and=20 > linked at one page.
>
Anyone have a great tip?
>
/Martin
Here are a few great tips: 1. Send your messages in plain text and not HTML. 2. In the future, send your messages to an appropriate mailing list. This mailing list is for discussions related the Python Catalog SIG. 3. To recursively download a web page and its links, check out wget (http://www.gnu.org/software/wget/wget.html) which is probably already installed on your system if you're using any of the popular Linux distributions. I am sure there are equivalents for Windows as well. Lyle From martin@loewis.home.cs.tu-berlin.de Mon Apr 23 17:12:45 2001 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Mon, 23 Apr 2001 18:12:45 +0200 Subject: [Catalog-sig] From a BSD point of view... In-Reply-To: <20010423124452.A11086@fling.sanbi.ac.za> (message from Johann Visagie on Mon, 23 Apr 2001 12:44:52 +0200) References: <20010423124452.A11086@fling.sanbi.ac.za> Message-ID: <200104231612.f3NGCjJ00859@mira.informatik.hu-berlin.de> > Ideally (for me), it would be nice to have BSDPAN-like functionality for > Python ports/packages in FreeBSD one day. Isn't that more of a distutils problem? I'm pretty sure that a patch that adds a bdist_bsd (or some such, would bdist_port be more appropriate?) command to distutils (in addition to bdist_rpm and bdist_wininst) would be accepted, as would probably be a patch to the 'install' command that allows registration with the package database. Regards, Martin From amos@digicool.com Mon Apr 23 23:41:42 2001 From: amos@digicool.com (Amos Latteier) Date: Mon, 23 Apr 2001 15:41:42 -0700 Subject: [Catalog-sig] Moving forward References: Message-ID: <3AE4AFA6.A63F738B@digicool.com> Andrew Kuchling wrote: > > Now that Python 2.1 is out, I think it's time to begin moving the > Catalog-SIG forward again. > > To recap where we stand: PEP 241 made it into Python 2.1. PEP 243 > didn't, but I don't know if there are any further changes that need to > go into it. I have a couple questions about pep 243 1. How can the server identify the uploader? You can include an optional signature file, however if you don't include this file there is no way to associate an identity with the uploaded file. In my prototype even if you don't include a signature file the server requires an account and keeps track of who uploaded what. Perhaps there could be optional support for HTTP authentication during the upload. This would allow the distutils to supply optional authentication credentials. 2. Platform specification. Should the server validate the platform specification? I suspect that platform specification in general is a rat hole. For example a binary package may require all sorts of things that are hard to represent as an os, os version, and Python version. I still haven't implemented platform specification in my prototype. 3. PKG-INFO conflicts. The PEP allows both extraction of the PKG-INFO file from the package and an optional upload of the PKG-INFO file. What happens if these files are not the same. I propose that the PKG-INFO file in the package be used if there is a conflict. > I'm planning to wrap up and release version 1.0.2 of the Distutils, > and then try to chew through the feature requests and other patches > that have accumulated on SourceForge, so they can be in the next > Distutils release. (1.1, 1.0.3, whatever.) > > So, what now? The only things I can really think of are: > > * Look at PEP 243 and finish off the specification. (Or is it done?) I still have a couple questions on the PEP (see above). Greg stein had lots of ideas about how we could use standard HTTP facilities. Should we revisit these ideas? In general, I don't think it's necessary for the PEP to be perfect, just good enough to work with our existing prototypes. Then we can evolve it and bump the protocol version number. > * The prototypes need to begin evolving toward being > production-usable. What are the criteria for production usability? I'd say we need to have a basic level of usability and stability. I'd love to hear specific feedback about what my prototype needs in order to move it toward reasonableness. > What else should we be doing? That sounds good. -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From moshez@zadka.site.co.il Tue Apr 24 06:24:32 2001 From: moshez@zadka.site.co.il (Moshe Zadka) Date: Tue, 24 Apr 2001 08:24:32 +0300 Subject: [Catalog-sig] Moving forward In-Reply-To: <3AE4AFA6.A63F738B@digicool.com> References: <3AE4AFA6.A63F738B@digicool.com>, Message-ID: On Mon, 23 Apr 2001, Amos Latteier wrote: > 1. How can the server identify the uploader? You can include an > optional signature file, however if you don't include this file there is > no way to associate an identity with the uploaded file. In my prototype > even if you don't include a signature file the server requires an > account and keeps track of who uploaded what. Perhaps there could be > optional support for HTTP authentication during the upload. This would > allow the distutils to supply optional authentication credentials. I think this is a feature in PEP-243 -- no false sense of security. We do have to think about maintaining a keyring in the server, though. > 2. Platform specification. Should the server validate the platform > specification? I suspect that platform specification in general is a rat > hole. For example a binary package may require all sorts of things that > are hard to represent as an os, os version, and Python version. I still > haven't implemented platform specification in my prototype. Well, if the specification is too complex, then the uploader can just punt on uploading binary packages... > 3. PKG-INFO conflicts. The PEP allows both extraction of the PKG-INFO > file from the package and an optional upload of the PKG-INFO file. What > happens if these files are not the same. I propose that the PKG-INFO > file in the package be used if there is a conflict. I suggest that the upload will be rejected. In the face of ambiguity, refuse the temptation to guess. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org From martin@loewis.home.cs.tu-berlin.de Tue Apr 24 07:02:40 2001 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Tue, 24 Apr 2001 08:02:40 +0200 Subject: [Catalog-sig] Moving forward In-Reply-To: <3AE4AFA6.A63F738B@digicool.com> (message from Amos Latteier on Mon, 23 Apr 2001 15:41:42 -0700) References: <3AE4AFA6.A63F738B@digicool.com> Message-ID: <200104240602.f3O62ei00889@mira.informatik.hu-berlin.de> > 1. How can the server identify the uploader? You can include an > optional signature file, however if you don't include this file there is > no way to associate an identity with the uploaded file. Sure there is: there should be an author= argument to setup. If the package is not signed, the server could assume that the package is submitted by the author of the package. Of course, that would require manual verification of some kind by the server operator at some later point. The Author: is also available in the PKG-INFO. > In my prototype even if you don't include a signature file the > server requires an account and keeps track of who uploaded > what. Perhaps there could be optional support for HTTP > authentication during the upload. This would allow the distutils to > supply optional authentication credentials. IMO, many security protocols suffer from there being to many options. We have a authentication procedure which involves verification that the package was really produced by someone with a certain identity, I don't think there is need for another authentication mechanism. As for "HTTP authentication", I assume you mean the Basic authentication. As you surely know, this has major problems from a security point of view; it is almost as good or bad as plain identification. As I said, identification is already possible through the distutils author= argument, although there might be need for an additional packager= identity - as supported by the bdist_rpm command. > 3. PKG-INFO conflicts. The PEP allows both extraction of the PKG-INFO > file from the package and an optional upload of the PKG-INFO file. What > happens if these files are not the same. I propose that the PKG-INFO > file in the package be used if there is a conflict. I'd think that should be an error - although it is probably a quality-of-implementation issue to detect that error automatically. > > * The prototypes need to begin evolving toward being > > production-usable. > > What are the criteria for production usability? I'd say we need to have > a basic level of usability and stability. I think the most important aspect is that somebody needs to start to operate a server as if it was in production use. That means they need to have an out-of-band procedure to accept public keys, and a download facility. The packages being uploaded must be persistent (and ideally available for immediate download), and an administrative contact address must be set-up. Of course, the servers should follow the protocol to the letter of the spec. I understand that there are some basic parameters to the protocol (e.g. the URL of server); I think we need to minimize these parameters (to, say, just the host name, fixing the relative path on the host). Regards, Martin