When the user has not ever selected a session from the selector, we will
log them into the `fallback' session, which is calculated by looking at
all installed sessions and picking the first one in the list.

There is a bug that the visually selected session presented in the
greeter can be different from the fallback session calculated inside
GDM. This happens because the two sort sessions differently.

Inside GDM we calculate the fallback session by comparing the full
basename of the file:

>>> GLib.strcmp0("gnome-xorg.desktop", "gnome.desktop")
-1

Whereas gnome-shell calls gdm_get_session_ids(), which returns IDs
without the ".desktop" extension. Those are then sorted:

>>> GLib.strcmp0("gnome-xorg", "gnome")
45

which gives a different ordering.

Fix this bug by calculating the fallback session in the same way, by
removing ".desktop" from the filename.

https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1705157

https://bugzilla.gnome.org/show_bug.cgi?id=787304

In theory, we're only only supposed to allow autologin
the first time a session is run, but we only count a
session run, once it's finished.  This means that if a
user creates a transient session to user switch, before
they've logged out the first time at boot up, that
transient session will begin autologin as well (which
actually gets treated as an auto unlock).

This commit makes sure autologin is only ever run on
the initial display.

https://bugzilla.gnome.org/show_bug.cgi?id=783779

If GDM shuts down while the login screen is active, we fail to
kill off the login screen session.

This commit fixes that, by explicitly stopping the greeter session
on the display (if there is one)

https://bugzilla.gnome.org/show_bug.cgi?id=780213

If a display starts out its life as a greeter display, and then
gets reused for the user session, we need to update the session-id
property on the display to match its new session.

This is important so the reauthentication mechanism is able to
match the session with existing display and run in the proper context.

https://bugzilla.gnome.org/show_bug.cgi?id=782182

We currently update the session type (to either wayland or
x11) when we first start the PAM conversation and later when
the username is set (if the user is not set at the same time as
the PAM conversation).

There's a race that means the session won't necessarly have been
read from accountsservice at these points.

This commit changes the code to instead update the session type
in result to the session actually getting read.

https://bugzilla.gnome.org/show_bug.cgi?id=781825

This was dropped in f66cdfcb but GDM won't start when the
default session-name is set to something else

https://bugzilla.gnome.org/show_bug.cgi?id=781793

commit 5c9e1205 attempts to handle
a session failing to start, but messages up the signal prototype
leading to crash.

This commit fixes that.

https://bugzilla.gnome.org/show_bug.cgi?id=781413

If we're running in legacy display mode, we currently can
end up with a leaked greeter following user switching.
That can happen if a user with an already running session
is reauthenticated (so the login screen won't morph into the
use session).

This commit makes sure we kill the greeter session off in that
case.

https://bugzilla.gnome.org/show_bug.cgi?id=780939

If we're running in legacy mode where VT1 is not necessarily a login
screen, then we can end up in a situation where logging out leaves us
sitting on the wrong vt.

1) log in to user 1 on vt 1
2) switch user to login screen on vt 2 and log in as user 2 on vt 2
3) switch user to login screen on  vt 3 and unlock user 1 back on vt 1
4) log out of user 1 on vt 1
5) now sitting at blank vt 1

This commit makes sure in that case we jump to a login screen

https://bugzilla.gnome.org/show_bug.cgi?id=780914

This are ignored by GTK3 and GNOME Shell now, and are only relevant
for GTK2 and other legacy apps now, not for GDM or gnome-initial-setup.

https://bugzilla.gnome.org/show_bug.cgi?id=780866

Daniel Drake authored Jan 02, 2017 and Mario Sanchez Prada committed Apr 04, 2017

The locked down dconf profile should not be used for the initial setup
session. This allows overridden values from the user profile to take
effect.

https://bugzilla.gnome.org/show_bug.cgi?id=780866

commit 4b47633b refactored some code
and inadvertently dropped an important comma, which broke user
switching.

This commit reintroduces the comma.

https://bugzilla.gnome.org/show_bug.cgi?id=780879

This should never have landed in the first place (I committed it by mistake
while pushing the patch for bug 780862) and according to the discussion in
bug 780866, it seems clear that this is not an upstreamable patch, not at
least in its current form.

This reverts commit 67ef79c1.

Sam Spilsbury authored Jul 21, 2015 and Mario Sanchez Prada committed Apr 03, 2017

Since automake 1.11.2 it is recommended that packages
use AM_DISTCHECK_CONFIGURE_FLAGS instead of
DISTCHECK_CONFIGURE_FLAGS as the latter is intended
to be a user variable.

Daniel Drake authored Jan 02, 2017 and Mario Sanchez Prada committed Apr 03, 2017

The locked down dconf profile should not be used for the initial setup
session. This allows overridden values from the user profile to take
effect.