Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
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) < 0x11' 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
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) < 0x11' failed.
Samuel
Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
On Sun, Dec 27, 2020 at 12:29:01AM +0100, Samuel Thibault wrote:
> Hello gettext maintainers,
>
> Lucas Nussbaum, le sam. 26 déc. 2020 22:52:15 +0100, a ecrit:
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> >
> > > 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) < 0x11' 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.
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.
Thanks.
Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
Hello gettext maintainers,
Lucas Nussbaum, le sam. 26 déc. 2020 22:52:15 +0100, a ecrit:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> > 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) < 0x11' 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?
Samuel
Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
Samuel Thibault, le dim. 27 déc. 2020 00:13:55 +0100, a ecrit:
> FTR, the file that poses problem is Testing/gtest/test/gtest_unittest.cc
> This is not something that contains anything to be translated, we'd need
> some option to just ignore Testing/ entirely.
More precisely, it is line
EXPECT_STREQ("(Invalid Unicode 0xABCDFF)",
WideStringToUtf8(L"\xABCDFF", -1).c_str());
which is *expected* to be an invalid code-point...
Samuel
Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
FTR, the file that poses problem is Testing/gtest/test/gtest_unittest.cc This is not something that contains anything to be translated, we'd need some option to just ignore Testing/ entirely. Samuel
Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
Source: dasher Version: 5.0.0~beta~repack2-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20201226 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[2]: Entering directory '/<>/po' > 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) < 0x11' failed. > ERROR: xgettext failed to generate PO template file. Please consult >error message above if there is any. > make[2]: *** [Makefile:153: dasher.pot] Error 1 > make[2]: Leaving directory '/<>/po' > make[1]: *** [Makefile:535: check-recursive] Error 1 > make[1]: Leaving directory '/<>' > dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2 The full build log is available from: http://qa-logs.debian.net/2020/12/26/dasher_5.0.0~beta~repack2-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with me so that we can identify if something relevant changed in the meantime. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
