I'm getting an infinite loop in what I assume is ./configure with gnome-media-2.14.2 I am not sure where to start, since I know C but not autoconf. ... checking for VUMETER... yes checking for GSR... yes checking for GStreamer 0.10 playbin plugin... [infinite loop here: never continues.]
Aha, I thought of a way to partially diagnose: ps axf output excerpted, then ps l27598 (that is the lower case of PS L27598), then psl27597, then strace -f emerge gnome-media: 25753 0:01 \_ /usr/bin/python -O /usr/bin/emerge gnome-media 25989 0:00 \_ tee -i -a /t/portage/log/8889-gnome-media-2.14.2.log 25990 0:00 \_ [gnome-media-2.14.2] sandbox /usr/lib/portage/bin/ebuild.sh compile 25991 0:00 \_ /bin/bash /usr/lib/portage/bin/ebuild.sh compile 26099 0:00 \_ /bin/sh ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-ipv6 --disable-esdtest --disable-gtk-doc --build=i686-pc-linux-gnu 27597 0:00 \_ /usr/bin/gst-inspect-0.10 playbin 27598 0:00 \_ /usr/bin/gst-inspect-0.10 playbin ps l27598 F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 5 0 27598 27597 30 14 15912 7192 pipe_w SN+ pts/3 0:00 /usr/bin/gst-inspect-0.10 playbi so stuck in pipe wait. from what? hmm so psl27597: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 0 0 27597 26099 31 14 5196 1988 wait SN+ pts/3 0:00 /usr/bin/gst-inspect-0.10 playbi stuck in wait. strace -f emerge gnome-media: ends in: (taps fingers, foot, waits patiently ... god autoconf sucks (it's so slow and convoluted)) and 1 minute and 21 seconds of 2.80GHz P4 CPU for just the strace process (also screen did a lot of CPU) later: [pid 29856] stat64("/tmp/portage/gnome-media-2.14.2/work/gnome-media-2.14.2", {st_mode=S_IFDIR|S_ISGID|0755, st_size=1400, ...}) = 0 [pid 29856] stat64(".", {st_mode=S_IFDIR|S_ISGID|0755, st_size=1400, ...}) = 0 [pid 29856] getpid() = 29856 [pid 29856] getppid() = 1 [pid 29856] getpgrp() = 27951 [pid 29856] rt_sigaction(SIGCHLD, {0x80810bd, [], 0}, {SIG_DFL}, 8) = 0 [pid 29856] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 [pid 29856] lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=656, ...}) = 0 [pid 29856] lstat64("/usr/libexec", {st_mode=S_IFDIR|0755, st_size=2224, ...}) = 0 [pid 29856] lstat64("/usr/libexec/gconfd-2", {st_mode=S_IFREG|0755, st_size=18, ...}) = 0 [pid 29856] open("/usr/libexec/gconfd-2", O_RDONLY|O_LARGEFILE) = 3 [pid 29856] ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf8c5768) = -1 ENOTTY (Inappropriate ioctl for device) [pid 29856] _llseek(3, 0, [0], SEEK_CUR) = 0 [pid 29856] read(3, "#!/bin/sh\nexit $?\n", 80) = 18 [pid 29856] _llseek(3, 0, [0], SEEK_SET) = 0 [pid 29856] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 [pid 29856] dup2(3, 255) = 255 [pid 29856] close(3) = 0 [pid 29856] fcntl64(255, F_SETFD, FD_CLOEXEC) = 0 [pid 29856] fcntl64(255, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE) [pid 29856] fstat64(255, {st_mode=S_IFREG|0755, st_size=18, ...}) = 0 [pid 29856] _llseek(255, 0, [0], SEEK_CUR) = 0 [pid 29856] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 [pid 29856] read(255, "#!/bin/sh\nexit $?\n", 18) = 18 [pid 29856] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 [pid 29856] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 [pid 29856] exit_group(0) = ? Process 29856 detached OHHH hmm, I disabled gconfd-2 by renaming it, since it was hanging out in my process list, I don't know what it does, and I saw it a lot when I wasn't running GNOME (like when I start mozilla, etc.). It bothers me enough that even when I let it try to behave, it still gets disabled by me every time it gets upgraded by portage within hours even though I didn't know it was one of the packages upgraded. Trying without gconfd-2 disabled: it's compiling. Ok, I will resolve the bug, but PLEASE consider getting rid of gconfd-2. It infects the system. Not sure if the infection is debilitating, but it is an infection.
I think it isn't really "fixed", so I'm "re-opening" it so I can "resolve works-for-me" it.
It is resolved, but I don't think it's fixed, because it will continue to be a problem whenever that infection of gconfd-2 comes up missing.
Just fyi, gconfd-2 is an integral part of gnome : it keeps track of all your settings. Killing or renaming it is not a good idea.
