Christopher Baines <m...@cbaines.net> writes:
> Ricardo Wurmus <rek...@elephly.net> writes: > >>>>>> View build log at >>>>>> '/var/log/guix/drvs/2j/5348zpz32qmb7x4v5ipg26d269hgxf-coreutils-8.32.drv.bz2'. >>>>> >>>>> Would you be able to share this log, or at least the last bit of it? >>>> >>>> There’s one failing test: >>>> >>>> ==> foo <== >>>> + fail=1 >>>> + break >>>> + Exit 1 >>>> + set +e >>>> + exit 1 >>>> + exit 1 >>>> + remove_tmp_ >>>> + __st=1 >>>> + cleanup_ >>>> + kill 23895 >>>> + wait 23895 >>>> + test '' = yes >>>> + cd /tmp/guix-build-coreutils-8.32.drv-0/coreutils-8.32 >>>> + chmod -R u+rwx >>>> /tmp/guix-build-coreutils-8.32.drv-0/coreutils-8.32/gt-assert.sh.B8Wf >>>> + rm -rf >>>> /tmp/guix-build-coreutils-8.32.drv-0/coreutils-8.32/gt-assert.sh.B8Wf >>>> + exit 1 >>>> FAIL tests/tail-2/assert.sh (exit status: 1) >>> >>> I tried building this derivation on the HoneyComb machine hooked up to >>> bordeaux.guix.gnu.org, and it fails to build in the same way. >>> >>> Maybe this is a failure that happens (or is more likely) with more >>> cores. The linux-libre version is slightly different on monokuma as >>> well, it's running 5.12.17-gnu currently. >> >> Thanks for reproducing this issue! I wonder what we should do about >> this; is it a real problem in coreutils, a problem with the test suite, >> or something else. >> >> To get past this we could replace coreutils on aarch64 with a package >> that disables this test, but before attempting to implement this >> workaround I’d like to know if there’s a real problem that also needs to >> be addressed. > > I tried building it again on the Overdrive machine, and it succeeded. I > also tried building it with --cores=1 on the HoneyComb machine and that > succeeded too. I have not been able to build this on Kreuzberg (a HoneyComb machine) with “--cores=1”. The same test keeps failing. I tried this at least five times. -- Ricardo