On Wed, 2008-10-15 at 06:34 -0700, Dan Nicholson wrote:
On Wed, Oct 15, 2008 at 3:35 AM, Karsten Hopp
> My last rebuild showed only ~100 failures, I'm not sure what I've done
> this time. I suspect that the removal of libtool-ltdl and all related
> packages from
> my full-install might have caused this and I'm in the process of rebuilding
> those with libtool-2.
> I've uploaded the current logs to http://karsten.fedorapeople.org/
> After a quick glance at them I think that there are quite a few easy fixes,
> but I still
> have to find out what causes p.e. the cracklib failure.
Looking at the first few:
afflib: needs AC_PROG_CXX
Or better, just call autoconf instead of autoreconf. (Or do it right
and patch configure.)
amanda: aclocal not told where macros are, end up using old libtool
The problem is that libtoolize is getting run at all.
aplus-fsf: needs AC_PROG_CXX
Wow... This one's a mess. I don't think that's the problem. In fact,
I'm not convinced the problem with this package has anything to do with
libtool2. It's hard to see what's going on amid all the warnings about
this code that the compiler is spewing; but if you scroll down to the
bottom you'll see it's just missing something that goes after a -L flag;
presumably some variable isn't getting set for some reason.
apr: script manually copying libtool files and getting it wrong
Or don't. I don't see any reason to regenerate configure in this
package. Only Makefile.in is getting patched.
avahi: needs AC_PROG_CXX
Again, this looks like a case where autoreconf doesn't need to be run at
ax25-apps: looks like aclocal was run, but libtoolize wasn't,
mismatch between macros and ltmain.sh
I see this patching a couple of Makefile.am's; running automake should
be sufficient. Eliding the calls to aclocal and autoconf should avoid
bind: aclocal not told where macros are, end up using old libtool m4
It's not clear to me why this spec file is running libtoolize and
aclocal at all.
blackbox: needs AC_PROG_CXX
I see no reason at all for this to be running autoreconf. (A comment
claims it gets rid of an rpath; I'd be a little surprised if this were
bmpx: needs AC_PROG_CXX
Actually, the problem is that it patches both configure.ac and
configure. Presumably the timestamps don't line up right as a result
and "make" triggers regenerating stuff. Either the patch to
configure.ac should be culled or the timestamps need massaging.
(There's also a patch to soup.m4 that just looks goofy.)
bzflag: needs AC_PROG_CXX
I see no reason to call autoreconf here.
cairo-dock: needs AC_PROG_CXX
Yikes. There's a bunch of magic happening here (of dubious value IMO;
but clearly the maintainer doesn't share that view). I'm really not
sure what to say here.
compat-db: libtool macros copied manually and getting it wrong
Yeah, more unusual stuff that's just very breakage-prone. Hard to say
if there's a better way without some deep knowledge of this package.
cracklib: yeah, failing on --tag=CC is very weird, especially when
configure.in seems completely reasonable
Pulling in new libtool here is really unnecessary. The package could
simply run autoconf instead of autoreconf.
Braden McDaniel e-mail: <braden(a)endoframe.com>