https://bugzilla.redhat.com/show_bug.cgi?id=1686307 Adam Williamson <awilliam@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |fedora-review? | |needinfo?(quantum.analyst@g | |mail.com) --- Comment #22 from Adam Williamson <awilliam@xxxxxxxxxx> --- Looks like a couple more test blips in the scratch build :/ two in x86_64, one in ppc64le. Not the same ones. They kinda look like timing issues to me, if anything, they don't leap out as being Python 3.13-related or anything. Might be a case where we should just throw builds until one sticks, or disable more tests :/ Doing a review on this...rpmlint outputs: [adamw@xps13a tmp]$ rpmlint python* =================================================================================== rpmlint session starts =================================================================================== rpmlint: 2.5.0 configuration: /usr/lib/python3.12/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-legacy-licenses.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml checks: 32, packages: 4 python-distributed.src: E: spelling-error ('Dask', '%description -l en_US Dask -> Ask, Task, Cask') python-distributed.src: E: spelling-error ('dask', '%description -l en_US dask -> ask, desk, disk') python3-distributed.aarch64: E: spelling-error ('Dask', '%description -l en_US Dask -> Ask, Task, Cask') python3-distributed.aarch64: E: spelling-error ('dask', '%description -l en_US dask -> ask, desk, disk') python3-distributed.s390x: E: spelling-error ('Dask', '%description -l en_US Dask -> Ask, Task, Cask') python3-distributed.s390x: E: spelling-error ('dask', '%description -l en_US dask -> ask, desk, disk') python-distributed.spec: W: patch-not-applied Patch0: 0009-get_ip-handle-getting-0.0.0.0-2554.patch python-distributed.spec: W: patch-not-applied Patch0: 0009-get_ip-handle-getting-0.0.0.0-2554.patch python3-distributed.aarch64: W: no-manual-page-for-binary dask-scheduler python3-distributed.aarch64: W: no-manual-page-for-binary dask-ssh python3-distributed.aarch64: W: no-manual-page-for-binary dask-worker python3-distributed.s390x: W: no-manual-page-for-binary dask-scheduler python3-distributed.s390x: W: no-manual-page-for-binary dask-ssh python3-distributed.s390x: W: no-manual-page-for-binary dask-worker python3-distributed.aarch64: E: no-binary python3-distributed.s390x: E: no-binary ============================================= 3 packages and 1 specfiles checked; 8 errors, 8 warnings, 39 filtered, 8 badness; has taken 1.4 s ============================================== The spelling-error is obviously false, the patch-not-applied also seems to be some kind of blip (the patch is listed as Patch: not Patch0:, and the spec uses %forgeautosetup -p1 so it should be applied). no-manual-page-for-binary is legit enough, I guess, if there is one we should package it, if not we should request it upstream. no-binary is because the python3-distributed package is arched. There is a comment in the spec: # We have an arched package to detect arch-dependent issues in dependencies, # but all of the installable RPMs are noarch and there is no compiled code. but that seems to not be accurate, it seems to have been copied from python-dask.spec, but the python3 subpackage doesn't have `BuildArch: noarch` as it does in python-dask.spec. (Though it's actually a lie for python-dask now too, since the "+foo" subpackages are arched). Probably needs fixing. "MUST: The package must meet the Packaging Guidelines" - well, it seems to violate "All patches should have an upstream bug link or comment". The only comment before the first three patches is "Fedora specific?" - that doesn't explain what they do, why they're Fedora specific (i.e. not upstreamable), and it's not even clear that comment applies to all three patches. 0005-Loosen-up-some-dependencies.patch has no comment. The comment for 0008-Avoid-using-sys.prefix-in-CLI-test.patch does not list an upstream reference or clearly explain why it's downstream-only. Personally I would also include short descriptions of each patch as well as PR links, but that's more a personal preference. "MUST: The License field in the package spec file must match the actual license. See Licensing Guidelines: Valid License Short Names" - I don't think this is fully met. First off, new spec files must use SPDX license identifiers, and "BSD" isn't one, according to https://spdx.org/licenses/ - you need to use a more specific identifier for exactly what flavor of BSD license this is. Second, there seem to be files in the package under licenses other than BSD: distributed/compatibility.py and distributed/threadpoolexecutor.py contain code under the Python license, and distributed/http/static/js/anime.min.js and distributed/http/static/js/reconnecting-websocket.min.js are under the MIT license. These licenses must also be listed, in SPDX style. "SHOULD: your package should contain man pages for binaries/scripts. If it doesn’t, work with upstream to add them where they make sense. See Packaging Guidelines: Manpages" - see above. I think those are all the outstanding issues I can see. Marking NEEDINFO for those to be worked on. -- 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=1686307 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%201686307%23c22 -- _______________________________________________ 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
