excerpt from configure: Testing default Xapian backend... glass Checking for GMime development files... Yes. Checking for GMime session key extraction support... gpg: Warning: using insecure memory! gpg: WARNING: key 6D92612D94E46381 contains preferences for unavailable algorithms on these user IDs: gpg: "Notmuch Test Suite <test_suite@notmuchmail.org> (INSECURE!)": preference for compression algorithm 3 gpg: it is strongly suggested that you update your preferences and gpg: re-distribute this key to avoid potential algorithm mismatch problems decryption failed No. *** Error: Could not extract session keys from encrypted message. This is likely due to your GMime having been built against a old version of GPGME. Please try to rebuild your version of GMime against a more recent version of GPGME (at least GPGME 1.8.0). Your current GPGME development version is: 1.13.0 Please note, notmuch should probably depend on gpgme. It seems like the test key used by notmuch is too old for my gpg (app-crypt/gnupg-2.2.17). This makes the check fail. I manually tested hacking the check up, and everything is fine. I'm not sure how to fix/work-around this issue, and/or if it is some gnupg config issue that it picks up.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c254be0749ca0792ec1c68417bd59ff8f725878a commit c254be0749ca0792ec1c68417bd59ff8f725878a Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2019-08-31 13:12:31 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2019-08-31 13:12:48 +0000 net-mail/notmuch: correct gpgme detection on Solaris Bug: https://bugs.gentoo.org/692098 Package-Manager: Portage-2.3.69, Repoman-2.3.16 Signed-off-by: Fabian Groffen <grobian@gentoo.org> net-mail/notmuch/notmuch-0.29.1.ebuild | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
Has that fixed the issue for you?
Yeah, it's a fugly workaround I applied only for this platform, I didn't think you'd like as general "fix". (It isn't for real, but in the ebuilds we control/ensure a suitable version of gpgme that is installed, so it should be ok.)
I have just taken a look at the diff. It's not ideal indeed. I tried to reproduce the problem on amd64, no luck, tests "T350-crypto: Testing PGP/MIME signature verification and decryption" all pass for me. I have gnupg-2.2.17 and gpgme 1.13.0.
I have the same versions: app-crypt/gnupg-2.2.17 -bzip2 -doc -ldap nls readline -selinux smartcard ssl -tofu -tools -usb -user-socket -wks-server app-crypt/gpgme-1.13.0 -common-lisp cxx -python -python_targets_python2_7 -python_targets_python3_5 python_targets_python3_6 -python_targets_python3_7 -qt5 -static-libs so my assesment may be wrong then if it works for you. The compression algorithm seems to refer to zip, gzip and bzip2, I'll try and see if enabling bzip2 in my gnupg makes it work. ... and doing so indeed fixes the compression algorithm error. It still fails though. Looking into that, reveals it's actually gmime failing, most likely because: dev-libs/gmime-3.2.3 -crypt -doc -idn -static-libs -test -vala Recompiling with USE=crypt makes the check work as it should. So I'll remove my fugly hack, but we need to add dependencies, most notably for gmime[crypt], gnupg[bzip2] and gpgme. The first is in there already, but hidden by USE=crypt, which doesn't do anything configure-related. I think USE=crypt should be unconditional (as the configure script does).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4179ca5f4cc167dc98e71db943584b2f307d7e90 commit 4179ca5f4cc167dc98e71db943584b2f307d7e90 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2019-09-19 07:21:18 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2019-09-19 07:21:31 +0000 net-mail/notmuch: drop gpgme hack, it's a dep problem Bug: https://bugs.gentoo.org/692098 Package-Manager: Portage-2.3.69, Repoman-2.3.16 Signed-off-by: Fabian Groffen <grobian@gentoo.org> net-mail/notmuch/notmuch-0.29.1-r1.ebuild | 5 ----- net-mail/notmuch/notmuch-0.29.1.ebuild | 5 ----- 2 files changed, 10 deletions(-)
Fabian, can we consider it fixed?
