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 bugzilla.redhat.com.
Bug 1436873 - KDE live environment notifies of available updates
Summary: KDE live environment notifies of available updates
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: spin-kickstarts
Version: 26
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jeroen van Meeuwen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F26FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2017-03-28 22:37 UTC by Adam Williamson
Modified: 2017-07-05 01:14 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-05 01:14:28 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
screenshot showing this with the 2017-06-28 nightly (740.50 KB, image/png)
2017-06-30 00:01 UTC, Matthew Miller
no flags Details

Description Adam Williamson 2017-03-28 22:37:02 UTC
Current Fedora 26 and Rawhide KDE live images notify that updates are available when booted live. They are not supposed to do this, it's in the release criteria: https://fedoraproject.org/wiki/Fedora_26_Final_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."

Proposing as a Final blocker.

Comment 1 Rex Dieter 2017-03-30 12:00:05 UTC
Apparently this kickstarts snippet is no longer working as advertised:

# Disable plasma-pk-updates
sed -i \
    -e "s|^X-KDE-PluginInfo-EnabledByDefault=true|X-KDE-PluginInfo-EnabledByDefault=false|g" \
    /usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/metadata.desktop \
    /usr/share/kservices5/plasma-applet-org.kde.plasma.pkupdates.desktop

Comment 2 Geoffrey Marr 2017-04-10 20:27:11 UTC
Discussed during the 2017-04-10 blocker review meeting: [1]

The decision was made to classify this bug as an AcceptedBlocker as it violates the following criteria:

"Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2017-04-10/f26-blocker-review.2017-04-10-16.01.txt

Comment 3 Rex Dieter 2017-04-18 15:43:51 UTC
Triaging to plasma-pk-updates

Comment 4 Adam Williamson 2017-06-06 18:45:23 UTC
Still happening as of 2017-06-06, for the record.

Comment 5 Than Ngo 2017-06-12 13:06:22 UTC
Adam, it seems to be fixed in KDE-live-beta-1.4, i cannot reproduce this issue anymore.

Could you please test the KDE-live-beta-1.4 iso again?
thanks

Comment 6 Adam Williamson 2017-06-12 18:26:43 UTC
It seems like it passed with Beta-1.3 and Beta-1.4, and also with the 20170611.n.1 nightly, but failed with all nightlies up to that point. Can someone confirm they actually did something to fix it, though?

Comment 7 Than Ngo 2017-06-19 11:16:15 UTC
I have reviewed the plasma-pk-updates and don't think it's a bug here, but this was likely  caused from other kde components which was unnoticed fixed by update to new releases sometimes during the development.

I move the state to MODIFIED and feel free to reopen it again if someone can reproduce it.

thanks

Comment 8 Adam Williamson 2017-06-20 19:46:14 UTC
It failed in today's Fedora 26 nightly test:

https://openqa.fedoraproject.org/tests/110646

click on the thumbnail with the red border and you'll see the update notification icon is there in the system tray (the circle with an upward-pointing arrow inside it). That test does nothing but boot the live image, wait 10 minutes, and then check whether the update notification is there.

