Bug#1072760: Bug#1072643: Bug#1072760: ikiwiki: FTBFS: Parse errors: No plan found in TAP output
Le lundi 10 juin 2024 à 10:21 +0100, Jonathan Dowland a écrit : > On Fri, Jun 07, 2024 at 05:22:32PM +0200, Santiago Vila wrote: > > During a rebuild of all packages in unstable, your package failed to build: > … > > t/po.t (Wstat: 65280 (exited 255) Tests: 38 Failed: > > 0) > > Non-zero exit status: 255 > > Parse errors: No plan found in TAP output > > On the face of it this looks to be a result of po4a changes. I'm not > sure if the root cause is the same as #1072643 yet; further > investigation is required. These two bugs are unrelated. The failure on goobox (#1072643) is linked to the fact that po4a is now much less forgiving about charsets. It now supposes UTF encoding unless specified otherwise. Before, it was relying on the default Perl behavior, which tries to do "the right thing" even if the user does something wrong. This is why previously, the ISO-8859-15 files were accepted without additional configuration while now po4a reports that it's not UTF. Fixing this simply requires to specify the encoding using the -M flag. The question may be about why we changed this. The answer is that the default Perl behavior was not always right leading to messy failures (in particular with gettext which makes things even more complex when msgids contain non-ascii chars), while the new behavior gives us more control. I'll try to improve the error messages to make things more explicit. On its side, the failure on ikiwiki (#1072760) is related to the fact that ikiwiki is using a function that I consider as a private API in po4a and recently changed. The fix is simply to update the the calls of that API in ikiwiki's code, and the update is trivial (simply give the filename twice to use it as refname). Sorry about the inconvenience, but please people, do not CC both bugs as they are unrelated. Sorry again about the inconvenience, Mt signature.asc Description: This is a digitally signed message part
Bug#1072760: Bug#1072643: Bug#1072760: ikiwiki: FTBFS: Parse errors: No plan found in TAP output
Le lundi 10 juin 2024 à 10:21 +0100, Jonathan Dowland a écrit :
> On Fri, Jun 07, 2024 at 05:22:32PM +0200, Santiago Vila wrote:
> > During a rebuild of all packages in unstable, your package failed to build:
> …
> > t/po.t (Wstat: 65280 (exited 255) Tests: 38 Failed:
> > 0)
> > Non-zero exit status: 255
> > Parse errors: No plan found in TAP output
>
> On the face of it this looks to be a result of po4a changes. I'm not
> sure if the root cause is the same as #1072643 yet; further
> investigation is required.
>
I think that the relevant part of the logs is here:
---
Cannot write to a file without refname at
/usr/share/perl5/Locale/Po4a/TransTractor.pm line 444.
Locale::Po4a::TransTractor::read(Locale::Po4a::Text=HASH(0x559ec7d9f248),
"/tmp/ikiwiki-test-po.nKtVlhHS3_/src/index.mdwn") called at /build/ikiwiki-
3.20200202.4/blib/lib/IkiWiki/Plu
gin/po.pm line 907
IkiWiki::Plugin::po::refreshpot("/tmp/ikiwiki-test-
po.nKtVlhHS3_/src/index.mdwn") called at t/po.t line 225
main::refresh_n_scan("index.mdwn", "translatable.mdwn",
"nontranslatable.mdwn") called at t/po.t line 233
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 38.
t/po.t .
-
That's really astonishing for me. I could not imagine that this function is
called by someone else than po4a itself...
This bug is related to https://github.com/mquinson/po4a/issues/504 which
requires a documentation improvement in po4a, but the bug to fix is in ikiwiki.
You should update your calls to this function to follow the prototype
modification. I'm sorry about that, but I fail to see another option.
Sorry for the inconvenience,
Mt
signature.asc
Description: This is a digitally signed message part
Bug#1072760: Bug#1072643: Bug#1072760: ikiwiki: FTBFS: Parse errors: No plan found in TAP output
On Tue Jun 11, 2024 at 11:40 PM BST, Martin Quinson wrote: > That's really astonishing for me. I could not imagine that this function is > called by someone else than po4a itself... > > This bug is related to https://github.com/mquinson/po4a/issues/504 which > requires a documentation improvement in po4a, but the bug to fix is in > ikiwiki. > You should update your calls to this function to follow the prototype > modification. I'm sorry about that, but I fail to see another option. No problem. I'll make that change. Further work will be required, too: we were also calling the methods ->detected_charset and ->set_charset, which have been removed (but we can pass utf-8 as the third argument to read() now); there might be more to do as well. I didn't write this module, so I don't know the reason we're using internal methods and suchlike, or if we could do what we need whilst avoiding that. > Sorry about the inconvenience, but please people, do not CC both bugs > as they are unrelated. Noted. Thank you, -- 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
