The option "default-new-key-adsk" of gpg can now be read with Kleo::getCryptoConfigEntry, so that we can check if an ADSK is actually configured to decide whether it makes sense to offer the "Add ADSK" action.

Backported to 2.4. Options are now listed with gpgconf.

Fixed in rG01fa318be0f8: scd: Fix how scdaemon pipe server finishes.

Can this be accepted? Since GPGME is doing a direct syscall, rather than going through the libc wrapper, there's no need for it to use libc-specific types. It makes more sense (and is more portable) to use the sized types equivalent to the definition that the kernel uses.

is there a keyring/password manager that is not dependent on a desktop environment that the terminal pinentry supports?

Yes, the SO number changed. Before that you had run the test with an old version of the library or maybe the current one depending on your system. However, a changed SO number means that you have can have two versions of the library installed and they don't alias them with symlinks. We rarely update SO numbers but int he libassuan case we did it because technically we had a minor ABI change but GnuPG and Cie. are not affected; we did it anyway to be correct.

Testing with various versions of kleopatra, I'm getting differing results:

Strange - running sudo ldconfig prior to make check did indeed allow the tests to pass and the gnupg executable to build. I don't recall needing to do that until now; has something changed?

What you should is to to run

Then I would propose to add additional text at the top of the tool tip for VSD versions only. Something along the lines of: "Please check with the approval document whether this function is compliant for your smart card model."
Would that be possible?

Kleopatra and likely also gpg have no way to know what products are listed in some approval document. And it would be very problematic to hard-code such a list in Kleopatra/gpg because it wouldn't be possible to update the list if new products are approved (which is very likely).

I have improved the heuristic for detecting light high-contrast themes. Upstreaming this is still open.

What makes a card compliant? is it just about supporting algorithms that are compliant?

Asking a change of gpgme would need more time... So, I decided to change gpg-agent side.
gpg-agent part was done in: rGb3f1f2cd192b: agent: Handle SCD DEVINFO --watch command in a special way.

I don't know what the "speedo build method" is, so no. I've built this software many times before with the usual routine: