Hi, I recently switched to unicode described in the gentoo doc http://www.gentoo.org/doc/en/utf-8.xml. revdep-rebuild --soname libncurses.so.5 emerges all packages but the install progress of the files isnt shown instead only this error comes up: sandbox:main signal SIGQUIT already had a handler ... I let it compile all packages, but if I run revdep-rebuild --soname libncurses.so.5 again, it wants to emerge all packages again. take a look at http://forums.gentoo.org/viewtopic-t-783728.html. I already posted there my problem. here is the full revdep-rebuild output: http://dpaste.com/71070/ Reproducible: Always Steps to Reproduce: 1.changed systeminfo as described at http://www.gentoo.org/doc/en/utf-8.xml (rc.conf locales etc.) 2.changed useflag +unicode and changed some (+ and -) other flags I dont remember, sorry 3.emerge -e system, emerge -e world 4.revdep-rebuild --soname libncurses.so.5 -> every emerge by revdep-rebuild says: sandbox:main signal SIGQUIT already had a handler ... Actual Results: here is the full revdep-rebuild output: http://dpaste.com/71070/ Expected Results: No error msg: sandbox:main signal SIGQUIT already had a handler ... revdep-rebuild should only run once and compile packages cleanly
That's two independent issues. First one is that sandbox prints a warning. That can be ignored. Second one is revdep-rebuild not managing to fix things on your system. For that one we need a bit more info - what packages is it trying to emerge?
(In reply to comment #1) > That's two independent issues. First one is that sandbox prints a warning. That > can be ignored. > > Second one is revdep-rebuild not managing to fix things on your system. For > that one we need a bit more info - what packages is it trying to emerge? > It wants many packages to emerge. The full revdep-rebuild log is here: http://dpaste.com/71070/ and here is my emerge --info: dampframme - 16:23:56 - ~ - 503. # emerge --info Portage 2.1.6.13 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.9_p20081201-r2, 2.6.29-gentoo-r5-mephisto x86_64) ================================================================= System uname: Linux-2.6.29-gentoo-r5-mephisto-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-glibc2.2.5 Timestamp of tree: Sat, 25 Jul 2009 11:15:02 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 2.1.8-r1 dev-lang/python: 2.5.4-r3 dev-util/cmake: 2.6.4 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=nocona -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/oss-overlay /usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi amd64 avahi bash-completion berkdb bzip2 cairo cdda cddb cdparanoia cdr cli cracklib crypt css cups dbus dga dri dts dvd dvdr dvdread encode exif ffmpeg firefox flac fontconfig fortran ftp gcj gd gdbm gif gnome gnustep gpm gtk hal hddtemp iconv icq ieee1394 ipv6 isdnlog java javascript jpeg jpeg2k lm_sensors matroska midi mime mmap mmx mmxext mp3 mp4 mpeg mplayer mudflap multilib nautilus ncurses nls nptl nptlonly nsplugin nvidia objc offensive ogg openal opengl openmp oss pam pcre pdf perl png pppd python readline recode reflection samba sdl session smp snmp speex spl sse sse2 ssl ssse3 sysfs tcpd theora tiff truetype unicode usb vcd vdpau videos vim-syntax wmf x264 xine xml xorg xpm xulrunner xv xvid xvmc zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 199341 [details] revdep-rebulid log I have went ahead and uploaded the pastebined log to bugzilla. We prefer logs and such to be attached to the bugs as it makes life easier and removes the chances of the logs getting lost.
James: Thanks for attaching the log Jochen: I suspect this is not 2 separate issues, but rather sandbox crashing during the install phase so that revdep-rebuild is not really able to re-install the packages. You could check the timestamps on files belonging to packages that were supposed to be rebuilt, and see if they were really re-installed. If it turns out my theory is right, the first thing to try is upgrading to a newer sandbox - say the latest testing version, 2.0.
(In reply to comment #4) > James: Thanks for attaching the log > > Jochen: I suspect this is not 2 separate issues, but rather sandbox crashing > during the install phase so that revdep-rebuild is not really able to > re-install the packages. You could check the timestamps on files belonging to > packages that were supposed to be rebuilt, and see if they were really > re-installed. > > If it turns out my theory is right, the first thing to try is upgrading to a > newer sandbox - say the latest testing version, 2.0. > I did a revdep-rebuild --soname libncurses.so.5 again yesterday. It finished with: >>> Installing (38 of 38) x11-terms/gnome-terminal-2.24.2-r1 sandbox:main signal SIGQUIT already had a handler ... * Updating desktop mime database ... * Updating shared mime info database ... * Updating scrollkeeper database ... * Installing GNOME 2 GConf schemas * Reloading GConf schemas ... [ ok ] * Updating desktop mime database ... * Updating shared mime info database ... * Updating scrollkeeper database ... sandbox:main signal SIGQUIT already had a handler ... >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * Regenerating GNU info directory index... * Processed 149 info files. * Build finished correctly. Removing temporary files... * * You can re-run revdep-rebuild to verify that all libraries and binaries * are fixed. Possible reasons for remaining inconsistencies include: * orphaned files * deep dependencies * packages installed outside of portage's control * specially-evaluated libraries rm: cannot remove `2_ldpath.rr': No such file or directory dampframme - 23:40:53 - ~ - 505. # The files of gnome-terminal have the same date: dampframme - 16:47:18 - ~ - 510. # ls -l /usr/bin/gnome-t* -rwxr-xr-x 1 root root 238672 2009-07-28 23:40 /usr/bin/gnome-terminal So, looks like the files get installed
Ok, how about you upgrade to testing sandbox and verify the message goes away, and then we can change the bug subject line and assign this to portage tools team.
Created attachment 199741 [details] full revdep-rebuild log with sandbox-2.0 sandbox:main signal SIGQUIT already had a handler ... comes up with sandbox 2.0, too. It compiles the packages atm. I will let you know when it completes and if it wants to emerge again
Created attachment 199745 [details] afterstep failed ACCESS VIOLATION hrmm now the 8th package x11-wm/afterstep-2.2.4 fails with ACCESS VIOLATION I think the main reason is: ACCESS DENIED open_wr: /etc/ld.so.cache~ make[1]: *** [install.dyn] Error 137 See the attachment for full log. ls -l /etc: -rw-r--r-- 1 root root 148390 2009-07-31 16:09 ld.so.cache -rw------- 1 root root 0 2009-07-31 16:11 ld.so.cache~
Yesterday I updated my system with eix-sync and emerge -uDN world. After that I ran revdep-rebuilt with no options. It recompiled vlc. There were those sandbox SIGQUIT messages, too. But I reran revdep-rebuilt and all was clean. So it has to be something wrong with that lib libncurses.so.5.
Wait a second... what's your actual problem here? When I'm not completely wrong, running revdep-rebuild --soname libncurses.so.5 several times will always re-emerge every package that is linked against libncurses.so.5. That's the intention behind the --soname/--library switch. Regarding the sandbox message, simply ignore it. That message will hopefully vanish in a future version of the sandbox.
(In reply to comment #10) > Wait a second... what's your actual problem here? > > When I'm not completely wrong, running > > revdep-rebuild --soname libncurses.so.5 > > several times will always re-emerge every package that is linked against > libncurses.so.5. That's the intention behind the --soname/--library switch. > > Regarding the sandbox message, simply ignore it. That message will hopefully > vanish in a future version of the sandbox. > ermm, then whats the point of revdep-rebuilt if it rebuilts every time?!? If a system is clean, there should be no rebuild!
(In reply to comment #11) > (In reply to comment #10) > > Wait a second... what's your actual problem here? > > > > When I'm not completely wrong, running > > > > revdep-rebuild --soname libncurses.so.5 > > > > several times will always re-emerge every package that is linked against > > libncurses.so.5. That's the intention behind the --soname/--library switch. > > > > Regarding the sandbox message, simply ignore it. That message will hopefully > > vanish in a future version of the sandbox. > > > > ermm, then whats the point of revdep-rebuilt if it rebuilts every time?!? > If a system is clean, there should be no rebuild! Then stop using --soname/--library switch. On my system, which has no linking issues, I get a big list of packages as well when I run revdep-rebuild --library libncurses.so.5 This is intended behaviour. If you want to be sure there are no more linking issues on your system simply run revdep-rebuild -i and see if that wants to rebuild anything.
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > Wait a second... what's your actual problem here? > > > > > > When I'm not completely wrong, running > > > > > > revdep-rebuild --soname libncurses.so.5 > > > > > > several times will always re-emerge every package that is linked against > > > libncurses.so.5. That's the intention behind the --soname/--library switch. > > > > > > Regarding the sandbox message, simply ignore it. That message will hopefully > > > vanish in a future version of the sandbox. > > > > > > > ermm, then whats the point of revdep-rebuilt if it rebuilts every time?!? > > If a system is clean, there should be no rebuild! > > Then stop using --soname/--library switch. On my system, which has no linking > issues, I get a big list of packages as well when I run > > revdep-rebuild --library libncurses.so.5 > > This is intended behaviour. > If you want to be sure there are no more linking issues on your system simply > run > > revdep-rebuild -i > > and see if that wants to rebuild anything. > Yep, that runs cleanly. But how do you then if the deps of a lib is OK if revdep recompiles every time?!
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #10) > > > > Wait a second... what's your actual problem here? > > > > > > > > When I'm not completely wrong, running > > > > > > > > revdep-rebuild --soname libncurses.so.5 > > > > > > > > several times will always re-emerge every package that is linked against > > > > libncurses.so.5. That's the intention behind the --soname/--library switch. > > > > > > > > Regarding the sandbox message, simply ignore it. That message will hopefully > > > > vanish in a future version of the sandbox. > > > > > > > > > > ermm, then whats the point of revdep-rebuilt if it rebuilts every time?!? > > > If a system is clean, there should be no rebuild! > > > > Then stop using --soname/--library switch. On my system, which has no linking > > issues, I get a big list of packages as well when I run > > > > revdep-rebuild --library libncurses.so.5 > > > > This is intended behaviour. > > If you want to be sure there are no more linking issues on your system simply > > run > > > > revdep-rebuild -i > > > > and see if that wants to rebuild anything. > > > > Yep, that runs cleanly. But how do you then if the deps of a lib is OK if > revdep recompiles every time?! > Like I said. When revdep-rebuild -i won't reemerge anything, your libs are sane. The --soname/--librabry switch is forcing a rebuild of any package that links against the given library. That's the intention behind those switches.
I gonna mark this bug as INVALID as the reported behavior of revdep-rebuild is no bug.
