https://bugzilla.redhat.com/show_bug.cgi?id=2112474 --- Comment #15 from Maxwell G <gotmax@e.email> --- (In reply to John Snow from comment #11) > Remaining items to handle, as I understand them: > > TLDR: > > - License is fine despite rpmlint chirps, AFAIK Correct. rpmlint hasn't been updated to follow the new licensing guidelines. > - Need man pages for CLI scripts I'd recommend manpages for your users, but this is not a requirement. It's a SHOULD guideline, not a MUST. > - Might need gpgverify (?) You only need to use %gpgverify if upstream already provides signed tarballs. You can ignore this. > - Need to integrate tests into a check phase, but there are dep problems. What dependencies are missing? You should run tests if it's possible/practical. If not, you should at least use %pyproject_check_import. This serves as a basic smoke test by trying to import all public modules. > 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+. You definitely do not need to do that to get the package into Fedora. They are unknown, because the license scanner can't detect a license if there's no license header. That doesn't really mean anything. > 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. For Fedora, the only license that really matters is the license of the actual installed content. The License tag does not need to account for other files in the source tarball that aren't installed. > > [ ]: 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. Yes, that is valid. > [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 Irrelevant. > python3-qemu-qmp.noarch: W: invalid-license GPL-2.0-only > python3-qemu-qmp.noarch: W: invalid-license LGPL-2.0-or-later You can ignore that, as I've explained. > 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 Not a requirement, as I've explained. > 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 See above. > python-qemu-qmp.src: W: invalid-license GPL-2.0-only > python-qemu-qmp.src: W: invalid-license LGPL-2.0-or-later See above. > (Did the old macros generate these ...?) No, they do not. > [ ]: %check is present and all tests pass. > > "SHOULD". ... but I do have tests, so I will attempt to wire them up here. Yes, you should do that if possible. > 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. Correct. The guidelines actually explicitly state that linting tools shouldn't be run in the RPM package. > I currently rely on avocado-framework >= 90, but I suppose > 92.x (the "LTS" release) isn't packaged for F36 yet. Yes, you'll have to edit the metadata to relax this requirement. -- 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
