dbus merge requestshttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests2024-01-15T20:00:49Zhttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/454meson: Use check_header to confirm headers work2024-01-15T20:00:49ZThomas Sondergaardmeson: Use check_header to confirm headers workinstead of using has_header use check_header to confirm the header
works. This is necessary to get the meson build to work with Visual
Studio 2022. It has <stdatomic.h> but it does not actually work when
compiling a C program. A minimal ...instead of using has_header use check_header to confirm the header
works. This is necessary to get the meson build to work with Visual
Studio 2022. It has <stdatomic.h> but it does not actually work when
compiling a C program. A minimal C program that include <stdatomic.h>
fails with the following errors:
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(36): error C2061: syntax error: identifier 'atomic_bool'
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(36): error C2059: syntax error: ';'
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(37): error C2061: syntax error: identifier 'atomic_char'
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(37): error C2059: syntax error: ';'
...
...
check_header is consistent with CMake's
check_include_file(stdatomic.h HAVE_STDATOMIC_H)
which is why the CMake-based build of dbus works with Visual Studio
2022, while the meson build doesn't.
Fixes #494https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/414CI: Don't run windows-meson-mingw-ucrt64 by default2023-06-13T13:16:32ZSimon McVittieCI: Don't run windows-meson-mingw-ucrt64 by default* CI: Don't run windows-meson-mingw-ucrt64 by default
Workaround for dbus#462: if this doesn't run reliably as a result of
external factors, then we shouldn't be using it as a CI gate.
* CI: Enable "debian mingw64 meson deb...* CI: Don't run windows-meson-mingw-ucrt64 by default
Workaround for dbus#462: if this doesn't run reliably as a result of
external factors, then we shouldn't be using it as a CI gate.
* CI: Enable "debian mingw64 meson debug" by default
This gives us coverage for Meson mingw-w64 by default, but
cross-compiling from Debian with MSVCRT rather than a native compilation
on Windows with UCRT. When combined with "windows msys64 ucrt64 cmake",
this fills in most of the missing coverage caused by disabling
windows-meson-mingw-ucrt64 to work around dbus#462.Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/411cmake: Define _GNU_SOURCE before checking for any symbols2023-06-07T12:26:13ZSimon McVittiecmake: Define _GNU_SOURCE before checking for any symbols* cmake: Define _GNU_SOURCE before checking for any symbols
Some of the symbols we check for, such as close_range(), are only
declared in their corresponding header files if _GNU_SOURCE was
defined.
Resolves: db...* cmake: Define _GNU_SOURCE before checking for any symbols
Some of the symbols we check for, such as close_range(), are only
declared in their corresponding header files if _GNU_SOURCE was
defined.
Resolves: dbus/dbus#453
* sysdeps: Correct fallback signature of Linux close_range()
Linux generally declares syscalls with flags as type int. It's the same
ABI, but a slightly different API, and it seems better for our fallback
definition to match it exactly.
Related to dbus/dbus#453.
---
Ready for review, but please don't merge until after I've released 1.15.8.
Not applicable to 1.14.x or older.
/cc @rhabacker1.16.0Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/405Fix CI2023-05-12T18:06:40ZSimon McVittieFix CI* CI: Run a detached pipeline for merge requests
After abuses of fdo infrastructure were mitigated in
freedesktop/freedesktop#540, contributors cannot usually run pipelines
in their own forks of dbus.
* CI: Only run for...* CI: Run a detached pipeline for merge requests
After abuses of fdo infrastructure were mitigated in
freedesktop/freedesktop#540, contributors cannot usually run pipelines
in their own forks of dbus.
* CI: Only run for pushes to dbus
In practice the pipeline is going to fail for namespaces other than
dbus, so don't waste time on trying to run it there; only run the
detached pipeline for the MR.
* CI: Update to current fdo CI templates
* CI: Remove an obsolete workaround
* CI: Update Windows runners
* CI: Sort lists of openSUSE packages alphabetically
* CI: Install mingw64-cross-cmake in openSUSE image
* CI: Disable OOM-testing code paths for Meson, matching Autotools and CMake
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.
* CI: Make creation of user idempotent
* CI: Avoid using a no-op download location that gives a 403 error
* CI: Disable "opensuse mingw64 cmake debug" until #455 is fixed
Having some CI is better than having no CI.
* CI: Disable native Windows builds for now
These are extremely slow (the image build is currently at 36 minutes
and still running) which is standing in the way of us having functional
CI at all. They can be re-enabled if someone will maintain them.Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/392CI: Avoid changing uid, except when running installed-tests2023-02-08T10:39:03ZSimon McVittieCI: Avoid changing uid, except when running installed-tests* CI: Don't change ownership of source directory
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...* CI: Don't change ownership of source directory
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.
* CI: Re-clone the git repository every time
This cleans up checkouts that were subjected to `chown -R` prior to this.
Resolves: dbus/dbus#447
* CI: Remove vestigial support for re-running tests in a Docker container
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).
* CI: Re-run some tests as root or as non-root, as appropriate
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.
---
We can revert the second commit after a few days or weeks, when old checkout directories on all shared runners have been cleaned up.
/cc @rhabackerSimon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/261build: Opt out from using mingw-w64's replacement printf(), etc.2022-03-08T08:28:08ZSimon McVittiebuild: Opt out from using mingw-w64's replacement printf(), etc.* build: Opt out from using mingw-w64's replacement printf(), etc.
The Windows code in dbus is careful to use Windows-specific equivalents
of the Standard C features that are not implemented by msvcrt.dll, so
we don't ne...* build: Opt out from using mingw-w64's replacement printf(), etc.
The Windows code in dbus is careful to use Windows-specific equivalents
of the Standard C features that are not implemented by msvcrt.dll, so
we don't need to substitute a Standard C printf implementation.
This avoids compiler warnings/errors when gcc expects us to be using
Microsoft printf syntax (`ms_printf` attribute), but newer versions of
mingw-w64 expect us to be using GNU or Standard C printf syntax
(`gnu_printf` attribute) as a result of `__USE_MINGW_ANSI_STDIO` being
enabled by default if not otherwise specified.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/380
* CI: Use current Debian stable release for mingw-w64 builds
Now that we have resolved the failure to build with newer mingw-w64,
we don't need to hold these back to Debian 10 'buster' and can upgrade
to the current stable release, Debian 11 'bullseye'.
* CI: Make most gcc warnings fatal for CMake builds
This makes sure we notice problems early.1.14.xSimon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/237internals: Use Standard C offsetof macro if available2021-12-13T12:44:10ZSimon McVittieinternals: Use Standard C offsetof macro if availableclang 13 fails to compile our current implementation with:
```
.../dbus/dbus-message.c:2070:3: error: variable length array folded to constant array as an extension [-Werror,-Wgnu-folding-constant]
_DBUS_STATIC_ASSERT (_DBUS_ALIGNOF (...clang 13 fails to compile our current implementation with:
```
.../dbus/dbus-message.c:2070:3: error: variable length array folded to constant array as an extension [-Werror,-Wgnu-folding-constant]
_DBUS_STATIC_ASSERT (_DBUS_ALIGNOF (DBusMessageRealIter) <=
^
.../dbus/dbus-internals.h:460:25: note: expanded from macro '_DBUS_STATIC_ASSERT'
typedef struct { char _assertion[(expr) ? 1 : -1]; } \
```
This appears to be because the "traditional" definition of
offsetof(), which we're hard-coding here, does not qualify as a constant
expression under C rules due to its use of pointer casts.
Modern compilers like gcc and clang have a built-in implementation
of offsetof that *is* a constant expression.
/cc @rhabacker @pwithnall1.14.xSimon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/190ci-build: Update required MSYS packages2022-02-25T11:54:54ZSimon McVittieci-build: Update required MSYS packagesThe older versions we were previously building against are no longer
available on mirrors.
Based on changes proposed in !189 by Arnout Engelen, and the package
list gathered by Ralf Habacker in #318.
Resolves: https://gitlab.freedeskto...The older versions we were previously building against are no longer
available on mirrors.
Based on changes proposed in !189 by Arnout Engelen, and the package
list gathered by Ralf Habacker in #318.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/318
Signed-off-by: Simon McVittie <smcv@collabora.com>
---
/cc @raboof @rhabackerhttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/167tests: On Unix, include <netinet/in.h> for IPPROTO_TCP2020-08-19T14:28:07ZSimon McVittietests: On Unix, include <netinet/in.h> for IPPROTO_TCPOtherwise, dbus doesn't compile on FreeBSD if the GLib-based tests
are enabled (which suggests that no FreeBSD user has run those tests
successfully).
We already include <netinet/in.h> in other places with no conditions
or checks other ...Otherwise, dbus doesn't compile on FreeBSD if the GLib-based tests
are enabled (which suggests that no FreeBSD user has run those tests
successfully).
We already include <netinet/in.h> in other places with no conditions
or checks other than "is Unix", so apparently it's portable enough that
specifically testing for its presence is not necessary. POSIX requires it
to exist.
---
Also nominated for dbus-1.12 branch, because it'll make it easier for the (possibly hypothetical) people who test dbus on non-Linux Unix.https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/129cmake: add X11 include directories to tools2020-01-23T11:36:23ZTuomo Rinnecmake: add X11 include directories to toolsadd include paths to tools, otherwise compilation will fail
if the headers are in non-standard locationadd include paths to tools, otherwise compilation will fail
if the headers are in non-standard locationhttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/113cmake: Create all output directories for Doxygen2019-04-26T21:48:56ZSimon McVittiecmake: Create all output directories for DoxygenCI 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 (I h...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 (I hope)
Signed-off-by: Simon McVittie <smcv@collabora.com>
/cc @rhabackerSimon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/110build: Don't assume we can set permissions on a directory2019-04-18T15:37:19ZSimon McVittiebuild: Don't assume we can set permissions on a directoryMSYS2 has enough of a Unixish environment to run Autotools, but
apparently not enough of a Unixish environment to have functional
permissions.
Closes: dbus#216MSYS2 has enough of a Unixish environment to run Autotools, but
apparently not enough of a Unixish environment to have functional
permissions.
Closes: dbus#216Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/109Backport -Wlogical-op fixes to 1.12.x2019-04-17T15:19:04ZSimon McVittieBackport -Wlogical-op fixes to 1.12.xgcc 8 won't compile the dbus-1.12 branch, because new warnings have been added to `-Wlogical-op`.
Note that this is a slight behaviour change. Previously, we accidentally accepted absolutely anything in a .service file section name, due...gcc 8 won't compile the dbus-1.12 branch, because new warnings have been added to `-Wlogical-op`.
Note that this is a slight behaviour change. Previously, we accidentally accepted absolutely anything in a .service file section name, due to an unintended tautologous expression (which, if it had been written the way it was intended to be, would have excluded the only section name we actually use, `D-BUS Service` (sic)). Now we apply the documented .desktop-style rules.
This change has been on master since 1.13.8 (December) without anyone reporting it causing problems.Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/108Adapt to API change in AX_CODE_COVERAGE version 282019-04-17T15:18:44ZSimon McVittieAdapt to API change in AX_CODE_COVERAGE version 28AX_CODE_COVERAGE recently changed the way it embedded its Makefile rules
in the output file: instead of using @CODE_COVERAGE_RULES@, users
are now meant to include aminclude_static.am.
The new AX_CODE_COVERAGE is only in the latest auto...AX_CODE_COVERAGE recently changed the way it embedded its Makefile rules
in the output file: instead of using @CODE_COVERAGE_RULES@, users
are now meant to include aminclude_static.am.
The new AX_CODE_COVERAGE is only in the latest autoconf-archive release,
version 2019.01.06, which is inconveniently new, so bundle everything
we need for the moment.
This requires us to stop using the deprecated CODE_COVERAGE_LDFLAGS
(which we still used to support older versions of autoconf-archive)
and replace them with CODE_COVERAGE_LIBS.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 2938c2125ebcd001e470aeac1ffac45b6b1ebe89)
Closes: dbus#265
---
Backport of dbus/dbus!88 to dbus-1.12.
/cc @pwithnall @rhabackerSimon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/88Adapt to API change in AX_CODE_COVERAGE version 282019-04-17T12:42:41ZSimon McVittieAdapt to API change in AX_CODE_COVERAGE version 28AX_CODE_COVERAGE recently changed the way it embedded its Makefile rules
in the output file: instead of using @CODE_COVERAGE_RULES@, users
are now meant to include aminclude_static.am.
The new AX_CODE_COVERAGE is only in the latest ...AX_CODE_COVERAGE recently changed the way it embedded its Makefile rules
in the output file: instead of using @CODE_COVERAGE_RULES@, users
are now meant to include aminclude_static.am.
The new AX_CODE_COVERAGE is only in the latest autoconf-archive release,
version 2019.01.06, which is inconveniently new, so bundle everything
we need for the moment.
This requires us to stop using the deprecated CODE_COVERAGE_LDFLAGS
(which we still used to support older versions of autoconf-archive)
and replace them with CODE_COVERAGE_LIBS.
---
Consistently add CODE_COVERAGE_LIBS everywhere
We need to link the code coverage objects, directly or indirectly,
into every executable and every shared library. The rule I've followed
to make it clear that we do this, without too much repetition, is:
each executable, shared library or convenience library has
CODE_COVERAGE_LIBS in its LDADD or LIBADD, unless it is linked to a
convenience library in the same directory that has CODE_COVERAGE_LIBS
in *its* LIBADD.
---
Consistently add CODE_COVERAGE_CPPFLAGS everywhere
We forgot this in a couple of places.
---
First commit proposed for dbus-1.12. Second and third commits probably not.
Resolves dbus#249Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/86configure.ac: Forbid AX_-prefixed patterns more selectively2020-01-14T09:48:16ZSimon McVittieconfigure.ac: Forbid AX_-prefixed patterns more selectivelyWe want to make autoconf fail early and with a user-comprehensible
message if autoconf-archive isn't installed, rather than generating
a configure script with syntax errors, or a configure script that runs
successfully but doesn't do ...We want to make autoconf fail early and with a user-comprehensible
message if autoconf-archive isn't installed, rather than generating
a configure script with syntax errors, or a configure script that runs
successfully but doesn't do what we intended.
However, autoconf-archive doesn't actually guarantee not to use
AX_-prefixed shell variable names without m4_pattern_allow'ing them
(unlike Autoconf, Automake, Libtool and pkg-config, which explicitly use
m4_pattern_allow for variables with AC_, AM_, LT_ and PKG_ prefixes), so
it isn't safe to assume that they won't be used. In particular, recent
versions of AX_CHECK_GNU_MAKE appear to be using
$AX_CHECK_GNU_MAKE_HEADLINE as a shell variable.
Instead, specifically forbid the names of the finite list of macros
that we actually use.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: dbus#249Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/36internals: Assume compiler supports a subset of ISO varargs syntax2018-11-16T11:41:34ZSimon McVittieinternals: Assume compiler supports a subset of ISO varargs syntaxWe have considerable anecdotal evidence that every relevant compiler
supports at least the small part of ISO varargs syntax that we need
here, because tools/tool-common.h has contained
#define VERBOSE(...) do {} while (0)
since dbu...We have considerable anecdotal evidence that every relevant compiler
supports at least the small part of ISO varargs syntax that we need
here, because tools/tool-common.h has contained
#define VERBOSE(...) do {} while (0)
since dbus 1.9.2 (2014) and nobody has complained yet. With that in
mind, let's simplify.
Signed-off-by: Simon McVittie <smcv@collabora.com>https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/35Don't check how to copy a va_list if we have va_copy; only use _DBUS_VA_COPY_...2018-11-20T11:23:38ZSimon McVittieDon't check how to copy a va_list if we have va_copy; only use _DBUS_VA_COPY_ASSIGN on MSVCIf we already have ISO C va_copy() or its non-standard counterpart __va_copy(), then there's no need to do an AC_RUN_IFELSE or its CMake equivalent to detect whether "args2 = args1" or "*args2 = *args1" works. AC_RUN_IFELSE is problemati...If we already have ISO C va_copy() or its non-standard counterpart __va_copy(), then there's no need to do an AC_RUN_IFELSE or its CMake equivalent to detect whether "args2 = args1" or "*args2 = *args1" works. AC_RUN_IFELSE is problematic during cross-compilation, where the program cannot be run (you have to know in advance that the test program will be run and what its result will be), so we want to avoid it whenever possible. In particular, this caused https://gitlab.freedesktop.org/dbus/dbus/-/jobs/44508 and https://gitlab.freedesktop.org/dbus/dbus/-/jobs/44510 to fail.
While fixing that, I noticed that the CMake build system uses _DBUS_VA_COPY_ASSIGN to implement va_copy() whenever no va_copy() or __va_copy() is available, ignoring the result of the check for DBUS_VA_COPY_AS_ARRAY. Restrict this behaviour to be specific to MSVC.https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/6dbus-launch: Fix unused variable warning when libX11 not present2018-10-18T17:24:57ZSimon McVittiedbus-launch: Fix unused variable warning when libX11 not presentCloses: https://gitlab.freedesktop.org/dbus/dbus/issues/228
Signed-off-by: Simon McVittie <smcv@collabora.com>
---
Previously part of !1.Closes: https://gitlab.freedesktop.org/dbus/dbus/issues/228
Signed-off-by: Simon McVittie <smcv@collabora.com>
---
Previously part of !1.