I did the upgrade steps to go to 1.4rc_1 from 1.2. The end result was a mostly stable system (well, the libcompat file contained the wrong version of libstdc++-libc, but anyways). So, I've been trying to update gnome2 with little success. Emerging any gnome2 related package, including scrollkeeper, causes a portage violation of the following: mkdir /var/tmp/portage/scrollkeeper-0.3.11-r1/image/var/log PATH="/sbin:/usr/sbin:/usr/lib/portage/bin:/bin:/usr/bin:/usr/local/bin:/opt/bin:/opt/rar:/opt/RealPlayer8:/usr/X11R6/bin:/opt/sun-jdk-1.4.0/bin:/opt/sun-jdk-1.4.0/jre/bin:/usr/qt/3/bin:/usr/qt/2/bin:/usr/kde/3/bin:/usr/kde/3/bin:/var/tmp/portage/scrollkeeper-0.3.11-r1/image//usr/bin" ; \ echo "`date +\"%b %d %X\"` Installing ScrollKeeper `scrollkeeper-config --version`..." >> /var/tmp/portage/scrollkeeper-0.3.11-r1/image//var/log/scrollkeeper.log PATH="/sbin:/usr/sbin:/usr/lib/portage/bin:/bin:/usr/bin:/usr/local/bin:/opt/bin:/opt/rar:/opt/RealPlayer8:/usr/X11R6/bin:/opt/sun-jdk-1.4.0/bin:/opt/sun-jdk-1.4.0/jre/bin:/usr/qt/3/bin:/usr/qt/2/bin:/usr/kde/3/bin:/usr/kde/3/bin:/var/tmp/portage/scrollkeeper-0.3.11-r1/image//usr/bin" ; \ /var/tmp/portage/scrollkeeper-0.3.11-r1/image//usr/bin/scrollkeeper-rebuilddb -q -p /var/tmp/portage/scrollkeeper-0.3.11-r1/image//var/lib/scrollkeeper ACCESS DENIED mkdir: /portage . . . --------------------------- ACCESS VIOLATION SUMMARY ---------------------------LOG FILE = "/tmp/sandbox-scrollkeeper-0.3.11-r1-28743.log" mkdir: /portage -------------------------------------------------------------------------------- I've done an emerge -e gnome, and it emerges all the way up to scrollkeeper and generates the same Access Violation. emerge -C scrollkeeper; emerge scrollkeeper produces: . . . >>> Installing catalog... >>> Rebuilding Scrollkeeper database... /usr/bin/scrollkeeper-rebuilddb: line 47: 18504 Segmentation fault scrollkeeper-update $quiet $verbose -p $scrollkeeper_db_dir >>> Updating Scrollkeeper database... /usr/sbin/ebuild.sh: line 9: 18507 Segmentation fault scrollkeeper-update -v >&${T}/foo >>> Regenerating /etc/ld.so.cache... . . Now, the Seg fault is caused by there being no /var/lib/scrollkeeper. However, premaking /var/lib/scrollkeeper doesn't cause emerge scrollkeeper to not generate the error. Making one then running scrollkeeper-update does successfully run the update. However, emerging anything gnome2 related, including scrollkeeper, produces the previously mentioned issue. My default compile options are "-mathlon -O3 -pipe". I've ran emerge scrollkeeper with "-O2" and "-O0". Neither have helped with the segfaults or access violations. I'm using gcc 3.2 (big surprise), have an Athlon 950Mhz CPU, and an ample amount of RAM. Kernel is 2.4.19-crypto-r7. Not sure what else to mention except the compiles themselves look to be fine, it just seems that scrollkeeper is writing to /portage instead of I'd assume ./portage for some reason. Any ideas on fixing this beyond starting completely over would be appreciated.
Well, i can't reproduce this and i can't really see what is going wrong. The only thing i noticed is you using crypto sources. Could some kernel settings you use have anything todo with it ?
The only kernel settings I'm using that could hypothetically cause problems would be maybe preemptive kernel or the crypto, though I don't see how those relates at all. My portage tempdir isn't on a crypto drive.
Well i don't see it either. But scrollkeeper works fine for me, and thats the only difference in setup as far as i can see. But i suppose it's not so easy to stop using crypto sources ? Can you disable those kernel options and try without them ? Well as a simple solution you could probably disable sandbox in /etc/make.globals , but i would like to go to the bottom of this with your help.
I've discovered the cause of the segfault and the weird error. Scrollkeeper is either misconcatenating or segfaulting when libsafe is in /etc/ld.so.preload. Removing it resolves the problem, but obviously this is either a bug in scrollkeeper or libsafe. I filed a bug report with scrollkeeper stating such, so hopefully it will be fixed so I can use libsafe more. Libsafe = yummy.
