Description of problem: I've been trying to use mockchain to rebuild a set of SRPMs. When I use either of the EPEL-5 targets, I see errors like this: mockchain -r epel-5-x86_64 -l glexec-emi2-0.1 --recurse *.rpm Traceback (most recent call last): File "/usr/bin/mockchain", line 329, in <module> main(sys.argv) File "/usr/bin/mockchain", line 222, in main res, msg = add_local_repo(mockcfg, my_mock_config, local_baseurl, 'local_build_repo') File "/usr/bin/mockchain", line 90, in add_local_repo execfile(infile) File "/etc/mock/epel-5-x86_64.cfg", line 6, in <module> config_opts['macros']['%__arch_install_post'] = '%{nil}' KeyError: 'macros' Version-Release number of selected component (if applicable): mock-1.1.28-1.fc17.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: If I comment out the entry: config_opts['macros']['%__arch_install_post'] = '%{nil}' then the mockchain builds proceed as expected. According to an RPM verify, those config files are intact.
That's odd. The top backtrace means that the config_opts dictionary doesn't have a key named 'macros' but that's initialized in mock.py, not from a config file.
Created attachment 690654 [details] make epel-5-* config files safe to eval talked to Seth Vidal about this. mockchain doens't go through the same config file paths as mock, so easiest thing to do for epel-5-* is to make the config files safe to evaluate on their own. This patch will be going into the next mock release.
mock-1.1.29-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/mock-1.1.29-1.fc17
mock-1.1.29-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.29-1.el6
mock-1.1.29-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mock-1.1.29-1.fc18
Package mock-1.1.29-1.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing mock-1.1.29-1.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0476/mock-1.1.29-1.el6 then log in and leave karma (feedback).
This seemed to break mockchain for me. Here are the errors in the log file: DEBUG util.py:88: remove tree: /var/lib/mock/epel-5-x86_64-mhuffman-30276/root/builddir DEBUG util.py:314: Executing command: ['/usr/sbin/userdel', '-r', '-f', 'mockbuild'] with env {'LANG': 'en_GB.utf8' , 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n "<mock-chroot>"', 'HOME': '/ builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'} DEBUG util.py:264: userdel: error removing directory /builddir DEBUG util.py:354: Child return code was: 12 DEBUG util.py:314: Executing command: ['/usr/sbin/groupdel', 'mockbuild'] with env {'LANG': 'en_GB.utf8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n "<mock-chroot>"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'} DEBUG util.py:264: groupdel: group mockbuild does not exist DEBUG util.py:354: Child return code was: 6 and INFO backend.py:589: Installed packages: DEBUG util.py:314: Executing command: ['rpm', '-q', '-a'] with env {'LANG': 'en_GB.utf8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n "<mock-chroot>"', 'HOME': '/builddir', 'PATH': '/usr/bi n:/bin:/usr/sbin:/sbin'} DEBUG util.py:264: error: cannot open Packages index using db3 - Invalid argument (22) DEBUG util.py:264: error: cannot open Packages database in /var/lib/rpm DEBUG util.py:354: Child return code was: 0
If I revert to 1.1.28 and comment out the macros line in epel-5-x86_64.cfg, mockchain building works.
mock-1.1.29-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.29-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.