Ricardo Wurmus <rekado@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.

That suggests it's probably a test suite issue, triggered by having more
cores.