On Tue, 6 Dec 2011 19:07:14 -0800 (PST) Darrell Anderson <humanreadable@...> wrote: > > Unfortunately, I suspect that Timothy Pearson is the only > > person who might be able to produce these files. > > I'm hesitant to file a bug about this because the problem > > is 1. with autotools and 2. probably limited to > > distros using ebuilds/Portage, of which there are only > > about three (Gentoo, Funtoo, and kinda-sorta > > Sabayon). > > If you post or link to your build logs I'm sure the heavy hitters will help. I'm not a coder, >just a packager and one of the people who monkey wrenches everything to find the breakage. :) Fortunately, the pertinent portions of the logs are short: * Package: kde-base/amor-3.5.13 * Repository: trinity * Maintainer: kde@... * USE: elibc_glibc kernel_linux userland_GNU x86 * FEATURES: sandbox >>> Unpacking source... >>> Unpacking parts of kdetoys-3.5.13.tar.bz2 to /var/tmp/portage/kde-base/amor-3.5.13/work >>> Unpacking kdetoys-3.5.13.tar.gz to /var/tmp/portage/kde-base/amor-3.5.13/work * Running eautoreconf in '/var/tmp/portage/kde-base/amor-3.5.13/work/amor-3.5.13' ... * Running aclocal ... [ !! ] * Failed Running aclocal ! * * Include in your bugreport the contents of: * * /var/tmp/portage/kde-base/amor-3.5.13/temp/aclocal.out aclocal.out contains the following, which I think is pretty clear: ***** aclocal ***** ***** PWD: /var/tmp/portage/kde-base/amor-3.5.13/work/amor-3.5.13 ***** aclocal aclocal-1.9: `configure.ac' or `configure.in' is required The output should look like this (produced by doping the source tarball with a configure.in from 3.5.10, which causes the build not to fail until configure is actually run): * Package: kde-base/kodo-3.5.13 * Repository: trinity * Maintainer: kde@... * USE: elibc_glibc kernel_linux userland_GNU x86 * FEATURES: sandbox >>> Unpacking source... >>> Unpacking parts of kdetoys-3.5.13.tar.bz2 to /var/tmp/portage/kde-base/kodo-3.5.13/work >>> Unpacking kdetoys-3.5.13.tar.gz to /var/tmp/portage/kde-base/kodo-3.5.13/work * Running eautoreconf in '/var/tmp/portage/kde-base/kodo-3.5.13/work/kodo-3.5.13' ... * Running aclocal ... [ ok ] * Running libtoolize --copy --force --install --automake ... [ ok ] * Running aclocal ... [ ok ] * Running autoconf ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy --foreign ... [ ok ] * Running elibtoolize in: kodo-3.5.13/admin/ * Applying portage/1.2.0 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/2.2.6 patch ... >>> Source unpacked in /var/tmp/portage/kde-base/kodo-3.5.13/work >>> Compiling source in /var/tmp/portage/kde-base/kodo-3.5.13/work/kodo-3.5.13 ... * econf: updating kodo-3.5.13/admin/config.guess with /usr/share/gnuconfig/config.guess * econf: updating kodo-3.5.13/admin/config.sub with /usr/share/gnuconfig/config.sub ./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --with-qt-dir=/usr/qt/3 --enable-mt --with-qt-libraries=/usr/qt/3/lib --disable-dependency-tracking --disable-debug --without-debug --without-arts --prefix=/usr/kde/3.5 --mandir=/usr/kde/3.5/share/man --infodir=/usr/kde/3.5/share/info --datadir=/usr/kde/3.5/share --sysconfdir=/usr/kde/3.5/etc (configure then fails because it can't find the designer plugins, which I assume is because the old configure.in doesn't know about tqt) More files are available, including the rest of that last log with the list of configure checks passed/failed, the system setup data, documentation for the e[foo] functions used by Portage, and the 1000+ lines of shellscript forming the backbone of the old KDE3 build system for Gentoo which I am trying to adapt.