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

@bitlord are you using the mesa-freeworld (RPM Fusion) packages? Some users reported issues (https://bugzilla.redhat.com/show_bug.cgi?id=2338414) and I suspect that it could be your problem as well.

It is possible that the NVIDIA GPU is selected as primary not because of the connector type, but because an error is falling back to software rendering.

FWIW, I documented the process here, hopefully it helps you selecting the desired GPU as primary while we find the issue: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4218

@bitlord I was kind of expecting it, as that information is exposed by the kernel. It is still surprising that mesa is affecting the selected device as, in addition to the connector type, it only checks that the device is capable of hardware rendering.

As a workaround, you can add a udev rule to set the primary GPU: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562

Some users suggest that this rule works better: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562#note_2249922

I'd still suggest to create a bug report in Mutter so we try to find a proper fix.

@bitlord the component selecting the primary GPU is mutter, i happens here: https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/backends/native/meta-renderer-native.c?ref_type=heads#L2321

There is a rule in place that selects as primary the GPU connected to the laptop screen by checking if one of its connectors is eDP, LVDS ot DSI.

Could you check if drm_info returns different connector types between mesa versions?

For example, in my laptop, this is the connector used by the laptop screen:

├───Connectors
│   ├───Connector 0
│   │   ├───Object ID: 241
│   │   ├───Type: eDP

If possible, open a bug report in Mutter. I think it could be a good place to start fixing the regression.

Un-pushing to stable to avoid conflicts with RPM Fusion. The RPM Fusion maintainers will push it when they are ready.

This update has been unpushed.

Fixed in a new build: FEDORA-2024-ff6d78f49f

@anotheruser added, thanks for testing

@thl, no, that's a bug and it should be solved by: https://src.fedoraproject.org/rpms/mesa/pull-request/52

If you see the error in other subpackage, please report it or open a MR.

Hey @agurenko,

Since Fedora 41 will be released soon, no, I didn't plan to build mesa 24.2.x for Fedora 40. Instead, I'd like to stick to the stable version there.