On Mon, Feb 18, 2013 at 11:50:28AM -0500, Tres Seaver wrote:
On 02/18/2013 10:21 AM, Marius Gedminas wrote:
On Mon, Feb 18, 2013 at 10:59:20AM +0200, Marius Gedminas wrote:
On Mon, Feb 18, 2013 at 01:00:02AM +0000, Zope tests summarizer wrote:
[6] Zope 3.4 Known Good Set / py2.4-64bit-linux
No progress here.
I disabled emails from this buildbot because who cares about stuff this ancient, right?
Dunno about that, but the doctest failure in zope.testing.testrunner might be due to some local configuration: basically, there is coverage info jammed into a test summery::
Total: 405 tests, 0 failures, 0 errors in N.NNN seconds. lines cov% module (path) ... testrunner-ex/sample1/sampletests/test1.py) testrunner-ex/sample1/sampletests/test11.py) testrunner-ex/sample1/sampletests/test111.py) testrunner-ex/sample1/sampletests/test112.py) testrunner-ex/sample1/sampletests/test12.py) testrunner-ex/sample1/sampletests/test121.py) testrunner-ex/sample1/sampletests/test122.py) ... False
instead of::
Total: 405 tests, 0 failures, 0 errors in N.NNN seconds. False
Just the reverse, actually. That test is trying to make sure that zope.testing's testrunner has a working --coverage option that prints coverage results. I tried to pdb and saw that the trace.Trace() object created by the test runner gives it back an empty result object (self.calledfuncs is {}). Experiments with python2.4 -m trace --trace helloworld.py show that /usr/lib/python2.4/trace.py seems to work. I gave up at that point. This used to work a few months ago (before I upgraded the OS?), but I can't figure out how to dig out old buildbot build results through its web interface. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development