Thanks.
I didn't consider well about the test environment which uses special pinentry program.
I'll fix the line 155.

"Revoke Certification(s)" is available in

• Certifications Overview as context menu option for the user IDs
• Certifications Overview as context menu option for the signatures
• Certificate Details as context menu option for the user IDs
• Certificate Overview (aka key list) as context menu option for keys
• Certificate Overview (aka key list) as menu entry of Certificates menu

This change breaks tests/openpgp/delete-keys.scm:

# cd tests/openpgp
# TESTS="delete-keys.scm" make check
[...]
PASS: tests/openpgp/setup.scm
("/home/ingo/dev/g10/build/gnupg/g10/gpg" --no-permission-warning --always-trust --delete-secret-keys "A0FF4590BB6122EDEF6E3C542D727CC768697734") failed: gpg: can't do this in batch mode without "--yes"

Thanks for addressing this in master.

Works for me. Also with a gpg.conf-2 file. Do you use a /etc/gnupg/gpg.conf ?

The feature (better cross compiling) was done in master.
We close this bug report as "Won't fix" since it will never been applied to 2.2.

In newer releases of libgpg-error, libksba, libassuan, libgcrypt, npth and ntbtls, we updated corresponding *.m4, so that we can use new gpgrt-config program only. And gpgrt-config command supports cross compiling and multiarch libraries.

For 2.2, rG61aea64b3c17: scd: Fix the use case of verify_chv2 by CHECKPIN. fixed this problem.

Fixed in master.
(confirmation interaction is also fixed.)

Need another patch to export it:

diff --git a/g10/export.c b/g10/export.c
index 8dd0b07d7..339424e19 100644
--- a/g10/export.c
+++ b/g10/export.c
@@ -627,6 +627,57 @@ canon_pk_algo (enum gcry_pk_algos algo)
 }

It's fixed in master by T3465: --pinentry-mode loopback with --delete-secret-keys, with new confirmation interaction.
For 2.2, you can use --batch and --yes, see T4667: "gpg: deleting secret key failed: No pinentry" when in --batch mode with --pinentry=loopback.

Did you remove .gnupg entirely? Secret keys are stored in .gnupg/private-keys-v1.d. If it remained, you didn't import your secret keys.
If it was the case, I'd like to merge this report to T3391: cannot import subkey that was once marked to be on a card.

I reconsidered this. Suppressing such messages with --quiet is oka and will be in 2.2.24.

The "Reliability History" says (in Chinese):

异常代码: c0000005
异常偏移: 0002b6c0

The error code c0000005 is something like SEGV on POSIX, I guess.
It occurred at the address 0002b6c0.

In general, I agree. But, given that the whole file is Windows-only and highly Windows-specific (dealing with the Windows registry), does it make sense in this case?

For portability reasons it would be better to define F_OK if is is not defined.