gettext 0.23.x

[Santiago Vila]

Greetings.

I've just uploaded gettext 0.23.1-0.1 for experimental.

[ This is preliminary, don't worry for the changelog, there will be a
proper one in unstable. Also please don't close any bugs yet, I want
to close them in unstable ].

There is a list of upstream changes here:

https://savannah.gnu.org/news/?id=10699

I've built the whole archive with the new gettext and I know that
the number of packages which FTBFS is approximately 22
(originally 24 but I already fixed two of them).

In most cases, the failure is like this:

make[3]: Entering directory '/<<PKGBUILDDIR>>/po'
*** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.20 but the
autoconf macros are from gettext version 0.22

and I expect that the trick I used for sitecopy (QA maintained), which
is to copy Makefile.in.in *after* dh_autoreconf:

https://salsa.debian.org/debian/sitecopy/-/commit/27e4ed4205b7c62197f0428b6890d7bac2f5692e

will also work in many other cases.

My plan is to report those bugs with severity:important now
and then wait a week before uploading gettext for unstable (at which
time the remaining bugs would be RC).

Would the Release Managers approve this?

Thanks.

[Guillem Jover]

Hi!

Post by Santiago Vila
I've just uploaded gettext 0.23.1-0.1 for experimental.

Ah, great, thanks!

Post by Santiago Vila
make[3]: Entering directory '/<<PKGBUILDDIR>>/po'
*** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.20 but the
autoconf macros are from gettext version 0.22
and I expect that the trick I used for sitecopy (QA maintained), which
https://salsa.debian.org/debian/sitecopy/-/commit/27e4ed4205b7c62197f0428b6890d7bac2f5692e
will also work in many other cases.

I think this indicates a problem in the upstream autotools support,
and it might be better to try to fix that instead of adding what seems
like a workaround that might end up causing problems too due to the
(silenced) version mismatch.

I don't see the gettext version in the repo yet, but perhaps you could
try whether the attached patch fixes the above issue (and potentially
similar ones too).

The problem with AM_GNU_GETTEXT_VERSION is that it requires an exact
version (from the autpoint gettext archive.dir.tar.xz) while
AM_GNU_GETTEXT_REQUIRE_VERSION requires at least the specified version
but will pull in the latest available, which in our case should in
theory match the one used for the autoreconf.

(For upstream submission, depending on the version requirements, you
might want to have both, for backward compatibility reasons, for an
example of this see
<https://git.dpkg.org/cgit/dpkg/dpkg.git/tree/configure.ac#n33>.)

Thanks,
Guillem

[Santiago Vila]

Post by Guillem Jover
I think this indicates a problem in the upstream autotools support,
and it might be better to try to fix that instead of adding what seems
like a workaround that might end up causing problems too due to the
(silenced) version mismatch.

I already did. Bruno says that autoreconf is not always expected to produce
a working package because of the heuristics it uses.

Post by Guillem Jover
I don't see the gettext version in the repo yet, but perhaps you could> try whether the attached patch fixes the above issue (and potentially
similar ones too).

(Note: For gettext, I'm currently using different repos for unstable
and experimental because I didn't fully get the hang on gbp yet. Will
ask in -mentors about this one day).

I'll try the proposed patch for sitecopy and see if it works for
other packages too.

Thanks a lot!

[Guillem Jover]

Hi!

Post by Santiago Vila

Post by Guillem Jover
I think this indicates a problem in the upstream autotools support,
and it might be better to try to fix that instead of adding what seems
like a workaround that might end up causing problems too due to the
(silenced) version mismatch.

I already did. Bruno says that autoreconf is not always expected to produce
a working package because of the heuristics it uses.

Ah, sorry, my wording was probably confusing. I think gettext works as
advertised. I meant the autotools support from the upstream project
that is currently failing to build, such as sitecopy.

Post by Santiago Vila

Post by Guillem Jover
I don't see the gettext version in the repo yet, but perhaps you could> try whether the attached patch fixes the above issue (and potentially
similar ones too).

(Note: For gettext, I'm currently using different repos for unstable
and experimental because I didn't fully get the hang on gbp yet. Will
ask in -mentors about this one day).

