DBus on "other" platforms
simon.mcvittie at collabora.co.uk
Mon May 16 11:23:23 UTC 2016
On 13/05/16 21:42, René J.V. Bertin wrote:
> That was rather simple, actually. Since I'm trying all this with
> the MacPorts build I am working with a build directory that has
> a somewhat crazy long path, which apparently shouldn't be used
> for creating sockets. Using the configure option
> --with-test-socket-dir=/tmp solved this.
Right, that's what that option is there for. Let's consider this resolved.
> Now I'm seeing
> %> test/test-dbus-daemon
> /creds: OK
That's not what I asked you to do. Please run it with the --tap option
to see the optional verbose messages that I mentioned, prefixed with "#".
Note that when you are not running it in the special tests environment,
this test will run a copy of the normal dbus-daemon from your $PATH, and
not the one you just compiled; similarly, it'll use your normal
(installed) session.conf, not a local one that hopefully only has
EXTERNAL enabled. If you are testing a special local compile of dbus you
or perhaps more simply
make -C test check-TESTS TESTS=test-dbus-daemon VERBOSE=1
> /processid: **
> ERROR:dbus-daemon.c:548:test_processid: assertion failed (error.name == DBUS_ERROR_UNIX_PROCESS_ID_UNKNOWN): ("org.freedesktop.DBus.Error.InvalidArgs" == "org.freedesktop.DBus.Error.UnixProcessIdUnknown")
> Exit 134
This is getting more in-depth. Could you open a bug report on
for this part, please?
Editing test/dbus-daemon.c to include something like
g_printerr ("%s: %s\n", error.name, error.message);
just before that assertion would probably let you provide more useful
information here. I would prefer that change not to be permanent since
it would make that test unnecessarily "noisy" on platforms where
fetching a process ID legitimately fails.
Collabora Ltd. <http://www.collabora.com/>
More information about the dbus