- Package:
- autopkgtest
- Source:
- autopkgtest
- Submitter:
- Ryutaroh Matsumoto
- Date:
- 2025-09-04 18:55:01 UTC
- Severity:
- important
- Tags:
Dear Maintainer, 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 On the other hand, all tests pass on LXC testbed, as seen on ci.debian.net. I have not understood how this difference appear... Log of autopkgtest is attached. Any difference betwen LXC and QEMU testbeds seems important, so I chose "important" severity. Best regards, Ryutaroh Matsumoto
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 /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
Hi, We're recently having more of these discussions. E.g. in https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/586, https://lists.debian.org/debian-ci/2025/06/msg00009.html and bug 1098646. While there will always be differences between the testbeds (as they do thing differently) we should get better at documenting what testbeds should provide and we're getting better at ensuring that the shipped tools don't do more than that. We're not there yet. Paul