What you should is to to run

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

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++.

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.

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.

Okay. The option has been renamed to "only-pubkeys"

Debian uses symbol versions to help with library transition. See https://lists.gnupg.org/pipermail/gnupg-devel/2024-June/035587.html for more. Although I am not sure whether this is a good idea, I just released a new version 3.0.1 with just a chnage in the symbol versioning. See rAc9e902705a

Maybe we can support this directly in gpgme's assuan API.

Thanks for the detailed analysis; we will check to tomorrow why this was changed.

Using clang for Windows is not tested or suggested. Thus low priority.

Now also done for libksba.

Note: With rK3e029a4ed0059116febe05924a14009ca622e3c5 autogen.sh was extended with targets to run converage scripts. However, there is no real documentation and it is questionable whether autogen.sh is the right place - after all the coverage stuff needs more support in a project which can't be easily done in a general way in autogen.sh. These chnages to autogen.sh have meanwhile be replaced by standard autogen.sh.

Yes, please.

Different pinentries provide different options. The curses pinentry does not have that external password manager thingy. Mixing GUI and tty use seems to be a rare case.

Didn't you had this problem with 1.10.x ? I can't remember that we changed anything at theat code for years. The only recent change was rC656ca459e which should not have changed anything. Maybe the problem is elsewhere.

Frankly, having environ declared in unistd.h is a glibc convenience and other systems likey don't have it. easy to fix, though.

Please create a bug report instead of pointing to a specific commit. Sure the commit is helpful but w/o a bug report we can't track a bug. I'll do it for you this time ;-)