Ensure that a failing plymouth doesn't prevent fsckd to reconnect/exit ... unexpected success
FAILED (unexpected successes=1)
autopkgtest [09:05:38]: test systemd-fsckd: -----------------------]
systemd-fsckd PASS
Note systemd-fsckd only fails on failures & errors, and passed with unexpected successes:
if len(result.failures) != 0 or len(result.errors) != 0:
return_code = 1
I also wonder what has changed to make this test case reliable, in the past it used to be flakey, that's why i switched it to expectedfailure. I guess it's ok to reenable this in devel.
I see no need to reenable it in stable series. It has a regression potential, since it used to be flakey, it may start to be flakey again blocking SRU migrations.
"and so causes autopkgtest failures." is not true.
From http:// autopkgtest. ubuntu. com/packages/ systemd/ bionic/ amd64 /objectstorage. prodstack4- 5.canonical. com/v1/ AUTH_77e2ada1e7 a84929a74ba3b87 153c0ac/ autopkgtest- bionic/ bionic/ amd64/s/ systemd/ 20190529_ 090547_ 1f40a@/ log.gz
E.g. https:/
Ensure that a failing plymouth doesn't prevent fsckd to reconnect/exit ... unexpected success
FAILED (unexpected successes=1)
autopkgtest [09:05:38]: test systemd-fsckd: ------- ------- ------- --]
systemd-fsckd PASS
Note systemd-fsckd only fails on failures & errors, and passed with unexpected successes: failures) != 0 or len(result.errors) != 0:
if len(result.
return_code = 1
I also wonder what has changed to make this test case reliable, in the past it used to be flakey, that's why i switched it to expectedfailure. I guess it's ok to reenable this in devel.
I see no need to reenable it in stable series. It has a regression potential, since it used to be flakey, it may start to be flakey again blocking SRU migrations.