Building with -fno-common now works for me on 2.2 and master. Thanks for the patch.

I took your patch but modified it to define EXTERN_UNLESS_MAIN_MODULE only at one place.

Note that we have a small pactch in the queue which should be applied by distributions to 1.37unless they want to wait for 1.38. See rEd72c1ddfde09ffa69745ec2439c5a16d15e2202f

Install the zlib development package, its name is often "zlib1g-dev". The source requires the header because we plan to eventually support compression.

Committed.

Thanks. Fix goes into 1.37.

It has been fixed in the repo for nearly a year, see T4459. A new release is urgently required and will follow in the next days. I close this as a duplicate.

Funny. I looked into the history of that function: @dshaw removed the option --list-trust-path from gnupg 1.x in December 2002. He commented

In a private mail someone else reported a similar problems and explained that gcc-10 will change the default from -fcommon to -fno-common. I think this is again a bad move in compiler development. Replacing the de-facto standard C compiler behaviour with something _allowed_ by ISO-C. No industrial grade toolchain would ever do such a silly default change - too many customers would rightfully be angry with them.

You mean that common blocks can't be used anymore? The RISC-OS had this problem but it was the only architecture I was aware of that required "extern" trickery.

We briefly talked in the OpenPGP WG about the u32 problem and agreed that this is not an issue for 2440bis. The mismatch between creation date and expiration period is one of those minor PGP flaws. PGP-2 even used days to specify the expiration period.

I would like to understand why this changed. T4061 might be relevant here. This has been fixed after the 2.2.19 release.

I don't care; encryption won't work for us 6ft under. (This is a protocol problem which someone should address in a couple of decades)

That looks pretty much like another gawk regression. The easiest fix is to install another AWK version (e.g. mawk).

FWIW, I found an open xterm with my query from last week:

@Valodim: I am pretty sure that last week it resolved only to a v4 address; today (and from another network and resolver) I get the same addresses as you.

ping keys.openpgp.org

The problem is likely that you don't have IPv4 support but keys.openpgp.org resolves only to a v4 address.
You should also use

BTW, I just pushed some new features to maste for the gpg-card tool. You can now do

Well that is due to "--debug packet" (aka --debug 1). We have this code

FWIW, the GTK and QT pinentries do have a qualitybar. However is is only enabled:

I agree.

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

It seems that gnome-keyring-daemon has some incompatible changes which breaks that version of pinentry-gnome. Or GKR has not been setup properly. I'd suggest to use pinentry-gtk until folks with knowledge about Gnome folks have figured out what is going wrong.