The arm patch tries to modify files that are nowhere to be found in the
entire source tree. The cygwin patch also doesn't work so good anymore:
1 out of 1 hunk FAILED -- saving rejects to file ChangeLog.rej
1 out of 1 hunk ignored -- saving rejects to file configure.ac.rej
1 out of 1 hunk FAILED -- saving rejects to file lib/hash-triple.c.rej
2 out of 2 hunks ignored
2 out of 2 hunks FAILED -- saving rejects to file src/chroot.c.rej
1 out of 1 hunk FAILED -- saving rejects to file src/cksum.c.rej
6 out of 9 hunks FAILED -- saving rejects to file src/copy.c.rej
1 out of 4 hunks FAILED -- saving rejects to file src/dd.c.rej
1 out of 1 hunk ignored
1 out of 2 hunks FAILED -- saving rejects to file src/mv.c.rej
4 out of 7 hunks FAILED -- saving rejects to file src/stat.c.rej
Tested on 16-core machine with 10 rebuilds:
$ nix build -f. coreutils --repeat 10
No failures. Original failure is probably fixed upstream
with a69e54cfdf7 ("maint: fix dependency of man/arch.1".)
I made a mistake merge. Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
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.
