https://bugzilla.redhat.com/show_bug.cgi?id=1069335 --- Comment #15 from Steven Dake <sdake@xxxxxxxxxx> --- Re Comment #12: What's the path forward here? It seems like the only thing that can be done in the spec itself is to make these files +x in %files. But, these things aren't actually scripts (from what I can tell), so a patch upstream to remove the #!/usr/bin/env lines from these files should probably be sumitted. Then we can add that patch to the rpm until it is merged. Nice work. You identified the problem and what to do (submit a patch upstream). The review doesn't need to gate on this, but ideally upstream should fix this oversight. I don't think its necessary to carry a patch on top of the patch stream in the RPM to fix the rpmlint warnings as long as an upstream bug is filed by the submitter (Angus) and linked in the bugzilla for further reference. Re: openstack-ironic.noarch: E: non-readable /etc/ironic/rootwrap.conf 0640L openstack-ironic.noarch: E: non-readable /etc/ironic/policy.json 0640L openstack-ironic.noarch: E: non-readable /etc/ironic/rootwrap.d/ironic-deploy-helper.filters 0640L openstack-ironic.noarch: E: non-readable /etc/ironic/rootwrap.d/ironic-images.filters 0640L openstack-ironic.noarch: E: non-readable /etc/ironic/rootwrap.d/ironic-manage-ipmi.filters 0640L openstack-ironic.noarch: E: non-readable /etc/ironic/ironic.conf 0640L These errors are b/c the files are not world readable. That is what is desired I believe. Do we need to flag them as exceptions to rpmlint somehow? Unfortunately rpmlint doesn't have said flagging feature. It makes sense for the reviewer in this case to build the rpm and make sure /etc/ironic and /var/lib/ironic actually are installed with the uid/gid specified in the spec file before signing off on these specific rpmlint E messages. Generally if rpmlint gives an error, and you want to fedora-review+ the package, the reviewer is responsible for verifying the E is a false-negative. Re man pages, what I typically do is ask in the review for the submitter to request the upstream create manual pages for their binaries. In the case of OpenStack, the upstream doesn't seem to care, but it doesn't hurt to create said bugs anyway. Looking good James! -- 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 https://admin.fedoraproject.org/mailman/listinfo/package-review