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.
Created attachment 179105 [details]
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.