Dear gettext maintainers: I applied commit d13f165b8370 to the Debian gettext package, as suggested by Bruno Haible, and several things happened.
One of them is that now glibc does not build because the gettext tests still expect the POT-Creation-Date header to be there. This has been reported here: https://sourceware.org/bugzilla/show_bug.cgi?id=21508 but this is of course not your fault. The other interesting thing which happened is explained in the report below which I have just received. Apparently the .mo files created now are not very orthodox. [ Please keep the Cc: lines if you can. Thanks ]. ----- Forwarded message from Jakub Wilk <jw...@jwilk.net> ----- Date: Mon, 21 Aug 2017 22:44:19 +0200 From: Jakub Wilk <jw...@jwilk.net> To: sub...@bugs.debian.org Subject: Bug#872869: msgfmt: trailing null bytes in header's msgstr User-Agent: NeoMutt/20170609 (1.8.3) Package: gettext Version: 0.19.8.1-3 Control: affects -1 + i18nspector The upstream commmit d13f165b8370 updates the header message msgstr, but it keeps the original msgstr_len ("the number of bytes in msgstr, including the terminating NUL"). As consequence, in the generated MO file there's a bunch of null bytes at the end of the msgstr. I guess this does not matter for gettext-runtime, but it makes i18nspector (and maybe other strict MO parsers) upset: $ msgunfmt /usr/share/locale/pl/LC_MESSAGES/gettext-runtime.mo | msgfmt - $ i18nspector messages.mo E: messages.mo: invalid-mo-file unexpected null byte in msgstr [...]
