gdm3 does not start my ~/.xsession anymore but boots gnome instead.

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.

Control: tags -1 + confirmed moreinfo

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, 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

Re: Simon McVittie

Sorry that wasn't my intention.

If triaging the old bugs doesn't work because no one is doing it, I'd
say it's better to close all bugs that haven't been updated for a year
or so, with a message asking to reopen if the problem is still
present. Of course that's not the normal way we handle bugs, but
leaving 300 bugs open (and most of them unattended) isn't useful.

Christoph

Please try with gdm3_3.38.2-1 when it becomes available on your mirror.

    smcv

Re: Simon McVittie

Hi,

I confirm that both the "System X11 Default" and "Default X11 Session"
options start my .Xsession file. (Iirc the second option was missing
in the old version.)

Thanks, and sorry for having been so indignant about the BTS
situation.

Christoph

Control: clone -1 -2
Control: retitle -2 gdm3: options for both "System X11 Default" and "Default X11 Session"
Control: severity -2 minor
for "unspecified OS default" (which is not actually the default for gdm
because we want to default to GNOME on Wayland, so maybe we should rename
it to not have "default" in its name).

I don't have this. I currently have options for:

* System X11 Default
* GNOME
* GNOME Classic
* GNOME on Xorg
* Weston

which come from

* /usr/share/gdm/BuiltInSessions/default.desktop
* /usr/share/wayland-sessions/gnome.desktop or /usr/share/xsessions/gnome.desktop
* /usr/share/xsessions/gnome-classic.desktop
* /usr/share/xsessions/gnome-xorg.desktop
* /usr/share/wayland-sessions/weston.desktop

respectively.

I think gdm looks for these in /usr/share/gdm, /usr/share/xsessions and
/usr/share/wayland-sessions; possibly also /etc/gdm3. Please grep these
locations for 'Name=Default X11 Session'?

It isn't ideal that we have an option for "it does something but we
can't tell you what", but we don't have enough information to do better,
and even if we could look into individual users' home directories to
see whether they have ~/.xsession and display that in the greeter,
that would be an information leak.

    smcv

Control: tags -1 + moreinfo

I think I might have found the root cause for this. Do you perhaps have
lightdm installed, even though you are not actively using it?

lightdm installs /usr/share/xsessions/lightdm-xsession.desktop, labelled
"Default Xsession", which starts the traditional x11-common session
(~/.xsessionrc or similar).

Unfortunately, it installs this into a location where *all* display
managers that work like this (including gdm3, sddm, lxdm, slim) will
load that session definition, even though it is not intended for them.

I think this is a lightdm bug (#1004559) and it should either not install
that session definition at all, or install it into a location where only
lightdm will see it (such as /usr/share/lightdm/sessions).

Following this logic, I removed the "System X11 Default" option in
gdm3/41.0-1. Instead, there is now an example file
/usr/share/doc/gdm3/examples/custom-x11-session.desktop which can be
copied into /etc/X11/sessions and customized as needed. This is the
method recommended in upstream GNOME documentation for defining local
sessions.

    smcv