This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Status of build bots?
On 8/22/19 11:47 AM, Mark Wielaard wrote:
On Thu, Aug 22, 2019 at 09:35:36AM +0200, Stefan Liebler wrote:
I've just had a look into the logs of some of the last builds of s390x
buildbot (before it was down). There I could always see: "No space left on
device".
It was actually a file sytem corruption, that showed up as "no space
left". The problem is that for other projects using this machine for
their buildbot it was quickly noticed and reported, but for glibc
nobody seemed to be monitoring the results.
Also before that file system issue the build also didn't work. And
all other buildbot workers also look red (for months). The problem is
that there is no known "good set" of test results and since there are
always build steps or tests failing you cannot determine if something
is a bad regression or "just" a (known?) failing testcase.
I think before we resurrect the buildbot workers (for whichever
architecture), we should see if we can define a minumum build and test
setup that should always PASS and make the buildbot sent warnings if
that changes. And make sure that someone monitors the results. And/Or
that making a buildbot worker turn red is a reason for reverting a
commit.
Cheers,
Mark
I've had a look at some older builds:
Can anybody help to find out what was going wrong here:
http://glibc-buildbot.reserved-bit.com/builders/glibc-s390x-linux/builds/2640/steps/check%20%28clobber%29/logs/stdio
I've only see:
make[1]: *** [Makefile:412: tests] Error 1
make[1]: Target 'check' not remade because of errors.
make[1]: Leaving directory
'/home/mjw/glibc/build/glibc-s390x-linux/build/glibc'
make: *** [Makefile:9: check] Error 2
Some other builds show those FAILs:
In your previous post, you've said "The s390x worker is somewhat
overloaded". Sometimes, I also see fails on machines where either the
current system itself or other lpars/zVM-guests are "overloaded".
FAIL: nptl/tst-create-detached
FAIL: nptl/tst-mutex10
=> then, you'll see timeouts
FAIL: rt/tst-cpuclock1
=> then, you'll see something like that "before - after 0.690189364
outside reasonable range"
FAIL: nss/tst-nss-files-hosts-getent
FAIL: nss/tst-nss-files-hosts-long
=> I've only saw this due to bug fixed with "test-container: Install
with $(sorted-subdirs) [BZ #24794]"
(https://sourceware.org/git/?p=glibc.git;a=commit;h=354e4c1adddb1da19c1043e3e5db61ee2148d912)
But I don't know if this was the case in the buildbot-build.
I've never seen these fails before. Does those also time out?
FAIL: nptl/tst-mutexpi7a
FAIL: nptl/tst-thread-affinity-pthread2