On Tue, 6 Dec 2011 19:07:14 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> 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(a)gentoo.org
* 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(a)gentoo.org
* 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.