When losing the D-Bus connection, we would write to stdout about it just
before killing ourselves with SIGTERM. We're a library, so we should
probably use stderr instead.
https://bugzilla.gnome.org/show_bug.cgi?id=721324
Part of the purpose of g_settings_get_child() was that it could be used
after you delay() a GSettings object, and then apply() all of the
settings together. In order for that to work, we need to share the
backend.
https://bugzilla.gnome.org/show_bug.cgi?id=720891
The x-content/win32-software type is only recognized if
the autorun.exe file is executable. Since the file is installed
as data, we need to fix up its permissions in an
install-data-hook.
Fix some races introduced in be2c7b83c4
while keeping the property that multiple handlers for the same unix
signal all get dispatched.
Also fix the behaviour of the source checking for pending signals when
it's created. No matter what we do here (clear the pending flag or not)
there is something that can go wrong.
If we clear the flag, we may prevent other sources from being
dispatched. If we don't clear it, we may end up dispatching the same
source twice (if we manage to dispatch it from its own thread before the
GLib worker has a chance to run).
Instead, run the full dispatch procedure when a new source is added. It
actually doesn't matter what thread this runs in since the lock is held.
https://bugzilla.gnome.org/show_bug.cgi?id=711090
The existing tests were accidentally using the same test data
twice. Fix that, and add another set of tests that exercise
the filename collation special cases.
g_time_val_from_iso8601 was attempting to parse strings
having only a date, but failed to actually set the timeval
despite returning TRUE. Since the docs state that the function
only parses strings containing a date and a time, just return
FALSE in this case.
Also remove an incomplete testcase for this behaviour that was
just checking the boolean return value, but not timeval.
