Your message dated Wed, 8 May 2024 18:21:46 +0200 with message-id <zjumms8cfyyps...@argenau.bebt.de> and subject line Re: Bug#1070688: gnupg: PINENTRY_USER_DATA not passed to pinentry has caused the Debian Bug report #1070688, regarding gnupg: PINENTRY_USER_DATA not passed to pinentry to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1070688: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070688 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: gnupg Version: 2.2.40-3 Severity: normal X-Debbugs-Cc: in.cognit...@arcor.de Dear Maintainer, * What led up to the situation? Most likely today's upgrade from GnuPG related packages 2.2.40-1.1 -> 2.2.40-3. "Yesterday this still has been working." * What exactly did you do (or not do) that was effective (or ineffective)? Use my custom pinentry that relies on PINENTRY_USER_DATA (or on Assuan command "OPTION pinentry-user-data") being passed through from client to pinentry. * What was the outcome of this action? Environment variable PINENTRY_USER_DATA is not set when the pinentry is called, and OPTION pinentry-user-data is not provided by the caller of the pinentry. * What outcome did you expect instead? The information set in environment variable PINENTRY_USER_DATA being forwarded from the client to the pinentry. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnupg depends on: ii dirmngr 2.2.40-3 ii gnupg-l10n 2.2.40-3 ii gnupg-utils 2.2.40-3 ii gpg 2.2.40-3 ii gpg-agent 2.2.40-3 ii gpg-from-sq [gpg] 0.8.0-5 ii gpg-wks-client 2.2.40-3 ii gpg-wks-server 2.2.40-3 ii gpgsm 2.2.40-3 ii gpgv 2.2.40-3 ii gpgv-from-sq [gpgv] 0.8.0-5 gnupg recommends no packages. Versions of packages gnupg suggests: pn parcimonie <none> pn xloadimage <none> -- no debconf information
--- End Message ---
--- Begin Message ---On 2024-05-08 Farblos <in.cognit...@arcor.de> wrote: > Never mind. During one of the last t64 upgrade orgies package gpg-sq got > installed on my system and succeeded to install the diversion to /usr/bin/gpg. > And the sequoia replacement is not very feature complete, as they continue > to stress themselfes. > For example, referencing a recipient by exact name with "=<recipient>" does > not work in gpg-sq, either. > I just purged gpg-sq and its dependencies and now I'm back to normal. > Feel free to close this issue. Hello, thank you very much for both sending a good bug report and actually finding a solution, too. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
--- End Message ---
