Checked the Wine build and it is working as expected: FEDORA-2025-af182e9da3

@pointy if you can leave a comment there as well it'll be super useful to get Wine pushed to stable.

The dependency issue is solved. "mesa-libOSMesa" is not used anymore, instead "mesa-compat-libOSMesa" is used:

$ koji download-build 2740517
Downloading [1/43]: wine-10.4-4.fc42.src.rpm
[...]

$ rpm -qp *rpm --requires | grep mesa
rpm -qp *rpm --requires | grep libOSMesa
mesa-compat-libOSMesa-devel
mesa-compat-libOSMesa(x86-32)
mesa-compat-libOSMesa(x86-64)

New Wine build: FEDORA-2025-af182e9da3

Un-pushing it for the moment and opened a MR in Wine fixing the issue.

Opened a MR fixing it: https://src.fedoraproject.org/rpms/wine/pull-request/26

I don't know how I missed it in the first place, sorry for the additional build.

This update has been unpushed.

Pushed to testing again. @agurenko your issue should be fixed now :D

A little update. Wine developers are not ready to push Wine 10.10 because "wine-mono does not compile with the new version of GCC (mingw-w64)": https://src.fedoraproject.org/rpms/wine/pull-request/24#comment-269505

So this mesa update is currently waiting for the release of mesa-compat: FEDORA-2025-9ccc5a859c

I can not push it, so I think it'll have to wait a few days.

Hey @imabug, thanks for testing

That's expected. libOSMesa was removed by mesa 25.1, however, Wine and asymptote still use that library. We can not update mesa to 25.1 in Fedora 42 without breaking Wine and asymptote until the compatibility package is available and we rebuild both packages using it.

So this is chicken and egg problem, until mesa-compat is available I can not create MRs updating Wine, asymptote and mesa. During that period, there will be a conflict between mesa and mesa-compat.

@agurenko oh, good catch! mesa 25.1.4 removes the mesa-libOSMesa package. Neal already created mesa-compat to provide it: https://src.fedoraproject.org/rpms/mesa-compat/

But it is not available in Fedora 42. I created a MR to make it available in Fedora 42: https://src.fedoraproject.org/rpms/mesa-compat/pull-request/1

And another one to use it in Wine: https://src.fedoraproject.org/rpms/wine/pull-request/24

I'm going to close this build for the moment and I'll push a new one once the issue is solved.

The failed test is a false positive. The Firefox icon is present in the KDE start menu in one of the versions. Can someone look into a fix for the test?

I pushed a new build updating to mesa 25.0.4 and including a revert to fix the CI errors while we find a better solution: FEDORA-2025-52471ac786

@synthexic, could you link the upstream issue, please?

As soon as a fix is available upstream I'll backport to Fedora.

Hi @siegf,

Please report the issue upstream (once GitLab is available again): https://gitlab.freedesktop.org/mesa/mesa/

The issue template on GitLab will ask you for useful information. You'll need to attach a coredump: https://fedoramagazine.org/file-better-bugs-coredumpctl/

That'll contain information about the problem.

Hey @markec, sure, pushing to stable.

Hi @koedi

If possible, create a bug report upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/

And provide a backtrace: https://docs.fedoraproject.org/en-US/quick-docs/bugzilla-providing-a-stacktrace/

Thanks!

Hi @cmorris,

Could you check if there are similar bug reports upstream and if not create one, please? https://gitlab.freedesktop.org/mesa/mesa/-/issues

For what you mentioned, this could be an issue in mesa, the kernel or both and it'd be interesting to discuss this issue upstream.

Hi @adamwill

Thanks for beating me on testing the update.

Indeed, I forgot to add the required "Obsoletes", added here: https://src.fedoraproject.org/rpms/mesa/c/ac886e3f55bb46584723b452a6ca661f3feb668d?branch=rawhide

I added it to dri-drivers as according to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32789 libglapi..so is merged into libgallium..so.

I'm afraid I don't. They are very active though. Usually, they are able to work on RPM Fusion at least once a week.

@markec I usually let the RPM Fusion developers push it to avoid version mismatches between mesa and mesa-freeworld