https://bugzilla.redhat.com/show_bug.cgi?id=2299712 --- Comment #2 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- (In reply to Miro Hrončok from comment #1) > The Licenses in the comment and in the License tag seem to be represented > differently. See e.g. "Zlib OR Apache-2.0 OR MIT" vs "Apache-2.0 OR MIT OR > Zlib" -- this is confusing and hard to verify. I ordered the components of disjunctive license expressions alphabetically because in very many cases, there are differently-ordered equivalent versions among the statically linked crate dependencies. For example, the raw %{cargo_license_summary} output contains all of the following: # MIT OR Apache-2.0 OR Zlib # MIT OR Zlib OR Apache-2.0 # Zlib OR Apache-2.0 OR MIT It’s hard to deduplicate these, or quickly check if a combination of licenses already exits in the License expression, without applying some sort of consistent normalization. It’s also kind of aesthetically displeasing to have to choose one form over the other two with no particular rationale. I’m open to other approaches, but I’m also also mindful of the need to cross-check and update the License expression when updating the package, without having to go through every part of it from scratch. How would you prefer to write the License expression? > Suggestion: Number patches after sources, i.e. rename Patch100 to Patch201 > and Patch101 to Patch301 -- that way it is more obvious which potch goes > where (and possibly also %autopatch could be used, with ranges, but I have > not tried that from subdirectories). This is a good suggestion. I’ll try it. > > # Downstream-only: do not override the default allocator > > It is not obvious why this is needed. The comment rather says we might want > to drop it. I assume this is to avoid an unpackaged dependency... ? Yes, I can add some detail to that comment. Packaging tikv-jemallocator would involve packaging a cluster of its dependencies and overcoming some fussy packaging issues. Since using it is “just” a performance optimization, and a relatively moderate one, this can be optional follow-up work rather than a blocker for packaging uv. > > • ⚖️ Drop-in replacement for common pip, pip-tools, and virtualenv commands. > > • ⁉️ Best-in-class error messages with a conflict-tracking resolver. > > Those two bullet points have double spaces after the emoji. Good catch! It looks like I introduced those spaces downstream. I’ll fix them. > > %package -n python3-uv > > Summary: %{summary} > > This subpackage should have a different summary. How about this? Summary: Importable Python module for uv > Have you considered excluding i686 from the start? This should be a leaf > package except for hatch which is noarch. Sure, that’s a good idea now that noarch packages no longer build on i686. > > export RUSTFLAGS='%{build_rustflags}' > > This should be part of %set_build_flags, is it actually needed? Hmm, it doesn’t look like it. Perhaps I copied that thoughtlessly from something else, or perhaps I did it in anticipation of possibly backporting to EPEL9 where %set_build_flags is not automatic – but I can cross that bridge when and if I get there. > > # -p uv-auth --lib: > > I got a bit confused by this comment in %check. What does it relate to? It corresponds to the "cargo test" options that would run the group of tests in which the failure occurred: Package Selection: -p, --package [<SPEC>] Package to run tests for Target Selection: --lib Test only this package's library So these tests are in the library (vs. binary, example, test, or bench) tests of the uv-auth workspace crate. test result: FAILED. 15 passed; 3 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.06s error: test failed, to rerun pass `-p uv-auth --lib` Additionally, these flags are the "target" for which cargo test reports failure when summarizing all test results: error: 1 target failed: `-p uv-auth --lib` -- 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=2299712 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202299712%23c2 -- _______________________________________________ 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
