Bug 492005

Created attachment 336566 [details]
Screenshot 1

Created attachment 336567 [details]
Screenshot 2

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

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

Also see http://bugs.freedesktop.org/show_bug.cgi?id=20559 where we're doing more debugging.

Does this only happen when you update all the updates, rather than just installing one or two? Also, what method did you use to update, the update viewer of the tray icon?

If you can give me _exact_ (insane detail) about how to reproduce this then I would very much appreciate it, at the moment I'm out of ideas.

Hmmm... I'm very much sure I started the update app manually before updates where shown in the tray and then updated all using this window. I think the tray icon shows up as soon as the update list is downloaded in the updater window, does this make sense?

I will report back if I can reproduce this with the next round of updates and give more details.

Okay, I've spent the morning looking through some debugging traces, as I managed to reproduce this. Oddly, it only seems to happen when I install all pending updates using the yum backend, rather than when using other backends, although the fix is in gnome-packagekit (backend neutral). It must be some sort of timing race.

Could you please try out the packages here: http://www.packagekit.org/packages/ and tell me if this fixes the issue.

a) "Update System" starts the old updater
b) even after updates are found, no tray icon shows up to indicate this

Can you try todays packages please (same location). Thanks.

I think this is now fixed, though I don't really understand when the update tray icon is supposed to show up now.

This is still happening.

On rawhide, I see the icon show (correctly) that there are new updates for the daily compose.  I update, and the icon goes away for the time being.  However, I have PK set to check for updates every hour.  The _next_ time it checks (ie in an hour), the icon comes back up showing that I have N updates available (where N was the number of packages I just updated).  Show Updates yields the same thing as the attachments.

We really should get this sorted for F11.

I have also seen the original issue happen about 2 days ago, e.g. the update icon was still visible after applying all updates. I would love to give better information on how to reproduce, but it just seems to happen sometimes :/

Is this now fixed with the latest rawhide? Thanks.

I still see this, with 
gnome-packagekit-2.27.2-0.2.20090414git
PackageKit-0.4.6-4.fc11

Icon shows up, claims 6 updates available, click to start update-viewer, but it finds no updates.

It's like when the program notices that there are no updates, that it doesn't try to remove the icon.

It's still broken for me too.

I found the problem, and it's taken me about 2 hours to debug. What happens is:

When PK does a successful UpdatePackages or UpdateSystem method, it emits an updates-changed signal to all connected clients, so they request a GetUpdates call and refresh their UI. This was tested to work with the dummy backend, and PK and g-p-k passed all their self tests. It also worked with the yum backend, but wasn't reliable, and the problem could be semi-reliably reproduced by installing _all_ the updates from rawhide at once, rather than cherry-picking.

Now, PK installs a yum plugin, refresh-packagekit, which is supposed to be run after the user has run tools like yum-cli, pirut and yumex. This plugin sends a dbus message to PackageKit, telling it that other tools are active, and that it's internal caches are invalid. It also gets the daemon to emit the updates-changed signal if updates list has changed. This ensures that users that use PK and the legacy tools don't get a confused PK.

Now, when PK runs yum to do UpdatePackages or UpdateSystem it loads all the default plugins. This INCLUDED refresh-packagekit. This meant that the plugin was sending a message for PK to dump it's cache and send updates-changed, and then the daemon was sending it's own updates-changed a few ms later. The spec only allows one updates-changed signal per foreign transaction at the END of the transaction.

