There's no reason for sys-fs/fuse to bomb when it can't build the kernel module. It should instead build the userland utilities and merge correctly. Here is the output: $ emerge sys-fs/fuse Calculating dependencies... done! >>> Emerging (1 of 1) sys-fs/fuse-2.6.0_pre2 to / >>> checksums src_uri ;-) fuse-2.6.0-pre2.tar.gz * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found sources for kernel version: * 2.6.15-gentoo-r7 * Checking for suitable kernel configuration options... * We have detected FUSE already built into the kernel. We will continue, but we wont build the module this time. * Please check to make sure these options are set correctly. * Failure to do so may cause unexpected problems. * Once you have satisfied these options, please try merging * this package again. !!! ERROR: sys-fs/fuse-2.6.0_pre2 failed. Call stack: ebuild.sh, line 1542: Called dyn_setup ebuild.sh, line 654: Called pkg_setup ebuild.sh, line 1236: Called linux-mod_pkg_setup linux-mod.eclass, line 465: Called linux-info_pkg_setup linux-info.eclass, line 541: Called check_extra_config linux-info.eclass, line 459: Called die !!! Incorrect kernel configuration options !!! If you need support, post the topmost build error, and the call stack if relevant. -------------------------------------------------- $ emerge --info Portage 2.1_pre7-r4 (default-linux/x86/2006.0, gcc-4.1.0, glibc-2.4-r1, 2.6.15-gentoo-r7 i686) ================================================================= System uname: 2.6.15-gentoo-r7 i686 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.14 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [disabled] dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: 2.0.1-r4 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/DIR_COLORS /etc/X11/Sessions /etc/X11/app-defaults /etc/X11/dm /etc/X11/gdm /etc/X11/ion3 /etc/X11/mwm/system.mwmrc /etc/X11/rstart /etc/X11/serverconfig /etc/X11/starthere /etc/X11/sysconfig /etc/X11/xdm /etc/X11/xinit /etc/X11/xkb /etc/asciidoc /etc/bash /etc/bash_completion /etc/bash_completion.d /etc/conf.d/net.example /etc/conf.d/wireless.example /etc/cups/mime.convs /etc/cups/mime.types /etc/eselect/compiler /etc/ethereal /etc/filesystems /etc/gconf /etc/genkernel.conf /etc/gimp /etc/gnome-vfs-2.0 /etc/gtk-2.0 /etc/init.d /etc/inputrc /etc/lynx /etc/make.conf.example /etc/man.conf /etc/mplayer.conf /etc/mutt /etc/muttng /etc/nanorc /etc/networks /etc/openldap /etc/pam.d /etc/postfix/sample /etc/profile /etc/protocols /etc/screenrc /etc/services /etc/skel /etc/sound /etc/terminfo /etc/udev /etc/vim /etc/xdg /usr/kde /usr/lib/X11/xkb /etc/env.d" CXXFLAGS="-O3 -march=athlon-xp -pipe" DISTDIR="/misc/distfiles" FEATURES="autoaddcvs autoconfig cvs digest distlocks keepwork metadata-transfer noclean sandbox sfperms sign" GENTOO_MIRRORS="http://olive http://mirrors.tds.net/gentoo http://mirrors.tds.net/gentoo http://distfiles.gentoo.org" LANG="en_US.utf8" MAKEOPTS="-j4" PKGDIR="/usr/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/home/agriffis/portage" PORTDIR_OVERLAY="/home/agriffis/overlay" SYNC="false" USE="x86 X alsa apache2 apm avi bash-completion berkdb bitmap-fonts cli crypt cscope cups decss dri dvd eds emboss encode evo exif ffmpeg flac foomaticdb fortran gdbm gif gnome gphoto gstreamer gtk gtk2 imap imlib ipv6 isdnlog jack java jpeg kde ladcca lcms libg++ libwww mad mailwrapper mikmod mng motif mozcalendar mozilla mozsvg mp3 mpeg ncurses nls nptl nptlonly nsplugin ofx ogg oggvorbis opengl oss pam pcre pda pdflib perl png pppd python qdbm qt quicktime readline reflection ruby sasl sdl session spell spl ssl svg tcpd tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vorbis wmf xml xmms xorg xv zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux userland_GNU video_cards_ati video_cards_vesa video_cards_fbdev" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
Yup, this bug is back, I noticed the same yesterday... :/
workaround: edit ebuild comment line 17 in this way: #CONFIG_CHECK="@FUSE_FS:fuse" and line 50: # linux-mod_src_install [code] ebuild fuse-2.6.0_pre2.ebuild digest emerge =sys-fs/fuse-2.6.0_pre2[/code] there is another bug that even if the module is not builded, the package is still added to moduledb
This looks like mrness' commit to linux-info.eclass I can see what this commit was supposed to do, but the cleanup doesnt actually "fix" anything that I can see. I'll revert this commit now and speak with mrness. I'd actually quite appreciate any commits to linux-* and kernel-* go through me, assuming it all works correctly then I'll normally just agree but I really don't like a load of bugs assigned to me about changes which I know nothing about. Just to put it into perspective, as of my last check over 700 ebuilds use this eclass, so effects are widespread.
just to add, the moduledb thing can be worked around with a test for MODULE_NAMES containing non-null values, but until every ebuild correctly uses MODULE_NAMES this isnt going to happen. At the moment it won't change. Sorry.
My commit was trying to merge soft&hard error reports. Also it reordered the operators, making ~ (aka do not die) the first (searched before commiting it; no other ebuilds uses ~ in conjuction with ! or @). I think the fix part is quite obvious. In your implementation, the function will not die if the last test doesn't fail. To be noted: this isn't the first time I correct a mistake in linux-info.eclass. See bug #74396 comment #8 and revision 1.15 of the linux-info.eclass. I fail to see how this bug has anything to do with my commit (the ebuild die in the exact same manner regardless what linux-info.eclass revision I use), so I'll reopen it. Please rollback linux-info.eclass to my revision. Please apply my patch
(In reply to comment #5) > My commit was trying to merge soft&hard error reports. > Also it reordered the operators, making ~ (aka do not die) the first (searched > before commiting it; no other ebuilds uses ~ in conjuction with ! or @). Yep, some of it was fairly obvious, but it didnt explain what the initial problem was anyways, so it did not show any actual fix. > I think the fix part is quite obvious. In your implementation, the function > will not die if the last test doesn't fail. Can you give me an example of this usage in the tree at present? > To be noted: this isn't the first time I correct a mistake in > linux-info.eclass. See bug #74396 comment #8 and revision 1.15 of the > linux-info.eclass. Ah no, I'm aware. In the previous case I knew of the problem, and I knew of the function limitations. In this case I've not seen a bug, nor been emailed re: the potential bug. > I fail to see how this bug has anything to do with my commit (the ebuild die in > the exact same manner regardless what linux-info.eclass revision I use), so > I'll reopen it. I tested both the previous revision, and your revision in the exact setup here. The original suceeded, yours failed. Thats why I reverted it. I have been meaning for some time to clean up this function, but please send patches my way, or open a bug report and attach as appropriate. > Please rollback linux-info.eclass to my revision. > Please apply my patch Sorry, I can't do this as the current patch breaks ebuilds using @CONFIG, as demonstrated in this bug. Please re-open another bug since its not related or email me and we can do it that way, specifying the problem and attaching a patch.
(In reply to comment #6) > > I think the fix part is quite obvious. In your implementation, the function > > will not die if the last test doesn't fail. > > Can you give me an example of this usage in the tree at present? Just set CONFIG_CHECK to FOO BAR , while your kernel doesn't have FOO but it has BAR. I > Ah no, I'm aware. In the previous case I knew of the problem, and I knew of the > function limitations. Are you serious? That was a pretty serious problem and you call it "limitation"?!? > I tested both the previous revision, and your revision in the exact setup here. > The original suceeded, yours failed. Thats why I reverted it. I have been > meaning for some time to clean up this function, but please send patches my > way, or open a bug report and attach as appropriate. Can you please send me your .config then? The one that fails with my variant of linux-info...
> > Can you give me an example of this usage in the tree at present? > Just set CONFIG_CHECK to FOO BAR , while your kernel doesn't have FOO but it > has BAR. I in which case, can you point me to the bug report, or email about this? I'll address the problem there instead of a bug which was logged as a result of an unknown and untested change. > > Ah no, I'm aware. In the previous case I knew of the problem, and I knew of the > > function limitations. > > Are you serious? That was a pretty serious problem and you call it > "limitation"?!? Exactly. Its a limitation. Want my reasoning for this? we dont have have linux 2.1.12 or 2.11.2 in the tree. Nor would we have anything which would be likely to cause immediate problems. I was actually aware that I did not calculate the version on an atomic basis, but at the time that was not important, and without any thought about it before I say this.. it still wouldnt cause a problem today. > > I tested both the previous revision, and your revision in the exact setup here. > > The original suceeded, yours failed. Thats why I reverted it. I have been > > meaning for some time to clean up this function, but please send patches my > > way, or open a bug report and attach as appropriate. > > Can you please send me your .config then? The one that fails with my variant of > linux-info... I can do, but its pretty easy to check. CONFIG_FUSE_FS=y, emerge sys-fs/fuse the rest wont matter.
(In reply to comment #8) > in which case, can you point me to the bug report, or email about this? I'll > address the problem there instead of a bug which was logged as a result of an > unknown and untested change. I'll tell you what. Why don't I make my own eclass instead of just trying to convince you? > Exactly. Its a limitation. Want my reasoning for this? we dont have have linux > 2.1.12 or 2.11.2 in the tree. Nor would we have anything which would be likely > to cause immediate problems. I was actually aware that I did not calculate the > version on an atomic basis, but at the time that was not important, and without > any thought about it before I say this.. it still wouldnt cause a problem > today. At that moment, 2.6.9 *was* in the tree, as well as 2.4.xx. What do you say about this example, mister "there are no ebuilds in the tree that proves me wrong"? > I can do, but its pretty easy to check. > CONFIG_FUSE_FS=y, emerge sys-fs/fuse Yeah, the exact same test that I did. Fails with brio using your linux-info.eclass.
(In reply to comment #8) > I can do, but its pretty easy to check. > CONFIG_FUSE_FS=y, emerge sys-fs/fuse Now I see. Your version dies only if it has $die == 1 (is 2 in this case), while mine dies on any hard_error. It could be easily solved using into my version.
> > in which case, can you point me to the bug report, or email about this? I'll > > address the problem there instead of a bug which was logged as a result of an > > unknown and untested change. > > I'll tell you what. Why don't I make my own eclass instead of just trying to > convince you? If you choose to do that, you can. But you should enforce policy and push the eclass to -dev for comments and what have you. My objection isnt that I dont like your patch. my objection is that I dont like your attitude. You should have asked the current maintainer to accept your patch, rather than just comitting a broken patch which didnt solve any known bug. If you knew of the bug, then you should have logged it and progressed it there. > > Exactly. Its a limitation. Want my reasoning for this? we dont have have linux > > 2.1.12 or 2.11.2 in the tree. Nor would we have anything which would be likely > > to cause immediate problems. I was actually aware that I did not calculate the > > version on an atomic basis, but at the time that was not important, and without > > any thought about it before I say this.. it still wouldnt cause a problem > > today. > > At that moment, 2.6.9 *was* in the tree, as well as 2.4.xx. What do you say > about this example, mister "there are no ebuilds in the tree that proves me > wrong"? correct it was. and the last I knew 269 was greater than 268. and 2610 was greater than 269. In fact, 2616 is still not a problem ebcause we dont have 2.61.6 or any other strange incarnation which you used as examples to break the logic of the code. IE: whyit was purely a limitation and not a concern at that time. > > I can do, but its pretty easy to check. > > CONFIG_FUSE_FS=y, emerge sys-fs/fuse > > Yeah, the exact same test that I did. Fails with brio using your > linux-info.eclass. I'll refrain from commenting on this, considering you made a statement regarding this before I could reply.
(In reply to comment #10) > (In reply to comment #8) > > I can do, but its pretty easy to check. > > CONFIG_FUSE_FS=y, emerge sys-fs/fuse > > Now I see. Your version dies only if it has $die == 1 (is 2 in this case), > while mine dies on any hard_error. It could be easily solved using into my > version. Yep, it was put in as a bit of a nasty hack, and I had always planned to implement something similar to how you have it in the proposed patch. @CONFIG = another soft error, so simply incrementing the count should suffice. I'm open to the patch you propose, but please do so through another bug which explains the problem it fixes (prefered) or via email.
if everyone is interested in this saga, follow the bug #133026.
