Use the newly added g_settings_schema_list_keys() API instead of
g_settings_list_keys() in order to list keys.
Doing this allows the 'list-keys' command to work without creating a
GSettings object, which is more efficient. It also means that we don't
have to provide a (meaningless and ignored) path when listing keys on
relocatable schemas.
While we're at it, update the 'range' command not to require creation of
a GSettings object, in a similar way.
https://bugzilla.gnome.org/show_bug.cgi?id=740308
The list of keys in a GSettings object depends entirely on the schema,
so it makes sense to expose this API there.
Move the implementation out of gsettings.c and into gsettingsschema.c,
replacing the earlier with a simple call to the new location.
We don't do the same for children because the children can change.
https://bugzilla.gnome.org/show_bug.cgi?id=740308
Cancellation of GPollFileMonitor is now handled correctly (in the sense
that no further signals will follow) but let's be extra paranoid and
disconnect our handler anyway, for good measure.
https://bugzilla.gnome.org/show_bug.cgi?id=739424
GPollFileMonitor emits CHANGES_DONE_HINT after CHANGED signals, but it
doesn't check to ensure that the file monitor wasn't cancelled before it
does that.
If the original signal caused the monitor to be unreffed, cancelled and
destroyed, we would still end up emitting an extra signal on it.
Avoid that by checking first for cancellation.
https://bugzilla.gnome.org/show_bug.cgi?id=739424
Removed all mentions of GLib file name encoding referring to
the environment strings. The env var content has no defined relation
to GLib's notion of filename encoding, or any encoding whatsoever.
It would be wrong to pass all UTF-8 strings through
g_filename_from_utf8() in order to put them into the environment,
for one thing.
https://bugzilla.gnome.org/show_bug.cgi?id=738185
DBus has recently introduced new message flag
DBUS_HEADER_FLAG_ALLOW_INTERACTIVE_AUTHORIZATION, which tells that
caller is willing to wait for unspecified amount of time for the call
to return, as the service may perform interactive authorization (e.g.
using polkit).
https://bugzilla.gnome.org/show_bug.cgi?id=739616
In order to maintain a logical stream of events, we need to make sure we
flush and queued change notifications before responding to any requests
for information from clients.
If we don't do this, it's possible that we emit an 'add' event that was
queued at the time of a 'DescribeAll' call _after_ the reply to that
call (which already contained the description of the new action).
In practice, this is not only logically incorrect, but it can also cause
problems. If a change to action 'state' or 'enabled' occurs after the
DescribeAll but before the signal has been dispatched, it will be
ignored because an 'add' signal is already pending. When that add
signal is sent, it will contain the correct data, but the receiver will
ignore it because it already saw the action in the DescribeAll reply.
https://bugzilla.gnome.org/show_bug.cgi?id=749693
This is a hack for GLocalFileInfo to correctly get icons for directories.
Without this change content type for any W32 directory is NULL
(because there's no registry entry for "inode/directory" by default,
and in any way there's no file extension that means "directory" to put there),
and GLocalFileInfo uses content type to grab icons.
https://bugzilla.gnome.org/show_bug.cgi?id=748727
The code here was returning gtk-directory and similar names as
fallback, with a comment claiming that these are 'builtin gtk'.
But they aren't, anymore, so just return the standard names.
This code used to look at the SCM_CREDENTIALS and ignore every message
not from uid 0. However, when user namespaces are in use this does not
work, as if uid 0 is not mapped you get overflowuid instead. Right now
this means we ignore all messages in such user namespaces and glib
apps hang on startup.
We can't look at pids either, as pid 0 is returned for processes
outside your pid namespace.
Instead the correct approach is to look at the sending sockaddr and
if the port id (nl_pid) is zero, then its from the kernel.
Source:
http://lists.linuxfoundation.org/pipermail/containers/2015-May/036032.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=750203
Instead of just dropping address types that we're not specifically
handling we return a GNativeSocketAddress which is just a dummy
container for the stuct sockaddr.
https://bugzilla.gnome.org/show_bug.cgi?id=750203
GListStore requires that item-type be derived from GObject, so specify
that the type of the item parameters is GObject so the functions can be
used via gobject-introspection.
Add a scope parameter for the callback used during insert_sorted.
Previously, we waited up to 0.5s, but that can fail on slow
architectures like ARM; now we wait up to 60s in 0.1s increments.
Patch originally by Simon McVittie <simon.mcvittie@collabora.co.uk>,
modified by Iain Lane to be called earlier, to catch all testcases in a
particular test.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=724113
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Acked-by: Matthias Clasen <mclasen@redhat.com>
We previously waited 0.25s, which should be enough even on slow machines,
but you never know; but we also now wait in 0.1s increments, so this test
should actually be faster now.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=724113
Acked-by: Matthias Clasen <mclasen@redhat.com>
I searched all files that mention g_test_run, and replaced most
g_print() calls. This avoids interfering with TAP. Exceptions:
* gio/tests/network-monitor: a manual mode that is run by
"./network-monitor --watch" is unaffected
* glib/gtester.c: not a test
* glib/gtestutils.c: not a test
* glib/tests/logging.c: specifically exercising g_print()
* glib/tests/markup-parse.c: a manual mode that is run by
"./markup-parse --cdata-as-text" is unaffected
* glib/tests/testing.c: specifically exercising capture of stdout
in subprocesses
* glib/tests/utils.c: captures a subprocess's stdout
* glib/tests/testglib.c: exercises an assertion failure in g_print()
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This stops it from interfering with structured stdout such as TAP.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This avoids any possibility of interfering with test syntax (such as
TAP) on stdout. TAP specifically does not parse stderr.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When running the nonce-tcp and tcp-anonymous tests in one run
of gdbus-peer, or running one of them twice via command-line options
"-p /gdbus/tcp-anonymous -p /gdbus/tcp-anonymous", the one run second
would sometimes fail to connect with ECONNRESET.
Adding more debug messages revealed that in the successful case,
g_main_loop_run() was executed in the server thread first:
# tcp-anonymous: server thread: listening on tcp:host=localhost,port=53517
# tcp-anonymous: server thread: starting server...
# tcp-anonymous: server thread: creating main loop...
# tcp-anonymous: server thread: running main loop...
# tcp-anonymous: main thread: trying tcp:host=localhost,port=53517...
# tcp-anonymous: main thread: waiting for server thread...
but in the failing case, the main thread attempted to connect
before the call to g_main_loop_run() in the server thread:
# tcp-anonymous: server thread: listening on tcp:host=localhost,port=40659
# tcp-anonymous: server thread: starting server...
# tcp-anonymous: server thread: creating main loop...
# tcp-anonymous: main thread: trying tcp:host=localhost,port=40659...
# tcp-anonymous: server thread: running main loop...
(The log message "creating main loop" was immediately before
create_service_loop(), and "running main loop" was immediately
before g_main_loop_run().)
To ensure that the GDBusServer has a chance to start accepting
connections before the main thread tries to connect to it, do not
tell the main thread about the service_loop immediately, but instead
defer it to an idle.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=749079
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This test originally did not connect to the bus, which meant it was
omitted from commits like 415a8d81 that made sure none of GLib tests
rely on the presence of an existing session bus. (In particular,
Debian autobuilders don't have a session bus.)
When test_double_array() was added, environments like the Debian
autobuilders didn't catch the fact that this test relied on having a
session bus, because it is often skipped in minimal environments
due to its libdbus-1 dependency.
We don't actually need to connect to a dbus-daemon here: it's enough
to convert the message from GVariant to D-Bus serialization, and
back into an in-memory representation through libdbus. That's what
check_serialization() does, and I've verified that when I re-introduce
bug #732754 by reverting commits 627b49b and 2268628 locally, this
test still fails.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=744895
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
The changed variable was previously uninitialised in the path where the
rate limit was actually changed. This could result in the
GObject::notify signal not getting emitted.
Spotted by Coverity.
CID: #1296516https://bugzilla.gnome.org/show_bug.cgi?id=748834
The third parameter of the thumnail_verify() function had been updated to
const GLocalFileStat, so update the thumbnail-verification test likewise
so that the test works properly on all supported platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=711547
Always run the full algorithm for a given mime type before considering
fallback types.
This includes considering installed applications capable of handling a
particular mimetype, even if such an app is not explicitly marked as
default, and there is a default app for a less-specific type.
Specifically, this often helps with cases of installing apps that can
handle a particular subtype of text/plain. We want to take those apps
in preference to a generic text editor, even if that editor is listed as
the default for text/plain and there is no default listed for the more
specific type.
Because of the more holistic approach taken by the algorithm, it is now
more complicated, but it also means that we can do more work while
holding the lock. In turn, that lets us avoid duplicating some strings,
which is nice.
https://bugzilla.gnome.org/show_bug.cgi?id=744282
If g_dbus_message_to_blob() fails at all, it will leak its mbuf. Spotted
by running the gdbus-serialization test under Valgrind — so there is a
justification for leak-free tests after all!
In path_rule_matches(), the given paths may be of 0-length. Do not
access memory before the array in those case. This is for example
triggered by:
test_match_rule (con, G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH, "/", "", FALSE);
in test_connection_signal_match_rules().
This bug was found thanks to GCC AddressSanitizer.
https://bugzilla.gnome.org/show_bug.cgi?id=745745
Passing an nonsense string for the --dest argument can lead
to a segfault of gdbus. Thats not nice, so use our existing
validation function for bus names here.
https://bugzilla.gnome.org/show_bug.cgi?id=747541
Make sure error handling on repeated <summary> and <description> is
being done properly, not resulting in glib-compile-schemas throwing a
critical.
https://bugzilla.gnome.org/show_bug.cgi?id=747542
Fix a couple of issues in error handling in glib-compile-schemas.
The first problem is that, in case of repeated <summary> or
<description> tags we were still allocating a GString which was never
being freed (due to the throwing of the error resulting in immediate
termination of the parse).
The second problem is that if the repeated <summary> tag also had
attributes, we would attempt to set the GError twice.
https://bugzilla.gnome.org/show_bug.cgi?id=747542
Bug 747209 introduced an error when multiple <summary> or <description>
tags are found for a single key in a GSettings schema. This check
should have been present from the start, but it was left out because the
schema compiler doesn't include these items in the cache file. Even
still -- part of the schema compiler's job is validation, and it should
be enforcing proper syntax here.
Repeated <summary> and <description> tags are a semi-common problem when
intltool has been misconfigured in the build system of a package, but
it's possible to imagine mistakes being made by hand as well.
The idea is that these problems would be caught during the build of a
package and maintainers would be forced to fix their build systems.
An unintended side-effect of this change, however, is that the schema
compiler started ignoring already-installed schemas that contained these
problems, when rebuilding the cache. This means that the installation
of _any_ application would cause the regeneration of the entire cache,
with these already-installed applications being excluded. Without the
schema in the cache, the application would crash on next startup.
The validation check in the gsettings m4 macro passes --strict to the
compiler, which is not used when rebuilding the cache after
installation. Pass this flag down into the parser and only throw the
error in case --strict was given. This will result in the (desired)
build failure without also causing already-installed apps to stop
functioning.
This means that we will not get even a warning about the invalid schema
file in the already-installed case, but that's fine. There is no sense
spamming the user with these messages when they are already quite fatal
for the developer at build time.
https://bugzilla.gnome.org/show_bug.cgi?id=747472
Commit f10b655 removed the inclusion of gasyncresult.h from gdbusproxy.c,
but gdbusproxy.c uses g_async_result_get_source_object(), which caused a
build warning/error. Fix that.
