Description of problem:
If I select just a single package to update (leaving all the other packages unchecked) and hit Install Updates, the one update is correctly downloaded and installed, but after that the window refreshes to be completely blank. The remaining list of updates is not shown. If I quit the application and run it again, the progress bar is forever stuck in "waiting" mode and no updates are displayed. You have to reboot the whole computer for gpk-update-viewer to start working again. I have reproduced this problem several times in a row. Screenshot is attached to see the "stuck" gpk-update-viewer.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. get a large list of updates, e.g. enable updates-testing
2. run gpk-update-viewer
3. select just one update, install it
4. see that the list will be empty after that
5. quit application, start it again
6. see that it is waiting forever
Created attachment 585162 [details]
pkmon output is displayed in the terminal
Let's discuss whether this is a blocker. I have waited at least 10 minutes and the PK didn't get unstuck. Reboot seems truly necessary.
"The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
Reproduced precisely as described. Note that when PK finishes installing the single update and refreshes to a blank grey update list, it still claims that one update is selected. When you quit and re-run, it's stuck as Kamil describes, it doesn't claim any updates are selected.
Fedora Bugzappers volunteer triage team
Discussed at the 2012-05-17 Fedora 17 final go/no-go meeting. This doesn't completely hit any of the Fedora 17 release criteria and has a simple workaround - install all of the updates. Thus it can be fixed by an update and does not need to block release. However, it does cause problems with certain update use cases and would be considered for freeze break. Separate patches and/or builds for the different PK issues are requested so that they can be evaluated individually.
I have done a clean F17 RC1 installation. Then I have downgraded two packages (gedit and shotwell) by downloading older build from koji. Then I used gpk-update-viewer to update one of those packages. The the second one. Surprisingly, everything worked perfect. After that I followed the original reproducer (enable updates-testing and select one package) and it got stuck again. So this is not deterministic, it might depend on the current state of repositories and state of the update set.
I wonder whether there is a use case we haven't considered when deciding blocker-ness. Maybe PK will get stuck even if we update all available packages, and then after a day or two another set of updates appears (some people don't reboot, just suspend, so it would be the same session). But this is hard to test - as I said, the issue is not deterministic.
When I was testing the PackageKit builds for #794927, PackageKit stalled when I had all of the builds from updates-testing selected for updates. I started the updates, imported the needed keys and PK stalled about halfway through.
We still don't know how often this is going to happen but with the new information, I'm moving this back to proposed.
Discussed in the 2012-05-18 blocker bug review meeting. Rejected as a blocker for Fedora 17 final because while this could be a problem - there is only one reporter of a blocker-worthy issue and there is no debug information to work off of.
Kamil, did you ever reproduce this again? Seems like we could close it out as CLOSED MAGICPIXIESINMYBOX....
I have tested it in F18 and it works well, let's just close.