Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Disabling gpk-update-icon on live images not working anymore|
|Product:||[Fedora] Fedora||Reporter:||Jeremy Katz <katzj>|
|Component:||gnome-packagekit||Assignee:||Richard Hughes <rhughes>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||axet, jbgallagher2000, mclasen, rhughes, richard, wwoods|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-10-07 12:36:12 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||438943, 446449, 457945|
Description Jeremy Katz 2008-09-10 16:34:27 EDT
In Fedora 9, by creating ~/.config/autostart/gpk-update-icon.desktop with X-GNOME-Autostart=false, we were able to stop gpk-update-icon from starting on login to the live image (since you generally don't want to apply updates) What's the right way to do this now?
Comment 1 Richard Hughes 2008-09-12 02:39:20 EDT
System->Preferences->Personal->Sessions Untick "PackageKit Update Applet" Does that work? I'm a little unclear how the live cd "works" -- i.e. are you allowwed to make package changes? If there's an environment variable set, I can key of that and not load.
Comment 2 Jeremy Katz 2008-09-12 09:16:47 EDT
That works. So maybe gnome-session has changed what it's looking for matching/validity As for how the live image works, we do some munging at boot time (so that it doesn't persist to the installed system) of gconf keys or desktop files for things like this. And while you could key off of something in the live environment, I've tried to keep it such that packages don't have to make changes, just because they're the sort of things that end up being hacks not acceptable to upstream.
Comment 3 Richard Hughes 2008-09-12 09:46:15 EDT
What are you actuall trying to disable? Wouldn't it just be okay to just set the following to false: /apps/gnome-packagekit/prompt_firmware /apps/gnome-packagekit/notify_available /apps/gnome-packagekit/notify_distro_upgrades and set to "never": /apps/gnome-packagekit/frequency_get_updates /apps/gnome-packagekit/frequency_get_upgrades /apps/gnome-packagekit/frequency_refresh_cache This way the applet will still be running (and show some UI if the user tries to install anything) but won't actually try to do anything by itself. Richard.
Comment 4 Jeremy Katz 2008-09-12 10:06:22 EDT
That's fine if it works now -- it didn't in the lead-up to F9 and so switching to just not starting was suggested in that discussion I'll try setting them when I can actually build an image again (inconsistent rawhide repo currently) and let you know
Comment 5 Richard Hughes 2008-09-12 11:12:29 EDT
If it does stuff with those keys set, open a bug and I give you permissions to use all CAPS in the subject line :-) I'll fix that sort of bug pretty quick, but I think all the time based ones are fixed now.
Comment 6 Jeremy Katz 2008-09-14 16:05:08 EDT
I'm still seeing metadata being downloaded when the network connection becomes available, which I wouldn't necessarily expect. This basically means a hit of 30+ megs of "memory" usage by the RAM-based r/w disk overlay. I don't seem to be getting notified, though, which is good :-)
Comment 7 Matthias Clasen 2008-10-01 21:10:34 EDT
When you uncheck the packagekit icon in the session capplet, it writes a desktop file hust like you describe, in ~/.local/share/autostart/gpk-update-icon.desktop with the line X-GNOME-Autostart-enabled=false so your F9 code should still work.
Comment 8 Jeremy Katz 2008-10-01 21:15:24 EDT
Ah, but ~/.local/share/autostart is different than ~/.config/autostart -- which is correct? Also, I'm not sure if we really want it in the gdm session in general
Comment 9 Matthias Clasen 2008-10-01 22:16:16 EDT
Ah, sorry. I have that mixed up. It actually is ~/.config/autostart As for the gdm session (ie the login screen), that is controlled by /usr/share/gdm/autostart/LoginWindow and doesn't include gpk-update-icon
Comment 10 Jeremy Katz 2008-10-01 23:17:59 EDT
Something is clearly a little off then.. it wasn't working a few weeks ago. May have been due to other gnome-session problems at the time. Definitely worth building some images with current rawhide and checking again
Comment 11 Matthias Clasen 2008-10-02 10:58:32 EDT
But where is the code to turn of gpk-update-icon ? I don't see it in fedora-livecd-desktop.ks in the spin-kickstarts repo
Comment 12 Jeremy Katz 2008-10-02 11:10:31 EDT
It's in fedora-live-base.ks
Comment 13 Matthias Clasen 2008-10-02 12:40:54 EDT
No, thats code that modifies pk defaults - in a questionable way, if I may say so, since that will cause the same settings to go in the installation, no ? The code to write an autostart desktop file for gpk-update-icon is not there anymore
Comment 14 Jeremy Katz 2008-10-02 13:04:08 EDT
No, it's done in the initscript and the install copies over the pristine image without any changes that were made. And the code to write the autostart file got pulled out when hughsie above said that it wasn't the way he'd suggest doing it.
Comment 15 J Gallagher 2008-10-03 03:45:41 EDT
PackageKit should NOT be notifying updates to the user in the LiveCD. In Fedora 10 Beta LiveCD (Gnome) it notifies me of 331 pending updates. That is ridiculous (and potentially harmful if you have a persistence overlay enabled since such a large update will usually corrupt the overlay) This needs urgent fixing before preview release.
Comment 16 Matthias Clasen 2008-10-03 13:45:24 EDT
Created attachment 319396 [details] pk getting active on a livecd of todays rawhide
Comment 17 Matthias Clasen 2008-10-03 14:19:56 EDT
Created attachment 319401 [details] gconf settings Maybe some of those enable_ settings should be false ?
Comment 18 Matthias Clasen 2008-10-03 14:20:59 EDT
Also, can I point out here that showing that firmware path in the ui is really bad form ?
Comment 19 Jeremy Katz 2008-10-06 09:42:27 EDT
*** Bug 465678 has been marked as a duplicate of this bug. ***
Comment 20 Matthias Clasen 2008-10-07 12:36:12 EDT
Should be fixed in the current .ks files, by setting more gconf keys.
Comment 21 Richard Hughes 2008-10-10 13:27:46 EDT
Another fix built as http://koji.fedoraproject.org/koji/taskinfo?taskID=873534 -- in rawhide tomorrow.