[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43986: core-updates' grep and coreutils fail strerror_r and perror2
From: |
bokr |
Subject: |
bug#43986: core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64 |
Date: |
Sat, 17 Oct 2020 20:59:57 +0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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