Here's mirroring script that is in place currently:

#!/bin/bash -e

In T5960#168905, @ebo wrote:

Here is an other instance with broken encoding (on 3.1.27.0-beta44):

It's partially resolved, the rest is wontfix at the moment

I pushed your chnages and removed a lot more code.
See: rPabbecc67

works

works in 3.1.27.0-beta44

For Testversion 3.1.27.0-beta44 for "Regenerate key" now the same algorithms as in 3.2.0 are offered for a Yubikey and it is possible to move them to the smart card.
This is fine even for not VSD-compliant keys, as they are marked as such.

Here is an other instance with broken encoding (on 3.1.27.0-beta44):

This has been solved loooong ago.

@jukivili was so kind and does the mirroring now.

Actually this is about improving an error message.

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