Am 13.04.26 um 12:21 schrieb Kevin J. McCarthy:
On Mon, Apr 13, 2026 at 10:33:31AM +0200, Oswald Buddenhagen via
Mutt-dev wrote:
On Mon, Apr 13, 2026 at 12:44:21PM +0800, Kevin J. McCarthy wrote:
The only workaround I could
find was running autoreconf with '-if' to force install.
this is a completely normal thing to require for a build from a git.
why are these .m4 files even in the repository?
Hi Oswald,
Historically they have been, for far longer than when I came on the
project. The prepare script seems not to have been changed for 19
years. I haven't seen this problem since I've been maintaining mutt,
so I'm a bit confused.
Hi everyone, long time no mail to the lists from my part...
It helps to put a line "AM_GNU_GETTEXT_VERSION(0.21)" into
configure.ac. Reason is this is the only way to tell autopoint (which
runs underneath autoreconf) to know what version the m4/ and po/ files
it copies are from. It doesn't know, so it can break on any system
that's sufficiently far away from the 0.21 files that Kevin checked into
these folders 2021, with
https://gitlab.com/muttmua/mutt/-/commit/ccc18061461c025ee05754d4b9e8f94db2fdb233
My routine for git checkouts is "autoreconf -isvf", or, spelled out,
"autoreconf -install --symlink --verbose --force"; gettext on the
maintainer's (Kevin's) system changes, autopoint needs the --force
option to get the matching files there in case it's unspecified or
somehow doesn't work because then autopoint has the liberty of making
everything consistent (autoreconf passes the --force option through).
Now, the CI builder or another developer's computer may have a different
gettext version then Kevin, and then that developer or CI job's notion
of what gettext should be ("whatever I have locally") and what's in m4/
are inconsistence, and that wreaks havoc. I have seen over the years
that some files get added to m4/, others are removed.
In fetchmail, the only package I maintain (upstream) that uses GNU
gettext, I do not check in m4/ files, but my CI setup is also
considerably narrower than mutt's apparently, and I test on a few Linux
distros, FreeBSD, and occasionally OpenBSD
When I updated to a vanilla gettext configuration with gettextize five
years ago, I committed the changes, as I thought the manual suggested:
https://www.gnu.org/software/gettext/manual/html_node/Distributed-Development.html
However, if it I did something wrong, then let's talk about what needs
to be changed.
The "something wrong" part can be fixed by adding one line
AM_GNU_GETTEXT_VERSION(0.21) to configure.ac
Thas two impacts:
1. it specifies the oldest that can be on a user's computer when
building mutt (because we set AM_GNU_GETTEXT([external]) as is advised),
to avoid arcane errors but make the minimum version explicit, and if
autopoint is older than 0.21, it will reject and suggest updating. Since
autopoint runs before ./configure, --disable-nls does not help.
2. it tells developers' autopoint that the m4/ files are good, and on my
Fedora 43 (which has gettext 0.25.1), it only wants to add
po/Makevars.template (which is for bootstrapping things, but mutt
already has po/Makevars, so it's of limited use -- for maintainers still
helpful only during gettextize-based updates to see if new configuration
items appear by diffing Makevars and the .template and look what's local
customization and what's upstream addition).
HTH
Cheers,
Matthias
