Previously, when sha256 either wasn't defined or set to an empty string
fetchpatch would error out as follows:
'''
warning: found empty hash, assuming 'sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA='
...
/nix/store/agwlk2bcfvz2ggrsbvwd7696qj55frbi-stdenv-linux/setup: line 96: /build/: Is a directory
sed: couldn't flush stdout: Broken pipe
'''
This patch makes it show fetchurl's error message instead:
'''
warning: found empty hash, assuming 'sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA='
...
error: hash mismatch in fixed-output derivation:
specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
got: sha256-NWGWoyEgT/ztCwbhNgGPvG+nqX4bxtFnD+wds6fklbs=
'''
This is very convenient for TOFU.
Co-Authored-By: Ivar Scholten <ivar.scholten@protonmail.com>
Nix now returns base64-encoded SRI hashes on hash mismatch. Usually,
people copy the returned hashes in TOFU fashion but since base64-encoded
strings can contain slashes, they often broke our use of them for temporary file name.
Escaping them should prevent the failures.
Since this is probably never the desired case and has led to actual
issues, see the comments at:
af1313e915
This might also happen when pulling a patch from GitHub or a similar web
interface without explicitly selecting the "raw" format.
Excludes and includes are implemented by passing the parameters to the
respective flags of `filterdiff`. Those were passed unescaped until now.
Since those flags expect patterns (similar to shell globs), something
like `/some/path/*` might be used to exclude or include all files in
some path. Without escaping the shell would expand the `*`, leading to
unexpected behaviour.
This commit was originally introduced as part of #41420 and then
reverted with the rest of that PR. However there was no reason to revert
his particular commit.
We still ensure the old and new ones start, respectfully, with `a/` and
`b/`. Use with `stripLen` to ensure tha the old `a/` and `/b` are gone
if a new prefix is added.
Before this fix, it seemed to be trying to merge our postFetch with the
patch normalization logic, but accidentally clobbering the whole thing
with the passed-in value.
Sometimes patches start without a leading prefix. We default to strip
one prefix or path component from patches (-p1) in the patchPhase in
stdenv.
As all patches should therefore be in this format, fetchpatch should
have an option to normalize patch paths. This commit introduces a new
argument to fetchpatch called addPrefixes that adds one patch prefix to
the old and new paths in a patch before putting it into the store.
Comes in handy if we want to make additional modificiations to the
output file. While I wasn't sure whether to invoke the passed postFetch
directly before the patch or afterwards, I thought it would be better
afterwards because "postFetch of fetchpatch" at least to my intuition
would sound that after whatever "fetchpatch" does - it comes afterwards.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
fetchpatch is fetchurl that determinizes the patch.
Some parts of generated patches change from time to time, e.g. see #1983 and
http://comments.gmane.org/gmane.linux.distributions.nixos/12815
Using fetchpatch should prevent the hash from changing.
Conflicts (auto-solved):
pkgs/development/libraries/haskell/gitit/default.nix
