- May 15, 2018
-
-
Iain Lane authored
The GDBusProxies hold a strong reference to the connection themselves, so maintaining separate weak references is unnecessary. This commit drops those extraneous weak references. https://bugzilla.gnome.org/show_bug.cgi?id=795940
-
Marco Trevisan authored
At the moment we call gdm_client_open_connection and when it finishes, assume client->priv->connection is implicitly initialized. This commit makes the operation more explicit by changing gdm_client_open_connection to gdm_client_get_connection and returning the GDBusConnection object directly, instead of returning a boolean. https://bugzilla.gnome.org/show_bug.cgi?id=795940
-
Ray Strode authored
At the moment we add a weakref on each proxy to the connection object. For the _sync variant functions, When the weakref fires, they call g_clear_object, clearing the connection, even if other proxies still have a reference. This commit changes that weak ref code to use g_object_unref instead. https://bugzilla.gnome.org/show_bug.cgi?id=795940
-
Ray Strode authored
Right now we keep the manager proxy alive long after we need it. It doesn't get cleared until one of the other proxies go away. That is not only unnecessary but illogical and confusing. This commit changes the manager proxy to be transient—only alive long enough to get what we need from it. https://bugzilla.gnome.org/show_bug.cgi?id=795940
-
Ray Strode authored
The manager fetching code in GdmClient treats its task return value as boolean, but it's actually a pointer (the manager) This commit corrects the confusion. https://bugzilla.gnome.org/show_bug.cgi?id=795940
-
Ray Strode authored
Right now libgdm tries to handle multiple simultaneous open calls at the same time by serializing the requests and giving them all the same connection. It's broken, though. - The pending_opens list is never populated, so we end up just doing multiple simultaneous open operations at a time anyway. - The finish code ends up calling g_task_return_error (task, NULL) instead of g_task_return_pointer in the non-error case. Since the feature doesn't work, drop it for now. https://bugzilla.gnome.org/show_bug.cgi?id=795940
-
- May 14, 2018
-
-
Marco Trevisan authored
At the moment we fail to nullify GdmClient's connection to GDM when the connection is disposed. This commit adds a weak pointer to correct that mistake. https://bugzilla.gnome.org/show_bug.cgi?id=795940
-
Marco Trevisan authored
If an async task tries to reuse an open connection, it erroneously explicitly unrefs it. That is incorrect, because there are weak references in use to handle disposing the connection when its no longer in use. This commit makes sure the local connection object in open_connection is nullified so the connection doesn't get autofree'd. https://bugzilla.gnome.org/show_bug.cgi?id=795940
-
- May 07, 2018
-
-
Marco Trevisan authored
If launching gdm from special environments (as jhbuild) these should be forwarded to the children greeter and launched apps too. https://bugzilla.gnome.org/show_bug.cgi?id=795886
-
Marco Trevisan authored
There's no need to add a different code path for this global env. https://bugzilla.gnome.org/show_bug.cgi?id=795886
-
Marco Trevisan authored
As per better readability. https://bugzilla.gnome.org/show_bug.cgi?id=795886
-
- Apr 24, 2018
-
-
Yetoo1 authored
When using unknown command line options with the GDM daemon, the program hangs until explicitly getting killed. This commit addresses that bug by dropping an unnecessary call to g_option_context_set_ignore_unknown_options, so GOptionContext will now give an error when encountering unknown options. https://bugzilla.gnome.org/show_bug.cgi?id=795494
-
- Apr 10, 2018
-
-
Yifan J authored
gdm is responsible to kill plymouth by spawning the "plymouth quit" subprocesses in gdm-manager.c. The current code pathes of quiting plymouth can never be reached when xdmcp is the only connection allowed. Consequently in the case of !show_local_greeter && xdmcp_enabled the plymouth-quit-wait.service will never quit and the login prompt will not popup without manual interference. This issue could be more obviously observed when a downstream like openSUSE which allows a customized sysconfig to switch the corresponding two options on a headless server (s390), where the setup is usually: DISPLAYMANAGER_REMOTE_ACCESS="yes" DISPLAYMANAGER_STARTS_XSERVER="no" The proposed patch handles this edge case by quit plymouth immediately when the condition is detected. https://bugzilla.gnome.org/show_bug.cgi?id=795120
-
- Mar 26, 2018
-
-
(cherry picked from commit 6b5c3691)
-
- Mar 16, 2018
-
-
(cherry picked from commit f2645e89)
-
- Mar 13, 2018
-
-
Ray Strode authored
-
Ray Strode authored
-
- Mar 12, 2018
-
-
- Mar 07, 2018
-
-
Ask Hjorth Larsen authored
-
Ray Strode authored
-
Ray Strode authored
-
A S Alam authored
-
- Mar 06, 2018
-
-
- Mar 03, 2018
-
-
- Mar 02, 2018
-
-
- Feb 28, 2018
-
-
Aurimas Černius authored
-
- Feb 27, 2018
-
-
Trần Ngọc Quân authored
Signed-off-by: Trần Ngọc Quân <vnwildman@gmail.com>
-
- Feb 26, 2018
-
-
Florian Müllner authored
The gdm_available_sessions_map hash table is set up with a value-free function that frees the struct itself, but not its contents. Of course elements are never removed from the map, so this fix doesn't matter in practice. https://bugzilla.gnome.org/show_bug.cgi?id=793855
-
Administrator authored
(cherry picked from commit f7ae5b62)
-
-
- Feb 25, 2018
-
-
- Feb 24, 2018
-
-
Rūdolfs Mazurs authored
-
-
-
- Feb 23, 2018
-
-
Piotr Drąg authored
-
- Feb 22, 2018
-
-
- Feb 21, 2018
-
-
- Feb 20, 2018
-
-
Ray Strode authored
-