<br><br><div><span class="gmail_quote">On 6/8/06, <b class="gmail_sendername">Tim Peters</b> <<a href="mailto:tim.peters@gmail.com">tim.peters@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[Tim]<br>>> FYI, here's the minimal set of failing tests:<br>>><br>>> $ python_d ../Lib/test/regrtest.py test_file test_optparse<br>>> test_file<br>>> test_optparse<br>>> test test_optparse failed -- Traceback (most recent call last):
<br>>> File "C:\Code\python\lib\test\test_optparse.py", line 1042, in<br>test_filetype_noexist<br>>> test_support.TESTFN)<br>>> File "C:\Code\python\lib\test\test_optparse.py", line 158, in
<br>assertParseFail<br>>> self.assertFalse("expected parse failure")<br>>> AssertionError<br><br>[Brett]<br>> Different type of failure as well;<br><br>Not so.<br><br>> if you look at the original failure it has to do with the help output
<br>> having an extra newline.<br><br>While if you look at the original failure ;-), you'll see that _both_<br>failure modes occur. The one I showed above occurs when test_optparse<br>runs the first time; the one you're thinking of occurs when regrest
<br>*re*runs test_optparse in verbose mode. The original HPPA log<br>contained both failures.</blockquote><div><br>Ah, my mistake. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>> ...<br>>> I have no idea why any of this is true, but there's good and bad news:<br>>> reverting rev 46757 does _not_ make the problem go away.<br><br>> Actually, that run had two checkins; there was also 46755.
<br><br>Build 992 on the W2k trunk buildbot had only 46757 in its blamelist,<br>and was the first failing test run there.<br><br>> But when I ``svn update -r46754`` it still fails on my OS X laptop.<br><br>What revision was your laptop at before the update? It could help a
<br>lot to know the earliest revision at which this fails.</blockquote><div><br>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. </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> So still ain't my fault. =)<br><br>No, you're so argumentative today I'm starting to suspect it is ;-)</blockquote><div><br>Sorry, but at the moment Python is failing on ``make install`` when it runs compileall . <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">...<br><br>>> As to why the failure only showed up recently, I'm not sure, but
<br>>> test_file must run before test_optparse, and it looks like the problem<br>>> goes away if "too many"(!) other tests intervene. The Win2K buildbot<br>>> is unique in that test_file has been followed very soon by
<br>>> test_optparse two builds in a row.<br><br>> We don't have any mechanism in place to record when we find tests failing in<br>> a row to always run them in that order until we fix it, do we?<br><br>That's right -- none. If would be easy to check in a little temporary
<br>tweak -- think I'll do that.<br><br>> Nor do we have a script to just continually check out older revisions<br>> in svn, compile, and test until the tests do pass, huh?<br><br>We don't, and I don't either. IIRC, Neil did quite a bit of that some
<br>time ago, and he may have a script for it. Doing a binary search<br>under SVN should be very easy, given that a revision number identifies<br>the entire state of the repository.<br></blockquote></div><br><br>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.
<br><br>-Brett<br>