Hi, >>> Emerging (1 of 8) app-crypt/gnupg-1.9.94 to / * gnupg-1.9.94.tar.bz2 MD5 ;-) ... [ ok ] * gnupg-1.9.94.tar.bz2 RMD160 ;-) ... [ ok ] * gnupg-1.9.94.tar.bz2 SHA1 ;-) ... [ ok ] * gnupg-1.9.94.tar.bz2 SHA256 ;-) ... [ ok ] * gnupg-1.9.94.tar.bz2 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking gnupg-1.9.94.tar.bz2 ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking gnupg-1.9.94.tar.bz2 to /home/portage/tmp/portage/gnupg-1.9.94/work * Applying gnupg-1.9.94-make.patch ... [ ok ] * Applying gnupg-1.9.94-fbsd.patch ... [ ok ] * Running eautoreconf in '/home/portage/tmp/portage/gnupg-1.9.94/work/gnupg-1.9.94' ... * Requested automake 1.6 * Using automake (GNU automake) 1.6.3 * Using aclocal (GNU automake) 1.6.3 * Running aclocal -I m4 -I gl/m4 ... [ ok ] * Running autoconf ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy ... [ !! ] * Failed Running automake ! * * Include in your bugreport the contents of: * * /home/portage/tmp/portage/gnupg-1.9.94/temp/automake-28680.out !!! ERROR: app-crypt/gnupg-1.9.94 failed. Call stack: ebuild.sh, line 1546: Called dyn_unpack ebuild.sh, line 708: Called src_unpack gnupg-1.9.94.ebuild, line 54: Called eautoreconf autotools.eclass, line 87: Called eautomake autotools.eclass, line 188: Called autotools_run_tool 'automake' '--add-missing' '--copy' autotools.eclass, line 240: Called die !!! Failed Running automake ! !!! If you need support, post the topmost build error, and the call stack if relevant. Portage 2.1.1-r1 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.17.13 i686) ================================================================= System uname: 2.6.17.13 i686 Intel(R) Pentium(R) 4 CPU 2.53GHz Gentoo Base System version 1.12.5 Last Sync: Tue, 31 Oct 2006 19:00:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -mtune=pentium4 -O3 -pipe -frename-registers" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/X11/Sessions /etc/X11/app-defaults /etc/X11/mwm /etc/X11/wmconfig /etc/X11/xinit /etc/bonobo-activation /etc/cups /etc/dbus-1 /etc/dev.d /etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/fonts /etc/foomatic /etc/gconf /etc/gimp /etc/gnome-vfs-2.0 /etc/hotplug /etc/hotplug.d /etc/imlib /etc/init.d /etc/iproute2 /etc/java-config/vms/ /etc/pam.d /etc/pango /etc/profile.d /etc/revdep-rebuild /etc/sasl2 /etc/ssl /etc/ssmtp /etc/t1lib /etc/terminfo /etc/xinetd.d /etc/xml" CXXFLAGS="-march=pentium4 -mtune=pentium4 -O3 -pipe -frename-registers -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--alphabetical" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" LDFLAGS="-Wl,--as-needed" LINGUAS="de" PKGDIR="/usr/portage/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="/home/portage/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac acpi alsa arts avi berkdb bitmap-fonts bzip2 cairo cdparanoia cdr cli cracklib crypt cups dri dvd dvdr dvdread eds elibc_glibc emboss encode fam firefox flac gdbm gif gnutls gstreamer gtk gtk2 iconv imlib input_devices_keyboard input_devices_mouse input_devices_synaptics isdnlog jpeg kde kdehiddenvisibility kernel_linux lcms libwww linguas_de mad mikmod mmx mp3 mpeg ncurses nls nptl nptlonly nsplugin ogg oggvorbis opengl pam pcmcia pcre pdflib perl png pnp ppds pppd python qt3 quicktime readline reflection samba sdl session slang smime spell spl sse sse2 ssl svg theora tiff truetype truetype-fonts type1-fonts udev usb userland_GNU video_cards_radeon vorbis win32codecs wmf x264 xcomposite xml xml2 xorg xprint xv xvid zlib" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 100930 [details] automake-28680.out
> * Requested automake 1.6 > * Using automake (GNU automake) 1.6.3 > * Using aclocal (GNU automake) 1.6.3 Should have selected your latest automake... and not your oldest... From autotools.eclass: if [[ -n ${WANT_AUTOMAKE} ]]; then if [[ ${WANT_AUTOMAKE} == "latest" ]]; then for amver in 1.10 1.9 1.8 1.7 1.6; do WANT_AUTOMAKE="${amver}" ROOT=/ has_version =sys-devel/automake-${amver}* && break done fi export WANT_AUTOMAKE einfo "Requested automake ${WANT_AUTOMAKE}" einfo "Using $(automake --version 2>/dev/null | head -n 1)" einfo "Using $(aclocal --version 2>/dev/null | head -n 1)" fi So I guess the has_version did not find any match so it defaults to the oldest,1.6.... Diego, can you please have a look on this one? It would also be great if the eclass will print the real requested version... Thanks!
I've added the extra information if latest automake was used. But it shouldn't be accepting 1.6 in truth, as using latest will add automake-1.10 or 1.9 to the dependencies.
Thanks! Any ideas why the problem occur?
Lars, can you please modify the ebuild to use explicit automake version: WANT_AUTOMAKE='1.10' And see which automake is selected?
* Applying gnupg-1.9.94-make.patch ... * Applying gnupg-1.9.94-fbsd.patch ... * Running eautoreconf in '/home/portage/tmp/portage/gnupg-1.9.94/work/gnupg-1.9.94' ... * Requested automake 1.10 * Using automake (GNU automake) 1.10 * Using aclocal (GNU automake) 1.10 * Running aclocal -I m4 -I gl/m4 ... * Running autoconf ... * Running autoheader ... * Running automake --add-missing --copy ... >>> Source unpacked. setting WANT_AUTOMAKE='1.10' works and gnupg-1.9.94 installed fine. Are there any other ebuilds that use WANT_AUTOMAKE='latest' which I can test on this machine?
You can test latest openssh... openssh-4.4_p1-r5
>>> Unpacking openssh-4.4p1.tar.gz to /home/portage/tmp/portage/openssh-4.4_p1-r6/work * Applying openssh-4.4p1-selinux-ac.diff ... * Running eautoreconf in '/home/portage/tmp/portage/openssh-4.4_p1-r6/work/openssh-4.4p1' ... * Requested autoconf 2.5 * Using autoconf (GNU Autoconf) 2.60 * Using autoheader (GNU Autoconf) 2.60 * Requested automake latest: 1.6 * Using automake (GNU automake) 1.6.3 * Using aclocal (GNU automake) 1.6.3 * Running autoconf ... * Running autoheader ... >>> Source unpacked. same problem here (though I only have openssh-4.4_p1-r6 in portage but I think this makes no difference). Strange thing is, that this only occurs on this specific machine. My two other ~x86 machines use automake-1.10 when WANT_AUTOMAKE='latest' is set. Please don't hesitate to ask for any information if you need some. For me this is a VERY strange error. Cheers Poly-C
Is this a different error? x86_64-pc-linux-gnu-gcc -march=k8 -Os -pipe -frename-registers -fweb -freorder -blocks -freorder-blocks-and-partition -combine -funit-at-a-time -ftree-pre -fg cse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants -Wall -Wno-pointer-s ign -Wl,-z,now -o gpg-protect-tool protect-tool.o protect.o minip12.o ../common /libsimple-pwquery.a ../jnlib/libjnlib.a ../common/libcommon.a ../gl/libgnu.a -L /usr/lib64 -lgcrypt -L/usr/lib64 -lgpg-error -L/usr/lib64 -lgpg-error -ldl /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: B FD 2.17 internal error, aborting at /var/tmp/portage/binutils-2.17/work/binutils -2.17/bfd/merge.c line 863 in _bfd_merged_section_offset /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: P lease report this bug. collect2: ld returned 1 exit status make[2]: *** [gpg-protect-tool] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-crypt/gnupg-1.9.94/work/gnupg-1 .9.94/agent' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/app-crypt/gnupg-1.9.94/work/gnupg-1 .9.94' make: *** [all] Error 2 !!! ERROR: app-crypt/gnupg-1.9.94 failed. Call stack: ebuild.sh, line 1568: Called dyn_compile ebuild.sh, line 937: Called src_compile gnupg-1.9.94.ebuild, line 80: Called die !!! (no error message) !!! If you need support, post the topmost build error, and the call stack if rel evant. AMD64 Glide
Yes, it's a different one as this bug here is not gnupg specific but rather somewhere in autotools.eclass or portage I think (or in worst case limited to this single machine of mine). Please file a new bugreport for this.
Not related to a specific package.
automake-wrapper-3 in portage with required changes for WANT_AUTOMAKE to be a space delimited list ... i'd like to leave it there for a little bit before we stabilize
same problem with automake-wrapper-3
uhh probably because we didnt actually fix the eclass
Hi, any idea what I could try to get this fixed? The packages that don't compile due to this bug are going to accumulate more and more. Even an "emerge -e system" fails at coreutils. Cheers Poly-C
Created attachment 102680 [details] emerge_debug.txt This is the output of emerge --debug --nocolor -1v pam The problem starts around line 657 when portageq's has_version returns 1 instead of 0 for ALL automake version I have installed. Please devs PLEASE help me getting rid of this error. The amount of packages that refuse to compile because of this is really huge and I don't wanna hack all ebuilds to spike them at my latest installed automake version (which is 1.10).
*** Bug 155486 has been marked as a duplicate of this bug. ***
Another curiosity is this: notebook:~ # portageq has_version / =sys-devel/automake-1.10* && echo found || echo not found found notebook:~ # So being queried by portageq on the commandline, automake-1.10 was found. I'm completely out of ideas now and I'm at the point where I start considering a full reinstall of Gentoo because of this fscking bug... a very frustrated Poly-C
Can someone explain what the devs are doing to resolve this??????????????? It's been happening for weeks now!!!
i cant understand your comment as there are too many retarded punctuations
It seems as the has_version function doesn't work in any ebuild, not only in the autotools.eclass. I recently tried to compile media-video/mjpegtools-1.8.0-r2 with activated quicktime useflag which resulted in a compile error due to a patch not being applied as it has a has_version condition that doesn't come into effect. I can clearly say that any ebuild using the has_version function on two of my computers won't work as has_version doesn't do what it's supposed to do.
Alright... a friend had the right idea in tracking the problem down. It's the userpriv feature which prevents has_version function from working correctly. When I unset it via FEATURES="-userpriv" everythings works like a charm. The autotools.eclass as well as mjpegtools-1.8.0-r2. I tried to narrow the problem down more so I downgraded sys-apps/sandbox-1.2.18.1 to version 1.2.17 but that didn't help. So dear devs, is that enough information for you to find a solution to that problem? I'd really like to keep "userpriv" in my features... Cheers Poly-C
*** Bug 161109 has been marked as a duplicate of this bug. ***
Is this still an issue? The offending "has_version()" bash function has completely changed since this was first reported, and "has_version" within portageq can no-longer be called from the global scope, meaning the two fundamental functions at issue may have moved passed this problem. Lars - can you comment?
Hi Jim, to be honest I lost patience and reinstalled both affected machines from scratch. Now the error is gone and I'm more or less happy with Gentoo again. For me the problem is solved but maybe there are other users out there who suffer from the same problem. Cheers Poly-C
autotools.eclass has been rewritten along with the wrappers such that the has_version func isnt used
