Your message dated Thu, 25 Oct 2018 11:02:27 -0400
with message-id <87woq6m5mk....@fifthhorseman.net>
and subject line Re: Bug#911768: [pkg-gnupg-maint] Bug#911768: pinentry-gnome3
fails to open a window with 'No Gcr System Prompter available, falling back to
curses'
has caused the Debian Bug report #911768,
regarding pinentry-gnome3 fails to open a window with 'No Gcr System Prompter
available, falling back to curses'
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.)
--
911768: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911768
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: pinentry-gnome3
Version: 1.1.0-1+b1
Severity: serious
Hi!
pinentry-gnome3 (but also pinentry-gtk-2) does not open a window anymore to ask
for a passphrase. If run from terminal it shows:
No Gcr System Prompter available, falling back to curses
OK Pleased to meet you
It was working fine since years. Of the packages pinentry-gnome3 depends on, I
have only upgraded recently libgpg-error0, libncursesw6, libtinfo6.
Even downgrading libgpg-error0 to 1.32-1 does not fix the issue.
I am clueless, but willing to help to find the culprit...
Ciao!
Tiziano
PS: not sure it is relevant, but I am not running GNOME, I use fvwm instead.
Dbus is running.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages pinentry-gnome3 depends on:
ii gcr 3.28.0-1
ii libassuan0 2.5.1-2
ii libc6 2.27-6
ii libgcr-base-3-1 3.28.0-1
ii libglib2.0-0 2.58.1-2
ii libgpg-error0 1.32-3
ii libncursesw6 6.1+20181013-1
ii libsecret-1-0 0.18.6-3
ii libtinfo6 6.1+20181013-1
Versions of packages pinentry-gnome3 recommends:
pn dbus-user-session <none>
Versions of packages pinentry-gnome3 suggests:
ii pinentry-doc 1.1.0-1
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi Tiziano--
thanks for following up here! I'm closing the bug report as you
recommended, but i wanted to add a little more followup in case someone
else reads this.
On Thu 2018-10-25 13:03:12 +0200, Tiziano Zito wrote:
> It has nothing to do with pinentry. Given that I have a system with almost
> identical setup without dbus-user-session where everything works, and given
> that
> installing dbus-user-session in the affected system fixed the issue, I
> started
> digging deeper.
I'm glad to hear that installing dbus-user-session fixed the issue. I'm
inclined to make dbus-user-session a hard Depends: of pinentry-gnome3
instead of a Recommends: to avoid future problems like this. What would
you think of that change?
> For the record, in case in the future anyone hits the same problem: The only
> difference between the affected system and the working one was that the
> affected
> system starts nfs-kernel-server.service on boot. This was not only delaying
> the
> boot process (whish is somewhat expected) but additionaly the order changed
> in
> which systemd services were started, resulting in a different order than the
> one
> in the working system. I couldn't pin down exactly what service was the
> problematic one, but disabling the nfs-kernel-server.service fixed the
> pinentry
> issue...
this is strange to me, because i think nfs-kernel-server.service is a
system service, and gpg-agent.{service,socket} (from the gpg-agent
package) and dbus.{service,socket} (from the dbus-user-session package)
are user services -- they shouldn't have any direct interaction, and
they're actually managed by entirely different systemd instances.
> Given that installing dbus-user-session fixed the issue independent of
> nfs-kernel-server being enabled or not, I assume that the problem may be due
> to
> gpg-agent starting *before* dbus in the non dbus-user-session scenario, but I
> am
> only guessing.
This does seem possible to me, but i don't understand how it would
interact with nfs-kernel-server.service unless there is some sort of
more general operating system race condition.
At any rate, i'm glad to hear that dbus-user-session fixed the issue for
you! do you have any reason that you don't want to just leave it
installed?
Thanks for all the debugging and documentation!
--dkg
signature.asc
Description: PGP signature
--- End Message ---
