On Fri, 11 Aug 2017 at 22:26:20 +0200, Raphael Hertzog wrote: > 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. :)
Part of the purpose of vectis is to set up and run sbuild in an environment closely resembling production Debian buildds, including running sbuild-createchroot, creating the sbuild user with home directory /nonexistent and so on. Until the production buildds were upgraded to stretch, it even used buildd.debian.org's special branch/fork of jessie sbuild (I'm very glad to have been able to get rid of the hacks I used to make that work). Unlike what is proposed on #859867, all the setup done by vectis is inherently disposable. This is a deliberate design choice. The tarball produced by sbuild-createchroot is cached, but can be regenerated any time; the autopkgtest virtual machine image likewise (although you have to be root and use `vectis bootstrap`, vmdebootstrap or some other manually-created VM to recover if you delete all your cached VM images, since the same VM image is used to create new VM images in `vectis new`); and the actual sbuild installation and setup, since it's sufficiently quick, is done for every build and not cached at all. This is not necessarily the sbuild that every Debian maintainer wants: it's somewhat heavyweight (lots of RAM required for virtualization, lots of setup repeated) and I wouldn't want to build libreoffice in it. However, it's what *I* wanted, and I only maintain small to medium-sized packages anyway. vectis is really just automation of things I was doing already, and things that I would/should have done if they weren't so much work to do manually (so part of its role is helping me to live up to the standards the project expects). The README at https://github.com/smcv/vectis has more details on its design decisions. > On Thu, 10 Aug 2017, Raphael Hertzog wrote: > > We also need > > qemu images for autopkgtest for example. And they also need to be updated > > regularly. `vectis new` creates these images. I haven't yet implemented `vectis refresh` (rebuild e.g. (VM, sbuild tarball, minbase tarball) x (sid, buster, stretch, xenial, artful) x (amd64, i386) in a way that could be done weekly from cron) but I hope to do that soon. > > 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. vectis supports Debian and Ubuntu by default, and is reasonably straightforward to configure for other derivatives (in $dayjob I've configured it for SteamOS and the Steam Runtime, and one of my design goals was to make it suitable for other derivatives that Collabora is involved with, like Apertis). On Sun, 20 Aug 2017 at 00:26:26 +0900, Johannes Schauer wrote: > since sbuild already supports autopkgtest as a backend (and thus also > autopkgtest-virt-qemu which vectis seems to be using) I'd be especially > interested in hearing which features are missing from sbuild that prevent > vectis from making use of that functionality. The reason vectis doesn't do this is a design choice, not an omission in sbuild. I have never seriously tried using the autopkgtest backend, because one of vectis' goals is that if it works in vectis, it should work on the production Debian infrastructure. Real Debian buildds use the schroot backend, therefore vectis must use schroot too - because if it didn't, there would be packages that build successfully in vectis but FTBFS on production infrastructure, because a typical autopkgtest environment has fewer strange quirks than a typical sbuild chroot (e.g. the /nonexistent thing, which has bitten me when working on dbus in the past, and an atypically small package set because no init, bootloader or kernel is needed inside a sbuild chroot). The sbuild/schroot invocation is layered inside a VM, because another vectis design goal is that everything that runs package code is inside a VM. Similarly, vectis knows how to run autopkgtest with the qemu backend (directly) and the lxc and schroot backends (inside a VM), because ci.debian.net currently uses lxc, so vectis should be able to replicate that: it matters for packages like flatpak, bubblewrap and debootstrap, where some tests don't work as desired under lxc and must be skipped or treated as expected failures. I will admit that I don't usually run tests under all three backends before upload - if I was a perfect maintainer, then I would, but it's very slow to run the tests for something like dbus 8 times (build-time, schroot, lxc, qemu, then the same again for i386 because I can't upgrade src:dbus on my amd64 host system until I've also built libdbus-1-3:i386). If the real, production Debian infrastructure ever switches to the autopkgtest backend, so will vectis. I would be happy to add *non-default* modes to vectis where it does things that do not mirror the production infrastructure (for instance mirroring future plans for production infrastructure, or taking shortcuts for faster test-builds), but they should not be the default, and it has not been my top priority. At the moment vectis is very much a spare-time project to automate what I would have been doing already, and what I should have been doing if I was a more exemplary maintainer (because automation makes it a lot easier to live up to Debian's ideal level of pedantry). S
