Bugzilla Bug 153936

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...