Bug 461825

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.

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.

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.

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

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.

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

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.

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

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

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

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

It's in fedora-live-base.ks

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

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.

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.

Created attachment 319396 [details]
pk getting active on a livecd of todays rawhide

Created attachment 319401 [details]
gconf settings 

Maybe some of those enable_ settings should be false ?

Also, can I point out here that showing that firmware path in the ui is really bad form ?

*** Bug 465678 has been marked as a duplicate of this bug. ***

Should be fixed in the current .ks files, by setting more gconf keys.

Another fix built as http://koji.fedoraproject.org/koji/taskinfo?taskID=873534 -- in rawhide tomorrow.