works. Tested on 3.1.26 with AD configured as keyserver.

closing, as the remaining issue is covered by T6093

@tlaurion Thank you for the report, but your particular problem is irrelevant to this ticket.
I lightly looked the log and noticed that the cross build would have some confusions for pkg-config, however, that's not our problem but yours.
For the particular failures in your build, the issues look like a problem of musl linker. It seems that it requires all dependency of libraries to be used, even if an executable doesn't use a library directly.
If it is the case, we need a patch... something like:

@gniibe
Trying to crosscompile newer 2.4 gpg toolstack from Heads OSF under PR https://github.com/osresearch/heads/pull/1350

The lookup also uses WKD (if the search term looks like an email address). (Maybe only if WKD is configured as auto key locate mechanism.)

Thanks for your follwup. Let me remark that it is sufficient to stop all gnupg processes (pkill gpg-agent) and then rename the ~/.gnupg to .gnupg-save-NNNN. This way you have a backup and gpg will create a new ~/.gnupg.

FWIW, some cards don't have PUKs but two PINs which are able to unblock reciprocal.

OCB mode (i.e. packet 20) is only used if the keys announce it. Thus only after moving a (private) key from GnuPG to a non-GnuPG compatible implementation you will run into this problem. The compatibility options won't override the preference system.

Should we also differentiate between wrong PUK and no PUK set?

Pushed the change.

Having GPG_ERR_BAD_PUK makes sense. So, I added a tag for gpg-error.

closing with reference to external testing

Fixed in master (of libgpg-error).
Pushed the change to libgcrypt (master and 1.10 branch).

works in gnupg24.

works

I'd say yes.

The "Secret key backup error" does not appear any more.
But if I hit "cancel" on the pinentry window, still a second pinentry window for the subkey pops up. No matter if I give the correct password in the second pinentry window or not, the backup is silently abandoned.

Thank you for the bug report.

We need to extend dirmngr_ldap.c to take a list of attributes to return. We already have the --multi option which returns all attributes for latter filtering by the caller but the specified attr is also used and thus dirmngr's start_cacert_fetch_ldap() retruns only the requested caCertificate.

Things for 2.4 are all done.

For 2.2 we will for now only implement the encryption.

yes, confirmed. And if I insist on choosing this certificate via the selection dialog I can not encrypt to this certificate, as sign/encrypt is grayed out. (As long as there is no valid key chosen additionally.)

@gniibe: Would you mind to look at this?

closing with reference to external testing

ok, ticket for the new issue is T6418