eavesdropping as a match rule key introduced in DBus 1.5.6, and the
privous implementation doesn't keep backwards compatibility with older
dbus-daemon.
And the reference dbus-daemon implementation just fail if unknwon key
found in match rule, this is undefined hehavior in DBus Sepcification.
Also there is a feature request for change this hehavior to
"ignore unknown key in match rule", See
https://bugs.freedesktop.org/show_bug.cgi?id=66114
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66107
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
--peer is a direct substitute for --address.
With --bus dbus-send registers on bus given by ADDRESS, thus allowing
messages to be sent to the bus.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48816
[adjusted to apply to current master -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There are two ways to find the dbus-daemon for testing. The first one is
defined as string at compile stage and the second one is export it from
test environment.
The first way has limitation that after defined, it's static string, so
it's impossible to run installable check. So let's unify to the second
way.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37849
[added missing "}" -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
--peer is a direct substitute for --address.
With --bus dbus-send registers on bus given by ADDRESS, thus allowing
messages to be sent to the bus.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48816
[adjusted to apply to current master -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Currently, DBus Specification only consists of four message types, so to
monitor all the types of message, no need to match all of them but just
left it empty is OK.
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66107
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There are two build failure on NetBSD 6.1.1 with gcc 4.5.3, the first
one is char to int, warning treated as error. The second one is a mismatch
between format string and arguments.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69842
[adjusted commit message -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Fix an incorrect sizeof which leads to allocation of more memory than
actually needed.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69329
[elide redundant "* sizeof (char)" which is 1 by definition -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Fix an incorrect sizeof which leads to allocation of more memory than
actually needed.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69329
[elide redundant "* sizeof (char)" which is 1 by definition -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When do autolaunch testing, libdbus will try to start dbus-launch in
installed direcotry, if fail then fall back to dbus-launch in $PATH.
dbus-launch does a relative better thing to start dbus-daemon in build
directory, however, in most of case, the build $prefix is different from
the real prefix where dbus-daemon installed. So dbus-daemon will fail to
start due to can't find its config file. And then dbus-launch will fall
back to finally the installed dbus-daemon.
This patch fix this behavior and will start dbus-launch and dbus-daemon
in build directory in test environment.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37849
In a previous patch, it check SIGHUP for windows, however, in fact there
is dbus-launch-win.c supposed to be used on windows. So just use SIGHUP
unconditionally.
Also free memory on OOM, although this doesn't make much sense since
this is a oneshort program, rather than a daemon.
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
[fixed whitespace -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66068
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
DBUS_SESSION_BUS_PID is not mandatory to set, but we should unset it
if present, since it points to a different session's bus. Likewise for
DBUS_SESSION_BUS_WINDOWID.
Similarly, if DBUS_STARTER_BUS_TYPE and DBUS_STARTER_ADDRESS
are set (as they would be under GNOME Terminal 3.8, see
<https://bugs.freedesktop.org/show_bug.cgi?id=63119>) then they
are likely to point to a different session's bus.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39196
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
In Linux envrionment, signal.h included by sys/wait.h, however, this
isn't the case in FreeBSD. So explicit include it to fix build failure.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66197
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This commit does several more strictly check for dbus-send as its usage
suggested.
* now --address is an invalid option but --address=, this just like the
others, say --reply-timeout=, --dest=, --type=
* --print-reply= only take an optional argument "=literal"
* --print-reply= will cause error with missing MSEC and invalid MSEC
will cause invalid value error
* --dest= will cause error with missing a NAME and also call
dbus_validate_bus_name to verify the NAME
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65424
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
It turns out that if you don't second-guess the system by catching
SIGINT, the right things happen: it's received by every program in the
foreground process group, including dbus-run-session and dbus-daemon.
Neither of those catch SIGINT (unlike dbus-launch) so they'll exit
gracefully without the wrapper script needing to do anything special.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39196
Reviewed-by: Colin Walters <walters@verbum.org>
From the department of "if it isn't tested, it doesn't work". I tried
compiling dbus without an assortment of optional features:
in_builddir ~/build/dbus/legacy ${MR_REPO}/configure \
--enable-developer --enable-maintainer-mode --enable-tests \
dbus_cv_sync_sub_and_fetch=no \
--disable-selinux \
--disable-inotify \
--disable-dnotify \
--disable-epoll \
--disable-kqueue \
--disable-launchd \
--disable-systemd \
--disable-libaudit \
--without-valgrind \
--disable-x11-autolaunch \
&& ...
and it resulted in -Wunused warnings.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=64362
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
...except for CheckForAbstractSockets.c, which runs before config.h is
generated, and sd-daemon.c, which is externally-maintained.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59971
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
If dbus is installed in a path, which contains a space, dbus-launch will
not launch the daemon. That is so, because a command line is built from
just the path to the daemon and a parameter. The path has to be
surrounded with quotes. This can be done unconditionally, because the
quotes do not cause any trouble even if they are not needed.
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=49450
Since Automake 1.11.4, an empty localstatelib_DATA variable will not
create $(localstatelibdir) as a side-effect.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51406
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Lennart Poettering <lennart@poettering.net>
When targeting Windows, linking against the static library requires
special effort to turn off DLL import/export processing. We normally
link some things against the dynamic library, but if we're not building
that, we'll have to link everything statically.
Based on patches from 'william' on fd.o #46367.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33973
Tested-by: René Berber <Rene.Berber gmail com>
This is more suitable for distributions' Xsession scripts: it verifies
that X is already available, and so never results in an attempt to poll
stdin.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197
dbus-launch --exit-with-session attempts to scope the session length
to various things:
- if DISPLAY points to an X server, exit when the X session ends
- if stdin is a terminal, exit when end-of-file is reached
- if both are true, exit when one of them happens, whichever is first
- if neither is true, fail
These are not particularly useful semantics: if the session is scoped to
the X session, then the terminal from which dbus-launch was launched
is irrelevant. This also causes practical problems when dbus-launch
consumes characters from the terminal from which it happens to have
been launched (some display managers, like slim and nodm, run users' X
sessions with stdin pointing to the terminal from which the init daemon
happens to have started the display manager during boot, usually tty1
on Linux).
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197
* dbus-send, dbus-uuidgen only need to link libdbus; libtool knows what
extra libraries libdbus depends on
* dbus-monitor uses a Winsock header (on Windows) so it needs
NETWORK_libs,but still doesn't need threads
* dbus-launch needs X (on Unix) but doesn't directly need threads or
networking
