Hello, On Tue, 13 Mar 2012, Philipp Thomas wrote:
On Tue, 13 Mar 2012 02:09:58 +0100, Christian Boltz
wrote: ERROR: RPATH "" on /home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-126.20.i386/usr/lib/perl5/vendor_perl/5.14.2/i586-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so is not allowed ERROR: RPATH "" on /home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-126.20.i386/usr/lib/perl5/vendor_perl/5.14.2/i586-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so is not allowed
RPATH sets the path the runtime linker will search when resolving dependencies. This is only needed when the libs don't reside in a standard directory. Having RPATH point to the buildroot is plain wrong as it'll never work. How you fix that with perl tools I don't know, so someone knowledgable like David needs to chime in :-) GONGGGGGGGGG
That's not a job for me. As it is definitely a bug in /usr/lib/rpm/brp-suse.d/brp-35-rpath, but ATM I'm too tired to even think about filing that bug. The perl-Module LibAppArmor.so is clean, no rpath, as 'strings' tells me. Now. Let's see what that script does, I do this in the osc/build chroot ... ==== brp-35-rpath : lines 18 - 44 ====
HAD_ERRORS=0 # check RPATH for bad directories for FILE in $(find $RPM_BUILD_ROOT -type f \( -perm -0100 -o -perm -0010 -o -perm -0001 \) 2>/dev/null); do
Result (among others I suspect): ./home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-0.x86_64/usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so
for RPATH_VAL in $(objdump -p "$FILE" 2>/dev/null | egrep -w '(RPATH|RUNPATH)' | awk '{ print $2 ":"}'); do
grusum:/> set -x grusum:/> objdump -p ./home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-0.x86_64/usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so [..] Dynamic Section: NEEDED libapparmor.so.1 NEEDED libc.so.6 RPATH RUNPATH INIT 0x0000000000003a60 [..] grusum:/> RPATH_VAL=$(objdump -p ./home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-0.x86_64/usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so | egrep -w '(RPATH|RUNPATH)' | awk '{ print $2 ":"}') ++ objdump -p ./home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-0.x86_64/usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so ++ egrep -w '(RPATH|RUNPATH)' ++ awk '{ print $2 ":"}' + RPATH_VAL=': :'
if [ "${RPATH_VAL:0:7}" = "\$ORIGIN" ]; then continue;fi
while [ -n "$RPATH_VAL" ]; do
### $RPATH_VAL is twice non empty
RPATH_VAL_NXT=${RPATH_VAL%%:*}
grusum:/> RPATH_VAL_NXT=${RPATH_VAL%%:*} + RPATH_VAL_NXT= HERE's is the bug. There's a test missing for RPATH_VAL_NXT being empty.
RPATH_VAL=${RPATH_VAL##$RPATH_VAL_NXT:}
grusum:/> RPATH_VAL=${RPATH_VAL##$RPATH_VAL_NXT:} + RPATH_VAL=' :' ok, now, we're supposed to have "pruned" one "dir" of rpaths from RPATH_VAL ...
test -d "$RPATH_VAL_NXT" && RPATH_VAL_NXT=$(cd ${RPATH_VAL_NXT//#\/\//\/}; pwd -P)
'test -d' fails as $RPATH_VAL_NXT is empty, rest of the line is ignored.
case ":$RPATH_VAL_NXT" in :/usr/lib*) ;; :/lib*) ;; :/opt/*/lib*) ;; :/usr/X11R6/lib*) ;; *)
still empty ...
echo "ERROR: RPATH \"$RPATH_VAL_NXT\" on $FILE is not allowed" HAD_ERRORS=1
... error.
esac done done done
==== Proposed patch: ==== --- ./usr/lib/rpm/brp-suse.d/brp-35-rpath.orig 2012-03-13 04:39:06.000000000 +0100 +++ ./usr/lib/rpm/brp-suse.d/brp-35-rpath 2012-03-13 04:43:38.000000000 +0100 @@ -24,6 +24,7 @@ while [ -n "$RPATH_VAL" ]; do RPATH_VAL_NXT=${RPATH_VAL%%:*} RPATH_VAL=${RPATH_VAL##$RPATH_VAL_NXT:} + test -z "$RPATH_VAL_NXT" && continue test -d "$RPATH_VAL_NXT" && RPATH_VAL_NXT=$(cd ${RPATH_VAL_NXT//#\/\//\/}; pwd -P) case ":$RPATH_VAL_NXT" in ==== I've just run the package through a 'osc build --no-init' (against Factory) and it's clean except some unrelated 25 rpmlint warnings (BTW: who the ... came up with the "macro-in-comment" check?): ==== WARNING: '/usr/lib/rpm/brp-desktop.data/applications-kmenuedit.menu' does not exist calling /usr/lib/rpm/brp-suse.d/brp-35-rpath calling /usr/lib/rpm/brp-suse.d/brp-40-rootfs ==== Philipp, could you please forcefully push above patch to the guys responsible for the brp stuff? I'm up for 22h now and my 5th beer of the night curiously seems to have vanished while I was innocently debugging the problem and writing this mail ... Weird that, eh? -dnh, Christian auch hier nochmal rüberwinkend ;) PS: long mail make tolerate long sig, no? ("random" is an alias) PPS: or the alternate patch: ==== --- ./usr/lib/rpm/brp-suse.d/brp-35-rpath.orig 2012-03-13 04:39:06.000000000 +0100 +++ ./usr/lib/rpm/brp-suse.d/brp-35-rpath 2012-03-13 04:43:38.000000000 +0100 @@ -24,6 +24,7 @@ while [ -n "$RPATH_VAL" ]; do RPATH_VAL_NXT=${RPATH_VAL%%:*} RPATH_VAL=${RPATH_VAL##$RPATH_VAL_NXT:} + test -n "$RPATH_VAL_NXT" || continue test -d "$RPATH_VAL_NXT" && RPATH_VAL_NXT=$(cd ${RPATH_VAL_NXT//#\/\//\/}; pwd -P) case ":$RPATH_VAL_NXT" in ==== whatever the devs prefer ;) -- They ARE right, you CAN secure an IIS against intrusion. First you turn off all the services and other hooks that lets it do all the things they brag on that makes IIS "better", then you imbed an axe in the machine, then you unplug it, encase it in glass, put it in a concrete vault, cover that with urethane, and toss the whole thing into the depest part of the ocean, cover it with 150 meters of silt, create a concrete sarcophogus over the silt pile, and liberally seed the area with spent nuclear fuel to kill anything that gets too close to it. No problem. -- random -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org