GitLab 18.2.2 introduced a security restriction that only allows
uploading artifacts to the user's own namespace.
To work around this, hardcode the artifact location to the path where
the artifacts were uploaded to in
ce0d4f998d ("ci: Fix for GitLab 18.2.2 upgrade").
This is an ugly but temporary workaround until a proper solution is in
place.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36836>
Some jobs define multiple of these to the same value; let's simply
ignore those, as they might have a legitimate reason to do it.
This wasn't a problem with skips and flakes as those can contain
duplicates, but fails (next commit) are not allowed to be defined
multiple times.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36648>
Rebuilding all the test containers for a change that only affects the
build containers is costly and unnecessary. Split the `DEBIAN_BASE_TAG`
into `DEBIAN_BUILD_BASE_TAG` and `DEBIAN_TEST_BASE_TAG` to make it
possible to rebuild only the relevant half of the containers.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36736>
Since 4095fac72b ("loader: move some common dri3 functions out
of dri3 loader") the new folder has been created, and since
950dac6e6c ("x11: Add an x11_xlib_display_is_thread_safe()
helper") it's also used by vulkan x11, so adding it to the core rules.
Fixes: 4095fac72b ("loader: move some common dri3 functions out of dri3 loader")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36705>
We can use the init-stage1 script from the Mesa build artifacts instead of
keeping a copy in the lava-trigger container and inlining it into the
LAVA job definition.
v2 (Guilherme)
* Source the `init-stage1.sh` file instead of executing it
* Avoid hardcoding the run_steps asserts, check only the core parts
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Co-authored-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36549>
Specifically, set WAYLAND_DISPLAY only once and reuse the var, don't
export it to weston itself (even though it's ignored because we
explicitly select the headless backend instead of auto), use long option
names for added clarity, and replace deprecated `--use-gl` with
`--renderer=gl`.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36485>
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Downgrade to Linux 6.14 for venus-lavapipe jobs
In Linux 6.16 (and possibly 6.15 as well), the virtio gfx device
initialization seems to have regressed, resulting in device initialization
failure.
```
deqp-runner 0.20.3
+ deqp-runner suite --suite /builds/RickXy/mesa/install/deqp-venus.toml --output /builds/RickXy/mesa/results --skips /builds/RickXy/mesa/install/all-skips.txt /builds/RickXy/mesa/install/venus-skips.txt --flakes /builds/RickXy/mesa/install/venus-flakes.txt --testlog-to-xml /deqp-tools/testlog-to-xml --fraction-start 1 --fraction 60 --jobs 16 --baseline /builds/RickXy/mesa/install/venus-fails.txt
Error: Failed to invoke dEQP for dEQP-VK.info.device:
stdout:
Writing test log into /builds/RickXy/mesa/results/dEQP-VK.info.device
dEQP Core 3299a07b86cf0b15f86d1a441e323e515b15f255 (0x3299a07b) starting..
target implementation = 'Default'
stderr:
MESA-VIRTIO: debug: one of required kernel params (4 or 9) is missing
FATAL ERROR: vk.enumeratePhysicalDevices(instance, &numDevices, nullptr): VK_ERROR_INITIALIZATION_FAILED at vkQueryUtil.cpp:83
```
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Drop the test from the fail list
It is reported to pass with Linux 6.16
```
Unexpected results:
07:33:07.167: KHR-GL46.sparse_texture2_tests.UncommittedRegionsAccess_texture_cube_map_r32i,Crash
07:33:07.167: spec@!opengl 1.1@streaming-texture-leak,UnexpectedImprovement(Pass)
```
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Update zink-avn-adl flakes list
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Add flake to zink-anv-adl skip list
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Add api@clgetdeviceinfo to Intel fails list
This api call is failing for Intel as well, like many of the other
types.
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36493>
Use the convention for Rust subprojects that was adopted by Meson 1.5.0
and newer.
Distros would prefer to avoid vendored crate sources, and instead use
local sources from e.g. /usr/share/cargo/registry. While Meson does not
support a local registry, it can be emulated with MESON_PACKAGE_CACHE_DIR.
However, because the distro might not be using the exact version of the
package, but only one that has the same semver, packagers need to add
some hacks to rewrite the wrap files. For example, in Fedora:
export MESON_PACKAGE_CACHE_DIR="%{cargo_registry}/"
# So... Meson can't actually find them without tweaks
%define inst_crate_nameversion() %(basename %{cargo_registry}/%{1}-*)
%define rewrite_wrap_file() sed -e "/source.*/d" -e "s/%{1}-.*/%{inst_crate_nameversion %{1}}/" -i subprojects/%{1}.wrap
%rewrite_wrap_file proc-macro2
%rewrite_wrap_file quote
%rewrite_wrap_file syn
%rewrite_wrap_file unicode-ident
%rewrite_wrap_file paste
Having a common convention for the name of Rust wraps makes it possible
to perform this transformation with a script without listing
the wraps one by one, and to share the script across multiple packages
(which will be useful when QEMU starts using Rust in a similar way to Mesa).
For an example of such a script, see
https://lore.kernel.org/r/20250722083507.678542-1-pbonzini@redhat.com/.
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36284>