[Python-Dev] trunk buildbot status

Trent Nelson tnelson at onresolve.com
Thu Mar 20 01:26:31 CET 2008

Quick update on the status of the trunk buildbots:

[x86 gentoo trunk (Neal Norwitz)]
This has been failing at the same point for the past couple of days now:
command timed out: 1800 seconds without output, killing pid 15168
process killed by signal 9
program finished with exit code -1

None of the other buildbots seem to be encountering the same problem.  Neal, got any idea what's going on with this one?

[alpha True64 5.1 trunk (Neal Norwitz)]
test_tarfile started failing recently (within the past few days) with CRC checks.  See http://www.python.org/dev/buildbot/trunk/alpha%20Tru64%205.1%20trunk/builds/2712/step-test/0.  Greg updated the test such that it prints out some more detail about the failure so we're waiting on that at the moment.

[hppa Ubuntu trunk (Matthias Klose)]
This has been consistently failing in test_socketserver for as long as I can remember:
make: *** [buildbottest] Alarm clock
program finished with exit code 2

I just updated that test such that it waits 20 seconds instead of 3 seconds at the end of the test if the server hasn't shutdown -- waiting for the test results of this still.

[x86 XP trunk (Joseph Armbruster)]
This box didn't survive the recent build changes, but I can't figure out why, none of the other Windows boxes encounter this error:
The following error has occurred during XML parsing:
File: C:\python\buildarea\trunk.armbruster-windows\build\PCbuild\_bsddb.vcproj
Line: 179
Column: 1
Error Message:
Illegal qualified name character.
The file 'C:\python\buildarea\trunk.armbruster-windows\build\PCbuild\_bsddb.vcproj' has failed to load.

Can someone check a clean trunk build on a Windows system that *only* has Visual C++ Express 2008?  The latest build system updates don't rely on any features of Visual Studio Professional, but the tools use a lot of common files, and perhaps a Service Pack needs to be applied or something.

[amd64 XP trunk (Thomas Heller)]
Builds fine, all tests pass except for test_largefile, which is failing as there's no more space left on the drive ;-)

[x86 XP-4 trunk (David Bolen)]
This is currently flagged as having failed test, but I don't think it's finished building since the finalised build updates, so hopefully the BSDDB errors in the last run will be resolved when it finished the latest build.

[x86 FreeBSD 2 trunk (Jeroen Ruigrok van der Werven)]
This is a FreeBSD 6.3-STABLE box (which switched to curses 5.6 from 5.2) -- there's been an ongoing thread with regards to why curses has started failing, Jeroen can probably provide more info on that.  Either way I don't anticipate a quick fix for this particular slave, unfortuantely.

Neal/Martin, I'd like to promote the following slaves to the stable list:
[g4 osx.4]
[x86 W2k8]
[AMD64 W2k8]
[ppc Debian unstable]
[sparc Ubuntu]
[sparc Debian]
[PPC64 Debian]
[S-390 Debian]
[x86 XP-3]
[amd64 XP]
[x86 FreeBSD]
[x86 FreeBSD 3]

The trunk builds of these slaves have been the most reliable since I've been tracking.


More information about the Python-Dev mailing list