This file was added by an employee of ubuntu.com, which
is owned by Canonical Ltd, and they use the license
mentioned.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Other files added by the same author use the same license,
so it can also be used for this file.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
This file was added by a member of the KDE organisation.
Other files added by members of this organization use the
license mentioned.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
This fixes the following warning when running reuse:
"PendingDeprecationWarning: '.reuse/dep5' is deprecated.
You are recommended to instead use REUSE.toml"
Makes the meson config match what the autotools config used to do.
v2: include changes suggested by @smcv to allow disabling if desired
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Instead of hardcoding these as always needed, test to see, since
they're not needed on Solaris 11.4, but are on older versions & illumos.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
dbus/dbus-pollable-set-epoll.c currently errors out if __linux__ is not
defined. Allows passing -Depoll=enabled to override.
Based on patch by Jonathan Perkin for pkgsrc on illumos:
https://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/sysutils/dbus/patches/patch-meson.build?rev=1.2
but modified to only change default of 'auto' and check for all non-Linux OSes.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Checking the uid of the user seat also works if elogind is used. Add
this as an option to the build and make it mutually exclusive with
enabling systemd.
Fix an off by one error which could produce a tv_nsec value of
1'000'000'000. The valid tv_nsec range is [0, 999,999,999], see
https://en.cppreference.com/w/c/chrono/timespec for reference.
Passing a timespec with a tv_nsec value of 1'000'000'000 to
pthread_cond_timedwait has been observed to cause it to return an error
code which in turn makes the DBUS library abort the application when
compiled with asserts enabled (by PTHREAD_CHECK).
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/556
Reviewed-by: Simon McVittie <smcv@collabora.com>
14.2 reaches end-of-life in September, and our 14.2-based image has a
sufficiently small amount of space available that it fails to upgrade
now.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We recommend that assertions are disabled in production builds of dbus,
which means that they are "cheap" to add to development builds as
"executable documentation" for our assumptions.
Lower-level code assumes that timeouts must be either -1 to block
forever, or non-negative to block for a finite time (but possibly 0,
to poll without blocking).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we were checking for -1 as the special-cased "block forever"
value, but as noted on dbus!524 it is a programming error to call
_dbus_condvar_wait_timeout() with any negative timeout.
Throughout DBusConnection the timeout is in fact constrained to be >= -1
(non-negative to have a timeout, or exactly -1 to block forever) but
checking for non-negative is presumably no more expensive than checking
for exactly -1, so let's be a little more defensive here, to make it
more obvious that we're doing this correctly.
This is the only caller of _dbus_condvar_wait_timeout() in our codebase.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As noted in dbus!524 by source code inspection, the Unix/pthread
implementation assumes that the timeout is non-negative and does not
support a mode where it blocks forever (which we normally represent as
a negative timeout, like POSIX poll(2)).
This means that it would be a programming error if we ever call
this with a negative timeout, so put an equivalent assertion in the
platform-independent layer. We recommend that assertions are disabled in
production builds, so it's "cheap" to have a redundant assertion here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We should never allocate a DBusTimeout with a negative timeout set:
if we want to wait forever for an event to happen, that's represented
by the absence of a DBusTimeout.
This ensures that code in DBusConnection can safely assume that the
timeout retrieved from a DBusTimeout will always be in its allowed range
(-1 to INT_MAX inclusive).
I've checked that all current callers get this right.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Getting into the `if (timeout == NULL)` block means that
timeout_milliseconds == -1, so it doesn't make sense to do arithmetic on it.
Pass -1 instead of a nonsensical value in this case
