| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
The user may have configured the user environment via
user.conf or other means. This commit makes sure this session gets
those environment changes.
|
|
|
|
|
|
| |
Right now we crash on clean up paths if the programs are invoked wrong.
This commit fixes that.
|
|
|
|
|
| |
This makes it behave more like gdm-x-session. Also, we're
going to need the connection in a minute.
|
|
|
|
|
|
|
|
|
|
|
|
| |
DBUS_SESSION_BUS_ADDRESS is not the preferred way to find the session
bus these days. Instead it's expected to be found at $XDG_RUNTIME_DIR/bus
This commit changes the session launcher code, to just try to get a
connection to the bus explicitly, instead relying on
the presence of DBUS_SESSION_BUS_ADDRESS to know whether to start a
fallback bus.
https://bugzilla.gnome.org/show_bug.cgi?id=770395
|
|
|
|
|
|
|
| |
I just noticed when reading the code that we pass a cancellable into
the function, but then don't use it.
https://bugzilla.gnome.org/show_bug.cgi?id=770396
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the user has an encrypted disk then systemd will cache the password
they type into the keyring. It makes sense to try to use this password
for automatic login purposes first, since on single user machines,
the sole user password is likely to match the disk password.
Of course if it doesn't work we'll fall back to the old way of doing
automatic login without a password (and then the user will have to
manualy enter if they need to for gnome-keyring or whatever)
https://bugzilla.gnome.org/show_bug.cgi?id=769950
|
|
|
|
|
|
|
| |
It doesn't do anything yet, but it will eventually get used for
autologin purposes, and maybe other things.
https://bugzilla.gnome.org/show_bug.cgi?id=769950
|
| |
|
| |
|
|
|
|
| |
It only has the chooser in it, so just move the chooser to the toplevel.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Future versions of gettext will fail if this header is missing.
|
| |
|
| |
|
|
|
|
| |
(cherry picked from commit 2778a8a85f73dced81acca6ca2d7268572817d78)
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's the potential for a crash in the shutdown path after the
factory is disposed, since we fail to disconnect signal handlers to
the displays / display store at factory dispose time.
This commit changes the g_signal_connect to g_signal_connect_object, to
avoid any potential for crash.
(this is a fix noticed when reading through the source. It's tangentially
related to a discussion on irc for a different bug)
|
| |
|
| |
|
|
|
|
| |
(cherry picked from commit b5df2d64487923196c288843d9e8ff2e89b90e8b)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 99eeae91c1f11997521ad3bc016a7b2d23ec7942 attempted to
support dbus user buses with X sessions, by supposedly importing
DISPLAY and XAUTHORITY into the dbus user bus activation
environment.
It didn't actually work, though, because the spawn_bus function
quits early if the dbus daemon is already running.
This commit fixes the code so that the activation environment is
always updated.
https://bugzilla.gnome.org/show_bug.cgi?id=761568
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many remote services refuse passwordless logins, so administrators may find it
surprising that the login screen over XDMCP doesn't require a password on the
account.
This commit toggles to that default.
Note, this change doesn't really make XDMCP more secure. It is inherently
insecure over an untrusted network, since it's a completely plain text
protocol.
https://bugzilla.gnome.org/show_bug.cgi?id=764669
|
|
|
|
|
|
|
|
| |
Temporarily set this to the VT that the login screen is currently active on so that pam modules that require this
information early can have access to it. Debian/Ubuntu use this to detect if the login is coming from a local tty.
PAM_TTY will get reset to the users VT right before the user session is opened.
https://bugzilla.gnome.org/show_bug.cgi?id=764669
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The login screen user account won't ever have a password or get locked,
so there's no reason to run the system-auth password and account
stacks for the login screen launch environment.
https://bugzilla.gnome.org/show_bug.cgi?id=764472
|
| |
|
|
|
|
| |
Signed-off-by: Trần Ngọc Quân <vnwildman@gmail.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|