Description of problem: Since update to librepo-1.7.13-1.fc21, packagekit doesn't work, both pkcon and gnome-software. Which in turn means offline updates don't work. Which means there's no GUI method of fixing this. I see this: $ pkcon update devassistant Resolving [=========================] Loading cache [=========================] Testing changes [=========================] Finished [=========================] Updating packages [=========================] Querying [=========================] Finished [=========================] Fatal error: cannot download d/devassistant-0.9.3-4.fc21.noarch.rpm to /var/cache/PackageKit/metadata/updates/packages/: Cannot download d/devassistant-0.9.3-4.fc21.noarch.rpm: All mirrors were tried I test with devassistant, but insert any package you wish, or just no argument for full system update. Always the same problem. Confirmed by several people, including Richard Hughes, the PackageKit maintainer. Yum and DNF are not affected. If I downgrade to librepo-1.7.11-1.fc21.x86_64, everything works fine. Version-Release number of selected component (if applicable): librepo-1.7.13-1.fc21 PackageKit-1.0.4-1.fc21.x86_64 libhif-0.1.8-1.fc21.x86_64 How reproducible: seems always Steps to Reproduce: 1. update to librepo-1.7.13-1.fc21 2. try to update some package using gnome-software or pkcon 3. see the "All mirrors were tried" error
Hi, TL;DR version: -------------- Librepo tries to get packages only from a local cache - because it's set to work only locally (LRO_LOCAL option is enabled). Long version: ------------- Libhif loads a local repodata from cache with a librepo handle that has LRO_LOCAL option set to True. With this option enabled, librepo doesn't download remote mirrorlist/metalink and internal librepo mirrorlist contains only one URL (the local path to the cache). Then, when the handle is used for downloading of packages, handle's internal mirrorlist contains only one item that is cached version of the repodata and the downloading cannot be successful. Solution for the current version of librepo (in F21) is: -------------------------------------------------------- * Do not specify mirrorlist when only local cached metadata should be loaded. * (Internal list of mirrors containing only the local path is created) * Load the metadata (lr_handle_perform()) * Disable the LRO_LOCAL option * Set a mirrorlist to the handle * (New internal list of mirrorlis is generated) * Download packages Current upstream librepo version (the one in a git) also resets internal list of mirrors when the LRO_LOCAL is changed, but the version currently available in Fedora don't do that - thus the mirrorlist must be set (or re-set) after the LRO_LOCAL is changed.
According to Tomas, this is broken in Rawhide as well. <hughsie> tmlcoch, does librepo from master work with PackageKit? <tmlcoch> hughsie, no it doesn't work. It seems that you tries to download packages with handle that has LRO_LOCAL enabled - in this case, librepo doesn't download remote metalinks/mirrorlists (https://github.com/Tojaj/librepo/issues/41). Proposing as a blocker: "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops. " https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Updates
This new libhif-0.1.8-2.fc21 build fixes the problem for me in F21: http://koji.fedoraproject.org/koji/taskinfo?taskID=8809683
libhif-0.1.8-3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/libhif-0.1.8-3.fc21
Package libhif-0.1.8-4.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libhif-0.1.8-4.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-1644/libhif-0.1.8-4.fc21 then log in and leave karma (feedback).
libhif-0.1.8-4.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1178259 has been marked as a duplicate of this bug. ***
Hi, Nice to see this report closed ;-) But with libhif-0.1.8-4.fc21.x86_64 apper is doing absolutely nothing. Apper Monitor - in service manager - is running. No notifications of any updates. Checking Updates from within apper (Updates -> Check for new updates) 'just' updates the verification time. The following message appear: void PackageModel::clear() void PackageModel::finished() PackageKit::Transaction(0xcf25b0) PackageKit::Transaction(0xcf25b0) I don't think this is the intention of apper. Martin Kho
Hi Martin, could you please try to provide any additional information? Related log entries from journald (command: journalctl) etc. Maybe also open a new bug against Apper.
Hi Tomas, I'd love to, but I get no information from anyware. From journalctl I only see every 3 hours or so dnf updating it's cache. What I've found is that PackageKit is never activated (I've tried to set updates checking to one hour). pkcon get-check keeps telling me that 'There are no updates available at this time.', until I run a "refesh force". Now it finds new updates. Then, also apper is happy telling me that there are updates. My conclusion is that somewhere in the beginning of the chain (PackageKit - libhif - apper) something is going wrong. HTH, Martin Kho
I see, in that case I cannot help you directly and since this bug is opened against librepo, which is the very last part of your package management stack (Apper - PackageKit - libhif - librepo) and because it seems that the problem appeared after libhif update and because the bug is originally related to broken offline updates in Gnome Software, could you please open a new bug against PackageKit or libhif to get this (new) bug tracked properly? Thanks Tomas
Okay thanks, I was afraid of that. It's rather unbelievable that a 'new' feature can have such disastreus consequenses...but it's not new. We get used to it ;-) Martin Kho