At previous, argv[0] is the full-qualified path of program, however, if
start dbus-launch failed, it will fall back to find one from $PATH,
while keep the argv[0] as the full-qualified path. So we'll get
misleading info from /proc or ps(1) about dbus-launch process.
One simple solution is just hard-code argv[0] to dbus-launch.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69716
Reviewed-by: Simon McVittie
It's least confusing if the two files have the same contents. systemd
already knows how to pick up our /var/lib/dbus/machine-id if it exists
and /etc/machine-id doesn't, but the converse is not currently true.
We should make it true, so that it doesn't matter what order
systemd-machine-id-setup and "dbus-uuidgen --ensure" were
invoked in.
In Debian, systemd currently Recommends dbus, so "dbus-uuidgen --ensure"
will *usually* - but not always! - run first, and the two files will
match. However, if you install systemd without dbus, and then install
dbus later, there will be a mismatch. With this change, it doesn't
matter which one is installed first: whichever one happens to come
first, it will generate the machine ID, and then the other one will
copy it.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77941
Reviewed-by: Lennart Poettering
xmlto is a shell script, it needs to be fed MSYSsy filenames.
This patch adds a cygpath invocation for filename conversion (autotools do
that automatically, for CMake you have to spell it out). Cygwpath is available
in MSYS2 (and Cygwin, obviously).
When cygpath is not available, use MSYS-specific pwd extension to get W32 path.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75860
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Leaving Nagle's algorithm enabled on the TCP transport leads to some
really long latencies (at least, during the first several messages).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75544
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This means we can drop our convenience copy of sd-daemon.[ch]. We're
checking for libsd-daemon anyway, to support journald and logind
integration.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71818
Reviewed-by: Lennart Poettering <lennart@poettering.net>
Autotools uses a versioned shared library name derived from libtool.
This patch adds a versioned shared library name to cmake builds for all
supported platforms. Binary compatibility for clients build against older
cmake generated binary packages of dbus is provided; on unix like os
with symbolic links and on Windows with a copy of the shared library.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74117
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[Add its source file to SOURCES: this test was previously relying on the
Automake feature that the default value of foo_bar_SOURCES is foo-bar.c. -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73495
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The algorithm to collapse a subsidiary config file's data into the
master data structure forgot to examine this flag.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73475
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
In general, I think developers running the tests would expect
them to terminate rather than hanging. Developers who want to debug
such an abort by attaching a debugger to a live process can still set
DBUS_BLOCK_ON_ABORT in the environment.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41252
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The new macros add_test_executables and add helper_executables provides a
platform independent way for specifing dbus test and service applications.
On native Windows and Linux/UNIX systems the test applications are
directly runable.
When cross compiling for Windows on Linux test applications could be
executed on the Linux host system with the help of wine and activated
binfmt_misc support for wine.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41252
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
It's easier to automate these tests if they launch their own
dbus-daemon, but easier to debug them if they don't: you can launch
a dbus-daemon separately, under gdb. However, tests that need a
specially-configured dbus-daemon will have to be skipped.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>