EDIT: I wrote "22 Beta-TC4", but it actually is TC5.

Sorry for the mystake.

See 
https://admin.fedoraproject.org/updates/FEDORA-2015-4497/plasma-pk-updates-0.1-3.fc22

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)

I can confirm that 'plasma-pk-updates-0.1-3.fc22' fixes the issue.

Proposed as a Blocker for 22-beta by Fedora user juliuxpigface using the blocker tracking app because:

 https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Update_notification

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.

Discussed at 2015-03-30 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-03-30/f22-blocker-review.2015-03-30-16.04.log.txt . Accepted as a blocker per criterion https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Update_notification : "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."

Ran into a snag,

1.  plasma5 uses an odd dir for scripts:
/usr/share/org.kde.plasma.desktop/kpartplugins/

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");
    break;
  }
  if (systrayFound) break;
}
if (!systrayFound)
  print("No systray found");

}

plasma-workspace-5.2.2-3.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/plasma-workspace-5.2.2-3.fc22

Not a full fix ^^, but a prerequisite for any subsequent plasma script to enable plasma-pk-updates applet.

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:
https://projects.kde.org/projects/kde/workspace/plasma-workspace/repository/revisions/5196689ae328decf7865e053d3e5997c2c184b16/diff
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.)

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.)

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...

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"

Oops, "Updates" is the muon one, we want the one labeled "Software Updates"

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.

Automatic Updates can be enabled:
http://wiki.sugarlabs.org/go/Fedora_22#Enable_Plasma_.28KDE.29_Automatic_Updates

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.

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.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-04-13/

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.

(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.

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 https://lists.fedoraproject.org/pipermail/test/2010-June/thread.html#91702 .

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.

Re: comment #9

to test, I confirmed that plasma-applet-org.kde.plasma.pkupdates.desktop currenly contains:
X-Plasma-NotificationArea=true
X-KDE-PluginInfo-EnabledByDefault=true

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.

And the converse, I tested modifying plasma-applet-org.kde.plasma.clipboard.desktop to include:
X-KDE-PluginInfo-EnabledByDefault=false

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

It would appear,

/usr/share/plasma/plasmoids/org.kde.plasma.systemtray/contents/config/main.xml

contains (among other things), the snippet:

    <entry name="extraItems" type="StringList">
      <default>org.kde.plasma.devicenotifier,org.kde.plasma.notifications,org.kde.plasma.battery,org.kde.plasma.mediacontroller,org.kde.plasma.networkmanagement,org.kde.plasma.clipboard</default>
    </entry>

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 :(

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/org.gnome.software.gschema.override << FOE
[org.gnome.software]
download-updates=false
FOE

(other stuff)

EOF

how was it disabled in the KDE live image before?

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.

https://fedoraproject.org/wiki/Test_Day:2015-04-21_FedUp#Test_Results

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

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.

There seems to many similar reports. Not sure if all of them are duplicates, but it seems likely: bug 1188207, bug 1201938, bug 1189602

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"

(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

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?

I consider it a variant of the same issue, so imo, track it here (and adjust summary as appropriate).

Hoping this kickstart change will take care of it:

https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f22&id=1fd1f6d13885169ccbfe9a167931c072a5d963e8

apper-0.9.1-11.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/apper-0.9.1-11.fc22

And related apper update that omits the apperd (kded module), so that it cannot (accidentaly) refresh packagekit either.

works for me in VirtualBox
auto updates are unchecked in live
but are checked and work once installed to HD

apper update went stable, I believe we can close this now.