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:

For the white high-contrast mode we use the normal (black) Breeze icons now. I think for Qt 5 that's all we can do with reasonable effort. For Qt 6/KF6 we have to revisit this anyway because a lot has changed (see T6932).

Selection with unpatched Qt:

Did you used the speedo build method? Did you install libassuan first?

In D601#6503, @ikloecker wrote:

I found the following in this file. This looks as if everything should stay as it is.

/* Note for Windows: Ignore the incompatible pointer type warning for
   my_read and my_write.  Mingw has been changed to use int for
   ssize_t on 32 bit systems while we use long.  For 64 bit we use
   int64_t while mingw uses __int64_t.  It does not matter at all
   because under Windows long and int are both 32 bit even on 64
   bit.  */

gpgme_ssize_t is even documented in gpgme.texi.

I found the following in this file. This looks as if everything should stay as it is.

/* Note for Windows: Ignore the incompatible pointer type warning for
   my_read and my_write.  Mingw has been changed to use int for
   ssize_t on 32 bit systems while we use long.  For 64 bit we use
   int64_t while mingw uses __int64_t.  It does not matter at all
   because under Windows long and int are both 32 bit even on 64
   bit.  */

Our Makefile does not use -Wincompatible-pointer-types for a reason. Please build gpgme only the standard way, i.e. by using ./autogen.sh --build-w32. Keep in mind that C is an entire different language than C++.

Looks good to me

Cast instead of using FARPROC

For VSD the key actions "Regenerate key" and "Generate key" should be hidden. (This is in the middle part of the view)

scdaemon part was done in: rG36d8cffc6cd2: scd: Finish DEVINFO --watch command on input close.

Thanks.

Reading the original bug report it is clear that this is not a gpg bug but a problem in the Python code. This should only be read as utf-8 if the NOTATION_FLAGS line indicated that this is human readable.

The use of putc_unlocked has long been removed. So we should also remove the declaration. Normally this does not harm but in your case you may want to pass CFLAGS="-DHAVE_PUTC_UNLOCKED" to make or remove the above declaration.

Backported for VSD 3.3

The point here is to escape control characters so that we do not run into problems when reading the stuff. Escaping non-ascii (c >127) is not required and would put a lower limit on the number of (utf-8) characters we can print via the status lines.
Note also that we use almost everywhere ascii versions of the character checks. Thus I would not consider this a bug.

Yes. please.

Verified the fix.