* 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 reverts commit 872770286d.
This will fix fwknop as well (should have done it like this in the first
place, where was my mind...).
Conclusion: Did something stupid... :o - I am *so incredibly sorry*,
will be way more careful (was already careful, but apparently not
enought...) next time and use nox.
Sorry @everyone and thanks @calvertvl for noticing this.
This shouldn't break anything as currently neither dev nor info will be
generated anyway (since both directories don't actually exist at the
install phase - "mv bin dev" would produce the dev output).
This change is required for building fwknop with GnuPG support.
By default, GPGME tries to search in $PATH for the gpg and gpgconf
binaries. This has the downside, that the library won't work by its own
and needs to have GnuPG in systemPackages or the user environment.
I've stumbled on this while working on one of the dependencies of
nixos-assimilate and nixpart (volume_key), where the testing environment
didn't come with GnuPG in $PATH and thus the tests have failed.
After testing this with a few programs using GPGME, I haven't found any
weird behavior in conjunction with the GnuPG agent.
However one possible implication could be that if the GnuPG used in
$PATH (and the config files in the user's home directory) should be
vastly incompatible, it could lead to failures.
In practice however, the GnuPG1/2 versions pretty much seem to stay
compatible within their major releases so it shouldn't pose a problem.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Also add gnupg1-compatibility symlinks to gnupg2.
Most packages should be able to use gnupg2 instead of gnupg1.
svn path=/nixpkgs/trunk/; revision=21883
