Hello, You're receiving this canned (template-based) bug report because I found a problem with a package during my tinderbox run. The package in question is running automake (and most likely other autotools) during compile phase by maintainer-mode. You can see in my blog post in the URL field why that's a problem, and how to address the issue, but in general, you don't want maintainer-mode rebuild during compile phase, especially since it can cause multiple run of econf. The causes of maintainer-mode rebuild are various, but most likely it's because of a patch that changes Makefile.am or configure.ac/in and don't rebuild autotools properly. The way to fix this is almost always to inherit autotools eclass and run eautomake/eautoreconf (as needed; eautoconf should only be used when automake is not involved, which is not the case here) during src_unpack phase. Thanks, Diego
Created attachment 179105 [details] Build log
This appears to be an upstream packaging error. The mtimes for the relevant files are: 2004-10-12 14:17:46.000000000 -0500 Makefile 2004-02-12 23:13:52.000000000 -0600 Makefile.am 2004-02-12 23:41:30.000000000 -0600 Makefile.in 2004-10-12 14:17:46.000000000 -0500 config.guess* 2004-02-12 23:41:30.000000000 -0600 config.h.in 2004-10-12 14:17:46.000000000 -0500 config.sub* 2004-09-28 09:34:56.000000000 -0500 configure* 2004-09-28 09:34:56.000000000 -0500 configure.in Note that configure.in has a modification time in 2004-09-28, but Makefile.in was modified 2004-02-12. This triggers one of the included maintainer-mode rules: $(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4) cd $(top_srcdir) && \ $(AUTOMAKE) --gnu Makefile The changes attached to bug #247937 fix this as a side effect, since the patch there uses eautoreconf after patching configure.in.
Looks like this was fixed along with bug #247937.
