/proc/uptime support can't be detected automatically when cross-compiling, so
it is disabled by default. This causes extremely large uptime values (e.g.
19167 days) on systems without RTCs because the boot time is set to the
epoch.
I suspect this issue is caused by the very old version of diffutils we
have in the aarch64+musl bootstrap tools, so hopefully we can
re-enable the tests once we have newer bootstrap tools.
Until a recent patch in coreutils, gnus uname -p returned a different
arch on apple silicon macs, compared to the uname shipped with macos.
This causes config.guess to produce incorrect build system triplets
for various projects on these systems when in a nix-shell.[23][42]
As coreutils only releases every few months/years and no release is
planned at the moment, I'm introducing the patch here. We can drop it
once the next coreutils version is released.
I made a tiny adjustment to the patch from [23]. I removed the usage
of MAYBE_UNUSED, which currently only compiles against HEAD.
[23] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52330
[42] https://github.com/NixOS/nixpkgs/issues/147914
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.
