Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1206760 - Plasma live session notifies for available updates
Summary: Plasma live session notifies for available updates
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-pk-updates
Version: 22
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: KDE SIG
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker https://fedoraproject...
Depends On: plasma-pk-updates
Blocks: F22FinalBlocker
TreeView+ depends on / blocked
Reported: 2015-03-28 09:43 UTC by Giulio 'juliuxpigface'
Modified: 2015-05-25 00:05 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-05-12 01:30:46 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1188207 0 unspecified CLOSED Apper won't check for updates even when user asks it to, and misses updates 2022-05-16 11:32:56 UTC
Red Hat Bugzilla 1189602 0 unspecified CLOSED PackagetKit reports no updates are available 2022-05-16 11:32:56 UTC
Red Hat Bugzilla 1201938 0 unspecified CLOSED pkcon refresh uses infinite cache age by default, making it a noop 2022-05-16 11:32:56 UTC

Internal Links: 1188207 1189602 1201938

Description Giulio 'juliuxpigface' 2015-03-28 09:43:30 UTC
Description of problem:

I was testing the case "QA:Testcase_desktop_updates" on KDE. While running a Fedora 22 Beta-TC4 (installed from the live spin), I don't receive notifies about available updates.

Version-Release number of selected component:
- apper-0.9.1-6.fc22.x86_64

Steps to Reproduce:
1. Download "kde live" iso from the TC5 Desktop page.
2. Perform an installation.
3. Reboot.
4. Ensure that '$ dnf check-update' lists available updates.
5. Try a '$ notify-send "test"' to ensure that the desktop can handle notifications.
6. Wait for a reasonably amount of time (I waited for more than 60 minutes and still no luck).

Actual results:
1. The user don't receive notifies about available updates.

Expected results:
1. On an installed system, KDE should notify "out of the box" about available updates.

Additional info:
I chose an automatic partitioning layout with encryption, on a 8gb KVM target disk, but I don't think this could be the cause.

Comment 1 Giulio 'juliuxpigface' 2015-03-28 09:50:20 UTC
EDIT: I wrote "22 Beta-TC4", but it actually is TC5.

Sorry for the mystake.

Comment 2 Rex Dieter 2015-03-28 13:58:31 UTC

For the update tool we're hoping to include in f22  (It can't be included in the .iso image until it hits stable updates)

Comment 3 Giulio 'juliuxpigface' 2015-03-30 06:06:18 UTC
I can confirm that 'plasma-pk-updates-0.1-3.fc22' fixes the issue.

Comment 4 Fedora Blocker Bugs Application 2015-03-30 06:11:41 UTC
Proposed as a Blocker for 22-beta by Fedora user juliuxpigface using the blocker tracking app because:

In Beta TC5, the release criteria 'Update notification' was violated by KDE's standard behavior.
I don't really know if I was supposed to report this as a blocker. Actually, the bug has been already fixed.

Comment 5 Adam Williamson 2015-03-30 16:13:45 UTC
Discussed at 2015-03-30 blocker review meeting: . Accepted as a blocker per criterion : "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."

Comment 6 Rex Dieter 2015-03-30 17:46:01 UTC
Ran into a snag,

1.  plasma5 uses an odd dir for scripts:

2.  Once I try to use that, however, my initial try doesn't seem to work (not sure if the script is running at all):

