Bug 1411689 - PackageKit-command-not-found queries disabled repos
Summary: PackageKit-command-not-found queries disabled repos
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 25
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-10 10:02 UTC by Devin Henderson
Modified: 2017-01-10 10:14 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-01-10 10:11:19 UTC
Type: Bug

Attachments (Terms of Use)

Description Devin Henderson 2017-01-10 10:02:04 UTC
Description of problem:

I had several Copr .repo files with enabled=0 that are dead repos and produce 404 errors when queried. PackageKit-command-not-found was taking very long and I realized it was because it was querying these disabled repos every time and getting "cannot update repo. All mirrors were tried" errors.

For example: https://paste.fedoraproject.org/524964/42449148/raw/

Expected Results:

Don't try to query repos that are disabled.

Comment 1 Devin Henderson 2017-01-10 10:03:11 UTC
My installed PackageKit version:

Installed Packages
PackageKit.x86_64                         1.1.5-0.1.20161221.fc25       @updates
PackageKit-Qt.x86_64                      0.9.5-6.fc24                  @System 
PackageKit-Qt5.x86_64                     0.9.5-6.fc24                  @System 
PackageKit-command-not-found.x86_64       1.1.5-0.1.20161221.fc25       @updates
PackageKit-glib.i686                      1.1.5-0.1.20161221.fc25       @updates
PackageKit-glib.x86_64                    1.1.5-0.1.20161221.fc25       @updates
PackageKit-gstreamer-plugin.x86_64        1.1.5-0.1.20161221.fc25       @updates
PackageKit-gtk3-module.i686               1.1.5-0.1.20161221.fc25       @updates
PackageKit-gtk3-module.x86_64             1.1.5-0.1.20161221.fc25       @updates

Comment 2 Kalev Lember 2017-01-10 10:03:47 UTC
Do they have enabled_metadata=1 set?

Comment 3 Devin Henderson 2017-01-10 10:09:18 UTC
Yeah, it looks like enabled_metadata=1 was probably set in them. Is changing that the solution? It also just occurred to me that maybe this is desired behavior and when the missing command is found in a disabled repo packagekit could offer to enable the repo and install the package which sounds reasonable. My only problem was that the dead repos were causing command-not-found to take a really long time to run so I just deleted the .repo files.


Comment 4 Kalev Lember 2017-01-10 10:11:19 UTC
Right, PackageKit looks at both enabled=1 and enabled_metadata=1 repos so that it could offer to enable the repo if it finds a match in there. Deleting sounds like a good way to solve this :) Setting enabled_metadata to 0 would also fix it.

Comment 5 Devin Henderson 2017-01-10 10:14:13 UTC
Thanks for the info!

Note You need to log in before you can comment on or make changes to this bug.