We're not going to replace deprecated functions here, similar to commit
88e0ccb2 in the dbus-1.10 branch.
Signed-off-by: Simon McVittie <smcv@collabora.com>
That's what is checked for by LT_LANG([Windows Resource]) further
up, and is what we now use during the build. Its value is typically
i686-w64-mingw32-windres.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This is nicer for cross-compiling, because AC_RUN_IFELSE can't work
there. In practice abstract sockets are supported on Linux since
2.2 (so, all relevant versions), and on no other platform; so it
seems futile to keep this complexity.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34905
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This was presumably once used in constructs like
"unix:" DBUS_PATH_OR_ABSTRACT "=/var/run/dbus/foo", but git grep says
there are no remaining uses, so it can go.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34905
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
LSB-style (SysV-style) init scripts have not historically been
portable between distributions, as evidenced by the presence of both
"Red Hat" and "Slackware" init scripts in dbus. Many distributors
prefer to maintain them downstream, as is done in Debian (and its
derivatives) and in Slackware, so that the init script can follow
OS conventions (for example regarding boot messages) and make use
of OS-provided facilities (for example, the Debian init script uses
dpkg's start-stop-daemon utility).
The Slackware and Red Hat init scripts removed by this commit are not
tested or maintained in practice, and so are likely to have bugs. The
Slackware init-script provided here is not used on actual Slackware
systems, which provide a different implementation of rc.messagebus in
their packaging, while the Red Hat init script has been superseded by
the systemd unit in current Fedora, CentOS and RHEL versions.
The Cgywin messagebus-config provided here does appear to be used in
production in cygwin-ports, but it's full of Cygwin-specifics with which
the dbus maintainers are not familiar, so it is probably more appropriate
for it to be tracked downstream as part of the Cygwin packaging.
The systemd unit is not removed, since it is used on multiple Linux
distributions with little or no modification, and receives regular
testing and maintenance; this makes it appropriate to maintain upstream.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/101706
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This feature is now compile-time conditional, and off by default.
pam_console appears to have been in Fedora and Gentoo until 2007.
pam_foreground seems to be specific to Debian and Ubuntu, where it was
unmaintained since 2008 and removed in 2010. The replacement for both
was ConsoleKit, which has itself been superseded by systemd-logind and
ConsoleKit2.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/101629
Reviewed-by: Philip Withnall <withnall@endlessm.com>
By default, Expat uses cryptographic-quality random numbers as a salt for
its hash algorithm, and since 2.2.1 it gets them from the getrandom
syscall on Linux. That syscall refuses to return any entropy until the
kernel's CSPRNG (random pool) has been initialized. Unfortunately, this
can take as long as 40 seconds on embedded devices with few entropy
sources, which is too long: if the system dbus-daemon blocks for that
length of time, important D-Bus clients like systemd and systemd-logind
time out and fail to connect to it.
We're parsing small configuration files here, and we trust them
completely, so we don't need to defend against hash collisions: nobody
is going to be crafting them to cause pathological performance.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101858
Tested-by: Christopher Hewitt <hewitt@ieee.org>
[smcv: Adjust build-system changes for 1.11.x]
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
By default ${runstatedir} is the same as ${localstatedir}/run, but many
Linux distributions configure it to be /run and mount a tmpfs in that
location. All other factors being equal, it is preferable to use /run
where available because it is guaranteed to be local, whereas traversing
/var might involve automounting a networked filesystem (even though
/var/run itself is very likely to be a tmpfs).
/run or /var/run is currently only used in a few places in dbus, but
I plan to make more use of it during the development of
<https://bugs.freedesktop.org/show_bug.cgi?id=100344>.
The pid file is not part of the API between dbus and other software
(other than distribution init scripts for dbus itself), so we do not
need to keep it strictly compatible; so it is OK to move it.
We do not yet use /run for the system bus socket, because that is
part of the API between D-Bus clients and servers, and has always been
"officially" /var/run/dbus/system_bus_socket.
<https://bugs.freedesktop.org/show_bug.cgi?id=101628> tracks the
possibility of changing that.
Similarly, we do not replace /var/run/console with /run/console, because
that path is part of the API between dbus-daemon and the obsolete PAM
modules pam_console and pam_foreground that used /var/run/console.
<https://bugs.freedesktop.org/show_bug.cgi?id=101629> tracks the possible
future removal of that code path.
In the CMake build system, the equivalent of ${runstatedir} remains
hard-coded to the equivalent of ${localstatedir}/run for simplicity. For
the sort of system-wide installations that would consider redefining
${runstatedir} to /run, the Autotools build system is strongly
recommended: in particular this is what Linux distributions are expected
to use.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101569
On systemd systems, /etc/machine-id is guaranteed to exist and has
the same format as the D-Bus machine ID. The major D-Bus implementations
read /etc/machine-id if it exists, but some less up-to-date
implementations still only read /var/lib/dbus/machine-id. We can be
nice to those implementations by ensuring /var/lib/dbus/machine-id
is a symlink; this way, the two files can never get out of sync.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101570
Now that g_test_trap_fork() has gone, we no longer have any calls to
GLib functions deprecated in or before 2.40.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101362
This is quite old (it's the version in Ubuntu 14.04 LTS, and older
than the version in Debian 8) but gives us g_test_skip(),
g_test_trap_subprocess() and GVariantDict, all of which will be
useful in the regression tests.
Remove workarounds for old versions.
After this commit we are still using the deprecated g_test_trap_fork(),
which will be removed in a subsequent commit. Don't opt-in to the new
deprecation warnings from 2.38 and 2.40 yet, because under our recommended
settings for dbus developers (-Werror) they would break the build.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101362
sidget and sidput functions are noop and deprecated since libselinux 2.0.86.
Also use pkg-config to detect libselinux and force version >= 2.0.86
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100912
Reviewed-by: Simon McVittie <smcv@collabora.com>
This avoids "capturing" the build directory in the built binaries
when built with embedded tests, which is good for reproducible builds.
See <https://reproducible-builds.org/> for more information.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100692
The version of expat that added the .pc file was released in 2012.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69801
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
With this support cmake and autotools generates cmake equivalent of
pkgconfig files on configure time named DBus1Config*.cmake. These
files are installed into the related directory where cmake expects
find_package related config files.
For instructions how to use this feature with clients see readme.cmake.
With previous DBus versions each cmake client using DBus as dependency
needed a related FindDBus*.cmake in its source distribution or in
the cmake binary packages. With the 'config' find package style support
provided by this patch this requirement has been removed.
The generated config file uses pkgconfig on unix or autotools to
fetch package build flags, which is the prefered way. On Windows
we do not want to require CMake users to have pkg-config installed
so it uses cmake buildin target export support for exporting all
targets into DBus1ConfigTargets*.cmake.
[smcv: make sure variable substitution works in Autotools too]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99721
Reviewed-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Relocatable pkgconfig files are necessary when using packages installed to
a location that does not match the location for which they were compiled.
However, using ${pcfiledir} is problematic for system installations
in standard locations, because it interferes with pkg-config's
ability to filter out -I, -L options that are redundant with compiler
defaults (which is important if you are trying to use a newer version
of a library than the system copy).
In practice operating system vendors installing dbus to standard
locations use Autotools, so we enable relocatable builds by default
when building with CMake.
For simplicity, we're also not relocatable if the library directory
is something more complicated than lib or lib64 (e.g. under Debian
multiarch); we don't want to have to compute how many ../ to add.
This is non-trivial to determine in an Autotools build, so for now
there is no support for relocation when built with Autotools,
even as an opt-in feature.
Going via the ${original_prefix} variable is because under Autotools,
both ${prefix} and ${exec_prefix} technically default to NONE, with
NONE replaced with their real defaults of /usr/local and '${prefix}'
(respectively) later on. If we tried to expand ${prefix} at the time
that we choose the value of ${pkgconfig_prefix}, that would cause
a broken value "prefix=NONE" to be hard-coded.
[smcv: no relocation on Autotools, make it optional in CMake,
expand commit message]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99721
Reviewed-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <smcv@collabora.com>
This adds a "sysusers.d" snippet for creating the system user "dbus" at
boot, if it is missing, in order to support stateless systems that boot
up with an empty /etc and need static information for determining which
system users to create.
This is only installed on systemd-based systems.
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99162
We need libapparmor 2.10 for the test, but not for the actual
functionality, for which 2.8.95 is enough. In particular this lets
us compile with AppArmor enabled on Ubuntu 14.04, which is still
the newest host platform available on travis-ci.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98666
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This requires libapparmor 2.10, for aa_features_new_from_kernel()
and related functions.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98666
The autoconf macros AX_COMPILER_FLAGS_{CFLAGS|CXXFLAGS|LDFLAGS} test
for compiler and linker support of various flags, and add the flags to
the generated output.
If the command-line option '--enable-compile-warnings' is specified to
'configure', a number of additional warning options is also added to the
output. This is the default.
The AX_COMPILER_FLAGS_* macros add stricter warnings then before. The
patch disables some of them to make dbus build without errors. A later
patch set should fix the warnings and remove the compiler flags.
This patch integrates all tests for compiler flags into the call to
AX_COMPILER_FLAGS_CFLAGS. All tests for compiler flags are now done
in a single place. The old macros have been removed.
Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
[smcv: add missing $ to DISABLE_WARNINGS]
[smcv: drop -Wno-discarded-qualifiers]
[smcv: drop non-C++ option -Wpointer-sign in C++ mode]
[smcv: work around an AX_COMPILER_FLAGS_CFLAGS bug]
[smcv: this source tree is called dbus, not DBus]
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
Annoyingly, the POSIX way to declare environ (as
"extern char **environ") is a redundant declaration in glibc with
_GNU_SOURCE; work around that.
We also have a workaround for _NSGetEnviron() needing to be used
instead of direct access to environ in at least some circumstances on
Mac OS. Attempt to sync that up between all the files that use environ,
consistently sorting the most special special-cases first (Windows
for files that are compiled there, then Mac, then GNU, with
lowest-common-denominator POSIX last).
The affected files are already OS-specific, so I'm not bothering to
introduce a nicer or higher-level API for this.
Based on the best bits of an earlier patch from me, and an earlier
patch from Thomas Zimmermann.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
