Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
these ebuilds have RESTRICT=stricter: dev-java/sun-jdk/sun-jdk-1.2.2.017.ebuild dev-java/sun-jdk/sun-jdk-1.3.1.17.ebuild dev-java/sun-jdk/sun-jdk-1.4.2.10-r2.ebuild dev-java/sun-jdk/sun-jdk-1.5.0.06-r2.ebuild dev-java/sun-jre-bin/sun-jre-bin-1.4.2.10.ebuild dev-java/sun-jre-bin/sun-jre-bin-1.5.0.06-r2.ebuild dev-java/sun-jre-bin/sun-jre-bin-1.5.0.06.ebuild dev-java/sun-jre-bin/sun-jre-bin-1.4.2.10-r2.ebuild games-fps/ut2004/ut2004-3369-r2.ebuild games-fps/ut2004/ut2004-3369-r4.ebuild net-www/netscape-flash/netscape-flash-7.0.63.ebuild x11-drivers/ati-drivers/ati-drivers-8.24.8.ebuild x11-drivers/ati-drivers/ati-drivers-8.22.5.ebuild x11-drivers/ati-drivers/ati-drivers-8.23.7.ebuild x11-drivers/ati-drivers/ati-drivers-8.21.7.ebuild x11-drivers/ati-drivers/ati-drivers-8.21.7-r1.ebuild if you have a binary and you want to ignore execstack warnings because you cant get upstream to fix the bug, then do this: QA_EXECSTACK_x86="usr/bin/retarded usr/lib/libsuck.so"
(In reply to comment #0) > > if you have a binary and you want to ignore execstack warnings because you cant > get upstream to fix the bug, then do this: > QA_EXECSTACK_x86="usr/bin/retarded usr/lib/libsuck.so" > Would it be possible to modify QA_TEXTRELS handling so that the files don't need to be on one line? It is impossible to keep the line lenght reasonable if I have to put all the binaries one one line. gawk: cmd. line:1: BEGIN { split("opt/sun-jre-bin-1.4.2.10/lib/i386/libawt.so gawk: cmd. line:1: ^ unterminated string ebuild: PLUGIN_DIR="opt/${P}/plugin/i386" QA_TEXTRELS="opt/${P}/lib/i386/libawt.so ${PLUGIN_DIR}/ns4/libjavaplugin.so ${PLUGIN_DIR}/ns610/libjavaplugin_oji.so ${PLUGIN_DIR}/ns610-gcc32/libjavaplugin_oji.so"
there is another bug open for your ideas. Search for QA_TEXTREL in the summary. hopefully we will be able to cut a new release later today.
ut2004 done...
some more bad packages: sci-chemistry/ccp4/ccp4-6.0.1.ebuild sci-chemistry/ccp4/ccp4-6.0.1-r1.ebuild nichoj: i thought i showed you have to fix the java packages ;)
In ccp4, I'm not doing it to fix executable stacks. I need portage's autofixing of rpath/runpath because the build system is too screwed for me to do anything else about it.
sun-jre-bin and sun-jdk were taken care of at some point.
x11-base/xorg-server/xorg-server-1.0.2-r7.ebuild:RESTRICT="stricter" x11-base/xorg-server/xorg-server-1.1.0-r1.ebuild:RESTRICT="stricter" x11-base/xorg-server/xorg-server-1.1.99.903.ebuild:RESTRICT="stricter" x11-base/xorg-server/xorg-server-1.2.99.0.ebuild:RESTRICT="stricter" x11-base/xorg-server/xorg-server-1.1.1-r2.ebuild:RESTRICT="stricter" x11-base/xorg-server/xorg-server-1.1.1-r1.ebuild:RESTRICT="stricter" x11-base/xorg-server/xorg-server-1.1.1.ebuild:RESTRICT="stricter" x11-drivers/ati-drivers/ati-drivers-8.28.8.ebuild:RESTRICT="nostrip multilib-pkg-force stricter" x11-drivers/ati-drivers/ati-drivers-8.29.6.ebuild:RESTRICT="nostrip multilib-pkg-force stricter" x11-drivers/ati-drivers/ati-drivers-8.30.3-r1.ebuild:RESTRICT="nostrip multilib-pkg-force stricter" x11-drivers/ati-drivers/ati-drivers-8.30.3.ebuild:RESTRICT="nostrip multilib-pkg-force stricter" x11-drivers/ati-drivers/ati-drivers-8.27.10-r1.ebuild:RESTRICT="nostrip multilib-pkg-force stricter" net-www/netscape-flash/netscape-flash-7.0.63.ebuild:RESTRICT="nostrip stricter" media-libs/mesa/mesa-6.5-r4.ebuild:RESTRICT="stricter" media-libs/mesa/mesa-6.5.2_pre20061102.ebuild:RESTRICT="stricter" media-libs/mesa/mesa-6.5.1-r2.ebuild:RESTRICT="stricter" media-libs/mesa/mesa-6.5-r3.ebuild:RESTRICT="stricter" media-libs/mesa/mesa-6.5.1-r1.ebuild:RESTRICT="stricter" media-libs/mesa/mesa-6.4.2-r2.ebuild:RESTRICT="stricter" app-emulation/vmware-workstation/vmware-workstation-5.5.3.34685.ebuild:RESTRICT="stricter strip" app-emulation/vmware-workstation/vmware-workstation-4.5.3.19414-r7.ebuild:RESTRICT="stricter strip" app-emulation/vmware-player/vmware-player-1.0.2.29634.ebuild:RESTRICT="stricter strip" sci-chemistry/ccp4/ccp4-6.0.1-r1.ebuild:RESTRICT="mirror stricter" sci-chemistry/ccp4/ccp4-6.0.1-r1.ebuild:# >=sys-apps/portage-2.1.1_pre1 for RESTRICT=stricter sci-chemistry/ccp4/ccp4-6.0.2.ebuild:RESTRICT="mirror stricter" sci-chemistry/ccp4/ccp4-6.0.2.ebuild:# >=sys-apps/portage-2.1.1_pre1 for RESTRICT=stricter sci-chemistry/ccp4/ccp4-6.0.1.ebuild:RESTRICT="mirror stricter" sci-chemistry/ccp4/ccp4-6.0.1.ebuild:# >=sys-apps/portage-2.1.1_pre1 for RESTRICT=stricter net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.0.5-r1.ebuild:RESTRICT="fetch stricter" net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.6.02.0030.ebuild:RESTRICT="fetch stricter" net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.6.00.0045-r1.ebuild:RESTRICT="fetch stricter" net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.0.3b-r4.ebuild:RESTRICT="fetch stricter" net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.7.00.0640.ebuild:RESTRICT="fetch stricter" net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.8.00.0490.ebuild:RESTRICT="fetch stricter" net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.6.03.0190-r1.ebuild:RESTRICT="fetch stricter" net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.0.1a-r1.ebuild:RESTRICT="fetch stricter" dev-java/diablo-jre-bin/diablo-jre-bin-1.5.0.07.00.ebuild:RESTRICT="fetch stricter"
Adding bsd, who handles dev-java/diablo-jre-bin.
diablo-jre-bin done.
latest portage code no longer respects RESTRICT=stricter since every aspect of it can be handled properly via other QA means
(In reply to comment #10) > latest portage code no longer respects RESTRICT=stricter since every aspect of > it can be handled properly via other QA means OK. How do I force portage to always fix RPATH?
xorg-server has the RESTRICT because it installs setuid and lazy bindings. I see the actual die in misc-functions.sh is commented out now, but it doesn't look as if there is any allowance made for packages that must do this. Similar goes for mesa ... upstream has no intention of fixing the TEXTRELs because it's under the impression that will hurt performance. So should these two packages (as well as the one I previously mentioned, ccp4) just always die when FEATURES=stricter? That sounds like a crappy solution.
you cant force portage to *workaround* broken RPATHs, you should be fixing your packages ignore lazy bindings for now (which is why i've commented out the die message), so there is no issue there TEXTRELs should obviously be handled via the QA_TEXTREL variable
(In reply to comment #13) > you cant force portage to *workaround* broken RPATHs, you should be fixing your > packages Impossible, unless someone pays me to work on it full-time for a month. It requires an overhaul of the entire build system of a complex, multi-language 60M package. I'll just copy the same code into my ebuild, then. Yay for duplication. > TEXTRELs should obviously be handled via the QA_TEXTREL variable OK, thanks for informing me about this variable. I had never heard of it before, so it's unclear how obvious this was.
umm, no ... you open bugs to track the issue where your packages have broken RPATHs inserting scanelf calls for people who are using FEATURES=stricter is not a fix and does not change the fact the package is broken and there should be a bug tracking it
(In reply to comment #15) > umm, no ... you open bugs to track the issue where your packages have broken > RPATHs > > inserting scanelf calls for people who are using FEATURES=stricter is not a fix > and does not change the fact the package is broken and there should be a bug > tracking it > Donnie, you can also do FEATURES="-stricter" for specific ebuilds in your bashrc. I doubt many people (read: users) actually use stricter. Although if vapier/solar/qa-crazy-people aren't willing to fix it; I don't see a reason to remove RESTRICT=stricter functionality.
chrpath?
(In reply to comment #17) > chrpath? What would be the point? If he needs auto fixing of rpaths he can call out scanelf from the ebuild itself (same crap as chrpath but smarter). However vapier is right. It should be fixed. (In reply to comment #16) > Donnie, you can also do FEATURES="-stricter" for specific ebuilds in your > bashrc. I doubt many people (read: users) actually use stricter. Although if > vapier/solar/qa-crazy-people aren't willing to fix it; I don't see a reason to > remove RESTRICT=stricter functionality. We have been submitting fixes for this stuff for years.. Fact of the mater is it's probably never going to be fixed properly no mater how many times we submit patches or spend our time to fixing it.
that's a lame position to take ... your package is broken and so it's up to the QA people to fix it ? i dont think so how you prioritize it yourself is up to you and whoever wants to fix it can
(In reply to comment #10) > latest portage code no longer respects RESTRICT=stricter since every aspect of > it can be handled properly via other QA means In #gentoo-portage irc discussion everyone seems to think we should keep support for RESTRICT=stricter. I don't see any alternative unless we are going to actually punt those ebuilds from the tree. At least RESTRICT=stricter serves as a record indicating packages that have known issues. Without support for RESTRICT=stricter, it will just make FEATURES=stricter so annoying that it discourages people from enabling it. If necessary, I suppose we can add the ability to mask ebuilds with RESTRICT=stricter (so that people can make sure they don't install them).
if you mask problems people will simply continue to ignore them FEATURES=stricter is for people who are looking into issues, not the general public the only people the removal of it affects are those running FEATURES=stricter and trying to install *broken packages* that have insecure RPATHs which is exactly what should be happening
OK, is there some file I can use similar to package.use, package.mask et al. to simply deactivate stricter on arbitrary package tokens?
(In reply to comment #22) > OK, is there some file I can use similar to package.use, package.mask et al. to > simply deactivate stricter on arbitrary package tokens? > I actually don't know. since stricter is enforce bash side you may be able to get away with using the profile.bashrc from base: for conf in ${PN} ${PN}-${PV} ${PN}-${PV}-${PR}; do [[ -r ${PORTAGE_CONFIGROOT}/etc/portage/env/${CATEGORY}/${conf} ]] \ && . ${PORTAGE_CONFIGROOT}/etc/portage/env/${CATEGORY}/${conf} done Thus /etc/portage/env/cat/PN can contain FEATURES="-stricter" and it *may* make it to the bash env; and thus turn off these checks. I'd have to test it though. It certainly can't affect any python code as the profile.bashrc is sourced far too late in the process.
(In reply to comment #23) > Thus /etc/portage/env/cat/PN can contain FEATURES="-stricter" Actually, instead of FEATURES="-stricter", you have to do something more like this: export FEATURES=${FEATURES/stricter/}
OK, how do I tell portage to ignore setXid lazy bindings? This is why the vmware-* stuff is listed, and is also an issue with the cisco-vpnclient-3des ebuilds. Yes, it no longer fails, but I'm now subject to getting bugs on this and the packages are binary. I've removed RESTRICT=stricter from all of the ebuilds.
like i said, you can ignore setuid bugs now ... mark em as dupes of Bug 71609
x11-base/xorg-server/xorg-server-1.2.99.0.ebuild:RESTRICT="stricter" x11-base/xorg-server/xorg-server-1.2.0-r1.ebuild:RESTRICT="stricter" x11-base/xorg-server/xorg-server-1.2.0.ebuild:RESTRICT="stricter" x11-base/xorg-server/xorg-server-1.1.1-r4.ebuild:RESTRICT="stricter" x11-base/xorg-server/xorg-server-1.1.1-r1.ebuild:RESTRICT="stricter" x11-drivers/ati-drivers/ati-drivers-8.28.8.ebuild:RESTRICT="nostrip multilib-pkg-force stricter" x11-drivers/ati-drivers/ati-drivers-8.29.6.ebuild:RESTRICT="nostrip multilib-pkg-force stricter" x11-drivers/ati-drivers/ati-drivers-8.32.5.ebuild:RESTRICT="nostrip multilib-pkg-force stricter test" x11-drivers/ati-drivers/ati-drivers-8.30.3-r1.ebuild:RESTRICT="nostrip multilib-pkg-force stricter" x11-drivers/ati-drivers/ati-drivers-8.30.3.ebuild:RESTRICT="nostrip multilib-pkg-force stricter" x11-drivers/ati-drivers/ati-drivers-8.27.10-r1.ebuild:RESTRICT="nostrip multilib-pkg-force stricter" media-libs/mesa/mesa-6.5.2-r1.ebuild:RESTRICT="stricter" media-libs/mesa/mesa-6.5-r3.ebuild:RESTRICT="stricter" media-libs/mesa/mesa-6.5.1-r4.ebuild:RESTRICT="stricter" media-libs/mesa/mesa-6.5.2.ebuild:RESTRICT="stricter" media-libs/mesa/mesa-6.5.1-r1.ebuild:RESTRICT="stricter" app-emulation/vmware-player/vmware-player-1.0.2.29634.ebuild:RESTRICT="stricter strip" sci-chemistry/ccp4/ccp4-6.0.1-r1.ebuild:RESTRICT="mirror stricter" sci-chemistry/ccp4/ccp4-6.0.2.ebuild:RESTRICT="mirror stricter" net-wireless/ipw3945d/ipw3945d-1.7.22-r4.ebuild:RESTRICT="stricter"
net-wireless/ipw3945d is taken care of.
All fixed during RESTRICT clean up.
