https://bugzilla.redhat.com/show_bug.cgi?id=2247350 --- Comment #45 from Kent Overstreet <kent.overstreet@xxxxxxxxx> --- > While I see no evidence of LTO breaking bcachefs-tools, I can disable it for now until I've gotten more of a chance to poke at it and see that it's fine. Thanks. Actually, a more likely source of breakage is any hardening flags you might be enabling; I was just spending a fair amount of time dealing with breakage from new kernel side hardening. Can we get a patch submitted to bcachefs-tools to add all those to the CFLAGS there? We definitely want LTO enabled, I just want testing and review for all of these. If you're flipping on hardening options, they should be in a warning mode, not "exit the process" mode; kernel side we've that e.g. the bounds checking that was added was triggering spuriously because we push VLAs pretty hard. > I am aware of how filesystem people work. I have been working professionally with this stuff for almost a decade now with OpenZFS, Btrfs, and now bcachefs. I have been working with the Btrfs folks both upstream and in Fedora for the better part of that timeframe too. Good to know. If you're going to be the main person involved on the Fedora side, I'd love to see you in the IRC channel - irc.oftc.net #bcache. > You haven't looked at what Debian is doing, have you? Debian has disabled all the Rust parts because they haven't gotten through devendoring and packaging all the Rust crates you use, because Debian *mandates* it. They are also applying their distro-wide build flags too. I have chosen to use the vendored crates for now because it is not worth it to me while the forked crates situation exists. No, I definitely have, and disabling the Rust part for now is a better solution in my eyes than devendoring. In recent years we've seen a lot of work on a lot of fronts on improving reproducibility of builds. What Cargo (and relatedly, NixOS) have been doing is a huge step in the right direction; a cargo lockfile now references _exact git sha1s_ of dependencies, which means that by checking in the lockfiles anyone building a particular revision of bcachefs-tools will get the same output, with respect to library dependencies. That's huge, considering that historically library version mismatch has been a huge source of build problems, in particular. (I was just fighting with this in someone else's C project, and as a result I can't reproduce the upstream smatch build and get the same source code analysis results. That sucks). It now means that we can catch all these sorts of issues with automated testing, before doing a release. I realize what we have now may not be what distribution people consider the ideal solution; it runs somewhat counter to your historical practices. But I consider it a big step forward, and I hope distribution people can do something that builds on top of what they achieved, and not take away the reproducibility of builds that's been achieved. The devendoring that's been talked about sounds too much like an experiment that I don't want to be the guinea pig for. > No. This needs to land so we can turn on bcachefs in the Fedora kernel. At this point, the only thing left for me to do is to add GPG verification since it looks like you publish signatures for the tarballs. There's no /need/ to do this on any particular schedule, and I would prefer to take things slow. I've spent 15 years on this project, taking my time to get things right, trying to produce something polished and stable. I don't want to burn my reputation by getting impatient and going too fast just as I'm at the finish line. I'm about to see a massive uptick in users and bug reports, just from bcachefs being merged into 6.7. It's going to be a lot to stay on top of, and dealing with bug reports in a timely manner is something I consider important: when I have the time to work with people it's an avenue to teaching people how to report bugs well, how to do useful testing, and it's how I've effectively built up a solid QA team. Not being able to respond to bug reports is a missed opportunity. So: a staged release, instead of everyone getting it all at once, is a _good_ thing. If the next 3 months after the release of 6.7 it's still primarily available to those building from source, I'm much more likely to be hearing from people I can work with. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2247350 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202247350%23c45 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
