#983186 autopkgtest: difference between qemu and lxc testbeds

Package:
autopkgtest
Source:
autopkgtest
Submitter:
Ryutaroh Matsumoto
Date:
2025-09-04 18:55:01 UTC
Severity:
important
Tags:
#983186#5
Date:
2021-02-20 19:18:48 UTC
From:
To:
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

#983186#10
Date:
2021-02-22 09:04:39 UTC
From:
To:
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

#983186#25
Date:
2025-09-04 18:52:52 UTC
From:
To:
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