if (userDataPath() != "/home/liveuser") {

systrayFound = false;
pids = panelIds;
for (i = 0; i < pids.length; ++i) {
  p = panelById(pids[i]);
  if (!p) continue;
  ids = p.widgetIds;
  for (j = 0; j < ids.length; ++j) {
    w = p.widgetById(ids[j]);
    if (!w || w.type != "systemtray") continue;
    systrayFound = true;
    w.currentConfigGroup = new Array("Applets");
    max = 0;
    for (k = 0; k < w.configGroups.length; ++k)
      if (parseInt(w.configGroups[k]) > max)
        max = parseInt(w.configGroups[k]);
    w.currentConfigGroup = new Array("Applets", max + 1);
    w.writeConfig("plugin", "org.kde.plasma.pkupdates");
    print("plasma-pk-updates added to the systray");
  if (systrayFound) break;
if (!systrayFound)
  print("No systray found");


Comment 7 Fedora Update System 2015-03-30 19:00:29 UTC
plasma-workspace-5.2.2-3.fc22 has been submitted as an update for Fedora 22.

Comment 8 Rex Dieter 2015-03-30 19:01:36 UTC
Not a full fix ^^, but a prerequisite for any subsequent plasma script to enable plasma-pk-updates applet.

Comment 9 Kevin Kofler 2015-03-30 20:59:14 UTC
So, it looks like we need to rewrite most of this function, not because the Plasma scripting API changed (it didn't), but because the systemtray applet was completely rewritten, and in particular, the configuration syntax is completely different. The ID "systemtray" is also no longer correct, it's now called "org.kde.plasma.systemtray". But changing that is not sufficient, the whole [Applets] config group system is gone.

It looks like the system tray now automatically figures out what plasmoids to show initially:
They look at the plasmoids with [X-Plasma-NotificationArea] == true and [X-KDE-PluginInfo-EnabledByDefault] == true.

(I think there's a bug in the upstream code, in that they only list the plasmoids that are enabled by default as allowed plasmoids. IMHO, they should list everything with with [X-Plasma-NotificationArea] == true as allowed, and only those with also [X-KDE-PluginInfo-EnabledByDefault] == true as enabled.)

Comment 10 Kevin Kofler 2015-03-30 21:12:45 UTC
Actually, I now think the code is correct, it's just their definition of "allowed" that didn't match mine. (They seem to mean "allowed" as in "the user allowed that plasmoid to run". I was thinking "plasmoid the user is allowed to enable", but they use availablePlasmoids for that meaning.)

Comment 11 Adam Williamson 2015-04-09 00:40:47 UTC
This doesn't seem to be working for me, at least, I've had a Beta RC1 KDE install sitting here for >1 hour with no update notifications...

Comment 12 Rex Dieter 2015-04-09 00:59:02 UTC
nod, it's not fixed yet, we don't have the applet getting enabled automatically.

If you want to test it manually, you can right click system tray "^", => 
  system tray settings => in general section, extra items, *check* item labeled "Updates"

Comment 13 Rex Dieter 2015-04-09 01:00:38 UTC
Oops, "Updates" is the muon one, we want the one labeled "Software Updates"

Comment 14 Adam Williamson 2015-04-09 01:01:08 UTC
OK. Setting back to ASSIGNED.

In theory this should block Beta, but honestly it seems wrong for update notification to be a Beta criterion with our current conception of Beta vs. Final, should probably be Final. Checking the history, making it Beta was just my first instinct way back when we created the criterion, no-one +1 or -1ed it so it went in there.

I'll send out a mail about this and we can also discuss it at go/no-go.

Comment 15 satellitgo 2015-04-09 02:47:56 UTC
Automatic Updates can be enabled:

Comment 16 Adam Williamson 2015-04-12 23:43:20 UTC
I'm going to propose we move this criterion to Final, as per #c14. Dropping AcceptedBlocker so we actually discuss it at go/no-go this week.

Comment 17 Petr Schindler 2015-04-13 16:50:58 UTC
Discussed at today's blocker review meeting [1].

This bug was accepted as Final Blocker - it was agreed in meeting that the criterion violated by this bug (update notification) should be moved to Final. Therefore this bug is accepted as a Final blocker.


Comment 18 Kevin Kofler 2015-04-13 17:31:05 UTC
So we are once again lowering the expectation of quality for our deliverables, just to be able to avoid a slip. Are we really sacrificing the quality of our release just for a sci-fi movie reference through our release date?! Or are there some other hidden motives? (RHEL 8?) I don't see any valid reason for that unusually strict schedule enforcement for F22.

Comment 19 Giulio 'juliuxpigface' 2015-04-13 18:22:36 UTC
(In reply to Kevin Kofler from comment #18)
> So we are once again lowering the expectation of quality for our
> deliverables, just to be able to avoid a slip. Are we really sacrificing the
> quality of our release just for a sci-fi movie reference through our release
> date?! Or are there some other hidden motives? (RHEL 8?) I don't see any
> valid reason for that unusually strict schedule enforcement for F22.

Hi Kevin.

In my opinion, this isn't a serious issue at all. As far as I know, the widget responsible for the updates is present, but it's not enabled (added to the panel) by default.

I haven't got a deep knowledge of our 'release criteria' yet, but I'm trying to judge the feature by the user point of view. And to me, this bug doesn't seem to be so serious since the user itself can easily add the appropriate widget to the panel.

Comment 20 Adam Williamson 2015-04-14 00:17:20 UTC
Kevin: not really, no, it just seemed not really to make sense for this to be a Beta criterion at all. The criterion was initially proposed by cwickert without a specific milestone given. I was the one who chose Beta, more or less on a whim. The proposal went through with a grand total of nobody commenting on it at all. So this criterion being a Beta criterion was hardly a carefully-considered decision by a committee of greybeards, it was just me picking milestones out of a hat. See .

Fast forward to several years later and we have a bug that violates the criterion, and honestly I just looked at it and thought 'that doesn't make sense as a Beta criterion in the first place, whose idiotic idea was that?' - then looked it up and found out it was me.

Our high-level goals for Beta are listed as:

The objectives of the Beta release are to:

    Publicly release installable media versions of a code complete test release: Beta is the last widely co-ordinated test release point in any given release cycle
    Finish testing Fedora 22 Changes
    Identify as many F22 Final blocker bugs as possible 

none of those *really* seems to match up with 'update notification has to work', for me. It just seems to be more appropriate for Final.

Comment 21 Rex Dieter 2015-04-21 17:18:08 UTC
Re: comment #9

to test, I confirmed that plasma-applet-org.kde.plasma.pkupdates.desktop currenly contains:

and I logged in as a fresh/new user, and this applet does not get enabled (by default).

It's unclear to me if that is by design or simply a bug.

Comment 22 Rex Dieter 2015-04-21 17:28:39 UTC
And the converse, I tested modifying plasma-applet-org.kde.plasma.clipboard.desktop to include:

and restarted with fresh user, and they (still) had the clipboard applet enabled by default.

Comment 23 Rex Dieter 2015-04-21 17:36:47 UTC
It would appear,


contains (among other things), the snippet:

    <entry name="extraItems" type="StringList">

I just tested adding org.kde.plasma.pkupdates.desktop to that list... and it works.

Except, implementing this will probably mean that now our live image will check for updates too :(

Comment 24 Adam Williamson 2015-04-21 18:06:23 UTC
you can nerf it in the livesys service, that's the normal way of doing such things. the Workstation kickstart already does that:

cat >> /etc/rc.d/init.d/livesys << EOF

# disable updates plugin
cat >> /usr/share/glib-2.0/schemas/ << FOE

(other stuff)


how was it disabled in the KDE live image before?

Comment 25 Kevin Kofler 2015-04-21 22:03:55 UTC
In Plasma 4, the whole default-enabling of the plasmoid was done in a Plasma initialization JavaScript script which checked whether the home directory was different from "/home/liveuser".

We can probably tweak that extraItems list from Plasma initialization JavaScript in Plasma 5 as well, but the problem is that we don't have nice code to start from. The system tray plasmoid has been rewritten and uses completely different configuration entries now.

Comment 26 satellitgo 2015-04-22 15:25:08 UTC

"No software update in system settings/extra items do dnf install @kde-desktop to add plasma-pk-updates"

Comment 27 satellitgo 2015-04-25 21:07:39 UTC
kunubutu at lfnw today has Plasma updates installed and selected on their release.
I asked for info on how they do it. Hope to get e-mail soon.

Comment 28 Kamil Páral 2015-04-27 11:12:43 UTC
There seems to many similar reports. Not sure if all of them are duplicates, but it seems likely: bug 1188207, bug 1201938, bug 1189602

Comment 29 satellitgo 2015-05-03 23:09:45 UTC
Appears to be fixed in Fedora-Live-KDE-x86_64-22-20150503   koji f22 branched

Update pop-upinforms when updates are available

System Tray Settings / Software Updates is selected both in live and after install. Also in Entries shows as "Auto"  as default.

Apper: "SearchGroups not supported by backend"

Comment 30 satellitgo 2015-05-03 23:15:11 UTC
(In reply to satellitgo from comment #29)
> Appears to be fixed in Fedora-Live-KDE-x86_64-22-20150503   koji f22 branched
> Update pop-upinforms when updates are available
> System Tray Settings / Software Updates is selected both in live and after
> install. Also in Entries shows as "Auto"  as default.
> Apper: "SearchGroups not supported by backend"

installed muon but it also does not list groups ie: other desktops
yumex does and works

Comment 31 Adam Williamson (Fedora) 2015-05-04 18:05:24 UTC
I confirm satellit's note from #c29 - in 20150503 nightly, I get update notifications both when booted live and after install.

So this bug as described is fixed, but there should *not* be update notifications when booted live, they need to be disabled somehow. This is also a release blocking issue. Should we close this and file a new bug, or edit this one?

Comment 32 Rex Dieter 2015-05-04 18:07:29 UTC
I consider it a variant of the same issue, so imo, track it here (and adjust summary as appropriate).

Comment 33 Rex Dieter 2015-05-05 17:21:26 UTC
Hoping this kickstart change will take care of it:

Comment 34 Fedora Update System 2015-05-05 18:28:15 UTC
apper-0.9.1-11.fc22 has been submitted as an update for Fedora 22.

Comment 35 Rex Dieter 2015-05-05 18:29:21 UTC
And related apper update that omits the apperd (kded module), so that it cannot (accidentaly) refresh packagekit either.

Comment 36 satellitgo 2015-05-06 19:40:18 UTC
works for me in VirtualBox
auto updates are unchecked in live
but are checked and work once installed to HD

Comment 37 Adam Williamson 2015-05-12 01:30:46 UTC
apper update went stable, I believe we can close this now.

Note You need to log in before you can comment on or make changes to this bug.