Bug 523713 - update to newer gettext in RHEL5
update to newer gettext in RHEL5
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gettext (Show other bugs)
5.6
All Linux
high Severity high
: rc
: ---
Assigned To: Jens Petersen
QE Internationalization Bugs
: i18n, Rebase
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-16 10:23 EDT by Jim Meyering
Modified: 2013-03-13 16:41 EDT (History)
8 users (show)

See Also:
Fixed In Version: gettext-0.17-1.el5
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Since the previous version of gettext no longer works with a large number of newer software projects, this updated package installs gettext version 0.17, which allows packages that require modern gettext to build successfully. Note: The Java and libintl.jar support has been discontinued.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-13 17:38:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
make log (2.10 KB, application/x-gzip)
2010-10-27 22:40 EDT, Kenichi Takemura
no flags Details

  None (edit)
Description Jim Meyering 2009-09-16 10:23:35 EDT
Description of problem:

Rich Jones and I (while working on libguestfs) have spent more than
30 minutes with a problem whose root cause lay with the fact that RHEL is
using an obsolete version of gettext: 0.14.6
[and this isn't the first time that RHEL's obsolete gettext has bitten us]

It is so old that when its po/M* templates are used with newer .m4 files
(as required in gnulib-using projects), the resulting configure
script no longer replaces at least one key symbol: @MKINSTALLDIRS@
That makes it so that this regular part of a build fails:

    $ make -C po DESTDIR=/tmp/pp install
    ...
    make[1]: Leaving directory `/h/meyering/w/co/libguestfs/po'
    touch stamp-po
    /bin/sh @MKINSTALLDIRS@ /tmp/pp/usr/local/share
    /bin/sh: @MKINSTALLDIRS@: No such file or directory
    make: *** [install-data-yes] Error 127
    make: Leaving directory `/h/meyering/w/co/libguestfs/po'

We were in that situation partly because the RHEL limitation required that we use AM_GNU_GETTEXT_VERSION([0.14]) in configure.in.
The latest is 0.17.
Using even 0.15 would have been enough to solve this particular problem, but that is not available in RHEL5.

Why is it ok to use newer versions of tools like autoconf, automake
and gettext in "stable" releases like RHEL?  Because if we don't,
their lack (the old obsolete ones) tend to stifle development efforts
based on RHEL, and discourage developers from using the platform.
Also, while you can say the above about lots of tools, these three
tools stand out for their exceptional stability and attention to
backwards compatibility.

There is precedent: automake-1.11 was added to RHEL4 and RHEL5 not long ago, for the same reason.



Version-Release number of selected component (if applicable): 0.14.6


How reproducible:


Steps to Reproduce:
1. see above (that was building libguestfs from a git clone)
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Paolo Bonzini 2009-09-22 17:51:48 EDT
I can add that the source code for all past versions of the gettext library is included (as RCS files) for use by the "autopoint" program that is part of gettext.

So, this does not affect programs that are stuck using an older version of gettext.
Comment 2 RHEL Product and Program Management 2009-11-06 14:14:39 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 3 Jim Meyering 2010-02-24 04:47:51 EST
I have just diagnosed yet another build failure (this time in libvirt) due to the fact that RHEL5 has support for only the ancient gettext-0.14.  There is no reason *not* to provide the latest, since doing that does not force any package to change its usage.
Comment 4 Jim Meyering 2010-03-21 16:56:55 EDT
Just a reminder that this really is worth pushing into 5.6 -- and safe.
If you're tempted to NAK it, please give me a heads up,
and I'll be happy to provide justification.
Comment 5 Jim Meyering 2010-03-24 05:17:29 EDT
Independently my note of 3 days ago (above), I've just noticed the following
complications in upstream libvirt developement that arise solely because
we're stuck with gettext-0.14 due to our desire to build on RHEL5.
That old version of gettext uses the now-obsolete MKINSTALLDIRS
variable, which is causing the latest problem:

  http://thread.gmane.org/gmane.comp.emulators.libvirt/22504

