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.

@werner Shall this be backported?

The import option "only-pubkeys" works for me/Kleopatra.

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.

Did some experiment and I concluded (for now) that new command for gpg-agent would not be needed.
Instead, it might be better doing following in GPGME.

Pushed the change to master. Please test.
rCbb0895bbb7c6: m4: Fix acinclude.m4 for underscore detection in the symbol.

Thank you for the report.

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

In T7175#187690, @jukivili wrote:

Hm, CFI directives should not be used on WIN32 target. This patch should solve the issue for now:

0001-src-hwf-x86-disable-inline-assembly-CFI-directivies-.patch984 BDownload

Here is a fix for the issue which preserves the removal of cut:

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

I tried to reproduce issue with clang/w32 toolchain from https://github.com/mstorsjo/llvm-mingw but there build worked even with CFI directives.

Hm, CFI directives should not be used on WIN32 target. This patch should solve the issue for now:

Thanks for testing. I pushed this fix to libgcrypt master.