action #26970
closed[functional]user_gui_login/sddm: password frequently mistyped
0%
Description
Updated by dimstar over 7 years ago
Looking at the typed password, there seems to be one key-press missed (the password length does not match expectations)
This test fails quite a lot lately, and makes staging and product testing a pain
Updated by dimstar over 7 years ago
- Copied to action #26972: [functional][sporadic][medium]user_gui_login/gdm: no mouse, resulting in no mouse-over user selection added
Updated by okurz over 7 years ago
so staging tests fail as well. Did you retry an older version of staging? Was it seen in QAM tests as well?
Updated by dimstar over 7 years ago
funnily, in staging we don't see it - but in the product tests it is most of the times seen in the large updates, mostly coming from openSSE 12.x and 13.x
Which could indicate, as coolo mentioned in the call, that there is some background task firing up and interfering
Updated by okurz over 7 years ago
- Priority changed from Normal to Urgent
reproducible every time in multiple scenarios.
Updated by okurz over 7 years ago
- Subject changed from user_gui_login/sddm: password frequently mistyped to [functional]user_gui_login/sddm: password frequently mistyped
Updated by dimstar about 7 years ago
- Status changed from New to In Progress
Inspected that a bit more - turns out, it does not mistype the password, but actually types the username (which happens to be one char shorter than the password)
The entire thing was tracked down to a product change on October 10, when the DM selection changed from /etc/sysconfig to update-alternative managed DM. This happened to replace KDM with SDDM on upgrade from 13.2 to TW; Since the needles all were good though, this was not immediately recognized as being a notable change.
The major difference though is that KDM expects the username to be typed and the username in openQA happens to be one char shorter than the password (which gave the impression that the password is just being mistyped)
I now removed DM_NEEDS_USERNAME=1 from the update_13.2 test suite, which means we can update to TW from 13.2 and it will cope with sddm being present, not asking for a password.
Snapshot 1117 will be the first to be running with this changed configuration (I don't want to postpone 1116 even longer by retriggering this test)
Updated by okurz about 7 years ago
- Status changed from In Progress to Resolved
- Assignee set to dimstar