https://bugzilla.redhat.com/show_bug.cgi?id=2112474 --- Comment #11 from John Snow <jsnow@xxxxxxxxxx> --- OK, thanks for the feedback. I've reworked the spec file to match the template Miro pointed out a bit more closely, but I kept the pkg_name and pypi_name macro definitions for now based on Alfredo's comment. I removed RFC comments that have been addressed in the discussion here. https://people.redhat.com/~jsnow/v2/python-qemu-qmp.spec https://people.redhat.com/~jsnow/v2/python-qemu-qmp-0.0.1-1.fc36.src.rpm I split out the docs into a subpackage. I didn't see this laid out in https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ so I took a wild stab at it. Remaining items to handle, as I understand them: TLDR: - License is fine despite rpmlint chirps, AFAIK - Need man pages for CLI scripts - Might need gpgverify (?) - Need to integrate tests into a check phase, but there are dep problems. At length: [ ]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "GNU Library General Public License, Version 2.0", "GNU General Public License, Version 2", "*No copyright* GNU General Public License, Version 2 GNU Library General Public License v2 or later", "GNU Library General Public License v2 or later". 47 files have unknown license. Detailed output of licensecheck in /home/jsnow/src/fedora/jsnow-mk5/python-qemu-qmp/licensecheck.txt I suppose I'll need to update the individual files upstream with SPDX identifiers, but I can't really control that for the current version. All of the "unknown" files are intended to be licensed as LGPLv2+. One interesting piece is that the .tar.gz for the SDist on PyPI actually includes my .gitlab-ci.d files, one of which is licensed as GPLv2. I didn't really intend to distribute these files in the SDist, so I'll have to look into that. It's harmless for now, but could cause problems when I go to drop the remaining legacy GPLv2 code. Thought I'd mention it. Otherwise, I believe "GPL-2.0-only AND LGPL-2.0-or-later" to be the correct aggregate license for the software as presently bundled. The "LICENSE" file contains text that matches the 2.0 license that uses the "Library" wording and not the 2.1 "Lesser" wording. [ ]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. I assume a comment is OK. I added one. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). Rpmlint ------- Checking: python3-qemu-qmp-0.0.1-1.fc37.noarch.rpm python3-qemu-qmp-doc-0.0.1-1.fc37.noarch.rpm python-qemu-qmp-0.0.1-1.fc37.src.rpm python3-qemu-qmp.noarch: W: spelling-error %description -l en_US asyncio -> syncopation python3-qemu-qmp.noarch: W: invalid-license GPL-2.0-only python3-qemu-qmp.noarch: W: invalid-license LGPL-2.0-or-later python3-qemu-qmp.noarch: W: no-manual-page-for-binary qmp-shell python3-qemu-qmp.noarch: W: no-manual-page-for-binary qmp-shell-wrap python3-qemu-qmp-doc.noarch: W: invalid-license GPL-2.0-only python3-qemu-qmp-doc.noarch: W: invalid-license LGPL-2.0-or-later python-qemu-qmp.src: W: spelling-error %description -l en_US asyncio -> syncopation python-qemu-qmp.src: W: invalid-license GPL-2.0-only python-qemu-qmp.src: W: invalid-license LGPL-2.0-or-later 3 packages and 0 specfiles checked; 0 errors, 10 warnings. 'asyncio' is the correct spelling. The version of rpmlint I have installed locally does not seem to like the SPDX identifiers, though I see that is a very recent requirement (July 2022). The manpage warning didn't come up for me on my first draft spec; I'll have to fix this upstream to generate manual pages for each binary tool. I think Sphinx can generate manual pages, but I haven't plumbed that yet. I'll work on this. (Did the old macros generate these ...?) [ ]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. I did sign my PyPI releases with my personal (jsnow@redhat) GPG key. I'll have to look into how to do this step. I also use an expiration on my key, so I worry that I am doing this step wrong. I can change my release process for 0.0.2 if necessary. (No idea what I am doing. EAFP.) [ ]: %check is present and all tests pass. "SHOULD". ... but I do have tests, so I will attempt to wire them up here. Upstream, these tests also include PyCQA tools, but I think those should be disabled here because they will only be a nuisance in this context if the goal is to just reproduce upstream tarballs verbatim. It will also balloon the builddeps quite a bit. I currently rely on avocado-framework >= 90, but I suppose 92.x (the "LTS" release) isn't packaged for F36 yet. I'll have to look into that, sorry. (Dogfood, yip yip!) -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2112474 _______________________________________________ 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
