bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ricardo Wurmus
Subject: bug#53903: aarch64: failed to compute the derivation for Guix
Date: Thu, 10 Feb 2022 10:49:55 +0100
User-agent: mu4e 1.6.10; emacs 27.2

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]