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.
P.S.: in this case the package is also failing when libtool 2 is in the system for the very reason that autotools are not properly rebuilt.
Created attachment 197522 [details]
I haven't run into or used that "maintainer mode" during development on safecopy.
Safecopy's source tree is a bit special, cause it has a "sub-project" (a library for testing) in a subdirectory.
I have found no way to prevent autotools to process subdirectorys that have configure.in files and the like, when run in the main dir, too
Unfortunately this processing of subdirectorys will mess things up. autotools have to be called in the subdirectory separately and in the right order, or they will fail.
The CVS HEAD ebuild for safecopy from gentoo-sunrise already does this things in the right order, however the normal ebuild assumes that autotools have already been run.
Running autotools again like it happened in this MAINTAINER-MODE build log breaks building of safecopy badly.
I am not sure how to prevent this maintainer mode from happening, but it needs to be prevented for safecopy to compile. Autotools must not be rerun!
Is that possible with an ebuild change? If so, how?
PS: I can release version 1.4 of safecopy that does no longer need the gentoo patches if that would help. (I incorporated those patches into the main source tree)
Created attachment 198052 [details]
ebuild proposal for safecopy-1.4
I attached a proposal for safecopy 1.4
It differs from 1.3 in that the patches needed for gentoo are already integrated, which makes it easier.
I added eautoreconf to the src_prepare to ensure executing autoconf in the right order of directories. This seemed to be more sensible than preventing maintainer-mode with some "find . -exec touch" hacks
I cannot reproduce the original build failure though. Please check wether the new version/ebuild fixes the issue.
Created attachment 198071 [details]
needed to sed the bin/sh to bin/bash or it only says "no such file", but it still fails pretty much all tests here..
but it solves the issue in this bug which I'm able to reproduce with 1.3 in tree now.
Created attachment 198073 [details]
ebuild without tests; at least it works
I sort of disagree on this "solution". the tests are supposed to validate safecopy's internal functionality. They work on all the systems I tested with, can you post the log of the failed tests?
If its just the test debug library failing again then that could be work arounded (by finding out when and why the test library fails and disabling tests under this conditions - or fix the test library), but if the tests fail because safecopy doesnt work correctly, removing the src_test is not a valid workaround.
+*safecopy-1.4 (16 Jul 2009)
+ 16 Jul 2009; Samuli Suominen <email@example.com> +safecopy-1.4.ebuild:
+ Version bump wrt #277418, thanks to Diego E. Pettenò and Corvus Corax.