Bug 2366708

ref: https://src.fedoraproject.org/rpms/gettext/c/9b44db8d2186b3d52ece9adddc945de27dac580a?branch=rawhide

We should make upstream aware of this I think, Manish

Wow! It's even an explicit change in the spec file that ought to have served as an early warning system:
https://src.fedoraproject.org/rpms/gettext/c/9b44db8d2186b3d52ece9adddc945de27dac580a?branch=rawhide

1. Upstream has provided a response regarding above issue : https://lists.gnu.org/archive/html/bug-gettext/2025-05/msg00041.html
2. Upstream has confirmed in https://savannah.gnu.org/bugs/?66968 that these issues occur when the dependent package's build recipe lacks an autopoint invocation.

Thanks Manish - so tl;dr this is actually an intentional upstream change and it seems using autopoint (from gettext-devel) should fix this issue.

If not please let us know: thanks for reporting.

Confirmed.
https://src.fedoraproject.org/rpms/claws-mail/c/51370282e11ad41c3a65b23a98767e46f48e793e?branch=rawhide

It's a low-level problem in autoreconf, which is aware of autopoint and in its manual claims it would run it, but it cannot cope with completely missing macro files apparently.

Thanks Michael - I was also wondering if something on the autotools side could help alleviate this, but perhaps not.

But:

* Basically autopoint seems to just doing cp'ing m4 files into local working directory - what is the point of
  doing this instead of just placing them on /usr/share/aclocal at the first place?

* And more and more packages are failing:
  https://koschei.fedoraproject.org/package/xscreensaver?collection=f43
  https://koschei.fedoraproject.org/package/ghemical?collection=f43

  Basically it seems packages calling intltool all have to modify.
  Can you check in total which packages are affected by this?

Some more response from upstream that might be helpful : https://lists.gnu.org/archive/html/bug-gettext/2025-05/msg00045.html

For people who don't want to run autopoint since I think that might do more then one wants, e.g. lcd4linux only needs AM_ICONV, a workaround is to add the following line to the .spec file before calling "./bootstrap",  "autoreconf -ivf" or something similar:

export ACLOCAL_PATH=/usr/share/gettext/m4/

(In reply to Mamoru TASAKA from comment #8)
> * Basically autopoint seems to just doing cp'ing m4 files into local working directory - what is the point of doing this instead of just placing them on /usr/share/aclocal at the first place?

autopoint copies not only a few *.m4 files but also the po/Makefile.in.in file. These need to be consistent (that is, from the same GNU gettext version); if they are not consistent, errors occur, as reported in <https://savannah.gnu.org/bugs/?66968>.

autopoint makes sure that they are consistent. An 'autoreconf' invocation without an 'autopoint' invocation does not.

(In reply to Hans de Goede from comment #10)
> For people who don't want to run autopoint since I think that might do more
> then one wants, e.g. lcd4linux only needs AM_ICONV, a workaround is to add
> the following line to the .spec file before calling "./bootstrap", 
> "autoreconf -ivf" or something similar:
> 
> export ACLOCAL_PATH=/usr/share/gettext/m4/

The condition is not whether you "want to run autopoint" or not.

The condition is whether the package has a po/ directory which are supposed to manage translations.
* If yes, you *must* invoke autopoint. This is documented at https://www.gnu.org/software/gettext/manual/html_node/autoconf-macros.html .
* If no, the suggested ACLOCAL_PATH trick would work too.

The problem of this ACLOCAL_PATH trick is that other Fedora package maintainers will copy it from one spec file to another, and then we are back at the inconsistency problems that gettext 0.24.1 and 0.25 are meant to fix.

To prevent this, better add a comment:

----------------------------------------------------------------------------------
# This setting is *ONLY* valid for packages that do not have a po/ directory.
# For packages with a po/ directory, don't do this! Invoke 'autopoint' instead.
export ACLOCAL_PATH=/usr/share/gettext/m4/
----------------------------------------------------------------------------------

What we want is for 'autoreconf' to replace all the *.m4 files in a package
with known good versions, to avoid a repeat of the xz debacle where an
upstream tarball had the *.m4 files replaced by subverted versions.  We don't
want it to do anything else.

For the projects I'm using, we junked the po/Makefile.in.in stuff and replaced
it with our own, much simpler versions.

If the above isn't possible, let us know so we can replace all the *.m4 stuff with
something simpler (and saner).

(In reply to Richard W.M. Jones from comment #13)
> What we want is for 'autoreconf' to replace all the *.m4 files in a package
> with known good versions, to avoid a repeat of the xz debacle where an
> upstream tarball had the *.m4 files replaced by subverted versions.  We don't
> want it to do anything else.
> 
> For the projects I'm using, we junked the po/Makefile.in.in stuff and
> replaced
> it with our own, much simpler versions.
> 
> If the above isn't possible, let us know so we can replace all the *.m4
> stuff with
> something simpler (and saner).

Redirecting this discussion to https://lists.gnu.org/archive/html/bug-gettext/2025-05/msg00046.html. Please reply to bug-gettext. A mailing list is the better place, than a bug tracker, for this kind of discussion.