This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: buildbot is green!


> LC_ALL=C readelf -W -d /mnt/b/glibc-ubuntu-trusty-slave2/glibc-i686-linux/build/build/rt/librt.so > /mnt/b/glibc-ubuntu-trusty-slave2/glibc-i686-linux/build/build/rt/librt.so.dynT
> test -s /mnt/b/glibc-ubuntu-trusty-slave2/glibc-i686-linux/build/build/rt/librt.so.dynT
> mv -f /mnt/b/glibc-ubuntu-trusty-slave2/glibc-i686-linux/build/build/rt/librt.so.dynT /mnt/b/glibc-ubuntu-trusty-slave2/glibc-i686-linux/build/build/rt/librt.so.dyn
> make[1]: *** [tests] Error 1
> make[1]: Target `check' not remade because of errors.
> make[1]: Leaving directory `/mnt/b/glibc-ubuntu-trusty-slave2/glibc-i686-linux/build/glibc'
> make: *** [check] Error 2
> make: Leaving directory `/mnt/b/glibc-ubuntu-trusty-slave2/glibc-i686-linux/build/build'

Yup, that's what it looks like.  What's probably more useful is to
try to replicate what the bot script does locally so you can manage
to reproduce this failure by hand.

> Which is elf/Makefile:

As Joseph pointed out, your analysis makes no sense.  There should
be a *** line for each particular command that failed, telling us
the leaf target involved.

> The slave looks like it's dead now though?

No, that would show as a purple status or something like that.

> http://130.211.48.148:8080/builders/glibc-i686-linux/builds/515/steps/update%20scripts/logs/stdio
> ~~~
> fatal: read error: Connection reset by peer
> program finished with exit code 128
> ~~~

This just means the "update" step failed.  That error is from git.
It was just a sourceware (or network) hiccup.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]