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).

I'm sorry, if my wording sounded harsh.

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?

Thanks. A few hours too late for 1.9.2.

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.

In T1756#143328, @gniibe wrote:

In T1756#131862, @whites11 wrote:

I understand this is kind of an edge case, but having the possibility to use signed ssh keys would be very useful to me.

??? Do you understand how ssh keys are handled by ssh client and ssh-agent?

In T1756#131862, @whites11 wrote:

I understand this is kind of an edge case, but having the possibility to use signed ssh keys would be very useful to me.

Backport was done with commit rC1d312bc65846 (for unknown reasons it did not show up in the list of bugs related to this bug; I added it by hand). Fix will go into 1.8.8.

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 found that the use of $CC -print-file-name=crt1.o won't work with some cross compiler.
For example, on my system of Debian bullseye for cross compiler ppc64el, while it's for multiarch configuration, crt1.o is under GNU cross style directory: /usr/powerpc64le-linux-gnu/lib

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.

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