F40 now ships v0.121 which again breaks something in the relearn theme
so let's lock our version here to one we know works and move on with
life. I can't be bothered to relearn hugo and themes every few months
just for a single static website.
And drop the job to test the minimum meson version in the process. F39
ships with python 3.12 which causes this error with meson 0.56.0
proto/meson.build:17:0: ERROR: <ExternalProgram 'python3' -> ['/usr/bin/python3']> is not a valid python or it is missing setuptools
We could put the effort into setting up the CI to fix this, but we
won't.
The pages job is only run once we push to main, so any issues with the
documentation build won't be picked up until it's too late. Split those
up and build the doc in a separate job, the pages job simply takes the
artifacts from that job and publishes them.
The ABI job git cloned from upstream and then compared HEAD with the
last ABI break. Problem though: the HEAD was origin/main, not the actual
HEAD from the merge request.
Fix this by adding upstream as a remote and fetching from it. And while
we're there update to the last ABI break commit sha and move the
abicheck bits into before_script.
Note that the remote has the CI job ID appended, this avoids conflicts
when the git repo is re-used betweenn jobs and the upstream remote
already exists.
Since meson is installed from pip, we'll use the latest stable version
when we build an image. Add an extra job with the fixed minimum version
so we ensure we actually build with that version.
The protocol name on an interface is a fixed string that is part of
the ABI since it's used in a few messages (e.g.
ei_handshake.interface_version). To avoid typos, let's expose that
string in the scanner and #define it in the generated sources.
Since we want the generated documentation to be useful on-disk, drop the
baseURL and switch to relativeURLs = true for hugo.
This is arguably a bit nasty in that it git clones the theme into the
build directory. But oh well...
Embarassingly, only the valgrind test would actually run tests because
it was the only one with a non-null MESON_TEST_ARGS. Let's fix this by
explicitly telling the build script to run the tests.
Because we currently only run the test suite in valgrind, we skip the
python test suite there (we don't want to valgrind python itself, too
messy).
Fix this by specifically excluding the python test suite and having a
separate job that just runs that suite instead.
And because the protocol test suite needs the directory to the
eis-demo-server and isn't smart enough to split spaces correctly, let's
change the builddir to just that.
This tests the protocol layer which is hard to test using libei/libeis.
Similar to the generated C bindings we compile a eiproto.py file that is
then used in the test to talk protocol directly to the eis-demo-server
that we start up.
By sending the specific messages and checking things happen as we expect
on the socket we can verify that the EIS implementation is correct (and
robust enough).
In theory this could also be used to test some other binary with an EIS
implementation and the scaffolding is there to set LIBEI_TEST_SERVER to
that binary. Wether this works is untested though...
The venv is needed now because black now requires a newer 'packaging'
and fails to installed with:
ERROR: Cannot uninstall 'packaging'. It is a distutils installed
project and thus we cannot accurately determine which files belong to
it which would lead to only a partial uninstall.
So let's use a venv and while we're doing this switch to use the
ci-fairy image so we don't need to worry about docker limits.
We don't have scheduled rebuilds so the containers build need to hang
around since they're almost certainly in use. Container expiry is
handled site-wide now anyway.
libei used to have direct portal support code (see the git history) but:
- that code was a custom proposed portal that never went anywhere
- libei has slowly changed to be more an input event transport layer since
it is now also used sending events *to* a libei context
- a number of libei users will never need the DBus code, either because they
don't want it or because they talk Dbus themselves na ddon't need this
abstraction.
Luckily, it's quite easy to move this into a separate library with a
simple API that does, effectively, the same trick as the old portal backend.
This API is aiming to be as simple as possible because the tools that
require anything more complex should talk to DBus directly.
An example tool that uses the API to retrieve an EIS fd over the
RemoteDesktop portal is included in this patch.
"Öffis" is a German word meaning public transport. It also sounds like the
French Œuf, the word for egg.
Co-authored-by: Olivier Fourdan <ofourdan@redhat.com>
The original idea here was that we would have an EmulatedInput portal
that allows the application to connect directly to the EIS
implementation to exchange input events - instead of ping-ponging DBus
events through the xdg-desktop-portal as the RemoteDesktop portal
requires.
This is no longer accurate, there are suggested PRs open to add
RemoteDesktop.ConnectToEIS to achieve the same through the existing
RemoteDesktop interface [1] and to add a new InputCapture portal
to allow for events to be sent to a libei receiver context [2].
The example EmulatedInput portal is thus superfluous and can be removed
from here.
We could switch the ei_setup_backend_portal() code to use RemoteDesktop
or InputCapture, depending on the context type, the utility of this is
questionable. Interaction with portals is complex, one needs to
implement the Session/Request interfaces correctly and in the case of
InputCapture also handle the complex zones/pointer barrier setup.
libportal does some of this (or it will, anyway) so it's more useful for
an application to use libportal and then just pass the received fd to
libei.
If there is a future need for this to be handled as part of libei, we
can (re)implement this, but for now it's best to just purge all of this.
[1] https://github.com/flatpak/xdg-desktop-portal/pull/762
[2] https://github.com/flatpak/xdg-desktop-portal/pull/714
I'm starting to question this, there are plenty of large projects
where this isn't a requirement (GNOME, systemd, ...) and libei doesn't
exactly contain sophisticated technology that needs a DCO.
Plus, it's a constant source of confusion for new contributors.
Let's drop the requirement.
Most of the time we don't pay attention to the details in the actual
jobs, them passing is good enough. So let's have at least one job with
-Werror that fails if our CI has warnings we don't have locally.
Allowed to fail because we don't want to be beholden to compiler changes
(though having this fail for a long period makes the job less useful
again).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
