With most current corutils/autotools, pygobject-2.18.0 dies during installation (error output is appended below). This is due to the fact that install does not accept the same argument twice in one line. The actual cause of the error is that the file "defsgen.py" is by mistake listed twice in codegen/Makefile.am This is similar to bug 267926, bug 277244, and bug 269372 (perhaps one should create a tracker for this kind of issue). I attach a patch which fixes the trivial error. For completeness, here is the error message: /usr/bin/install -c -m 644 __init__.py argtypes.py reversewrapper.py code-coverage.py codegen.py definitions.py defsconvert.py defsgen.py defsparser.py docextract.py docextract_to_xml.py docgen.py h2def.py defsgen.py createdefs.py mergedefs.py missingdefs.py mkskel.py override.py scanvirtuals.py scmexpr.py '/var/tmp/portage/dev-python/pygobject-2.18.0/image//usr/lib/python2.6/site-packages/gtk-2.0/codegen' /usr/bin/install: will not overwrite just-created `/var/tmp/portage/dev-python/pygobject-2.18.0/image//usr/lib/python2.6/site-packages/gtk-2.0/codegen/defsgen.py' with `defsgen.py'
Created attachment 199750 [details, diff] Patch which removes the duplicate line from codegen/Makefile.am The patch has to be applied before eautoreconf, of course.
What version of sys-apps/coreutils do you actually mean? Also post the output of `emerge --info`.
I mean coreutils-2.18 as written in the summary. Since apparently you cannot reproduce it, I checked and you are right that (currently) the problem only occurs if WANT_AUTOMAKE=1.11 is in the environment: The current autotools eclass otherwise defaults to WANT_AUTOMAKE=1.10, and automake-1.10 does not accumulate several files to one install command (so the duplicate target is just tacitly copied redundantly). Nevertheless that the target defsgen.py is duplicate in codegen/Makefile.am is a real bug (even if with automake-1.10 it "only" has the effect of a redundant copy operation). So consider it as a QA bug which will hit users at least once automake-1.11 will become the default in autotools eclass; I adjust the severity correspondingly.
sys-apps/coreutils currently has only the following versions in the tree: 7.1, 7.2, 7.4 Why do you need support for ancient versions?
Oh, I confused the version with pygobject's. I mean coreutils-7.4 Fixing it in the summary (and also adding automake-1.11 to the summary).
You forgot to reopen this bug...
patch looks fine, I'll check if the ebuild can be kept away from eautoreconf
In 2.18 without a bump.