| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
If --uninstall is given then don't give an error if the schema directory
is empty. Instead, erase the gschemas.compiled file, if it exists.
This is the right thing to do in the 'make uninstall' rule, where the
schema directory could very well be left empty as a result.
Modify gsettings.m4 to use this option.
|
|
|
|
| |
handle schema checking, installation, uninstallation, cleaning
|
|
|
|
| |
No semantic changes.
|
|
|
|
| |
change a mention of gschema_compile in the docs
|
|
|
|
| |
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=618839
|
|
|
|
|
|
|
| |
The test was assuming that g_timeout_add() waited for at least the amount of
time given to it before running the function. This is not the case -- the
function can be run as much as 1ms early. Make the lower time bound asserted
in the test more permissive to account for this.
|
|
|
|
| |
Fix trivial typo in GCredentials code
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: David Zeuthen <davidz@redhat.com>
|
| |
|
|
|
|
| |
Signed-off-by: David Zeuthen <davidz@redhat.com>
|
|
|
|
| |
Signed-off-by: David Zeuthen <davidz@redhat.com>
|
|
|
|
|
|
|
| |
- hold a lock while accessing the tree of delayed values
- use weak reference counts with the owner object to avoid doing
g_object_notify on a dead object
- dispatch the "has-unapplied" notify to the proper main context
|
|
|
|
|
|
|
| |
This commit fixes up a few race conditions in the GSettingsBackend, mostly with
respect to change notifications occuring at the same time as the last reference
count on a GSettings is dropped. With GDBus feeding us our incoming signals in
a separate thread, this is something that could easily happen.
|
| |
|
|
|
|
|
|
| |
The thread-default context that was in effect at the time that the
GSettings was created will be used for emitting signals on that
GSettings.
|
|
|
|
|
|
|
|
|
| |
There is currently no way (near as I can tell) to ensure that a message
has been sent when using GDBus. If we exit() before we are sure, then
it is very possible that the message isn't sent at all. This behaviour
was observed when using the GSettings commandline tool with dconf.
A quick and dirty workaround for now.
|
| |
|
|
|
|
|
|
| |
https://defect.opensolaris.org/bz/show_bug.cgi?id=10194
Updated copyright.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
I have added some hints on how to use intltool for translation
of summary and description elements, taken from comments in bug #618523.
|
|
|
|
|
|
|
|
| |
Don't define __USE_GNU, thats a glibc-internal macro, and
don't use SOL_SOCKET when not including sys/socket.h.
Maybe this file should be called glinuxcredentialsmessage.c...
Bug #618730
|
|
|
|
|
| |
It's --schema-file now, not --schema-files.
Bug #616864.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Rename the --schema-files option to --schema-file, since it only
accepts one file at a time. Change the GSETTINGS_CHECK_RULE to
use it that way, too. And also make it work better with !srcdir
builds.
Bugs #616731 and #616864
|
|
|
|
|
|
|
| |
Without this fix, we segfault if the exported object returned an error
on all get_property() calls (in reality, this never happens).
Signed-off-by: David Zeuthen <davidz@redhat.com>
|
|
|
|
|
|
|
|
|
| |
Fix an unintentional double free introduced in commit
4ad4c306c3b80620185cf975b402e17a6174aea9.
This bug manifested itself when trying to complete this
$ gdbus introspect --system --dest <tab>
|
|
|
|
|
|
| |
Use "&s" instead of "s", and free the variant iters after use.
Bug #618663.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From valgrind running gdbus-peer test:
==20513== 32 bytes in 1 blocks are definitely lost in loss record 1 of 15
==20513== at 0x4024E4C: realloc (vg_replace_malloc.c:429)
==20513== by 0x4079BB1: g_realloc (gmem.c:174)
==20513== by 0x4099472: g_string_maybe_expand (gstring.c:396)
==20513== by 0x409A42A: g_string_insert_c (gstring.c:1050)
==20513== by 0x42169AC: g_string_append_c_inline (gstring.h:153)
==20513== by 0x421682C: _my_g_input_stream_read_line_safe (gdbusauth.c:336)
==20513== by 0x421843E: _g_dbus_auth_run_server (gdbusauth.c:1265)
==20513== by 0x4222B94: initable_init (gdbusconnection.c:1783)
==20513== by 0x41CF8D5: g_initable_init (ginitable.c:106)
==20513== by 0x41CFA8D: g_initable_new_valist (ginitable.c:219)
==20513== by 0x41CF920: g_initable_new (ginitable.c:139)
==20513== by 0x4223479: g_dbus_connection_new_sync (gdbusconnection.c:2046)
Bug #618650.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
==6279== 21,615 (4,708 direct, 16,907 indirect) bytes in 169 blocks are
definitely lost in loss record 12 of 13
==6279== at 0x4024D2E: malloc (vg_replace_malloc.c:207)
==6279== by 0x4079A90: g_malloc (gmem.c:135)
==6279== by 0x4079DC8: g_malloc_n (gmem.c:252)
==6279== by 0x4097E66: g_strsplit (gstrfuncs.c:2434)
==6279== by 0x42169A2: g_dbus_address_get_stream_sync
(gdbusaddress.c:875)
Bug #618622.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Free the bus address after creating the singleton.
==26308== 39,736 (10,517 direct, 29,219 indirect) bytes in 388 blocks
are definitely lost in loss record 14 of 15
==26308== at 0x4024D2E: malloc (vg_replace_malloc.c:207)
==26308== by 0x4079A90: g_malloc (gmem.c:135)
==26308== by 0x4079DC8: g_malloc_n (gmem.c:252)
==26308== by 0x4095607: g_strdup (gstrfuncs.c:102)
==26308== by 0x4216B9A: g_dbus_address_get_for_bus_sync
(gdbusaddress.c:961)
==26308== by 0x422A7AE: get_uninitialized_connection
(gdbusconnection.c:5241)
Bug #618622.
|
|
|
|
|
|
| |
The result of read_string() was leaked.
Bug #618615.
|
|
|
|
|
| |
This code leaked the return value of g_variant_get_child_value();
use g_variant_get() instead and free the iter when done.
|
|
|
|
|
|
| |
Also add a test case to catch this.
Signed-off-by: David Zeuthen <davidz@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that we didn't observe padding (neither when reading nor
writing) for empty arrays which (apparently) is needed according to
the D-Bus spec and reference implementation. A simple test case to
provoke this behavior is as follows (notice the lack of 4 bytes worth
of padding at position 0x0064):
Error calling dbus_message_demarshal() on this blob: org.freedesktop.DBus.Error.InvalidArgs: Message is corrupted (Alignment padding not null)
0000: 6c 01 00 01 2e 00 00 00 41 00 00 00 37 00 00 00 l.......A...7...
0010: 08 01 67 00 08 73 61 7b 73 76 7d 61 73 00 00 00 ..g..sa{sv}as...
0020: 01 01 6f 00 08 00 00 00 2f 66 6f 6f 2f 62 61 72 ..o...../foo/bar
0030: 00 00 00 00 00 00 00 00 03 01 73 00 06 00 00 00 ..........s.....
0040: 4d 65 6d 62 65 72 00 00 11 00 00 00 30 31 32 33 Member......0123
0050: 34 35 36 37 38 39 30 31 32 33 34 35 36 00 00 00 4567890123456...
0060: 00 00 00 00 0e 00 00 00 09 00 00 00 53 6f 6d 65 ............Some
0070: 74 68 69 6e 67 00 thing.
The blob was generated from the following GVariant value:
('01234567890123456', @a{sv} {}, ['Something'])
If the blob was encoded using DBusMessageIter, the payload would have been:
0000: 6c 01 00 01 32 00 00 00 41 00 00 00 36 00 00 00 l...2...A...6...
0010: 01 01 6f 00 08 00 00 00 2f 66 6f 6f 2f 62 61 72 ..o...../foo/bar
0020: 00 00 00 00 00 00 00 00 03 01 73 00 06 00 00 00 ..........s.....
0030: 4d 65 6d 62 65 72 00 00 08 01 67 00 08 73 61 7b Member....g..sa{
0040: 73 76 7d 61 73 00 00 00 11 00 00 00 30 31 32 33 sv}as.......0123
0050: 34 35 36 37 38 39 30 31 32 33 34 35 36 00 00 00 4567890123456...
0060: 00 00 00 00 00 00 00 00 0e 00 00 00 09 00 00 00 ................
0070: 53 6f 6d 65 74 68 69 6e 67 00 Something.
** ERROR:gdbus-serialization.c:547:check_serialization: code should not be reached
Aborted
and this is now in the libdbus-1-using serialization test case.
Signed-off-by: David Zeuthen <davidz@redhat.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|