The X11 connection is opened and never closed. Because dbus-launch
forks and continues to run non-trivial code in a forked child, it is
not clear whether (or where) it would be safe to close it; instead, we
leave it open until process exit, at which point the socket is cleaned
up by the kernel.
Any memory allocated for the X11 connection is only allocated once per
run of dbus-launch, so there's no need to keep track of it, and we can
silence these memory leak warnings as uninteresting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we are not using Meson subprojects, this will have no practical
effect, because the directories won't exist.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't currently know the equivalent of python3-mallard-ducktype on
other OSs like openSUSE, but we know this should work on Debian (it does
when we do Autotools builds).
Signed-off-by: Simon McVittie <smcv@collabora.com>
The whole point of these tests is that they're safe to enable because
they don't affect the production binaries.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These pass a lot of configure arguments taken from RPM macros, which
are only accepted by the meson command if we don't explicitly select
a mode.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is similar to what we have done for CMake since dbus/dbus!87
(commit 1063bba "CI: Do the CMake native debug build from an Autotools
`make dist`"). Our official source releases are Autotools `make dist`
tarballs, so our CI should assert that such tarballs contain everything
necessary to do a CMake or Meson build, so that downstream distributions
using our tarballs as source can choose their preferred build system.
When the Meson build system is ready to be recommended as more preferred
than Autotools, we can do as GLib did: stop releasing `make dist`
tarballs, and start releasing `meson dist` tarballs instead (which will
change nothing for Meson or CMake users, but Autotools users will have
to run autoreconf or autogen.sh before building).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This will make it easier to capture log files. All our CI builds happen
in an expendable checkout, so we can safely remove and re-create ./build.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Use install_emptydir() in Meson versions that support it, or a script
with similar invocation in versions that do not. This will make it
straightforward to migrate to install_emptydir() when we drop support
for Meson versions older than 0.60.0.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Use install_symlink() in Meson versions that support it, or a script
with similar invocation in versions that do not. This will make it
straightforward to migrate to install_symlink() when we drop support
for Meson versions older than 0.61.0.
Based on an implementation in the game-data-packager package, which used
a shell script.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This should let us build everything with a mingw-w64 toolchain, without
having to use prebuilt dependencies from MSYS.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As long as we are treating Autotools as a first-class citizen, what we
release will be `make distcheck` output.
Signed-off-by: Simon McVittie <smcv@collabora.com>
CMake 3.21 can emit JUnit XML test results which can be visualized by
GitLab. This also updates the gitlab CI config file to make use of this
feature whenever possible.
Using PRId64, etc. to print dbus_int64_t or dbus_uint64_t is not 100%
portable. On platforms where both long and long long are 64-bit (such as
Linux and macOS), we will prefer to define dbus_int64_t as long.
If the operating system has chosen to define int64_t as long long,
which is apparently the case on macOS, then the compiler can warn that
we are passing a long argument to PRId64, which is "lld" and therefore
expects a long long argument (even though that ends up with the same
bit-pattern being used).
We can't necessarily just use int64_t and uint64_t directly, even if all
our supported platforms have them available now, because swapping
dbus_int64_t between long and long long might change C++ name mangling,
causing ABI breaks in third-party libraries if they define C++ functions
that take a dbus_int64_t argument.
Signed-off-by: Simon McVittie <smcv@collabora.com>
What we are aiming for here is that `dbus-launch --autolaunch` will
exit with an error if it would have been unable to advertise the bus
in a way that will be picked up by other instances of itself, so that
we don't get a proliferation of autolaunched dbus-launch instances,
each with its own dbus-daemon, and none of them talking to the others.
However, we don't need to do that *immediately*: we can try to look for
an existing instance first. If we find one, then we can assume that
it's suitable for use, even if X11 autolaunching was disabled at
compile-time or if connecting to the X server failed at runtime. We
only need to bail out if we get to the point where we are ready to start
forking child processes.
This lets systemd users run `dbus-launch --autolaunch` to find a
systemd-managed dbus-daemon, even if X11 autolaunching is disabled.
When combined with the previous commit, it also lets macOS users run
`dbus-launch --autolaunch` to find a launchd-managed dbus-daemon.
Resolves: dbus/dbus#385
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we were looking for an existing bus via
_dbus_lookup_user_bus(), meaning a user bus $XDG_RUNTIME_DIR/bus
(in practice this is managed by systemd --user, although in principle
there's nothing to stop other session frameworks from providing the
same thing).
_dbus_lookup_session_address() looks for an externally-managed
dbus-daemon in a more general way: on macOS it uses launchd, and on other
Unix it's a thin wrapper around _dbus_lookup_user_bus(). Let's try that,
so that macOS users can get their existing dbus-daemon from launchd.
This partially resolvesdbus/dbus#385, although initially only for macOS
users who have (unusually) enabled X11 autolaunching support.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The mingw related jobs are running the whole test suite which
is an extension to the available jobs.
The environment variable ci_suite is not used on openSUSE
distributions, as it is determined from the installed image.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Instead of having to specify an exact version that needs to be adjusted
with each repository update, it is now possible to specify package names
without version or partially qualified versions, which reduces the
frequency of necessary adjustments.
This is achieved by searching for the package names in a previously
downloaded list of available packages.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