This is yet another example of how refusing to upgrade this package in RHEL5 hurts our development efforts.  Considering two things:
  - the number and frequency of these problems
  - their relative subtlety -- it is hard enough to diagnose that, while they
      may cause trouble with our customers, the typical developer will not
      trace the problem back to a package's use of an old gettext.

Bearing those in mind, I've just raised this bug's priority to "high".
Comment 6 Jim Meyering 2010-03-24 05:19:09 EDT
Hi Eric,
I've Cc'd you on this, so you'll know why we are currently stuck with gettext-0.14 in libvirt/RHEL5.
Comment 7 Jens Petersen 2010-04-27 21:56:40 EDT
I think this could be done if QE is happy.
Comment 8 Jim Meyering 2010-05-21 11:15:14 EDT
Jens, then please let's get QE to sign off on it ASAP.
It has been causing wasted developer time yet again, just today.
I've raised severity to HIGH, in case increased visibility will help.
Comment 9 Jens Petersen 2010-05-23 20:00:17 EDT
(I note that gettext-0.18 was released recently upstream,
but it is not yet even in fedora so maybe it is safer to stay
with 0.17 for now.)
Comment 10 Jim Meyering 2010-05-24 02:52:34 EDT
While there are some welcome improvements in 0.18 (10x msgmerge speed-up), 0.17 will solve the problem with less risk of disruption.
Comment 13 Jens Petersen 2010-07-06 02:15:48 EDT
If you want this for 5.6 probably better to add some bugs here
that this blocks?
Comment 14 Paolo Bonzini 2010-07-16 06:41:36 EDT
There are two problems caused by this bug.  One is that the .m4 files used by some packages may conflict with those provided by the old RHEL version of gettext.  This can usually be worked around, but this is getting more and more inconvenient.

Upstream could simply ignore RHEL and upgrade to a newer gettext.  The problem then would simply that client packages would expect the newer gettext.  Then development of this packages could not be done on RHEL5, because gettext-provided files could not be regenerated.

In both scenarios, gettext is the same as automake and, as noted by Jim, the latest upstream version of automake (1.11) is included in RHEL5.
Comment 16 Jens Petersen 2010-08-19 04:35:07 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
The gettext package has been updated to 0.17 to work better with newer upstream project releases.
Comment 17 Jens Petersen 2010-08-27 01:42:20 EDT
https://brewweb.devel.redhat.com/buildinfo?buildID=141676

Jim, if you have a chance to test that would be helpful.
Comment 18 Jens Petersen 2010-08-27 01:44:14 EDT
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-The gettext package has been updated to 0.17 to work better with newer upstream project releases.+The gettext package has been updated to 0.17 to work better with newer upstream project releases.  Java support and libintl.jar was dropped since it needs newer gcj.
Comment 21 Jim Meyering 2010-10-04 02:54:07 EDT
Here's how to demonstrate the problem.
Try to build libvirt from cloned sources on RHEL5.x,
following instructions in README-hacking:

  http://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=README-hacking;hb=HEAD

But note that I worked around the problem, so to
demonstrate it, you'll have to back out the work-around:

Follow those instructions, but insert the following step before
the one that runs autogen.sh:

    Revert the work-around change in configure.ac:

      git show 89bdf84bcd9c60 configure.ac | patch -R -p1

I.e., do this:

    git clone git://git.sv.gnu.org/gnulib
    git clone git://libvirt.org/libvirt
    cd libvirt
    export GNULIB_SRCDIR=../gnulib
    git show 89bdf84bcd9c60 configure.ac | patch -R -p1
    ./autogen.sh
    make
    make -C po DESTDIR=/tmp/lv install

On RHEL5.x, it should fail with gettext-1.14.x
and succeed with the new one.
Comment 22 Jaromir Hradilek 2010-10-07 04:22:49 EDT
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1,3 @@
-The gettext package has been updated to 0.17 to work better with newer upstream project releases.  Java support and libintl.jar was dropped since it needs newer gcj.+Since the previous version of gettext no longer works with a large number of newer software projects, this updated package installs gettext version 0.17, which allows packages that require modern gettext to build successfully.
+
+Note: The Java and libintl.jar support has been discontinued.
Comment 23 Kenichi Takemura 2010-10-27 22:39:47 EDT
Hi Jim

