On Sat, 27 Jan 2018 22:45:37 +0100 Martin Pitt <[email protected]> wrote:
[...] > Johannes Schauer [2018-01-12 14:27 +0100]: [...] > > When I added the autopkgtest backend to sbuild in addition to schroot, I did > > this with the long term goal in mind that at some point I could also update > > the > > sbuild-update program to support the autopkgtest backend. > > It's not what I would recommend doing actually, as with backends like LXC, > lxd, > or qemu it's actually more reliable and presumably not even slower to just > download a current daily image than upgrading existing ones. With schroots it > makes a lot more sense, but there's already mk-sbuild for that job. Of course > you can work with upgraded testbeds, but by nature they are less reliable. Hello, I am a "passerby" with respect to this bug report, so to speak. I would like to ask a question: Martin, do I understand correctly that you are saying that recreating the QEMU/KVM testbed from scratch (with autopkgtest-build-qemu) is faster than upgrading an existing QEMU/KVM testbed? Despite the debootstrap step, which is notoriously slow?!? Johannes, have you found a solution in the meanwhile? P.S.: please bear with me: I am trying to figure out how to use autopkgtest with QEMU/KVM testbeds and I am probably still a bit too ignorant, but I failed to find some explanations in the documentation... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgptPRLwT5avo.pgp
Description: PGP signature
