This kind of end to end documentation is invaluable when you're trying to troubleshoot.
I had a service complaining about the root file permissions which changed between Fedora versions [1]. I was never able to figure out what produced the file system image but thanks so this guide I know where to start looking now.
Techrights are hard to take seriously, the site's author has such a bad case of that polemic tendency that he lost a libel case because he wouldn't stop harassing someone (https://caselaw.nationalarchives.gov.uk/ewhc/kb/2025/3063).
So as a relatively fresh Fedora user (2024) who just sold their Windows PC (2025) and is in love with the OS, where would be a good place to look for areas to contribute in? Is there a place where Fedora maintainers write down what parts of the pipeline are in need of volunteers?
Personally I feel a good way to get involved is to test updates in bodhi for those packages you care about, or to take part in the process that happens around release time where we go through several freeze cycles and have 'blocker bugs' that need their fixes to be validated: https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
> Every build starts from a clean room. You can never get a different result because someone installed something on the builder last week.
At least 6 years ago, this was not entirely true: a package happened to build only because, by happy accident, the builder had a dependency installed by something else. Since the dependency was not in its Build-Requires:, the build would fail in COPR, which really used a clean room. A case of being saved by the alphabetic order, I guess?
Mmm, COPR and Koji I think use the same mock configs but someone else would have to confirm that :)
It's definitely possible that one of a packages build dependencies pulls in something that a package /should/ depend on and then when it drops it suddenly the build fails. That's why I think we mostly want 'autogenerated' BuildRequires nowadays that are generated based on the upstream source or packaging format to make that less of a figuring out excercise.
This kind of end to end documentation is invaluable when you're trying to troubleshoot.
I had a service complaining about the root file permissions which changed between Fedora versions [1]. I was never able to figure out what produced the file system image but thanks so this guide I know where to start looking now.
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2402944#c1
Meanwhile the bluewashing seems to be keeping a steady pace. https://techrights.org/n/2026/07/22/IBM_is_Not_Done_Destroyi...
I haven’t followed the news. Sounds like IBM is bad news for Fedora long term?
I don't want to be hyper critical but was there ever a project that got better after being acquired by IBM?
Techrights are hard to take seriously, the site's author has such a bad case of that polemic tendency that he lost a libel case because he wouldn't stop harassing someone (https://caselaw.nationalarchives.gov.uk/ewhc/kb/2025/3063).
Truly a "Beefy Miracle".
https://web.archive.org/web/20230112002240/https://beefymira...
So as a relatively fresh Fedora user (2024) who just sold their Windows PC (2025) and is in love with the OS, where would be a good place to look for areas to contribute in? Is there a place where Fedora maintainers write down what parts of the pipeline are in need of volunteers?
There's a guide! It's here: https://docs.fedoraproject.org/en-US/project/join/ (or: https://fedoramagazine.org/how-to-contribute-to-fedora/)
Personally I feel a good way to get involved is to test updates in bodhi for those packages you care about, or to take part in the process that happens around release time where we go through several freeze cycles and have 'blocker bugs' that need their fixes to be validated: https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
I would recommend to look at Fefora's infra "backlog": https://forge.fedoraproject.org/infra/tickets/issues
> Every build starts from a clean room. You can never get a different result because someone installed something on the builder last week.
At least 6 years ago, this was not entirely true: a package happened to build only because, by happy accident, the builder had a dependency installed by something else. Since the dependency was not in its Build-Requires:, the build would fail in COPR, which really used a clean room. A case of being saved by the alphabetic order, I guess?
Maybe they have updated Koji since.
Mmm, COPR and Koji I think use the same mock configs but someone else would have to confirm that :)
It's definitely possible that one of a packages build dependencies pulls in something that a package /should/ depend on and then when it drops it suddenly the build fails. That's why I think we mostly want 'autogenerated' BuildRequires nowadays that are generated based on the upstream source or packaging format to make that less of a figuring out excercise.
Been thinking about this for years