This is now done :)

This is now merged in master :)

Optionally, (configurable on the Directory Services page) Kleopatra now queries WKDs for all user IDs when updating an OpenPGP certificate.

So this works for me now. The user where we build gpg4win has local diversions in ~/bin so as to not affect the GnuPG builds in any way and in the dockerfile we use update-alternatives to select the posix flavor.

I confirmed that the pselect EINTR problem of Linux (at least for x86) has not yet been fixed: https://lkml.org/lkml/2018/3/21/909

The MSI Package though is a 64 bit MSI Package. For 32 Bit Windows we would need to ship a different MSI Package. (Which we actually have build support for because I thought that was neccessary even in 2020)

No, everything in Gpg4win is 32 bit, except for gpgol, gpgex and gpgme, libgpg-error and libassuan. Which are addionally installed under bin_64. But for the whole KDE stack it should easily be switchable. The KDE Windows project regularly builds them as 64bit applications. Basically we would then need to invert the logic and use the 64 bit compiler as the main compiler and the 32 bit compiler as the _ex compiler for gpgol and gpgme.

Need to do this for the docker image and this way document how to do that with update alternatives. For our build setup it made most sense to manually link it only for the Gpg4win build user and not a system wide change.

Kleopatra is a 64 bit application, right? For GnuPG we are working on 64 bit support for Windows. This is planned for 2.6. problems are how to represent sockets, file descriptors, streams and so on. Regarding the time interface, we should have everything ready in the GPGME<->GnuPG interface. In GPGME we need to check that we don't use int instead of time_t, though. When that has been done/fixed we could use a 64 bit gpgme and kleopatra along with the 32 but gnupg. Might be easier for approval reasons.

Mh, since there are no 32bit Versions of Windows sold for quite some years now maybe we should consider just going full 64bit with everything to solve this? Or is this a stupid suggestion?

It turned out that we need to fix this for use by Kleopatra on Windows.

Fixed. Removing Gentoo tag because it's not Gentoo-specific.

It may be better to open a separate issue for the issue in gpg, so that it's not overlooked/forgotten when the issue in gpgtar is fixed.

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

This looks like the same problem I encountered in Gentoo's Portage. To unlock the binary package signing key, Portage will run the equivalent of gpg --homedir ... --digest-algo ... --local-user ... --output /dev/null /dev/null. If unlocking fails (due to e.g. wrong password), /dev/null is removed: https://bugs.gentoo.org/912808