This release in a RC for gnupg-2.2. The main difference as far as
nixpkgs is concerned is that the binary `gpg2` is now called `gpg` and
`gpgv2` is called `gpgv`.
This update fixed all explicit use of `gpg2` and `gpgv2` across nixpkgs,
but there might be some packaged software that internally use `gpg2`
not handeled by this commit.
See http://lists.gnu.org/archive/html/info-gnu/2017-08/msg00001.html
for full release information
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
This fixes `fetchurl-force.nix` not being installed, which breaks
bundix for some gems.
E.g.
```
$ nix-build --argstr url https://rubygems.org/gems/nio4r-2.1.0.gem /nix/store/y6959dxal86l3alc0ryf7752prbbkzxg-bundix-2.2.0/lib/ruby/gems/2.3.0/gems/bundix-2.2.0/lib/bundix/fetchurl-force.nix
error: getting status of ‘/nix/store/y6959dxal86l3alc0ryf7752prbbkzxg-bundix-2.2.0/lib/ruby/gems/2.3.0/gems/bundix-2.2.0/lib/bundix/fetchurl-force.nix’: No such file or directory
```
Rainbow needs rake (a make analogue) as build dep. This builds an specific
version of rake for building rainbow.
Since rake is private to rainbow there shouldn't be any problems until rainbow
devs decide they need another rake version which is unlikely.
The bin stubs need to be built where there's access to /nix/store - so
it can't happen in a nix-shell run. Ergo, a shell.nix needs to be able
to signal to the build that all bins need to be built.
Original error:
$ nix-shell -p jekyll --command "jekyll new test"
Running bundle install in /private/tmp/test...
Bundler: There was an error while trying to write to
Bundler:
`/nix/store/l67429rhvrmr7c4c1msb7s8zjq4fx7ad-gemfile-and-lockfile/.bundle/config`.
Bundler: It is likely that you need to grant write permissions for
that path.
`usesGemspec` no longer required to trigger the "copy everything into
gemfile-and-lock" behavior. If the mainGem is referred to by path,
that's sufficient.
