Control: retitle -1 autopkgtest-virt-podman stacktraces on image not generated 
with autopkgtest-build-podman
Control: severity -1 important

On Sun, 19 Jan 2025 at 21:15:30 +0100, Paul Gevers wrote:
> I'm trying to add podman support to debci and in the process I had
> autopkgtest fail to run with an image created with autopkgtest-build-podman

That's not my reading of your log. Instead, it's failing to run with an
image *not* created with autopkgtest-build-podman:

> root@host:/tmp/autopkgtest.K9hkde/build.MFf/real-tree# autopkgtest
> debian/tests/testpkg/ -- podman debian:unstable
...
> If I then run $(podman image inspect debian:unstable) I get:
> # podman image inspect debian:unstable
...
>           "RepoTags": [
>                "docker.io/library/debian:unstable"
>           ],
>           "RepoDigests": [
> "docker.io/library/debian@sha256:223ab26e710a24a3033518f2c2f1fb22e4aa5ba5626ce00eea01e19ef3b58a18",
> "docker.io/library/debian@sha256:7a1bf1b8fa1b22173fe5cf9c0d8747e935ac710363760179b1502e3354a47ee0"
>           ],
...
>           "Comment": "debuerreotype 0.15",

That's debian:unstable from Dockerhub, not autopkgtest/debian:unstable
from your local run of a-b-podman.

> My current implementation generates an image logged like so:
> + debci setup --backend podman
> I: testbed setup [unstable/amd64/podman]: starting at Sun Jan 19 20:41:08
> CET 2025
> debian-distro-info: unknown distribution series `unstable'
> WARNING: podman requires either passt or slirp4netns, depending on version
> INFO:autopkgtest-build-docker:['podman', 'build', '--tag',
> 'autopkgtest/debian:unstable', '--tag', 'autopkgtest/amd64/debian:unstable',
> '--build-arg=IMAGE=debian:unstable', '--build-arg=AUTOPKGTEST_APT_PROXY=',
> '--build-arg=AUTOPKGTEST_APT_SOURCES=...

This is taking debian:unstable (which expands to
docker.io/library/debian:unstable as per
/etc/containers/registries.conf.d/shortnames.conf) as input, and generating
an image as output that has two names,
autopkgtest/debian:unstable and autopkgtest/amd64/debian:unstable
(which implicitly expand to localhost/autopkgtest/debian:unstable and
localhost/autopkgtest/amd64/debian:unstable, indicating that they are
images that exist in podman's local storage).

If you `podman image inspect autopkgtest/amd64/debian:unstable` you should
see that it has a non-empty set of labels:

               "Labels": {
                    "io.buildah.version": "1.38.0",
                    "org.debian.autopkgtest.dpkg_architecture": "amd64",
                    "org.debian.autopkgtest.init": "none",
                    "org.debian.autopkgtest.release": "sid",
                    "org.debian.autopkgtest.vendor": "debian"
               }

(I normalized the release name to sid rather than unstable for this
particular image, with your commands you'd get unstable rather than sid
I think)

You'll also see that it has a bunch of layers that refer to the
setup-testbed script, which debian:unstable doesn't.

> That doesn't have a Config.Labels field, so $(podman image inspect
> --format='{{json .Config.Labels}}' debian:unstable) returns "null" which by
> json.loads() is converted to None.
> 
> Should autopkgtest-virt-podman on line 197 test for "labels is not None"
> first, or is this maybe a bug in autopkgtest-build-podman?

There is a genuine bug here, which is that a-v-podman doesn't currently
accept third-party images with no labels, and it should. But it seems like
your invocation of a-v-qemu is both working as designed, and not doing what
you thought it was designed to do :-)

autopkgtest-virt-podman(1) has examples for both modes, and both are meant
to be possible.

    smcv

Reply via email to