[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1004420: openmsx-catapult: flaky autopkgtest: local variable 'done' referenced before assignment

Source: openmsx-catapult
Version: 17.0-2
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian-ci@lists.debian.org
User: debian-ci@lists.debian.org
Usertags: flaky

The openmsx-catapult autopkgtest seems to be failing intermittently.
Several runs on ci.debian.net fail with errors like this:

> + /tmp/autopkgtest-lxc.mk6dsl1u/downtmp/build.TO2/src/debian/tests/run.py
> Creating logfile at /tmp/dogtail-debci/logs/run_20220118-073351_debug ...
> Warning: AT-SPI's desktop is visible but it has no children. Are you running any AT-SPI-aware applications?
> Clicking on [check box | Check for working hardware configurations after closing this dialog]
> Mouse button 1 click at (237.5,78.5)
> Clicking on [push button | OK]
> Mouse button 1 click at (332.5,129.0)
> Clicking on [menu | File]
> Mouse button 1 click at (19.0,12.5)
> Clicking on [menu item | Test MSX Hardware]
> Mouse button 1 click at (117.5,37.5)
> Traceback (most recent call last):
>   File "/tmp/autopkgtest-lxc.mk6dsl1u/downtmp/build.TO2/src/debian/tests/run.py", line 83, in <module>
>     test_detect()
>   File "/tmp/autopkgtest-lxc.mk6dsl1u/downtmp/build.TO2/src/debian/tests/run.py", line 60, in test_detect
>     done.click()
> UnboundLocalError: local variable 'done' referenced before assignment

For example, see:
At the time of writing, one of the first two migration-reference/0 runs
(which run tests in a pure testing environment) failed and the other one
succeeded; similarly, of the two recent runs with src:glib2.0 taken from
unstable, one failed and the other succeeded.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between passing
and failing without changes to the list of installed packages, are causing
people unrelated to your package to spend time on these tests: in this
particular case, I looked at it because it could have prevented a new
version of glib2.0 with denial-of-service fixes from migrating to testing.

Please either fix the test to be more robust, or or use the
"flaky" restriction for this test until a solution has been found.


Reply to: