While running under valgrind, it may take over 30 cycles in the loop to
wait for a running GTestDBus instance. So we have to increase the
waiting time.
Waiting a whole second will change the signal/noise ratio and will only
fail, if there's really a problem with the GTestDBus usage.
And as we're sleeping 500us in every loop, we usually get a super fast
response, too.
-j introduces race conditions, which lets the find -name ... -delete
commands fail, because those can't find specific files, which got
removed in the meantime.
The xctx color field is a full duplicate of the settings logic.
Only logic included in xctx color fields, are the frame colors, which
fall back to the global frame setting. So, this required to handle it
directly in settings.c
We haven't been using libdbus for a while so there is no use to
linking it with the build.
Unfortunately there is still a dependency on it as we depend on the dbus
package to tell us where to put our service files.
Alpine is running with Musl libc and musl uses extended precision
doubles, while valgrind can't handle extended precision,
2.3 == atof("2.3") won't be true under valgrind.
And therefore the option retrieval methods *_get_double would fail.
Also we have to increase the test verbosity, as `SKIPm` doesn't print
the message when skipping the tests.
See: silentbicycle/greatest#85
These aren't used anymore. Any notification which gets moved from
waiting to displayed, will have set the start field with the current
monotonic time.
So testing start == 0 won't ever succeed in
queues_notification_is_finished, as the tested notification is contained
in the displayed queue. So the start field never will be 0.
Also there's no semantics for start being 0 in dunst actually
implemented.
