Hi Ramana. These are covered by the release process documentation but I thought I'd fill them out.
The builds are completing. You can see the finished grid at: http://ex.seabright.co.nz/helpers/buildlog/gcc-linaro-4.7-2012
Click on 'Compare' for each machine to see the results like: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.7-2012.07/logs/ar...
The test compare picks a close version but falls back to something ancient. Add the correct previous version like: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.7-2012.07/logs/ar...
Check for any differences by searching for 'Just in'. A is the previous release, B is this. There's one regression in http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.7-2012.07/logs/ar...
which is: gcc.target/arm/pr42172-1.c scan-assembler-times ldr 1
I'd normally check our upstream builds: http://ex.seabright.co.nz/helpers/buildlog/gcc-4.7+svn
but this is a ARMv5 fault and we only track Cortex-A9. Checking gcc-testresults shows: http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg00171.html
so the fault is upstream.
I've spawned the test-oecore-gcc-linaro-4.7-2012.07 / x86_64-heavy and ubutest-gcc-linaro-4.7-2012.07 / i686,x86_64 jobs. The results will pop up similar to the 4.6 ones in the buildlog.
-- Michael
On 6 July 2012 00:10, Michael Hope michael.hope@linaro.org wrote:
Hi Ramana. These are covered by the release process documentation but I thought I'd fill them out.
The builds are completing. You can see the finished grid at: http://ex.seabright.co.nz/helpers/buildlog/gcc-linaro-4.7-2012
Click on 'Compare' for each machine to see the results like: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.7-2012.07/logs/ar...
The test compare picks a close version but falls back to something ancient. Add the correct previous version like: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.7-2012.07/logs/ar...
Check for any differences by searching for 'Just in'. A is the previous release, B is this. There's one regression in http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.7-2012.07/logs/ar...
which is: gcc.target/arm/pr42172-1.c scan-assembler-times ldr 1
The test results look fine for all but .
http://ex.seabright.co.nz/build/gcc-linaro-4.7-2012.07/logs/x86_64-precise-c...
thinks the oecore builds failed. Is this the expected behaviour ?
I also don't yet see ubutest or benchmarks for 4.6 having run for the arm boards so I've tried spawning them again.
Ramana
Ramana
I'd normally check our upstream builds: http://ex.seabright.co.nz/helpers/buildlog/gcc-4.7+svn
but this is a ARMv5 fault and we only track Cortex-A9. Checking gcc-testresults shows: http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg00171.html
so the fault is upstream.
I've spawned the test-oecore-gcc-linaro-4.7-2012.07 / x86_64-heavy and ubutest-gcc-linaro-4.7-2012.07 / i686,x86_64 jobs. The results will pop up similar to the 4.6 ones in the buildlog.
-- Michael
On 6 July 2012 00:10, Michael Hope michael.hope@linaro.org wrote:
Hi Ramana. These are covered by the release process documentation but I thought I'd fill them out.
I've found another flaw with the script which means the 4.7 release testing we've done is broken. Before leaving today I thought I'd do a md5sum on the tarball on cbuild@ex.seabright.co.nz and my local disk to satsify my paranoid self. However while doing this I realized that I'd accidentally broken the release because it appears as though the rsync somewhere had failed and I missed noticing the return value somewhere. Unfortunately this means we need to spawn another set of builds.
It would be nice if the script could do an md5sum of the local tarball and the rsync'd tarball to make sure the 2 are identical to prevent such occurrences. Thus a borked rsync from somewhere remotely doesn't end up causing this problem. I'll see what I can do with that. and send a separate patch out. I'll hopefully get it right third time around. Sorry.
regards, Ramana
The builds are completing. You can see the finished grid at: http://ex.seabright.co.nz/helpers/buildlog/gcc-linaro-4.7-2012
Click on 'Compare' for each machine to see the results like: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.7-2012.07/logs/ar...
The test compare picks a close version but falls back to something ancient. Add the correct previous version like: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.7-2012.07/logs/ar...
Check for any differences by searching for 'Just in'. A is the previous release, B is this. There's one regression in http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.7-2012.07/logs/ar...
which is: gcc.target/arm/pr42172-1.c scan-assembler-times ldr 1
I'd normally check our upstream builds: http://ex.seabright.co.nz/helpers/buildlog/gcc-4.7+svn
but this is a ARMv5 fault and we only track Cortex-A9. Checking gcc-testresults shows: http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg00171.html
so the fault is upstream.
I've spawned the test-oecore-gcc-linaro-4.7-2012.07 / x86_64-heavy and ubutest-gcc-linaro-4.7-2012.07 / i686,x86_64 jobs. The results will pop up similar to the 4.6 ones in the buildlog.
-- Michael
On 7 July 2012 05:43, Ramana Radhakrishnan ramana.radhakrishnan@linaro.org wrote:
On 6 July 2012 00:10, Michael Hope michael.hope@linaro.org wrote:
Hi Ramana. These are covered by the release process documentation but I thought I'd fill them out.
I've found another flaw with the script which means the 4.7 release testing we've done is broken. Before leaving today I thought I'd do a md5sum on the tarball on cbuild@ex.seabright.co.nz and my local disk to satsify my paranoid self. However while doing this I realized that I'd accidentally broken the release because it appears as though the rsync somewhere had failed and I missed noticing the return value somewhere. Unfortunately this means we need to spawn another set of builds.
It would be nice if the script could do an md5sum of the local tarball and the rsync'd tarball to make sure the 2 are identical to prevent such occurrences. Thus a borked rsync from somewhere remotely doesn't end up causing this problem. I'll see what I can do with that. and send a separate patch out. I'll hopefully get it right third time around. Sorry.
regards, Ramana
The builds are completing. You can see the finished grid at: http://ex.seabright.co.nz/helpers/buildlog/gcc-linaro-4.7-2012
Click on 'Compare' for each machine to see the results like: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.7-2012.07/logs/ar...
The test compare picks a close version but falls back to something ancient. Add the correct previous version like: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.7-2012.07/logs/ar...
Check for any differences by searching for 'Just in'. A is the previous release, B is this. There's one regression in http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.7-2012.07/logs/ar...
which is: gcc.target/arm/pr42172-1.c scan-assembler-times ldr 1
I'd normally check our upstream builds: http://ex.seabright.co.nz/helpers/buildlog/gcc-4.7+svn
but this is a ARMv5 fault and we only track Cortex-A9. Checking gcc-testresults shows: http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg00171.html
so the fault is upstream.
I've spawned the test-oecore-gcc-linaro-4.7-2012.07 / x86_64-heavy and ubutest-gcc-linaro-4.7-2012.07 / i686,x86_64 jobs. The results will pop up similar to the 4.6 ones in the buildlog.
The md5sum of the files used in the build are now recorded with the build. I'll add a check of the GPG signature.
-- Michael
linaro-toolchain@lists.linaro.org
-
Michael Hope -
Ramana Radhakrishnan