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/
