action #53288

[opensuse][kde] Upgrade popups confuse KDE Tests

Added by dimstar about 2 years ago. Updated 17 days ago.

Bugs in existing tests
Target version:
Start date:
Due date:
% Done:


Estimated time:



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

Expected result

Last good: 20190607 (or more recent)

Further details

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)


#1 Updated by SLindoMansilla about 2 years ago

  • Subject changed from Upgrade popups confuse KDE Tests to [opensuse][kde] Upgrade popups confuse KDE Tests

#2 Updated by okurz about 2 years ago

  • Priority changed from Normal to Urgent

Then I see multiple problems:

I guess it's rather simple: We have the updates repo removed however the notification is already there and not going away automatically. 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 with the popup reappearing in a fresh session.

I can think of multiple ideas what to do:

  1. Terminate/kill the update popup before even trying to switch back to the X11 session
  2. Click on the red X icon as soon as we see it (would need hard to maintain needles, probably)
  3. ignore that section in every needle (as you already stated)
  4. Reboot after removal of the according repos
  5. 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

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?

#5 Updated by StefanBruens about 2 years ago

Notifications in KDE upstream and in KDE:Applications are no longer repeated.

#6 Updated by okurz about 2 years ago

wow, does that mean a fix will reach our tests soon then?

#7 Updated by StefanBruens about 2 years ago

okurz wrote:

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

Well, as favogt mentioned in : "Will do some more minor cleanups and forward"

favogt assigning to you as I assume the "fix" to the tests will be implicit by product behavioural change :)

#9 Updated by okurz 17 days ago

  • 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

Also available in: Atom PDF