https://bugzilla.redhat.com/show_bug.cgi?id=1451407 --- Comment #5 from Stephen Gallagher <sgallagh@xxxxxxxxxx> --- (In reply to Nick Clifton from comment #4) ... > > 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 ?) > They're not harmful. Actually I meant not to include that in the final list of issues, but forgot to delete it. > (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). > Yeah, actually in retrospect it's probably better to include them, on the off-chance they ever got removed from the default buildroot. > > > - 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. > Don't assume that the "Unknown or generated" ones are ignorable. Best to double-check. In general, we assume that if they have no license information, they're covered by the project license. > > > - 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. > Thanks > > > - 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. As I said, this isn't a blocker, but it's completely acceptable to have a subpackage like `foo-filesystem` that contains only empty directory structures and have packages depend on that. It's recommended that anything that supports plugins should have either the main package or a -filesystem package provide the necessary framework. > > 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. :-( > Above my pay-grade. > > > - 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 ? > Sorry, I should have mentioned that this was just fallout from not having `Requires: gcc` > > > [!]: %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. > This is non-blocking. It's a SHOULD criterion. I marked it as [!] because %check wasn't present. > > > 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 ? > They're warnings, not errors. It's mostly a reminder in case you forgot to package the manual. -- 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
