Re: qemu-sbuild-utils and autopkgtest-build-qemu
On Thu, 05 Nov 2020 at 11:20:52 +0100, Paul Gevers wrote:
> On 05-11-2020 10:51, Christian Kastner wrote:
> > However, autopkgtest-build-qemu is written in shell. I chose Python for
> > qemu-sbuild-create because it makes things like argument parsing, string
> > manipulation, and processing some of the flags so much more simpler.
I personally think we should be using less shell and more Python. Anything
that runs on the host system is fine to be in Python.
For anything that runs on the guest (VM, container, whatever), ideally
we'd only need Essential, so there's an incentive to use shell there;
but autopkgtest-virt-qemu needs at least python3-minimal or python-minimal
in the VM anyway, so maybe that ship has sailed.
I have a half-written branch for an alternative to autopkgtest-virt-qemu
that is an autopkgtest-virt-ssh setup script instead of being a backend
in its own right, so that instead of doing strange tricks with 9pfs,
we can treat the VM as exactly equivalent to a remote or cloud machine.
I'll try to get that to a reviewable status, but my development time is
limited and I have various other priorities, like my day job and GNOME.
Another possible route for autopkgtest-virt-qemu is to abandon the idea
of creating a virtual machine image from scratch, and instead use the
Debian cloud images and cloud-init, the same way Ubuntu uses *their*
official cloud images with autopkgtest-buildvm-ubuntu-cloud. Again,
I have the beginnings of a prototype of this but there are only so many
hours in a day.
> > and also re-working of the vmdb2 YAML generation to accommodate more
> > options (like the recently requested UEFI vs. BIOS)?
Another autopkgtest-build-qemu enhancement that I've considered is to
make it optionally use debos instead of vmdb2, which means we would lose
support for non-amd64 hosts, but gain the ability to run it as an
unprivileged user.
> Although I am one of the maintainers of autopkgtest, I have no clue how
> qemu works (my previous laptop didn't even allow me to run that in a
> sane way) and very little clue of lxc too. Also the docker support
> request is totally hopeless for me.
I use autopkgtest-virt-qemu every time I do an "official" Debian package
build for upload, via <https://salsa.debian.org/smcv/vectis>. Please cc me
on qemu-related merge requests if you want me to take a look.
I too have very little clue about lxc, but I got far enough to
reverse-engineer from debci how we're meant to set it up, and vectis
now knows how to run it.
I also want to get the Docker MR finished and merge it (preferably with
Podman support so that you don't have to be root), but I think this is
going to require some refactoring in setup-testbed so that we can do
some but not all of the setup.
smcv
Reply to: