Spec URL: https://orion.fedorapeople.org/rust-exr.spec SRPM URL: https://orion.fedorapeople.org/ Description: Fedora Account System Username: orion error: Failed build dependencies: (crate(deflate/default) >= 1.0.0 with crate(deflate/default) < 2.0.0~) is needed by rust-exr-1.4.2-1.fc37.x86_64 (crate(flume/default) >= 0.10.9 with crate(flume/default) < 0.11.0~) is needed by rust-exr-1.4.2-1.fc37.x86_64
deflate has been updated.
FYI, It looks like this crate does not support big-endian architectures (according to its README): https://crates.io/crates/exr It's also explicitly only a dependency of "image" on little-endian architectures: https://github.com/image-rs/image/blob/master/Cargo.toml#L47-L50 As such, I'm inclined to just disable the OpenEXR functionality in "image" until this is resolved.
Are you still interested in packaging this crate? It would allow us to enable "exr" functionality of the "image" crate. Not sure if that's something you want (or need), but it would at least make our deviations from upstream in the package for "image" unnecessary. To resolve the problem with the missing support for big-endian architectures, I would just wrap the %cargo_build and %cargo_test macros in %ifnarch s390x conditionals, similar to what we do here: https://src.fedoraproject.org/rpms/rust-cpufeatures/blob/rawhide/f/rust-cpufeatures.spec#_67-80
Only partially at this point, but happy to help out. But looking a the latest version (1.5.2) I get: DEBUG util.py:443: Problem 1: nothing provides requested (crate(half/default) >= 2.1.0 with crate(half/default) < 3.0.0~) DEBUG util.py:443: Problem 2: nothing provides requested (crate(miniz_oxide/default) >= 0.6.2 with crate(miniz_oxide/default) < 0.7.0~)
If the latest version fails due to missing dependencies, then it would be OK to package a slightly older one, and I'll update it later, once I have updated the dependencies.
It looks like we have an issue where the crate doesn't ship various image files needed by the tests (tests/images). What's the best way forward here? Is it expected that they would be shipped in the crate? Can we shift to the github source?
(In reply to Orion Poplawski from comment #6) > It looks like we have an issue where the crate doesn't ship various image > files needed by the tests (tests/images). What's the best way forward here? Skip the tests which attempt to open files that aren't included in published crates ("%cargo_test -- -- --skip name_of_test"). If that doesn't work (for example, because the tests embed the contents of these files at build-time instead of opening them at run-time, i.e. with something like the "include_bytes!()" macro), then "rm tests/path_to_test.rs" the affected files in %prep. > Is it expected that they would be shipped in the crate? Can we shift to the > github source? No, that's not a good idea. We mandate using .crate files from crates.io for a reason. Mostly because it ensures that the crates successfully built before they were uploaded, and that the Cargo.toml metadata is normalized and has some extraneous stuff removed which could interfere with Fedora packaging tools.
Looks like we're fine without this crate, for now. I'll re-submit a review request for it if we ever start needing it.