https://bugzilla.redhat.com/show_bug.cgi?id=2247350 --- Comment #38 from Neal Gompa <ngompa13@xxxxxxxxx> --- (In reply to Kent Overstreet from comment #34) > Here, I've opened one: https://github.com/rust-lang/rust/issues/118018 Thank you for that. (In reply to Kent Overstreet from comment #37) > > I'm sorry, but I really don't understand this argument. I assume we don't even use the same C / Rust compilers (or the same versions) - I really hope you don't want us to ship and use the same version of the C / Rust compilers and the linker that you used to build and test, too? > > No. What I want is, if you're going to enable LTO, do it by submitting a > patch to bcachefs-tools so it can be properly tested. > > > To the contrary - Fedora packages *MUST* be built with the default compiler flags set by the distribution - calling this "monkey-patching" is not accurate. > Unless there are actual problems that are caused by some flags, just > disabling them is not OK. > > I seriously doubt you change the compiler flags for the kernel to something > unsupported. > We do, in fact, build our kernel with our build flags. Some stuff *is* selectively disabled, but nearly all our build flags are used. 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. > > This is not the first project that's written in Rust that now makes up some kind of critical component in Fedora - even RPM itself now has dependencies that are written in Rust. The way we package components like these has never caused any "subtle" issues like the ones you're thinking of here. > > I'm sorry, but RPM won't cause the system to fail to boot, or corrupt user > data, if it has bugs. > It definitely can do those things. And in the past *has* done some of those things. > Us filesystem people are _considerably_ touchier than most about having a > proper QA process. > 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. > > This is also out of your hands, given how packaging works, be it Rust or C or whatever - you just *cannot* guarantee (or expect) that we will ship the exact versions of dependencies that you tested with - or the same version of the C / Rust compiler that you compiled your tests with, for what it's worth. > > > Making sure that the packages that *we* ship actually work is also not *your* responsibility, but that of the *packager*. > > No, this attitude right here is a total non starter. > > I'm the one who's primarily going to be on the hook for bcachefs bug > reports; I have not seen any of you involved in bcachefs, nor have I seen > any kind of a QA process from you guys. > I don't get involved in anything unless I can ship it in Fedora. There is no point otherwise. Feel free to ask the Btrfs folks for my credentials, I'm very well-known there. > Given that, this "we know best, and you will have no involvement" attitude > isn't going to fly. I haven't gotten this working with any other > distributions; NixOS, Debian and Arch people have been totally fine to work > with, and have been in active communication when necessary and contribute > changes back. > 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. > Let's just put a pause on this whole process, shall we? 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. Unfortunately, I don't seem to be able to find the signing key, at least gpg can't download it. Could you publish it somewhere on your website? Here's a sample command for how it would work. gpg2 --export --export-options export-minimal 2A70052E44BC4216BE8EF42B13AB336D8DCA6E76 > gpgkey-2A70052E44BC4216BE8EF42B13AB336D8DCA6E76.gpg -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. 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%23c38 -- _______________________________________________ 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
