Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 271059 - =gnome-extra/at-spi-1.26.0 automake issue
Summary: =gnome-extra/at-spi-1.26.0 automake issue
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] GNOME (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-24 14:15 UTC by Kobboi
Modified: 2009-05-25 22:07 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
WANT_AUTOMAKE=1.9 patch (automake-1.9.patch,401 bytes, text/plain)
2009-05-25 03:09 UTC, David Abbott (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kobboi 2009-05-24 14:15:27 UTC
>>> 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
Comment 1 Kobboi 2009-05-24 14:19:03 UTC
Adding WANT_AUTOMAKE=1.9 to the ebuild fixes the issue for me.
Comment 2 David Abbott (RETIRED) gentoo-dev 2009-05-25 03:09:50 UTC
Created attachment 192360 [details]
WANT_AUTOMAKE=1.9 patch

Same here: adding export WANT_AUTOMAKE=1.9 seemed to fix it, attached a patch
Comment 3 Kobboi 2009-05-25 09:18:50 UTC
Why the export?
Comment 4 Xake 2009-05-25 10:50:57 UTC
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.
Comment 5 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-05-25 10:59:59 UTC
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 :)
Comment 6 Xake 2009-05-25 11:38:59 UTC
(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)?
Comment 7 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-05-25 11:47:54 UTC
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"
Comment 8 Gilles Dartiguelongue (RETIRED) gentoo-dev 2009-05-25 11:55:03 UTC
erm so we are supposed to set WANT_AUTOMAKE even if eautomake used to eautoreconf if automake version differed ?
Comment 9 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-05-25 12:11:37 UTC
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 ;)
Comment 10 Xake 2009-05-25 12:29:31 UTC
(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?
Comment 11 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-05-25 12:39:42 UTC
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).
Comment 12 Gilles Dartiguelongue (RETIRED) gentoo-dev 2009-05-25 13:22:03 UTC
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 :)
Comment 13 Gilles Dartiguelongue (RETIRED) gentoo-dev 2009-05-25 22:07:46 UTC
ok fixed. Thanks guys for spotting this and the explanations.