Bug 523713

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.

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 "?".

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.

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.

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".

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.

I think this could be done if QE is happy.

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.

(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.)

While there are some welcome improvements in 0.18 (10x msgmerge speed-up), 0.17 will solve the problem with less risk of disruption.

If you want this for 5.6 probably better to add some bugs here
that this blocks?

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.

    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.

https://brewweb.devel.redhat.com/buildinfo?buildID=141676

Jim, if you have a chance to test that would be helpful.

    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.

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.

    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.

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.

Created attachment 456127 [details]
make log

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.

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.

Thanks, but the interesting part is the code that does AC_SUBST([MKINSTALLDIRS]).
Which .m4 file contains *that* definition?

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)

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?

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.

Thank you Jim.

As you commented, I will have make check test.

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

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.