This will let us drop the dbus-python dependency.
The C version does not 100% reproduce all the hash table
and array manipulation of the python version, but the tests
do not rely on it anyway.
This greatly simplifies the test since everything is now in a single
process and possible bugs / quirks in libdbus-1 will not interfere
with the tests. On the other hand, we no longer test interoperability
with libdbus-1. This is somewhat moot, however, since other tests that
involve a message bus (e.g. GTestDBus users which include most of the
GDBus test suite itself) will test this.
Also ensure that we don't pollute existing D-Bus keyrings for the
DBUS_COOKIE_SHA1 authentication method (e.g. files in the
~/.dbus-keyrings directory) by setting the environment variables
G_DBUS_COOKIE_SHA1_KEYRING_DIR and
G_DBUS_COOKIE_SHA1_KEYRING_DIR_IGNORE_PERMISSION.
All in all, this change avoids some thorny issues where the GDBus and
libdbus-1 implementations disagree on whether an item in the D-Bus
keyring is still valid (items have an age etc.). In reality, since the
DBUS_COOKIE_SHA1 authentication method is never used in production,
this is never hit in production. This bug was, however, frequently hit
if you just ran the test suite repeatedly for 15 minutes or so.
Also add TODO items to mention that we currently don't test corner
cases involving
- DBUS_COOKIE_SHA1 timeouts
- libdbus-1 interoperability
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
GValueArray as a whole is deprecated in favor of GArray (with GValue
elements); warnings like "'g_value_array_get_nth' is deprecated: Use
'g_array_index' instead" are confusing because they suggest that the
GArray functions can be used with GValueArrays. Make them say "Use
'GArray' instead" instead.
https://bugzilla.gnome.org/show_bug.cgi?id=690970
This DTD wasn't syntactically correct, and didn't actually
describe keys correctly. This change makes it a bit too lax,
but at least it can be used now.
https://bugzilla.gnome.org/show_bug.cgi?id=690538
This returns a GInputStream corresponding to the stdin on the
commandline that caused this invocation.
The local case works on both UNIX (GUnixInputStream on stdin) and
Windows (GWin32InputStream on GetStdHandle(STD_INPUT_HANDLE)). The
remote case works only on UNIX (by fd passing over D-Bus).
https://bugzilla.gnome.org/show_bug.cgi?id=668210
Rather than overloading --verbose, just skip the tests that aren't
supposed to be run in the parent process (so that if you do run the
toplevel test with --verbose, it doesn't immediately error out).
https://bugzilla.gnome.org/show_bug.cgi?id=679683
If you had two tests "/foo/bar" and "/foo/bar/baz", and ran the test
program with "-p /foo/bar/baz", it would run "/foo/bar" too. Fix that.
And add a test to tests/testing for it.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
g_test_trap_fork() doesn't work on Windows and is potentially flaky on
unix anyway given the fork-but-don't-exec. Replace it with
g_test_trap_subprocess(), which re-spawns the same program with
arguments telling it to run a specific (otherwise-ignored) test case.
Make the existing g_test_trap_fork() unit tests be unix-only (they
never passed on Windows anyway), and add a parallel set of
g_test_trap_subprocess() tests.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
Some compilers assume a literal value is a certain byte-length without
checking the type to which it is being assigned, giving a compile-time
warning: a default of 'long' is a mismatch when assigning to a guint64
when the latter is a 'long long'. Use one of glib's standard macros to
specify the type of the constant to match the variable type.
https://bugzilla.gnome.org/show_bug.cgi?id=688829
1) use "../libtool" rather than "libtool" to avoid problems
with wacky OS X not-actually-libtool
2) Use libtool on the libtool script, not the binary, so that it
actually does anything
3) Don't use "gdb --ex" since it's apparently new-ish/non-portable.
https://bugzilla.gnome.org/show_bug.cgi?id=684723
