Created attachment 177065 [details] fix initialisation order After yesterday's update to libgpg-error 1.25 (ports r426175) gpg-agent (and scdaemon, dirmngr and possibly more) abort on startup with message "Assertion failed: (res == 0), function enter_npth, file npth.c, line 123". Investigation shows that the cause of this is a wrong order of initialisation of npth and libgpg-error - since the update, libgpg-error calls out to npth so npth needs to be initialised before libgpg-error. Upstream gnupg has fixed this in the upcoming 2.1.16 - but there was a lot of shuffling in the initialisation routines, which makes a direct import of their fix into our port about impossible. Upstream has been notified (or will be, once the mail makes it through greylisting). Attached patch does the naive thing and just moves the npth-initialisation up in the affected core (and drags the patch-doc-Makefile.in into makepatch format). Please note added patch files: M security/gnupg/Makefile A security/gnupg/files/patch-agent_gpg-agent.c A security/gnupg/files/patch-dirmngr_dirmngr.c M security/gnupg/files/patch-doc-Makefile.in A security/gnupg/files/patch-g13_g13.c A security/gnupg/files/patch-scd_scdaemon.c
(In reply to Christoph Moench-Tegeder from comment #0) Sorry for the breakage. :-( The release seems to be planned for tomorrow, though: https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032184.html
*** Bug 214576 has been marked as a duplicate of this bug. ***
Any news one this?
Fixing this would be more important than other "features".
(In reply to Roman Bogorodskiy from comment #1) I do not understand! Most people preferring the compilation way due to special needs do not have a rela chance to easily row back on ports broken like this! On all systems we updated the ports, we suffer seriously from this bug. -) claws-mail depends on gpg-agent when using pgp key infrastructure - mail is not working! -) A whole set of X11-based workstation, starting gpg-agent as the initiater for the windowing system do not start anymore due to the incapacitated gpg-agent!
It would be really great if something happend here quickly. As mentioned in the comments a lot of people suffer heavily from this problem. I used the attached patch to circumvent the issue using a custom patched and compiled port but that really shouldn't be the way to go for such an issue.
Created attachment 177181 [details] patch update to 2.1.16 gnupg 2.1.16 was released yesterday: https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032199.html Attached a patch to update the port to this version. As I don't use gnupg match, I've only checked that gpg-agent starts for me. I'm still building it in jails for different FreeBSD versions though. Anyway, if somebody can confirm that it fixes the issue, I'll try to reach portmgr so we can commit that without having to wait for maintainer timeout/approval.
(In reply to Roman Bogorodskiy from comment #7) s/match/much. Anyways, build tested on 9-10-11-12 amd64 and 10 i386.
A commit references this bug: Author: novel Date: Sun Nov 20 12:18:36 UTC 2016 New revision: 426573 URL: https://svnweb.freebsd.org/changeset/ports/426573 Log: security/gnupg: update to 2.1.16 This release fixes an issue that the previous gnupg release (2.1.15) was incompatible with libgpg-error 1.25 that caused gpg-agent failing to start. PR: 214568 Submitted by: cmt Tested by: cmt Reported by: many Changes: head/security/gnupg/Makefile head/security/gnupg/distinfo head/security/gnupg/files/patch-doc-Makefile.in head/security/gnupg/files/patch-tools_Makefile.in head/security/gnupg/pkg-plist
Assign to committer resolving
Thanks.
Merge-quarterly is not needed as libgpg-error is at 1.24 there. Closing this one.