Hi Antonio,

2018-05-11 19:45 GMT+02:00 Antonio Terceiro <terce...@debian.org>:
> On Fri, May 11, 2018 at 04:41:11PM +0200, Bálint Réczey wrote:
>> Control: tags -1 wontfix
>>
>> Hi Paul,
>>
>> 2018-05-08 21:48 GMT+02:00 Paul Gevers <elb...@debian.org>:
>> > Source: unattended-upgrades
>> > Version: 1.0
>> > Severity: important
>> > User: debian...@lists.debian.org
>> > Usertags: flaky
>> >
>> > While inspecting regressions in autopkgtest results¹, I noticed that
>> > your package unattended-upgrades fails regularly, without obvious
>> > changes. There are multiple failure modes (some copied below).
>>
>> Thank you for working on autopkgtest gating migration!
>>
>> > Could you please investigate and make your autopkgtest more robust?
>> > Please contact me if you need help and you think I can provide that (I
>> > am not subscribed to this bug).
>>
>> Checking the logs the failures seem to be infrastructure issues, most
>> often temporary problems with downloading files from
>> snapshot.debian.org (via local proxy when it is present). IMO those
>> should be fixed by monitoring the logs and retrying the test
>> automatically rather than working around the issues in u-u/test
>> itself.  An even better fix would be fixing the proxy/snapshot.d.o,
>> but this may be out of scope for the autopkgtest infrastructure.
>
> autopkgtest will retry on failures when it is accessing the network
> (such as installing test dependencies), but when your test script hits
> the network (in this case by calling deboootstrap), you must make sure
> it can survive temporary network access problems. This type of failure
> will happen occasionaly on ci.debian.net, but also on developers
> machines, build daemons, etc, so it's not realistic to expect each of
> those to monitor logs and retry arbitrary/random network access
> failures.
>
> Also, it would not be feasible for autopkgtest or debci to automatically
> detect arbitrary network failures in 10k+ source packages.
>
> Please reconsider, and make the tests robust against networking issues.

I monitored the runs for some time and the test does not seem to be
flaky in unstable. Since I added a new test with debootstrap I keep
monitoring it and it shows to be flaky I may add retries somewhere.

Cheers,
Balint

Reply via email to