Hide Forgot
Description of problem: Using mash for a multilib-relevant arch (eg. x86_64) produces a stacktrace, regardless what builds are included: Traceback (most recent call last): File "/usr/bin/mash", line 82, in ? main() File "/usr/bin/mash", line 70, in main rc = themash.doMultilib() File "/usr/lib/python2.4/site-packages/mash/__init__.py", line 417, in doMultilib pid = self.doDepSolveAndMultilib(arch, cachedir) File "/usr/lib/python2.4/site-packages/mash/__init__.py", line 367, in doDepSolveAndMultilib yumbase.doSackFilelistPopulate() File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 434, in doSackFilelistPopulate if 'filelists' in repo.sack.added[repo]: KeyError: <yum.yumRepo.YumRepository object at 0x19590790> mash failed in /data/mash/buildsys-el5 Version-Release number of selected component (if applicable): Tested with 0.2.10 and yum 3.0.5 on RHEL5. How reproducible: Always; Run mash on EL5 (yum 3.0.x) with arch x86_64 included. Actual results: See above stacktrace. Additional info: After some debugging it seems that this problem is related to the yum-API. See below for some debug output: yconfig = [main] debuglevel=9 pkgpolicy=newest exactarch=0 gpgcheck=0 reposdir=/dev/null cachedir=/yumcache installroot=/tmp/mash-buildsys-el5/buildsys-el5-x86_64.tmp logfile=/yum.log [buildsys-el5-x86_64] name=buildsys-el5 baseurl=file:///data/mash/buildsys-el5/x86_64 enabled=1 doSackSetup: archlist = ('amd64', 'ia32e', 'x86_64', 'noarch'), thisrepo = buildsys-el5 findRepos: pattern = buildsys-el5 findRepos: item = buildsys-el5 findRepos: name = buildsys-el5-x86_64 findRepos: repos = {'buildsys-el5-x86_64': <yum.yumRepo.YumRepository object at 0x2aaaaf129210>} findRepos: result = [] Setting up Package Sacks populateSack: which = [], with = metadata, myrepos = [] filelist = [] mash done in /data/mash/buildsys-el5 As you can see, is findRepos() from yum/repos.py never matching the repository from the generated yum config and therefore returning nothing. For some reason is the repository name not taken from the "name" attribute, but from the config header. Has this been found anywhere else or is this specific to this yum version?
Created attachment 295356 [details] Fix
Added in git for upstream, will probably make its way into EPEL soon.
Well, to be honest I've to correct my above description. The yum-API is not causing the problem. I've just done the same test with 3.2.7, and findRepos() there behaves identical. The only difference is, that this version seems to somewhere later populates the repo list itself so it doesn't propagate to mash. And "name" is not the repo name, but a human readable string describing the repository.
Well, it's only an API problem in that mash was using it wrong. :)
Fixed in 0.2.10-2. Sorry about the delay.
mash-0.2.10-2.fc8 has been submitted as an update for Fedora 8
mash-0.2.10-3.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
mash-0.5.16-1.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/mash-0.5.16-1.el5
mash-0.5.20-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/mash-0.5.20-1.el5
mash-0.5.20-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.