Red Hat Bugzilla – Bug 621639
repoquery sets yum's arch
Last modified: 2015-02-17 08:19:19 EST
Description of problem:
I am accustomed to running this query from time to time to see what's out there:
repoquery -a --pkgnarrow=available --archlist=noarch,x86_64
With a recent change to yum-utils, --archlist now also sets yum's arch to the first item of the list, which means I need to reverse the order of the two arches. But instead of giving me a nice error message to help me figure out the problem, repoquery gave me a misleading traceback:
Traceback (most recent call last):
File "/usr/bin/repoquery", line 1187, in <module>
File "/usr/bin/repoquery", line 1181, in main
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 697, in returnPkgList
ygh = self.doPackageLists(what, **kwargs)
File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 2147, in doPackageLists
avail = self.pkgSack.returnNewestByNameArch(patterns=patterns,
File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 818, in <lambda>
pkgSack = property(fget=lambda self: self._getSacks(),
File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 608, in _getSacks
File "/usr/lib/python2.7/site-packages/yum/repos.py", line 283, in populateSack
sack.populate(repo, mdtype, callback, cacheonly)
File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 163, in populate
if self._check_db_version(repo, mydbtype):
File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 221, in _check_db_version
File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1224, in _check_db_version
repoXML = self.repoXML
File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1413, in <lambda>
repoXML = property(fget=lambda self: self._getRepoXML(),
File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1409, in _getRepoXML
raise Errors.RepoError, msg
yum.Errors.RepoError: Cannot retrieve repository metadata (repomd.xml) for repository: rawhide. Please verify its path and try again
Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=noarch error was
File /var/cache/yum/noarch/15/rawhide/metalink.xml.tmp is not XML
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run the query above
The traceback shown above
A list of packages or an error message giving me a hint about the order of elements in --archlist.
The current behavior prevents this query from being used at all, but it seems to me that it could be a useful query, especially when combined with name patterns.
repoquery -a --pkgnarrow=available --archlist=noarch
How about NOT setting yum's arch if the first element of the list is "noarch"?
I definitely agree about fixing the traceback, however, the ordering behavior was documented in the man page under --archlist. It was added mainly to keep from surprising people who ran:
repoquery --archlist=x86_64,ia32e on an i686 box and found that no pkgs were returned. I'm debating about simply skipping over noarch if it is the first one in the list.
James, you added the code to set the arch to the first val from archlist - what do you think about leaving arch unset if archlist is noarch or reverting this patch?
I think skipping to the second item in the list, or leave arch unset if no second item, if noarch is first in archlist is the right thing to do.
I also don't mind just always skipping the arch setting if the first item is noarch.
Either of those should fix the traceback too, but we should also catch that in case anything else goes wrong.
this patch fixes the traceback
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.
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.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 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, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
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.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.