* QA Notice: The following files contain writable and executable sections * Files with such sections will not work properly (or at all!) on some * architectures/operating systems. A bug should be filed at * http://bugs.gentoo.org/ to make sure the issue is fixed. * For more information, see http://hardened.gentoo.org/gnu-stack.xml * Please include the following list of files in your report: * Note: Bugs should be filed for the respective maintainers * of the package in question and not hardened@g.o. * RWX --- --- usr/lib64/opera/opera Since it is a bin, please hide it.
I would have fixed that already but it seems QA_EXECSTACK is ignored, so I can't think I can simply "hide" it.
The QA_EXECSTACK variable is supposed to be handled by scanelf from app-misc/pax-utils, but it seems like some of its handling for QA_* variables has been broken in recent releases. What version of pax-utils do you observe the problem with?
use QA_PREBUILT rather than setting specific QA vars
(In reply to comment #3) 24 Sep 2012; Mike Frysinger <vapier@gentoo.org> opera-12.02.1578.ebuild: QA_DT_HASH (old/deprecated) -> QA_FLAGS_IGNORED (new hotness). So what was that? Is that now old too?
Fixed in every opera{,-next} ebuild that will stick around for a while.
(In reply to comment #4) that was purely mechanical to remove a variable that's been deprecated for a long time. i wanted to finally clean it up since people weren't doing it themselves. i didn't look at anything else in packages other than grepping the tree and running sed.
*** Bug 448846 has been marked as a duplicate of this bug. ***
So should it be set in the global scope of the ebuild now? I get different results on different systems with QA_* exported in src_prepare().
I think it was always supposed to be global-scope.
The QA_* variables have always been intended to be set in global scope. People who set the variables in phases typically do it in order to specify the exact paths of files, but they should really be using wildcards to match them instead.
(In reply to comment #9) ^^^ that
OK, should be fixed now.
