Everything mentioned above was translated and is now shown that way in all three languages.

I would keep the "create group", too.

In T7515#198012, @alexk wrote:

Regarding the suggest list I would change the following:
but keep:

• Enable/Disable Certificate

Regarding the suggest list I would change the following:

That is not a new issue. We have the very same issue since ever. However, without keyboxd you had random results depending on the order of the keys in the keyring.

That is an installation/migration question and the warning is just a convenience thing to remind the few early users of keyboxd to migrate to common.conf.

As usual use ./deadbeef.... as the filename to distinguish it from a fingerprint.

To be clear about what's going on here, blocker.cert has simply adopted the primary keys of each certificate found in /usr/share/gnupg/distsigkey.gpg -- i think GnuPG requires each component key in its keystore to have a unique fingerprint across all component keys in the keystore. so when one certificate claims those fingerprints as subkeys, any certificate that has a primary key with a matching fingerprint gets rejected with doesn't match our copy.

I understand you as saying you won't fix the fact that the warning is not emitted during initial homedir setup. I'm not sure why that scenario is not worthy of a warning when a post-setup scenario is, but okay.

thanks for correcting that, @ikloecker. i've corrected the initial report.

I did a quick test with a test user running a Wayland session and the AppImage works now.

What about deleting the environment variable in gpg-agent:

gpg-connect-agent 'OPTION putenv=DBUS_SESSION_BUS_ADDRESS' /bye

or to use a pinentry-wrapper?