Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

Version bump

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Compile without errors and make check don't fail under ~x86

automake-1.9.1 already out.
http://ftp.gnu.org/gnu/automake/automake-1.9.1.tar.bz2
Does it need a new bug submission?

base-system folks: made the 1.9 ebuild for local usage (w/o uclibc patch, since
I cannot test it). Does it help, if I attach the files?

carlo, let's get this one going since kde is now using automake 1.9 - either
attach or commit to portage with KEYWORDS="" so we can start to play with the
ebuild.

as a side note, it may be time to start deprecating older versions of automake
that are supported in the build.  surely we can get rid of 1.4 and make 1.5 the
new default if no version is specified.

no, we cant really get rid of older versions ... autotools is one set of
packages where old versions never die no matter how much you want them to

about the only thing we could do is move to a SLOT-ed setup

please post a diff against the current 1.8.5-r1 ebuild

Created an attachment (id=39245) [details]
automake.diff

Created an attachment (id=39246) [details]
am-wrapper.diff

Created an attachment (id=39247) [details]
infopage.diff

Please note that I removed the uclibc epatch line from the ebuild. Needs to be
readded.

We need to identify which packages use the older versions.  I would bet that we
can, with a little work, get rid of the old automake versions.

just becuase portage doesnt use the older versions doesnt mean users dont
either

which is why moving to SLOTs is viable; getting rid of packages is not

i agree with you there - if we can migrate to the versions being slotted
instead of encompassed in one mega ebuild that would be grand.

the bigger problem is the pita it generates.

*** Bug 64965 has been marked as a duplicate of this bug. ***

Version 1.9.1, 1.9.2 and 1.9.3 are available. I cannot build arts-1.3.1 without
aclocal-1.9, why are those ebuilds not version bumped?

why dont you read the bug before asking the same question over and over again

see comment #11

1.9.3 is now in portage

before the new stuff can be unmasked, what i'm going to need is heavy testing

the way to do it is this:
mkdir -p /etc/portage
echo "sys-devel/autoconf
sys-devel/autoconf-wrapper
sys-devel/automake
sys-devel/automake-wrapper" >> /etc/portage/package.unmask
emerge -C automake autoconf
emerge =automake-1.{4,5,6,7,8,9}* =autoconf-2.{13,59}* auto{conf,make}-wrapper

then just start emerging things :P
file new bugs and make them block this one

I'm testing now. If anything screwy turns up I'll let you know.

When I build 1.9, I get "checking whether autoconf works... no"
unless I do "export WANT_AUTOCONF=2.5" first.

SpanKY wrote:
> 1.9.3 is now in portage
> before the new stuff can be unmasked, what i'm going to need is heavy testing

I'm building system from scratch using the unmkasked stuff.
It works for me.
Removing some version of automake, like 1.4 and 1.7, brakes some ebuilds that should depend on them when the new ebuilds will be unmasked. The wrapper works fine for me.

so change the line:
emerge =automake-1.{4,5,6,7,8,9}* =autoconf-2.{13,59}* auto{conf,make}-wrapper

to this:
emerge =autoconf-2.{13,59}* =automake-1.{4,5,6,7,8,9}* auto{conf,make}-wrapper

ive released new autoconf stuff

ok, unmasked automake

WATCH OUT :)

Closing, automake-1.9 in portage and works fine.