Bug#973485: gdm3 starts gnome instead of .xsession even when "Default X11 session" is selected

[Simon McVittie]

Control: tags -1 + confirmed moreinfo

On Sat, 31 Oct 2020 at 16:35:27 +0100, Christoph Berg wrote:
> gdm3 does not start my ~/.xsession anymore but boots gnome instead.

I can reproduce this with "#!/bin/sh", "exec openbox" in a test user's
~/.xsession. (Obviously you need openbox for that to work, or replace
openbox with whatever you actually wanted to run.)

I think the root cause might be
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972108>. Do you see
"has_option: not found" in the system log (systemd Journal or syslog)
during login? If you apply the patch from that bug to /etc/gdm3/Xsession,
does that work? It seems to work for me, with my openbox-based reproducer.

(My understanding is that gdm doesn't/can't use the centralized
/etc/X11/Xsession from x11-common because its calling convention is
different.)

> Sorry if that bug was already reported, but no way I'm going to read
> through the 300 (!) open gdm3 bugs. Please do some BTS house keeping.

Sorry, the Debian GNOME team do not have the resources to work through
the GNOME packages' backlog of years-old bugs. I wish we could, but the
active team members are as overloaded as all the other major teams,
and it's as much as we can do to keep up with recent bug reports. If
you can help, please do.

User-facing desktop packages attract a steady stream of bug reports,
many of them unclear or from inexperienced users who need a lot of
help before they can provide enough information to understand the bug,
for components throughout the stack (because there's no good way for a
non-developer to know that a symptom in "GNOME" might really be a bug
in something like gnome-settings-daemon, Mesa or the kernel).

I sometimes put a few hours into dealing with older bug reports, but I
can't do that routinely, and the result is usually not noticeable. People
in Debian tend to get upset at any suggestion that we might consider
closing old bugs without being able to point to a specific code change
that fixed them, so the default is that they stay open forever, making
it a daunting task to even start triaging.

If your intention was to make me or another active team member feel
guilty enough to drop everything and spend a day triaging, I'm sorry,
but that isn't sustainable: if I take on extra responsibilities every
time someone complains about a team that I'm already trying to help,
that's how we get burned-out maintainers who abandon the project and leave
the remaining team members more overloaded. Even if we don't care about
maintainers' well-being (which we should), that seems counterproductive.

    smcv