Bugzilla Bug 226311

Rebuilding autotools through maintainer-mode is _not_ good, because it usually
means you forget to add dependencies, and they'll magically use the same
version as used by upstream, which might not be what the user have installed at
all.

If you patch Makefile.am or configure.in/configure.ac you _have to_ use
autotools.eclass and eautomake/eautoreconf. Exceptions are granted _only_ for
system packages that would make it impossible to run autotools during
stagebuilding.

Please fix your package.

Please show me the proof that it is actually rebuilt. Patching Makefile.am and
Makefile.in together and/or configure.in and configure together is no problem
in my years of experience. It is a problem when Makefile.am or configure.in is
patched, but not Makefile.in/configure and eautoreconf is not called - then it
will hit maintainer-mode rebuild, but we patch all matching things unless you
provide a build.log that shows otherwise.
So this is INVALID until such a time.

config.status: pango/pango-features.h is unchanged
configuration:
        backends: FreeType X Xft Cairo
 cd . && /bin/sh
/var/tmp/portage/x11-libs/pango-1.20.5/work/pango-1.20.5/missing --run
automake-1.10 --gnits  Makefile
aclocal.m4:16: warning: this file was generated for autoconf 2.61.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically `autoreconf'.
configure.in:126: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...):
suspicious cache-id, must contain _cv_ to be cached
../../lib/autoconf/general.m4:1973: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:1993: AC_CACHE_CHECK is expanded from...
aclocal.m4:687: AC_LIBTOOL_COMPILER_OPTION is expanded from...
aclocal.m4:4977: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from...
aclocal.m4:2757: _LT_AC_LANG_C_CONFIG is expanded from...
aclocal.m4:2756: AC_LIBTOOL_LANG_C_CONFIG is expanded from...
aclocal.m4:134: AC_LIBTOOL_SETUP is expanded from...
aclocal.m4:114: _AC_PROG_LIBTOOL is expanded from...
aclocal.m4:79: AC_PROG_LIBTOOL is expanded from...
aclocal.m4:6522: AM_PROG_LIBTOOL is expanded from...
configure.in:126: the top level
configure.in:126: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...):
suspicious cache-id, must contain _cv_ to be cached
aclocal.m4:732: AC_LIBTOOL_LINKER_OPTION is expanded from...
configure.in:126: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, ...):
suspicious cache-id, must contain _cv_ to be cached
aclocal.m4:2834: _LT_AC_LANG_CXX_CONFIG is expanded from...
aclocal.m4:2833: AC_LIBTOOL_LANG_CXX_CONFIG is expanded from...
aclocal.m4:1882: _LT_AC_TAGCONFIG is expanded from...
configure.in:126: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_CXX,
...): suspicious cache-id, must contain _cv_ to be cached
configure.in:126: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_F77, ...):
suspicious cache-id, must contain _cv_ to be cached
aclocal.m4:4056: _LT_AC_LANG_F77_CONFIG is expanded from...
aclocal.m4:4055: AC_LIBTOOL_LANG_F77_CONFIG is expanded from...
configure.in:126: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_F77,
...): suspicious cache-id, must contain _cv_ to be cached
configure.in:126: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ, ...):
suspicious cache-id, must contain _cv_ to be cached
aclocal.m4:4165: _LT_AC_LANG_GCJ_CONFIG is expanded from...
aclocal.m4:4164: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from...
configure.in:126: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_GCJ,
...): suspicious cache-id, must contain _cv_ to be cached
 cd . && /bin/sh ./config.status Makefile
config.status: creating Makefile
Making all in pango
Making all in opentype


is this bloody enough for you?
Have you even bothered checking the ebuild? Have you bothered checking 
"${FILESDIR}/${PN}-1.2.5-lib64.patch" ?

Hey, chill out friends, it's no big deal :)

I've commented out the first hunk in the patch (now only the C file and
Makefile.in are actually modified) and indeed maintainer-mode is no longer
activated.

Fixed in CVS.

This is absolutely wrong. This will break under our nose as soon as we add a
complex build system patch that will need an eautoreconf

(In reply to comment #2)
> Have you even bothered checking the ebuild? Have you bothered checking 
> "${FILESDIR}/${PN}-1.2.5-lib64.patch" ?

Yes, it patches both, so it should be fine. Please elaborate on the appropriate
thread on gentoo-dev that I posted about this ordeal two weeks ago with your
comments on why this is technically not enough. Because it is for most packages
and we should fix it properly, not throw eautoreconf waiting time to all of our
users.

Diego,

I've forced the old patch (that modifies both Makefile.{in,am}) to apply
without multilib and I can't reproduce the autoremake.

Could you attach a full build.log and emerge --info so we can compare with what
you have on your system?

Thanks

Created an attachment (id=160661) [details]
x11-libs:pango-1.20.5:20080704-133609.log

Feel free, I actually told eva more than once about this thing not working
properly.

If you want a reason for the problem: 2003 is _way_ behind from today, the rest
of the autotools will result newer than the Makefile.in, and there you go with
your maintainer mode triggered.

Diego, I have a hunch that the patch is not causing this, because the Makefile
causing the autoremake is ${S}/Makefile.in and not ${S}/pango/Makefile.in
(which is the one modified by the patch).

Could you try rebuilding pango with the lib64 patch completely disabled?

Thanks

*** Bug 226841 has been marked as a duplicate of this bug. ***

This should not happen nowadays because the Makefile.am part is commented out,
however I looked at the timestamps of the patch and it doesn't seem to be the
reason why the maintainer mode was triggered. I wonder what else could have
triggered this.

We shouldn't be commenting out the Makefile.am chunk.
The patch tool guarantees (I'm 98% sure) us that all files in one patch file
will have an equal timestamp after patching.