fedpkg-1.19-2.fc22.noarch still has self.mockconfig = 'fedora-devel-%s' % self.localarch I really appreciate you fixing this upstream. Would you mind pushing an update to Rawhide and Fedora 22 to fix this as well? +++ This bug was initially created as a clone of Bug #1151956 +++ Description of problem: When DNF support is enabled in mock then 'fedpkg mockbuild' for rawhide fails: INFO: calling preinit hooks Mock Version: 1.2.0 INFO: Mock Version: 1.2.0 Start: /usr/bin/dnf update Config error: releasever not given and can not be detected from the installroot. ERROR: Exception(/home/hrw/HDD/devel/redhat/rpmbuild/fedora-packager/mock/mock-1.2.0-1.fc22.src.rpm) Config(rawhide-x86_64) 0 minutes 0 seconds Works if I want to build for f21. Version-Release number of selected component (if applicable): mock 1.2.0-1 fedora-packager 0.5.10.4-2.fc21 How reproducible: always Steps to Reproduce: 1. fedpkg clone -a flashrom 2. cd flashrom 3. enable dnf in /etc/mock/site-defaults.cfg 4. fedpkg mockbuild Actual results: 09:46 hrw@puchatek:flashrom$ LANGUAGE=C fedpkg mockbuild Wrote: /home/hrw/HDD/devel/redhat/rpmbuild/fedora-packager/flashrom/flashrom-0.9.7-1.svn1850.fc22.src.rpm INFO: mock.py version 1.2.0 starting (python version = 2.7.8)... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run INFO: Start(/home/hrw/HDD/devel/redhat/rpmbuild/fedora-packager/flashrom/flashrom-0.9.7-1.svn1850.fc22.src.rpm) Config(rawhide-x86_64) Start: clean chroot Finish: clean chroot Start: chroot init INFO: calling preinit hooks Mock Version: 1.2.0 INFO: Mock Version: 1.2.0 Start: /usr/bin/dnf update Config error: releasever not given and can not be detected from the installroot. ERROR: Exception(/home/hrw/HDD/devel/redhat/rpmbuild/fedora-packager/flashrom/flashrom-0.9.7-1.svn1850.fc22.src.rpm) Config(rawhide-x86_64) 0 minutes 0 seconds INFO: Results and/or logs in: /home/hrw/HDD/devel/redhat/rpmbuild/fedora-packager/flashrom/results_flashrom/0.9.7/1.svn1850.fc22 INFO: Cleaning up build root ('cleanup_on_failure=True') Start: clean chroot Finish: clean chroot ERROR: Command failed. See logs for output. # /usr/bin/dnf --installroot /var/lib/mock/rawhide-x86_64/root groupinstall build --setopt=tsflags=nocontexts Could not run mockbuild: Command '['mock', '--configdir', '/tmp/fedora-devel-x86_64.gAwPJXmockconfig', '-r', 'fedora-devel-x86_64', '--resultdir', '/home/hrw/HDD/devel/redhat/rpmbuild/fedora-packager/flashrom/results_flashrom/0.9.7/1.svn1850.fc22', '--rebuild', '/home/hrw/HDD/devel/redhat/rpmbuild/fedora-packager/flashrom/flashrom-0.9.7-1.svn1850.fc22.src.rpm']' returned non-zero exit status 1 Expected results: build goes and final packages are created Additional info: --- Additional comment from Marcin Juszkiewicz on 2014-10-13 03:52:41 EDT --- When I run 'mock flashrom-0.9.7-1.svn1850.fc22.src.rpm' then builds fine. --- Additional comment from Dennis Gilmore on 2014-10-13 04:35:05 EDT --- Reassigning to mock. fedpkg has no way to know dnf is used and it shouldn't matter. Mock should do the same thing regardless of what's used in the backend --- Additional comment from Mikolaj Izdebski on 2014-10-13 05:03:23 EDT --- As workaround you can set releasever manually, for example: config_opts['releasever'] = '22' --- Additional comment from Marcin Juszkiewicz on 2014-10-13 05:05:47 EDT --- Mikołaj: I rarely use 'fedpkg mockbuild' - most of builds do with 'mock --verbose' so this issue does not affects me too much. --- Additional comment from Mikolaj Izdebski on 2014-10-13 05:10:30 EDT --- I see, I just wanted to point a workaround. IMO this is a bug in fedpkg/rpkg - mock requires releasever and all configs shipped with mock by default have explicit releasever set. Fedpkg generates its own mock config without releasever, which causes mock to fail. --- Additional comment from Miroslav Suchý on 2014-10-13 07:25:17 EDT --- $ ls -l /etc/mock/default.cfg lrwxrwxrwx 1 root root 25 Oct 13 13:20 /etc/mock/default.cfg -> fedora-rawhide-x86_64.cfg $ grep dnf /etc/mock/site-defaults.cfg config_opts['package_manager'] = 'dnf' $ mock --rebuild mock-1.2.0-1.fc20.src.rpm successfully pass likely because: $ grep releasever /etc/mock/default.cfg config_opts['releasever'] = '22' Can you please run: $ rpm -V mock and verify that your /etc/mock/fedora-rawhide-x86_64.cfg and you do not have any .rpmnew/.rpmsave leftovers? --- Additional comment from Marcin Juszkiewicz on 2014-10-13 07:31:52 EDT --- 13:27 hrw@puchatek:~$ ls -l /etc/mock/default.cfg lrwxrwxrwx. 1 root root 25 10-01 11:24 /etc/mock/default.cfg -> fedora-rawhide-x86_64.cfg 13:27 hrw@puchatek:~$ grep dnf /etc/mock/site-defaults.cfg config_opts['package_manager'] = 'dnf' 13:27 hrw@puchatek:~$ rpm -V mock S.5....T. c /etc/mock/site-defaults.cfg 13:28 hrw@puchatek:~$ ls /etc/mock/ default.cfg fedora-19-x86_64.cfg fedora-21-s390x.cfg epel-5-i386.cfg fedora-20-armhfp.cfg fedora-21-x86_64.cfg epel-5-ppc.cfg fedora-20-i386.cfg fedora-rawhide-aarch64.cfg epel-5-x86_64.cfg fedora-20-ppc64.cfg fedora-rawhide-armhfp.cfg epel-6-i386.cfg fedora-20-ppc.cfg fedora-rawhide-i386.cfg epel-6-ppc64.cfg fedora-20-s390.cfg fedora-rawhide-ppc64.cfg epel-6-x86_64.cfg fedora-20-s390x.cfg fedora-rawhide-ppc64le.cfg epel-7-x86_64.cfg fedora-20-x86_64.cfg fedora-rawhide-s390.cfg fedora-19-armhfp.cfg fedora-21-aarch64.cfg fedora-rawhide-s390x.cfg fedora-19-i386.cfg fedora-21-armhfp.cfg fedora-rawhide-sparc.cfg fedora-19-ppc64.cfg fedora-21-i386.cfg fedora-rawhide-x86_64.cfg fedora-19-ppc.cfg fedora-21-ppc64.cfg logging.ini fedora-19-s390.cfg fedora-21-ppc64le.cfg site-defaults.cfg fedora-19-s390x.cfg fedora-21-s390.cfg 13:28 hrw@puchatek:~$ diff -u site-defaults.cfg /etc/mock/site-defaults.cfg --- site-defaults.cfg 2014-10-12 22:38:04.000000000 +0200 +++ /etc/mock/site-defaults.cfg 2014-10-13 09:30:50.660049072 +0200 @@ -48,6 +48,7 @@ # config_opts['package_manager'] = 'yum' # If you want to use DNF, set it to 'dnf'. To use DNf you need to have dnf and # dnf-plugins-core installed +config_opts['package_manager'] = 'dnf' # You can configure Yum, DNF, rpm and rpmbuild executable paths if you need to # use different versions that the system-wide ones Note that calling "mock" directly works. Calling 'fedpkg mockbuild' fails. --- Additional comment from Miroslav Suchý on 2014-10-13 07:36:08 EDT --- mock --rebuild /tmp/flashrom/flashrom-0.9.7-1.svn1850.fc22.src.rpm Finish sucessfully, while: fedpkg mockbuild (as stated in #0) fail. Investigating... --- Additional comment from Miroslav Suchý on 2014-10-13 07:53:09 EDT --- I see: $ fedpkg -v mockbuild ... Initiating a koji session to http://koji.fedoraproject.org/kojihub Temporary mock config directory: /tmp/fedora-devel-x86_64.Fzqv4Gmockconfig Running mock --configdir /tmp/fedora-devel-x86_64.Fzqv4Gmockconfig -r fedora-devel-x86_64 --resultdir /tmp/flashrom/results_flashrom/0.9.7/1.svn1850.fc22 --rebuild /tmp/flashrom/flashrom-0.9.7-1.svn1850.fc22.src.rpm directly on the tty When I pause the process here and do: /tmp/fedora-devel-x86_64.Fzqv4Gmockconfig/fedora-devel-x86_64.cfg which does not contain releasever variable. Note that mock no longer ships fedora-devel-*.cfg config files. These were for long time symlinks to fedora-rawhide-*.cfg. And with these last release we decided that it is time to remove it. I'm not sure what fedpkg is doing when the file is missing (it would be nice to produce some warning). But the solution seems to be (and I verified that is then working): --- ./src/fedpkg/__init__.py.orig 2014-10-13 13:46:01.511026580 +0200 +++ ./src/fedpkg/__init__.py 2014-10-13 13:46:16.462071850 +0200 @@ -153,7 +153,7 @@ self._distval = self._findmasterbranch() self._distvar = 'fedora' self.dist = 'fc%s' % self._distval - self.mockconfig = 'fedora-devel-%s' % self.localarch + self.mockconfig = 'fedora-rawhide-%s' % self.localarch self.override = None self._distunset = 'rhel' # If we don't match one of the above, punt Therefore flipping back to fedpkg. --- Additional comment from Pavol Babinčák on 2014-10-13 08:03:45 EDT --- https://git.fedorahosted.org/cgit/fedpkg.git/commit/?id=29b82ab8a3d25badd82454917faf7ebc8f2c8ac2 --- Additional comment from Miro Hrončok on 2015-01-30 17:53:31 EST --- Will this fix be propagated to Fedora as well? --- Additional comment from Tomas Mraz on 2015-02-18 12:58:00 EST --- Please. :)
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.