[Python-checkins] r46971 - python/trunk/Lib/test/test_zipfile64.py

Fri Jun 16 01:47:55 CEST 2006

On 6/15/06, Neal Norwitz <nnorwitz at gmail.com> wrote:
>> On 6/15/06, Tim Peters <tim.peters at gmail.com> wrote:
> > > Author: neal.norwitz
> > > Date: Thu Jun 15 11:57:03 2006
> > > New Revision: 46971
> > >
> > > Modified:
> > > python/trunk/Lib/test/test_zipfile64.py
> > > Log:
> > > Steal the trick from test_compiler to print out a slow msg.
> > > This will hopefully get the buildbots to pass. Not sure this
> > > test will be feasible or even work. But everything is red now,
> > > so it can't get much worse.
> >
> > This isn't going to work ;-)
> >
> > Most of the buildbots fail with "No space left on device", and that
> > was after I rearranged the test to cut down the peak disk use. I'm
> > not sure exactly what that is now, but it's at least
> >
> > 6442244863 +たす 28888889 =わ 6,471,133,752
> >
> > bytes.
> >
> > It seems likely to me that some of the failing buildbots have that
> > much free disk space, but not on the partition used by TemporaryFile()
> > (multi-gigabyte temp-space partitions are rare in my Unixy
> > experience).
> >
> > Anyway, fix that and then there's that this test alone takes 50%
> > longer than all the rest of the -uall tests combined on my box.
> >
> > I don't have a solution in mind other than disabling this test, but
> > for 2.5b1 that's a "good enough" solution for me.
>> I've come to a similar conclusion. I thought about checking the disk
> available before trying to run the test and skipping the test in that
> case. But it doesn't address how long it takes to run this test.
> Maybe this should be like one of the bigmem tests?

Sounds like it. I don't think it necessarily calls for its own -u option
for regrtest with bigmem being available.
-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-checkins/attachments/20060615/511d2f53/attachment-0001.htm