Hi all, adding #1033352 as below contains information for that bug, too.
On 2024-02-25 19:50, Johannes Schauer Marin Rodrigues wrote: > in that issue you asked exactly the question I was about to ask you. :) > > Though it seems incus should now be able to deal gracefully with the situation > and there is nothing else that sbuild needs to do to handle this, correct? > > Note, that the autopkgtest/podman backend has a similar issue, see #1033352 > for > details. To fix this, Christian submitted this MR against sbuild: > > https://salsa.debian.org/debian/sbuild/-/merge_requests/55 > > Reading how incus worked around this problem, maybe podman can do the same? I believe there is one difference: unless Im mistaken, incus has a centralized location for containers, whereas podman rootless container images are stored in $HOME. Also, the podman configuration lives $HOME. > On Tue, 23 Jan 2024 14:30:07 +0000 stefa...@debian.org wrote: >> Filed an incus upstream bug about handling this situation more >> gracefully: https://github.com/lxc/incus/issues/422 That issue does mention a practical solution: grabbing $HOME from /etc/passwd. But it mentions that incus only does that when $HOME is not in env, so HOME=/sbuild-nonexistent would impede that. Technically, by providing the right envvars, setting ENVIRONMENT_FILTER, and other tricks, it should be possible to trick sbuild+autopkgtest+podman to ignore $HOME. But unfortunately, podman does not allow this -- similar to the incus issue above. Another trick I thought of was to hack autopkgtest-virt-podman: when run, if HOME=/sbuild-nonexistent, ignore it and use the value /etc/passwd. This might be less invasive than my MR to sbuild. It still has a failure mode (if HOME is deliberately set to something else) but that's a fairly unusual use case. Best, Christian
