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.
When using a format with a trailing % character, dunst ends in an
endless loop, searching for a % char, while pointing exactly with the
haystack on the % character.
Increasing the substring pointer will shift the pointer forwards onto
the actual NULL character and stop the loop.
In previous releases when a replace request came in with an id that
doesn't exist we created a new notification with it anyway.
This is used by some to imitate the behaviour of `stack_tag` and while
not recommended (as it will break if another notification gets assigned
that id) we want to avoid such subtle breakages without consideration.
This bug was introduced in d879d70da060ea78fe735d62249a0afdf3e61bc8.
To assert static objects, we either have to add a method into the
object under test itself and recompile on a test run with the activated test
method (but also recompile after tests, so that method is gone on
release builds).
Alternatively we can include the whole .c file in our test
infrastructure and save the object in the test directory. So there's no
necessity to clean it up prior to a release build and it's contained
away.
This requires, that the test folder isn't excluded in coveralls.
The coveralls service is a great webservice, but like the testsuite it's
better to have an alternative, which makes it possible to process it
locally. This is faster and doesn't even require a full push iteration.
gcovr is easy to get:
pip install gcovr
make test-coverage-report
Add the necessary compiler flags to the Makefile to actually make
coverage reports available locally, too.
The coverage files have to get cleaned every time before the test gets
run. Otherwise, it would sum up the coverage over multiple test runs.
