This is less brittle and breaks loud if the code changes.
Also remove the /usr/bin/file patch. It is not really required
for the build to work, the generated warning is harmless.
* Replace LD_LIBRARY_PATH with OS-specific name (e.g. DYLD_LIBRARY_PATH
on macOS).
* Disable Python tests on macOS, because they use gpg, which fails due
to a very long socket path (https://github.com/NixOS/nix/pull/1085).
The former should be fixed upstream. The latter is a Nix-specific issue,
but it can be worked-around upstream by making Python tests respect
--disable-gpg-test.
I haven't been doing any maintenance for a long time now and not only
do I get notified, it also creates a fake impression that all these
packages had at least one maintainer when in practice they had none.
when calling python3Packages.gpgme, it was still picking python2.
Changed withPython into pythonSupport since it's the convention.
I had to enable ncurses too because of this error when configuring:
configure:19978: checking python extra libraries
configure:19985: result: -lpthread -ldl -lcrypt -lncurses -lutil -lm
configure:19992: checking python extra linking flags
configure:19999: result: -Xlinker -export-dynamic
configure:20006: checking consistency of all components of python development environment
configure:20032: gcc -o conftest -g -O2 -I/nix/store/hy65mn4wjswqih75gfr6g4q3xgqdm325-python3-3.6.6/include/python3.6m conftest.c -L/nix/store/hy65mn4wjswqih75gfr6g4q3xgqdm325-python3-3.6.6/lib -lpython3.6m -Xlinker -export-dynamic -lpthread -ldl -lcrypt -lncurses -lutil -lm >&5
/nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/ld: cannot find -lncurses
collect2: error: ld returned 1 exit status
configure:20032: $? = 1
I've rebuild all packages that depend on gpgme and everything seems fine
so far (there are a few failures but the ones I've checked are unrelated
to gpgme).
Upstream release notes (Noteworthy changes in version 1.11.1):
* Fixed build problems in the 1.11.0 release.
* Added C++ interfaces which were planned for 1.11.0.
The 1.11.0 release came with these changes:
* New encryption API to support direct key specification including
hidden recipients option and taking keys from a file. This also
allows to enforce the use of a subkey.
* New encryption flag for the new API to enforce the use of plain
mail addresses (addr-spec).
* The import API can now tell whether v3 keys are skipped. These old
and basically broken keys are not anymore supported by GnuPG 2.1.
* The decrypt and verify API will now return the MIME flag as
specified by RFC-4880bis.
* The offline mode now has an effect on gpg by disabling all network
access. [#3831]
* A failed OpenPGP verification how returns the fingerprint of the
intended key if a recent gpg version was used for signature
creation.
* New tool gpgme-json as native messaging server for web browsers.
As of now public key encryption and decryption is supported.
Requires Libgpg-error 1.29.
* New context flag "request-origin" which has an effect when used
with GnuPG 2.2.6 or later.
* New context flag "no-symkey-cache" which has an effect when used
with GnuPG 2.2.7 or later.
* New convenience constant GPGME_KEYLIST_MODE_LOCATE.
* Improved the Python documentation.
* Fixed a potential regression with GnuPG 2.2.6 or later.
* Fixed a crash in the Python bindings on 32 bit platforms. [#3892]
* Various minor fixes.
- added gnupg to checkInputs
- generate manpage (optional)
- move alot.desktop file to $out/share/applications
- disabled tests as they need the network (dependency on twisted)
Thanks to Sarah Brofeldt, Ben Mcginnes for their help (and other) and
to FRidh for the repeated careful reviews.
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>
