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.
