Summary: | www-client/opera-12.10.1652 : usr/lib64/opera/opera contains RWX sections | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | New packages | Assignee: | Jeroen Roovers (RETIRED) <jer> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dev-portage, flameeyes, solar, vapier |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=404003 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Agostino Sarubbo
2012-11-06 19:37:34 UTC
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. |