QA » openQA Project » openQA Tests

can you enlighten us about the "weird issue" you noted in #9492#note-3 ?

My guess would be it's taking over 100 seconds for the update viewer to launch.. @mkravec does that make sense to you as a possible cause?

I think it's more the inverse, the updater opens up "too fast" while the "wait_idle" within the assert for desktop runner is still blocked and then the updater either closes itself or "esc" is forwarded to the wrong window?

Test is failing only on gnome@64bit-ipmi and jpupava told me today that ipmi does not understand assert_and_click. Might be connected to this?

Every backend has to properly implement every call of the testapi. Of course ipmi also knows assert_and_click. The problem is visible in the logfile and you are right that it is ipmi specific:

18:39:26.0265 Debug: /var/lib/openqa/share/tests/sle/tests/x11/updates_gnome.pm:26 called testapi::x11_start_program
18:39:26.0266 <<< type_string(string='gpk-update-viewer', max_interval=250)
…
18:39:27.2032 wait_idle sleeping for 15 seconds
18:39:42.2189 >>> wait_idle: timed out after 15
18:39:42.2194 <<< send_key(key='ret')
18:39:42.4215 <<< wait_idle(timeout=57)
18:39:42.4219 wait_idle sleeping for 57 seconds
18:40:39.4379 >>> wait_idle: timed out after 57

so the second wait_idle which comes from send_key 'ret', 1 is sleeping blindly for 57(!) seconds. During this time the update manager probably disappears because of a timeout again.
Why 57 seconds? The default for wait_idle is shorter but the ipmi-backend scales the timeout so we end up with these 57 seconds. Fix? Probably remove the "wait_idle", i.e. the ,1 from send_key and replace with something proper.

Oliver, thanks - I saw 57s wait_idle, but did not think that gpk-update-viewer closes after 60 by itself :)
Also send_key confused me with parameter "1" not being seconds, but boolean..

PR on the way.