I've removed qgpgme-format-security.patch as version 1.10.0 already
contains it:
git tag --contains=5d4f977dac542340c877fdd4b1304fa8f6e058e6
Everything rebuilds fine so far.
Upstream release notes (Noteworthy changes in version 1.10.0):
* Now returns more specific error codes for decryption to distinguish
between bad passphrase, user canceled, and no secret key.
* Now returns key origin information if available.
* Added context flag "auto-key-retrieve" to selectively enable the
corresponding gpg option.
* Added flag is_de_vs to decryption and verify results.
* py: Use SEEK_SET as default for data.seek.
* cpp: Various new APIs.
* Reduced spawn overhead on Linux again. Added new configure option
--disable-linux-getdents to disable this feature for very old
Linux versions.
* Improved the Python bindings build system.
* Made the test suite less fragile.
* 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
