Some of them fail when run on Windows, and debugging the test suite
for a subproject is out-of-scope for dbus.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Debian 12 'bookworm' has Meson 1.0.1, which is too old for the current
stable branch of GLib. Use the version from bookworm-backports when
running on Debian and building with a mingw-w64 compiler.
We can stop doing this and put meson back in the normal list of
packages when we update to the Debian 13 stable release, expected to be
released in mid 2025.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Commit a56de468 "CI: Avoid using a no-op download location that gives
a 403 error" changed this, but now the direct URL to the file *also*
gives a 403 error. According to the comments in this file, the only
reason we're fetching these URLs is in an effort to pre-seed the
cache of intermediate certificates, so the specific URL that we're
requesting is uninteresting: we just need to fetch *something*.
dbus#546
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, the CMake build enabled tests by default, and enabled both
modular and intrusive (embedded) tests with a single option. This is
a really bad idea if anyone is using CMake-built binaries in production.
DBUS_BUILD_TESTS now enables only the modular tests, which are safe to
enable in production builds.
A new DBUS_ENABLE_INTRUSIVE_TESTS option enables the intrusive test
instrumentation.
To preserve existing test coverage, explicitly enable the intrusive
tests in most CMake-based Gitlab-CI jobs (Debian native, openSUSE native,
Windows).
In jobs that have a mirrored pair of production/debug builds (openSUSE
and Debian mingw32/mingw64 cmake), instead we leave the production
build as-is and only build full test coverage in the debug build.
Co-authored-by: Philip Withnall <philip@tecnocode.co.uk>
Signed-off-by: Simon McVittie <smcv@collabora.com>
This hopefully helps to get across the point that enabling these tests
adds instrumentation to libdbus and dbus-daemon, with a potentially
significant impact on code size, performance and security.
To avoid a huge diffstat which would be difficult to review, the cpp
macro that is checked by most of the C code is still
DBUS_ENABLE_EMBEDDED_TESTS, which is defined or undefined under exactly
the same conditions as the new DBUS_ENABLE_INTRUSIVE_TESTS.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/537
Co-authored-by: Philip Withnall <philip@tecnocode.co.uk>
Signed-off-by: Simon McVittie <smcv@collabora.com>
This choice of exe_wrapper doesn't appear to work on Debian 12, causing
a build failure while checking that the output of the C++ compiler is
executable.
Another advantage of this is that if we're not running the test suite,
we can do a more traditional cross-build where running host-architecture
executables is impossible, which doubles as a way to prove that this
still works.
Signed-off-by: Simon McVittie <smcv@collabora.com>
On Debian 12, this is necessary to get libclang-rt-14-dev (which
contains the headers for LeakSanitizer) without hard-coding the clang
major version.
Signed-off-by: Simon McVittie <smcv@collabora.com>
A command like `dbus-test-tool spam --payload=abcde --bytes` could
previously have left the length uninitialized.
Detected by compiling with gcc 14.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Recent versions of glibc support C.UTF-8 natively, and both Debian and
openSUSE (which we use for our CI) have been patching it into our glibc
versions for several years before that.
Helps: https://gitlab.freedesktop.org/dbus/dbus/-/issues/488
Signed-off-by: Simon McVittie <smcv@collabora.com>
Before we removed the Autotools build system, these meant: do a
`make dist` with Autotools, then unpack the resulting tarball, and build
it with Meson or CMake (as appropriate). This was important because the
contents of an Autotools `make dist` differed significantly from what's
in git: only the files that were explicitly declared as sources in the
Autotools build system were distributed, and Autotools would also add its
own generated cruft.
Now that we're doing releases with Meson, the official source release
artifact is basically `git archive`, so there's much less need to
distinguish between official source releases and what's in git, and these
variant build systems became simple aliases for meson and cmake.
Remove those aliases from tools/ci-build.sh, and stop using them in
.gitlab-ci.yml.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The 'debian mingw32 autotools debug' job was replaced with a corresponding
meson related job named 'debian mingw32 meson debug' and the remaining
autotools related jobs were removed.
The drop in replacement job for 'debian mingw64 autotools' is
'debian mingw32 meson' and is now build by default.
On 32 bit systems long will overflow in 2038, causing complete breakage.
This is confirmed by running dbus's test suite on a 32 bit system
with system time set to 2040 (and configured to use 64 bit time_t of course).
Note that both timespec and timeval are specified with time_t for the
seconds component. This should propagate everywhere where that data is
passed and stored, but previously _dbus_get_monotonic_time() and
_dbus_get_monotonic_time() would truncate it to long.
Also add a function for parsing dbus_int64_t from
files, as existing functions can only handle long.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
This is generally not recommended (dbus should usually be installed from
the OS distributor's packages, which should install into a staging
directory using `DESTDIR`), but we'll want to use it in Gitlab-CI.
Signed-off-by: Simon McVittie <smcv@collabora.com>
There are some differences between Autotools and Meson here:
- Because we detect native atomic operations differently, we can no
longer emulate a platform that doesn't have them, such as ARMv4;
but modern OSs no longer support ARMv4 and all significant hardware
platforms now have native atomic operations, so this is now less of
a concern.
- Similarly, we can no longer emulate a platform that doesn't have the
getrandom() library function, but that function is available in all
relevant glibc versions (such as CentOS >= 8, Debian >= 10,
Ubuntu >= 18.04) so testing the fallback path is less of a concern now.
We also no longer try to disable dnotify in the legacy build, but our
dnotify code path was removed in 2013, so --disable-dnotify didn't do
anything anyway.
[Separated from a larger commit on dbus!378 —smcv]
Co-authored-by: Simon McVittie <smcv@collabora.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
The order and arrangement of the initialization of the build directories
has been improved: the deletion of special directories have been moved to
the associated part, the rest have been merged and there is a default
value if not specified as an environment variable, making it easier to
execute on the command line.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
This customization simplifies their use, e.g. when outputting the command
line used. Because of FreeBSD, 'awk' is used instead of 'gawk' to make
sure that the tool is available.
Due to an adaptation of an rpm macro for cross-compiling with cmake, there
was a problem with the previous method of using the current directory as
the build directory. Instead, the command line options provided by cmake
are now used to define the source and build directories, which provide more
stable behavior.
Fix#455
Repeatedly re-running each test with different malloc() calls failing
is really slow, and in particular this is making
dbus:dbus / marshal-recursive time out on freedesktop.org CI.
Signed-off-by: Simon McVittie <smcv@collabora.com>
On Gitlab-CI we're always running the overall script as root (and
therefore we'll only enter the code path to re-run as non-root),
but when using these scripts for manual testing they might be run as
non-root to begin with.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Travis CI needed this, but Gitlab-CI always runs our tests in a Docker
container of our choice, so there's never any need to enter another
(and it's not allowed anyway).
Signed-off-by: Simon McVittie <smcv@collabora.com>
These CI scripts were originally used on Travis-CI, which starts all
builds as an ordinary user that has the ability to become root via `sudo`.
On Gitlab-CI, we don't need that: we start as uid 0, and can do the
whole CI run like that. This also means we get somewhat better test
coverage, because some of our unit tests benefit from being run as uid 0.
The only test coverage we lose by being uid 0 is that
test_pending_fd_timeout() in test/dbus-daemon.c is skipped, because
uid 0 bypasses the limit that's under test there.
To make the consume libdbus via Meson's subproject use case more useful,
introduce message_bus and tools command line options which control if
the D-Bus daemon and/or the tools are build. The idea here is that
depending projects are interested only in the library.
The strong recommendation is only to build libdbus as static library:
libdbus_dep = dependency(
'dbus-1',
required: get_option('libdbus'),
fallback: ['dbus', 'libdbus_dep'],
default_options: [
'default_library=static',
'embedded_tests=false',
'message_bus=false',
'modular_tests=disabled',
'tools=false',
],
)
This ensures that any installed D-Bus infrastructure on the target
system is not overwritten.
Signed-off-by: Daniel Wagner <dwagner@suse.de>
The full license texts are not added because they were already
added in a previous commit.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
see #394
These files are licensed under the GPL only, without the AFL dual-license
of most of the dbus codebase.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Co-authored-by: Ralf Habacker <ralf.habacker@freenet.de>
Unlike ASan, by default UBSan prints one-line warnings and keeps going
and it makes it impossible for the CI to catch issues automatically when
it runs the unit tests. With this patch applied the CI should be able to
prevent issues like
https://gitlab.freedesktop.org/smcv/dbus-issue413/-/merge_requests/1#note_1549306
from making it into the repository going forward.
Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>
We would like to start using ${runstatedir}/dbus/system_bus_socket,
so that distributors who make /var/run a symbolic link to /run will
usually get their dbus-daemon listening on /run/dbus/system_bus_socket,
which has some advantages in corner cases, such as when /var is mediated
by an automounter or is unmounted during system shutdown.
Unfortunately, the interoperable path in the D-Bus Specification is
/var/run/dbus/system_bus_socket for historical reasons (D-Bus is older
than /run), and older versions of Slackware are known to have had /run
and /var/run as distinct directories. Do a check during configuration
to catch systems configured like this and show a warning.
When cross-compiling, this assumes that the system where dbus is built
(the build system in Autotools/Meson, or the "host" in CMake terminology)
has its /var/run and /run set up in a way that is compatible with the
system where dbus will run (the host system in Autotools/Meson, or the
"target" in CMake terminology). This is not 100% correct, but seems good
enough for a warning that will hopefully only trigger for misguided OS
distributors.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Similar to dbus/dbus!286, but more so: just use the package names,
ignoring their version numbers completely.
pcre2 is not strictly needed at the moment, but it'll be a dependency
for GLib >= 2.73.x (older versions used pcre). For a bit of
future-proofing, download both pcre and pcre2.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The Makefile.am files contain % pattern rules that are not supported by
`make` (bmake) on FreeBSD. Since the replacing the patterns is non-trivial,
this commit updates the CI script to use GNU make when building on FreeBSD.
