Bug 634956
Summary: | repoquery shouldn't traceback when it can't contact a repo | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ruggero <giurrero> | ||||
Component: | yum-utils | Assignee: | Seth Vidal <skvidal> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 13 | CC: | dan, dbn.lists, james.antill, mads, maxamillion, mihai, notting, pmatilai, poc, tim.lauridsen, vondruch | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | abrt_hash:dc8d095c | ||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2011-06-28 12:42:57 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Ruggero
2010-09-17 12:41:46 UTC
Created attachment 447997 [details]
File: backtrace
I thought this was fixed in newer versions of yum, what version of yum do you have? yum --version yum --version 3.2.28 Installato: rpm-4.8.1-2.fc13.x86_64 da 2010-07-09 08:48 Build : Fedora Project su 2010-06-30 10:41 Committed: Panu Matilainen <pmatilai> su 2010-06-30 Installato: yum-3.2.28-3.fc13.noarch da 2010-08-23 09:32 Build : Fedora Project su 2010-08-12 16:35 Committed: Seth Vidal <skvidal at fedoraproject.org> su 2010-08-12 Ok, I guess not then :(. I'll get that changed now so it doesn't traceback. To solve your problem though, if you didn't know, you can run: yum-config-manager --disable chromium Package: yum-utils-1.1.28-1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Ran 'repoquery -qR dracut-network' (as a user) 2. No, not sure what the state of the local cache is. Package: yum-utils-1.1.28-1.fc13 Architecture: x86_64 OS Release: Fedora release 13 (Goddard) How to reproduce ----- 1. repoquery -l boost-devel 2. error looking for repo 3. crash Comment ----- I was running repoquery and it crashed after reporting an error getting the livna mirrorlist. I think the livna issue is legitimate, but yum dealt with it. I guess repoquery probably couldn't handle that situation. Package: yum-utils-1.1.28-1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1.ran: repoquery --info [Oo]ffline[Ii]map 2.yum crashed with traceback 3. Comment ----- Run repoquery --info [Oo]ffline[Ii]map As noted in earlier comments, the Chromium repo was enabled but fails as it's currently is not available for F14. IMHO this is in itself a bug. Yum should warn about failing repos and continue instead of bailing. You can add skip_if_unavailable=true, to your chromium repo. config. Good to know, thanks. I do think this should be the default all the same (i.e. the option should be "fail_if_unavailable", default false). Package: yum-utils-1.1.28-1.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Install suspend2 repo from http://mhensler.de/swsusp/download/suspend2.repo 2. Make sure it points to a non-existent repo (404 Not Found) 3. Issue repoquery --repoid suspend2 -a Comment ----- suspend2 is not yet available for Fedora 14 (404 Not Found). The above command resulted in crash. Patrick, It's a policy decision to opt to abort if a repo is unavailable by default. We've made it an option the user can set now. If you choose to do that go right ahead. However, I do not think it is a bug that we've intentionally selected a policy different from what you may choose for your own systems. Thanks. Mihai, the bug you're seeing has been fixed upstream. with this patch, I think http://yum.baseurl.org/gitweb?p=yum-utils.git;a=commitdiff;h=d37a4dba3793efa1ba70d7c9d354db4990b62efd (In reply to comment #12) > Mihai, > the bug you're seeing has been fixed upstream. > > with this patch, I think > http://yum.baseurl.org/gitweb?p=yum-utils.git;a=commitdiff;h=d37a4dba3793efa1ba70d7c9d354db4990b62efd Excellent, thanks! (In reply to comment #12) > Patrick, > It's a policy decision to opt to abort if a repo is unavailable by default. > We've made it an option the user can set now. If you choose to do that go right > ahead. However, I do not think it is a bug that we've intentionally selected a > policy different from what you may choose for your own systems. As I said, my opinion is that a warning would suffice, but it's not a big deal. Package: yum-utils-1.1.28-1.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) Comment ----- Failing with the nice message is ok, but it shouldn't show a stacktrace (In reply to comment #15) > Package: yum-utils-1.1.28-1.fc14 > Architecture: i686 > OS Release: Fedora release 14 (Laughlin) > > > Comment > ----- > Failing with the nice message is ok, but it shouldn't show a stacktrace Agreed. Also, the nice message could mention the skip_if_unavailable config option as a hint to the user. Package: yum-utils-1.1.28-1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. repoquery --alldeps --archlist=src --tree-whatrequires rubygem-sqlite3-ruby Package: yum-utils-1.1.28-1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Run boxgrinder command: repoquery --quiet --disablerepo=* --enablerepo=boxgrinder-fedora-14-base,boxgrinder-fedora-14-updates,boxgrinder-postgresql -c 'build/appliances/x86_64/fedora/14/mimic2/fedora-plugin/tmp/yum.conf' list available postgresql postgresql-server pgadmin3 system-config-firewall-base dhclient kernel --nevra --archlist=x86_64,noarch 2. 3. This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |