On 6/8/06, Tim Peters <[EMAIL PROTECTED]> wrote:
Ah, my mistake.
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.
Sorry, but at the moment Python is failing on ``make install`` when it runs compileall .
[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
_______________________________________________ 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
