https://bugzilla.redhat.com/show_bug.cgi?id=2349303 --- Comment #7 from Alexander Lent <lx@xxxxxxxxxxxxxx> --- Hi Tom, my comments on the review items follow: (for the two areas addressed by comment #6, I have tried to answer in my own words) (In reply to Tom.Rix from comment #5) > [ ]: License field in the package spec file matches the actual license. > Note: Checking patched sources after %prep for licenses. Licenses > found: "*No copyright* Apache License", "Unknown or generated", "*No > copyright* Apache License 2.0". 44 files have unknown license. > Detailed output of licensecheck in /sfs/fedora-review/review-python- > safetensors/licensecheck.txt This should be addressed by the SourceLicense line; The srpm contains only Apache-2.0 code and the spec (licensed by the FPCA). While upstream doesn't use SPDX annotations on all files it does ship a conspicuous LICENSE file. (If you think it's important I can file a bug upstream for SPDX annotations.) > > # Results of the Cargo License Check > # > # Apache-2.0 > # Apache-2.0 OR BSL-1.0 > # Apache-2.0 OR MIT > # MIT > # MIT OR Apache-2.0 > # Unlicense OR MIT > License: Apache-2.0 AND (Apache-2.0 OR BSL-1.0) AND (Apache-2.0 OR MIT) AND > MIT AND (MIT OR Apache-2.0) AND (Unlicense OR MIT) > SourceLicense: Apache-2.0 > # The PyPI package lives at https://pypi.org/project/safetensors/ > # But the GitHub URL encompasses the entire project including the > separately-packaged Rust crate > > Why isn't this just ? > > License: Apache-2.0 > > I do not think it is necessary include > > %license bindings/python/LICENSE.dependencies > > As you are not bundling these packages The standard behavior for Rust dependencies is static linking, so we *are* bundling Rust dependencies in the binary packages. The relevant guidelines say that the license summary and license concatenation should be used. See: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_python_projects https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_license_tags > [-]: Package must own all directories that it creates. > Note: Directories without known owners: /usr/lib64/python3.13, > /usr/lib64/python3.13/site-packages My understanding is that other packages should own these files. > [ ]: If the source package does not include license text(s) as a separate > file from upstream, the packager SHOULD query upstream to include it. It already does, though due to how the PyPI sources are generated, the LICENSE file is in the crate subfolder. > [ ]: Fully versioned dependency in subpackages if applicable. > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in > python3-safetensors , python3-safetensors+numpy , > python3-safetensors+torch This seems to be a result of using the pyproject extras macros. Strangely the guidelines seem to require it but the extras macro (generated by pyp2spec) doesn't do it: "A package that provides a Python extra MUST require the extra’s main package with exact NEVR." https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_handling_extras > [!]: Latest version is packaged. > > 0.5.3 > Packaging the latest version is blocked on bug 2348381. > [ ]: Package does not include license text files separate from upstream. Should be good on this one. > [-]: Patches link to upstream bugs/comments/lists or are otherwise > justified. The only patch swaps the bundled crate (which we purge in %prep) for the exact version of the safetensors crate as a dependency. > [ ]: Sources are verified with gpgverify first in %prep if upstream > publishes signatures. > Note: gpgverify is not used. I know the PyPA is moving to a different signature scheme/system for verifying published sources for Python packages. If/When we have support for that, I would be happy to set up verification of the sources. > > python3-safetensors+numpy.x86_64: E: spelling-error ('Metapackage', > 'Summary(en_US) Metapackage -> Meta package, Meta-package, Prepackage') > python3-safetensors+torch.x86_64: E: spelling-error ('Metapackage', > 'Summary(en_US) Metapackage -> Meta package, Meta-package, Prepackage') > python3-safetensors+numpy.x86_64: W: no-documentation > python3-safetensors+torch.x86_64: W: no-documentation > 4 packages and 0 specfiles checked; 2 errors, 2 warnings, 41 filtered, 2 > badness; has taken 0.5 s I think it's normal for extras packages to lack Documentation. The spelling error is being generated by the Python RPM Macros. Do you think it's worth filing a bug against those for the rpmlint fail in "Metapackage" vs "Meta-package"? > Unversioned so-files > -------------------- > python3-safetensors: > /usr/lib64/python3.13/site-packages/safetensors/_safetensors_rust.abi3.so I believe that this is normal for compiled code in Python site-packages. > > Notes: > > python3-safetensors+numpy: > python3-safetensors+torch: > > These I think are overkill, reduce to just python3-safetensors, even if it > means > needed to manually add > > Requires: python3dist(numby) > Requires: python3dist(torch) The Python extra packages exist to provide their metadata to the distro package system; without them automatic dependency resolution won't work for future packages that depend on the extras. For example, a future package might have a requirement on safetensors[torch] (in the python syntax) which the pyproject_buildrequires macro will translate into python3dist(safetensors[torch]), which will pull in the extra package, consequentially pulling in torch and numpy, but only for dependencies that need them. The guidelines note that if we want to Recommends/Suggests the extras by default for a good experience, we can do so. See here for more info: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_handling_extras -- 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=2349303 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202349303%23c7 -- _______________________________________________ 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
