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

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: >> >> $ 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 testfiletypenoexist >> 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 testoptparse runs the first time; the one you're thinking of occurs when regrest reruns testoptparse 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 >> 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.

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