Hi Christian, [My personal view] On 05-11-2020 10:51, Christian Kastner wrote: > I received feedback from the sbuild maintainers that parts of the newly > packaged qemu-sbuild-utils could have been integrated into sbuild. We've > begun a discussion. > > The same could be said about another part of the utilities, as > qemu-sbuild-create basically just extends autopkgtest-build-qemu. > Technically, all of the features of the former could be integrated into > the latter. > > 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. > > Would you consider a re-write of autopkgtest-build-qemu in Python, and > mid-term integration of the features of qemu-sbuild-create, like > > --install-packages > --extra-deb > > and also re-working of the vmdb2 YAML generation to accommodate more > options (like the recently requested UEFI vs. BIOS)? > > > In any case, the plan for now is to file an RC bug against > qemu-sbuild-utils to prevent a migration to testing until the > integration questions with sbuild and autopkgtest are resolved. To be honest, I think this whole qemu (and other back-ends) handling should actually be extracted from the autopkgtest package and go live on its own. I remember Ian even volunteered for that once long time ago, although I don't even try to find that message. 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 care about the testing part, that's what I'm maintaining. Maybe you can try to find some volunteers to join forces to maintain the autopkgtest backends, as they are not specific for autopkgtest as far as I'm aware, and then you could do all the re-writing you want to do. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature