Well, it's a (hard) requirement unless you explicitly disable efl, i.e. ./configure (without --disable-efl) fails with an error if elementary or ecore-x is not found.

I don't think the patch made elementary and ecore-x dev headers an absolute hard requirement; in particular, ./configure --disable-efl works fine to build pinentry without having these headers installed.

The following patch makes the efl requirements optional unless pinentry-efl is explicitly enabled:

diff --git a/configure.ac b/configure.ac
index bc67c14..ce170c9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -423,7 +423,24 @@ AC_ARG_ENABLE(pinentry-efl,
             pinentry_efl=$enableval, pinentry_efl=maybe)

rP19a18ba5fee0 makes elementary and ecore-x hard requirements for pinentry. I don't think that's intended.

Thanks for the verification, @wltjr. I've pushed 19a18ba5fee049aac87b5114763095aaeb42430f to the master branch for future releases.

Btw, ecore-x was also needed, so that should remain. Just to be clear, the final version should be

PKG_CHECK_MODULES(EFL,[elementary >= 1.18,ecore-x])

Give or take the >= vs >.

@dkg it was the 2nd one, the EFL vs efl. That worked fine after uppercasing it! The >= may not be necessary, but might as well. I am on a much newer EFL, 1.25.1, so not really able to test that part of it. I should be running one of the latest autotools,

[ebuild   R    ] sys-devel/automake-1.16.3-r1:1.16::gentoo  USE="-test" 0 KiB
[ebuild   R    ] sys-devel/autoconf-2.69-r5:2.69::gentoo  USE="-emacs" 1,438 KiB
[ebuild   R    ] sys-devel/libtool-2.4.6-r6:2::gentoo  USE="-vanilla" 951 KiB

Pushed the change. Please test.

See the comment in rE13918d05a333: Allow building with --disable-threads. for ABI incompatibility.

hm, actually, maybe the efl should be EFL in order to produce and substitute the EFL_CFLAGS and EFL_LIBS variables.

@wltjr maybe it needs ecore-x as well as elementary > 1.18 in the PKG_CHECK_MODULES line? oh, and looks like i screwed up and used > where i should have used >= sorry! fixing those would make the PKG_CHECK_MODULES line be:

With the third case it accesses the settings file, but does not write anything.

When does it work and when not:

• It works: if I change columns, column widths, sorting column or window size. Then close Kleopatra and restart it within the same environment (screen size).

Kleopatra running on Linux (Ubuntu 20.10, 21.04; Fedora 34, 35 (rawhide)) does this. Closing Kleopatras window saves columns and column widths as shown (it even works if I change the systemwide used font).
On Windows 10 this does not work. Closing Kleopatra via the windows "Close Button" or by selecting "Close Window" or "Exit" from the main menu settings will not be saved. Opening the window again will show columns as they where after installing (way to small for displaying the dates created and expired and the hash of the key). The sorting column is lost too on Windows, but not Linux.
I am unsure if this bug is triggered by my company setup, or if it exists on any Windows 10 installation.

Looks like its missing an include

x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..  -pthread -I/usr/include/libsecret-1 -I/usr/include/gio-unix-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/lib64/libffi/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include    -I/usr/include/ncursesw -I../secmem -I../pinentry -Wall  -O2 -pipe -march=amdfam10 -mcx16 -msahf -mabm -mlzcnt -Wall -Wno-pointer-sign -Wpointer-arith -c -o pinentry-efl.o pinentry-efl.c
pinentry-efl.c:32:10: fatal error: Elementary.h: No such file or directory
   32 | #include <Elementary.h>
      |          ^~~~~~~~~~~~~~
compilation terminated.

@dkg for sure, I will test out the patch ASAP. Thanks for the ping.

I think you're saying "GnuPG will reject all subpackets marked with a critical flag unless there is a specific known semantic for *criticality* for that subpacket" Am I understanding that right? Is there a published list of criticality semantics that GnuPG is willing to accept? How do those semantics differ from standard semantics for the packet in question?

fwiw, i think a patch like this ought to work with reasonably-modern versions of autotools:

@wltjr maybe you could take a look at this?

werner this would really be a bug because we have code in Kleopatra to both save the selected coloumns, their widths and the sorting state.

The mix up of external patches and commits makes it not easy to see what has been fixed. AFAICS rC3d095206c30d fixes the last bug mentioned by @ballapete on Jan 26.

When building with no threads support, I think that generating same lock-obj-pub-$host.h is just possible by this change.

Tell us the architecture(s) which doesn't support POSIX threads by uClibc.
Adding support for such an architecture would be the best.

Sorry, I was assuming uClibc were not supporting POSIX threads.

Thank you for more information.

I was not the author of the host "hacking" which has been committed to buildroot in 2016 by https://git.buildroot.net/buildroot/commit/package/?id=2f89476ad98b82ea9f914337b0050c4808082c82 so I can't really comment on it.
You can find more information here: https://patchwork.ozlabs.org/project/buildroot/patch/1451762923-15985-1-git-send-email-joerg.krause@embedded.rocks/
Especially, it seems that Jörg Krause started a discussion about this issue and proposed a patch to fix the architecture depends but it was never applied. Unfortunately, I wasn't able to find more information as it seems that links on comments.gmane.org are broken ...

Please note that the result with --host="arm-unknown-linux-gnueabi" for linux-uclibcgnueabih machine is different to the one of correctly generated version by gen-posix-lock-obj.c with USE_POSIX_THREADS undefined on the host.

I would understand your workaorund of using artifical --host intentionally.

Merged your fix. Thanks for the contribution. Commit should show up here in a second.

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

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

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

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

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

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

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?

Good morning.

The now used /var/run thingy solves all these problems nicely. In fact we may eventually remove the use fallback of using sockets in the GNUPGHOMEDIR.

Eventually we will move to keyboxd which is already an experimental option in 2.3. Thus we won't do anything here.

The other patches don't make sense because of future plans for dirmngr.

Critical attributes are well known from CMS and X.509 and some have a history which can only be described as cargo cult. We should not allow them in the OpenPGP ecosystem without giving them a specific semantic aside from "we do something with it".

Done. FWIW. in 2.3 symcryptrun will be removed entirely.

RFC 4880 says:

POSIX says so (use printf instead).
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

Without any defined semantic it is not proper to ignore a critical bit. The software which created this keyblock seems to aim for incompatibility.

iirc the advise from the GNU coding standards is to use printf(1) instead of trying to figure out how echo(1) works.

Thank you. I'll fix. Perhaps, I'll ignore old UNIXen like AIX 6.1, which has no way to echo with no newlines.

The problem ist not an "ugly error message" but it does not recognize that the e-mail IS encyrpted by Symantec-PGP! But the plugin always says:

Actually I would be in favor of removing this portable thingy. It is and will always be the worst and most insecure way of using crypto.

Looks like this has been addressed in af23ab5c5482d625ff52e60606cf044e2b0106c8. A quick test building the current version in master with --disable-asm worked for me.

Unfortunately, building without "--disable-asm" does not work if building a universal package under MacPorts (e.g. 32bit and 64bit x86 or 64bit x86 and arm64).