Bug 1188600

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