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