https://bugzilla.redhat.com/show_bug.cgi?id=2181039 Fabio Valentini <decathorpe@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |fedora-review? Assignee|nobody@xxxxxxxxxxxxxxxxx |decathorpe@xxxxxxxxx CC| |decathorpe@xxxxxxxxx Status|NEW |ASSIGNED --- Comment #2 from Fabio Valentini <decathorpe@xxxxxxxxx> --- 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%{version}/%{name}-%{version}.tar.gz instead of: Source0: https://github.com/firecracker-microvm/firecracker/archive/refs/tags/v%{version}.tar.gz#/%{name}-%{version}.tgz 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_revision 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. -- 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=2181039 _______________________________________________ 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
