Instead of using $DBUS_USE_TEST_BINARY to control whether to use the
hard-coded test binary TEST_BUS_LAUNCH_BINARY, we can just use
$DBUS_TEST_DBUS_LAUNCH to control what we launch directly, as we
were already doing for $DBUS_TEST_DAEMON.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Instead of using $DBUS_USE_TEST_BINARY to control whether to use the
hard-coded test binary TEST_BUS_LAUNCH_BINARY, we can just use
$DBUS_TEST_DBUS_LAUNCH to control what we launch directly, as we
were already doing for $DBUS_TEST_DAEMON.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This fixes signedness mismatch warnings on platforms where socklen_t
is unsigned, notably Linux (where it's an unsigned int).
We still use int for the fallback case where the platform does not
define socklen_t, because that was the traditional (pre-POSIX) type:
for details see NOTES in Linux accept(2),
<http://manpages.debian.org/cgi-bin/man.cgi?query=accept&sektion=2>.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93069
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The idea is that .travis.yml is specific to Travis-CI, but most of the
actual work is done in tools/ci-build.sh, which should be reasonably
CI-platform-agnostic (it currently assumes that build-dependendencies are
preinstalled, that the "native" platform we're building on is GNU/Linux
or something very close, and that "mingw" means mingw-w64 as packaged
in Debian and Ubuntu).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The warnings are fixed by adding functions to dbus string name
space returning unsigned char pointer, which avoids the need to
use casts.
Bug: https://bugs.freedesktop.org/attachment.cgi?id=93069
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Use the standard C99 PRI*64 macros instead of checking for specific GNU
libc version. We also specifically check for windows which does not have
proper C99 support.
This fixes printing of int64 on non-GNU 32 bit systems (like musl libc).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92043
Reviewed-by: Thiago Macieira <thiago@kde.org>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[smcv: fix extra % in the Windows fallbacks; include <inttypes.h> where needed]
A normal DBusConnection will automatically reply to o.fd.Peer
messages such as Ping. We don't want this: if we are using
traditional eavesdropping with an older dbus-daemon, we'll
confuse everyone else by replying to messages that weren't
intended for us. If we are using the new Monitoring
interface (since 1.9.12), the same still applies, but in
addition, the dbus-daemon will disconnect us for not being
a well-behaved monitor.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90952
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Previously, this would always succeed, but might use
weak random numbers in rare failure cases. I don't think
these UUIDs are security-sensitive, but if they're generated
by a PRNG as weak as rand() (<= 32 bits of entropy), we
certainly can't claim that they're universally unique.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
[smcv: document @error]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
unistd.h and sleep() are normally Unix-specific, although mingw also provides them.
The Windows C runtime documents _environ as its equivalent of Unix environ.
https://bugs.freedesktop.org/show_bug.cgi?id=90089
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
We close() the fd after we have printed it, but close() isn't
standard functionality on Windows. Unix FD-passing is never going
to work on non-Unix platforms anyway.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89428
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
gettimeofday is implicitly declared (i.e. not in our #include'd header
files) when cross-compiling for on Windows. Now that fd.o#83115
has been fixed, using _dbus functions is not a problem.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89428
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88896
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[smcv: rebase onto differently indented version of previous commit]
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Use cross platform function _dbus_get_real_time() for fetching current time.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88896
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[smcv: use %ld to avoid needing casts; reinstate printing the timestamp;
libdbus-1 is sufficient now that fd.o#83115 is fixed; print timestamp for
non-literal dbus-send replies too]
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This provides backwards-compatible autolaunching behaviour, as long
as dbus-launch inherits the XDG_RUNTIME_DIR (which it presumably did
if it's going to work at all, since it must also have inherited the
DISPLAY). In particular, we go through the motions of starting the
dbus-daemon, so that we can start the "babysitter" process that will
maintain the X11 window to store the bus address.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61301
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
[smcv: decorate _dbus_lookup_user_bus with DBUS_PRIVATE_EXPORT so we
can still call it after fixing fd.o#83115; update cmake to match Autotools]
As a side benefit, this means that dbus-launch now understands
/etc/machine-id and not just /var/lib/dbus/machine-id.
Since machine_uuid comes out of libdbus allocated with dbus_malloc,
to avoid having to copy it from malloc-allocated to
dbus_malloc-allocated storage, it makes sense to change it to be
consistently dbus_malloc-allocated (particularly now that Bug #83115
has made use of internal symbols relatively painless). However, I'm
deliberately not changing the allocation model of any other strings
in dbus-launch right now; that's a larger yak-shaving exercise.
If OS builders (distributions) have chosen to use the per-user bus,
this provides two possible modes of operation for compatibility with
existing X session startup hooks.
A legacy-free system can just upload DISPLAY, XAUTHORITY and possibly
DBUS_SESSION_BUS_ADDRESS into dbus-daemon's and systemd's activation
environments, similar to
http://cgit.freedesktop.org/systemd/systemd/tree/xorg/50-systemd-user.sh
installed by systemd (but unlike systemctl,
dbus-update-activation-environment works for traditional
D-Bus-activated services, not just for systemd services).
A system where compatibility is required for environment variables
exported by snippets in /etc/X11/xinit/xinitrc.d (in Red Hat derivatives,
Gentoo, etc.) or /etc/X11/Xsession.d (Debian derivatives) can upload
the entire environment of the X session, minus some selected environment
variables which are specific to a login session (notably XDG_SESSION_ID).
In Debian, I plan to put the former in a new dbus-user-session package
that enables a user-session-centric mode of operation for D-Bus,
and the latter in the existing dbus-x11 package, with the intention that
dbus-x11 eventually becomes a tool for change-averse setups or goes
away entirely.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61301
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
- change "ref serial" to "in_reply_to" (avoiding whitespace for easy
visual parsing)
- prefix with # to clarify that these are not part of the data
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89165
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
dbus-send could already pretty-print bytestrings that do not have
\0 termination, but those are awkward to work with (they need copying),
so they are now discouraged. Teach it to print bytestrings that
do have \0 termination as well.
In the process, rewrite this part of the message parser
to use dbus_message_iter_get_fixed_array(), which is the Right way
to get arrays of numbers out of a message.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89109
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Move the dbus_connection_add_filter() call further up as a precaution,
because it isn't safe for a monitor to not have a filter that
swallows all messages.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46787
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This is installed by default, but easy to filter out for embedded systems
or whatever.
Based on earlier work by Simon McVittie and Will Thompson
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34140
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
