Thanks, I try to keep the README always up to date with the debian depenencies as I find this useful myself without running configure multiple times to find all the dependencies.

This won't work in the context of buildroot as we're passing --host="arm-unknown-linux-gnueabi" to avoid the following build failure:

We also need to support the use case of GNU cross style, like when we build with MinGW toolchain.

With GnuPG in master (to be 2.3), it can handle the second SKESK when the first one fails.

For other libraries, like libgcrypt, it is mostly OK with old gpg-error.m4, because those libraries don't depend on new libgpg-error features.

Fixed GnuPG in rGe1e3f1db4660: build: Update gpg-error.m4. and rG985e85dc0e6c: build: Update gpg-error.m4..

Fixed more in rEd7fd25bbfb83: build: Fix the previous change..

Thank you for the report. I had expected *-*-linux* matches only to GNU/Linux (Linux kernel with GNU C library).

Fixed with rCa5799f1618aaf1bbb52e7e121275228dd4a3ac8b

No question a list like this is bound to be incomplete, but the argument "the README can only tell about those which we don't expect to be installed on a developer's box" does not seem to apply to the other items already on the list. For instance build-essentials and automake are almost certainly on every developers machine already.

There is a message telling you what is missing. Thus I can not consider this a bug. There are just too many dependencies which are required for cross-compiling that the README can only tell about those which we don't expect to be installed on a developer's box.

I have a fix in a branch here: https://github.com/drichardson/gpg4win/tree/fix-missing-zh-readme

Backward compatibility fixed using the MacPorts legacysupport PortGroup:
https://github.com/macports/macports-ports/commit/74b50424649a7c657521140fcd7f92ba79a3cec5

Could you tell what is the status of this ticket? Is it planned for the development?
For some users usage is problematic when there are other readers recognized, provided by the OS or hardware platform, and ordered before the target device which in turn blocks access to it.

They are mandatory for gnupg but not for Libgcrypt and Libgpg-error. I guess we can fix that.

This does not look like a bug report. Please ask on a mailing list for help.

There is still useful software working only with 2.7. So it is not the time to drop this.

A page feed character is a very common and useful control character. In fact Emacs knows how to jump page by page.

This approach is too simplistic. See Ryan Schmidt's and Joshua Root's comments in https://trac.macports.org/ticket/62278

Somewhat related: before the change that resulted in the PIN issue, I already occasionally had to reconnect the reader because gnupg would ask for the card when it was in fact already present.

Because, threads are optional on uclibc as threads are not supported by all embedded targets.
libgpg-error was building perfectly fine without threads until version 1.40 as all pthread calls were protected by USE_POSIX_THREADS.
Should I understand from your answer that threads are now mandatory?

A beta release is available as https://gnupg.org/ftp/gcrypt/alpha/libgcrypt/libgcrypt-1.9.2-beta16.tar.bz2 (https://gnupg.org/ftp/gcrypt/alpha/libgcrypt/libgcrypt-1.9.2-beta16.tar.bz2.sig).

How does it come that you have a Linux kernel without threads? Or maybe the better question is why does libc not support threads?

Considered again, I realized that (1) is no need to check.

Good morning.

For 2.3.0 we won't be able to fix all bugs./feature requests. Instead we l will solve that in the 2.3 series.

Works for me.

dirmngr needs to be killed for this. gpgconf --kill dirmngr.

Meanwhile we introduced the keyboxd which should solve such problems. It will be marked experimental in 2.3 but I expect that it will soon be used as the default way to store keys - at least under Windows.