gnupatch: 2.7.6 -> 2.7.6-unstable-2024-08-25

[tie]

Description of changes

This change updates gnupatch to the latest Git commit.

Note that stdenv/linux uses fetchurlBoot as fetchurl for bootstrap and we need fetchFromSavannah (or rather fetchzip) that is not compatible with fetchurlBoot, so we override fetchzip to use fetchurl from the current package set instead of using fetchurlBoot. This shouldn’t be an issue on Darwin because curl is included in bootstrap files. FreeBSD stdenv seems to have curl in bootstrap files as well.

References:

• https://savannah.gnu.org/bugs/?57883#comment2
• gnupatch: fix segfault on cleanup #337473
• stdenv: add applyPatches and support patch directories #335579 (comment)

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[emilazy]

Thanks! I don’t feel entirely confident to review this gnarly stdenv bootstrap stuff but I’ll try to take a closer look soon.

Could we avoid some of the bootstrapping issues by just using fetchurl? I don’t know if we need fetchzip specifically for this.

[tie]

Could we avoid some of the bootstrapping issues by just using fetchurl? I don’t know if we need fetchzip specifically for this.

If Git tarballs generated by Cgit are reproducible, then yes. Otherwise we can’t use fetchurlBoot because it hashes the file instead of archive contents. E.g. see https://github.blog/open-source/git/update-on-the-future-stability-of-source-code-archives-and-hashes

[philiptaron]

I think this can be in pkgs/by-name/gn/gnulibBootstrapHook. I'd prefer that.

[tie]

Hm, I’d at least expect pkgs/by-name to be case-insensitive (or rather forcing all package names to be lower-case and erroring otherwise) since that’s a reasonable behavior given that macOS and Windows use case-insensitive filesystems by default. I’m not sure if that’s the case though.

[philiptaron]

We have a check in nixpkgs-vet that names can't differ by case -- food and FooD are rejected. macOS and Windows are case insensitive but case-preserving, so we can use the filesystem for determining attrset names as pkgs/by-name does.

[philiptaron]

Why did this need to change?

[tie]

No reason in particular, it was easier to remove all fetchurl/fetchurlBoot instances in stdenv/linux and rewrite it from scratch to when working on this PR, and I haven’t minimized the diff yet because some commits should be split into separate PRs (e.g. openssl stuff).

[philiptaron]

I think we can merge this separate from this PR.

[tie]

Yes, I was planning to do this 👍

[philiptaron]

I think we can merge this separate from this PR, and since it's a version bump, I'd prefer that.

[emilazy]

Can we? I thought the change to python3Minimal would be load‐bearing.

[tie]

I’m not really sure if gnulib even uses/needs python3, i.e. by default gnulib-tool does a PATH lookup before using Python implementation (unless GNULIB_TOOL_IMPL is explicitly set).

https://github.com/coreutils/gnulib/blob/6e95321249ae6986c3df764a6e539f8b5be13948/gnulib-tool#L161

[philiptaron]

https://github.com/NixOS/nixpkgs/actions/runs/10648732824/job/29518094549?pr=337961

This nixpkgs-vet error is unexpected to me. Taking a look.

[emilazy]

I think the check was broken at some point? It might need a rebase.

[infinisil]

The error is misleading, but the underlying problem seems to be that pkgs.gnupatch isn't actually pointing to the definition in pkgs/by-name, neither before nor after this PR:

nix-repl> builtins.unsafeGetAttrPos "gnupatch" pkgs
{
  column = 33;
  file = "/home/ncasil/src/nixpkgs/pkgs/stdenv/linux/default.nix";
  line = 679;
}

Not entirely sure why that happens, because both all-packages.nix and pkgs/by-name should override stdenv definitions:

nixpkgs/pkgs/top-level/stage.nix

Lines 348 to 355 in 3c799ef

	toFix = lib.foldl' (lib.flip lib.extends) (self: {}) ([
	stdenvBootstappingAndPlatforms
	stdenvAdapters
	trivialBuilders
	splice
	autoCalledPackages
	allPackages
	otherPackageSets

[tie]

@infinisil, I assume this is because of the stdenv.overrides inherited from the previous stage (and stdenvOverrides taking precedence over allPackages)?

nixpkgs/pkgs/stdenv/linux/default.nix

Lines 667 to 701 in c2090cb

	overrides = self: super: {
	inherit (prevStage)
	gzip bzip2 xz bash coreutils diffutils findutils gawk
	gnused gnutar gnugrep gnupatch patchelf
	attr acl zlib libunistring;
	inherit (prevStage.gnugrep) pcre2;
	${localSystem.libc} = getLibc prevStage;
	# Hack: avoid libidn2.{bin,dev} referencing bootstrap tools. There's a logical cycle.
	libidn2 = import ../../development/libraries/libidn2/no-bootstrap-reference.nix {
	inherit lib;
	inherit (prevStage) libidn2;
	inherit (self) stdenv runCommandLocal patchelf libunistring;
	};
	gnumake = super.gnumake.override { inBootstrap = false; };
	} // lib.optionalAttrs (super.stdenv.targetPlatform == localSystem) {
	# Need to get rid of these when cross-compiling.
	inherit (prevStage) binutils binutils-unwrapped;
	gcc = cc;
	};
	};
	})
	# This "no-op" stage is just a place to put the assertions about stage5.
	(prevStage:
	# previous stage5 stdenv; see stage3 comment regarding gcc,
	# which applies here as well.
	assert isBuiltByNixpkgsCompiler prevStage.binutils-unwrapped;
	assert isBuiltByNixpkgsCompiler prevStage.${localSystem.libc};
	assert isBuiltByNixpkgsCompiler prevStage.gcc-unwrapped;
	assert isBuiltByNixpkgsCompiler prevStage.coreutils;
	assert isBuiltByNixpkgsCompiler prevStage.gnugrep;
	assert isBuiltByNixpkgsCompiler prevStage.patchelf;
	{ inherit (prevStage) config overlays stdenv; })

nixpkgs/pkgs/top-level/stage.nix

Lines 161 to 165 in c2090cb

	# stdenvOverrides is used to avoid having multiple of versions
	# of certain dependencies that were used in bootstrapping the
	# standard environment.
	stdenvOverrides = self: super:
	(super.stdenv.overrides or (_: _: {})) self super;

nixpkgs/pkgs/top-level/stage.nix

Lines 352 to 363 in c2090cb

	toFix = lib.foldl' (lib.flip lib.extends) (self: {}) ([
	stdenvBootstappingAndPlatforms
	stdenvAdapters
	trivialBuilders
	splice
	autoCalledPackages
	allPackages
	otherPackageSets
	aliases
	configOverrides
	] ++ overlays ++ [
	stdenvOverrides ]);

This feels really weird to me, especially since the inherited (g)libc depends on xgcc-*-libgcc while other packages (that are not present in stdenv.overrides) are using regular gcc-*-libgcc. E.g.

$ nix path-info --recursive $(nix build --no-link --print-out-paths --file . bash^out) | fgrep libgcc
/nix/store/3kghvsns26scklmgi2f14787lzwrvqnf-xgcc-13.3.0-libgcc

nix path-info --recursive $(nix build --no-link --print-out-paths --file . coreutils^out) | fgrep libgcc
/nix/store/3kghvsns26scklmgi2f14787lzwrvqnf-xgcc-13.3.0-libgcc
/nix/store/vxk9halw286r11jabdyni93kkghhb9f5-gcc-13.3.0-libgcc

But perhaps that is a separate issue.