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.

seems to be related to https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=a5f88f30ce612b0239b946c4424d81cf0d552e96

Backported for VSD 3.3

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.

@werner Shall this be backported to VSD 3.3? The changes look more dramatic than they are. I mostly reordered existing code.

See: MacPorts Ticket 70267 and MacPorts PR #24601

Oh, I did not notice the change as I clicked to the patch from mail notification. Trying now with the updated one:

Just to make sure, did you use the updated version of the patch? I edited the message with fix candidate and changed the attachment.

Running scratch build on s390x: https://koji.fedoraproject.org/koji/taskinfo?taskID=119376728 with the proposed change. The failure is now: