[Python-Dev] [Python-checkins] buildbot warnings in hppa Ubuntu dapper trunk (original) (raw)

Tim Peters tim.peters at gmail.com
Fri Jun 9 04:56:27 CEST 2006

[Tim]

FYI, here's the minimal set of failing tests:

$ pythond ../Lib/test/regrtest.py testfile testoptparse testfile testoptparse test testoptparse failed -- Traceback (most recent call last): File "C:\Code\python\lib\test\testoptparse.py", line 1042, in test_filetype_noexist testsupport.TESTFN) File "C:\Code\python\lib\test\testoptparse.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 reruns 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 testfile must run before testoptparse, and it looks like the problem goes away if "too many"(!) other tests intervene. The Win2K buildbot is unique in that testfile has been followed very soon by testoptparse 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.

More information about the Python-Dev mailing list