In 6733ece `-DUSE_HTTP_PARSER=system` was introduced, which does not seem
to work with this fork. So instead fallback to the `builtin`.
Also sync with upstream cmake flags.
See inline comment; this does not build on Hydra and either requires custom
patching or a new release from upstream before it will build.
Note that we can still recompute the `cargoSha256` for #79975; the package
is broken in the identical way.
###### Motivation for this change
Update to latest upstream version
###### Things done
* [ ] Tested using sandboxing ([nix.useSandbox](http://nixos.org/nixos/manual/options.html#opt-nix.useSandbox) on NixOS, or option `sandbox` in [`nix.conf`](http://nixos.org/nix/manual/#sec-conf-file) on non-NixOS linux)
* Built on platform(s)
* [x] NixOS
* [ ] macOS
* [ ] other Linux distributions
* [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
* [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nix-review --run "nix-review wip"`
* [x] Tested execution of all binary files (usually in `./result/bin/`)
* [ ] Determined the impact on package closure size (by running `nix path-info -S` before and after)
* [ ] Ensured that relevant documentation is up to date
* [x] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md).
###### Notify maintainers
cc @worldofpeace @tfc @jtraue
Old intercaps names are aliased.
darcs-to-git: rename from darcsToGit
git-fast-export: rename from gitFastExport
git-remote-gcrypt: rename from gitRemoteGcrypt
hub-unstable: rename from hubUnstable
top-git: rename from topGit
Changes the default fetcher in the Rust Platform to be the newer
`fetchCargoTarball`, and changes every application using the current default to
instead opt out.
This commit does not change any hashes or cause any rebuilds. Once integrated,
we will start deleting the opt-outs and recomputing hashes.
See #79975 for details.
The existing post-install was not successfully patching the git-gui script,
and thus was invoking the packaged osx app which uses the system tk,
which is too old to work (and is no longer supported by Apple anyway).
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.
Git ships with a zsh completion script, but this script was previously
only available at $out/share/git/contrib/completion/git-completion.zsh,
which is not a path (or a filename) that would be discovered by a
typical zsh installation. This commit symlinks that file to
$out/share/zsh/site-functions/_git, which is a more standard location.
That zsh completion script is mostly a wrapper around the Bash
completion script, so this commit also patches the former so that it can
"find" the latter.
According to https://repology.org/repository/nix_unstable/problems, we have a
lot of packages that have http links that redirect to https as their homepage.
This commit updates all these packages to use the https links as their
homepage.
The following script was used to make these updates:
```
curl https://repology.org/api/v1/repository/nix_unstable/problems \
| jq '.[] | .problem' -r \
| rg 'Homepage link "(.+)" is a permanent redirect to "(.+)" and should be updated' --replace 's@$1@$2@' \
| sort | uniq > script.sed
find -name '*.nix' | xargs -P4 -- sed -f script.sed -i
```
The sed invocation was changing all lines matching "local daemon.*".
This changed the line it was supposed to, but two other lines that also
matched that pattern were being modified, which meant that the
"daemon_pid_var" and "daemon_pid" variables were not defined when they
should have been.
Idea shamelessly stolen from 4e60b0efae.
I realized that I don't really know anymore where I'm listed as maintainer and what
I'm actually (co)-maintaining which means that I can't proactively take
care of packages I officially maintain.
As I don't have the time, energy and motivation to take care of stuff I
was interested in 1 or 2 years ago (or packaged for someone else in the
past), I decided that I make this explicit by removing myself from several
packages and adding myself in some other stuff I'm now interested in.
I've seen it several times now that people remove themselves from a
package without removing the package if it's unmaintained after that
which is why I figured that it's fine in my case as the affected pkgs
are rather low-prio and were pretty easy to maintain.
Since bash-completion rules are loaded dynamically, the completion
rules for `gitk <Tab>` waere not being loaded until the user first
typed `git <Tab>`. Fix this by adding a symlink named `gitk`.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
When perlSupport = false, we will set NO_PERL=1, and build Git without
Perl support. This is a build option that Git supports. However, Git's
test suite still requires a Perl to be available to run the tests, and
we did not provide one. The tests respect PERL_PATH, and if it is not
set, they default to /usr/bin/perl.
Before this commit, if we set "perlSupport = false", then no Perl would
be available to the package, and so the tests would default to
/usr/bin/perl. When building without a sandbox, that could still work,
even though there is no "perl" on the path, because the tests defaulted
to an absolute path.
You can reproduce this issue as follows:
nix-build -E 'let pkgs = (import ./default.nix) {}; in pkgs.git.override { perlSupport = false; }'
I just ran into this when trying to build pkgs.git from an old version
of Nixpkgs that I was able to build just fine in the past, and today it
would not build any more, complaining when running the tests:
make -C t/ all
make[1]: Entering directory '/build/git-2.18.0/t'
rm -f -r 'test-results'
/nix/store/czx8vkrb9jdgjyz8qfksh10vrnqa723l-bash-4.4-p23/bin/bash: /usr/bin/perl: No such file or directory
In the past the sandbox was not enabled by default, so then it worked
for me. But now that it is enabled, my host's (not NixOS) /usr/bin/perl
is no longer accessible, and the build fails.
The solution is to explicitly set PERL_PATH when running the tests. This
*almost* works, except that there appears to be a bug in the test for
"git request-pull". That command is a Bash script that calls Perl at
some point, so it requires Perl, and therefore it cannot be supported
when NO_PERL=1. But that particular test does not check whether Git was
compiled with Perl support (other tests do include that check), and that
makes the test fail:
t5150-request-pull.sh ..............................
not ok 4 - pull request after push
not ok 5 - request asks HEAD to be pulled
not ok 6 - pull request format
not ok 7 - request-pull ignores OPTIONS_KEEPDASHDASH poison
not ok 9 - pull request with mismatched object
not ok 10 - pull request with stale object
Dubious, test returned 1 (wstat 256, 0x100)
Failed 6/10 subtests
This output makes sense if you look at t5150-request-pull.sh. Test 1 and
2 are setup steps. Test 3 does call request-pull, but it expects the
command to fail, and it cannot distinguish between the command exiting
with a nonzero exit code, or failing to start it at all. So test 3
passes for the wrong reasons. Test 4 through 10 all call request-pull,
so they fail.
The quick workaround here is to disable the test. I will look into
upstreaming a patch that makes the test skip itself when Perl is
disabled.
The tests for null patterns where changed in 25754125cef278c7e9492fbd6dc4a28319b01f18,
it's possible utf-8 normalisation is causing different behaviour here.
not ok 54 - LC_ALL='C' git grep -P -f f -i 'Æ<NUL>[Ð]' a
not ok 57 - LC_ALL='C' git grep -P -f f -i '[Æ]<NUL>Ð' a
not ok 60 - LC_ALL='C' git grep -P -f f -i '[Æ]<NUL>ð' a
not ok 63 - LC_ALL='C' git grep -P -f f -i 'Æ<NUL>Ð' a
Dubious, test returned 1 (wstat 256, 0x100)
Failed 4/145 subtests
(less 48 skipped subtests: 93 okay)
Putting the file in $out/share/bash-completion/completions means that it will be loaded on demand by nixpkgs.bash-completion.
With the old location, the user would either have to explicitly source the file during bash startup, or set BASH_COMPLETION_COMPAT_DIR before sourcing bash_completion.sh, which will eagerly load everything in that directory.
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
Reduces gitMinimal closure size from 329.6M to 174.8M.
Fixes the issue https://github.com/NixOS/nixpkgs/issues/64350.
In git 2.22.0 git-stash is no longer a shell script and now it is just a symlink to git.
`postInstall` assumed that it was a shell script, tried to patch it and
ended up corrupting the file and made `strip` refuse stripping it.
A recent upgrade of cargo-vendor changed its output slightly, which
broke all cargoSha256 hashes in nixpkgs.
See https://github.com/NixOS/nixpkgs/issues/60668 for more information.
Since then, a few hashes have been fixed in master by hand, but there
were a lot still to do, so I did all of the ones left over with some
scripts I wrote.
The one hash I wasn’t able to update was habitat's, because it’s
currently broken and the build doesn’t get far enough to produce a
hash anyway.
adds a tool to get the paths of the dependencies needed by the helper scripts
(which are written only once and are never updated) to the output and patches
them to use it expand their path
gnupg is gnupg 2.2. gnupg1 is also gnupg 2.2, just with a few extra
symlinks in the bin directory. None of these packages need those
symlinks, and it's confusing for them to say they're depending on
"gnupg1", so switch their dep to plain "gnupg".
