In the sandbox built for https://nixbuild.net, the coreutils build fails
because a failure in the df skip-rootfs test. The test failure is triggered by
the existance of a rootfs file system. However, I think that the test is faulty,
and I have reported it upstream in
https://lists.gnu.org/archive/html/bug-coreutils/2019-12/msg00000.html.
Disabling the test makes the coreutils build work in the nixbuild.net sandbox,
and I can't think of any negative impact disabling it can have. In normal nix
setups and in the normal nix sandbox, this test is not exercised anyway, since
there is no rootfs visible.
Some target platforms, especially when building inside a container
have issues with the inotify test. I also saw issues related to that
test under macOS so I would suggest in skipping that for now.
Release notes:
https://savannah.gnu.org/forum/forum.php?forum_id=9394
Touchups:
* enable tests w/musl (disable 2 gnulib tests)
* improve tests we modify: use exit code 77 to
indicate test skipped (causing it to be reportd as SKIP)
Note: Not yet on mirrors, but can be (manually) fetched from primary
In usernamespaces some POSIX assumptions break, which
make some coreutils fail when running with sandbox but without a nix-deamon.
With this pull request it is possible to bootstrap stdenv without root-permission,
which is quiet useful in HPC environments.
- default coreutils is stripped of /share/ (11 -> 2 MiB)
- coreutils-full retains /share/ and adds openssl for faster *sum tools
- NixOS systemPackages contains coreutils-full
- *Support parameter defaults are moved inside
(it seemed confusing to have `? false` and "at once" with `? isLinux`)
Closure considerations:
+ typical build-time closure will get lighter by ~9 MiB
- typical closure of NixOS installation will grow by ~2 MiB,
due to referring to both versions. I think it would be possible to
re-use most of the utils between the two versions, but the expression
would get much more complex.
I considered having stdenv with minimal coreutils and the default
`coreutils` attribute being full, but it turned out there were too many
trivial references in nixpkgs, so it didn't seem easy to keep rebuild
impact of openssl from growing significantly.
coreutils is part of stdenv, which doesn't allow openssl currently.
It's unclear that adding openssl to stdenv was intended,
but if it was it was not discussed or mentioned.
To unbreak "all the things", reverting until this
has been discussed and a proper fix has been put together.
This reverts commit df9f76c62d, reversing
changes made to 585ded7329.
Originally this was introduced in 055e646b ('coreutils: Guard against compiler not supporting __builtin_stpncpy_chk') four years ago. Right now this doesn't seem to serve any purpose and it conflicts with the hardening flags:
<command line>:2:9: warning: '_FORTIFY_SOURCE' macro redefined [-Wmacro-redefined]
#define _FORTIFY_SOURCE 2
^
<command line>:1:9: note: previous definition is here
#define _FORTIFY_SOURCE 0
^
1 warning generated.
The main changes are in libSystem, which lost the coretls component in 10.13
and some hardening changes that quietly crash any program that uses %n in
a non-constant format string, so we've needed to patch a lot of programs that
use gnulib.
