Its copyright notice in upstream now refers LICENSE file, which requires some arrangement.

So, I have something working… in the apparent absence of any sort of clear documentation that I could find. I had some time on my hands this afternoon, so had another look.

The key was generated without a passphrase.
Removing the pinentry-mode loopback parameter did not result in any popup at all but just gave me the below result:

Does the key have a passsphrase or somehow the empty string as passphrase?
If you don't use lookback mode: does the pinentry pop up?

Thanks for responding to this issue. The GnuPG2.29 is the version of GnuPG that came with the RHEL8.2 server provided for by our server engineer team(might be part of an RPM package the installed). Do you know if this issue got fixed in the later versions after that?

(I edited the report to make it readable, but did not yet looked at it in detail)
I wonder why you are using a decent libgcrypt but a 3 years old GnuPG version?

I work on gniibe/jitterent branch.
I realized that full featured jitterentropy now requires pthread. Timer-less mode uses threads for entropy. This is not good for libgcrypt use.

Sorry, I have been confused and it took time to understand issues.
Indeed, there are (at least) four issues.

Kleopatra now checks both keyserver options. Previously, Kleopatra checked only one of them depending on the version of gpg (< 2.3.0 vs. >= 2.3.0). Note that the automatic lookup is only done if the keyserver option specifies an LDAP server, i.e. if it starts with "ldap".

By the way he is the version details of gpg2.2.9_rhe8 that I used:
fubar:testingGPG2.2.9-> gpg2.2.9_rhel8 --homedir gnupg2.0 --version --verbose
gpg: WARNING: unsafe permissions on homedir 'TESTING_GPG2.2.9/gnupg2.0'
gpg (GnuPG) 2.2.9
libgcrypt 1.9.4
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Sure there are logs, see the options log-file and debug in the man pages.
To sign using specific subkey or the main key, use the fingerprint of the key and append an exclamation mark.
For example

I think we can close this bug. The warning will now only be printed as part of the the regression test and after all it is just a warning.

Will go into 2.3.4 which will also silence the noise of not being able to read it. The major reason for this code is to allow building an AppImage.

Thanks for the patch. That is sufficent. I added you to the Contributor group, though.

OK. Sorry for the noise. I got a clarification that the test is no longer needed so closing this issue.

I think that this is due to support of UTF-8 codepage problem by console.

Fixed. See parent task for details.

Result of self-test with failed compliance:

The thing is that any n.m.k-something version should behave versionwise the same as n.m.k. That is okay, because beta versions etc are not considered to be released. This is required to allow testing beta version _before_ doing the release.

From the FIPS Certs draft for RHEL 8.5, I have the following sentence:

Thanks for creating the issue.

Kleopatra now also handles a version like Gpg4win-3.1.16-beta15, but gpgconf --query-swdb seems to ignore pre-release identifiers:

$ gpgconf --query-swdb gpg4win 3.1.15-beta16
gpg4win:3.1.15-beta16:u::0:20211012T161328:20211019T103252:3.1.16:20210611T000000:0::

We are currently using "implict" service indicators but eventually we may change Libgcrypt to support explicit indicators.

Good point. I have added support for semantic versioning to Kleo::gpg4winVersionNumber().