GNU bug report logs -
#43986
core-updates' grep and coreutils fail strerror_r and perror2 tests in gnulib-tests on armhf-on-aarch64
Previous Next
Full log
Message #11 received at 43986 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 4 years and 300 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.