Bug 1179182 - automake-1.15 is available
Summary: automake-1.15 is available
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: automake
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Pavel Raiskup
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-06 12:01 UTC by Upstream Release Monitoring
Modified: 2015-01-30 18:14 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-01-07 18:58:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1187719 0 unspecified CLOSED [gssproxy] fix FTBFS with new automake-1.15 2021-02-22 00:41:40 UTC

Internal Links: 1187719

Description Upstream Release Monitoring 2015-01-06 12:01:16 UTC
Latest upstream release: 1.15
Current version/release in Fedora Rawhide: 1.14.1-6.fc22
URL: http://ftp.gnu.org/gnu/automake/

Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring Soon this service will be implemented by a new system: https://release-monitoring.org/
It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition.

Comment 1 Pavel Raiskup 2015-01-07 11:50:33 UTC
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.

Comment 3 Simo Sorce 2015-01-07 20:56:27 UTC
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

Comment 4 Pavel Raiskup 2015-01-07 23:16:07 UTC
(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

Comment 5 Pavel Raiskup 2015-01-08 09:50:53 UTC
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).

Comment 6 Simo Sorce 2015-01-08 14:02:20 UTC
That's good advice for upstream, but how do I handle downstream ?
Do I need to patch configure.ac ?

Comment 7 Pavel Raiskup 2015-01-08 14:16:39 UTC
(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.

Comment 8 Simo Sorce 2015-01-08 18:06:40 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.