Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Samuel Thibault]

Santiago Vila, le dim. 27 déc. 2020 00:59:23 +0100, a ecrit:
> On Sun, Dec 27, 2020 at 12:29:01AM +0100, Samuel Thibault wrote:
> > Lucas Nussbaum, le sam. 26 déc. 2020 22:52:15 +0100, a ecrit:
> > > > INTLTOOL_EXTRACT="/usr/bin/intltool-extract" XGETTEXT="/usr/bin/xgettext" srcdir=. /usr/bin/intltool-update --gettext-package dasher --pot
> > > > xgettext: x-c.c:1666: phase5_get: Assertion `UNICODE_VALUE (c) >= 0 && UNICODE_VALUE (c) < 0x110000' failed.
> > > > ERROR: xgettext failed to generate PO template file. Please consult
> > > >        error message above if there is any.
> > 
> > And this is due to this part of dasher:
> > 
> >   EXPECT_STREQ("(Invalid Unicode 0xABCDFF)",
> >    WideStringToUtf8(L"\xABCDFF", -1).c_str());
> > 
> > which is precisely *expected* to be an invalid code-point... Since this
> > string is not marked as to be translated, xgettext shouldn't error out
> > about it?
> 
> I don't know.
> 
> It must be noted that I uploaded gettext 0.21 for unstable recently
> and it propagated to testing today. Apparently the new gettext is more
> nitpicky than the old one.
> 
> My feeling is that somehow you are calling xgettext "implicitly", i.e.
> without being really aware that you are in fact calling xgettext.

Well, it does seem that upstream's intent really is to call xgettext
over the source code, to extract translatable strings.

> If required I can ask gettext upstream about this, but we would need a
> minimal test case and a little bit more of investigation on our side.

€ cat test.c

#include <wchar.h>

void f(const wchar_t *str) { }

void g(void) {
	f(L"\xABCDFF");
}


€ xgettext test.c
xgettext: x-c.c:1666: phase5_get: Assertion `UNICODE_VALUE (c) >= 0 && UNICODE_VALUE (c) < 0x110000' failed.

Samuel