Control: reassign 853066 pinentry-gnome3 Control: reassign 845565 pinentry-gnome3 Control: forcemerge 845565 853066 841909
Le Tue, Jan 31, 2017 at 03:38:23PM +0100, Vincent Lefevre a écrit : > On 2017-01-31 22:57:07 +0900, Charles Plessy wrote: > > Control: forcemerge -1 845565 > > Note that the bug was merged to itself. Do not use -1 when several > bugs are mentioned in To/Cc. I think that both bugs 845565 and > 853066 should be reassigned to pinentry-gnome3, *then* forcemerge'd > with bug 841909. Argh, sorry for the mess ! > > Do you think it might help to put the Debian GNOME maintainers in the > > loop ? Perhaps there is a GNOMEish way to ensure that the GNOME tools > > are launched in GNOME context, and text tools are launched in text > > context. > > In my case, I do not use GNOME at all, but expect X11 tools in a X11 > context (e.g. pinentry-gtk-2). IMHO, either pinentry-gnome3 should > detect the context and do the necessary fallback(s), or a pinentry > wrapper should be preferred to the alternatives system: it would > detect the context and launch the right pinentry-* program (with > fallback when not installed). Indeed, I think that pinentry-gnome3 should not be called in this context. For instance, from my SSH session, if I type `sudo apt install foo`, my password is prompted in text mode in the SSH session, not as a popup on a distant computer. Similarly, if I type `exit`, then the SSH session where I entered the command is ended; I do not get a popup on the distant computer asking if I want to close the graphical session instead. I think that the gpg ~ gpg-agent ~ pinentry chain should to the same: prompting the user at the location where the user ran the command, as it used to do in Jessie. I understand that this UI problem is quite far from what the Debian GnuPG Maintainers are able to commit to solve, and that the freeze is near. So where is the best place to call for help ? Perhaps planet.debian.org ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
