The following ebuilds are found to have broken autotools handling, as they run libtoolize directly (they never should, instead they should call eautoreconf in autotools.eclass, read http://www.gentoo.org/proj/en/qa/autofailure.xml for more information): ./dev-cpp/libgnomecanvasmm/libgnomecanvasmm-2.0.1.ebuild: libtoolize --copy --force ./dev-cpp/libgnomecanvasmm/libgnomecanvasmm-2.10.0.ebuild: libtoolize --copy --force ./dev-cpp/libgnomecanvasmm/libgnomecanvasmm-2.11.1.ebuild: libtoolize --copy --force ./dev-cpp/libgnomecanvasmm/libgnomecanvasmm-2.12.0.ebuild: libtoolize --copy --force ./dev-cpp/libgnomecanvasmm/libgnomecanvasmm-2.6.1.ebuild: libtoolize --copy --force Please cleanup the ebuilds by asking for stable marking, removing obsolete ebuilds with no relevant keywords, or porting the fixes in newer versions (if presents) to properly handle autotools. Thanks, Diego
ppc64 - you are blocking this bug.
ppc64 is not blocking anything anymore. Now we need some cleanup of libgnomecanvasmm SLOT=2.0 users: app-office/passepartout-0.5: sgml app-office/passepartout-0.6: sgml passepartout-0.6_p1 uses newer SLOT and earlier could be cleaned up and there seem to be no visibility problems either. sgml herd, can you do that cleanup or can I take care of it?
(In reply to comment #2) > passepartout-0.6_p1 uses newer SLOT and earlier could be cleaned up and there > seem to be no visibility problems either. Just dump it, I filed Bug 194742 for this but noone did that after stabilization.
Done.