Bug 1179182

Please see the upstream announcement, there are some minor incompatibilities:
http://www.mail-archive.com/autotools-announce@gnu.org/msg00115.html

I don't think there is some change which could break builds of big subset
of Fedora packages, so updating in Rawhide.

http://pkgs.fedoraproject.org/cgit/automake.git/commit/?id=f7306e7b3ffd2

Ok I hity one such "unlikely to break" packages.
I tried to build gssntlmssp with a bugfgix patch and the build[1] failed with:

+ ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-wbclient --disable-static --disable-rpath
configure: WARNING: unrecognized options: --disable-rpath
configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
error: Bad exit status from /var/tmp/rpm-tmp.9SfKFn (%build)
    Bad exit status from /var/tmp/rpm-tmp.9SfKFn (%build)


What is the recommended way to handle this in the fedora package ?


[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=602640

(In reply to Simo Sorce from comment #3)
> Ok I hity one such "unlikely to break" packages.
> I tried to build gssntlmssp with a bugfgix patch and the build[1] failed
> with:
> 
> + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu
> [...]

Ouch, sorry - it seems to be about this commit:
http://git.savannah.gnu.org/cgit/automake.git/commit/?h=minor&id=7bc592708cc65

Quite simple to revert, though we should rather find proper fix and fix it
upstream and possibly hotfix in rawhide?

> What is the recommended way to handle this in the fedora package ?

I'm not sure yet, so not clearing the needinfo;  I'll post asap.  The
workaround is obvious for your case (if you hurry for the build):

  ln -s build/install-sh install-sh

however I'm not sure yet whats the real trigger (why other packages don't
build-fail, or if they do how big audience is here).  Let me please check
tomorrow please (it is getting late today).

Pavel

Simo, for your particular case, I would probably move the AC_CONFIG_AUX_DIR
macro before anything else BUT after the AC_INIT macro.  There is very
interesting macro dependency chain and it seems to me that
AC_USE_SYSTEM_EXTENSIONS requires AC_CONFIG_AUX_DIR_DEFAULT (transitively
through AM_AUX_DIR_EXPAND) and this macro should not ideally be called when
AC_CONFIG_AUX_DIR is used.  Actually, it is not called if AC_CONFIG_AUX_DIR is
called sufficiently early.

[OT] I would move AC_CONFIG_SRCDIR, AC_CONFIG_MACRO_DIR, and possibly others
autoconf related macros. [/OT]

I'll try to look at it more deeply and ping upstream (autoconf/automake),
there are some macro builtins which could be used to warn you about this
situation (I'm not sure yet whether this is bug or not).

That's good advice for upstream, but how do I handle downstream ?
Do I need to patch configure.ac ?

(In reply to Simo Sorce from comment #6)
> That's good advice for upstream, but how do I handle downstream ?
> Do I need to patch configure.ac ?

There are probably different ways, but I would patch configure.ac as that
should be good candidate for upstream proposal.

Thank you,
I ended up removing all three directives you mentioned from the upstream configure.ac and then dferived a patch for rawhide until a new upstream relase is out.