D398: 908_0141-dirmngr-More-win32-system-daemon-cleanup.patch

D397: 909_0142-dirmngr-hkp-Avoid-potential-race-condition-when-some.patch

D396: 910_0143-dimrngr-Avoid-need-for-hkp-housekeeping.patch

D395: 911_0144-dirmngr-Drop-useless-housekeeping.patch

D394: 912_0145-dirmngr-Lazily-launch-ldap-reaper-thread.patch

We're shipping these patches in debian unstable as of 2.1.15-9.

This has been changed in 2.1.16 to happen only every minute. Along with the
wakeup being done at the full second (as has been agreed upon for other
daemons), this should be more of an annoyance than a real problem.

In practice, dirmngr from git master still wakes up every few seconds due to the
ldap-reaper thread, even if no connections to ldap have ever happened.

the patch dirmngr-Lazily-launch-ldap-reaper-thread.patch avoids this additional
wakeup at least for those dirmngr instances that have never used LDAP.

D393: 914_0001-dirmngr-hkp-Avoid-potential-race-condition-when-some.patch

D392: 915_0002-dimrngr-Avoid-need-for-hkp-housekeeping.patch

D391: 916_0003-dirmngr-Lazily-launch-ldap-reaper-thread.patch

D390: 917_0004-dirmngr-Avoid-automatically-checking-upstream-swdb.patch

D389: 918_0005-dirmngr-Drop-useless-housekeeping.patch

I've updated the patch series here to the series we're using in debian for 2.1.16.

I just pushed the LDAP reaper patch for 2.1.17.

The LDAP stuff is mainly used for CRLs and is often hard to deploy because often
proxies are needed etc. I don't know a public one which is reliable enough for
testing. The one I used mostly was related to certain smartcards but those
cards expire faster than software can be deployed. Fortunately most public CRLs
are available via HTTP.

Another use are LDAP keyservers. I do not know a public service, Some
keyserver operators run them privately and Ireply on them to test GnUPG's support.

Please do not use "checking-upstream-swdb" patch.

Sure, for Debian and other distros the version number is of no use and should
not be used (I am still annoyed by xlockscreen thing). However disabling this
in dirmngr is the wrong approach. It should be disabled in tools which actually
use that service (e.g. KMail). The SWDB file carries more version information
than just GPA and is thus useful for developers who build their own version of
GPA or their own Windows installer. It has also nothing to do with the wakeups.

Having a dirmngr installed which does not work as described is a bad idea.

BTW: although we won't be able to implement key retrieval queueing into dirmngr
(e.g. for use with --auto-key-retrieve) in time for the Debain freeze, we will
add this later so that it may be available in a later point release. Obviously
this needs regualr wakeups to test for network connectivity and to process the
queue.

Patch 0001 should be applied to 2.3

Patch 0001 applied to master.