Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: https://eclipseo.fedorapeople.org/for-review/rust-ed25519-dalek.spec SRPM URL: https://eclipseo.fedorapeople.org/for-review/rust-ed25519-dalek-1.0.1-1.fc35.src.rpm Description: Fast and efficient ed25519 EdDSA key generations, signing, and verification in pure Rust. Fedora Account System Username: eclipseo
New Spec URL: https://eclipseo.fedorapeople.org/for-review/rust-ed25519-dalek.spec New SRPM URL: https://eclipseo.fedorapeople.org/for-review/rust-ed25519-dalek-1.0.1-1.fc35.src.rpm
< # rust-cpufeatures is only available on these arches < ExclusiveArch: x86_64 aarch64 --- > ExclusiveArch: %{rust_arches}
Build requires rust-curve25519-dalek, which does not have a review request that I see. Looks like ed25519 and ed25519-dalek need to be built together.
I will take this even though I am just starting on rust packages. At least it is two sets of eyes, and I did find one nit.
Never mind about rust-arches. You mentioned that this package supports only some rust_arches in bz#1981114
So as soon as rust-curve25519-dalek is on QA, we can move forward with these two.
> ExclusiveArch: x86_64 aarch64 This is wrong, use %{rust_arches} instead.
Yes, the cpufeatures package provides *optimizations* for the supported arches. It still builds and runs on other arches. So please use %{rust_arches}
I see rust-curve25519-dalek was added to f34+ 3 months ago, so I'll look at this tomorrow.
I can't download the spec to see if ExclusiveArch was fixed.
I will continue with review as if you had fixed the ExclusiveArch.
Ok, it builds on f35. Looking up tutorial on what else to check for rust reviews.
For new packages, it's more important that they build on rawhide. As for Rust reviews, it's usually a good idea to compare the spec file with an the original unmodified rust2rpm output, and check if it prints any error messages. Additionally, you need to ensure that the built packages are actually installable (this is not always the case, for example, non-default optional dependencies are not needed for the build, but only when installing the built packages). You could take a look at the Rust packaging tutorial / workshop that I held at Nest 2022 last weekend - the recording is still available, and the slides are available here: https://decathorpe.fedorapeople.org/flock2022/
New Spec URL: https://gathman.org/linux/SPECS/rust-ed25519-dalek.spec New SRPM URL: https://gathman.org/linux/f37/src/rust-ed25519-dalek-1.0.1-4.fc37.src.rpm Problem 1: conflicting requests - nothing provides (crate(merlin) >= 2.0.0 with crate(merlin) < 3.0.0~) needed by rust-ed25519-dalek+merlin-devel-1.0.1-4.fc37.noarch Problem 2: conflicting requests - nothing provides (crate(sha2/asm) >= 0.9.0 with crate(sha2/asm) < 0.10.0~) needed by rust-ed25519-dalek+asm-devel-1.0.1-4.fc37.noarch Problem 3: package rust-ed25519-dalek+batch-devel-1.0.1-4.fc37.noarch requires crate(ed25519-dalek/merlin) = 1.0.1, but none of the providers can be installed - conflicting requests - nothing provides (crate(merlin) >= 2.0.0 with crate(merlin) < 3.0.0~) needed by rust-ed25519-dalek+merlin-devel-1.0.1-1.fc37.noarch - nothing provides (crate(merlin) >= 2.0.0 with crate(merlin) < 3.0.0~) needed by rust-ed25519-dalek+merlin-devel-1.0.1-4.fc37.noarch Problem 4: package rust-ed25519-dalek+batch_deterministic-devel-1.0.1-4.fc37.noarch requires crate(ed25519-dalek/merlin) = 1.0.1, but none of the providers can be installed - conflicting requests - nothing provides (crate(merlin) >= 2.0.0 with crate(merlin) < 3.0.0~) needed by rust-ed25519-dalek+merlin-devel-1.0.1-1.fc37.noarch - nothing provides (crate(merlin) >= 2.0.0 with crate(merlin) < 3.0.0~) needed by rust-ed25519-dalek+merlin-devel-1.0.1-4.fc37.noarch
That means two things: - the "asm" feature needs to be disabled, because it's disabled in our package for the "sha2" crate - the "merlin" feature needs to be disabled, or the "merlin" crate needs to be packaged (version 2.0.1, not the latest 3.0.0)
Please continue with this review if you still need this package.
This is an automatic action taken by review-stats script. The ticket submitter failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we consider this ticket as DEADREVIEW and proceed to close it.
Can there be two versions of merlin packaged? Should I try to compile with current merlin?
Why would we need two versions? We need either one (the one which is required by ed25519-dalek), or none (if the optional feature is disabled in ed25519-dalek).
The app (cjdns) doesn't work with the feature disabled. Fedora rust policy says you must use the latest on cargo.io
It actually says you SHOULD package the latest version, not MUST: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_crate_versions If whatever you're working on does require an older version and does not work with the latest, then that's a sufficiently good reason for not packaging the latest version.