https://bugzilla.redhat.com/show_bug.cgi?id=2126785 Björn Persson <bjorn@xxxxxxxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mark.e.fuller@gmx | |.de) --- Comment #9 from Björn Persson <bjorn@xxxxxxxxxxxxxxxxxxxx> --- Points 1, 3, 4, 6, 8, 9, 10, 11, 13, 14, 15, 17, 18, 19, 20, 22, 23 and 24 are fixed. These are unresolved: 2: You turned the -common subpackage into the main package as I suggested, but you left two Requires and one Summary tag behind. Those are now just text that is part of the description. You can't have tags in a %description section. 5: Other than the License tag in the spec, the licensing situation has not improved. I see some changes have been committed upstream, but those aren't in the source package. Even in the Github repository it's still unclear which files the MIT license in usbrelay_py/LICENSE applies to. 7: The explicit dependency on hidapi is gone, but only by accident as "Requires: hidapi" is only text in the description. Delete that line, or explain why the automatic dependency is insufficient. 12: py3_shebang_flags is still not used. Try passing the pathname to py3_shebang_fix. 16: "Requires: systemd-udev" is nonfunctional because it's only text in the description. 21: I see no news about signature verification. So the signing code in the makefile is unused then? I noticed one thing that I missed previously: 25: The -mqtt subpackage should be tagged "BuildArch: noarch" as it contains only arch-independent files. Four new issues have appeared: 26: For Python libraries there is a policy that the Fedora package's name should contain the canonical project name. Now that the library is on PyPI as "usbrelay-py" (which correctly matches the module name), that defines the canonical project name as "usbrelay-py", so the subpackage should be called "python3-usbrelay-py" instead of "python3-usbrelay". (The policy says only "should" though, not "must".) 27: Since you removed the %generate_buildrequires section, pyproject_buildrequires is now executed in the %prep section. I don't think it does anything useful outside of a %generate_buildrequires section. 28: Installing the packages creates the group too late: Installing : hidapi-0.12.0-2.fc37.x86_64 Installing : usbrelay-1.1-1.fc37.x86_64 Installing : python3-usbrelay-1.1-1.fc37.x86_64 Installing : hidapi-devel-0.12.0-2.fc37.x86_64 Installing : python3-paho-mqtt-1.6.1-4.fc37.noarch Running scriptlet: usbrelay-mqtt-1.1-1.fc37.x86_64 Installing : usbrelay-mqtt-1.1-1.fc37.x86_64 warning: group usbrelay does not exist - using root warning: group usbrelay does not exist - using root Running scriptlet: usbrelay-mqtt-1.1-1.fc37.x86_64 Installing : usbrelay-devel-1.1-1.fc37.x86_64 Running scriptlet: usbrelay-devel-1.1-1.fc37.x86_64 Creating group 'usbrelay' with GID 982. That seems related to this RPMlint warning: usbrelay-mqtt.x86_64: W: empty-%pre The %pre scriptlet was supposed to create the group, but does nothing because sysusers_create_compat didn't output any commands. This goes a bit beyond my knowledge. I think sysusers_create_compat is executed during macro expansion, before the tarball is unpacked, so usbrelay.sysusers doesn't exist yet. It may also be that it has another working directory than you expected, so the relative pathname is wrong. It may be possible to avoid sysusers_create_compat and instead run systemd-sysusers in a suitable scriptlet after usbrelay is installed but before usbrelay-mqtt is installed. I'm asking for help on the devel list. 29: When I start the daemon without any relays connected, SystemD tries to restart it several times until it reaches a restart limit. That's not review-blocking but are you sure that's what you want? -- 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=2126785 _______________________________________________ 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
