Bug #10496
apt-get scenarios are fragile
100%
Description
These tests could use some retrying with new tor circuits.
[sudo] password for amnesia: W: GPG error: tor+http://ftp.us.debian.org wheezy-backports Release: The following signatures were invalid: BADSIG 8B48AD6246925553 Debian Archive Automatic Signing Key (7.0/wheezy) <ftpmaster@debian.org>
W: Failed to fetch tor+http://ftp.us.debian.org/debian/dists/testing/main/binary-i386/Packages Hash Sum mismatch
W: Failed to fetch tor+http://ftp.us.debian.org/debian/dists/testing/non-free/binary-i386/Packages Hash Sum mismatch
W: Failed to fetch tor+http://ftp.us.debian.org/debian/dists/testing/main/i18n/Translation-en 404 Not Found
W: Failed to fetch tor+http://ftp.us.debian.org/debian/dists/wheezy-backports/contrib/binary-i386/Packages 404 Not Found
E: Some index files failed to download. They have been ignored, or old ones used instead.Of course, retrying doesn’t won’t guarantee that the test can succeed. The forthcoming freezable-apt repo OTOH combined with retrying might.
Subtasks
History
#1 Updated by anonym 2015-11-06 11:51:20
- Assignee set to anonym
#2 Updated by anonym 2015-11-06 12:20:12
- Target version set to 246
#3 Updated by anonym 2015-11-06 12:45:48
- Assignee changed from anonym to kytv
#4 Updated by intrigeri 2015-11-16 04:46:11
> The forthcoming freezable-apt repo OTOH combined with retrying might.
It will fix the root cause of the problem described here.
#5 Updated by sajolida 2015-11-27 04:40:15
- Target version changed from 246 to Tails_2.0
#6 Updated by intrigeri 2015-12-05 13:24:57
- Target version changed from Tails_2.0 to Tails_2.2
(We’re going to mark as fragile all tests that depend on Tor to have bootstrapped for the moment => not so urgent. Waiting for freezable APT repo might make sense too.)
#7 Updated by intrigeri 2015-12-05 13:25:20
- Type of work changed from Test to Code
#8 Updated by bertagaz 2016-03-03 15:48:45
- Assignee changed from kytv to bertagaz
- Target version changed from Tails_2.2 to Tails_2.4
#9 Updated by bertagaz 2016-06-07 12:31:35
- Target version changed from Tails_2.4 to Tails_2.5
#10 Updated by bertagaz 2016-07-02 09:55:31
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 20
- Feature Branch set to test/10496-apt-get-scenarios-are-fragile
Pushed two commit that implements retry_tor in the APT scenario. Let just run it a moment in Jenkins.
#11 Updated by bertagaz 2016-07-07 05:37:40
- Assignee changed from bertagaz to anonym
- % Done changed from 20 to 60
- QA Check set to Ready for QA
Works fine in Jenkins and $HOME. That’s a quite tiny patch, shouldn’t be hard and long to review, and it’s ready for it IMHO.
#12 Updated by bertagaz 2016-07-11 09:33:03
Note that this ticket branch has been merged into bugfix/10494-retry-htpdate-with-more-fragile-tests, so it has also been tested in Jenkins in this other branch.
#13 Updated by intrigeri 2016-07-13 13:38:04
- Assignee changed from anonym to bertagaz
- QA Check changed from Ready for QA to Dev Needed
“Also lower a bit the timeout to 15 minutes” -> and indeed “15 minutes” is clearer than “900”, so please revert to 15*60 in the code :)
Please drop the condition in step 'I kill the process "apt"' if $vm.has_process?("apt"), it’s useless and racy.
In the recovery_proc you can just run commands as root, no need to make things more complicated using sudo here (as opposed to the piece of code that exercises what we expect real users to do).
Maybe the test would be more correct, i.e. closer to the documented retry_tor semantics, if the recovery_proc for apt update deleted the lists that may have been downloaded already?
#14 Updated by bertagaz 2016-07-14 04:54:30
- Assignee changed from bertagaz to intrigeri
- QA Check changed from Dev Needed to Ready for QA
intrigeri wrote:
> “Also lower a bit the timeout to 15 minutes” -> and indeed “15 minutes” is clearer than “900”, so please revert to 15*60 in the code :)
commit:5f2124e
> Please drop the condition in step 'I kill the process "apt"' if $vm.has_process?("apt"), it’s useless and racy.
commit:ec90cfc
> In the recovery_proc you can just run commands as root, no need to make things more complicated using sudo here (as opposed to the piece of code that exercises what we expect real users to do).
commit:cf7be34
> Maybe the test would be more correct, i.e. closer to the documented retry_tor semantics, if the recovery_proc for apt update deleted the lists that may have been downloaded already?
Well, I wondered, but thought it was closer to the user experience if we didn’t delete them. Anyway, that’s commit:9c5122fa, feel free to do whatever you want of it depending on your opinion.
#15 Updated by intrigeri 2016-07-14 17:34:05
- Assignee changed from intrigeri to anonym
>> In the recovery_proc you can just run commands as root, no need to make things more complicated using sudo here (as opposed to the piece of code that exercises what we expect real users to do).
> commit:cf7be34
execute_successfully, maybe? Consider it code-reviewed by me if you want to do that change before anonym’s review.
>> Maybe the test would be more correct, i.e. closer to the documented retry_tor semantics, if the recovery_proc for apt update deleted the lists that may have been downloaded already?
> Well, I wondered, but thought it was closer to the user experience if we didn’t delete them. Anyway, that’s commit:9c5122fa, feel free to do whatever you want of it depending on your opinion.
I’m not 100% sure. I’ll let anonym make the call. If we keep it, we might want execute_successfully here, though.
Other than that, code review passes for me!
#16 Updated by intrigeri 2016-07-21 06:02:17
- Assignee changed from anonym to intrigeri
#17 Updated by intrigeri 2016-07-21 08:49:58
- Status changed from In Progress to Fix committed
- Assignee deleted (
intrigeri) - % Done changed from 60 to 100
- QA Check changed from Ready for QA to Pass
Merged, thanks!
#18 Updated by intrigeri 2016-08-02 09:29:47
- Status changed from Fix committed to Resolved