[opensuse][kde] Upgrade popups confuse KDE Tests
openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-update_Leap_15.0_kde@64bit fails in
Test suite description¶
Upgrade scenario from Leap 15.0 with kde installed. Maintainer: riafarov.
Fails since (at least) Build 20190612
Last good: 20190607 (or more recent)
Always latest result in this scenario: latest
After the upgrade from the DVD is completed, there are, as always, more updates available from the FTP tree. While those updates are not applied, a bunch of 'update notifications' pop up, informing the user of such.
Of course we could handle that by crafting needles to ignore the area of the update notifications - but that sounds like the wrong approach.
This issue currently shows up on all KDE Update tests (from DVD, no issues with NET install and zdup upgrades, as those make use of the FTP tree during the upgrade already)
#2 Updated by okurz about 2 years ago
- Priority changed from Normal to Urgent
Then I see multiple problems:
- did we not have these modules to install all pending updates in one step?
- did we not disable all external repos? To answer myself: We do: https://openqa.opensuse.org/tests/962594#step/zypper_lr/3
I guess it's rather simple: We have the updates repo removed however the notification is already there and not going away automatically.
https://openqa.opensuse.org/tests/962594#step/user_gui_login/1 shows the first occurence of the update popup.
and logout and login does not seem to make the dialog go away as one can see in https://openqa.opensuse.org/tests/962594#step/desktop_runner/3 with the popup reappearing in a fresh session.
I can think of multiple ideas what to do:
- Terminate/kill the update popup before even trying to switch back to the X11 session
- Click on the red X icon as soon as we see it (would need hard to maintain needles, probably)
- ignore that section in every needle (as you already stated)
- Reboot after removal of the according repos
- Restart the graphical session
Both "rebooting" and "restarting" should be taken with care because that means we should rather move the according test modules earlier. No use in rebooting implicitly to explicitly test rebooting later on.
I would go with a combination of 1 and 3.
SLindoMansilla you haven't added a team tag, I would think it's "[functional][u]", isn't it?
#3 Updated by StefanBruens about 2 years ago
IMHO this is either a bug in the new KDE notification implementation (since 5.16.0) or a bug in the zypper/packagekit integration.
Only a single notification should be show, replacing older ones.
It is easy to trigger this, just run "pkcon refresh" multiple times in a row, each one produces a new notification (after a few seconds).
#4 Updated by okurz about 2 years ago
yes, I guess so.
But coming back to my own question in #53288#note-2 I see that
- in the gnome clean installation case https://openqa.opensuse.org/tests/962919# we install available updates directly after installation
- same in KDE https://openqa.opensuse.org/tests/962915#step/updates_packagekit_kde/21
- we do not do that in neither the KDE upgrade scenario https://openqa.opensuse.org/tests/953728#
- nor the gnome one https://openqa.opensuse.org/tests/963064
I guess the problem only appears now because of the KDE update applet that StefanBruens mentioned however I think we should use that opportunity to crosscheck what is expected from all the test flows we can imagine:
- anyone knows why we do not try to install updates after upgrade? Did behaviour maybe change with some yast change about applying online updates during installation?
- riafarov We already have the module "installation/online_repos", do we have scenarios that actually enable online updates during upgrades?
- how about handling updates (or just the "wrong" notifications about it) in the upgraded systems as we do in the clean installation case – of course only when we do not apply the online updates during installation?
#7 Updated by StefanBruens about 2 years ago
wow, does that mean a fix will reach our tests soon then?
Don't know, you probably have to poke one of the openSUSE KDE project maintainers ;-)
#8 Updated by okurz about 2 years ago
- Status changed from New to In Progress
- Assignee set to favogt
- Status changed from In Progress to Resolved
The above mentioned SR is done for long. Other than this there were no mentions in this ticket for already 2 years (!) so assuming "Resolved". This ticket showed up in the SLO related queries from https://progress.opensuse.org/projects/openqatests/wiki/Wiki#SLOs-service-level-objectives