bug#43986: core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64

[Danny Milosavljevic]

Finally, I could rerun the tests in guix environment, and they DO NOT FAIL
on aarch64-for-armhf inside guix environment -s armhf-linux grep.

Editing the gettext-minimal package in order to enable tests again and trying 
to enter

  guix environment -s armhf-linux grep

again, sure enough, gettext-minimal fails with the same error again.

What is going on?!

But

 ./pre-inst-env guix build -s armhf-linux grep

works.

But

./pre-inst-env guix environment -s armhf-linux grep

fails in gettext-minimal.

WTF?!

This is on dover.guix.info.


pgpyjbv9p21Aj.pgp
Description: OpenPGP digital signature

bug#43986: core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64

[Danny Milosavljevic]

and sed, while trying to prepare the guix environment for grep.

and gettext-minimal 0.21, while trying to prepare the guix environment for grep.

Happens both with this: guix environment -s armhf-linux --pure grep
And with this: guix environment -s armhf-linux --pure -e '(@@ (gnu packages 
commencement) grep-final)'
That's BEFORE successfully entering the environment.

After fixing all of those, I'm finally in a guix environment for grep.

To be clear, for each of my messages in this bug report, I've made sure to try
it on unmodified core-updates--and it totally fails there, too.

I've not updated from core-updates origin since a few days ago since I don't
want to build all the derivations again.  So Ludo's update of grep to 3.5
I have not seen yet (it's grep 3.4 right now).


pgpDBXobOkTnw.pgp
Description: OpenPGP digital signature

bug#43986: core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64

[Ludovic Courtès]

Marius Bakke  skribis:

> Danny Milosavljevic  writes:
>
>> How do I debug this?
>>
>> $ guix-core-updates/guix/pre-inst-env guix environment -s armhf-linux --pure 
>> grep
>>
>> needs grep (it's in the implicit native inputs), and that grep has a test 
>> failure.
>
> Does this work?
>
>   guix environment -s armhf-linux -e '(@@ (gnu packages commencement) 
> grep-final)'
>
> Otherwise you can approximate it by building with -K, step into the
> /tmp/guix-build-... directory and run 'source environment-variables'.

Also note that I upgraded ‘grep’ to 3.5 in the meantime (commit
370adc91b59ac06243067a31122f567a7c35b24b).

Ludo’.

bug#43986: core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64

[Danny Milosavljevic]

and diffutils, while trying to prepare the guix environment for grep.


pgpFLswkFOvtq.pgp
Description: OpenPGP digital signature

bug#43986: core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64

[Danny Milosavljevic]

and findutils, while trying to prepare the guix environment for grep.


pgpKEz8UicShA.pgp
Description: OpenPGP digital signature

bug#43986: core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64

[bokr]

Hi Danny,

On +2020-10-17 12:20:11 +0200, Danny Milosavljevic wrote:
> How do I debug this?
> 
> $ guix-core-updates/guix/pre-inst-env guix environment -s armhf-linux --pure 
> grep
> 
> needs grep (it's in the implicit native inputs), and that grep has a test 
> failure.

What if the test failure tested a grep feature that you don't actually need 
from the implicit native input grep?

Is there no way to use a fully valid subset of a tool's functionality (that 
excludes irrelevant test failures
of unused broken functionality) if there's a test failure in testing everything?

If one could express a dependency on a limited subset by passing also a 
required-features list, à la ACL?,
maybe dependencies could trigger less builds, and the feature lists might 
reveal opportunities
for optimizing out some dependencies, e.g. where a bash shell's one or two grep 
invocations might
depend on grep only for a regex match that might easily be rewritten with 
bash's own built-in '=~'

One could imagine builds producing ELFs with bitvectors flagging features built 
and tested,
for efficient dynamic safe-capability determination re usage by dependents, but 
I better stop rambling.

So, monolith dependencies vs factoring, how to balance?

> 
> So I can't actually enter the environment for building grep and running
> 
>make check
> 
> .
> 
> What now?

HTWNEU -- Hope This Was Not Entirely Useless :)
-- 
Regards,
Bengt Richter

bug#43986: core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64

[Danny Milosavljevic]

Hi,

core-updates' grep and coreutils fail strerror_r and perror2 tests in 
gnulib-tests on armhf-on-aarch64:

guix-build-coreutils-8.32.drv-0:

test-perror2.c:84: assertion 'msg3 == msg4 || STREQ (msg3, str3)' failed
test-strerror_r.c:170: assertion 'msg3 == msg4 || STREQ (msg3, str3)' failed

(on dover.guix.info)

grep-3.4:

test-perror2.c:84: assertion 'msg3 == msg4 || STREQ (msg3, str3)' failed
test-strerror_r.c:170: assertion 'msg3 == msg4 || STREQ (msg3, str3)' failed


pgpx5FsmK19yG.pgp
Description: OpenPGP digital signature