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.
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.
Unfortunately, that sausage is laced with systemd, which is kind of bad for you. I try to stick to manufacturers who are more frugal about what they put in the sausage.
It’s at odds with the philosophy of do one thing and do it well. Its monolithic feature set pushes out smaller contributors and leads to increased reliance on a singular package. This tends to self reinforce. I also use systemd in my current distro so not sure where I stand on this but it’s a fair concern.
Before systemd I had Redhat machines with 3 to 4 years of uptime, and now you need to restart Linux after updates....while Windows people rarely and they laugh at you...
The proof this site is misnamed is that a post criticizing systemd gets downvoted, probably by people who have never questioned why an init system needs to become half the operating system.
It's absolutely off-topic to moan about systemd on every post about Linux.
If there was a complaint about how systemd complicated builds and tests in a specific way the commenter could name, that'd be valid. Just finger-wagging is tiring after how many, 10 years?
I think the systemd people state that it is more than an init system, maybe your expectation of it needs to be adjusted. "systemd is a software suite for system and service management on Linux built to unify service configuration and behavior across Linux distributions." One of the great things about Linux is that you can always choose a distro that fits your ideals (or whatever else).
The systemd init isn't half an operating system any more than the coreutils "ls" utility is half a userspace. The systemd project has many different components but they're independent, they are not all literally part of the init system.
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
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
Truly a "Beefy Miracle".
https://web.archive.org/web/20230112002240/https://beefymira...
> 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.
Unfortunately, that sausage is laced with systemd, which is kind of bad for you. I try to stick to manufacturers who are more frugal about what they put in the sausage.
That's most of the entire planet using Linux.
And social media and fast food...does not mean its good for you...
I’m out of the loop on this, not trying to ignite a holy war, but what’s the gist of the anti-systemd stance?
New thing bad
It’s 16 years old and just as old are the criticisms?????
It’s at odds with the philosophy of do one thing and do it well. Its monolithic feature set pushes out smaller contributors and leads to increased reliance on a singular package. This tends to self reinforce. I also use systemd in my current distro so not sure where I stand on this but it’s a fair concern.
Before systemd I had Redhat machines with 3 to 4 years of uptime, and now you need to restart Linux after updates....while Windows people rarely and they laugh at you...
Just use another distro without systemd, no one cares.
People who dont care use Windows.
The proof this site is misnamed is that a post criticizing systemd gets downvoted, probably by people who have never questioned why an init system needs to become half the operating system.
It's probably being downvoted and flagged because it's off topic to the post and adds no substance which is against site rules.
Its not off topic, as reply to the comment, the post is replying.
It's absolutely off-topic to moan about systemd on every post about Linux.
If there was a complaint about how systemd complicated builds and tests in a specific way the commenter could name, that'd be valid. Just finger-wagging is tiring after how many, 10 years?
I think the systemd people state that it is more than an init system, maybe your expectation of it needs to be adjusted. "systemd is a software suite for system and service management on Linux built to unify service configuration and behavior across Linux distributions." One of the great things about Linux is that you can always choose a distro that fits your ideals (or whatever else).
The systemd init isn't half an operating system any more than the coreutils "ls" utility is half a userspace. The systemd project has many different components but they're independent, they are not all literally part of the init system.