Previously, we took the default application for a particular mimetype
from the system and copied it into the user's configuration as the
default there.
Instead of doing that we leave the user's default unset, and at time of
use, if the user has no explicitly-set default value, we use the system
default.
This avoids complicated situations where inappropriate applications were
being set as the default in the user's configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=658188
gio-2.0.pc's Libs.private was still using @LIBASYNCNS_LIBADD@, which
was no longer being substituted to anything and so broke "pkg-config
--static". Fix it to be @NETWORK_LIBS@ instead.
https://bugzilla.gnome.org/show_bug.cgi?id=659889
We ignore entries with mountpoint of "swap" and "ignore". Add "none" to
that list, since Debian uses it.
Probably we should move to using our already-existing internal list of
things to ignore, but this patch is more minimally intrusive for now.
https://bugzilla.gnome.org/show_bug.cgi?id=654563
Commit afa82ae805f9c8bb875a3f863a7b4669953f159f introduced a compilation
regression on BSD systems that use the sysctl(3) interface; we need to
declare the buffer len in _g_get_unix_mount_points()
BZ #659528
Otherwise we might collide with an interface called Connection.
https://bugzilla.gnome.org/show_bug.cgi?id=659699
This is for the same reason that GDBusProxy has its properties
prefixed with g-.
Signed-off-by: David Zeuthen <davidz@redhat.com>
In registration_data_export_interface(), the object_path is obtained using:
object_path = g_dbus_object_get_object_path (G_DBUS_OBJECT (data->object));
But when exporting an object uniquely, the object_path is not assigned
to the GDBusObject until after all the interfaces are exported.
Therefore, registration_data_export_interface() is trying to export
the interface on the non-unique object path, which can lead to
run-time errors if an object already exists on that path.
Instead, registration_data_export_interface() should be passed the
object_path explicitly, as is done in
g_dbus_object_manager_server_export_unlocked().
Signed-off-by: David Zeuthen <davidz@redhat.com>
Ensure that the output/target stream in a g_output_stream_splice_async()
operation is marked as closed if G_OUTPUT_STREAM_SPLICE_CLOSE_TARGET is
passed to g_output_stream_splice_async(). This removes the possibility of
local FDs being closed twice because the stream's not marked as closed.
This is implemented by calling g_output_stream_close() from within
g_output_stream_splice_async() instead of calling the stream's close_fn()
directly.
Closes: bgo#659324
(cherry picked from commit fe27bf003764e453cd15cab67e8a99fcda84db1d)
When g_settings_apply() is called on a delayed settings backend and
there is a D-Bus error when communicating with dconf-service, recent
versions of the dconf GSettingsBackend call a function in GLib that
improperly delivered the signal directly instead of using
g_main_context_invoke().
This patch fixes this function to route in the same way as the others so
that the signal is dispatched in the proper GMainContext.
Previously, we were returning an empty buffer for all filenames
where fstat() gives a size of 0. But this is only appropriate
for regular files.
Also improve the documentation around this issue. Based on a
patch by Ryan Lortie.
mmap() fails on zero-sized files, so we previously had a special case to
avoid calling it in that case. Unfortunately, this had the side effect
of causing us to fail to notice that we were attempting to mmap() a
device node.
Modify the special-casing to only apply in the case that we're dealing
with a normal file.
https://bugzilla.gnome.org/show_bug.cgi?id=659212
Otherwise, we could use-after-free the GDBusWorker, if its last-unref
is immediately after _g_dbus_worker_new returns (before the worker thread
does its initial read).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
This member is written in _g_dbus_worker_stop from arbitrary threads, and
read by the worker thread, so it should be accessed atomically.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
