[pkg-gnupg-maint] Bug#911768: pinentry-gnome3 fails to open a window with 'No Gcr System Prompter available, falling back to curses'

[Daniel Kahn Gillmor]

On Tue 2019-03-12 15:01:26 +0000, Simon McVittie wrote:
> If I understand their position correctly, the Debian systemd maintainers
> would consider that to be a misconfiguration, because
> Depends: libpam-systemd is the official way for a package to say "I need
> a fully working systemd-logind and systemd --user", and packages like
> dbus-user-session are allowed to assume that. If a sysadmin wants to
> not use pam_systemd (which will mean their systemd-logind doesn't work
> correctly and systemd --user doesn't get started), they should remove
> that package so it doesn't satisfy dependencies.

thanks for this clarification, it sounds reasonable to me.

> I'd be very tempted to make dbus-user-session the only implementation of
> dbus-session-bus on Linux if it wasn't for the systemd-related political
> reasons not to, because it's becoming increasingly clear to me that the
> "one bus per X11 display" case is decreasing in viability over time
> as upstreams and packagers both start to assume (the equivalent of)
> dbus-user-session.

This makes me a little bit sad, as someone who has in the past made good
use of multiple X11 displays for the same user, but i agree that it
reflects current reality pretty clearly.  Furthermore, the main use
cases i had in the past for multiple X11 displays were (a) testing, and
(b) X11 isolation, both of which are better served by a distinct user
account in the first place.

> No, I don't think we should. Many packages explicitly use dbus-launch
> (which is in dbus-x11.deb), even packages that should really be using
> something else (see my 2016 MBF). Historical design choices in dbus-launch
> mean that it does two different things when run with different options:
> some options try to reuse an existing bus, but some options guarantee
> to start a new bus.

fwiw, i helped someone debug a problem on IRC the other day, and it was
due to unnecessary use of dbus-launch in their ~/.Xsession (they were
doing something like "exec dbus-launch awesome" instead of just "exec
awesome", even though they had dbus-user-session installed).

So the existence of dbus-launch on their system was actually causing
them problems.  I think this was a case of problem-solving via "don't do
that then", but it seems likely that many folks have cargo-culted
dbus-launch into places where they don't necessarily need it, and where
it was unable to fall back to the dbus per-user session.

thanks for all of your work in fixing as many of these corner cases as
you've done, it's much appreciated!

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20190312/77541d9b/attachment.sig>