Project

General

Profile

Bug #17457

Add Buster support to the automated test suite

Added by anonym about 2 months ago. Updated 10 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
-
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

I've already done some work on this on the test/15460-replace-sikuli branch, so I mostly want to create this ticket before any one else does and starts working on it.

I'll use this ticket to list other issues I've noticed, but not solved yet.

  • QEMU 4.2 backport for Buster (needed to support saving snapshots in a nested setup)
  • Ability to run the test suite with --view from a Wayland desktop (#15460#note-103)

And in passing, for Bullseye support, see #17031.


Related issues

Related to Tails - Bug #15953: Make our test suite survive changes in the surrounding environment Confirmed 09/14/2018
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed
Blocked by Tails - Bug #15460: Test suite broken with Java 9+ so we need to replace Sikuli In Progress
Blocks Tails - Bug #15831: Use qemu-xhci for TailsToaster Confirmed 08/22/2018
Blocks Tails - Feature #15450: Create LUKS2 persistent volumes by default In Progress 03/23/2018

History

#1 Updated by anonym about 2 months ago

In Debian Buster we'll have qemu 3.1, but it lacks support to save snapshots in a nested setup, which is bad news for our Jenkins setup (and everyone using nested setups). From the qemu 3.1 changelog: "x86 machines cannot be live-migrated if nested Intel virtualization is enabled. The next version of QEMU will be able to do live migration when nested virtualization is enabled, if supported by the kernel."

It is fixed in qemu 4.2, which is in Debian Bullseye, so if it gets backported we could use that. Otherwise we can downgrade to Debian Stretch's qemu 2.8, which also works. I have verified that both of these options work.

#2 Updated by anonym about 2 months ago

  • Related to Bug #17429: Stretch and Buster VMs running on a sid host can't run our test suite added

#3 Updated by anonym about 2 months ago

#4 Updated by anonym about 2 months ago

  • Related to deleted (Bug #17429: Stretch and Buster VMs running on a sid host can't run our test suite)

#5 Updated by intrigeri about 2 months ago

It is fixed in qemu 4.2, which is in Debian Bullseye, so if it gets backported we could use that. Otherwise we can downgrade to Debian Stretch's qemu 2.8, which also works. I have verified that both of these options work.

Just to be clear: you've locally backported 4.2 for Buster and it solves this problem, right?

I don't expect there will be official backports for Buster and I don't think maintaining them ourselves would be a good use of our resources.

Note that we've been requiring a custom QEMU package (in our isotester-stretch repo) for a while in order to run our test suite. I think it went mostly fine for developers. So we could do this:

  • Bullseye and newer (developers): use QEMU from Debian
  • Buster (developers, future CI): use custom backport uploaded to our isotester-stretch repo
  • Stretch (developers, current CI): drop support once Stretch is EOL in a few months, so we can stop maintaining our Stretch QEMU; to make this work, notify sysadmins and developers a while before, so they have time to upgrade stuff to Buster

How does this sound?

#6 Updated by anonym about 2 months ago

intrigeri wrote:

It is fixed in qemu 4.2, which is in Debian Bullseye, so if it gets backported we could use that. Otherwise we can downgrade to Debian Stretch's qemu 2.8, which also works. I have verified that both of these options work.

Just to be clear: you've locally backported 4.2 for Buster and it solves this problem, right?

Ah, no, and I see how what I wrote was unclear, sorry! I meant that I have successfully run the test suite on:

  • Debian Buster with qemu from stretch
  • Debian Bullseye with its qemu

So I haven't done any backport. I just now tried to see if a trivial rebuild would work, but it failed due to a new dependency missing in Buster, libslirp-dev. But that's just a single dep, and backporting it as well looks easy (no additional deps). Of course, this might get harder as the Buster vs Bullseye delta grows.

I don't expect there will be official backports for Buster and I don't think maintaining them ourselves would be a good use of our resources.

Are you saying that the plan you outline below is not a good use of our resources? Please clarify!

Note that we've been requiring a custom QEMU package (in our isotester-stretch repo) for a while in order to run our test suite. I think it went mostly fine for developers. So we could do this:

  • Bullseye and newer (developers): use QEMU from Debian
  • Buster (developers, future CI): use custom backport uploaded to our isotester-stretch repo
  • Stretch (developers, current CI): drop support once Stretch is EOL in a few months, so we can stop maintaining our Stretch QEMU; to make this work, notify sysadmins and developers a while before, so they have time to upgrade stuff to Buster

How does this sound?

Sounds good to me. Is there even any alternative? If Stretch is EOL soon, I guess it won't receive security fixes so staying on Stretch's version won't work for long.

#7 Updated by intrigeri about 2 months ago

Hi!

anonym wrote:

I just now tried to see if a trivial rebuild would work, but it failed due to a new dependency missing in Buster, libslirp-dev. But that's just a single dep, and backporting it as well looks easy (no additional deps). Of course, this might get harder as the Buster vs Bullseye delta grows.

I suspect that in the context of a private, Tails-only backport, we could simply drop this build-dep and disable the corresponding feature when calling ./configure (I doubt we use this functionality anywhere). But indeed, this might not be the case for future new {build,runtime} deps.

intrigeri wrote:

I don't expect there will be official backports for Buster and I don't think maintaining them ourselves would be a good use of our resources.

Are you saying that the plan you outline below is not a good use of our resources? Please clarify!

What I wrote above applies only to an official backport, as in "uploaded to Debian and maintained — until Buster in EOL — under Debian rules". I don't think maintaining such a backport would be a good use of our resources.

While what I proposed below instead applies to a custom backport, i.e. uploaded to our custom APT repository.

Clearer?

How does this sound?

Sounds good to me.

:)

Is there even any alternative? If Stretch is EOL soon, I guess it won't receive security fixes so staying on Stretch's version won't work for long.

I expect QEMU will be in the scope of Stretch LTS (and hopefully so because we have no plan to upgrade to Buster our main virtualization server), so yes, in theory we could keep maintaining support for running the test suite on Stretch. But I'd rather not have to maintain 2 custom QEMU packages for too long. A 6 months transition period would be OK, I guess, but longer than that, please, no ⇒ the earlier the clock countdown starts, the better, IMO :)

#8 Updated by anonym about 2 months ago

intrigeri wrote:

anonym wrote:

I just now tried to see if a trivial rebuild would work, but it failed due to a new dependency missing in Buster, libslirp-dev. But that's just a single dep, and backporting it as well looks easy (no additional deps). Of course, this might get harder as the Buster vs Bullseye delta grows.

I suspect that in the context of a private, Tails-only backport, we could simply drop this build-dep and disable the corresponding feature when calling ./configure (I doubt we use this functionality anywhere).

Cool, I was unsure what it was used for.

But indeed, this might not be the case for future new {build,runtime} deps.

intrigeri wrote:

I don't expect there will be official backports for Buster and I don't think maintaining them ourselves would be a good use of our resources.

Are you saying that the plan you outline below is not a good use of our resources? Please clarify!

What I wrote above applies only to an official backport, as in "uploaded to Debian and maintained — until Buster in EOL — under Debian rules". I don't think maintaining such a backport would be a good use of our resources.

While what I proposed below instead applies to a custom backport, i.e. uploaded to our custom APT repository.

Clearer?

Yes, now I get it!

How does this sound?

Sounds good to me.

:)