The first updates-changed signal was causing the clients to get the new update list, and the second was causing the clients to cancel the first, and reschedule a second check. But in that window there was a race where the incorrect data would be sent before the cancel (as the daemon had not yet dropped it's caches).

So, the fix was simple: Don't load refresh-packagekit in the yumBackend. This is simply a case of adding refresh-packagekit to disabled_plugins before we initialise yum. This fixes the problem for me.

I'll do F11 build now.

Could you please try: http://koji.fedoraproject.org/koji/taskinfo?taskID=1318633

If this works, I'll ask for tags. Thanks.

I've requested a tag here: https://fedorahosted.org/rel-eng/ticket/1628

Thanks for the bug fix and the info on how it was broken. Appreciate it.

I can still see this issue with PK 0.4.6-8.

I updated fully. One hour later, PK searched for new updates and is now displaying the tray icon. If I click on it to view updates, it says no updates are available.

I can't reopen the bug report though :-/

Ok, given the explaination in #17, this must also be triggered by another thing. I also just got the icon back after applying updates, telling me the same 22 (?) updates are available. Reopening.

Created attachment 341884 [details]
Update history

This screenshot shows my update history. Notice that no PK packages were updated.

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

Adding flag fedora_requires_release_note to track getting this on the Fedora 11 Release Notes.

I can't reproduce this. Is anybody able to reliably reproduce this, and are able to give precise instructions?

Can somebody get the output of "dbus-monitor --system" and "pkmon --verbose" when this happens please?

Also, the output from "killall gpk-update-icon && gpk-update-icon --verbose" would be really good. Thanks.

Steps to reproduce:
System>Preferences>Software Updates
Set to HOURLY
downgrade some stuff
check for updates
update
WAIT ONE HOUR
icon comes back erroneously.


Same happens if you have it daily, but you wait one day.

I can see this a well.

On Fedora Rawhide x86-64 (updated from Beta to yesterday):

(in Gnome)
Icon does not show, but  even if updates are available (as per yum and yum extender ...with almost all plugins), gpk-update-viewer says it is otherwise.
More than 5 updates are available
 
I also get the following traceback 

gpk-update-viewer
 
File "/usr/lib/python2.6/site-packages/yum/repos.py", line 79, in doSetup
    self.ayum.plugins.run('postreposetup')
  File "/usr/lib/python2.6/site-packages/yum/plugins.py", line 179, in run
    func(conduitcls(self, self.base, conf, **kwargs))
  File "/usr/lib/yum-plugins/rpm-warm-cache.py", line 32, in postreposetup_hook
    cmd = commands[0]
TypeError: 'NoneType' object is unsubscriptable
______________________


pkmon


TI:23:02:24	FI:egg-debug.c	FN:egg_debug_init,304
 - Verbose debugging 1 (on console 1)PK_VERBOSE
TI:23:02:24	FI:pk-monitor.c	FN:main,161
 - connected=1
TI:23:02:24	FI:pk-monitor.c	FN:main,178
 - refreshing task list
TI:23:02:24	FI:pk-task-list.c	FN:pk_task_list_print,94
 - Tasks:
[none]...
State:


____________________

#gpk-update-icon --verbose

Nothing happens

The icon cannot be called from konsole/terminal in Gnome

______________________


I also got an error with kpackagekit

It does NOT ASK FOR Super-User Password unlike Yum Extender

Plus See attachment

Created attachment 344049 [details]
kpackagekit error

A. Mani -- re: comments #29 and #30, you are looking at a different problem.  Please file that as a separate bug.  This bug concerns the specific bug about the tray icon sticking around after a successful update.

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

Filed it as a new bug

https://bugzilla.redhat.com/show_bug.cgi?id=500923

Still not fixed in Fedora 11 Release Candidate. Please change Version to F-11.

Created attachment 344107 [details]
dbus-monitor --system and pkmon --verbose output

This is the output of dbus-monitor --system and pkmon --verbose as demanded in #26. It starts when the update icon appeared for the first time. It contains the 'real' update, a one hour of waiting (that is, a lot of noise). When the icon appeared for the second time, I started gpk-update-viewer again, get 'no updates'. Then the log ends.

(In reply to comment #35)
> Created an attachment (id=344107) [details]
> dbus-monitor --system and pkmon --verbose output

Thanks for that. According to that log (whew!), the daemon is doing exactly the correct thing, which is expected as I found and fixed the bug found in comment 17.

There looks to be a client problem, possible in the PkClient or GpkCheckUpdate objects. I'll hunt now.

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

Could you all try these packages please: http://koji.fedoraproject.org/koji/taskinfo?taskID=1355881

Thanks.

(In reply to comment #38)
> Could you all try these packages please:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1355881

Does not seem to help, still the same behaviour. 

~ $  rpm -q gnome-packagekit 
gnome-packagekit-2.27.2-0.1052.20090515git.fc11.x86_64

Jiri, can you try with a new PackageKit from http://koji.fedoraproject.org/koji/taskinfo?taskID=1356621 -- thanks.

The same. The only difference was that the real update ended by 'getting informations/files?' (I do not remember exactly), i.e. at the end of the update quite huge amount of data was downloaded.

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

(In reply to comment #41)
> The same.

Can you try setting /etc/PackageKit/PackageKit.conf to have "UseUpdateCache=false" please. This turns of all the caching in the dameon.

(In reply to comment #40)
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1356621 -- thanks.  

This has fixed it for me, Icon comes and goes.
Tried running "yum update" manually to fool it,
still comes and goes :)

rhughes:  Is the PackageKit.conf "UseUpdateCache=false" recommendation an official fix due out in updated packages?  Or are you recommending this as a workaround for users affected?

FYI, rhughes is on a honeymoon trip for a couple of weeks IIRC. So I guess, we need to document the workaround if this actually works.

(In reply to comment #40)
> Jiri, can you try with a new PackageKit from
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1356621 -- thanks.

I can also confirm that these packages don't fix the problem here, not even when used with gnome-packagekit from comment #38.

I tried with updates from comment #40 and comment #38 and with
UseUpdateCache=false and I am still getting the orange sun icon approx. one
hour after I did the update. The tooltip says that there is the same number of
updates as before and when I start the update, I get "there are no more
updates". I.e., nothing changed. Moreover, as I described in comment #41, huge
amount of data is downloaded at the end of the 'real' update. 

Hence, at least for me "UseUpdateCache=false" does not look like a solution.
Moreover, the description of this option in the /etc/PackageKit/PackageKit.conf
does not look like something that should be suggested as a workaround.

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

(In reply to comment #48)
> Hence, at least for me "UseUpdateCache=false" does not look like a solution.
> Moreover, the description of this option in the /etc/PackageKit/PackageKit.conf
> does not look like something that should be suggested as a workaround.  

I agree. That shouldn't of fixed it, it's the result of me banging my head against a wall trying to work out where the bug can be. I'm going to do some more detailed code review in the client now, and try to find the root cause.

(In reply to comment #41)
> at the end of the update quite huge amount of data was downloaded.  

commit 5ad07501de1ab98e683f06505d5bd5db868e1414
Author: Richard Hughes <richard>
Date:   Wed May 27 09:18:01 2009 +0100

    When we search for the file list after an install or upgrade, use the local package not the remote package else we might start downloading remote package lists

:100644 100644 0026169... 9144ebb... M  src/pk-transaction.c

Maybe a long shot, but does turning off NetworkManager fix things?

(In reply to comment #51)
> (In reply to comment #41)
> > at the end of the update quite huge amount of data was downloaded.  
> 
> commit 5ad07501de1ab98e683f06505d5bd5db868e1414
> Author: Richard Hughes <richard>
> Date:   Wed May 27 09:18:01 2009 +0100
> 
>     When we search for the file list after an install or upgrade, use the local
> package not the remote package else we might start downloading remote package
> lists
> 
> :100644 100644 0026169... 9144ebb... M  src/pk-transaction.c  

There's a test package here to fix this specific issue if you're interested in testing:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1379550

(In reply to comment #50)
>I'm going to do some more detailed code review in the client now, and try
>to find the root cause.  

Can you try the builds here please: http://koji.fedoraproject.org/koji/taskinfo?taskID=1379557

This should fix things once-and-for-all

Thanks.

Yes, the new packages fixes it here.

Confirmed fixed (tested with taskID=1379550 only then with addition of taskID=1379557 on a i686PAE Gnome desktop)
The installation of a package went fine, then an icon appeared (refresh-apckagekit) then disappeared few seconds later...

Looks good here too.

(In reply to comment #57)
> Looks good here too.  

I've updated PackageKit packages to those suggested in comment#54.  Since then I've updated to today's updates.  After updating, I performed several yum cli queries (enough to trigger the refresh-packagekit plugin).  The reported issue appears to be resolved

Sorry, premature results.  Since my previous post, it appears that the gpk-update-icon has re-appeared suggesting updates.  Clicking on the icon again shows that no updates are available.

# rpm -qa PackageKit*
PackageKit-gstreamer-plugin-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-glib-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-yum-plugin-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-yum-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-gtk-module-0.4.8-0.1228.20090527git.fc11.i586

(In reply to comment #59)
...
> # rpm -qa PackageKit*
And what about the gnome-packagekit* ones from taskID=1379557 ?

(In reply to comment #57)
> Looks good here too.  

Works for me too.

(In reply to comment #60)
> > # rpm -qa PackageKit*
> And what about the gnome-packagekit* ones from taskID=1379557 ?  

Thanks, I missed both builds (PackageKit and gnome-packagekit).  Retesting and haven't seen it today yet using the following:
 * PackageKit-0.4.8-0.1228.20090527git.fc11.i586
 * gnome-packagekit-2.27.2-0.1056.20090527git.fc11.i586

Can you please push the builds to updates-testing at least?

(In reply to comment #63)
> Can you please push the builds to updates-testing at least?  

There's an upstream release scheduled to happen in three days time -- when that happens I'll upload new gnome-packagekit and PackageKit rpms to updates testing, and after a few days push to stable so it can happen as a zero day update.

Sorry have the bad news:
Have the "All software is up to date"
 
PackageKit-gtk-module-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-debuginfo-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-qt-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-yum-plugin-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-browser-plugin-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-ruck-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-glib-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-gstreamer-plugin-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-yum-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-0.4.8-0.1228.20090527git.fc11.i586
PackageKit-command-not-found-0.4.8-0.1228.20090527git.fc11.i586
gnome-packagekit-debuginfo-2.27.2-0.1052.20090515git.fc11.i586
gnome-packagekit-2.27.2-0.2.20090414git.fc11.i586


Then another "Downloading lists" process started.
Then a "No package cache available" backend should have done this.
too quick to get exact message.
Nothing relevant in dmesg | tail\ and or log viewer

(In reply to comment #65)
> Sorry have the bad news:
> Have the "All software is up to date"

Did you reboot after installing the packages? Can you describe exactly what bug you are seeing and the steps to do it please? Thanks.

(In reply to comment #66)
> (In reply to comment #65)
> > Sorry have the bad news:
> > Have the "All software is up to date"
> 
> Did you reboot after installing the packages? 

Not immediatly, not until after got 
https://bugzilla.redhat.com/show_bug.cgi?id=492005#c65

Can you describe exactly what bug

Just as in my comments, exact Window was too fast to read perfectly

> you are seeing and the steps to do it please? Thanks.  

Updated via pk
ay 29 08:19:38 Updated: ibus-libs-1.1.0.20090508-5.fc11.i586
May 29 08:19:39 Updated: 32:bind-libs-9.6.1-0.4.rc1.fc11.i586
May 29 08:19:39 Updated: 32:bind-utils-9.6.1-0.4.rc1.fc11.i586
May 29 08:19:40 Updated: fedora-setup-keyboard-0.4-2.fc11.i586
May 29 08:19:40 Updated: ksysguardd-4.2.3-5.fc11.i586
May 29 08:19:41 Updated: preupgrade-1.1.0-1.fc11.noarch
May 29 08:19:41 Updated: ibus-gtk-1.1.0.20090508-5.fc11.i586
May 29 08:19:54 Updated: ibus-1.1.0.20090508-5.fc11.i586

and a yum localinstall
May 29 09:05:27 Installed: kompozer-0.8a3-2.fc10.i386

Have now rebooted after about 1.30 minutes, PK set to check hourly.

Ok, an hour has now  passed since reboot, pk icon has come and gone.

I am still seeing this behaviour on my box. tray icon shows updates available when there is none.

[ravis@localhost ~]$ rpm -qa | grep Pack
PackageKit-gstreamer-plugin-0.4.6-8.fc11.x86_64
PackageKit-yum-plugin-0.4.6-8.fc11.x86_64
PackageKit-0.4.6-8.fc11.x86_64
PackageKit-glib-0.4.6-8.fc11.x86_64
PackageKit-yum-0.4.6-8.fc11.x86_64
PackageKit-gtk-module-0.4.6-8.fc11.x86_64

(In reply to comment #69)
> I am still seeing this behaviour on my box. tray icon shows updates available
> when there is none.
> 
> [ravis@localhost ~]$ rpm -qa | grep Pack
> PackageKit-gstreamer-plugin-0.4.6-8.fc11.x86_64
> PackageKit-yum-plugin-0.4.6-8.fc11.x86_64
> PackageKit-0.4.6-8.fc11.x86_64
> PackageKit-glib-0.4.6-8.fc11.x86_64
> PackageKit-yum-0.4.6-8.fc11.x86_64
> PackageKit-gtk-module-0.4.6-8.fc11.x86_64  

Have you got gnome-packagekit* from:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1379557

Which I also missed.

Frank

gnome-packagekit-2.27.2-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/gnome-packagekit-2.27.2-1.fc11

gnome-packagekit-2.27.2-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gnome-packagekit'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-5748

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

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

gnome-packagekit-2.27.2-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Running F11 x86, my update icon no longer shows up at all, not for new packages, not during package searches/installs/etc. I don't know if it is related to this bug or not but its bothersome. PackageKit version 4.8.1

Regarding comment #76, same here.

(In reply to comment #76)
> Running F11 x86, my update icon no longer shows up at all, not for new
> packages, not during package searches/installs/etc. I don't know if it is
> related to this bug or not but its bothersome. PackageKit version 4.8.1  

By default we are hiding the icon where the calling application is still open. This means if you open gpk-update-viewer, and then start an update, the icon will not show as you can cancel the transaction in the update viewer UI. If you do a killall gpk-update-viewer, the icon will reappear, and you can get the generic progress window with the cancel buttons.

If you don't like this preference, and want an icon for every transaction, just set the GConf key /apps/gnome-packagekit/update-icon/watch_active_transactions to true, in todays rawhide.

This is still happening for me in Rawhide.

PackageKit-0.5.1-0.1.20090727git.fc12.x86_64
gnome-packagekit-2.27.4-0.1.20090727git.fc12.x86_64

The update icon reported 1311 packages to update last night.  There were a few broken deps so I had to update via yum (the refresh-packagekit plugin is installed for yum, btw) and pass --skip-broken.  Several hours after updating, the gnome PK icon still reports 1311 packages to update, even though it's only a small handful of packages were skipped.