Test failures on buildbot
Remy Blank
(the timezone fix). For example:
Unfortunately, all tests pass on all my machines (Linux + OS X), both
with and without pytz. Any ideas what could be wrong?
Tim, what version of pytz do you have on your test machines?
-- Remy
Christian Boos
results, which is our own tzinfo subclass.
-- Christian
Remy Blank
>> Tim, what version of pytz do you have on your test machines?
>
> None I guess, as I see <FixedOffset "GMT +1:00" 1:00:00> in the test
> results, which is our own tzinfo subclass.
That was also my guess, but I could reproduce the issue neither with nor
without pytz.
If pytz is not installed, how could two Linux platforms have different
behaviors for this, if we only use our own timezone classes (which don't
use local TZ info)? It would basically mean that the datetime module, in
particular datetime.replace(), behaves differently.
-- Remy
Christian Boos
in a non-DST timezone.
I suppose the test has to take this into account, for choosing an
appropriate expected value.
-- Christian
Remy Blank
> Right, look at time.daylight usage in the code. Tim's buildbot must live
> in a non-DST timezone.
Correct, I could finally reproduce the issue by switching my timezone to
PST. Actually, any timezone different from the one used in that
particular test (which happens to be mine) reproduces the issue.
> I suppose the test has to take this into account, for choosing an
> appropriate expected value.
No, actually some of the changes in [8831] were wrong. The issue is
fixed with [8857]. I guess we now have enough reasons to make a second
release candidate...
-- Remy
Tim Hatch
> Christian Boos wrote:
>> Right, look at time.daylight usage in the code. Tim's buildbot must live
>> in a non-DST timezone.
>
> Correct, I could finally reproduce the issue by switching my timezone to
> PST. Actually, any timezone different from the one used in that
> particular test (which happens to be mine) reproduces the issue.
In other testing news, it looks like the minimum Genshi version has
increased again (beyond what I had on the OS X box), causing
strange-looking failures running trac-admin. At some point we need to
make a test for that to get an understandable failure.
There was a single recent failure on the Ubuntu builder because it
required an edit to not be made by "anonymous" but "anonymous" was
contained in one of the words in my dictionary file which happened to be
chosen for the edit text -- a re-run fixed it. Eventually we should
trim out such words in trac/tests/contentgen.py
There was a single recent failure on the Windows 7 builder because it
couldn't rename a file. This was likely related to this builder being
virtualized, and it being windows. A re-run fixed it.
There's an issue running the tests on Windows Vista and Windows 7 in
certain circumstances, and the stdlib needs a one-line patch being
discussed in http://bugs.python.org/issue6906
Tim
Remy Blank
Tim Hatch wrote:
> In other testing news, it looks like the minimum Genshi version has
> increased again (beyond what I had on the OS X box), causing
> strange-looking failures running trac-admin. At some point we need to
> make a test for that to get an understandable failure.
Yes, Christopher has merged the advanced-i18n branch back into trunk,
and we now require at least that revision. When you say "strange-looking
failures running trac-admin", I assume you mean that trac-admin refuses
to run because Genshi>=0.6dev-r1072 is not provided, right?
> There was a single recent failure on the Ubuntu builder because it
> required an edit to not be made by "anonymous" but "anonymous" was
> contained in one of the words in my dictionary file which happened to be
> chosen for the edit text -- a re-run fixed it. Eventually we should
> trim out such words in trac/tests/contentgen.py
I have also seen spurious failures due to random words being too long.
Some tests choose 5 random words e.g. for ticket summaries, and if all
words are relatively long, format_to_oneliner() shortens the summary
with an ellipsis, which makes some tests fail.
-- Remy
Tim Hatch
>> In other testing news, it looks like the minimum Genshi version has
>> increased again (beyond what I had on the OS X box), causing
>> strange-looking failures running trac-admin. At some point we need to
>> make a test for that to get an understandable failure.
>
> Yes, Christopher has merged the advanced-i18n branch back into trunk,
> and we now require at least that revision. When you say "strange-looking
> failures running trac-admin", I assume you mean that trac-admin refuses
> to run because Genshi>=0.6dev-r1072 is not provided, right?
it's a version issue. Functional test output is much better, containing
a single failure with the traceback from the failed
pkg_resources.require(). We should either skip the trac-admin tests
when this requirement isn't met, or fail the whole test since running
Trac without current Genshi isn't supported as far as I know.
Unit:
http://buildbot.timhatch.com/trac/builders/OS%20X%2010.5%20py26%20intel/builds/50/steps/unit%20tests/logs/stdio
Functional:
http://buildbot.timhatch.com/trac/builders/OS%20X%2010.5%20py26%20intel/builds/50/steps/functional%20tests/logs/stdio
> I have also seen spurious failures due to random words being too long.
> Some tests choose 5 random words e.g. for ticket summaries, and if all
> words are relatively long, format_to_oneliner() shortens the summary
> with an ellipsis, which makes some tests fail.
up. Let me know of any other issues you notice.
Tim
Remy Blank
> We should either skip the trac-admin tests
> when this requirement isn't met, or fail the whole test since running
> Trac without current Genshi isn't supported as far as I know.
I'd suggest the latter. There may be other spurious failures due to an
insufficient version of Genshi, so we had better exit early with an
explicit error message.
-- Remy