The particular part of mkheader compilation with -O0 was introduced by dkg for cross build support.
I believe that -O<number> (where <number> is not zero) is common but -O<something-other> is dependent.
Requesting non-optimization by -O0 seems GCC specific.
(I grep-ped autoconf-archive and observed the use cases of -O0.)

Here's an excerpt of the output which should cover the critical step. Let me know if you need more/all.

Well, that was probably from the time I wrote that tool.

Sorry, there have been quite some bindings with similar names, so I couldn't identify which one this is about. Can you please run with your test code with GPGME_DEBUG=9:/foo/gpgme.log set which makes it it easier to understand what is going on.

Hi, this is using the Python language bindings provided by GPGME. I am the author of gnupg.py which my attempt to use those bindings to revoke a signature.

I do not know this Python library. It looks like one of the older binding to GPGME. Please contact the author of gnupg.py or switch over to the Python language binding we provide with gpgme.

As a user I think that this capability would be a great addition to PGP and it might even make it a standard tool for key generation across cryptocurrencies.

(Found while trying to answer a user question at http://wald.intevation.de/forum/forum.php?thread_id=2140&forum_id=21&group_id=11)

PS I forgot to say why movement to cmake will be the best way.

I totally disagree.

Please read libgpg-error's README. For each architecture we need to have a dedicated config file - this has nothing to do with autotools. Big and little endian variants are obviously different architectures. Here is an excerpt from the README

Hello @wener, I want to say that libgpg-error is the only one (!) application that fails to cross compile using valid toolchains: "armeb-unknown-linux-gnueabi" and "aarch64_be-unknown-linux-gnu". It compiles and runs perfectly using "arm-unknown-linux-gnueabi" and "aarch64-unknown-linux-gnu", but fails with big endian. I see project are actually using "hton/ntoh" so we shouldn't see this error. What this problem is about?

Please do not do such changes after you found a solution. I assume this was some kind of error you won't further explain. Better just close it as invalid.

The Name field in GnuPG needs to be at least 5 _bytes_ long. Given that UTF-8 is required for Hangul, a 3 _character_ name is at least 6 bytes long and thus passes gpg check. The Name field is also optional and the whole test can be skipped using --allow-freeform-uid.

Fixed in master and 2.2

there is no way to handle this correctly with such messages. The PGP Standard says that PGP Messages may have every encoding. This is a reason why we always talk about "you should use PGP/MIME" as this is basically PGP with added handling for content meta information like the text encoding.

It has now been over 6 months since the patches were available to fix this problem and they have not been adopted upstream.

This is fixed now.

This is fixed in Gpg4win-3.1.11

Related task: About subkeys is T4028

Prio raised and assigned to werner as he asked for it.

Considering the concrete use case(s), it is more rational to support listing by capability.