Hi,

arch-test currently respects the $CHROOT environment variable. If the
user has it set, then it will be as if --chroot was passed to arch-test.
Maybe this is intentional so that arch-test can be called with a chroot
even in situations where one does not have direct control over the
arch-test call?

Michael Tokarev (CC) found this bug when running mmdebstrap with
CHROOT=unstable-amd64 set which is done by the rust development tools.
This will make arch-test and thus mmdebstrap fail if unstable-amd64 does
not contain the expected contents. The CHROOT variable is not set up for
the use of arch-test so mmdebstrap will fail in this case.

I could remove the CHROOT variable from the environment before calling
arch-test from mmdebstrap but before doing that I wanted to give you a
heads-up about this behaviour and allow you to either:

 * confirm that this is intentional (and then maybe mention this in
   the man page of arch-test) or
 * add a CHROOT= in front of the option parsing loop so that whatever
   the environment contains is ignored

Thanks!

cheers, josch

Control: fixed-upstream

If I recall correctly, it's unintentional -- shell merely inherits variables
from the environment.  And it's unlikely that anyone relies on the variable
rather than -c.  Heck, the very -c option is obsolete now, it made sense
when qemu-user had to live inside the chroot.

Done, in git.


Meow!