https://bugzilla.redhat.com/show_bug.cgi?id=2265862 --- Comment #8 from Peter Pentchev <roam@xxxxxxxxxxx> --- Spec URL: https://download.copr.fedorainfracloud.org/results/roam/spiped/fedora-rawhide-x86_64/07189163-spiped/spiped.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/roam/spiped/fedora-rawhide-x86_64/07189163-spiped/spiped-1.6.2-2.fc41.src.rpm (In reply to Artur Frenszek-Iwicki from comment #7) > > Group: Applications > Not used in Fedora. > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_tags_and_sections No idea how I missed that one; I swear I looked through the list of tags that should not be used... thanks! > > Source0: https://www.tarsnap.com/spiped/spiped-1.6.2.tgz > This makes it necessary to update the URL every time you bump the package to > a new version. > Consider using the %{version} macro as part of the URL. > https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ > #_using_version OK, this is a funny one, since I already do that in a couple of other specfiles for internal consumption. But yeah, I had missed it in this one. Thanks! > > Patch0: install.patch > Please add a comment describing what the patch does. > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_patch_guidelines Right, I guess I am used to other packaging systems where it is accepted that the patch files themselves will contain both a one-line comment and a longer description. Yeah, I admit I must have missed that part in the guidelines. > > %check > > %{__make} test > Using macro forms of system executables is discouraged. > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_macros Yep, I was a bit unsure about that one, too; I guess I thought that using an internal macro was somehow better than not using a macro at all and, I don't know, allowing the use of an alternative make(1) implementation? But yeah, apparently that is not the common thinking. Thanks for pointing it out. > > %files > > %{_mandir}/man1/spipe.1.gz > > %{_mandir}/man1/spiped.1.gz > Do not assume man pages will be gzipped. Use a wildcard that can match any > compression format (including no compression). > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_manpages Yeah, again, I guess I am used to other packaging systems where it is pretty much a rule that manual pages must be gzipped during the build. But yeah, the guidelines do not say that, true. Thanks a lot for your review! There is a new copr build with fixes for these issues. G'luck, Peter -- 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=2265862 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202265862%23c8 -- _______________________________________________ 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
