https://bodhi.fedoraproject.org/updates/FEDORA-2025-82b66363b4
Integrated “backport” (appears to be not yet merged into upstream Making sure you're not a bot! ) causes issues.
People explicitly reported issues.
Build pushed to stable.
Causes issues for more people ( Mesa 25.2.7 appears to break Proton games )
What is the reasoning behind this? What is considered “stable“?
I thought it was a bit premature myself but hopefully the package maintainer sees this and can provide their reasoning.
Note that the update was submitted to stable by a different packager than who built and created the update, so with it being the weekend, they might not even be aware that it happened yet …
I’m new to the fedoraverse but how does this happen?
Multiple issues reported, and still someone pushed it out?
So now we’re seeing this: Reddit - The heart of the internet
Which happened to me, a mere 4 days after writing about switching to Fedora
People are fallible and software has bugs. If you hadn’t switched to Fedora a mere 4 days ago, it would probably still have happened.
Sometimes it happens even to the best of us and sometimes to large corporations like Cloudflare, Crowdstrike and Microsoft.
Right, but there were pretty clearly reported problems in this case. Surely there’s some kind of sign-off on these kinds of things so someone can’t just push an update through like this?
Given that someone apparently did, evidently not. Perhaps the very act of uploading the package, having it pass all of the currently defined testing and declaring it “good” is enough to triggers its release. Maybe it was human oversight. Maybe it was malicious. Maybe the packager didn’t realise what he was releasing was the same package that people were hitting issues with.
As @decathorpe says above, “the update was submitted to stable by a different packager than who built and created the update, so with it being the weekend, they might not even be aware that it happened yet.”
I’m sure it’ll all come out in the end… probably.
In general, package maintainers need to take feedback on updates into account. However, there’s still a judgement call involved: Is this issue reproducible? If so, is it even clear how many users would be affected? Often it’s hard to answer those questions, and packagers need to make a decision whether to let the update proceed, to amend it (if there’s a known or proposed fix), or to pull it entirely.
In this case, the package maintainer who pushed the button to submit the mesa update to “stable” is not the maintainer of “mesa” in Fedora, but they are the package maintainer for the NVidia driver on RPMFusion … and since they didn’t leave a comment when they pushed the update, it’s not clear (to me) what the reasoning behind that action was.
That’s even more concerning then, how could they push an update if they’re not even a maintainer of the package? Sounds like updates for this sort of thing in Fedora need more checks to go through…
We do have access control checks for stuff like this, but the packager in question is in the “trusted” group (provenpackagers) who are allowed to manage all (*) packages in Fedora …
My best guess is that mesa was pushed to stable because mesa-freeworld had already done the same in RPM Fusion. I imagine that upgrading mesa-freeworld without upgrading mesa to the corresponding version would cause other difficulties for the users of mesa-freeworld. I remember being surprised that DNF offered to perform that upgrade, but I held off on it.
Edit: now that I think about it more, I’m not sure if I remember actually trying the upgrade for real, or if I only looked at the output of check-upgrade
It’s a nightmare trying to keep freeworld packages in sync with fedora.
Thank you for your work!
No, there isn’t. It’s not practical to have ‘sign off’, given the number of packages and the number of maintainers in Fedora. Any maintainer of a package in the update (I think that’s the rule, anyway…), or any proven packager, can push an update stable if it meets the minimum requirements to be pushed stable (which, for stable releases, are +1 total karma or 7 days in updates-testing for non-critical path updates, +2 total karma or 14 days in updates-testing for critical path updates).
Not even for major packages like Mesa? That seems like something that should be there. I could understand for minor stuff and apps, but system critical stuff like Mesa should have something more?
At present, no. We could consider adding something, but it’d be a chunk of engineering work: you’d have to write the whole system into Bodhi, including some kinda way for people to request signoff from others, probably…
I would hope, that at some point, the individual who pushed it will comment on the reasons, as because RPMFusion needed it is not, really, a great answer (quite honestly, if that was the total answer I would petition to have the individual removed from PP status, as RPMFusion is not Fedora, and Fedora should not be a pawn to RPMFusion’s decisions). I would suggest we let the individual respond before jumping to conclusions or actions.
@leigh123linux is the person who pushed it, and he already posted in this thread.
I think FEDORA-2025-2f4ba7cd17 is intended to be fix for this, if people could try that out it’d be great.
With FEDORA-2025-2f4ba7cd17 I don’t see spinning CPU issue using NVidia proprietary driver 580.95.05 from RPMFusion and RTX 4060. Version without “backport” FEDORA-2025-16fd872987 also worked well in meantime.
Can testing of work-in-progress patches ( not yet reviewed/accepted by upstream ) be better separated from released Fedora versions to reduce chances of accidents in the future?
Nevertheless, RPMFusion is what make Fedora usable in real world scenarios. I hope there is a way to improve the collaboration processes to better mitigate issues like this.