First: $ esc /usr/bin/esc: line 4: cd: /usr/lib/esc-1.0.0: No such file or directory /usr/bin/esc: line 5: ./esc: No such file or directory s/lib/lib64/ in /usr/bin/esc gets around that. Then, on startup: $ esc Unable to create nspr log file '/home/devel/notting/.redhat/esc/esc.log' [ dialog ] Alert e TypeError: Components.classes['@redhat.com/rhTray'] has no properties nullTypeError: Components.classes['@redhat.com/rhCoolKey'] has no properties At this point it appears hung.
Jack, dozer is an x86_64 machine. There is probably a some libdir values hard coded to .../lib/xxx rather then %libdir. bob
Bob, I should be able to easily fix the launch script by doing something like cd $(rpm --eval '%{_libdir}') It looks like it won't let esc write the log file into his esc profile directory created by xulrunner. If xulrunner itself can't write the user's profile that might explain the second set of symptoms.
It might be better if the build or install process crated a modified shell script. That way you don't depend on rpm itself. Then the question is what is the deal with permissions. Can you test this on dozer when you've made the changes? bob
For simplicity sake. I've come up with another solution simply changing the script: arch64=$(/bin/uname -m | grep 64 if [ $arch64 ] ; then cd /usr/lib64/esc-1.0.0 else cd /usr/lib/esc-1.0.0 A redhat magazine article spoke explicitly about scripts making use of the "uname -m" command and making decisions accordingly.
That will break on ia64, as libdir there is /usr/lib. Plus, s390x is 64 bit. Ugh, need to get the magazine articles fixed.
Jack, The simple thing is start with esc.script. In the RPM do something like. sed -e 's;\$LIBDIR;'%{_libdir}';g' esc.script > $path_for_esc/esc This will replace $LIBDIR with the %_libdir from rpm. bob
Have obtained the use of a machine to test this problem. Currently working on the fix. +devel_ACK