Bug #16355
Test suite: please detect and warn about “Known issues”…
0%
Description
So I’ve discovered the fun related to Bug #12142 (i.e. https://bugs.debian.org/851694), after having wasted quite some time on the USB test suite development (Bug #16004).
It has been freshly documented in master (commit:7a6bddabe047a8ba9fb554fc3442d4fa1260e8e1 — by the way, why not mention the binaries available in the same suite, instead of suggesting a local rebuild?), but I’d hate it to see others (maybe future me with a different setup) lose time over this again.
I’m therefore proposing an extra check, ensuring we have the known good qemu version when running on Debian stretch. This should be a no-op on the isotesters, which have this version installed already.
FWIW, this might also be the reason why I’ve had so many issues with snapshots while working on the test suite updates for feature/buster (Bug #16314)… I’m currently checking this hypothesis, and will update Bug #16314 accordingly.
Target branches: devel and feature/buster.
Files
Subtasks
Related issues
| Related to Tails - Feature #15864: Make onboarding of new developers easier | In Progress | 2018-08-30 |
History
#1 Updated by CyrilBrulebois 2019-01-14 03:09:00
- Description updated
#2 Updated by intrigeri 2019-01-14 07:57:20
- Status changed from New to In Progress
- Assignee changed from intrigeri to CyrilBrulebois
> by the way, why not mention the binaries available in the same suite, instead of suggesting a local rebuild?),
I was assuming that at least some developers would be reluctant to add third-party binary APT sources, i.e. to trust our infra to be root on their system. Perhaps I was overly cautious? I’m fine adding the binary APT source if you want.
> but I’d hate it to see others (maybe future me with a different setup) lose time over this again.
OK!
> I’m therefore proposing an extra check, ensuring we have the known good qemu version when running on Debian stretch. This should be a no-op on the isotesters, which have this version installed already.
Code looks good to me. Please push this to a branch so we confirm it’s a no-op on Jenkins before we deploy it :)
#3 Updated by intrigeri 2019-06-02 14:42:58
- Status changed from In Progress to Needs Validation
#4 Updated by intrigeri 2019-08-30 20:48:19
- Status changed from Needs Validation to Confirmed
Since then, we’ve updated QEMU a few times, so I’m wondering if the benefits of hard-coding the exact desired version is worth its maintenance cost. After thinking about it again, I’m also not enthusiastic at the idea of having to coordinate upgrading our QEMU package on all Jenkins workers, with having the corresponding version number updated in all relevant branches in tails.git: the coupling is a bit too tight for it to be practical.
Another option, that has none of these drawbacks, would be to check that we’ve got a Tails QEMU custom package, i.e. version ends with .0tailsN, installed. It’s of course less powerful (although we’ve not needed the extra power so far), but it would be sufficient to catch the typical problem experienced by folks who run the test suite for the first time on a given system, that is running QEMU from Debian.
If we agree on something here that does not require substantially more work than what you did already, I could try to submit a branch so that future contributors benefit from your feedback, that triggered this ticket+patch :)
#5 Updated by intrigeri 2019-08-31 13:54:19
- related to Feature #15864: Make onboarding of new developers easier added
#6 Updated by intrigeri 2019-09-07 07:00:43
- Status changed from Confirmed to In Progress
Applied in changeset commit:tails|f787d13c8aefae7dd6e471ac19250802e3c600db.