DES isn't considered secure anymore for long time now, more and more platforms
dropping DES from their RPC implementations, and even the one where it came
from (Solaris) disabled it for a decade now. We have much better alternatives
(eg. passing creds via Unix socket for local connections, ssh tunneling,
MIT-MAGIC-COOKIE-1, ...), so it's unlikely anybody still really relying on it.
Therefore, sweep it out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1453>
This script runs with -e, so if the timeout command returns a non-0
exit status (meaning the while loop timed out), the script exits
immediately as well.
This would leave weston running in the background, which resulted in
meson waiting for weston to terminate until hitting meson's own timeout.
Instead, explicitly kill weston whenever the shell exits. This results
in meson recording the test as failed immediately.
As a bonus, we can drop the special handling around run-piglit.sh.
v2:
* Use trap (José Expósito)
v3:
* Explicitly use bash, and document a bashism we rely on
(Olivier Fourdan)
When running the xserver:xwayland / XTS test in an environment where
an X server is running for :0, Xwayland fails to start with error:
(EE)
Fatal server error:
(EE) Server is already active for display 0
If this server is no longer running, remove /tmp/.X0-lock
and start again.
(EE)
And the `timeout` command fails instead of waiting for Weston to
initialize.
Add the `-displayfd` parameter to Xwayland to avoid this issue.
The `-displayfd` parameter lets Xwayland pick an unused display number,
avoiding the start up error when an X server is already active for :0,
the default display number.
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: José Expósito <jexposit@redhat.com>
When neither `wayland-info` nor `weston-info` are installed, the
`xwayland-piglit.sh` script will wait indefinitely for the compositor
to start.
Use `Xwayland -pogo` instead to wait until weston is initialized.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1536
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: José Expósito <jexposit@redhat.com>
weston-info has been deprecated for quite some time, whereas wayland-info
may not be available yet.
So we use either, depending on what's actually available.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The xwayland-piglit.sh script spawns weston, runs run-piglit.sh and
finally kills weston.
However, this whole script is running with “-e” meaning that any error
will cause the script to exit immediately.
As a result, if run-piglit.sh exits with a non-zero code such as 77 for
skipping the test, the script will exit prematurely leaving weston
running, and meson will simply wait until the timeout kicks in, and
fail eventually instead of skipping the test as it should.
Fix this by removing the option to exit immediately prior to spawn the
script run-piglit.sh.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1204
Suggested-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
It runs XTS via piglit on (non-rootless) Xwayland on weston using the
headless backend.
Xwayland might use glamor if enabled in the build, but we're making sure
it uses software rendering.
v2:
* Use weston-info to wait for weston to be ready, instead of just a
fixed sleep. (Martin Peres)
v3:
* Build wayland 1.18 & weston 9.0 locally, since the packages in Debian
buster are too old for current Xwayland.
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Trying to build fat binaries for multiple arches tickles a bug [1] in
the framework detector in meson 0.50. Workaround this by not bothering
building for x86, which is probably no great loss :S
https://github.com/mesonbuild/meson/issues/5290
This gets us parallelism between rendercheck tests at the cost of
spinning up more Xvfbs, and nicer logging of the tests that are run.
Signed-off-by: Eric Anholt <eric@anholt.net>
The latter use Python 2 and break with any non-ASCII characters in the
environment, the former uses Python 3 and works fine in that case.
Reviewed-by: Eric Anholt <eric@anholt.net>
This removes the dependency on an externally generated docker image, and
should make it easier to update the docker image or make other changes
related to it.
This is based on Debian testing, because I'm most familiar with Debian.
But it should be easy to base it on another distro.
v2:
* Use kaniko instead of docker-in-docker for image generation, so it can
also work in unprivileged runners.
* Drop piglit.conf & tetexec.cfg overrides, just make sure the files in
the image work.
Fold build-travis-deps.sh into .gitlab-ci.yml.
Preparation for the next change, which would break the Travis Linux
build.
Reviewed-by: Eric Anholt <eric@anholt.net>
Gitlab very kindly exposes the details of the git commit message (among
much else) in the environment. Unfortunately, piglit tries to handle the
environment in non-UTF8-safe ways, which means if the top-of-tree commit
mentions non-ASCII characters (say, in the author's name) then all the
tests fail and so does the pipeline.
Fortunately none of those variables are things our piglit invocation
needs. Since I've failed to rebuild the docker image as yet, just clear
the likely variables from the environment before running piglit.
This-makes-me: ☹
The image now has enough mojo to run xts, hooray!
Note there's a couple of ugly bits in here. The piglit config fragment
and stock tetexec.cfg reflect missing features from the test suites
(using an installed copy of xts, figuring out the xserver test matrix at
runtime, etc.), I'll be happy to remove them once the tests are fixed.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Make appveyor ignore builds for /travis.*/ and vice versa. If you're
only testing a Windows change, building for OSX and Linux too is a bit
rude.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Install and use xorgproto, and build with optimization as clang has
warnings that only work above -O0. Also expand the build matrix for both
Xcode 8.3 and 9.2. Both images are OSX 10.12 at the moment so this is
really just a way to test with clang 8 vs 9.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Stretch's Mesa is too far behind, and building Mesa to build xserver is
not the sort of problem we're trying to solve here. But our Travis
scripts run inside a docker image, and that image can be whatever, so
since I have to keep rawhide building anyway let's switch to that for
now. The dockerfile can be found at:
https://github.com/nwnk/xserver-travis
The $DISTRO part of the change is foreshadowing for the day we readd a
(probably sid-based) debian image; patches for other environments are
welcome.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The Xvfb tests are passing and Xephyr-glamor is failing for me, but it
fails identically on autotools. It's disabled on Travis for now
because the >10 minutes of silence during testing times out the entire
build.
v2: Fix the disable on travis.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This currently does a meson build using a docker image I've prepared.
The Dockerfile source is at:
https://github.com/anholt/xserver-travis
Docker proved to be necessary to cut the build time per Travis push.
If some day we end up using meson in more of the X stack, we may be
able to move more dependencies out of the docker image and into the CI
build (putting the I in CI). Until then, we'll have to do docker
image rebuilds when dependencies are added/updated.
To enable Travis CI on your github repository, see the first two steps
of the docs at:
https://docs.travis-ci.com/user/getting-started/
Once you do that, pushing branches to your github repo will trigger
builds, which will send you email if they fail. Current build status
can be veiewed your account on travis-ci.org:
https://travis-ci.org/anholt/xserver
Fixes make check with out-of-tree builds.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Once I introduced a second X server being tested, I found that startx
hit races in choosing a display.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
I was confused by the behavior I'd written before. keithp and
mattst88 responded with shock that I would have made it so surprising,
as well.
v2: Point to index.html instead of problems.html, which won't exist if
we had no problems.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
The "dmesg-fail" line was matching our "fail" regex, so if you didn't
have those we would ignore fails.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
By default the tests will be skipped. However, if you set XTEST_DIR
to the repo of a built X Test Suite and PIGLIT_DIR to a piglit repo
(no build necessary), make check will run piglit's xts-render tests
against Xvfb.
We could run more of XTS5, but I haven't spent the time identifying
what additional subset would be worth running, since much of it is
only really testing the client libraries. We want to make sure that
we keep the runtime down, and this subset of the test suite took 92
seconds according to piglit.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Enrico Weigelt, metux IT consult
Konstantin
Michel Dänzer
José Expósito
Olivier Fourdan
Povilas Kanapickas
Jon Turney
Eric Anholt
Michel Dänzer
Michel Daenzer
Adam Jackson