[Python-Dev] buildbot
> Currently, branches are not supported, because buildbot is
> somewhat limited. When I get a solution for this problem,
> I plan to have all buildbots build both the trunk and the
> 2.4 branch; such builds would only be initiated whenever
> something is committed on the branch.
Branch support appeared fairly recently (buildbot-0.7.0, about two months
ago), and I believe it should be sufficient to trigger builds for both the
trunk and the 2.4 branch. The last part of the setup involves modifying the
svn_buildbot.py hook script, though, so I won't claim this support is
complete yet.
The basic idea is that you create multiple Scheduler instances, one for each
branch you want to monitor. Both Schedulers are configured to trigger all the
Builders. You configure the SVN-checkout step of the build process with a
baseURL= argument to provide the common portion of the SVN URL, and add a
defaultBranch= argument to point to the trunk. Each Build is done for a
specific branch, and the SVN checkout step just appends the branch name to
the baseURL to figure out what to pass to 'svn co %s'
Assuming the ChangeSource is providing branch information properly, this will
result in any change to the trunk causing a trunk build, and any change to
the 2.4 branch causing a 2.4 build.
Your master.cfg file will probably want to have some of the following
elements:
---BEGIN---
from buildbot.changes.pb import PBChangeSource
c['sources'] = PBChangeSource() # N.B.: don't set prefix=
from buildbot.scheduler import Scheduler
all_builders=["sparc solaris10 gcc trunk",
"g5 osx trunk",
"amd64 gentoo trunk",
"x86 gentoo trunk"]
s1 = Scheduler("trunk scheduler", "trunk", 2*60, all_builders)
s2 = Scheduler("2.4 scheduler", "branches/release24-maint", 2*60, all_builders)
c['schedulers'] = [s1, s2]
...
from buildbot.process.factory import s
from buildbot.process.step import SVN
checkoutstep = s(SVN, baseURL="http://svn.python.org/projects/python/";,
defaultBranch="trunk", mode="copy")
steps = [checkoutstep, ...]
---END---
The tricky part is getting branch-annotated Changes into the buildbot in the
first place. I assume you're using the svn_buildbot.py script. The version
provided in the current release always sets the branch to 'None', which
implies the default branch. You will have to edit this script to give it the
ability to decide which branch each change is for (by adding some code which
does a test like filename.startswith("trunk/"), perhaps), then include the
branch name in the RPC call that informs the buildmaster about the new
Change. Basically you'll need to change this call:
return persp.callRemote('addChange', {'who': who,
'files': changed,
'comments': message,
'revision': revision})
into one like:
branchname = "trunk" # or "branches/release24-maint"
return persp.callRemote('addChange', {'who': who,
'branch': branchname,
'files': changed,
'comments': message,
'revision': revision})
There's been some discussion on the buildbot-devel list about the best way to
implement branch-determination. One school of thought says it belongs close
to the repository (hence inside a hook script like svn_buildbot.py). Another
says it is easier to configure from the buildbot side, in which case you'd
probably want to modify buildbot.changes.pb.PBChangeSource to analyze the
filenames and decide which branch they live on there.
There was also a patch[1] to add some regexps to svn_buildbot.py to do this
kind of branch determination. I haven't been able to review it properly yet,
but it may give you some ideas. svn_buildbot.py certainly needs help here.
The rest of the Buildbot is branch-enabled and ready to go. The only
lingering issues are with status delivery: the main HTML "Waterfall" HTML
will interleave builds of both branches on the same page, which could be a
bit confusing (if the top line is red, does that mean the trunk is broken, or
the 2.4 branch?). Fixing this (by creating separate pages for each branch) is
high on the TODO list.
If there's any way I can help out further, please let me know. I'm ecstatic
that Python is using a buildbot.. if you have any feature suggestions or bug
reports, please send them to me, to the buildbot-devel mailing list[2], or
file them in the sf.net bugtracker[3]. Or corner me at PyCon, or in #twisted
(where I can sometimes be found as ).
thanks!
-Brian (author of Buildbot)
[1]: http://sourceforge.net/mailarchive/message.php?msg_id=13977004
[2]: http://sourceforge.net/mailarchive/forum.php?forum=buildbot-devel
[3]: http://sourceforge.net/projects/buildbot/
Re: [Python-Dev] slight inconsistency in svn checkin email subject lines
Walter Dörwald wrote: > And while we're at it, could you remove the "commit of" too? IMHO it > just obscures the real content of the subject. Done. FYI, the rationale for this prefix was that post-commit distinguishes between "commit" and "revprop", where revprop would indicate that properties changed, not the contents. I just noticed that this is not actually post-commit, but that there is a second hook, post-revprop-change, which I hadn't filled out yet. I just created the hook; because I dropped the prefix, commit and revprop mails will have the same subject. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Real time behaviour of Pythons memory management; WAS: RE: Documentation about Python's GC,python-dev list messages referenced in Modules/gcmodule.c notreachable anymore
Garbage Collector findings To understand pythons garbage collector better and to get a picture about the runtime behaviour and performance I did some experiments: The attached script allocates a lot of circularly self referencing lists. Then it instantiates a one item list. I tuned the loop counter in such a way that the subsequent instantiation of the one item list triggers the garbage collector. The number of the circularly self referencing objects is around 9. Results (Pentium4 3GHz, Python 2.4.1 on cygwin/Win2k) - gc gen 1) | time msec 2) | unreachable 3) ---+--+ None | 0.000| All 0 | 0.002| All 1 | 0.007| All 2 | 0.065| All None | 0.000| None 0 | 0.001| None 1 | 0.003| None 2 | 0.018| None --> Collecting a self referencing list costs about 0.7 usec (micro seconds) --> Checking a non collectable self ref list costs about 0.2 usec (micro seconds) Legend: 1) the generation the garbage collector has been triggered to collect (None means that GC wasn't triggered) 2) time for instantiating a list with one entry in msec 3) All: All of the circularly self referencing lists were **unreachable** (thus got collected by the gc) None: None of the circularly self referencing lists were **unreachable** (no garbage available to collect) Questions - 1. Am I correct that in a system which instantiates a lot*) of containerish objects without destructing them again the GC may be triggered to evaluate all generations which may be very costy (see above)? 2. In a system where only generation 0 and 1 get evaluated (because not so much object got instantiated without beeing destructed) the costs are relatively low. Correct? *) a lot means here: more than ``threshold0 * threshold1 * threshold2`` objects, Python 2.4 default values are: 700*10*10 = 7 Gregoire P.S.: Interestingely the counters found by experimenting seem to depend on the platform (my platform: Python 2.4.1, cygwin under Win2k, the counters aren't valid for native Python 2.4.2 under Win2k). gctest.py Description: gctest.py ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot
> "Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes: Martin> It *is* a bug for Python to emit warnings on "major Martin> platforms" (PEP 7). OK, I'm as big a standards bigot as the next guy, you hooked me. After some consideration, I can't write the patch, though. I'm sorry that all I can offer is time and trouble testing on a Mac G4 running Panther (10.3.9), but for what it's worth, I offer it. I'll get the workspace ready, and when there's a patch, I'll test it. Martin> Also, it would be good if PEP 11 was considered before Martin> breaking platforms. I don't think Apple is ever likely to consider Python PEPs when revising its standard headers in incompatible ways.<0.5 wink> -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] file.next() vs. file.readline()
Twice now, I've been bitten by the 'mixing file-iteration with readline' issue. (Yeah, twice.. Good thing I don't write anything important in Python ;) I've also seen a number of newbies bitten by the same thing. The issue, for those that aren't aware, is that when mixing file-iteration and readline (or readlines or such), you run the risk of getting data in the wrong order. This is because file-iteration uses an 8k buffer, while readline doesn't. It's not really a big deal, once you understand it's not wise to mix iteration and the readline(s) methods. I do wonder, though, why Python doesn't take care to raise an exception when readline is called with 'stuff' in the iteration-buffer. A cursory look at the source doesn't reveal any glaring problems. It's a single check, possibly two, with good locality of reference. Also, raising an exception when there is stuff in the buffer would only make mixing iteration/readline an error when you would actually, in fact, lose or mess up data. In other words, it would only raise exceptions for existing cases that are already broken. Is there something I've missed that makes the check undesireable or unfeasible? Or should I just assume no on has gotten around to it (or could be bothered), and just submit a patch? :) (Making readline and friends use the same buffer may seem the better solution to some, but I'm sure there's a whole discussion behind that, about whether to buffer or not. All non-iteration routines in fileobject.c take pretty good care not to read too much, and I choose to see that as explicitly designed that way.) Absent-ly y'rs, -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file.next() vs. file.readline()
I'd say go right ahead and submit a change to SF (and then after it's reviewed you can check it in yourself :-). The only reason I can think of why this isn't done yet would be that nobody thought of it. Of course there are other ill-advised combinations, like write followed by read for which stdio doesn't guarantee any result in particular. In Py3K I want to revise the whole I/O stack to be independent from C stdio (except on those platforms where that's the only I/O you have.) --Guido On 1/4/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > Twice now, I've been bitten by the 'mixing file-iteration with readline' > issue. (Yeah, twice.. Good thing I don't write anything important in > Python ;) I've also seen a number of newbies bitten by the same thing. The > issue, for those that aren't aware, is that when mixing file-iteration and > readline (or readlines or such), you run the risk of getting data in the > wrong order. This is because file-iteration uses an 8k buffer, while > readline doesn't. It's not really a big deal, once you understand it's not > wise to mix iteration and the readline(s) methods. > > I do wonder, though, why Python doesn't take care to raise an exception when > readline is called with 'stuff' in the iteration-buffer. A cursory look at > the source doesn't reveal any glaring problems. It's a single check, > possibly two, with good locality of reference. Also, raising an exception > when there is stuff in the buffer would only make mixing iteration/readline > an error when you would actually, in fact, lose or mess up data. In other > words, it would only raise exceptions for existing cases that are already > broken. > > Is there something I've missed that makes the check undesireable or > unfeasible? Or should I just assume no on has gotten around to it (or could > be bothered), and just submit a patch? :) > > (Making readline and friends use the same buffer may seem the better > solution to some, but I'm sure there's a whole discussion behind that, about > whether to buffer or not. All non-iteration routines in fileobject.c take > pretty good care not to read too much, and I choose to see that as > explicitly designed that way.) > > Absent-ly y'rs, > -- > Thomas Wouters <[EMAIL PROTECTED]> > > Hi! I'm a .signature virus! copy me into your .signature file to help me > spread! > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Sharing between multiple interpreters and restricted mode
Hi, At the company I work for we've embedded Python 2.4.1 in a C++ application. We execute multiple scripts concurrenlty, each one in its own interpreter (created using Py_NewInterpreter()). We are sharing a certain instance between interpreters because its to expensive to instantiate that class every time an interpreter is created. The class is instantiated in the main interpreter (that is always alive) and every time a new interpreter is created, that instance is added to the interpreter's __builtins__ dict. The problem I'm having is that some methods of that class (when executed in an interpreter different from the one it was created in) complain about being in restricted execution mode. Assuming that there are no issues with this instance lifetime (coz it will always be referenced by the main interpreter), is there a safe way to do some sharing between interpreters ?. Thanks. -- Gabriel Becedillas Developer CORE SECURITY TECHNOLOGIES Florida 141 - 2º cuerpo - 7º piso C1005AAC Buenos Aires - Argentina Tel/Fax: (54 11) 5032-CORE (2673) http://www.corest.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sharing between multiple interpreters and restricted mode
This is more a question for c.l.py. My own suggestion is to go back to a single shared interpreter; what's the value of separate interpreters if you're sharing objects anyway? Sharing Python code between interpreters is definitely not supported. If you insist on separate interpreters, an alternative solution to your heavyweight shared object might be a lighter-weight facade for that object which can be instantiated separately in each interpreter? --Guido On 1/4/06, Gabriel Becedillas <[EMAIL PROTECTED]> wrote: > Hi, > At the company I work for we've embedded Python 2.4.1 in a C++ > application. We execute multiple scripts concurrenlty, each one in its > own interpreter (created using Py_NewInterpreter()). > We are sharing a certain instance between interpreters because its to > expensive to instantiate that class every time an interpreter is > created. The class is instantiated in the main interpreter (that is > always alive) and every time a new interpreter is created, that > instance is added to the interpreter's __builtins__ dict. > The problem I'm having is that some methods of that class (when > executed in an interpreter different from the one it was created in) > complain about being in restricted execution mode. > Assuming that there are no issues with this instance lifetime (coz it > will always be referenced by the main interpreter), is there a safe way > to do some sharing between interpreters ?. > Thanks. > > -- > > Gabriel Becedillas > Developer > CORE SECURITY TECHNOLOGIES > > Florida 141 - 2º cuerpo - 7º piso > C1005AAC Buenos Aires - Argentina > Tel/Fax: (54 11) 5032-CORE (2673) > http://www.corest.com > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot
On 4-jan-2006, at 0:51, Bob Ippolito wrote: > > On Jan 3, 2006, at 3:12 PM, Martin v. Löwis wrote: > >> Bob Ippolito wrote: >>> Who's going to bother? >> >> It violates PEP 7, unless you argue that OS X/gcc is not >> a "major compiler". > > Clearly, but that still doesn't answer the question of who's going to > do it. Writing two code paths with availability macros and all the > testing involved is a whole lot of work to fix a harmless warning on > older versions of the OS. If it actually caused a problem I'm sure > someone would go through the trouble, but in this case it's probably > not worth the effort. More energy seems to be spent on talking about this than implementing the required patch :-) This should do it, although I haven't tested this on OSX 10.3: diff -u Python-2.4.2/Modules/getpath.c Python-2.4.2-orig/Modules/ getpath.c --- Python-2.4.2/Modules/getpath.c 2006-01-04 21:06:17.0 +0100 +++ Python-2.4.2-orig/Modules/getpath.c 2004-08-08 03:00:47.0 +0200 @@ -381,12 +381,8 @@ NSModule pythonModule; #endif #ifdef __APPLE__ -#ifdef MAC_OS_X_VERSION_10_4 -uint32_t nsexeclength = MAXPATHLEN; -#else unsigned long nsexeclength = MAXPATHLEN; #endif -#endif /* If there is no slash in the argv0 path, then we have to * assume python is on the user's $PATH, since there's no > > -bob > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ > ronaldoussoren%40mac.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] TAR problems under Solaris
Recently, someone on dclpy posted about an error he got when he tried to unpack the Python distribution tarball with Sparc Solaris 9's tar: tar: directory checksum error With GNU tar, it worked correctly. Is this a known issue, or is it irrelevant? Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] TAR problems under Solaris
[Reinhold Birkenfeld] > Recently, someone on dclpy posted about an error he got > when he tried to unpack the Python distribution tarball > with Sparc Solaris 9's tar: > > tar: directory checksum error > > With GNU tar, it worked correctly. > > Is this a known issue, or is it irrelevant? It's a known issue for just about every tarball-based distribution of every project on the planet. For Python, Solaris tar woes are noted on this page: http://www.python.org/2.4.2/bugs.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] TAR problems under Solaris
Tim Peters wrote: > [Reinhold Birkenfeld] >> Recently, someone on dclpy posted about an error he got >> when he tried to unpack the Python distribution tarball >> with Sparc Solaris 9's tar: >> >> tar: directory checksum error >> >> With GNU tar, it worked correctly. >> >> Is this a known issue, or is it irrelevant? > > It's a known issue for just about every tarball-based distribution of > every project on the planet. For Python, Solaris tar woes are noted > on this page: > > http://www.python.org/2.4.2/bugs.html Ah ok, so never mind. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] TAR problems under Solaris
On Wed, 2006-01-04 at 22:01 +0100, Reinhold Birkenfeld wrote: > Recently, someone on dclpy posted about an error he got > when he tried to unpack the Python distribution tarball > with Sparc Solaris 9's tar: > > tar: directory checksum error > > With GNU tar, it worked correctly. > > Is this a known issue, or is it irrelevant? Dunno, but I'm always having problems w/ Solaris tar, so I just use GNU tar on Solaris. ;) -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] buildno (Was: [Python-checkins] commit of r41907- python/trunk/Makefile.pre.in)
Barry Warsaw wrote: > Unfortunately, /usr/bin/type doesn't seem to accept the -t flag for me > on Solaris 9. Okay, so what's the best (read: portable) way to do this? The portable way would be to check for svnversion in configure, and then only use it if it was found. You could also check for .svn in configure, and generate the entire buildno generation. OTOH, I also think we should get rid of buildno entirely. Instead, svnversion should be compiled into the object file, or, if it is absent, $Revision$ should be used; the release process should be updated to force a commit to the tag/Modules/buildno.c right after creating the tag. sys.build_number should go, and be replaced with sys.svn_info, which should also include the branch from which the checkout/export was made. $Revision$ should only be trusted if it comes from a tag/. Should I write a PEP for that? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Real time behaviour of Pythons memory management; WAS: RE: Documentation about Python's GC,python-dev list messages referenced in Modules/gcmodule.c notreachable anymore
Weber, Gregoire wrote: > Questions > - Notice that this article is not appropriate for python-dev. If you ask "is it the case that Python behaves such and such?", you have a python-list (comp.lang.python) question. For python-dev, the question should be formulated as "because it is such and such, would it be acceptable to change it so and so?" > 1. Am I correct that in a system which instantiates a lot*) >of containerish objects without destructing them again the >GC may be triggered to evaluate all generations which may >be very costy (see above)? Correct. > 2. In a system where only generation 0 and 1 get evaluated >(because not so much object got instantiated without beeing >destructed) the costs are relatively low. Correct? Correct. If the objects are *really* short-lived, a generation 0 collection might never get initiated, even though millions of containers are created. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot
[Brian Warner wrote] >... > The only lingering issues are with status delivery: the main HTML > "Waterfall" HTML will interleave builds of both branches on the same > page, which could be a bit confusing (if the top line is red, does > that mean the trunk is broken, or the 2.4 branch?). Or for separate logic projects being built with the same builtbot master. For example, say Python's buildbot wanted to do regular builds and tests of the distutils tree (http://svn.python.org/view/distutils/trunk/). > Fixing this (by creating separate pages for each branch) is high on > the TODO list. I'm keen to help with that if I can. I'm now subscribed to buildbot-devel (as trentm at gmail) so I can pester you about that there further. Cheers, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot
[Trent Mick wrote] > Or for separate logic projects being built with the same builtbot s/logic/logical/ Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot
Ronald> This should do it, although I haven't tested this on OSX 10.3: Not quite. On my 10.3 system MAC_OS_X_VERSION_10_ for in 0, 1, 2, 3, 4 is defined. However, MAC_OS_X_VERSION_MAX_ALLOWED is defined to be MAC_OS_X_VERSION_10_3. This works for me (compiles with no warnings, passes all tests). Skip % svn diff Modules/getpath.c Index: Modules/getpath.c === --- Modules/getpath.c (revision 41914) +++ Modules/getpath.c (working copy) @@ -381,8 +381,12 @@ NSModule pythonModule; #endif #ifdef __APPLE__ +#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4 uint32_t nsexeclength = MAXPATHLEN; +#else +unsigned long nsexeclength = MAXPATHLEN; #endif +#endif /* If there is no slash in the argv0 path, then we have to * assume python is on the user's $PATH, since there's no ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] TAR problems under Solaris
On Thursday 05 January 2006 08:23, Barry Warsaw wrote: > Dunno, but I'm always having problems w/ Solaris tar, so I just use > GNU tar on Solaris. ;) Maybe we should switch to cpio-based distributions? Anthony ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
