Re: [Linaro-toolchain-builds] [cbuild] gcc-linaro-4.7-2012.08 armv7l failed

On 15 August 2012 00:45, Matthew Gretton-Dann matthew.gretton-dann@linaro.org wrote:

So looking at the logs this seems to be a transient data transfer error:

The logs (http://builds.linaro.org/toolchain/gcc-linaro-4.7-2012.08/logs/armv7l-natty-...) have:

make[4]: Entering directory `/scratch/cbuild/slave/slaves/tcpanda02' make -s -f ../../lib/fetch.mk gcc-linaro-4.7-2012.08/gcc-linaro-4.7-2012.08.tar-spawn 2>&1 | grep -v '^make[' Trying http://builds.linaro.org/toolchain/snapshots/gcc-linaro-4.7/gcc-linaro-4.7-2... Trying http://ex.seabright.co.nz/snapshots/gcc-linaro-4.7/gcc-linaro-4.7-2012.08.ta... Trying http://builds.linaro.org/toolchain/snapshots/gcc-linaro-4.7-2012.08.tar.xz Trying http://ex.seabright.co.nz/snapshots/gcc-linaro-4.7-2012.08.tar.xz Trying http://builds.linaro.org/toolchain/snapshots/gcc-linaro-4.7/gcc-linaro-4.7-2... Trying http://ex.seabright.co.nz/snapshots/gcc-linaro-4.7/gcc-linaro-4.7-2012.08.ta... Trying http://builds.linaro.org/toolchain/snapshots/gcc-linaro-4.7-2012.08.tar.bz2 Trying http://ex.seabright.co.nz/snapshots/gcc-linaro-4.7-2012.08.tar.bz2 bunzip2: gcc-linaro-4.7-2012.08/gcc-linaro-4.7-2012.08.tar.bz2: data integrity (CRC) error in data

Not sure here. ex.seabright is the authoritative source. Perhaps there was a fault with the proxy in the control lab?

The good news is that the test fired and the build failed early. I've logged LP: #1036867 to see if it happens again.

The x86_64 build has succeeded OK though, so I (well Ramana really) have, eventually, restarted that build. We did encounter some issues with restarting the build as follows:

1. My Launchpad ID doesn't have permissions to spawn jobs through the

web interface at ex.seabright.co.nz

Fixed.

2. So I attempted to spawn the job manually as follows:

   $ ssh -p7023 cbuild@ex.seabright.co.nz ./cbuild/tools/spawn.sh

gcc-linaro-4.7-2012.08 armv5-builder Spawning gcc-linaro-4.7-2012.08 into the queue benchmarks Spawned into a9-builder

This wasn't exactly what I expected.  What are the correct runes

here to get a build?

Spawn picks the closest spawn class based on the filename or, if supplied, the second argument. Here you supplied 'armv5...' which is closest to 'benchmarks'.

What you want is to click 'Release' beside the job name in the scheduler view, to respawn through the /spawn interface, or to touch the .job file in cbuild@orion:~/queue/armv5-builder.

I've left this job in place as I've probably done enough damage already...

3. Ramana then attempted to use the web-interface at

http://ex.seabright.co.nz/helpers/recent to get the job to rebuild (http://ex.seabright.co.nz/helpers/scheduler/spawn?queue=armv7l&job=gcc-l...). However, this results in a Python exception.

Real men don't use user-friendly argument checking :) Well, not on hacks like this tool. There is no armv7l queue so an assert fired.

4. Finally we used Ramana's credentials on the spawn interface, and

that seems to have spawned the rebuild correctly.

Good.

I'll let this run and see what happens.

Michael, can you just check that things are progressing properly please, and also give me appropriate permissions on the web interface?

Checking: http://ex.seabright.co.nz/helpers/buildlog/gcc-linaro-4.7-2012

shows that the build finished on x86_64 and i686. Checking /scheduler shows that ARM builds are in progress on a9hf, a9, and armv5. Most are in the testsuite and have ~6 hours to go.

-- Michael