bug#53903: aarch64: failed to compute the derivation for Guix

[Ricardo Wurmus <rekado@elephly.net>]

Christopher Baines <mail@cbaines.net> writes:

>>> Looks like this derivation can be built at least:
>>>
>>>   https://data.guix.gnu.org/gnu/store/2j5348zpz32qmb7x4v5ipg26d269hgxf-coreutils-8.32.drv
>>
>> Interesting.  I wonder what machine built it; maybe it succeeds in qemu.
>> The honeycombs here all cannot “guix pull”, so I suspect that they all
>> fail to build it.
>
> Unfortunately, looking up what machine built it requires poking in the
> build coordinator database currently. I looked, and it was monokuma (an
> Overdrive machine).

Interesting, thanks for digging!

>>>> 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.

-- 
Ricardo