Bug#898208: kwidgetsaddons: KDateComboBoxTest::testSignals() fails: 'QTest::qWaitForWindowActive(combo.data())' returned FALSE
Source: kwidgetsaddons
Version: 5.44.0-1
Severity: important
User: debian-ci@lists.debian.org
Usertags: flaky
The autopkgtest for kwidgetsaddons appears to be unreliable: it
intermittently succeeds or fails with:
FAIL! : KDateComboBoxTest::testSignals() 'QTest::qWaitForWindowActive(combo.data())' returned FALSE. ()
Loc: [/tmp/autopkgtest-lxc.3z7re_he/downtmp/build.osO/src/autotests/kdatecomboboxtest.cpp(190)]
Because this is intermittent and has previously succeeded, the CI
infrastructure considers this to be a regression in the dbus package,
causing the migration delay to be increased from 5 to 15 days. I've
requested a retry. Recent discussion of gating migration by autopkgtests
on debian-devel[0] noted that if this is going to work, and in particular
if we are going to *block* migration when it causes autopkgtest
regressions rather than merely delaying it, intermittent autopkgtest
failures are likely to have to be considered RC due to their impact on
the tested package's dependencies; for now I've filed it as important.
I don't think this is *actually* a dbus regression, because the test
has been intermittently failing since 5.44.0, even with older dbus.
I've previously proposed[1] a way to mark autopkgtests as unsuitable
for gating CI, while still having them available for convenient manual
testing (and optionally run, but with their results disregarded, on the
real CI infrastructure so that their reliability can be assessed), but
this isn't currently possible. If the autopkgtest can't be made reliable
then it would make sense to disable it for the moment.
Looking at the log, it seems this autopkgtest isn't actually testing
the installed library as intended by the autopkgtest spec, because the
test executable is linked to a just-compiled library instead:
[ 70%] Linking CXX executable ../bin/kdatecomboboxtest
/usr/bin/c++ -g -O2 ... -o ../bin/kdatecomboboxtest -Wl,-rpath,/tmp/autopkgtest-lxc.fq9fh4o5/downtmp/build.GID/src/obj-x86_64-linux-gnu/bin ... ../bin/libKF5WidgetsAddons.so.5.44.0 ...
This doesn't seem right? The specification[2] says autopkgtests are
intended to test the installed version of the software, which in this
case should mean they test that /usr/lib/MULTIARCH/libKF5WidgetsAddons.so.5
still works.
Regards,
smcv
[0] https://lists.debian.org/debian-devel/2018/05/msg00061.html
[1] https://bugs.debian.org/851558
[2] https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst
Reply to: