Martin Pitt

@bobhenz-jabil please ignore the debian-testing failures. It's a meson regression: https://github.com/mesonbuild/meson/issues/13461

At first sight that sounds like issue #115 which was fixed more than two years ago in commit 1b58d24fb78e8297f2b0e96abb99fcbee7f37784. But that was about umockdev-record, and it seems you try this...

The cockpit test failure detected a crun regression in podman-next, see https://github.com/containers/crun/issues/1367 Unrelated to this PR.

Just yesterday I had a similar idea ("use toolbox for my Debian development"), and came up with a [little script](https://piware.de/gitweb/?p=bin.git;a=blob;f=build-sid-toolbox) to set this up. You don't install libnss-myhostname. Without that,...

FTR, I now [improved my script](https://piware.de/gitweb/?p=bin.git;a=blob;f=build-debian-toolbox) to be able to build a debian or ubuntu container for any release from the stock dockerhub images.

@philn: I created a debian testing toolbox successfully just yesterday.. I just tried `build-debian-toolbox bionic ubuntu` and it works (at least it's installing debs now, and I can shell in)....

I'm not a toolbox project maintainer, but honestly this whole "toolbox specific images" approach seems flawed to me. It has not worked very well even for Fedora (e.g. Fedora 34...

@debarshiray ^ Any opinion about the strategic direction here? (See previous comment)

@debarshiray Right, it's a trade-off. But I think the only other reasonable option is to add a bunch of workflows/pipelines that build, validate, and push all supported OS containers *every...

I'm trying to reduce this to a podman command, as I figure that's easier to investigate or possibly reassign to podman. This also does *not* work: ``` podman run -it...