Hello, FYI, while watching the autopkgtest BoF at debconf, I discovered vectis by Simon McVittie: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843486
Arguably it covers some common grounds since it does setup sbuild in a VM. Maybe there's room for collaboration here as well? Simon, you might want to review the history of #859867 and share your thoughts about this topic and let us know whether vectis is going to handle all this too. :) Cheers, On Thu, 10 Aug 2017, Raphael Hertzog wrote: > Hello guys, > > On Sat, 05 Aug 2017, Michael Stapelberg wrote: > > Thanks for the thorough review. It took me quite a bit to address all these > > comments :). > > Great to see progress being made here but I have a few ideas that might > impact how you implement all this. > > I really like the idea to make it easier for people to setup everything > they need to be able to do their packaging work. Unfortunately, setting > up the sbuild chroot is only part of the answer. We also need > qemu images for autopkgtest for example. And they also need to be updated > regularly. > > And as you mentionned, it would be nice to be able to support derivatives > easily, not only in place of Debian, but next to the usual Debian support. > > And we want this package to work for packagers on their laptop but it > would be extra cool if it could also be used on build daemons to maintain > the build chroots. > > I envision a system where the "build environments" would be defined > by files in /etc/something/build-environments.d/ and we would provide > the initial file to support sid and we could have additional packages > providing more of them. > > Then we would translate this in appropriate sbuild-createchroot calls > and appropriate commands to create the autopkgtest qemu images, etc. > > Some further comments: > > - since we would also support autopkgtest, it's probably best put in some > separate package, not in sbuild itself > > - we could make it generic enough so that each "package builder" could > hook into our scripts to build/update their build environment (e.g. > chroot tarballs for pbuilder for example). > > - the initial configuration file could be controlled by debconf questions, > either to disable it entirely (e.g. because you rely on configuration > management to provide the descriptions of the build environments) or > to replace the suite name and the mirror to use, it would be low > priority so as to not burden people with those questions. > > Cheers, > > -- > Raphaël Hertzog ◈ Debian Developer > > Support Debian LTS: https://www.freexian.com/services/debian-lts.html > Learn to master Debian: https://debian-handbook.info/get/ > > _______________________________________________ > Buildd-tools-devel mailing list > buildd-tools-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/buildd-tools-devel -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
