When i tried to build x11-drivers/xf86-video-intel-2.7.99.901 it failed with some errors from libtool concerning unrecognized commands. Those errors disappeared when I installed sys-devel/libtool-2.2.4. So I think there sould probably be a build time dependency on >libtool-2, or something like that. Reproducible: Always Steps to Reproduce: 1. emerge =sys-devel/libtool-1.5.26 2. emerge =x11-drivers/xf86-video-intel-2.7.99.901 3. Look at the error messages ;-) Actual Results: Error messages: /var/tmp/portage/x11-drivers/xf86-video-intel-2.7.99.901/work/xf86-video-intel-2.7.99.901/uxa/../libtool: line 848: X--tag=CC: command not found /var/tmp/portage/x11-drivers/xf86-video-intel-2.7.99.901/work/xf86-video-intel-2.7.99.901/uxa/../libtool: line 881: libtool: ignoring unknown tag : command not found /var/tmp/portage/x11-drivers/xf86-video-intel-2.7.99.901/work/xf86-video-intel-2.7.99.901/uxa/../libtool: line 848: X--mode=link: command not found /var/tmp/portage/x11-drivers/xf86-video-intel-2.7.99.901/work/xf86-video-intel-2.7.99.901/uxa/../libtool: line 1015: *** Warning: inferring the mode of operation is deprecated.: command not found /var/tmp/portage/x11-drivers/xf86-video-intel-2.7.99.901/work/xf86-video-intel-2.7.99.901/uxa/../libtool: line 1016: *** Future versions of Libtool will require --mode=MODE be specified.: command not found /var/tmp/portage/x11-drivers/xf86-video-intel-2.7.99.901/work/xf86-video-intel-2.7.99.901/uxa/../libtool: line 1046: libtool: warning: cannot infer operation mode from `/bin/sh': No such file or directory /var/tmp/portage/x11-drivers/xf86-video-intel-2.7.99.901/work/xf86-video-intel-2.7.99.901/uxa/../libtool: line 7196: libtool: you must specify a MODE: command not found /var/tmp/portage/x11-drivers/xf86-video-intel-2.7.99.901/work/xf86-video-intel-2.7.99.901/uxa/../libtool: line 7197: Try `libtool --help' for more information.: command not found Portage 2.1.6.13 (default/linux/amd64/2008.0, gcc-4.1.2, glibc-2.9_p20081201-r2, 2.6.29-gentoo-r5 x86_64) ================================================================= System uname: Linux-2.6.29-gentoo-r5-x86_64-Intel-R-_Core-TM-2_Duo_CPU_P8400_@_2.26GHz-with-glibc2.2.5 Timestamp of tree: Thu, 09 Jul 2009 00:45:01 +0000 app-shells/bash: 4.0_p24 dev-java/java-config: 2.1.7 dev-lang/python: 2.4.4-r6, 2.5.4-r2 dev-python/pycrypto: 2.0.1-r6 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.5, 1.7.9-r1, 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="-O2 -pipe -fforce-addr -march=nocona" 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" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -pipe -fforce-addr -march=nocona" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.switch.ch/ftp/mirror/gentoo" LANG="de_CH.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="de en fr" 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" SYNC="rsync://192.168.1.1/gentoo-portage" USE="X acl alsa amd64 bash-completion berkdb bzip2 cli cracklib crypt cups dri fortran gdbm gif gpm iconv ipv6 isdnlog jpeg midi mmx mudflap multilib ncurses nls nptl nptlonly openmp pam pcre pdf perl png pppd python readline reflection session smp spl sse sse2 ssl svg sysfs tcpd unicode vim-syntax xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" 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="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en fr" USERLAND="GNU" VIDEO_CARDS="intel vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Reassigning on maintainers. Probably it's possible to fix this bug just adding rm for m4/{libtool,lt~obsolete,ltoptions,ltsugar}.m4 ltmain.sh and running elibtoolize, but ... that's up to you.
I won't fix this because : 1) this ebuild is both p.masked _and_ only keyworded for unstable arches. Support on stable system is not my main concern with this snapshot. 2) this ebuild rebuilds the autotools because one of the patches modify a Makefile.am. Hopefully, the next RCs and the final releases won't require such patches, so those should build correctly on stable systems. So for now, if you want to build the latest available code for the intel driver, you should use xf86-video-intel-9999 from the x11 overlay. Thanks
*** Bug 277866 has been marked as a duplicate of this bug. ***
sorry, but I really fail to see what prevents you from specifying the correct deps. just because somebody doesn't magically know the circumstances under which that ebuild is supposed to be used, it is allowed to fail for them? pretty weak argument, IMHO. its a trivial single line to be added to the ebuild, right? but hey - you're the boss. (no hard feelings at all - i am greatful the ebuild exists in the first place - thanks :-) humbly Thilo
Because this ebuild is p.masked and hopefully will be gone by next week, I don't see the need to change that for just a short lived ebuild that was never intended for stable users :)
*** Bug 277961 has been marked as a duplicate of this bug. ***
