On Mon, May 29, 2023 at 08:12:54PM +0200, Helmut Grohne wrote:
> Control: clone -1 -2
> Control: retitle -2 debvm's autopkgtests should be marked as flaky
> Control: submitter -2 !
> Control: severity -2 important
>
> Hi Wouter,
>
> On Mon, May 29, 2023 at 02:28:08PM +0200, Wouter Verhelst wrote:
> > I would like to use debvm to run autopkgtests for nbd-client. In order
> > to do that, I would need to run the vm noninteractively, do some in-vm
> > tests, and then shut it down again, with the result of the test
> > affecting the exit state.
>
> Thanks for caring about debvm! Before we delve into your problem, let me
> point out that I had a rather longer talk with Paul Gevers about my
> autopkgtests. In effect, these tests - when executed in testing - still
> test unstable packages. As such, a problem in unstable may make the test
> in stable or testing fail. This is bad. I am at fault here. Please avoid
> repeating my mistake.
I will try :-)
> That being said, would you spend a moment on my autopkgtests anyway? The
> usual interaction happens on stdin/stdout via serial by default, but you
> can also background it and interact with it via ssh, which is what my
> tests do. I think this is the easiest way to script it. Does that suit
> your needs? If not, can you add more detail to how you see this
> happening?
Yeah, that could definitely work. I'll have a look at your autopkgtest
> I also note that autopkgtest has a qemu backend. While this backend is
> not available in the Debian infrastructure, it is being asked for
> repeatedly. Maybe Paul knows more here, but it seems to me that a test
> restriction asking for a VM is more useful for your use case in
> principle.
No, my test needs to communicate with a service outside the VM, so using
the qemu backend for autopkgtest won't help.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
