The comment implied that even failed initialization would set
is_initialized = TRUE, but this wasn't the case - failed initialization
would only set initialization_error, and it was necessary to check both.
It turns out the documented semantics are nicer than the implemented
semantics, since this lets us use atomic operations, which are also
memory barriers, to avoid needing separate memory barriers or locks
for initialization_error (and other members that are read-only after
construction).
I expect to need more than one atomically-accessed flag to fix thread
safety, so instead of a minimal implementation I've turned is_initialized
into a flags word.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661689
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661992
Reviewed-by: David Zeuthen <davidz@redhat.com>
We didn't previously test anything except the implicit default of TRUE.
Now we test implicit TRUE, explicit TRUE, explicit FALSE, and
disconnecting at the local end (which regressed while fixing Bug #651268).
Also avoid some questionable use of a main context, which fell foul of
Bug #658999 and caused this test to be disabled in master.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100
Bug-NB: NB#287088
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: David Zeuthen <davidz@redhat.com>
(cherry picked from commit be89f052c2f578a812d7bba4bbd02be04a4fdc03)
This was a regression caused by my previous work on GDBusWorker thread-safety
(Bug #651268). The symptom is that if you disconnect a GDBusConnection
locally, the default implementation of GDBusConnection::closed
terminates your process, even though it shouldn't do that for
locally-closed connections; this is because GDBusWorker didn't think a
cancelled read was a local close.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100
Bug-NB: NB#287088
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: David Zeuthen <davidz@redhat.com>
(cherry picked from commit 5e0492da509aad12b93b732c449dae1a016367c1)
GDBusConnection sets the closed flag in the worker thread, then adds an
idle callback (which refs the Connection) to signal this in the main
thread. The tests session_bus_down doesn't spin the mainloop, so the
"closed" signal will always fire if iterating the mainloop later (and
drops the ref when doing so). But _is_closed can return TRUE even before
signalling this, in which case the "closed" signal isn't fired and the
ref isn't dropped, causing the test to fail.
Instead simply always wait for the closed signal, which is a good thing
to check anyway and ensures the ref is closed.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661896
Reviewed-by: Matthias Clasen <mclasen@redhat.com>
I've seen builds fail with
nm-connection.c:119:691: error: declaration of '_GStaticAssertCompileTimeAssertion_119' shadows a previous local [-Werror=shadow]
because several compile-time assertions ended up on the same
line. __COUNTER__ is meant specifically for the purpose of
constructing identifiers, so use it when available.
On OpenBSD translation files are always installed under PREFIX/share/locale,
there is no such thing as PREFIX/lib/locale; according to that, set
DATADIRNAME to "share".
GVDB deals with empty lists by returning NULL for the list instead of a
zero-length (non-NULL) strv. We can work around that in GSettingsSchema
by checking for the NULL case and treating it like a zero-length list.
https://bugzilla.gnome.org/show_bug.cgi?id=660147
If the connection to the bus is lost while a method call is ongoing,
the method call does not get cancelled. Instead it just sits around
until it times out.
This is visible here on XO laptops when stopping the display manager
during shutdown. imsettings starts sending a sync message to give up
its bus name (via g_bus_unown_name()), then systemd terminates the
session bus at approximately the same time. imsettings then hangs for
about 20 seconds before timing out the message.
http://lists.freedesktop.org/archives/dbus/2011-September/014717.html
imsettings behaviour could be improved as described in that thread,
but I think this is a glib bug. I've also come up with the attached
patch which fixes it.
Credits for the bug-fix goes to Daniel Drake <dsd@laptop.org>. The test
case was written by David Zeuthen <zeuthen@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=660637
Signed-off-by: David Zeuthen <davidz@redhat.com>
Since it is valid for a D-Bus interface / service to add new methods,
signals or properties we must NEVER warn about unknown properties or
drop unknown signals or disallow unknown method invocations when we
have an expected interface.
So this means that the expected_interface machinery is only useful for
checking that the service didn't break ABI.
Also update the docs so it is clear exactly what it means to have an
expected interface.
https://bugzilla.gnome.org/show_bug.cgi?id=660886
Signed-off-by: David Zeuthen <davidz@redhat.com>
g_file_make_directory_with_parents() will fail for already
existing directories, unlike g_mkdir_with_parents(), so mention
this clearly in the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=660791
Presumably, the rationale for not storing the endianness is that
GVariant is a recursive type system, and in a sane format, endianness
only needs to be stored once per blob of data (once per D-Bus message,
once per file on disk, etc.).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>
Also include a shorter version in the docs for g_variant_store, with a
pointer to g_variant_get_data.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>
Strings matching /%[a-z]/ are special syntax for gtk-doc.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>
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
