On Wed, 2008-10-15 at 06:34 -0700, Dan Nicholson wrote: > On Wed, Oct 15, 2008 at 3:35 AM, Karsten Hopp <karsten@xxxxxxxxxx> wrote: > > > > My last rebuild showed only ~100 failures, I'm not sure what I've done > > differently > > 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 m4 macros 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 (just > use autoreconf!) 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 all. > ax25-apps: looks like aclocal was run, but libtoolize wasn't, causing > 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 the problem. > bind: aclocal not told where macros are, end up using old libtool m4 macros 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 still true.) > 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@xxxxxxxxxxxxx> <http://endoframe.com> Jabber: <braden@xxxxxxxxxx> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
