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 attachment 39245 [details] automake.diff
Created attachment 39246 [details] am-wrapper.diff
Created attachment 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.
