On Fri, 15 Sep 2017 22:14:31 -0400, Augie Fackler <r...@durin42.com> wrote:
On Sep 15, 2017, at 22:08, Augie Fackler <r...@durin42.com> wrote:
# HG changeset patch
# User Augie Fackler <au...@google.com>
# Date 1505527705 14400
# Fri Sep 15 22:08:25 2017 -0400
# Node ID 0da0e691552a428641c75e1633e5f1d0fbf3483e
# Parent 209120041d12b524648fa856732aa404dfedd91d
tests: add and remove some (glob) markers
These are the sane-looking failures on the Windows buildbot. The
run-tests failure looks like some sort of environment variable setting
dance is failing on Windows (huh?), and I'm singularly baffled by the
test-patchbomb-tls.t failure. But we're close to getting that builder to
pass.
I'm baffled by the run-tests failure too. The test runs fine outside of
buildbot on that system. Any chance you can force a debug run of this
test, to see what is lurking behind $RUNTESTDIR?
The patchbomb test failure is transient. I've seen cases where `hg serve`
daemons from the previous run aren't killed for some reason. Aside from
subsequent serve errors, a telltale sign is the warnings in the build
phase dropping from 7 to 1, as the C code isn't rebuilt. (Compare
before[1] and after[2] the Patch Tuesday reboot.) When I notice that, I
have to manually kill off the stuck python process. But sometimes there
is no stuck process, and these *.t errors clear on their own. I wonder if
the serve process looks like it is running to the parent process, which
stops waiting, but it hasn't opened the listening port yet when a test
process tries to connect.
I'll check Monday to see if python processes are stuck.
[1]
https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/181/steps/make%20local/logs/stdio
[2]
https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/183/steps/make%20local/logs/stdio
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