Comment 9 Than Ngo 2017-06-28 13:23:16 UTC
(In reply to Adam Williamson from comment #8)
> It failed in today's Fedora 26 nightly test:
> 
> https://openqa.fedoraproject.org/tests/110646
> 
> click on the thumbnail with the red border and you'll see the update
> notification icon is there in the system tray (the circle with an
> upward-pointing arrow inside it). That test does nothing but boot the live
> image, wait 10 minutes, and then check whether the update notification is
> there.

Adam, i tested the Fedora-KDE-Live-x86_64-26-20170627.n.0.iso today and still cannot reproduce this issue with this image. It's the same testing like you did.
run live image in qemu and wait 20 mitunes, the update notification does not show up after more than 20 minutes.

Could someone else reproduce this issue?

Comment 10 Rex Dieter 2017-06-28 13:28:23 UTC
Easier test without waiting 20 minutes: Is the "Software Updates" applet even enabled/visible in system tray?  Hint: it should not be (not even hidden)

Comment 11 Than Ngo 2017-06-28 14:13:23 UTC
no, the "Software Updates" applet is not visible in system tray

Comment 12 Adam Williamson 2017-06-28 20:50:28 UTC
Well, I did lie a bit: that's not quite *all* the test does. It actually boots to runlevel 3 and installs a dummy, low-versioned python3-kickstart package to ensure that an update will actually be available if the check is run. Then it does 'systemctl isolate graphical.target', waits for KDE to start up, and waits 10 minutes and checks the system tray.

The test is still failing quite often, as you can see from https://openqa.fedoraproject.org/tests/113875#previous .

Comment 13 Than Ngo 2017-06-29 12:37:10 UTC
Adam, could you please provide the steps which you did exactöy for testing so we can reproduce this issue?

Thanks

Comment 14 Adam Williamson 2017-06-29 16:47:32 UTC
That's what #c12 is.

Comment 15 Matthew Miller 2017-06-30 00:00:15 UTC
(In reply to Ngo Than from comment #13)
> Adam, could you please provide the steps which you did exactöy for testing
> so we can reproduce this issue?
> 
> Thanks

Ngo, I booted up the livecd from  https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170628.n.1/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-26-20170628.n.1.iso in a VM. The software updates icon is there at the bottom of the screen, and within a few seconds pops up telling me that 65 updates are available.

Comment 16 Matthew Miller 2017-06-30 00:01:36 UTC
Created attachment 1293012 [details]
screenshot showing this with the 2017-06-28 nightly

Comment 17 Matthew Miller 2017-06-30 00:05:48 UTC
Rex, that sed *does* seem to happen. I did

$ grep X-KDE-PluginInfo-EnabledByDefault     /usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/metadata.desktop \
>     /usr/share/kservices5/plasma-applet-org.kde.plasma.pkupdates.desktop

and the result is 


/usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/metadata.desktop:X-KDE-PluginInfo-EnabledByDefault=false
/usr/share/kservices5/plasma-applet-org.kde.plasma.pkupdates.desktop:X-KDE-PluginInfo-EnabledByDefault=false

which looks like what you're going for, right? Maybe the option changed or something?

Comment 18 Adam Williamson 2017-06-30 00:11:07 UTC
Thanks, Matt - I didn't get to this in the end today.

Ngo etc., note for reproduction purposes it seems like the notification doesn't *always* appear. The openQA test fails about half the time, or a little more. *Sometimes* the notification doesn't appear, and it passes.

Comment 19 Matthew Miller 2017-06-30 00:48:51 UTC
Based on quick testing, even completely removing those desktop files is insufficient. I recommend

dnf -C remove plasma-pk-updates

(or I guess `rpm -e plasma-pk-updates` -- whichever is Proper for spin kickstarts these days

Comment 20 Matthew Miller 2017-06-30 01:00:53 UTC
Wait, hold on -- Rex says modifications outside of /home/liveuser get copied to the main system. Which is what I thought too but it's been too long. So, here's my working theory:

1. This was actually disabling update checking _always_.

2. Sometime long ago, the change to the .desktop files was the way to disable these applets or plasmoids or whatever.

3. Now it works! Yay!

4. Except, it also works on the live CD. 

5. Except sometimes that fails, or people don't hang out there long enough to notice, so we didn't notice it.

How to fix now? Must be some per-session way of disabling applets. Dunno. Need KDE knowledge here.

Comment 21 Matthew Miller 2017-06-30 01:29:26 UTC
For what it's worth, with the image I downloaded running in a VM on my home desktop, with today's available updates, it succeeds every time

Comment 22 Matthew Miller 2017-06-30 01:38:43 UTC
Actually, I'm now suspicious that this never worked. In bug #1206760, one person verifies the solution which Rex proposes -- but maybe they ran into the "it doesn't always work" issue and got lucky.

Comment 23 Matthew Miller 2017-06-30 01:40:30 UTC
Wait, as noted in that bug, the Workstation livecd overwrites stuff in /usr. So, now I'm confused again.

Maybe it is bedtime.

Comment 24 Jan Grulich 2017-06-30 07:53:59 UTC
I tried to change EnableByDefault to false in ../org.kde.plasma.pkupdates/metadata.desktop and then tried to add a new systray widget and plasma-pk-updates were not there so this is working. BUT there is another applet showing updates coming from Discover which is also enabled by default, are you sure the applet you see is plasma-pk-updates? The difference between them is that Discover (notifier) just shows the number of updates, while plasma-pk-updates lists them all and can actually do the update.

Comment 25 Than Ngo 2017-06-30 08:57:08 UTC
(In reply to Adam Williamson from comment #18)
> Thanks, Matt - I didn't get to this in the end today.
> 
> Ngo etc., note for reproduction purposes it seems like the notification
> doesn't *always* appear. The openQA test fails about half the time, or a
> little more. *Sometimes* the notification doesn't appear, and it passes.

Adam, i can now reproduce this issue in Fedora-KDE-Live-x86_64-26-20170628.n.1.iso

I think the correct solution for this issue is to remove the plasma-pk-updates package in fedora-live-kde-base.ks because we don't want the update on livecd.
I also made a patch for fedora-kickstarts which fixes this issue.

Could you please apply it?

diff --git a/fedora-live-kde-base.ks b/fedora-live-kde-base.ks
index 3934d85..158ad85 100644
--- a/fedora-live-kde-base.ks
+++ b/fedora-live-kde-base.ks
@@ -7,6 +7,12 @@
 
 %post
 
+# this is installed by default but we don't need it
+# fixed bz#1436873 
+
+echo "Removing plasma-pk-updates package."
+rpm -e plasma-pk-updates
+
 # set default GTK+ theme for root (see #683855, #689070, #808062)
 cat > /root/.gtkrc-2.0 << EOF
 include "/usr/share/themes/Adwaita/gtk-2.0/gtkrc"

Comment 26 Matthew Miller 2017-06-30 13:40:11 UTC
(In reply to Ngo Than from comment #25)
> I think the correct solution for this issue is to remove the
> plasma-pk-updates package in fedora-live-kde-base.ks because we don't want
> the update on livecd.
> I also made a patch for fedora-kickstarts which fixes this issue.

Hi Ngo! I'm not sure Adam has access to apply that change either. Please use the pull request workflow at https://pagure.io/fedora-kickstarts/branch/f26.

But, are you sure this fix works and doesn't affect the final install? Rex and I have a lot of confusion on this front. :)

Comment 27 Than Ngo 2017-06-30 15:16:43 UTC
(In reply to Matthew Miller from comment #26)
> (In reply to Ngo Than from comment #25)
> > I think the correct solution for this issue is to remove the
> > plasma-pk-updates package in fedora-live-kde-base.ks because we don't want
> > the update on livecd.
> > I also made a patch for fedora-kickstarts which fixes this issue.
> 
> Hi Ngo! I'm not sure Adam has access to apply that change either. Please use
> the pull request workflow at https://pagure.io/fedora-kickstarts/branch/f26.
>

Adam Williamson (adamwill) is the admin and he should have commit access.

> But, are you sure this fix works and doesn't affect the final install? Rex
> and I have a lot of confusion on this front. :)

i haven't tried to create the new kde live iso with this patch but i tried following steps and verified the thix.

1. run Fedora-KDE-Live-x86_64-26-20170628.n.1.iso un text mode (runlevel 3)
2. rpm -e plasma-pk-updates package
3. systemctl start sddm.service

The software updates icon doesn't show up anymore! problem is fixed.

4. click "Install to Hard Drive" to install the KDE
5. reboot after installation is finish
6. check with "rpm -q plasma-pk-updates package" to see if it's install.
   it's installed

i also read the liveinst codes and don't see how it could affect the final install.

Comment 28 Than Ngo 2017-06-30 15:27:57 UTC
we should recreate kde livecd with the fixed fedora-live-kde-base.ks asap so it can be tested again. Reassign to correct component.

Comment 29 Matthew Miller 2017-06-30 15:34:16 UTC
https://pagure.io/fedora-kickstarts/pull-request/252

Comment 30 Matthew Miller 2017-07-02 16:27:22 UTC
Confirming that plasma-pk-updates is removed on the live media, and the icon with notifications no longer pops up right away. (Although now updates-testing is also properly disabled, so there are not a bunch of pending updates.)

Comment 31 Adam Williamson 2017-07-03 06:06:33 UTC
Matthew: you can use the trick the openQA test uses to make an update available (install an intentionally down-versioned copy of a package; https://fedorapeople.org/groups/qa/openqa-repos/openqa-testrepo-1/ contains such a package for testing). Setting ON_QA as our proposed fix for this was in RC-1.3.

Comment 32 Neal Gompa 2017-07-03 15:31:08 UTC
So then how does it come back on install?

Comment 33 Matthew Miller 2017-07-03 16:09:18 UTC
(In reply to Neal Gompa from comment #32)
> So then how does it come back on install?

I can confirm empirically that it does. In RC 1.3, no applet in live, yes applet after install.

Comment 34 Matthew Miller 2017-07-03 16:10:37 UTC
Also when I enable updates-testing, I get notifications in the installed system, and nothing shows up in the livecd.

Comment 35 Adam Williamson 2017-07-03 17:06:41 UTC
Neal: see the discussion above. The 'removal' of the package happens while the live image is booted; this means it's really only happening in the overlay disk image (which is stored in RAM and lasts only the length of the boot) that allows this kind of 'modification' to the live environment. When you run an install from a live image it does not transfer any modifications made in the live overlay, it installs the clean base image.

Comment 36 Neal Gompa 2017-07-03 20:50:30 UTC
(In reply to Adam Williamson from comment #35)
> Neal: see the discussion above. The 'removal' of the package happens while
> the live image is booted; this means it's really only happening in the
> overlay disk image (which is stored in RAM and lasts only the length of the
> boot) that allows this kind of 'modification' to the live environment. When
> you run an install from a live image it does not transfer any modifications
> made in the live overlay, it installs the clean base image.

Ah okay, cool. Live media is so confusing sometimes. :)

Comment 37 Adam Williamson 2017-07-05 01:14:28 UTC
OK, tested this manually to be sure and I'm pretty happy it's fixed. Definitely no update notification in live mode (and the applet is entirely missing, which is good), and after install it *does* work. Not sure why the openQA test is failing, but I tested manually - clean install, boot to runlevel 3, enable updates-testing, reboot, login, and an update notification appears.

As there's no update that needs pushing for this fix, we can just close it now, I believe.


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