There's a generated header that got comment about the source header
from glibc.dev, which added unwanted runtime dependency. Tested:
nix build -f pkgs/top-level/release.nix stdenvBootstrapTools.{aarch64,i686,x86_64}-linux.test
Fixes this build error:
In file included from src/helper/options.c:38:
/nix/store/dl4h1p847f2rsrsfvlmm6cxxx7q21kxj-glibc-2.30-dev/include/sys/sysctl.h:21:2: error: #warning "The <sys/sysctl.h> header is deprecated and will be removed." [-Werror=cpp]
21 | #warning "The <sys/sysctl.h> header is deprecated and will be removed."
| ^~~~~~~
cc1: all warnings being treated as errors
Fixes: 48a997cd ("Merge #66528: glibc: 2.27 -> 2.30 (into staging)")
This has several advantages:
1. It takes up less space on disk in-between builds in the nix store.
2. It uses less space in the binary cache for vendor derivation packages.
3. It uses less network traffic downloading from the binary cache.
4. It plays nicely with hashed mirrors like tarballs.nixos.org, which only
substitute --flat hashes on single files (not recursive directory hashes).
5. It's consistent with how simple `fetchurl` src derivations work.
6. It provides a stronger abstraction between input src-package and output
package, e.g., it's harder to accidentally depend on the src derivation at
runtime by referencing something like `${src}/etc/index.html`. Likewise, in
the store it's harder to get confused with something that is just there as a
build-time dependency vs. a runtime dependency, since the build-time
src dependencies are tarred up.
Disadvantages are:
1. It takes slightly longer to untar at the start of a build.
As currently implemented, this attaches the compacted vendor.tar.gz feature as a
rider on `verifyCargoDeps`, since both of them are relatively newly implemented
behavior that change the `cargoSha256`.
If this PR is accepted, I will push forward the remaining rust packages with a
series of treewide PRs to update the `cargoSha256`s.
It's certainly better to have those two caveats than not evaluate.
Both seem rather niche. Unfortunately I failed to find a better way.
I started testing builds of several cross variants; all seem OK.
"master" is not a valid SHA-1 commit hash, and it's not even
necessarily the branch used. 'nixos-version --revision' now returns an
error if the commit hash is not known.
XML error introduced with merge commit 4e0fea3fe2.
This was probably because of wrong conflict resolution, because the
actual change (d8e697b4fc) had the close
tag of the <para/> element, but the merge commit didn't.
Signed-off-by: aszlig <aszlig@nix.build>
