Description of problem: I have a package which contains Lua binary files (.lc) which prevents it from being arch-independent. Running rpmlint on the package's rpm files, however, gives a "no-binary" error. I think rpmlint should properly detect Lua binary files compiled via luac and not report an error. The package with this problem is Billiards (review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=919867) Version-Release number of selected component (if applicable): rpmlint-1.4-11.fc18.noarch
Fixed upstream: http://sourceforge.net/p/rpmlint/code/ci/be327c1 Note that because of this: > I have a package which contains Lua binary files (.lc) which prevents it from > being arch-independent. ...you cannot ship the *.lc files in /usr/share, they need to be somewhere in /usr/lib(64) instead. After the above fix, rpmlint will start whining "arch-dependent-file-in-usr-share" for each of them.
(In reply to comment #1) > Fixed upstream: http://sourceforge.net/p/rpmlint/code/ci/be327c1 Thanks, Ville! Just a side-note: I was surprised when I learned that rpmlint's upstream is SourceForge. Everything (Top 10 results of Google search, the URL of rpmlint's .spec file) points to http://rpmlint.zarb.org. Should I file a bug report about this? > Note that because of this: > > > I have a package which contains Lua binary files (.lc) which prevents it from > > being arch-independent. > > ...you cannot ship the *.lc files in /usr/share, they need to be somewhere > in /usr/lib(64) instead. After the above fix, rpmlint will start whining > "arch-dependent-file-in-usr-share" for each of them. Thanks for pointing this out.
(In reply to comment #2) > Just a side-note: I was surprised when I learned that rpmlint's upstream is > SourceForge. Everything (Top 10 results of Google search, the URL of > rpmlint's .spec file) points to http://rpmlint.zarb.org. Should I file a bug > report about this? No need, migration from zarb.org to sf.net is in progress, and the old rpmlint.zarb.org homepage will be updated soonish.
(In reply to comment #3) > No need, migration from zarb.org to sf.net is in progress, and the old > rpmlint.zarb.org homepage will be updated soonish. Ok, no problem. Should this bug be closed as UPSTREAM or should we wait for the fix to land in Fedora's rpmlint?
That'd be up to the Fedora rpmlint maintainers, I'm sure they'll take care of this as they feel appropriate. I suppose it's about time to roll a new upstream release soonish.
rpmlint-1.4-14.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/rpmlint-1.4-14.fc18
rpmlint-1.4-14.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/rpmlint-1.4-14.fc17
Package rpmlint-1.4-14.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing rpmlint-1.4-14.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-4646/rpmlint-1.4-14.fc18 then log in and leave karma (feedback).
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
rpmlint-1.4-14.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
rpmlint-1.4-14.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.