this one includes support for automake-1.10 but shouldnt require it
Stable on ppc
1. emerges on x86 2. passes collision test 3. automake and php emerge with it sys-devel/automake-wrapper-2 Portage 2.1.1-r1 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.18.1 i686) ================================================================= System uname: 2.6.18.1 i686 Genuine Intel(R) CPU T2300 @ 1.66GHz Gentoo Base System version 1.12.6 Last Sync: Fri, 03 Nov 2006 13:50:01 +0000 ccache version 2.3 [disabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.3.5-r3, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 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 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer" 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 /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/" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--nospinner" FEATURES="autoconfig collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test userfetch userpriv usersandbox" GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/ http://gentoo.inode.at/" LINGUAS="en de en_GB de_CH" MAKEOPTS="-j3" 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="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 X a52 aac acpi alsa apache2 asf berkdb bitmap-fonts cairo cdr cdrom cli cracklib crypt cups dbus divx dlloader dri dts dvd dvdr dvdread eds elibc_glibc emboss encode fam ffmpeg firefox flac fortran gdbm gif gnome gpm gstreamer gtk hal iconv input_devices_keyboard input_devices_mouse ipv6 isdnlog java jpeg kde kernel_linux ldap libg++ linguas_de linguas_de_CH linguas_en linguas_en_GB mad mikmod mmx mono mp3 mpeg ncurses nls nptl nptlonly ogg opengl oss pam pcre perl png ppds pppd python qt3 qt4 quicktime readline reflection rtsp samba sdl session smp spell spl sse sse2 sse3 ssl svg tcpd test tetex theora threads truetype truetype-fonts type1-fonts udev unicode userland_GNU vcd video_cards_fbdev video_cards_i810 video_cards_vesa vorbis win32codecs wxwindows x264 xine xml xorg xprint xv xvid zlib" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
now in prefix
(In reply to comment #0) > this one includes support for automake-1.10 but shouldnt require it > Not true. Since the default has moved from automake 1.9 to automake 1.10, emerging will die when trying to compile a package that does not explicitly set WANT_AUTOMAKE. dev-lang/ruby-1.8.5, for example, dies and spits out this error: ***** aclocal ***** am-wrapper: /usr/bin/aclocal-1.10 is missing or not executable. Please try emerging the correct version of automake. php only compiles because it explicitly sets WANT_AUTOMAKE to 1.9 (php5_1-sapi.eclass, line 331) and automake compiles because it doesn't use eautoreconf, eaclocal, or eautomake. Furthermore, there is no good reason to have this stable as its only advantage over automake-wrapper-1-r1 is support for automake 1.10. I think this should only be stabilized when it can depend on the suitable version of automake (1.10).
incorrect those packages are broken regardless ... get them fixed as it is not a bug in the wrapper
(In reply to comment #5) > incorrect > > those packages are broken regardless ... get them fixed as it is not a bug in > the wrapper > Hmmm.... Why have a default at all then? Why not just die whenever WANT_AUTOMAKE isn't set? This would certainly make weeding out "broken" packages easier and help to avoid any problems like this in the future... Also, I didn't say that it was a bug in the wrapper. Sorry if it sounded like that.
amd64 done.
because autotools does not require ebuilds ... you should certainly be able to run `automake` in your own code ive added automake-wrapper-4 to be a bit more flexible, but the ruby ebuild is still broken and a bug should be filed if one hasnt been yet
Stable for HPPA.
x86 is stable
Turned back to ~x86, as there seem to be some problems as reported by Mr_Bones on IRC. Readd us, too.
incorrect, read the comments here sdl-mixer is broken
(In reply to comment #12) > incorrect, read the comments here > > sdl-mixer is broken Fix it :-P, x86 gone again...I love bug spam.
I'm on x86. media-libs/xvid-1.1.0-r3 gave this: am-wrapper: /usr/bin/aclocal-1.10 is missing or not executable. Please try emerging the correct version of automake. then I ran aclocal myself and I got the same error. automake-1.10 is not in the stable tree but automake-wrapper-2 is(in x86). It shouldn't default to 1.10, should default to 1.9. I have to emerge with WANT_AUTOMAKE="1.9" now.
did you read the comments ? xvid is broken as it fails to set up proper autotool dependencies, go file a bug about it
A lot of packages seems broken with the new automake. The output >> am-wrapper: /usr/bin/aclocal-1.10 is missing or not executable. >> Please try emerging the correct version of automake. Doesn't help at all to determine the actual cause - broken package. Please put a more usable error message there. Something in the lines of "this ebuild does not specify automake version ...".
if you actually looked at how things happen you'd realize that it isnt really possible
I'm on amd64. Due to this bug the following packages cannot be emerged: dev-lang/ruby-1.8.5, media-libs/xine-lib-1.1.2-r2, games-arcade/crack-attack-1.1.14-r1. The message: am-wrapper: /usr/bin/aclocal-1.10 is missing or not executable. Please try emerging the correct version of automake I also don't understand why it defaults to automake-1.10 if the latest stable today is automake-1.9.6-r2.
...Removing amd64 again since this is not amd64 specific. I have to agree though that stabilizing something that breaks a lot of ebuilds isn't the nicest thing to do...
which part of "those packages are broken" did you find confusing ?
There were errors when compiling - ruby-1.8.5 - libgadu 1.7.0_pre20050719 Error output (the same in both packages): am-wrapper: /usr/bin/aclocal-1.10 is missing or not executable. Please try emerging the correct version of automake. After adding "=automake-wrapper-2" to /etc/portage/package.mask and emerging version 1-r1 solved the problem.
if people arent going to read the bug before posting, then dont bother posting
Mike, I'm a bit confused. I have a package (not in the tree, just normal sources) that gives the same error about automake-1.10 missing. You seem to suggest that the package should be fixed. Where to look for? The package itself just calls automake. This fails anyhow, because by default it doesn't work: pegatoo ~ # automake --version am-wrapper: /usr/bin/automake-1.10 is missing or not executable. Please try emerging the correct version of automake.
that is tracked in Bug 154361
(In reply to comment #15) > did you read the comments ? xvid is broken as it fails to set up proper > autotool dependencies, go file a bug about it > How about $ automake am-wrapper: /usr/bin/automake-1.10 is missing or not executable. Please try emerging the correct version of automake. packages may have to set their automake versions, that's fine. But do everybody that use automake have to, too? I couldn't find such a claim in automake documentation. automake-1.10 is ~x86 but automake-wrapper-2 is x86 and it wants to use automake-1.10 without a dependency. So, my being not able to run automake without setting WANT_AUTOMAKE is indeed a bug of automake-wrapper-2 on x86, no?
so you read about half the bug and then stopped ? try reading the comment that appears right before yours
(In reply to comment #26) > so you read about half the bug and then stopped ? try reading the comment that > appears right before yours > I love your sarcastic style. I wish I was trying to do something other then to help. I read them all for the third time, and yes I still think it's a bug to to be able to run automake without setting the environment variable. Care to explain why it's not?
"...it's a bug NOT to be..." (In reply to comment #27) > (In reply to comment #26) > > so you read about half the bug and then stopped ? try reading the comment that > > appears right before yours > > > > I love your sarcastic style. I wish I was trying to do something other then to > help. > > I read them all for the third time, and yes I still think it's a bug to to be > able to run automake without setting the environment variable. Care to explain > why it's not? >
you didnt read the whole bug so i'll read it for you: read comment #23 where Fabian reports the same exact thing as you read comment #24 where i tell Fabian we're handling that issue at Bug 154361 read Bug 154361 where i say the problem is now fixed in cvs; sync up and update
sparc stable.
stable on ppc64
alpha done and mips was already done...
