https://bugzilla.redhat.com/show_bug.cgi?id=1451407
Nick Clifton <ni...@redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(ni...@redhat.com) |
--- Comment #4 from Nick Clifton <ni...@redhat.com> ---
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@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
