Created attachment 282315 [details] Build log 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
Thanks for reporting! + 06 Aug 2011; Sebastian Pipping <sping@gentoo.org> libmp3splt-0.7.ebuild, + +files/libmp3splt-0.7-maintainer-mode.patch: + Disable maintainer mode (bug #377999) +
Ehm that's the wrong fix. The package uses automake, so eautoconf is not correct, you should use eautoreconf to be on the safe side. Remove the patch and replace the eautoconf call, that should do it.
(In reply to comment #2) > Ehm that's the wrong fix. The package uses automake, so eautoconf is not > correct, you should use eautoreconf to be on the safe side. Remove the patch > and replace the eautoconf call, that should do it. I only patch configure.ac so I don't really see what's wrong with just calling eautoconf. Also, eautoreconf fails for some reason. If you insist on the use of eautoreconf, I will need assistance.
When you rebuild configure from configure.ac, it needs to have the same automake version in sync or everything can tear at the seams. The presence of eautoconf is necessary for packages that do _not_ use automake, but just autoconf, for all the others eautomake/eautoreconf are the only supported options. Please let me know what fails with eautoreconf, so I can see what needs to be fixed.
Created attachment 282363 [details] aclocal.out >>> Preparing source in /var/tmp/portage/media-libs/libmp3splt-0.7/work/libmp3splt-0.7 ... * Applying libmp3splt-0.7-disable-docs.patch ... [ ok ] * Applying libmp3splt-0.7-flags.patch ... [ ok ] * Applying libmp3splt-0.7-maintainer-mode.patch ... [ ok ] * Running eautoreconf in '/var/tmp/portage/media-libs/libmp3splt-0.7/work/libmp3splt-0.7/libltdl' ... * Running aclocal ... [ !! ] * Failed Running aclocal ! * * Include in your bugreport the contents of: * * /var/tmp/portage/media-libs/libmp3splt-0.7/temp/aclocal.out ==================== Same with and without the maintainer-mode patch. Note the "libltdl" at the end above.
That's due to upstream being silly. Remove ifdef([LT_CONFIG_LTDL_DIR], [ LT_CONFIG_LTDL_DIR([libltdl]) ], []) and AC_WITH_LTDL from configure.ac (keep the LT_INIT stuff) and it will work correctly. The configure.ac declares to bundle libltdl but that's not the case, at least not in the 0.7 source tarball, which makes eautoreconf try to run autotools there even if they are not present.
Created attachment 282365 [details, diff] libmp3splt-0.7-libltdl.patch As @INCLTDL@ and @LIBLTDL@ are used in Makefile.am I run into compile errors when just removing stuff as you proposed. With these lines added it compiles: +AC_SUBST([INCLTDL], []) +AC_SUBST([LIBLTDL], [-lltdl]) So what I could do is: 1) disintegrate libmp3splt-0.7-maintainer-mode.patch and 2) integate the new libmp3splt-0.7-libltdl.patch What do you think?
Yeah that looks right, thanks for taking this up! :)
Thanks for your help! + 07 Aug 2011; Sebastian Pipping <sping@gentoo.org> libmp3splt-0.7.ebuild, + +files/libmp3splt-0.7-libltdl.patch, + -files/libmp3splt-0.7-maintainer-mode.patch: + Move from eautoconf to eautoreconf (bug #377999) +
