Re: Help transition to gettext 0.15
On Tue, Sep 12, 2006 at 08:02:29AM -0300, Damián Viano wrote:
> I'd like to discuss about the fixes to this bugs also...
>
> On Sun, Sep 10, 2006 at 07:52:39PM -0300, Damián Viano wrote:
> > The bugs I've seen from this rebuilt are mostly 3:
> > - #386487: FTBFS: aclocal: macro `AM_PROG_MKDIR_P' required but not
> > defined
>
> I'm not sure about this, but replacing the AC_REQUIRE([AM_PROG_MKDIR_P])
> call for AC_REQUIRE([AC_PROG_MKDIR_P]) in gettext.m4 and po.m4 seems to
> fix it, although I'm not sure if this would be the better (or even
> correct?) fix. Any comments regarding this Denis?
Here is the current status of RC bug reports
* #385177 meld: Problem with plural forms. Patch in the BTS, NMU planned
in few days.
* #386220 gchangepass: No rule to make target `m4/inttypes.m4', needed by
`aclocal.m4'. Stop.
Patch in the BTS, dicsussion below.
* #386222 lyskom-tty-client: po/Makefile.in.in has to be updated.
I cannot reproduce this one in a clean chroot, it can certainly be
closed or downgraded.
* #386072: gnome-lokkit: aclocal: macro `AM_PROG_MKDIR_P' required but not
defined.
Two packages only have to be fixed because of changes in *.m4. So I
believe that we should fix these packages and not messing up gettext m4
files.
More discussion below.
> > - #385235: gettext 0.15 causes build failures in multiple packages
>
> This is the plurals problem, and I think
Right. Many packages contain invalid PO files, but MO files are also
shipped and thus do not need to be rebuilt. This is an upstream
problem, only one package has still to be fixed (meld).
> > - some about @MKINSTALLDIRS@ failures, which was previously being
> > defined in AM_GNU_GETTEXT and now it's not
>
> This one is my biggest doubt, and I see 3 options:
>
> - re-gettextize the packages (to get a newer version of the
> po/Makefile.in.in)
> - patch the po/Makefile.in.in
> - Add the definition of MKINSTALLDIRS in AM_GNU_GETTEXT again
>
> I'd also like to hear comments from Denis on this, my own comments
> follow...
>
> Re-gettextize is hard in most cases, the gettext Makefile.in.in changed
> a lot, it uses an extra file (Makevars), and the case I tested couldn't
> be represented in a diff (due to symlinks problems, although it might
> be possible to avoid those). I see all this very difficult to do in a
> rules file.
>
> Patching the Makefile.in.in seems the easiest way, specially if it was
> already patched (or sed'ed).
>
> Adding the definition of MKINSTALLDIRS to AM_GNU_GETTEXT seems to be
> quite easy too (my m4 foo is not strong enough to do this in a
> reasonable way to provide a patch), and would be consistent to some
> extent with other backward compatibility subts made there. The question
> of which program should be used as MKINSTALLDIRS is not trivial *to me*,
> can someone enlighten me about that? mkdir -p? install-sh -p?
> mkinstalldirs again? could this possibly be defined according to the
> required version of autotools/gettext?
The gchangepass package contains symlinks in m4/*.m4 to
/usr/share/aclocal/*.m4. These links were generated by an invocation of
gettextize, but two links do no more exist, hence a build failure. This
is a very bad idea, those files cannot be patched because they are
symlinks (as you already noticed).
Maintainer should have called 'gettextize --copy' instead, there would
not be any problem. My suggestion is thus to create a new gchangepass
tarball. Debian maintainer is upstream, so there should be no problem.
Gnome-lokkit is a little bit different, the problem is that it calls
aclocal when building the package. It Build-Depends on automake 1.4,
but it seems that gettext now requires a more recent automake (I thought
that this was already the case previously, well I was surely wrong).
The best solution is to upgrade configuration files to automake 1.9,
but this may be quite hard. Another option is to grab an old version
of gettext, run 'gettextize --copy' to generate gettextize m4 files.
Fortunately this is automated by autopoint. In fact, debian/rules
already call autopoint, but it needs more tweaking, a patch has just
been sent to #386072.
In short, there does not seem to be any reason to patch gettext,
three packages need to be uploaded, that's all.
Denis
Reply to: