On 2020-12-04 21:54, Aurelien Jarno wrote: > On 2020-12-04 21:38, Xavier wrote: > > Control: tags -1 + ftbfs > > > > Le 04/12/2020 à 20:46, Paul Gevers a écrit : > > > Source: glibc, node-iconv > > > Control: found -1 glibc/2.31-5 > > > Control: found -1 node-iconv/2.3.5-4 > > > Severity: serious > > > Tags: sid bullseye > > > X-Debbugs-CC: debian...@lists.debian.org > > > User: debian...@lists.debian.org > > > Usertags: breaks needs-update > > > > > > Dear maintainer(s), > > > > > > With a recent upload of glibc the autopkgtest of node-iconv fails in > > > testing on all architectures when that autopkgtest is run with the > > > binary packages of glibc from unstable. It passes when run with only > > > packages from testing. In tabular form: > > > > > > pass fail > > > glibc from testing 2.31-5 > > > node-iconv from testing 2.3.5-4 > > > all others from testing from testing > > > > > > I copied some of the output at the bottom of this report. > > > > > > Currently this regression is blocking the migration of glibc to testing > > > [1]. Due to the nature of this issue, I filed this bug report against > > > both packages. Can you please investigate the situation and reassign the > > > bug to the right package? > > > > > > More information about this bug and the reason for filing it can be found > > > on > > > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > > > > > Paul > > Hi, > > > > I rebuild node-iconv (nocheck) and rebuild/autopkgtest reverse > > dependencies of node-iconv, all passed: > > * rebuild: node-body-parser, node-encoding, node-expat, > > node-iconv-lite, node-raw-body > > * autopkgtest: node-body-parser, node-d3-dsv, node-raw-body > > > > So maybe we can just ignore 2 failing tests for now (a "should throw" > > which doesn't throw). > > > > I gave a quick look at the node-iconv code, and looking at > debian/patches/use-glibc-iconv.patch the issue might be related to the > changes in the C.UTF-8 locale that does a bit more transliteration than > before.
The problem is that the 'が' wasn't considered as valid UTF-8 in glibc 2.31-4: | $ echo 'ça va が' | LC_ALL=C.UTF-8 iconv -f utf-8 -t ascii//translit | ca va iconv: illegal input sequence at position 7 With glibc 2.31-5 it is considered as valid, although not transliterable: | $ echo 'ça va が' | LC_ALL=C.UTF-8 iconv -f utf-8 -t ascii//translit | ca va ? Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
