The autopkgtests against kscreenlocker and kwin succeeded on retry, as was a case of hiccups on the infra.
The fails of kdeconnect against kde-cli-tools is an upstream issue with that test (race condition) that for some reason has become worse and affecting more architectures, but nontheless is not the fault in any way of the kde-cli-tools upload.
show that the test was regressed previously when triggered by a qtbase upload, and when triggered against itself (Trigger: kdeconnect/1.3.3-0ubuntu0.18.04.1) it fails, so regressed in release.
So in this case the test fails should not block this SRU. A fix in a separate kdeconnect SRU may be considered, if an acceptably reliable upstream solution to their broken test appears.
The autopkgtests against kscreenlocker and kwin succeeded on retry, as was a case of hiccups on the infra.
The fails of kdeconnect against kde-cli-tools is an upstream issue with that test (race condition) that for some reason has become worse and affecting more architectures, but nontheless is not the fault in any way of the kde-cli-tools upload.
For example the history here: http:// autopkgtest. ubuntu. com/packages/ k/kdeconnect/ bionic/ amd64
show that the test was regressed previously when triggered by a qtbase upload, and when triggered against itself (Trigger: kdeconnect/ 1.3.3-0ubuntu0. 18.04.1) it fails, so regressed in release.
Also fails on upstream KDE CI: https:/ /build. kde.org/ job/Extragear/ job/kdeconnect- kde/job/ stable- kf5-qt5% 20SUSEQt5. 12/2/testReport /projectroot/ tests/testsslso cketlinereader/
So in this case the test fails should not block this SRU. A fix in a separate kdeconnect SRU may be considered, if an acceptably reliable upstream solution to their broken test appears.