here goes, also moved all patches to ${FILESDIR} as distfiles is a bad patch for bugfix patches.
Created attachment 7557 [details] fam-oss-2.6.9-r1.ebuild
Created attachment 7558 [details] ChangeLog
Created attachment 7559 [details] digest-fam-oss-2.6.9-r1
Created attachment 7560 [details] dnotify.patch
Created attachment 7561 [details, diff] dnotifyfix.patch
Once again, its a glibc-2.3 problem, which are fixed in 2.3.2 CVS versions. If we fix it like this now, we will have issues when 2.3.2 is out again. Ill rather see if I can get glibc-2.3.1 patched to fix this.
fam-oss-2.6.9.ebuild works for me, but fam-oss-2.6.9-r1.ebuild consistently fails with g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\"/etc/fam.conf\" -march=pentium3 -O3 -pipe -c -o RPC_TCP_Connector.o `test -f RPC_TCP_Connector.c++ || echo './'`RPC_TCP_Connector.c++ g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\"/etc/fam.conf\" -march=pentium3 -O3 -pipe -c -o Scanner.o `test -f Scanner.c++ || echo './'`Scanner.c++ g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\"/etc/fam.conf\" -march=pentium3 -O3 -pipe -c -o Scheduler.o `test -f Scheduler.c++ || echo './'`Scheduler.c++ Scheduler.c++:37: uninitialized const member `Scheduler::IOTypeInfo::iotype' Scheduler.c++:38: uninitialized const member `Scheduler::IOTypeInfo::iotype' make[2]: *** [Scheduler.o] Error 1 make[2]: Leaving directory `/home/store/tmpPortage/portage/fam-oss-2.6.9-r1/work/fam-2.6.9/fam' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/store/tmpPortage/portage/fam-oss-2.6.9-r1/work/fam-2.6.9' make: *** [all] Error 2 !!! ERROR: app-admin/fam-oss-2.6.9-r1 failed. !!! Function src_compile, Line 57, Exitcode 2 !!! emake failed My emerge info (if it helps) is: Portage 2.0.46-r9 (, gcc-3.1.1, glibc-2.2.5-r6,2.2.5-r7) ================================================================= System uname: 2.4.20-gentoo-r1 i686 Pentium III (Coppermine) GENTOO_MIRRORS="http://www.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/home/store/tmpPortage" PORTDIR_OVERLAY="" USE="x86 3dnow gif jpeg libg++ mikmod mmx mpeg ncurses nls pdflib png qtmt quicktime xml2 xv zlib gdbm berkdb slang readline tetex svga tcltk java sdl tcpd pam libwww ssl perl python imlib oggvorbis motif opengl scanner kde -gnome -avi -ggi -dvd -xmms ldap -encode crypt -gtk -gtk2 apm pcmcia cups X qt arts -alsa -esd oss mozilla spell truetype gpm" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O3 -pipe" CXXFLAGS="-march=pentium3 -O3 -pipe" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="" AUTOCLEAN="no" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache" Not sure what other info to supply. Let me know if I can help further!
Additional: The new ebuild comments out the line patch -p1 < ${FILESDIR}/${PF}-gcc3.patch || die in src_unpack(). If I put if back in (and copy the old patch file to the required new name) then it builds fine for me. Now of course maybe that line is commented out for a good reason which I am unaware of!! Sean
The GCC patch was commented out because I didn't see it doing anything on my machines which are all GCC3 based, I assumed it was bogus (or fixed in the later gcc versions). It didn't on my main machine cause a small compile error, but if it works for you by all means apply it - hell it doesn't seem like the devs like this solution anyways (I agree glibc is kinda at fault here - but a fix is none the less a fix). as I said, it compiled for me without, you might want to change -O3 to -O2 - mostly because -O3 is generally overkill and will infact not make your system faster, it tends to inline everything and what not... In other news, I see that you are running gentoo-2.4.20-r1 which has the imon patch, use that and copy the headers ($kernel/include/linux/imon.h) into /usr/include/linux/ - and you should be fine, this is the best option, since imon has less overhead than dnotify.
The ebuild works OK on an up-to-date 1.4-rcX box (gcc 3.2.1), but fails on my up-to-date but 'only' 1.2-ish box, with gcc 3.1.1. Have you tried it with a 3.1 gcc? That would be interesting. Knocking down the optimisation didn't seem to help - it's one of the first things I tried originally (as one tends to automatically do!!!) I'll look into the imon stuff - thanks for that. pip pip.
ehh, ~ the fam-oss in portage already has a fix for this (at least for me and a couple of testers it worked fine) and that one is much easier then all this patchwork. Can you give it a try ? hmm second look, it did the same thing. It has been there for a while now, why didn't i know about this bug and why didnt you check the tree ;) Anyway, the gcc3 patch i also uncommented since it works fine as it is with 3.2, officially we don't support 3.1 but i suppose i could put it back in, it does no harm. So i think i can close this bug ? Any comments ?
*** Bug 10071 has been marked as a duplicate of this bug. ***
This may or may not be a problem with fam, but... gnome-theme-manager (from gnome-base/control-center-2.2.0.1) does not run if fam is running. If you turn fam off, it works. Restarting fam breaks it again. From what I've seen, when fam is on, gnome-theme-manager makes one complete TCP connection (i.e. both sides close the connection), after which gnome-theme-manager hangs. strace reveals that is it is hanging on a fam-related UNIX socket. I'll include this as an attachment.
Created attachment 8010 [details] strace -e trace=network,write gnome-theme-manager Note that gnome-theme-manager connects to fam via a TCP socket (795), then connects to fam via a UNIX socket, and then proceeds to write out a bunch of stuff, and then hangs/blocks apparently in I/O wait.
is not related, and the gnome ebuild mentions this fact at the end it is a known problem, if you want to open a bug about it.. go ahead, but isn't the place.
Putting this fix in for the next release. If it turns out to give problems with a newer glibc reopen.
