Samuel Thibault, le ven. 26 août 2022 14:52:19 +0200, a ecrit: > Santiago Vila, le ven. 26 août 2022 14:25:19 +0200, a ecrit: > > > FAIL: msgcat-17 > > > =============== > > > > > > 16,18c16,18 > > > < "Fehler beim Schreiben eines großen Ergebnisses auf eine zu kleine " > > > < "Platte% s% smit der jederzeitigen Möglichkeit eines Fehlers in jedem > > > Moment " > > > < "und an jeder Stelle" > > > --- > > > > "Fehler beim Schreiben eines großen Ergebnisses auf eine zu kleine > > > > Platte% s" > > > > "% smit der jederzeitigen Möglichkeit eines Fehlers in jedem Moment und > > > > an " > > > > "jeder Stelle" > > > > I have the feeling that this may have something to do with terminal width on > > Hurd, but I don't really know. > > I don't pay particular attention to my terminal width when I restart > buildd, but I also had a quick try, and building gettext in various > terminal sizes doesn't change the result (and it should really not, > otherwise it's a gettext test suite bug, I'd say :)
The test actually passes --width=80 > > > < "Fehler beim Schreiben eines großen Ergebnisses auf eine zu kleine " > > > < "Platte% s% smit der jederzeitigen Möglichkeit eines Fehlers in jedem > > > Moment " > > > --- > > > > "Fehler beim Schreiben eines großen Ergebnisses auf eine zu kleine > > > > Platte% s" > > > > "% smit der jederzeitigen Möglichkeit eines Fehlers in jedem Moment und > > > > an " > > In the second line of the reference, there are more characters than in > the first line of the obtained result. So it's probably not a question > of width, but I guess it may rather be related to e.g. word breaking > rules. Investigation would be needed to find out what exactly makes the > break happen at a different position. Apparently on hurd-i386 gettext is not using libunistring, probably because the latest version is not built due to a couple test failures. I have fixed them, the gettext giveback will be waiting ~6h for the resulting binaries to be installed. Samuel
