[Pkg-puppet-devel] Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet

Johannes Schauer Marin Rodrigues josch at debian.org
Fri Feb 3 08:44:41 GMT 2023


Hi,

Quoting Vagrant Cascadian (2023-02-03 00:18:58)
> On 2023-02-01, Jérôme Charaoui wrote:
> > I don't know how common that is in build environments, but it's not 
> > something that I have or think I should have in my build (sbuild) or 
> > test (autopkgtest) environments.
> 
> I was able to reproduce the issue with sbuild.
> 
> This appears to be because sbuild copies the host's /etc/passwd and
> /etc/group into the chroot when it builds... and presumably the buildd
> environment does this as well (and all DSA machines have the puppet user
> available?)... and so the puppet user is in fact available in those cases,
> but not others...
> 
> I was able to workaround the issue with:
> 
>   sbuild --chroot-setup-commands='adduser --gecos ,,, --disabled-password puppet' ...
> 
> Is there an option in sbuild to not copy the passwd/group information into
> the chroot? What are the implications of that?

I think we are not so much talking about a limitation of sbuild but about a
limitation of the sbuild schroot backend. When above you say that sbuild copies
/etc/passwd and /etc/group into the chroot, what you probably mean is that
sbuild-createchroot appends the output of `getent passwd sbuild` and `getent
group sbuild` to /etc/passwd and /etc/group, respectively? It would be news to
me if sbuild at any point copies all of /etc/passwd or /etc/group into the
chroot at any point. Do you see this somewhere happening in the code?

Remember that the sbuild-createchroot utility is only really useful if you use
the sbuild schroot backend (which is also the default backend and also the
backend that is used on the buildds). Since you are asking whether passwd/group
information can somehow not be copied into the chroot, you probably are not
interested in a change in the buildd infrastructure but just a local change?

In that case, maybe consider not using the schroot backend but the unshare
backend. The latter has the advantage that you do not need any special setup of
the chroot at all. Any chroot tarball that contains apt can be used by the
unshare backend. Quick introduction (assuming you are on amd64):

$ mkdir -p ~/.cache/sbuild
$ mmdebstrap --variant=buildd unstable ~/.cache/sbuild/unstable-amd64.tar.xz
$ sbuild --chroot-mode=unshare ...

Note that in contrast to the schroot backend, you do not need to become the
superuser at any point.

Thanks!

cheers, josch



More information about the Pkg-puppet-devel mailing list