Bug 634956 - repoquery shouldn't traceback when it can't contact a repo
repoquery shouldn't traceback when it can't contact a repo
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: yum-utils (Show other bugs)
13
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
abrt_hash:dc8d095c
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-17 08:41 EDT by Ruggero
Modified: 2014-01-21 18:16 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-28 08:42:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (2.00 KB, text/plain)
2010-09-17 08:41 EDT, Ruggero
no flags Details

  None (edit)
Description Ruggero 2010-09-17 08:41:46 EDT
abrt version: 1.1.13
architecture: x86_64
cmdline: /usr/bin/python -tt /usr/bin/repoquery --whatrequires --alldeps -s 'python(abi) = 2.6'
component: yum-utils
executable: /usr/bin/repoquery
kernel: 2.6.34.6-54.fc13.x86_64
package: yum-utils-1.1.28-1.fc13
reason: yumRepo.py:1409:_getRepoXML:RepoError: Cannot retrieve repository metadata (repomd.xml) for repository: chromium. Please verify its path and try again
release: Fedora release 13 (Goddard)
time: 1284727280
uid: 500

backtrace
-----
yumRepo.py:1409:_getRepoXML:RepoError: Cannot retrieve repository metadata (repomd.xml) for repository: chromium. Please verify its path and try again

Traceback (most recent call last):
  File "/usr/bin/repoquery", line 1187, in <module>
    main(sys.argv)
  File "/usr/bin/repoquery", line 1181, in main
    repoq.runQuery(regexs)
  File "/usr/bin/repoquery", line 763, in runQuery
    pkgs = self.matchPkgs(items, plain_pkgs=plain_pkgs)
  File "/usr/bin/repoquery", line 739, in matchPkgs
    pkgs = self.returnPkgList(patterns=items)
  File "/usr/bin/repoquery", line 692, in returnPkgList
    pkgs = self.pkgSack.returnNewestByNameArch(**kwargs)
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 827, in <lambda>
    pkgSack = property(fget=lambda self: self._getSacks(),
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 617, in _getSacks
    self.repos.populateSack(which=repos)
  File "/usr/lib/python2.6/site-packages/yum/repos.py", line 283, in populateSack
    sack.populate(repo, mdtype, callback, cacheonly)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 163, in populate
    if self._check_db_version(repo, mydbtype):
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 221, in _check_db_version
    return repo._check_db_version(mdtype)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1224, in _check_db_version
    repoXML = self.repoXML
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1413, in <lambda>
    repoXML = property(fget=lambda self: self._getRepoXML(),
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1409, in _getRepoXML
    raise Errors.RepoError, msg
RepoError: Cannot retrieve repository metadata (repomd.xml) for repository: chromium. Please verify its path and try again

Local variables in innermost frame:
msg: 'Cannot retrieve repository metadata (repomd.xml) for repository: chromium. Please verify its path and try again'
self: <yum.yumRepo.YumRepository object at 0x111cd90>
e: NoMoreMirrorsRepoError()
Comment 1 Ruggero 2010-09-17 08:41:48 EDT
Created attachment 447997 [details]
File: backtrace
Comment 2 James Antill 2010-09-17 10:05:59 EDT
I thought this was fixed in newer versions of yum, what version of yum do you have?

yum --version
Comment 3 Ruggero 2010-09-17 10:17:46 EDT
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@redhat.com> 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
Comment 4 James Antill 2010-09-17 10:22:56 EDT
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
Comment 5 Bill Nottingham 2010-10-19 16:25:28 EDT
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.
Comment 6 Dan Nicholson 2010-10-29 08:14:13 EDT
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.
Comment 7 Patrick O'Callaghan 2010-11-03 22:43:10 EDT
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
Comment 8 Patrick O'Callaghan 2010-11-04 09:17:06 EDT
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.
Comment 9 James Antill 2010-11-04 09:46:46 EDT
You can add skip_if_unavailable=true, to your chromium repo. config.
Comment 10 Patrick O'Callaghan 2010-11-04 09:51:03 EDT
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).
Comment 11 Mihai T. Lazarescu 2010-11-04 10:40:54 EDT
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.
Comment 12 seth vidal 2010-11-04 10:58:24 EDT
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
Comment 13 Mihai T. Lazarescu 2010-11-04 11:16:02 EDT
(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!
Comment 14 Patrick O'Callaghan 2010-11-04 14:19:23 EDT
(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.
Comment 15 Mads Kiilerich 2010-11-16 06:46:20 EST
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
Comment 16 Patrick O'Callaghan 2010-11-16 10:43:36 EST
(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.
Comment 17 Vít Ondruch 2011-02-07 01:19:54 EST
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
Comment 18 Daniel Scott 2011-05-17 13:43:07 EDT
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.
Comment 19 Bug Zapper 2011-05-31 09:15:23 EDT
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
Comment 20 Bug Zapper 2011-06-28 08:42:57 EDT
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.

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