Sorry again here, I meant the Debian experimental repo, not git repo
(didn't even look for that :).

Post by Santiago Vila
I'll try the proposed patch for sitecopy and see if it works for
other packages too.

Great, thanks!

Regards,
Guillem

[Santiago Vila]

Hi. Since this is standard procedure, I've just filed the bugs:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-***@lists.debian.org;tag=gettext-0.23

but with the caveat that I don't know when I will able to do the upload
for unstable. At this moment I don't want to think about NMUs yet.

Note for Guillem: I've included your suggested fix in the bug template.

Thanks.

[Simon Josefsson]

Post by Santiago Vila
but with the caveat that I don't know when I will able to do the upload
for unstable. At this moment I don't want to think about NMUs yet.

Yay! I'm happy to help with NMUs if needed. I think getting gettext
0.23.x into trixie would be good.

Post by Santiago Vila
Note for Guillem: I've included your suggested fix in the bug template.

I don't think we should patch upstream code for things that aren't clear
upstream bugs. Patching upstream code in Debian packaging has a
maintainance cost and some risks. As far as I understand, the reason
for the FTBFS's isn't due to upstream misuse of gettext, it is a symptom
of how Debian packaging is (mis-)using autotools. I suggest generally
to not patch upstream code without reporting it upstream. In this case,
I don't think filing upstream bugs is a good idea: it seems more
appropriate if we fix this via debian/rules instead of putting fixes to
Debian-specific problems into upstream code (especially since the fix
changes upstream semantics wrt gettext so isn't guarantee to be what
upstream prefer). Some of the packages seems to already do strange
things in debian/rules related to gettext and autotools, so I think at
least some of these are packaging bugs and not upstream bugs.

/Simon

[Guillem Jover]

Hi!

Post by Simon Josefsson

Post by Santiago Vila
Note for Guillem: I've included your suggested fix in the bug template.

Great, thanks!

Post by Simon Josefsson
I don't think we should patch upstream code for things that aren't clear
upstream bugs. Patching upstream code in Debian packaging has a
maintainance cost and some risks.

I disagree. Regardless of this being an upstream bug or not, I think
patching should and has always been an option, if it improves our lives,
or gives better behavior when integrating with the packaging.

Integration into a distribution implies potentially making different
trade-offs, which are not necessarily upstream bugs.

Post by Simon Josefsson
As far as I understand, the reason
for the FTBFS's isn't due to upstream misuse of gettext, it is a symptom
of how Debian packaging is (mis-)using autotools.

While an upstream would not usually see this particular issue, unless
running autoreconf on an already autoreconf'ed tree during development
(for example), the semantics for AM_GNU_GETTEXT_VERSION might seem to
give some sense of control, but at the same time these seem
counterproductive, in a similar way as if a project requested that it
needs an exact version of any other tool (when a minimum would work as
well and give users an easier time), notice how this behavior diverges
from for example autoconf's AC_PREREQ which only requires a specific
minimum version. This seems like a recipe to ship obsolete build system
infrastructure, so in that sense it still looks like something
worthwhile I'd still propose upstream.

Post by Simon Josefsson
In this case, I don't think filing upstream bugs is a good idea: it
seems more appropriate if we fix this via debian/rules instead of
putting fixes to Debian-specific problems into upstream code
(especially since the fix changes upstream semantics wrt gettext so
isn't guarantee to be what upstream prefer). Some of the packages
seems to already do strange things in debian/rules related to gettext
and autotools, so I think at least some of these are packaging bugs
and not upstream bugs.

Personally I think using AM_GNU_GETTEXT_REQUIRE_VERSION is the better
fix (both for upstream and for our packages), as it gives better
semantics, and should reduce workarounds, hacks and hardcoding of
internal gettext details from debian/rules, and simplify packaging,
with the cost of a few lines patch. Potentially forcing a version
mismatch via debian/rules seems more error prone, and it also means
going against the wishes of the autotools upstream which added those
version consistency checks for a reason. :)

Of course upstream projects might reject the patch, but then I also
think it's perfectly fine to still use the simpler, more robust and
elegant solution at hand, regardless. And as long Debian considers
best practice to run autoreconf at build time (even if it's currently
imperfect, so that we can regen stuff if we need to modify the
autotooled build system source, or get new autotools changes
percolated into the whole archive with a mass rebuild), maintainers
should feel free to use the best tool at hand to support that.

Thanks,
Guillem