Let's settle on this plan, then!

Is there even any alternative? If Stretch is EOL soon, I guess it won't receive security fixes so staying on Stretch's version won't work for long.

I expect QEMU will be in the scope of Stretch LTS (and hopefully so because we have no plan to upgrade to Buster our main virtualization server), so yes, in theory we could keep maintaining support for running the test suite on Stretch. But I'd rather not have to maintain 2 custom QEMU packages for too long. A 6 months transition period would be OK, I guess, but longer than that, please, no ⇒ the earlier the clock countdown starts, the better, IMO :)

Agreed.

#9 Updated by intrigeri about 2 months ago

I suspect that in the context of a private, Tails-only backport, we could simply drop this build-dep and disable the corresponding feature when calling ./configure (I doubt we use this functionality anywhere).

Cool, I was unsure what it was used for.

IIRC slirp is some kind of userspace networking mode which is mostly useful when running QEMU without root, or to hook all kinds of interesting userspace network mangling in the loop (this sort of things could be useful some day for post-Wayland Unsafe Browser confinement or similar, for example). AFAICT we don't use this anywhere with QEMU in Tails-land :)

#10 Updated by anonym about 2 months ago

intrigeri wrote:

I suspect that in the context of a private, Tails-only backport, we could simply drop this build-dep and disable the corresponding feature when calling ./configure (I doubt we use this functionality anywhere).

I dropped --enable-slirp=system and the corresponding libslirp-dev and built a backported qemu 4.2, and I see no more snapshot problems under Buster. Yay!

Cool, I was unsure what it was used for.

IIRC slirp is some kind of userspace networking mode which is mostly useful when running QEMU without root, or to hook all kinds of interesting userspace network mangling in the loop (this sort of things could be useful some day for post-Wayland Unsafe Browser confinement or similar, for example). AFAICT we don't use this anywhere with QEMU in Tails-land :)

Thanks for the explanation!

#11 Updated by intrigeri about 2 months ago

I dropped --enable-slirp=system and the corresponding libslirp-dev and built a backported qemu 4.2, and I see no more snapshot problems under Buster. Yay!

Oooooh yeah!

#12 Updated by intrigeri 24 days ago

  • Blocked by Bug #15460: Test suite broken with Java 9+ so we need to replace Sikuli added

#13 Updated by intrigeri 16 days ago

  • Subject changed from Add buster support to the automated test suite to Add Buster support to the automated test suite
  • Description updated (diff)

#14 Updated by intrigeri 16 days ago

  • Blocks Bug #15831: Use qemu-xhci for TailsToaster added

#15 Updated by intrigeri 16 days ago

  • Blocks Feature #15450: Create LUKS2 persistent volumes by default added

#16 Updated by intrigeri 16 days ago

  • Related to Bug #15953: Make our test suite survive changes in the surrounding environment added

#17 Updated by intrigeri 10 days ago

  • Description updated (diff)

#18 Updated by intrigeri 10 days ago

  • Description updated (diff)

Also available in: Atom PDF