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

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

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.

So I can't actually enter the environment for building grep and running

make check

.

What now?

Hi Danny,

On +2020-10-17 12:20:11 +0200, Danny Milosavljevic wrote:

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?

HTWNEU -- Hope This Was Not Entirely Useless :)

--

Regards,

Bengt Richter

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

Danny Milosavljevic <dannym@scratchpost.org> writes:

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

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

Marius Bakke <marius@gnu.org> skribis:

Also note that I upgraded ‘grep’ to 3.5 in the meantime (commit

370adc91b59ac06243067a31122f567a7c35b24b).

Ludo’.

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

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.