I tried building and testing autopkgtest using my
autopkgtest-build-lxc created testing chroot, but the "autopkgtest"
autopkgtest failed.  The errors were all of the form:

subprocess.CalledProcessError: Command '['cp', '-a', '/usr/lib/locale/C.UTF-8', '/tmp/autopkgtest.test.8uy3vwdb/chroot//usr/lib/locale']' returned non-zero exit status 1.

and the stderr shows the reason:

cp: cannot stat '/usr/lib/locale/C.UTF-8': No such file or directory

One possible cause is that my system has /etc/locale.conf specifying
LANG=en_GB.UTF-8 and LC_* likewise; locale (as root) reports:

LANG=en_GB.UTF-8
LANGUAGE=
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC=en_GB.UTF-8
LC_TIME=en_GB.UTF-8
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
LC_ADDRESS=en_GB.UTF-8
LC_TELEPHONE=en_GB.UTF-8
LC_MEASUREMENT=en_GB.UTF-8
LC_IDENTIFICATION=en_GB.UTF-8
LC_ALL=

So when I run "autopkgtest-build-lxc debian testing", it creates a
container with the default locale being en_GB.UTF-8 - indeed, in that
container, locale gives the same output.

If the container were created with the locale being C.UTF-8, then it
might fare a little better, although a quick attempt to do this still
seemed to end up with the default locale being en_GB.UTF-8.

It is entirely possible that there is a different cause, though.
Inside the container, I have:

root@autopkgtest-testing:~# ls /usr/lib/locale/
C.utf8	locale-archive

So maybe there is a filename issue here instead?

Best wishes,

   Julian

Hi Julian,

Sorry for taking so long to get back to this issue.

In version 5.30 Simon rewrote the logic that (among others) handled the
locale in the testbed. $(man autopkgtest) mentions that the default LANG
is C.UTF-8 and that you can set it on the command line with --set-lang.
All other LC_ variables are unset (in lib/in-testbed/wrapper.sh). I just
tried (with a d/t/control that has Test-Command: env) and see that LANG
is indeed set to C.UTF-8 when I don't use `--set-lang `and is set to
en_US.UTF-8 when I specify that with `--set-lang`. (On my host system,
LANG=en_US.UTF-8) Can you still reproduce the issue you reported?

Paul