Since we're heading for a 1.14.x branch (dbus#350), also draft the
summary of what has changed since 1.12.x.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We've had a request for a 1.14.x stable-branch, but the Containers
interface is only partially implemented, not yet described in the
D-Bus Specification, and not ready to be part of our API guarantees.
Signed-off-by: Simon McVittie <smcv@collabora.com>
dbus-run-session starts a dbus-daemon before the client application.
We must avoid letting the application try to connect before the
dbus-daemon's DBusServer is listening for connections.
In the Unix implementation, we already achieved this via the
--print-address option. If the client tried to connect too soon,
the server would not yet be listening and the client would fail.
In the Windows implementation, we communicate the bus address to
the client application as an autolaunch: address, so if the client
tried to connect too soon, it would autolaunch a new dbus-daemon
instead of using the one that it was intended to use.
We can avoid this by using a new option to pass in a Windows event
object, which will be set when the server has started and is ready
to process connections.
Fixes#297
With this parameter, docbook will generate the same id's when generating the
same docs. This is helpful to get bit-by-bit 'reproducible' output, which
makes auditing the package easier.
Tested both the cmake output and the automake output
This had two issues that could damage interoperability.
First, the spec wording suggested that any cookie that had not been
deleted was suitable for use in authentication. However, this introduces
a race condition, which is called out in comments in both the reference
implementation and GDBus: the newest cookie might be less old than the
arbitrary lifetime when authentication *begins*, but older than the
lifetime at the time authentication *ends*. As a result, we need a grace
period during which an old cookie will still be accepted, but a newer
cookie exists and will be used for new authentication operations.
Second, the spec wording implied that the arbitrary timeouts were
completely up to the implementor. However, GLib bug
https://gitlab.gnome.org/GNOME/glib/-/issues/2164 indicates that they
need to be reasonably compatible: in particular, GDBus servers
historically didn't allocate new cookies until 10 minutes had passed,
but libdbus clients would decline to use a cookie older than 5 minutes,
causing authentication to fail if the gdbus-server test-case (in which
GDBus and libdbus clients connect to a GDBus server) happened to take
longer than 5 minutes to run.
While I'm here, also be consistent about calling the secrets "cookies"
(consistent with the name of the mechanism) rather than "keys" (which
is what they are called in libdbus' dbus-keyring.c).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Qt help files are used by Qt Creator and KDevelop, for example, to support
the development of Qt-based applications and libraries.
Generating api documentation in Qt help format is controlled by two
user specific options named --enable-qt-help and --with-qchdir (autotools)
and -DENABLE_QT_HELP and -DINSTALL_QCH_DIR (cmake).
Spotted by Mubin. This documentation relates to the code in
add_bus_environment() in bus/activation.c.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #275
Clients listening for a signal can match against the 'sender', expecting
it to come from a connection with a specific name. With this change,
dbus-send can send signals to them.
This adds a description of send_destination_prefix to the dbus-daemon manual.
Signed-off-by: Adrian Szyndela <adrian.s@samsung.com>
Change-Id: I46e6fa54ee34095c3ac83ec2c06cb91cf5669c7f
CI builds intermittently fail with
error: Could not create output directory /.../doc/api/xml
or
error: Could not create output directory /.../doc/api/man
Fixes: https://gitlab.freedesktop.org/dbus/dbus/issues/266
Signed-off-by: Simon McVittie <smcv@collabora.com>
