Description of problem: The infamous problem is back. When I install F18 Alpha from DVD, boot it and try to use yum or gpk-application, I "wait in the queue" for a long time. I mean a _really_ long time, like 30 to 60 minutes. There is no information provided what is going on, no details, no progress bar, nothing. Just "waiting in the queue". By using pkmon I managed to find out that software updates from updates-testing are being downloaded in the background. Because I have a very slow Internet, it often takes dozens of minutes (I have no idea whether delta RPMs are being used). The culprit is the new GNOME feature "offline updates" [1] that automatically downloads all system updates in the background and then installs them on system reboot. For the whole time I can't search the package database, change enabled repositories, check for updates, virtually anything. I see two major problems here: 1. gpk-application doesn't inform user what's happening, doesn't show progress bar, doesn't allow user to pause/cancel it. It just says "waiting in the queue". You may easily get the notion that it is stuck/broken. 2. Downloading of updates locks out any other functionality. That seems to be completely unnecessary. It's just downloading files. Why can't I query the database in the mean time? There seems to be superfluous locks in the code. The processing needs to be locked when a) determining what to download b) installing packages; but not when c) downloading the packages. [1] http://fedoraproject.org/wiki/Features/OfflineSystemUpdates Version-Release number of selected component (if applicable): PackageKit-yum-plugin-0.8.3-2.fc18.x86_64 PackageKit-glib-0.8.3-2.fc18.x86_64 PackageKit-device-rebind-0.8.3-2.fc18.x86_64 PackageKit-command-not-found-0.8.3-2.fc18.x86_64 PackageKit-yum-0.8.3-2.fc18.x86_64 gnome-packagekit-3.5.4-1.fc18.x86_64 PackageKit-gtk3-module-0.8.3-2.fc18.x86_64 PackageKit-0.8.3-2.fc18.x86_64 PackageKit-gstreamer-plugin-0.8.3-2.fc18.x86_64 How reproducible: easily Steps to Reproduce: 1. have a slow Internet connection or simulate it 2. install F18 Alpha from DVD 3. you probably also need to import gpg keys to workaround bug 856225 4. wait until "offline updates" kick in - that should be soon. you can use pkmon to monitor progress, but you have to exit it and run again each time to see that different packages are being downloaded. 5. you can't use yum or any packagekit gui tool now, everything is "waiting in the queue" 6. patiently wait dozens of minutes until you can do anything 7. repeat every time new updates are pushed
(In reply to comment #0) > For the whole time I can't search the package database, change enabled > repositories, check for updates, virtually anything. Yes, it's a huge yum problem. In Fedora 15 we've introduced a parallel transaction feature for exactly this use case. Unfortunately yum takes the global lock when doing *anything*, even downloading. If you use a PackageKit backend like aptcc or zif then you can happily search for things and install them while the updates are downloading. As I understand it, the yum maintainers don't want to support a split locking model, so there's not an awful lot we can do. We could automatically cancel the auto-download of updates (although killing yum is very racy) if there is a GUI action, although that seems like working around the problem.
(In reply to comment #1) > although that seems like working around the problem. I've spotted the bug that caused PackageKit not to do this. I forgot we enabled the auto-killing of background stuff by default now, and it was just a bug that stopped it working. I'll do F18 build for testing now.
Is it possible to let yum list all the URLs that it is about to download and then download it inside PackageKit instead? Or use yumdownloader (I think that it doesn't lock the database)? That would solve the issue without auto-killing anything.
(In reply to comment #3) > Is it possible to let yum list all the URLs that it is about to download and > then download it inside PackageKit instead? Or use yumdownloader (I think > that it doesn't lock the database)? That would solve the issue without > auto-killing anything. As I understand it, no, as all the yumDownloader, repo checks and signature checking needs to be done with yum. To download a package yum might need new repodata, which we'll want to cancel anyway. The yum maintainers don't want me to copy-and-paste chunks of yum into PackageKit, so I'm stuck between a rock and a hard place. I'm hoping the yum re-write (the hawkey thing) is going to be a lot more sane. Can you try this build please? http://koji.fedoraproject.org/koji/taskinfo?taskID=4497934 -- it at least fixes the killing logic.
Is there a way to trigger the auto-download feature manually? I lowered the check interval using gsettings, but it doesn't seem to work really well. I would love to execute some command and start the process right away.
(In reply to comment #5) > Is there a way to trigger the auto-download feature manually? I lowered the > check interval using gsettings, but it doesn't seem to work really well. I > would love to execute some command and start the process right away. Yup, see https://gitorious.org/packagekit/packagekit/blobs/master/contrib/systemd-updates/README.txt
I started update download manually, then run gpk-application. Once I run that, downloading stops, but PK gets broken and performs no action at all (neither pkcon nor gpk-application). > [kparal@localhost ~]$ pkcon --only-download --background update > Getting updates [=========================] > Waiting in queue [=========================] > Starting [=========================] > Getting information [=========================] > Updating packages [=========================] > Waiting in queue [=========================] > Starting [=========================] > Running [=========================] > Resolving dependencies [=========================] > Downloading packages [=========================] <<<< HERE I STARTED gpk-application <<<< > Cancelling [=========================] > Updating packages [=========================] > Waiting in queue [=========================] > Starting [=========================] > Fatal error: Failed: failed > [kparal@localhost ~]$ pkcon repo-list > Getting repositories [=========================] > Waiting in queue [=========================] > Starting [=========================] > Fatal error: Failed: failed
Can you try with polkit-0.107-3.fc18, yum-3.4.3-45.fc18 and PackageKit-0.8.4-1.fc18 please -- that should work well and I've been using it here for a few days now.
PackageKit-0.8.4-3.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/PackageKit-0.8.4-3.fc18
Package PackageKit-0.8.4-3.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing PackageKit-0.8.4-3.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-15375/PackageKit-0.8.4-3.fc18 then log in and leave karma (feedback).
I tried with PackageKit-0.8.4-3.fc18 and it seems to work flawless. Background task is cancelled when working in GUI and resumed once I stop working in the GUI. Now I just wish it worked the same with yum... actually, could yum use the same routine and send some signal to PackageKit to release the lock for a while? That would be awesome.
(In reply to comment #11) > Now I just wish it worked the same with yum... actually, could yum use the > same routine and send some signal to PackageKit to release the lock for a > while? That would be awesome. Ah, that's bug 812938, cool - I'll comment there.
The update is stable, closing.