The SVGs must not be part of any stable API, there is too much behavior
implied that we cannot/do not specify. So it's perfectly likely that a future
change in the SVGs or rendering libraries breaks things in some detail. But
then we cannot update the SVGs without risking breaking other clients that
rely on the current behavior.
Besides: we only have one theme, called "gnome" because a push
towards having SVGs for other themes never happened.
And that theme isn't gnome-specific, it merely looks GNOMEy. The theme is very
much piper-specific in that it requires certain elements that piper cares
about. Currently anyway, if we make this part of our API, piper cannot change
that behavior ever without breaking others.
So let's drop SVG handling completely and rely on the clients to sort it out
for themselves.
For now the SVGs are left in the tree to make it easier to copy to Piper. Once
that's done, we will remove those too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Scan-build is at the point where it gives us too many false positives to be
reliable and they're not easily fixable other than sprinkling
"ignore_clang_sa_mem_leak" comments all over the source.
This caused us to drop F29 from the CI earlier, see 1225f421c0, but
really we just shouldn't use something that's so unreliable as part of our CI.
The main issue continues to be the use of __attribute__((cleanup)) but others
give us false positives too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This reverts commit 874d7eccb8.
Looks like 18.10 fails at every pipeline build, so better
punting this for later.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Some change in F29 breaks the CI runs, so lets switch back to what we had
before so we can merge patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
https://bugs.llvm.org/show_bug.cgi?id=3888
clang analyzer doesn't know how to handle __attribute__(cleanup()).
There are only 2 warnings raised because the analyzer only look at the
current compilation unit for checking the malloc call. So only those
2 are detected by clang and then marked as memory leak.
This also means our current continuous integration doesn't check for
memory leaks.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
And use it to create ratabg-command.py
Benefits are that we bypass ratbagd, meaning we can attach gdb or run
valgrind on the tools themselves.
Problem is the python wrapper doesn't clean up after itself, and so
running valgrind is moot
Fixes#274
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We are reusing a lot the fedora container, but we need to always download
and install the same set of packages. Store them in the workspace to
speed up the tests.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Note that the push requires a specific private key in the libratbag
circle CI organization, meaning that only the master branch of libratbag
will be allowed to push to the doc repo.
Note also that only the master branch will trigger the request:
- any PR will not trigger the request
- any push on the master branch of a personal repo will fail while
attempting to write the docs, if the repo is setup to use circleCI too.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Better than the markdown we were using before, even though we're currently
(ab)using the js/c++ domains for the structure. There is no DBus domain in
sphinx yet.
The main motivation was to get the enums into the documentation since they are
exported ABI.
Generating the documentation is quirky - we use doxygen to extract the
comments from the C header file and then use XSLT to convert to .rst which
sphinx can use. Still better than having to maintain even more copies of the
enums.
Since this is only of interest for maintainers that need to upload the
documentation, it is turned off by default.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Checks for the three layers we need and that any buttons in the files are
consecutive and have the right layers
Fixes#196
Co-authored-by: Jente Hidskes <hjdskes@gmail.com>
The hwdb was a quick and easy way to add entries for new devices but we need
more and more info about the various types of devices. It's better to move
this to a proper database.
Side-effect: this also gives us an easy way to point to the list of devices
supported and makes checking for e.g. missing svgs easier.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Otherwise we get build errors when rawhide is broken, like today. Not worth
chasing that moving target.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous approach had no effect, it wasn't doing things correctly.
Add a proper valgrind setup, run with:
mesontest --setup=valgrind
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
[fixed rebase conflict]
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It doesn't cost much to actually install the files, so we can check
where they are installed.
Also add mesonconf before building so we can see in the logs
the various configure environment.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Circle CI uses docker, so nothing prevents us from running several
tests in parallel for different distributions. Ideally, we should also
be able to test the install and be sure we can talk to ratbagd
with the dbus activation on those various distributions.
This version runs both Fedora rawhide and Ubuntu 17.04 at the same
time.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Semaphore CI is still using Ubuntu 14.04, and the shipped systemd version
is just too old.
OTOH, Circle CI 2.0 (still beta as of today) allows to use any docker
image as a base for running the tests. Meaning that we can have a fedora
rawhide image as a base and we do not have to handle the update of systemd
meson and others.
Ship a basic circle.yml for Circle CI to run our tests and add the badge
in the README.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
