Created attachment 1957108 [details] build.log Description of problem: libblkio fails to build from source with multiple errors. See build log attached to this bug. Version-Release number of selected component (if applicable): libblkio-1.2.2-4.fc39 How reproducible: 100% Steps to Reproduce: 1. Try to build the package in Rawhide.
https://koji.fedoraproject.org/koji/taskinfo?taskID=99833864
I can reproduce this by upgrading from nix 0.24 to 0.26. The upstream Cargo.toml files specify 0.24, so this build failure doesn't happen upstream. Upstream libblkio has removed the nix dependency. I will roll an upstream release and send a downstream pull request to build the new version of libblkio. Is it expected that Fedora will build newer (unstable) crates and existing packages will fail to build from source? Or are we doing something wrong that allowed this to happen?
Rawhide is on the bleeding edge. Its purpose is to integrate the newest packages together. However whether it is expected in the Rust stack that $some_random_change which breaks the building of another package should go unnoticed into Fedora is another question I'm not too familiar with. For OCaml packages we always rebuild dependencies so we try to pick this sort of thing up, but that is a lot of work.
(In reply to Stefan Hajnoczi from comment #2) > I can reproduce this by upgrading from nix 0.24 to 0.26. The upstream > Cargo.toml files specify 0.24, so this build failure doesn't happen upstream. libblkio in Fedora builds against nix v0.24, not v0.26, so this is not the cause. > Upstream libblkio has removed the nix dependency. I will roll an upstream > release and send a downstream pull request to build the new version of > libblkio. > > Is it expected that Fedora will build newer (unstable) crates and existing > packages will fail to build from source? Or are we doing something wrong > that allowed this to happen? As I said, this isn't caused by the nix v0.26 update in Fedora, since we're still shipping v0.24 and that's what libblkio builds against (as intended, that's what the "(nix>=0.24 with nix<0.25)" dependency stuff is *for*). === That said, the FTBFS issue is, as far as I can tell, this is caused by an upstream bug. The "virtio-driver" crate depends on nix v0.24 with "default-features = false", however, the code obviously imports items from "nix" that are only present if the "ioctl" feature is enabled. This used to work "by accident" because some other crate in libblkio's dependency tree used to pull in nix v0.24 with default features enabled. This no longer seems to be the case (hard to tell what changed, since koschei was not enabled). However, it should also be simple to fix - just add the features that are actually used to the list of enabled features of "nix" in the virtio-driver crate's Cargo.toml. This seems to just be the "ioctl" feature: change virtio-driver/Cargo.toml line 20 from: nix = { version = "0.24", default-features = false, features = ["event"] } to: nix = { version = "0.24", default-features = false, features = ["event", "ioctl"] } and it should just work (but I have not tested this) - it should just fix the *first* compiler error, there might be others.
(In reply to Fabio Valentini from comment #4) > (In reply to Stefan Hajnoczi from comment #2) > > I can reproduce this by upgrading from nix 0.24 to 0.26. The upstream > > Cargo.toml files specify 0.24, so this build failure doesn't happen upstream. > > libblkio in Fedora builds against nix v0.24, not v0.26, so this is not the > cause. > > > Upstream libblkio has removed the nix dependency. I will roll an upstream > > release and send a downstream pull request to build the new version of > > libblkio. > > > > Is it expected that Fedora will build newer (unstable) crates and existing > > packages will fail to build from source? Or are we doing something wrong > > that allowed this to happen? > > As I said, this isn't caused by the nix v0.26 update in Fedora, since we're > still shipping v0.24 and that's what libblkio builds against (as intended, > that's what the "(nix>=0.24 with nix<0.25)" dependency stuff is *for*). > > === > > That said, the FTBFS issue is, as far as I can tell, this is caused by an > upstream bug. > > The "virtio-driver" crate depends on nix v0.24 with "default-features = > false", however, the code obviously imports items from "nix" that are only > present if the "ioctl" feature is enabled. This used to work "by accident" > because some other crate in libblkio's dependency tree used to pull in nix > v0.24 with default features enabled. This no longer seems to be the case > (hard to tell what changed, since koschei was not enabled). > > However, it should also be simple to fix - just add the features that are > actually used to the list of enabled features of "nix" in the virtio-driver > crate's Cargo.toml. This seems to just be the "ioctl" feature: > > change virtio-driver/Cargo.toml line 20 from: > nix = { version = "0.24", default-features = false, features = ["event"] } > to: > nix = { version = "0.24", default-features = false, features = ["event", > "ioctl"] } > and it should just work (but I have not tested this) - it should just fix > the *first* compiler error, there might be others. Thanks for explaining the root cause, Fabio! I have sent a pull request: https://src.fedoraproject.org/rpms/libblkio/pull-request/2 The next upstream release will drop the nix dependencies that blkio and virtio-driver had in libblkio 1.2.2. That change is already merged upstream. I have patched libblkio 1.2.2 as you suggested for the time being.
https://koji.fedoraproject.org/koji/taskinfo?taskID=100125586
FEDORA-2023-f548e939a2 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f548e939a2
FEDORA-2023-f548e939a2 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-1c3bdc3bdc (libblkio-1.5.0-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-1c3bdc3bdc
FEDORA-2025-1c3bdc3bdc (libblkio-1.5.0-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.