Control: clone -1 -2 Control: reassign -2 src:python3.9 3.9.1-4 Control: retitle -2 python3.9: autopkgtest fails when run under qemu: cannot read character map directory `/usr/share/i18n/charmaps': No such file or directory
On Sun, 21 Feb 2021 at 04:18:48 +0900, Ryutaroh Matsumoto wrote: > I set up testbeds by > debci setup -f -a amd64 -s sid -b qemu > debci setup -f -a amd64 -s sid -b lxc > > "autopkgtest -u debci -B -U python3.9" behaves differently on QEMU and LXC > testbeds. > > On QEMU testbed, it fails with > > [error] character map file `ISO-8859-1' not found: No such file or directory > [error] cannot read character map directory `/usr/share/i18n/charmaps': No > such file or directory > [error] character map file `UTF-8' not found: No such file or directory > [error] cannot read character map directory `/usr/share/i18n/charmaps': No > such file or directory This looks like it might indicate a bug in the autopkgtests of python3.9. /usr/share/i18n/charmaps is in the locales package, which the 'testsuite' autopkgtest does not explicitly depend on. However, I'm not sure why this did not fail under lxc: according to testsuite-packages, locales was not installed for the run in lxc either, so I would expect both backends to succeed or fail the same way. Perhaps debian/locale-gen should do nothing and exit successfully if both the desired locales are already available? This script appears to be similar in concept to https://sources.debian.org/src/glib2.0/2.67.4-1/debian/tests/run-with-locales/ which does know how to skip generation of locales that already exist. It looks as though the actual *tests* all pass, but by default, autopkgtest interprets anything printed on stderr as being a failure. With hindsight, that might not be the best default, but it's part of the "API" so it's too late to change it now. If this behaviour is not desired for python3.9, please add Restrictions: allow-stderr to the affected test(s). smcv
