| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
- Create Python bindings to xkbcommon.
- Create a regression test framework using pytest.
- Add regression tests for issues 90, 346, 382 and 383.
- Document how to write tests.
- CI: Create a separate job for the libxkbcommon build that share
its artifacts.
- CI: Add the tests to the keymap_tests job.
|
|
|
|
| |
Additionally, report successful tests count.
|
|
|
|
|
|
|
| |
Required to run pipelines after some infrastructure changes, see
https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/540
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
| |
A custom layout may define its own types or a user may want to
overwrite existing types. This option activates the `custom`
types file, which is user-provided.
This is a follow-up to 5ca9f8aea2876fe6926fc27f564d36eaf5ca5c8d.
|
|
|
|
|
|
| |
Some languages need to be special-cased, pycountry doesn't list them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
| |
While there is an ongoing battle between the americans (with their lack
of 'u' and overuse of 'z') and the brits (which seem to think there's
nothing wrong with a superfluous 'u' but shy away from 'z'), spelling
comparison with a 'z' just seems overly enthusiastic.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
| |
Even the xserver is now meson only and building a desktop stack without
meson is not possible anymore. So let's drop autotools for meson, which
is much easier to maintain.
|
|
|
|
| |
This should pick up the new xlstproc dependency
|
| |
|
|
|
|
| |
needed for xlstproc
|
| |
|
|
|
|
|
|
|
| |
xkbcli list parses evdev.xml and spits out YAML, let's run this here so
we can fix it before it hits users.
https://github.com/xkbcommon/libxkbcommon/issues/267
|
|
|
|
|
| |
Fixes the 404 that we see in the merge request check from time to
time.
|
|
|
|
|
|
|
| |
This lets us use the ci-fairy image instead of manually preparing the alpine
image on each run. Side-effect: we won't fall afoul of docker's pull limits.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
| |
libxkbcommon (commit 1cae25005211) now provides the output of the layout
tester format in YAML, with successful compilations on stdout and failed ones
on stderr. This makes it easy to collect the results, extract and print the
failures with yq but also parse the yaml file and leave a JUnit XML in place
that will then show up as result on a MR page.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
| |
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
xorgproto 2021.2 and later has a recognizable pattern for adding new keysyms
to XF86keysym.h based on the Linux kernel input-event-codes.h. Use this to
detect any keysyms that are present in the header file but not yet in
symbols/inet.
This is merely a gitlab CI job as we only have to do an actual update once
every few months or so. A git diff is sufficient here too, it contains all the
information we will need to understand what is missing from the updated file.
We check xorgproto master because that gives us some heads-up on what will
come. There is a minor chance that we are mapping keycodes that change before
the release but it's minor and fixable anyway.
Requires: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/23
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This layout does not exist and we will never provide it.
However, having it in the XML file means it will show up in GUI
configuration mechansism that parse the XML file directly (instead of using
libxbkcommon's libxkbregistry).
Our rulesets fall back to the file "symbols/layout", section "variant"
for any layout(variant) that's not explicitly covered. This enables users to
create a symbols/custom file with their layout and have it
available.
As there are no variants, the GUI tools will only be able to use the default
section. Commandline tools can use variants as well.
This is papering over the whole issue only, but it does provide for some
convenience. It will still require adding a file in /usr/share in most cases,
but since we do not provide this file, it will be safe from being overwritten.
Fixes #257
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The various <I123> keycodes in keycodes/evdev simply match the kernel
defines + offset 8. There is no need to maintain these manually, let's
generate them instead.
Keycodes update rarely and irregularly (on average maybe every second kernel
release) so there's no need to integrate this into the build itself, let's add
it to our CI instead.
The script here uses python-libevdev which has a list of the various key
codes and their names (compile-time built-in in libevdev itself so it's
advisable that a recent libevdev is used). The script is hooked up to a custom
job that will fail if there are key codes with a #define in the kernel that
are not listed in our evdev file. We allow that job to fail, it's not that
urgent to block any merge requests.
Changes to v1, see commit 5dc9b48c and its revert 8fa3b314:
- Parse the template for existing defines and alias those keys. e.g.
alias <I121> = <MUTE>;
- Kernel v5.10 keycodes are now included in the file
- The script defaults to the correct template/keycode file, no commandline
arguments needed for the default run.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tool prints to stderr for failures, stdout for success. So far we only
collected stdout but not stderr. For undefined keysyms we usually get lots of
failed keymaps and the log exceeds the gitlab limits.
Let's collect stdout and stderr as separate files instead, and save it as
artifacts on failure. We don't really care about the keymaps on success anyway
- no-one will look through gigabytes of keymaps in the hope of finding
something wrong.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the generated keys overwrote existing keys, causing warnings
and nonfunctional keys. For example:
xkbcommon: WARNING: Multiple names for keycode 121; Using <I121>, ignoring <MUTE>
Revert this commit, we're too close to a release and it's better to wait until
the next one to give this approach more time to settle.
Fixes #247
This reverts commit 5dc9b48c9b31de9f9780887a79ded3b1e52591d9.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
| |
This is a massive file but it is very repetitive, getting a good compression
from xz down from several GB into a few MB.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
| |
The keymap test produces a massive file, we don't need to pass this around to
later stages.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The various <I123> keycodes in keycodes/evdev simply match the kernel
defines + offset 8. There is no need to maintain these manually, let's
generate them instead.
Keycodes update rarely and irregularly (on average maybe every second kernel
release) so there's no need to integrate this into the build itself, let's add
it to our CI instead.
The script here uses python-libevdev which has a list of the various key
codes and their names (compile-time built-in in libevdev itself so it's
advisable that a recent libevdev is used). The script is hooked up to a custom
job that will fail if there are key codes with a #define in the kernel that
are not listed in our evdev file. We allow that job to fail, it's not that
urgent to prevent any other pipelines.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
| |
We have jobs that rely on those artifacts and 20 min is too short. Where a
dependent job fails, the artifact is often gone before we can hit retry. So
let's bump this to something definitely long enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
|
| |
Generate an Arch container and run our builds off that. This gives us a few
advantages:
- the container image is always the same until twe change the tag, so we
can reproduce any build issues easily
- we don't need to pull from docker hub unless we rebuild the images, so we're
less affected by the upcoming ratelimits
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
| |
Together with a CI job that makes sure we can build with meson from the make
dist output.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
| |
The initial check happens too quickly so it's quite hard to file an MR before
the MR check job runs in the CI. Delay this a bit by moving it to the last
stage.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libxkbcommon's parser has an optimization where it stops parsing a file when
the required keymap is found. The result of that was that the syntax error
fixed in !83 didn't get detected - all tested layouts where before that
erroneous line.
There's only one xkb_symbols map thats below that line but that one is
referenced in evdev.extras.xml, not evdev.xml. So let's update our CI to test
for that too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fdo ci-templates provide a tool called ci-fairy which can check
merge requests as part of a pipeline. In this case we check for the checkbox
set to allow collaboration (i.e. the one that allows a maintainer to rebase a
merge request). Where it is missing, the CI job fails (though it's not fatal).
ci-fairy uses FDO_UPSTREAM_REPO to get the upstream repository, see the docs
for more details
https://freedesktop.pages.freedesktop.org/ci-templates/ci-fairy.html#checking-merge-requests
Output is both on stdout and as junit file which is presented nicely by
gitlab. Provided anyone reads it...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
| |
Using pytest because it does a lot of the setup/tracing stuff for us. The test
checks all symbols files and generates a list of tuples (layout, variant)
from the files. That's then used in a generic-enough keymap to be fed to
xkbcomp. Where xkbcomp fails we fail the test (and pytest will collect
stdout/stderr/etc.) for us.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This produces virtually the same installed tree as the autotools builds with
the following exceptions:
- rules symlinks is no longer supported. This option is 16y old and likely
hasn't been used in the last decade or so
- the xkeyboard-config.pc file uses expanded paths now, e.g.
xkb_base=/usr/share/X11/xkb
vs autotools'
xkb_base=${datarootdir}/X11/xkb
The values are the same for both so this is not a functional change.
- substitutions in the man page are hardcoded since we can't use the m4
XORG_MACROS. This appears to only matter for the miscmansuffix and there
only for solaris up to including 11.3. so... meh?
- the .mo files differ, but it's hard to say why since they're generated
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
| |
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
| |
Few people work on gitlab CI often enough to have all this paged in, let's add
some comments to make it more obvious.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
| |
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should detect syntax errors and any other parsing issues.
We add a make install stage and pass the installed files through as artifacts
to the next stage. Then we fetch libxkbcommon from git and run the magic
tester tool (which tries to parse every layout/variant/option combination).
A single test run will take quite a while, on my system here that tool takes
about 14 minutes so expect the test suite to be the same.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
| |
Let's use CI_PROJECT_DIR which resolves to the root of the checked-out git
directory, i.e. the $PWD for the scripts we use. We can't really use anything
else as install dir because if we want to cache the artifacts (future patch)
they have to be within this directory somewhere.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Easier to read and comprehend, but also safer to use because it's harder to
mix up the headers.
Previously, the HDR file would have the list of section headers and had to be
called in the right order using HDR in the file list in the Makefile.am.
Let's move the section headers to the files themselves where it's more obvious
if they're ever wrong and make the script include them as required.
The include order is kept as-is for now so that the final evdev/base rules
files are identical.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|