Home Original page

[Python-Dev] [Python-checkins] buildbot warnings in hppa Ubuntu dapper trunk

Brett Cannon brett at python.org
Fri Jun 9 05:03:19 CEST 2006 
On 6/8/06, Tim Peters <tim.peters at gmail.com> wrote:
>
> [Tim]
> >> FYI, here's the minimal set of failing tests:
> >>
> >> $ python_d ../Lib/test/regrtest.py test_file test_optparse
> >> test_file
> >> test_optparse
> >> test test_optparse failed -- Traceback (most recent call last):
> >>   File "C:\Code\python\lib\test\test_optparse.py", line 1042, in
> test_filetype_noexist
> >>     test_support.TESTFN)
> >>   File "C:\Code\python\lib\test\test_optparse.py", line 158, in
> assertParseFail
> >>     self.assertFalse("expected parse failure")
> >> AssertionError
>
> [Brett]
> > Different type of failure as well;
>
> Not so.
>
> > if you look at the original failure it has to do with the help output
> > having an extra newline.
>
> While if you look at the original failure ;-), you'll see that _both_
> failure modes occur.  The one I showed above occurs when test_optparse
> runs the first time; the one you're thinking of occurs when regrest
> *re*runs test_optparse in verbose mode.  The original HPPA log
> contained both failures.


Ah, my mistake.

>> ...
> >> I have no idea why any of this is true, but there's good and bad news:
> >> reverting rev 46757 does _not_ make the problem go away.
>
> > Actually, that run had two checkins; there was also 46755.
>
> Build 992 on the W2k trunk buildbot had only 46757 in its blamelist,
> and was the first failing test run there.
>
> > But when I ``svn update -r46754`` it still fails on my OS X laptop.
>
> What revision was your laptop at before the update?  It could help a
> lot to know the earliest revision at which this fails.


No clue.  I had not updated my local version in quite some time since most
of my dev as of late has been at work.

> So still ain't my fault.  =)
>
> No, you're so argumentative today I'm starting to suspect it is ;-)


Sorry, but at the moment Python is failing on ``make install`` when it runs
compileall .

...
>
> >> As to why the failure only showed up recently, I'm not sure, but
> >> test_file must run before test_optparse, and it looks like the problem
> >> goes away if "too many"(!) other tests intervene.  The Win2K buildbot
> >> is unique in that test_file has been followed very soon by
> >> test_optparse two builds in a row.
>
> > We don't have any mechanism in place to record when we find tests
> failing in
> > a row to always run them in that order until we fix it, do we?
>
> That's right -- none.  If would be easy to check in a little temporary
> tweak -- think I'll do that.
>
> > Nor do we have a script to just continually check out older revisions
> > in svn, compile, and test until the tests do pass, huh?
>
> We don't, and I don't either.  IIRC, Neil did quite a bit of that some
> time ago, and he may have a script for it.  Doing a binary search
> under SVN should be very easy, given that a revision number identifies
> the entire state of the repository.
>


That would be handy.  Question is do we just want a progressive backtrack or
an actual binary search that goes back a set number of revisions and then
begins to creep back up in rev. numbers when it realizes it has gone back
too far.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060608/c161a02b/attachment.html
More information about the Python-Dev mailing list