>>> Emerging (1 of 4) gnome-extra/at-spi-1.26.0 * at-spi-1.26.0.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking at-spi-1.26.0.tar.bz2 to /scrap/var/tmp/portage/gnome-extra/at-spi-1.26.0/work * Fixing OMF Makefiles ... [ ok ] * Running elibtoolize in: at-spi-1.26.0 * Applying install-sh-1.5.4.patch ... * Applying portage-2.2.patch ... * Applying sed-1.5.6.patch ... * Applying as-needed-2.2.6.patch ... * Applying at-spi-1.22.0-tests.patch ... [ ok ] am-wrapper: warning: invalid WANT_AUTOMAKE 'latest'; ignoring. * Running automake --add-missing --copy ... [ !! ] * Failed Running automake ! * * Include in your bugreport the contents of: * * /scrap/var/tmp/portage/gnome-extra/at-spi-1.26.0/temp/automake.out $ sudo cat /scrap/var/tmp/portage/gnome-extra/at-spi-1.26.0/temp/automake.out ***** automake ***** ***** PWD: /scrap/var/tmp/portage/gnome-extra/at-spi-1.26.0/work/at-spi-1.26.0 ***** automake --add-missing --copy configure.in:9: version mismatch. This is Automake 1.10.2, configure.in:9: but the definition used by this AM_INIT_AUTOMAKE configure.in:9: comes from Automake 1.9.6. You should recreate configure.in:9: aclocal.m4 with aclocal and run automake again. atk-bridge/Makefile.am:23: libbonobo-2: non-POSIX variable name atk-bridge/Makefile.am:23: liboaf-2: non-POSIX variable name atk-bridge/Makefile.am:23: libORBit-2: non-POSIX variable name atk-bridge/Makefile.am:23: libat-spi: non-POSIX variable name docs/reference/idl/Makefile.am:18: <D: non-POSIX variable name docs/reference/idl/Makefile.am:26: <D: non-POSIX variable name Reproducible: Always
Adding WANT_AUTOMAKE=1.9 to the ebuild fixes the issue for me.
Created attachment 192360 [details] WANT_AUTOMAKE=1.9 patch Same here: adding export WANT_AUTOMAKE=1.9 seemed to fix it, attached a patch
Why the export?
Hi, diego? Want to take a look at this? This bug is actually your fault. at-spi only inherits autotool.eclass becouse it wants to use eautomake. at-api was packaged using automake-1.9* and becouse of that autotools.eclass needs to run eautoreconf before it runs eautomake (as latest is currently resolved as 1.10). This was not a problem before but since you changed how autotools.eclass handles WANT_AUTOMAKE="latest". This is becouse eautomake when figuring out if it needs to run eautoreconf runs "WANT_AUTOMAKE="latest" automake --version" which fails since am-wrapper cannot handle 'latest'. autotools.eclass continues without running eautoreconf, and eautomake fails becouse of that. Now you can argue that at-spi anyway should use WANT_AUTOMAKE="1.9" to avoid the extra time running eautoreconf takes, but still this exposed a bug in the autotool.eclass that should be fixed.
Good call, I'll look into fixing autotools.eclass later on today; on the other hand, yeah if you just want to use eautomake you _should_ set WANT_AUTOMAKE explicitly, otherwise you should use eautoreconf :)
(In reply to comment #5) > Good call, I'll look into fixing autotools.eclass later on today; on the other > hand, yeah if you just want to use eautomake you _should_ set WANT_AUTOMAKE > explicitly, otherwise you should use eautoreconf :) > For you as the autotools-guru, is it prefered as long as the packages can handle both situations do as currently (and thus pull in "latest" autoconf and automake), or do WANT_AUTOMAKE="1.9" WANT_AUTOCONF="none" (and thus only pull in an "older" automake)?
given that 1.11 is already in tree, I'd count 1.9 likely as the last one that can still be used; on the other hand, there is one issue: you have to make sure that the patchlevel is not changing, otherwise it's better "latest"
erm so we are supposed to set WANT_AUTOMAKE even if eautomake used to eautoreconf if automake version differed ?
Okay let me try to explain eautomake tries to conservatively _not_ run full-blown aclocal/autoconf; but it can do that only if the version (not the slot! the version!) of automake is unchanged from the original "make dist" that generated it. If you don't set WANT_AUTOMAKE, it will get in 1.10, note that 1.10 != 1.9 and run full-blown eautoreconf; since this is adding an overhead to test, if you know that the package uses an older automake and it'll will run eautoreconf; then please just run eautoreconf. The failsafe to run eautoreconf if they differ is for cases when "make dist" was ran with automake-1.10 and you have 1.10.1 installed for instance, in that case you want eautoreconf, but you have chances to get the same version running if the user hasn't updated. If you don't set WANT_AUTOMAKE, you know the package uses 1.9, and you just run eautomake, you're doing it wrong ;)
(In reply to comment #9) So what you are trying to say is that in this case we should eautoreconf or WANT_AUTOMAKE="1.9" eautomake and not let the autotools.eclass handle the autoreconf since that is just a failsafe for cases when "make dist" was run with for example automake-1.9.0 and you are running automake-1.9.6?
Never reset WANT_AUTOMAKE in local scope, but yeah you should do one of those two (with WANT_AUTOMAKE in ebuild scope for autotools.eclass to pick it up obviously).
alright, got it. You might want to spread the word though because I'm pretty sure this is not how other maintainers would get it as well :)
ok fixed. Thanks guys for spotting this and the explanations.