I am verifying this bug trying the steps you provided.

$ rpm -qa gettext*
gettext-0.14.6-4.el5
gettext-devel-0.14.6-4.el5

But I cannot see any errors in make. Could you check the attached logs and advise me?

make.log : log of 'make'
make2.log : log of ' make -C po DESTDIR=/tmp/lv install'

(In reply to comment #21)
> Here's how to demonstrate the problem.
> Try to build libvirt from cloned sources on RHEL5.x,
> following instructions in README-hacking:
> 
>   http://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=README-hacking;hb=HEAD
> 
> But note that I worked around the problem, so to
> demonstrate it, you'll have to back out the work-around:
> 
> Follow those instructions, but insert the following step before
> the one that runs autogen.sh:
> 
>     Revert the work-around change in configure.ac:
> 
>       git show 89bdf84bcd9c60 configure.ac | patch -R -p1
> 
> I.e., do this:
> 
>     git clone git://git.sv.gnu.org/gnulib
>     git clone git://libvirt.org/libvirt
>     cd libvirt
>     export GNULIB_SRCDIR=../gnulib
>     git show 89bdf84bcd9c60 configure.ac | patch -R -p1
>     ./autogen.sh
>     make
>     make -C po DESTDIR=/tmp/lv install
> 
> On RHEL5.x, it should fail with gettext-1.14.x
> and succeed with the new one.
Comment 24 Kenichi Takemura 2010-10-27 22:40:47 EDT
Created attachment 456127 [details]
make log
Comment 25 Jim Meyering 2010-10-28 02:17:54 EDT
Kenichi,

Since my work-around in libvirt, I suspect that someone added an independent work-around in gnulib, too, so that at least gnulib-using projects are protected, even on systems with older gettext.  Thus, to reproduce the failure you would have to use an older version of gnulib, rather than the very latest.  That would require an older version of libvirt, too, and it might not be worth the trouble.

If you must reproduce the failure, you may also want to try with libguestfs.

Hmm... investigating more, I see that the old gettext's nls.m4 contains the
definition of MKINSTALLDIRS:

AC_SUBST(MKINSTALLDIRS)

Yet gnulib's file by the same name does not.
Since libvirt's bootstrap favors gnulib's m4 files over those
imported by the possibly-dated gettextize, there would be no MKINSTALLDIRS substitution.

Hence, the way to check (don't even need to build) for the failure is
to look for @MKINSTALLDIRS@ in po/Makefile after running ./configure.
If it's there, "make install" should fail.  If not, please find the code that defines it and let me know.
Comment 26 Kenichi Takemura 2010-10-28 20:54:51 EDT
Hi Jim

At the moment "make install" does not fail.
Can you check the grep result?

> If it's there, "make install" should fail.  If not, please find the code that
> defines it and let me know.

# pwd
/home/ktakemur/tmp2/libvirt

# grep '@MKINSTALLDIRS@' po/*
po/Makefile.in.in:MKINSTALLDIRS = @MKINSTALLDIRS@
po/Makefile.in.in~:MKINSTALLDIRS = @MKINSTALLDIRS@

# grep 'MKINSTALLDIRS' po/*
po/Makefile:MKINSTALLDIRS = $(top_builddir)/build-aux/mkinstalldirs
po/Makefile:mkinstalldirs = $(SHELL) $(MKINSTALLDIRS)
po/Makefile.in:MKINSTALLDIRS = $(top_builddir)/build-aux/mkinstalldirs
po/Makefile.in:mkinstalldirs = $(SHELL) $(MKINSTALLDIRS)
po/Makefile.in.in:MKINSTALLDIRS = @MKINSTALLDIRS@
po/Makefile.in.in:mkinstalldirs = $(SHELL) $(MKINSTALLDIRS)
po/Makefile.in.in~:MKINSTALLDIRS = @MKINSTALLDIRS@
po/Makefile.in.in~:mkinstalldirs = $(SHELL) $(MKINSTALLDIRS)

(In reply to comment #25)
> Kenichi,
> 
> Since my work-around in libvirt, I suspect that someone added an independent
> work-around in gnulib, too, so that at least gnulib-using projects are
> protected, even on systems with older gettext.  Thus, to reproduce the failure
> you would have to use an older version of gnulib, rather than the very latest. 
> That would require an older version of libvirt, too, and it might not be worth
> the trouble.
> 
> If you must reproduce the failure, you may also want to try with libguestfs.
> 
> Hmm... investigating more, I see that the old gettext's nls.m4 contains the
> definition of MKINSTALLDIRS:
> 
> AC_SUBST(MKINSTALLDIRS)
> 
> Yet gnulib's file by the same name does not.
> Since libvirt's bootstrap favors gnulib's m4 files over those
> imported by the possibly-dated gettextize, there would be no MKINSTALLDIRS
> substitution.
> 
> Hence, the way to check (don't even need to build) for the failure is
> to look for @MKINSTALLDIRS@ in po/Makefile after running ./configure.
> If it's there, "make install" should fail.  If not, please find the code that
> defines it and let me know.
Comment 27 Jim Meyering 2010-10-29 01:30:19 EDT
Thanks, but the interesting part is the code that does AC_SUBST([MKINSTALLDIRS]).
Which .m4 file contains *that* definition?
Comment 28 Kenichi Takemura 2010-10-29 03:00:11 EDT
Hi Jim. OO sorry! Here they are.

$ grep -r "AC_SUBST(MKINSTALLDIRS)" *

libvirt/autom4te.cache/traces.2:  AC_SUBST(MKINSTALLDIRS)
libvirt/autom4te.cache/traces.0:  AC_SUBST(MKINSTALLDIRS)
libvirt/libvirt-0.8.4/m4/nls.m4:  AC_SUBST(MKINSTALLDIRS)
libvirt/m4/nls.m4~:  AC_SUBST(MKINSTALLDIRS)
libvirt/m4/nls.m4:  AC_SUBST(MKINSTALLDIRS)
Comment 29 Jens Petersen 2010-11-01 23:13:10 EDT
I tried to bootstrap libvirt-0.7.6 (the last release before the AC_SUBST fix)
but still can't get a build error.  I guess this is really a developer
bootstrapping problem so it might be harder to find examples of releases
with such failures?

(Just a side-remark: RHEL5 still seems to have automake-1.9.6.)

Anyway Jim, what are your suggestions: short of coming up
with a backwards regression package build testcase, what would
you suggest Kenichi tests to cover the QA for the new gettext package?
Comment 30 Jim Meyering 2010-11-09 09:45:46 EST
Jens, Kenichi,  sorry about the delay.
I did spend some time trying to reproduce the failure, but could not.  Then I ran out of time while investigating what might have changed to cause the success.

I think gettext's own "make check" tests should suffice.
Given how old sources are used when required, I'm not worried about backwards compatability.
Comment 31 Kenichi Takemura 2010-11-09 21:20:53 EST
Thank you Jim.

As you commented, I will have make check test.
Comment 38 errata-xmlrpc 2011-01-13 17:38:08 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2011-0047.html
Comment 44 Jim Meyering 2011-01-20 12:44:25 EST
To anyone who encounters a problem with the newer gettext-0.17 when rebuilding a RHEL-5 package, here's something to check, especially if you see an unexpanded @MKINSTALLDIRS@ string in po/Makefile:

If you see the above, your package sources probably include a po/Makefile.in.in file that was generated by gettext-0.14.  Since that is a generated file, it's the packager's job to ensure that when a newer gettext comes along, that it is used to regenerate things.  If the spec file does something like this:

  %build
  aclocal
  autoconf

then that is the problem: the build rules do not run gettextize -f,
which would have updated your old po/Makefile.in.in file, thus removing
the reference to the obsolete symbol, @MKINSTALLDIRS@.

You should replace the above with the following:

  %build
  autoreconf -i

autoreconf automatically runs gettextize as well as the other tools, as needed.

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