Fam Zheng <f...@redhat.com> writes: > Alex, > > This is the result of my fiddling around docker + qemu-user in the weekend. It > can do most of the work except the injection of qemu-user binary from host > build. We can try to integrate your "docker.py update" into Makefile to do > that, but an open question is how to handle the dependency cleanly: we > intentionally allow "make docker-foo" w/o configure or build, but the > qemu-user > case is very different.
I think it is certainly worth keeping the ability to inject qemu into the docker container. While for a random build-on-other-arch type setup we can rely on the docker distro's implementation for builds the other use case is testing the current qemu still works for a linux-user type setup. > The major change is using "FROM debian" and build thing in the container so > that qemu-arm, fakeroot and debootstrap are not required on the system (the > docker file installs qemu-user-static). This way the pre script is not needed. > > The upside is debootstrap can make use of docker cache, so updating is easy, > but we have to handle chroot in run script, before running the test > command. But really the native Debian host doesn't take the time to setup, it is the debootstrap that chugs along. Until docker hub starts supporting multiple architecture docker images (which I believe is coming) it doesn't make much difference to the image build time. > This seems cleaner in host side dependencies to me, what do you think? I think we should support both. Keeping all the dependencies inside the docker environment works really well for keeping everything host distribution agnostic and is probably the way forward to support "cross" build setups from the Makefiles. One advantage of the pre script approach is we can have a generic recipe for Debian which allows the user to spin up various architectures just by tweaking the environment variables. And from my point of view one of the drivers for my patches was being able to setup rootfs without complicated bind mounts and chroots so I do like "docker run" dropping directly into a translated shell. Is there a similar boot strap we can use to setup cross fedora images? Maybe we should merge the .py changes and your dockerfiles in test/docker/dockerfiles and my general purpose (but requiring host requirements) into contrib/docker? > > Fam > > Fam Zheng (4): > docker: More sensible run script > docker: Fix exit code if $CMD failed > docker: Support "QEMU_CHROOT" in dockerfiles > docker: Add debootstrap-arm image > > tests/docker/Makefile.include | 5 ++-- > tests/docker/dockerfiles/debootstrap-arm.docker | 35 > +++++++++++++++++++++++++ > tests/docker/run | 28 +++++++++++++++++--- > 3 files changed, 62 insertions(+), 6 deletions(-) > create mode 100644 tests/docker/dockerfiles/debootstrap-arm.docker -- Alex Bennée
