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

  • Open
  • quality assurance status badge
Details
4 participants
  • bokr
  • Danny Milosavljevic
  • Ludovic Courtès
  • Marius Bakke
Owner
unassigned
Submitted by
Danny Milosavljevic
Severity
normal
D
D
Danny Milosavljevic wrote on 14 Oct 2020 12:41
(address . bug-guix@gnu.org)
20201014124120.15f19ad6@scratchpost.org
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
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl+G1dAACgkQ5xo1VCww
uqW6YAf9GUQGbP0X8C9TcDQfCXFNj/W+XLBS8XFy4cAniz2OI9jqK0QfETf2Ggi2
4GW6LgHJb+K+H1CMn7qhNaChvJZKdTaRqhwVgEZD7J/MfBbej0oTrp57MKVy7xYg
XJ/0jM2O1Xd3X1+rXGNCaXrAFmxbMldoJ3pZUI0g2s6TlSpx2j5QEzUfwHj8xFoV
1dmgcFOE+H9hQJx+8YN+P5rSQIUMfvPpssKBw9x1JO8rMy17zX+jK+hHFIi6QhOY
cCMJ+165VE7QO5ercQP8wT1zHP6t4bFf7MFvGFU4SaEYXAPRjyiQ84UQjA8IYvAm
0+1xOUNCGoj3AaiX+NoflcASIBqh4Q==
=A6y8
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 17 Oct 2020 12:20
(address . 43986@debbugs.gnu.org)
20201017121923.48d8e85a@scratchpost.org
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?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl+KxVsACgkQ5xo1VCww
uqU7QAf+M7SxKBd2RIq3B8wp4iczaDy3Wikqma4F7i7c5OFi5sA8TiiXHGyWTGsM
oiCqbAJaAQG/v/TT88GMSjbWPYrWush0TfbG3rvils+q9QxJqA8obwiGzvMMUEr4
QA4Yi2UH4pVC46LX0JqPeKiIgE3TIlQjnH+el2n5Xs0tIfdqCVsTkm/ZcERNeoIy
sa5NeXzu9G7kYRK7UAchQJtnzy7Jq4MVCaGbMYXxBkRHEPoUGOgW3cy/jab/h+sf
VynC/kJ7shwI984AIFhsf2K9W9FDDXVz84lR9/JPwWTV3bMVttSpjK8dDK6hCO8H
h8S4PzK7IDNBb4vo3MJ9v6XW571uUQ==
=a8BW
-----END PGP SIGNATURE-----


B
B
bokr wrote on 17 Oct 2020 20:59
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 43986@debbugs.gnu.org)
20201017185957.GA2851@LionPure
Hi Danny,

On +2020-10-17 12:20:11 +0200, Danny Milosavljevic wrote:
Toggle quote (6 lines)
> 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?

Toggle quote (9 lines)
>
> 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
D
D
Danny Milosavljevic wrote on 19 Oct 2020 00:45
(address . 43986@debbugs.gnu.org)
20201019004517.485c9c99@scratchpost.org
and findutils, while trying to prepare the guix environment for grep.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl+MxX0ACgkQ5xo1VCww
uqUrngf+IBtnuqTXWq88CRsPzf15MqG3TLz3Dcc/Yrvku2Z2qprPryDOBRugAnlS
zsz7gCt2JRDbzkn76UluhWYQiFSYcaadrJFSnx9ZS1y1Qejoj++Lqa0cdg0HNGkw
M+jqDcsy3rjtb8TZygFyccYEsV2xrMJpjhgpgmWnbQsSPPw/UGC7MRnQYSGgjSNh
VZBOpm95xYiN25rWQVEcTjwYdUQGaCg7o3FgErstbofhZCDCgrmRn2ADn/r81nDu
i8mAISXyVxzpALIICJSPJ1KLHthSdu/q6+q17vwFZ0X9av18Fl8PCCX0FaXHfAWw
zb/sJiskt1cbr1jNGx2exD3VMrtk9w==
=9EJR
-----END PGP SIGNATURE-----


M
M
Marius Bakke wrote on 19 Oct 2020 00:49
87r1pvjgk6.fsf@gnu.org
Danny Milosavljevic <dannym@scratchpost.org> writes:

Toggle quote (6 lines)
> 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'.
-----BEGIN PGP SIGNATURE-----

iQFDBAEBCgAtFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl+MxmkPHG1hcml1c0Bn
bnUub3JnAAoJEKKgbfKjOlT6r3sIAMOYk23R/+SmE+w43mOLdL863jaup8dz7Fdq
1wO7z4Mz+b0i/XeZtdVtF5ZXGRZ+AzuaFyhZXMKbjrkZVP7lTPdjmO08jtY5obgK
qhJPKXuAG6g0kbuX9TxOyEqwwynBpZ674lkUMNAPLbostyupGhRZo/kDNkfZhJcq
4ReraLGUTX0dZR1Y6X417xQyklRapaCrrR+cz8Hg0FAUk0hi67dJYvJeb5+Hvf1a
LquBNS2Pa6+IjW0h8pd6yWKf9keJPDhViFzWOGHhtIJxEwLkjNhTbS3YF68WLknD
Mb1fXfZPqE/MayBAOn8YvEtEsA4CGirp8tBjs/N6r+o5IA7s7uM=
=In7P
-----END PGP SIGNATURE-----

D
D
Danny Milosavljevic wrote on 20 Oct 2020 09:22
(address . 43986@debbugs.gnu.org)
20201020092246.5a27c998@scratchpost.org
and diffutils, while trying to prepare the guix environment for grep.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl+OkEYACgkQ5xo1VCww
uqWcmwgAkJs3fINW4XcqgB1A+BzI+ynblrdHlG3TKJO/gqg+4CTynVJz8IM7A88H
XgdDfrTCPCuUlILoKG+SAQ8dxnyadpR1jS383Eu3vXhQijrfB8dFi1EDnOn0j2jG
VRjo/LR7lsRO2XsvOkgOTqgi802rB6n8LAPqRSnuY8fsY+G2Ht7ap5IyALlcn918
x8iT0pfzpRCjyIR/r2v9PN77XLeX3EpLbjuZhk9WWHSf7KRokACo/8ecSDJrnLeQ
PaUeRWwrP5T63jUWZ7RU6FPArFgA09l0GJy/Z7HykS+3WIEyHKaPyAgHeD8WfaiY
KAHu748tC07M/4CdlxYqL33+m+qH0A==
=lZU7
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 21 Oct 2020 12:26
(name . Marius Bakke)(address . marius@gnu.org)
87h7qn6fk3.fsf@gnu.org
Marius Bakke <marius@gnu.org> skribis:

Toggle quote (15 lines)
> Danny Milosavljevic <dannym@scratchpost.org> 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’.
D
D
Danny Milosavljevic wrote on 21 Oct 2020 18:04
(address . 43986@debbugs.gnu.org)
20201020190151.38ad32f1@scratchpost.org
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).
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl+QXAAACgkQ5xo1VCww
uqUDgAgAj1vCt54hwsxOnKY6DkR3OgGI98d9ItbsB1AdptIuR3Q4TnOulKigigGi
mXzPAXW0h5Vuf81wezCfAhS3lhCov9OGOTZxjXFXagNVzVbHQKcnqNTdNjoBrjF2
pqsHhL0R0U8lTb8mDKu2E1tjyK4ph4EKLZ4OcsfFM8CLwbFCDFTQ19m8KgIi39fQ
K6VL0+9juVuyfGgFBBKVKtvKWaYI4g/UkkCvjXFixAIugPz/wtfq/jsTouYSvSa1
7GP49Ab7DTgAPbOwpX2IicnTX9y4PrBgjjCo9p+1X1wCcnHrVHLJXk4fdDOnhb9X
xk+18+MRSj9R61r7bL3WnS2cUOLwFA==
=dQUS
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 21 Oct 2020 19:03
(address . 43986@debbugs.gnu.org)
20201021190358.7b9b6453@scratchpost.org
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.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl+Qaf4ACgkQ5xo1VCww
uqWiJQf9FzProCKeESVR9iNwyD+Gi+C2C2UbO6Hm8Znc1cdEe5h0IrrEOqoxYMou
4f1x2DS5ChAyITyfSIieznsANGm3eFq2Q6o5W91pFRS75rfTZv0sRLhBYhrvVtUq
MoBSXhzGrl6oizlH5msE9KvIwntlumAOU58bYzHLIn1SKZHNY927lq8MDvlVbudR
gXDbql7tD8Mt8zkfXzQrdZ8m0ZpIKj5tRj3KrQO+Pj4Z/qccF3iG0nJ+134ywa6M
987YdSahrfXn2a+3tB8wN/3p42eN51LPlTXOCaCITawyx/jyKNo2/eFyWx83Ws32
Spy2fpX8aHqwR/Q64t6+Kzm8SwK19w==
=3WHL
-----END PGP SIGNATURE-----


?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 43986@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 43986
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch