fix(mesa): libOSMesa is obsolete (#4763)

* fix: Obsolete libOSMesa, add compat package

* feat: A lil thank you

* feat: Epoch on compat package so both are the same

Signed-off-by: Gilver <rockgrub@disroot.org>

* Update mesa.spec

---------

Signed-off-by: Gilver <rockgrub@disroot.org>
This commit is contained in:
Gilver
2025-05-11 21:17:50 -05:00
committed by GitHub
parent a6210e60e9
commit 68ca317303
5 changed files with 586 additions and 4 deletions
@@ -0,0 +1,117 @@
Subject: RE: Question about Mesa MLAA license
From: Jorge Jimenez <iryoku@gmail.com>
Date: 01/08/2013 12:50 PM
To: Tom Callaway <tcallawa@redhat.com>
CC: "jorge@iryoku.com" <jorge@iryoku.com>
Yes to both questions.
Thanks,
Jorge
From: Tom Callaway <tcallawa@redhat.com>
Sent: January 8, 2013 6:49 PM
To: Jorge Jimenez <iryoku@gmail.com>
CC: jorge@iryoku.com
Subject: Re: Question about Mesa MLAA license
On 01/08/2013 12:39 PM, Jorge Jimenez wrote:
> Hi Tom,
>
> What we meant with that is that we made an exception for clause 2.
> Instead of clause 2, in the case of the Mesa project, you have to name
> the technique Jimenez's MLAA in the config options of Mesa. We did that
> just to allow them to solve license issues. This exception should be for
> the Mesa project, and any project using Mesa, like Fedora.
>
> We want to widespread usage of our MLAA, so we want to avoid any kind of
> license complications. Hope current one is good for Fedora, if not
> please tell, and we'll see what we can do!
Okay, a few more questions:
* If Fedora decides to simply reproduce the quoted statement:
"Uses Jimenez's MLAA. Copyright (C) 2010 by Jorge Jimenez, Belen Masia,
Jose I. Echevarria, Fernando Navarro and Diego Gutierrez."
Specifically, if this is done as part of documentation included with
Mesa, is that sufficient to meet clause 2 even if the Mesa config option
is not set as described in your exception?
* Currently, the Mesa config option for MLAA says: "Morphological
anti-aliasing based on Jimenez\' MLAA. 0 to disable, 8 for default
quality". Is this in compliance with your exception?
Thanks again,
~tom
==
Fedora Project
Subject: RE: Question about Mesa MLAA license
From: Jorge Jimenez <iryoku@gmail.com>
Date: 01/08/2013 12:39 PM
To: "jorge@iryoku.com" <jorge@iryoku.com>, Tom Callaway <tcallawa@redhat.com>
Hi Tom,
What we meant with that is that we made an exception for clause 2.
Instead of clause 2, in the case of the Mesa project, you have to name
the technique Jimenez's MLAA in the config options of Mesa. We did that
just to allow them to solve license issues. This exception should be for
the Mesa project, and any project using Mesa, like Fedora.
We want to widespread usage of our MLAA, so we want to avoid any kind of
license complications. Hope current one is good for Fedora, if not
please tell, and we'll see what we can do!
Cheers,
Jorge
From: Tom Callaway <tcallawa@redhat.com>
Sent: January 8, 2013 6:30 PM
To: jorge@iryoku.com
Subject: Question about Mesa MLAA license
Jorge,
Thanks for all of your fantastic graphics work! I have been auditing
Fedora (a popular distribution of Linux) for license compliance and I
came across your MLAA code in Mesa.
The license says:
* 2. Redistributions in binary form must reproduce the following
statement:
*
* "Uses Jimenez's MLAA. Copyright (C) 2010 by Jorge Jimenez, Belen Masia,
* Jose I. Echevarria, Fernando Navarro and Diego Gutierrez."
*
* Only for use in the Mesa project, this point 2 is filled by naming the
* technique Jimenez's MLAA in the Mesa config options.
That wording is unclear. When you say "Only for use in the Mesa
project...", it seems like you could either be saying:
- This code may only be used as part of Mesa.
OR
- In Mesa, you can comply with clause 2 by simply selecting "Jimenez's
MLAA" in the Mesa config options.
*****
If the first item is true, then we may have to remove the MLAA code from
Fedora's copy of Mesa. However, looking at the license on your SMAA
code, I do not believe it to be the case. Please let me know either way!
Thanks in advance,
Tom Callaway
Fedora Legal
==
Fedora Project
+10
View File
@@ -0,0 +1,10 @@
project pkg {
arches = ["x86_64", "aarch64", "i386"]
rpm {
spec = "mesa-compat.spec"
}
labels {
mock = 1
subrepo = "mesa"
}
}
+329
View File
@@ -0,0 +1,329 @@
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Antheas Kapenekakis <git@antheas.dev>
Date: Sat, 15 Mar 2025 16:39:08 +0100
Subject: [BEGIN] SteamOS Changes
--
2.49.0
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Date: Fri, 14 Jan 2022 15:58:45 +0100
Subject: STEAMOS: radv: min image count override for FH5
Otherwise in combination with the vblank time reservation in
gamescope the game could get stuck in low power states.
---
src/util/00-radv-defaults.conf | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/util/00-radv-defaults.conf b/src/util/00-radv-defaults.conf
index 72f3438b39d..02d7ada7ad9 100644
--- a/src/util/00-radv-defaults.conf
+++ b/src/util/00-radv-defaults.conf
@@ -221,5 +221,9 @@ Application bugs worked around in this file:
<application name="Total War: WARHAMMER III" application_name_match="TotalWarhammer3">
<option name="radv_disable_depth_storage" value="true"/>
</application>
+
+ <application name="Forza Horizon 5" application_name_match="ForzaHorizon5.exe">
+ <option name="vk_x11_override_min_image_count" value="4" />
+ </application>
</device>
</driconf>
--
2.49.0
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Date: Thu, 22 Feb 2024 22:32:45 +0100
Subject: STEAMOS: Dynamic swapchain override for gamescope limiter for DRI3
only
The original patch (from Bas) contained WSI VK support too but it's
been removed because the Gamescope WSI layer already handles that.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
---
.../frontends/dri/loader_dri3_helper.c | 42 ++++++++++++++++++-
.../frontends/dri/loader_dri3_helper.h | 1 +
2 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/src/gallium/frontends/dri/loader_dri3_helper.c b/src/gallium/frontends/dri/loader_dri3_helper.c
index 9e4ca3f5707..7863623f8de 100644
--- a/src/gallium/frontends/dri/loader_dri3_helper.c
+++ b/src/gallium/frontends/dri/loader_dri3_helper.c
@@ -297,6 +297,30 @@ dri3_update_max_num_back(struct loader_dri3_drawable *draw)
}
}
+static unsigned
+gamescope_swapchain_override()
+{
+ const char *path = getenv("GAMESCOPE_LIMITER_FILE");
+ if (!path)
+ return 0;
+
+ static simple_mtx_t mtx = SIMPLE_MTX_INITIALIZER;
+ static int fd = -1;
+
+ simple_mtx_lock(&mtx);
+ if (fd < 0) {
+ fd = open(path, O_RDONLY);
+ }
+ simple_mtx_unlock(&mtx);
+
+ if (fd < 0)
+ return 0;
+
+ uint32_t override_value = 0;
+ pread(fd, &override_value, sizeof(override_value), 0);
+ return override_value;
+}
+
void
loader_dri3_set_swap_interval(struct loader_dri3_drawable *draw, int interval)
{
@@ -311,10 +335,12 @@ loader_dri3_set_swap_interval(struct loader_dri3_drawable *draw, int interval)
* PS. changing from value A to B and A < B won't cause swap out of order but
* may still gets wrong target_msc value at the beginning.
*/
- if (draw->swap_interval != interval)
+ if (draw->orig_swap_interval != interval)
loader_dri3_swapbuffer_barrier(draw);
- draw->swap_interval = interval;
+ draw->orig_swap_interval = interval;
+ if (gamescope_swapchain_override() != 1)
+ draw->swap_interval = interval;
}
static void
@@ -443,6 +469,12 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
draw->swap_interval = dri_get_initial_swap_interval(draw->dri_screen_render_gpu);
+ draw->orig_swap_interval = draw->swap_interval;
+
+ unsigned gamescope_override = gamescope_swapchain_override();
+ if (gamescope_override == 1)
+ draw->swap_interval = 1;
+
dri3_update_max_num_back(draw);
/* Create a new drawable */
@@ -1087,6 +1119,12 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable *draw,
if (draw->type == LOADER_DRI3_DRAWABLE_WINDOW) {
dri3_fence_reset(draw->conn, back);
+ unsigned gamescope_override = gamescope_swapchain_override();
+ if (gamescope_override == 1)
+ draw->swap_interval = 1;
+ else
+ draw->swap_interval = draw->orig_swap_interval;
+
/* Compute when we want the frame shown by taking the last known
* successful MSC and adding in a swap interval for each outstanding swap
* request. target_msc=divisor=remainder=0 means "Use glXSwapBuffers()
diff --git a/src/gallium/frontends/dri/loader_dri3_helper.h b/src/gallium/frontends/dri/loader_dri3_helper.h
index 9061e9755e2..6cc64be298a 100644
--- a/src/gallium/frontends/dri/loader_dri3_helper.h
+++ b/src/gallium/frontends/dri/loader_dri3_helper.h
@@ -170,6 +170,7 @@ struct loader_dri3_drawable {
bool block_on_depleted_buffers;
bool queries_buffer_age;
int swap_interval;
+ int orig_swap_interval;
const struct loader_dri3_vtable *vtable;
--
2.49.0
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Date: Mon, 24 Feb 2025 17:48:21 +0100
Subject: radv: stop computing the UUID using the physical device cache key
Otherwise, the UUID changes for games that have shader-based drirc
workarounds and this breaks precompiled shaders on SteamDeck.
Instead, use this pdev cache key to compute the logical device hash
which is common to all pipelines.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
---
src/amd/vulkan/radv_device.c | 6 +++++-
src/amd/vulkan/radv_physical_device.c | 1 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 2de839e5d6d..da732ae503e 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -858,6 +858,7 @@ radv_device_init_cache_key(struct radv_device *device)
const struct radv_physical_device *pdev = radv_device_physical(device);
const struct radv_instance *instance = radv_physical_device_instance(pdev);
struct radv_device_cache_key *key = &device->cache_key;
+ struct mesa_blake3 ctx;
key->keep_shader_info = device->keep_shader_info;
key->trap_excp_flags = device->trap_handler_shader && instance->trap_excp_flags;
@@ -879,7 +880,10 @@ radv_device_init_cache_key(struct radv_device *device)
key->primitives_generated_query = true;
}
- _mesa_blake3_compute(key, sizeof(*key), device->cache_hash);
+ _mesa_blake3_init(&ctx);
+ _mesa_blake3_update(&ctx, &pdev->cache_key, sizeof(pdev->cache_key));
+ _mesa_blake3_update(&ctx, &device->cache_key, sizeof(device->cache_key));
+ _mesa_blake3_final(&ctx, device->cache_hash);
}
static void
diff --git a/src/amd/vulkan/radv_physical_device.c b/src/amd/vulkan/radv_physical_device.c
index 0d3660e7064..826c23a6c46 100644
--- a/src/amd/vulkan/radv_physical_device.c
+++ b/src/amd/vulkan/radv_physical_device.c
@@ -206,7 +206,6 @@ radv_device_get_cache_uuid(struct radv_physical_device *pdev, void *uuid)
return -1;
#endif
- _mesa_sha1_update(&ctx, &pdev->cache_key, sizeof(pdev->cache_key));
_mesa_sha1_final(&ctx, sha1);
memcpy(uuid, sha1, VK_UUID_SIZE);
--
2.49.0
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Antheas Kapenekakis <git@antheas.dev>
Date: Sat, 15 Mar 2025 16:39:25 +0100
Subject: [BEGIN] SteamOS Backports
--
2.49.0
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Natalie Vock <natalie.vock@gmx.de>
Date: Fri, 28 Feb 2025 14:21:57 +0100
Subject: radv/rt: Limit monolithic pipelines to 50 stages
Beyond that, monolithic pipelines just bloat to incredible sizes,
destroying compile times for questionable, if any, runtime perf benefit.
Indiana Jones: The Great Circle has more than 100 stages and takes
several minutes to compile its RT pipeline on Deck when using monolithic
compilation, and yet separate shaders still end up faster (probably
because instruction cache coherency in traversal is better).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33818>
---
src/amd/vulkan/radv_pipeline_rt.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_pipeline_rt.c b/src/amd/vulkan/radv_pipeline_rt.c
index 5a23dc99cc4..1421688d580 100644
--- a/src/amd/vulkan/radv_pipeline_rt.c
+++ b/src/amd/vulkan/radv_pipeline_rt.c
@@ -600,7 +600,11 @@ radv_rt_compile_shaders(struct radv_device *device, struct vk_pipeline_cache *ca
bool library = pipeline->base.base.create_flags & VK_PIPELINE_CREATE_2_LIBRARY_BIT_KHR;
- bool monolithic = !library;
+ /* Beyond 50 shader stages, inlining everything bloats the shader a ton, increasing compile times and
+ * potentially even reducing runtime performance because of instruction cache coherency issues in the
+ * traversal loop.
+ */
+ bool monolithic = !library && pipeline->stage_count < 50;
for (uint32_t i = 0; i < pCreateInfo->stageCount; i++) {
if (rt_stages[i].shader || rt_stages[i].nir)
continue;
--
2.49.0
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Antheas Kapenekakis <git@antheas.dev>
Date: Sat, 15 Mar 2025 16:39:33 +0100
Subject: [BEGIN] Our Mesa backports
--
2.49.0
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Maarten Lankhorst <maarten.lankhorst@intel.com>
Date: Mon, 17 Feb 2025 14:55:29 -0800
Subject: anv: Mark images with format modifiers set as scanout.
We currently use the presence of struct WSI_IMAGE_CREATE_INFO_MESA.scanout to mark the BO as scanout,
but this only handles the linear case, and fails when drm format modifiers are used.
Also handle the case of exportable BO with tiling set to VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT.
This fixes the gamescope handling of using vulkan allocated images for scanout.
Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12633
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Normalspeak: fixes battlemage iGPUs in gamescope
---
src/intel/vulkan/anv_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 1884932bbc7..cbc1b4aad87 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1533,6 +1533,9 @@ VkResult anv_AllocateMemory(
dedicated_info->image != VK_NULL_HANDLE) {
ANV_FROM_HANDLE(anv_image, image, dedicated_info->image);
+ if (image->vk.tiling == VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT)
+ alloc_flags |= ANV_BO_ALLOC_SCANOUT;
+
/* Apply implicit sync to be compatible with clients relying on
* implicit fencing. This matches the behavior in iris i915_batch
* submit. An example client is VA-API (iHD), so only dedicated
--
2.49.0
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Antheas Kapenekakis <git@antheas.dev>
Date: Mon, 24 Mar 2025 19:50:51 +0100
Subject: Revert "winsys/amdgpu: use VM_ALWAYS_VALID for all VRAM and GTT
allocations"
This reverts commit 8c91624614c1f939974fe0d2d1a3baf83335cecb.
Messes with AutoVRAM, who would have thought?
---
src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
index 24ba28827f8..46461f8ee59 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
@@ -618,11 +618,6 @@ static struct amdgpu_winsys_bo *amdgpu_create_bo(struct amdgpu_winsys *aws,
if (flags & RADEON_FLAG_GTT_WC)
request.flags |= AMDGPU_GEM_CREATE_CPU_GTT_USWC;
- if (aws->info.has_local_buffers &&
- initial_domain & (RADEON_DOMAIN_VRAM_GTT | RADEON_DOMAIN_DOORBELL) &&
- flags & RADEON_FLAG_NO_INTERPROCESS_SHARING)
- request.flags |= AMDGPU_GEM_CREATE_VM_ALWAYS_VALID;
-
if (flags & RADEON_FLAG_DISCARDABLE &&
aws->info.drm_minor >= 47)
request.flags |= AMDGPU_GEM_CREATE_DISCARDABLE;
--
2.49.0
+126
View File
@@ -0,0 +1,126 @@
# Credit to LionHeartP from Nobara for most of the spec and letting me know about the need for this package <3
%global origname mesa
%global ver 25.0.4
Name: %{origname}-compat
Summary: Mesa graphics libraries - legacy compatibility libraries
Version: %{lua:ver = string.gsub(rpm.expand("%{ver}"), "-", "~"); print(ver)}
Release: 1%{?dist}
Epoch: 1
License: MIT AND BSD-3-Clause AND SGI-B-2.0
URL: http://www.mesa3d.org
Source0: https://archive.mesa3d.org/mesa-%{ver}.tar.xz
# src/gallium/auxiliary/postprocess/pp_mlaa* have an ... interestingly worded license.
# Source1 contains email correspondence clarifying the license terms.
# Fedora opts to ignore the optional part of clause 2 and treat that code as 2 clause BSD.
Source1: Mesa-MLAA-License-Clarification-Email.txt
# Keep Mesa builds relatively the same
Patch0: bazzite.patch
BuildRequires: meson >= 1.3.0
BuildRequires: gcc
BuildRequires: gcc-c++
BuildRequires: gettext
%if 0%{?with_hardware}
BuildRequires: kernel-headers
%endif
BuildRequires: pkgconfig(expat)
BuildRequires: pkgconfig(zlib) >= 1.2.3
BuildRequires: pkgconfig(libzstd)
BuildRequires: bison
BuildRequires: flex
BuildRequires: pkgconfig(libelf)
BuildRequires: llvm-devel >= 7.0.0
BuildRequires: libdrm-devel
BuildRequires: python3-devel
BuildRequires: python3-mako
BuildRequires: python3-pycparser
BuildRequires: python3-pyyaml
%description
%{summary}.
%package libOSMesa
Summary: Mesa offscreen rendering libraries
Provides: libOSMesa
Provides: libOSMesa%{?_isa}
# New things should not rely on this as this library is dead upstream
Provides: deprecated()
%description libOSMesa
%{summary}.
%package libOSMesa-devel
Summary: Mesa offscreen rendering development package
Requires: %{name}-libOSMesa%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release}
# New things should not rely on this as this library is dead upstream
Provides: deprecated()
%description libOSMesa-devel
%{summary}.
%prep
%autosetup -n %{origname}-%{ver} -p1
cp %{SOURCE1} docs/
%build
# We've gotten a report that enabling LTO for mesa breaks some games. See
# https://bugzilla.redhat.com/show_bug.cgi?id=1862771 for details.
# Disable LTO for now
%define _lto_cflags %{nil}
%meson \
-Dplatforms= \
-Dosmesa=true \
-Dgallium-drivers=llvmpipe \
-Dgallium-vdpau=disabled \
-Dgallium-va=disabled \
-Dgallium-xa=disabled \
-Dgallium-nine=false \
-Dgallium-opencl=disabled \
-Dgallium-rusticl=false \
-Dvulkan-drivers= \
-Dshared-glapi=enabled \
-Dgles1=disabled \
-Dgles2=disabled \
-Dopengl=true \
-Dgbm=disabled \
-Dglvnd=disabled \
-Dglx=disabled \
-Degl=disabled \
-Dllvm=enabled \
-Dshared-llvm=enabled \
-Dvalgrind=disabled \
-Dbuild-tests=false \
-Dmesa-clc=auto \
-Dmicrosoft-clc=disabled \
-Dxlib-lease=disabled \
-Dandroid-libbacktrace=disabled \
-Dlibunwind=disabled \
-Dlmsensors=disabled \
%ifarch %{ix86}
-Dglx-read-only-text=true \
%endif
%{nil}
%meson_build
%install
%meson_install
# trim some garbage, the mesa base package handles these
rm -rf %{buildroot}%{_datadir}/drirc.d
rm -rf %{buildroot}%{_includedir}/GL/gl*.h
rm -rf %{buildroot}%{_includedir}/KHR
%files libOSMesa
%{_libdir}/libOSMesa.so.8*
%files libOSMesa-devel
%dir %{_includedir}/GL
%{_includedir}/GL/osmesa.h
%{_libdir}/libOSMesa.so
%{_libdir}/pkgconfig/osmesa.pc
%changelog
* Thu Apr 24 2025 Neal Gompa <ngompa@fedoraproject.org> - 25.0.4-1
- Initial split from mesa for compat libraries (rhbz#2362203)
+4 -4
View File
@@ -210,7 +210,7 @@ Obsoletes: mesa-omx-drivers < %{?epoch:%{epoch}:}%{version}-%{release}
Summary: Mesa libGL runtime libraries
Requires: libglvnd-glx%{?_isa} >= 1:1.3.2
Requires: %{name}-dri-drivers%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release}
Obsoletes: %{name}-libOSMesa < 25.1.0~rc2-1
Obsoletes: %{name}-libOSMesa < %{?epoch:%{epoch}:}25.1.0~rc2-1
%description libGL
%{summary}.
@@ -222,7 +222,7 @@ Requires: libglvnd-devel%{?_isa} >= 1:1.3.2
Provides: libGL-devel
Provides: libGL-devel%{?_isa}
Recommends: gl-manpages
Obsoletes: %{name}-libOSMesa-devel < 25.1.0~rc2-1
Obsoletes: %{name}-libOSMesa-devel < %{?epoch:%{epoch}:}25.1.0~rc2-1
%description libGL-devel
%{summary}.
@@ -253,7 +253,7 @@ Requires: %{name}-filesystem%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{rel
%if 0%{?with_va}
Recommends: %{name}-va-drivers%{?_isa}
%endif
Obsoletes: %{name}-libglapi < 25.0.0~rc2-1
Obsoletes: %{name}-libglapi < %{?epoch:%{epoch}:}25.0.0~rc2-1
%description dri-drivers
%{summary}.
@@ -262,7 +262,7 @@ Obsoletes: %{name}-libglapi < 25.0.0~rc2-1
%package va-drivers
Summary: Mesa-based VA-API video acceleration drivers
Requires: %{name}-filesystem%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release}
Obsoletes: %{name}-vaapi-drivers < 22.2.0-5
Obsoletes: %{name}-vaapi-drivers < %{?epoch:%{epoch}:}22.2.0-5
%description va-drivers
%{summary}.