It depends on gdbus-sessionbus.c which only builds on unix.

When presented with an array of empty arrays of 8-byte-aligned types,
GDBus would incorrectly apply the 8-byte alignment when reading back.

https://bugzilla.gnome.org/show_bug.cgi?id=673612Signed-off-by: David Zeuthen <davidz@redhat.com>

Excercise more parts of the guessing machinery.
These tests rely on the mime database being present.

With this change,
DBUS_SESSION_BUS_ADDRESS= make check
succeed here.

Nothing wrong with leaving debug spew in the code, but we should
not build it if it is not used.

This reverts commit 3ccc4cf9.

Components using GIO to do window to application matching can
use that field to retrieve potential candidates.

https://bugzilla.gnome.org/show_bug.cgi?id=673659

GDBus heavily relies on idles for some of its cleanup operations,
and not running a mainloop leads to things not getting cleaned
up properly, which in turn leads to test failures, since the
session bus singleton does not get removed.

Make GApplication tests manage their dbus connections.

This program is only used indirectly from gapplication.c in
tests, but that is no reason to let it segfault when it is
run from the commandline without arguments.

It depends on gdbus-sessionbus.c which only builds on unix.

GDBusProxy sets an error on a GSimpleAsyncResult and then returns
without dispatching the result for completion (and leaks the result in
the process).  Fix that.

Also add a testcase.  Unfortunately, adding the testcase uncovered
bug #672248.  We can work around that by reordering the tests.

https://bugzilla.gnome.org/show_bug.cgi?id=672249

https://bugzilla.gnome.org/show_bug.cgi?id=671270

This test made some invalid assumptions that are no longer true.
Disable it until we can figure out a better way.

https://bugzilla.gnome.org/show_bug.cgi?id=667755

Add a test to check that remaining data is read before the close
event is received.

https://bugzilla.gnome.org/show_bug.cgi?id=669810

g_file_read() was returning G_IO_ERROR_IS_DIRECTORY when you tried to
open a directory on unix, but G_IO_ERROR_PERMISSION_DENIED on win32.
Fix that, and add a test to tests/file.c

Pointed out on IRC by Paweł Forysiuk.

https://bugzilla.gnome.org/show_bug.cgi?id=669330

This is useful when using certain D-Bus services where the
PropertiesChanged signal does not include the property value such as
e.g. various systemd mechanisms, see e.g.

 https://bugs.freedesktop.org/show_bug.cgi?id=37632Signed-off-by: David Zeuthen <davidz@redhat.com>

==1265== 84 (8 direct, 76 indirect) bytes in 1 blocks are definitely lost in loss record 793 of 827
==1265==    at 0x4029467: calloc (vg_replace_malloc.c:467)
==1265==    by 0x408479B: standard_calloc (gmem.c:104)
==1265==    by 0x4084846: g_malloc0 (gmem.c:189)
==1265==    by 0x4084B2D: g_malloc0_n (gmem.c:385)
==1265==    by 0x4228A98: g_resource_load (gresource.c:253)
==1265==    by 0x804A56D: test_resource_registred (resources.c:198)

==509== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 828 of 837
==509==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==509==    by 0x4084724: standard_malloc (gmem.c:85)
==509==    by 0x40847C7: g_malloc (gmem.c:159)
==509==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==509==    by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==509==    by 0x405390D: g_bytes_new_take (gbytes.c:122)
==509==    by 0x804A48C: test_resource_data (resources.c:174)

==29204== 11,456 (84 direct, 11,372 indirect) bytes in 1 blocks are definitely lost in loss record 859 of 861
==29204==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204==    by 0x4084724: standard_malloc (gmem.c:85)
==29204==    by 0x40847C7: g_malloc (gmem.c:159)
==29204==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204==    by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204==    by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204==    by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204==    by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204==    by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204==    by 0x417C1DB: g_object_new (gobject.c:1535)
==29204==    by 0x41E5E29: g_converter_input_stream_new (gconverterinputstream.c:204)
==29204==    by 0x4228D38: g_resource_open_stream (gresource.c:363)

==28778== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 842 of 863
==28778==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28778==    by 0x4084724: standard_malloc (gmem.c:85)
==28778==    by 0x40847C7: g_malloc (gmem.c:159)
==28778==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==28778==    by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==28778==    by 0x405390D: g_bytes_new_take (gbytes.c:122)
==28778==    by 0x804C2B1: test_uri_query_info (resources.c:435)

==28318== 38 (12 direct, 26 indirect) bytes in 1 blocks are definitely lost in loss record 613 of 865
==28318==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28318==    by 0x4084724: standard_malloc (gmem.c:85)
==28318==    by 0x40847C7: g_malloc (gmem.c:159)
==28318==    by 0x4084AB4: g_malloc_n (gmem.c:361)
==28318==    by 0x4229599: g_resources_enumerate_children (gresource.c:806)
==28318==    by 0x804B39E: test_resource_registred (resources.c:283)

==27820== 31 bytes in 1 blocks are definitely lost in loss record 587 of 866
==27820==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27820==    by 0x4084724: standard_malloc (gmem.c:85)
==27820==    by 0x40847C7: g_malloc (gmem.c:159)
==27820==    by 0x4084AB4: g_malloc_n (gmem.c:361)
==27820==    by 0x409D6A1: g_strdup (gstrfuncs.c:356)
==27820==    by 0x4069FF7: g_get_current_dir (gfileutils.c:2544)
==27820==    by 0x804BCA7: test_resource_module (resources.c:370)

Rather than misusing g_file_open_tmp(), misuse g_file_new_tmp()
instead. Progress! (Also, gets rid of a compile warning about close()
on win32.)

... instead of just g_assert(), so when the test does fail, one immediately
can see the actual value the variable had.

The glib-compile-resources --generate-dependencies call was failing,
although not stopping the build.

Failed to open file 'test2.gresource.xml': No such file or directory
Failed to open file 'test3.gresource.xml': No such file or directory
Failed to open file 'test4.gresource.xml': No such file or directory
Failed to open file 'test.gresource.xml': No such file or directory

With this we're not longer exporting the constructor headers, which means
we're not tying ourselves to a macro that might need special tweaking on
a compiler-by-compiler basis.

The parser has been moved into Gtk in a modified form and the printer
was never really useful anyway (except for debugging/testing).