We have a few noarch packages containing files in /usr/lib64: $ urpmf --media "Core 32bit Release" /usr/lib64 -f | cut -d':' -f1 | sort -u cleanfeed-20020501-8.mga1.noarch mingw32-filesystem-49-3.mga1.noarch nagios-check_ssl_cert-1.9.1-2.mga1.noarch orca-2.32.1-1.mga1.noarch virtualbox-doc-4.0.6-3.mga1.noarch This is incorrect, and upload of such packages should be blocked by buildsystem, likely using rpmlint
I think this is a more specific issue of the "package create a unowned directory" problem, so maybe by widening the scope ( wth a youri check ), we could solve more issues. By they way, all of them are likely buggy : cleanfeed:/usr/lib64/news/bin/control/filter_innd.pl orca:/usr/lib64/python2.7/site-packages/orca/scripts/toolkits/VCL.py virtualbox-doc:/usr/lib64/virtualbox/UserManual.pdf nagios-check_ssl_cert:/usr/lib64/nagios/plugins/check_ssl_cert mingw32-filesystem:/usr/lib64/mingw32-scripts On the other hand : orca.noarch: W: noarch-python-in-64bit-path /usr/lib64/python2.7/site-packages/orca/chnames.py and the other are likely FHS violation already trapped by rpmlint.
CC: (none) => misc
(/usr/lib64/virtualbox/UserManual.pdf is where VirtualBox -> Help -> Contents expects the pdf to be, of course that won't work on i586, and I shouldn't have made it noarch. I think/hope it could be patched to use /usr/share/doc/virtualbox, I'll see what I can do in that regard).
(virtualbox fixed in SVN, now the pdf is in the /usr/share/doc/virtualbox).
CC: (none) => dmorganecAssignee: sysadmin-bugs => qa-bugs
Any suggestions on how qa should test this, or can this bug be closed?
CC: (none) => davidwhodgins
ping sysadmin :)
I added a check on noarch-python-in-64bit-path,
Stormi can you test this one please.
Olivier too please.
This bug can be closed, there is no package to test, a rpmlint check now blocks package submit when they have noarch python scripts in 64 bits lib path.
Status: NEW => RESOLVEDCC: (none) => stormiResolution: (none) => FIXED