https://bugzilla.redhat.com/show_bug.cgi?id=1451407 Nick Clifton <nickc@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(nickc@xxxxxxxxxx) | --- Comment #4 from Nick Clifton <nickc@xxxxxxxxxx> --- Hi Stephen, > Apologies for the delay on this. Things got hectic. No worries - thanks very much for taking the time to run the review. > tl;dr: work needed (see Issues:) No surprises there - this is my first contribution. :-) Anyway, on to the review. I have created an updated version of the submissions which addresses most of the points raised: Spec URL: https://nickc.fedorapeople.org/annobin.spec SRPM URL: https://nickc.fedorapeople.org/annobin-2.0-1.fc26.src.rpm > Issues: > ======= > - All build dependencies are listed in BuildRequires, except for any that > are listed in the exceptions section of Packaging Guidelines. > Note: These BR are not needed: gcc gcc-c++ > See: http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 OK, I will remove them. (Does it matter if they are present ?) (FYI: I know that the Fedora Review Guidelines webpage contains that link above, but the Exceptions_2 entry on the Guidelines page does not actually specify which requirements can be omitted from the BuildRequires tag). > - Some content found to have MIT/X11 (BSD like) licenses. This needs to be in > the License: field OK, this is now done. Note - the fedora-review tool flags quite a few files as "Unknown or generated". I assume that I can ignore these. Also it flags the LICENSE file as having "*No copyright* GPL (v3)". I assume that this is OK too. > - Why are you explicitly excluding the LICENSE and COPYING3 files? Those need > to be installed with the %license macro I was basing my annobin.spec file on the spec file used by the odb package. (This is another gcc plugin, so it seemed like a good idea at the time). That package excludes the LICENSE/COPYING3 files and does not have a %license entry, so I thought that that was the correct thing to do for plugins. Anyway I have now corrected this issue and added the %license entry. > - This package does not own some of the directories it requires or alternately > depend on a package that requires it. In all likelihood, you need to have this > package `Requires: gcc` to ensure that its directory structure is properly > owned. I also doubt anyone would want to install this plugin without also > having gcc available. True. > - /usr/lib/gcc/x86_64-redhat-linux/7/plugin is also owned by gcc-gdb-plugin. > This is *not* a blocker, but it's worth asking the gcc folks if they should > just have this owned by some common package if it's going to start being used > by multiple plugins. Oh how I wish... :-) Does Fedora support meta-packages ? Ie could we have a gcc-plugin meta package that owns this directory, and maybe a documentation directory as well. It could also link somehow to each of the currently existing gcc plugin packages. In a related note, I have been trying to get the gcc folks to take more responsibility for plugins, and to start treating them as an official part of the compiler. But so far I have been blocked each time I try. Plugins are seen as being a bit of a mess and not suitable for inclusion in a real compiler project. :-( > - Drop the %clean section; it's not required on any supported version of Fedora > or EPEL anymore Done. > [!]: Final provides and requires are sane (see attachments). Umm, not sure what needs to be done here. Could you provide me with a pointer or two please ? > [!]: %check is present and all tests pass. I have not done this (yet) as I am still trying to work out a clean way to test the plugin. I hope however that this is not a showstopper. > annobin.x86_64: W: no-documentation This should be done. > annobin.x86_64: W: no-manual-page-for-binary built-by.sh > annobin.x86_64: W: no-manual-page-for-binary check-abi.sh > annobin.x86_64: W: no-manual-page-for-binary hardened.sh These are shell scripts. As such I have tried to make them self-documenting. Is there a way to tell rpmlint that this is the situation ? Cheers Nick -- 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 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
