While emerging dev-db/qdbm-1.8.33, portage fails with the following; making executable: /usr/lib/libjqdbm.so.1.0.0 making executable: /usr/lib/libqdbm.so.11.5.0 QA Notice: the following files contain insecure RUNPATH's Please file a bug about this at http://bugs.gentoo.org/ For more information on this issue, kindly review: http://bugs.gentoo.org/81745 /var/tmp/portage/qdbm-1.8.33/work/qdbm-1.8.33/perl/depot/../..:/lib usr/lib/perl5/site_perl/5.8.7/sparc-linux/auto/Depot/Depot.so /var/tmp/portage/qdbm-1.8.33/work/qdbm-1.8.33/perl/curia/../..:/lib usr/lib/perl5/site_perl/5.8.7/sparc-linux/auto/Curia/Curia.so /var/tmp/portage/qdbm-1.8.33/work/qdbm-1.8.33/perl/villa/../..:/lib usr/lib/perl5/site_perl/5.8.7/sparc-linux/auto/Villa/Villa.so !!! ERROR: dev-db/qdbm-1.8.33 failed. !!! Function dyn_install, Line 1058, Exitcode 0 !!! Insecure binaries detected !!! If you need support, post the topmost build error, NOT this status message.
Created attachment 70203 [details, diff] makeMake is bad
This patch WORKSFORME
i havent looked, but cant you add that var to RUNENV rather than changing every call to `make` ?
hattya, please bump with patch
Created attachment 70293 [details, diff] qdbm-runpath.patch how about this instead
SpanKY: we'll probably have to commit that ourselves as hattya looks kinda MIA.
Fixed in CVS.
Still broke, same thing as originally posted.
Guess we are stuck here. Jason: the first version of the patch was fixing it for you ?
Correct, the original patch works for me on the systems where it has been problema tic. Some more notes on that; I have three systems I've been testing this on (x86, amd64 and sparc64). All systems are running up to date ~arch systems which are updated on a daily basis and all have the perl use flag enabled. The ~x86 and ~sparc64 systems are running 32 bit userlands where the ~amd64 system is running a 64 bit userland. All have pax-utils installed. The ~amd64 system has not had a single problem with qdbm at all, before and after the patch. However both the ~x86 and ~sparc64 systems have had problems with the unpatched qdbm and the patched version currently in portage. The first patch in this bug (cuurrently labeled makeMake is bad), works on those two systems though.
vapier: We'll probably go with the "makeMake is bad" patch if you don't see why yours failed.
hattya: could you apply the "makeMake is bad" patch instead ? Looks like it's the only one that solves it.
in CVS.
Jason: can you confirm it's ok with the one in CVS ? hattya: could you revbump the ebuild so that people affected pick up the change in normal upgrades ?
The ebuild currently in portage fails in the same fashion. Also, it appears to still be using the second patch.
Yes, the patch in CVS looks unchanged. Hattya, could you please doublecheck and commit the "makemake is bad" attached patch ?
Sorry, I forgot to commit... In CVS now.
Thx Hattya. Arches please test and mark stable.
amd64 stable
x86 done
Stable on SPARC
Alpha stabled.
Marked ppc64 stable. In testing with FEATURES="test" the tests did fail like so: LD_LIBRARY_PATH=.:/lib:/usr/lib:/var/tmp/portage/homedir/lib:/usr/local/lib ./cbtest misc <Miscellaneous Test> Checking serialization of list ... ok Checking serialization of map ... ok Checking string utilities ... ok Checking encoding utilities ... ok Checking date utilities ... ./cbtest: W3CDTF formatter is invalid make: *** [check] Error 1 !!! ERROR: dev-db/qdbm-1.8.33-r2 failed. Does this warrant any attention? 1.8.30 failed in a similar fashion. I will leave ppc64 on the cc and we can discuss or split off to a different bug.
Stable on ppc.
Apparently ppc64 stable keyword was lost somewhere along the way.
Remarked stable; I dont know what happened. The above stated test failure still exists however.
Ready for GLSA. About the test failure: probably better to open a separate bug about it, since we'll close this one when the security part will be done.
GLSA 200511-02 ia64 should mark stable to benefit from GLSA
