In shell-like pseudocode, the desired result is:
if $use_subdir
dir = $tmpdir/dbus_nonce-$random
path = $dir/nonce
mkdir $dir
write file at $path
else
dir = $user_owned_place
path = $dir/dbus_nonce-$random
write file at $path
However, /nonce was accidentally appended to $dir instead of $path,
resulting in an attempt to mkdir /tmp/dbus_nonce-XXXX/nonce when
dbus_nonce-XXXX hadn't been created yet.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34569
Tested-by: David Zeuthen <davidz@redhat.com>
Reviewed-by: David Zeuthen <davidz@redhat.com>
The org.freedesktop.DBus.ObjectManager provides a standardized and
efficient way of keeping one or more tree of objects synchronized
between one server and several clients.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34869
Signed-off-by: David Zeuthen <davidz@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
I'm deliberately using a hypothetical API from example.com, rather
than a real API, to avoid perpetuating these over-simplifications any
further than they've spread already:
- "namespaces start with org.freedesktop"
- "namespaces start with org"
- "interfaces are defined by their sole implementation"
- "services have one object implementing one interface"
- "interfaces always behave like classes"
- "interfaces are always noun phrases"
- "there is a freedesktop.org D-Bus API for screensavers"
A coworker was just tripped up by `dbus-monitor --session --system` only
monitoring the system bus. This patch would have saved him reproducing a
tricky bug several times!
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=26548
Reviewed-by: Colin Walters <walters@verbum.org>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Newer systemd-based systems support a global machine ID with the same
metrics as the D-Bus machine ID, but more powerful semantics (for
example on ro media) in /etc/machine-id.
If the D-Bus machine ID cannot be read, fall back to the systemd machine
ID.
This is a first step towards allowing D-Bus to be started up during
early boot where /var is not available.
[plus a whitespace fix -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35228
This is necessary to run the regression tests under valgrind (if
telling it to output to a dedicated fd), gdb, fakeroot etc.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35173
Reviewed-by: Colin Walters <walters@verbum.org>
"Private libraries are libraries which are not exposed through your
library, but are needed in the case of static linking" -- pkg-config(1)
Reviewed-by: Colin Walters <walters@verbum.org>
Also use AC_LINK_IFELSE rather than reinventing it as a shell function.
This was the last user of ld_supports_flag, so, delete it.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33466
Reviewed-by: Colin Walters <walters@verbum.org>
It's a minor security benefit, but not automatically beneficial (it
enables ASLR, but breaks prelinking, some buggy toolchains, and some gdb
versions). Distributions who know their infrastructure works well can
enable it just as easily via
./configure CFLAGS="-fPIE" LDFLAGS="-pie"
without extra support from us, and that's a generic solution applicable to
many packages.
Similarly, don't force libdbus and libdbus-internal to be PIC: libtool
knows better than we do whether that's necessary/beneficial on a
particular platform.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=16621
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27215
Bug-NB: NB#171940
Reviewed-by: Colin Walters <walters@verbum.org>
Also remove some pointless indirection (extra_tests etc.), don't install
the unused directory $(libexecdir)/dbus-1 (we actually install the
launch helper directly into $(libexecdir)), and allow dbus_daemondir to be
set on Windows rather than forcing dbus-daemon to be installed to
$(bindir) there.
dbus_daemon_execdir has to contain "exec" so that the dbus-daemon will be
installed by "make install-exec" and not "make install-data".
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=14512
Reviewed-by: Colin Walters <walters@verbum.org>
It turns out that rsync --chmod means "pretend the source files had
already had this chmod operation applied to them", and not "chmod the
destination files" like you'd expect.
As a result, the -p (--perms) option is also needed, so that rsync will
"preserve" the modified permissions. Otherwise, the docs will not be
group-writeable as intended, and only the person who made the previous
upload will be able to upload them next time.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=36130
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
