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
