https://bugzilla.redhat.com/show_bug.cgi?id=2181039
Fabio Valentini decathorpe@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |fedora-review? Assignee|nobody@fedoraproject.org |decathorpe@gmail.com CC| |decathorpe@gmail.com Status|NEW |ASSIGNED
--- Comment #2 from Fabio Valentini decathorpe@gmail.com --- Initial comments:
1. I don't really understand what this comment is meant to say:
""" # This should be left enabled for generating buildreqs correctly. """ %bcond_without check
Yes, "check" needs to be enabled for "dev-dependencies" to be included in generated BuildRequires, if that's what you meant to say ... but I'm not sure if that needs to be said explicitly, since this is normal for Rust packages.
2. Building for the *-musl Rust targets is not going to be supported in Fedora (we don't even have the musl toolchain targets available). All conditionals that rely on %{cargo_target} and / or %{with jailer} are noops, please remove them.
3. The Source URLs use the old and deprecated format that relies on the URL "#/fragment" hack. Please use the "new" format (which has worked for almost a decade), i.e. Source0: https://github.com/firecracker-microvm/firecracker/archive/v%%7Bversion%7D/%... instead of: Source0: https://github.com/firecracker-microvm/firecracker/archive/refs/tags/v%%7Bve... Same applies to the URLs for Source1 and Source2.
Documentation for this (both for using tarballs for git tags or for specific commits) is here: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_commit...
4. Strange names for downloads of bundled crates. I'm not sure why you're downloading kvm-bindings-e835920.tar.gz and micro-http-4b18a04.tar.gz but store them as kvm-bindings-0.6.0-1.crate and micro_http-0.1.0.crate. This is confusing and unnecessary, since you control all parts of this process, there's no need to name them as if they were upstream crates.
5. Patches are included without comments or explanations. Please include short comments about what your patches do to the spec file, and whether they are suitable for upstreaming (or not).
6. Don't ignore test failures. It's OK to ignore specific tests that don't work in our containerized build environment, but "|| :"-ing everything is not OK.
7. Include breakdown of the dependencies / licenses. The License tag looks comprehensive, but there's no indication how this list was generated (you're not using the %cargo_license or %cargo_license_summary macros in the spec file), and there's no breakdown that lists which dependency is available under which license.