[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.
>> ...
>> 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.
> So still ain't my fault. =)
No, you're so argumentative today I'm starting to suspect it is ;-)
...
>> 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.
_______________________________________________
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
