Hi, I just released new version of Mock.
I submitted it to updates-testing F26, F25 and EPEL-7 so please test it before it hit stable.
From the release notes: https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.4.1
There are new features:
* Mock previously used chroot technology. Few past releases Mock offered systemd-nspawn which is modern container technology for better isolation. This release use systemd-nspawn as default. If you want to preserve previous behaviour you can use `--old-chroot` option. * Mock now uses bootstrap chroot to install target chroot. This is big change and see special paragraph at the bottom of this release notes. * Chroot now contains `/dev/hwrng` and `/dev/prandom` when they exists in host [[#33](https://github.com/rpm-software-management/mock/issues/33)] * We added %distro_section macro to Mageia configs
There are some bugfixes:
* Resultdir is now chowned to user who executed mock so they can delete the files. * Previously we declared that package state plugin is enabled by default, but the plugin was in fact disabled. It is now enabled by default (as stated in mock documentation) [[RHBZ#1277187](https://bugzilla.redhat.com/show_bug.cgi?id=1277187)]. * Creating directories for mount points have been delayed after mount of tmpfs [[#57](https://github.com/rpm-software-management/mock/issues/57)] * Exit code of machinectl is now ignored as machinectl set non-zero code even for non-fatal errors. Errors which are quite often not relevant nor important for mock. * hw_info plugin does not crash when output contains non-ASCII characters [[#68](https://github.com/rpm-software-management/mock/issues/68)]
Notes: * This version has not been released for EL6. If you are using EL6 and you want to use latest Mock, please upgrade you infrastructure to EL7. * Configs for s390 architecture has been removed as it is not supported any more. * Configs for aarch64 and ppc64le now use different GPG key as those architectures has been moved from Secondary to Primary. * Epel5 config points now to Vault.centos.org. Note that EL5 has been EOLed. We will keep epel-5 config for some time. But any issue with building for epel-5 target will not be fixed.
## Bootstrap chroot
Mock is calling `dnf --installroot` to install packages for target architecture into target directory. This works. Mostly. The only problem that use host DNF and rpm to install packages. But this can cause problem when new RPM feature is introduces. Like Soft dependencies or Rich dependencies. When you have EL6 host and try to install Fedora rawhide package with Rich dependency then rpm will fail and you cannot do anything about it. You can upgrade your build machine to Fedora rawhide, but that is often not possible when it is part of critical infrastructure.
So we introduced Boostrap chroot. And 'we' actually means Michael Cullen who implement it. And Igor Gnatenko who proposed this idea. Big kudos for both of them.
Bootstrap chroot means that we first create very minimal chroot for target platform and we call DNF/YUM from that platform. For example: when you are on RHEL7 and you want to build package for `fedora-26-x86_64`, mock will first create chroot called `fedora-26-x86_64-bootstrap`, it will install DNF and rpm there (fc26 versions). Then it will call DNF from `fedora-26-x86_64-bootstrap` to install all needed packages to `fedora-26-x86_64` chroot.
The disadvantage is that you will need more storage in `/var/lib/mock`, the build is little bit slower. But you will hardly notice that unless you disabled `yum_cache` and `root_cache` plugins for some reasons.
The advantage is that you can use stable version of OS to build packages for even most recent OS. And vice versa.
If you want to preserve previous behaviour you can use `--no-bootstrap-chroot` command line option or set:
``` config_opts['use_bootstrap_container'] = False ```
in your configuration.
Please do not push this stable until there has been sufficient time to test in koji and possibly develop new features in koji to make supporting chroot or systemd-nspawn configurable per tag/target
Dennis
El mié, 26-04-2017 a las 15:52 +0200, Miroslav Suchý escribió:
Hi, I just released new version of Mock.
I submitted it to updates-testing F26, F25 and EPEL-7 so please test it before it hit stable.
From the release notes: https://github.com/rpm-software-management/mock/wiki/Release-Notes -1.4.1
There are new features:
- Mock previously used chroot technology. Few past releases Mock
offered systemd-nspawn which is modern container technology for better isolation. This release use systemd-nspawn as default. If you want to preserve previous behaviour you can use `--old-chroot` option.
- Mock now uses bootstrap chroot to install target chroot. This is
big change and see special paragraph at the bottom of this release notes.
- Chroot now contains `/dev/hwrng` and `/dev/prandom` when they
exists in host [[#33](https://github.com/rpm-software-management/mock/issues /33)]
- We added %distro_section macro to Mageia configs
There are some bugfixes:
- Resultdir is now chowned to user who executed mock so they can
delete the files.
- Previously we declared that package state plugin is enabled by
default, but the plugin was in fact disabled. It is now enabled by default (as stated in mock documentation) [[RHBZ#1277187](https://bugzilla.redhat.com/show_bug.cgi?id=1277187)] .
- Creating directories for mount points have been delayed after mount
of tmpfs [[#57](https://github.com/rpm-software-management/mock/issues/5 7)]
- Exit code of machinectl is now ignored as machinectl set non-zero
code even for non-fatal errors. Errors which are quite often not relevant nor important for mock.
- hw_info plugin does not crash when output contains non-ASCII
characters [[#68](https://github.com/rpm-software-management/mock/issues/68)]
Notes:
- This version has not been released for EL6. If you are using EL6
and you want to use latest Mock, please upgrade you infrastructure to EL7.
- Configs for s390 architecture has been removed as it is not
supported any more.
- Configs for aarch64 and ppc64le now use different GPG key as those
architectures has been moved from Secondary to Primary.
- Epel5 config points now to Vault.centos.org. Note that EL5 has
been EOLed. We will keep epel-5 config for some time. But any issue with building for epel-5 target will not be fixed.
## Bootstrap chroot
Mock is calling `dnf --installroot` to install packages for target architecture into target directory. This works. Mostly. The only problem that use host DNF and rpm to install packages. But this can cause problem when new RPM feature is introduces. Like Soft dependencies or Rich dependencies. When you have EL6 host and try to install Fedora rawhide package with Rich dependency then rpm will fail and you cannot do anything about it. You can upgrade your build machine to Fedora rawhide, but that is often not possible when it is part of critical infrastructure.
So we introduced Boostrap chroot. And 'we' actually means Michael Cullen who implement it. And Igor Gnatenko who proposed this idea. Big kudos for both of them.
Bootstrap chroot means that we first create very minimal chroot for target platform and we call DNF/YUM from that platform. For example: when you are on RHEL7 and you want to build package for `fedora-26-x86_64`, mock will first create chroot called `fedora-26-x86_64-bootstrap`, it will install DNF and rpm there (fc26 versions). Then it will call DNF from `fedora-26-x86_64-bootstrap` to install all needed packages to `fedora-26-x86_64` chroot.
The disadvantage is that you will need more storage in `/var/lib/mock`, the build is little bit slower. But you will hardly notice that unless you disabled `yum_cache` and `root_cache` plugins for some reasons.
The advantage is that you can use stable version of OS to build packages for even most recent OS. And vice versa.
If you want to preserve previous behaviour you can use `--no-bootstrap-chroot` command line option or set:
config_opts['use_bootstrap_container'] = False
in your configuration.
-- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys _______________________________________________ buildsys mailing list -- buildsys@lists.fedoraproject.org To unsubscribe send an email to buildsys-leave@lists.fedoraproject.or g
Dne 26.4.2017 v 20:35 Dennis Gilmore napsal(a):
Please do not push this stable until there has been sufficient time to test in koji and possibly develop new features in koji to make
OK, I switched off "Auto-request stable" for now. Well kind off. I discovered it cannot be switched off once set [1], but I raised the karma treshold to very high number.
[1] https://github.com/fedora-infra/bodhi/issues/1482
How many days you need for testing? Is one week enough?
supporting chroot or systemd-nspawn configurable per tag/target
Why would you enable/disable nspawn per chroot? It does not make sense to me. You can even build EL5 build inside of nspawn. What is important is the host, not the target.
Dne 27.4.2017 v 09:38 Miroslav Suchý napsal(a):
Dne 26.4.2017 v 20:35 Dennis Gilmore napsal(a):
Please do not push this stable until there has been sufficient time to test in koji and possibly develop new features in koji to make
OK, I switched off "Auto-request stable" for now. Well kind off. I discovered it cannot be switched off once set [1], but I raised the karma treshold to very high number.
[1] https://github.com/fedora-infra/bodhi/issues/1482
How many days you need for testing? Is one week enough?
supporting chroot or systemd-nspawn configurable per tag/target
Why would you enable/disable nspawn per chroot? It does not make sense to me. You can even build EL5 build inside of nspawn. What is important is the host, not the target.
To be honest, I experience some issues with RHEL6 buildroot on my Rawhide. For example, this does not work:
~~~ $ mock -r rhel-6-x86_64 shell --unpriv --new-chroot INFO: mock.py version 1.4.1 starting (python version = 3.6.1)... Start: init plugins INFO: selinux disabled Finish: init plugins Start: init plugins INFO: selinux disabled Finish: init plugins Start: run Start: chroot init INFO: LVM plugin enabled. Allocated pool data: 51.41%. Allocated metadata: 28.79%. INFO: calling preinit hooks INFO: enabled root cache INFO: enabled yum cache Start: cleaning yum metadata Finish: cleaning yum metadata INFO: enabled HW Info plugin Finish: chroot init INFO: Installed packages: Start: shell Child died too early. getent initgroups failed with error code 1. Failed to parse group data from getent. Finish: shell ~~~
while '--old-chroot' works just fine. I did not bothered too much to analyze, but I'd be cautious.
Vít
El jue, 27-04-2017 a las 10:16 +0200, Vít Ondruch escribió:
Dne 27.4.2017 v 09:38 Miroslav Suchý napsal(a):
Dne 26.4.2017 v 20:35 Dennis Gilmore napsal(a):
Please do not push this stable until there has been sufficient time to test in koji and possibly develop new features in koji to make
OK, I switched off "Auto-request stable" for now. Well kind off. I discovered it cannot be switched off once set [1], but I raised the karma treshold to very high number.
[1] https://github.com/fedora-infra/bodhi/issues/1482
How many days you need for testing? Is one week enough?
Probably we will need 3-4 weeks at least.
supporting chroot or systemd-nspawn configurable per tag/target
Why would you enable/disable nspawn per chroot? It does not make sense to me. You can even build EL5 build inside of nspawn. What is important is the host, not the target.
There may be various reasons why. we have a flag for run root tasks to use --new-chroot or not currently because some of the tasks work just fine in a chroot and not in a nspawn container while others do not run at all in chroot and need to be run in a container of some form. It is messy and the change needs to be coordinated and its more than just Fedora rel-eng but koji devs as well.
To be honest, I experience some issues with RHEL6 buildroot on my Rawhide. For example, this does not work:
weird cases like Vit experienced is why.
Dennis
On Thu, 27 Apr 2017 10:16:23 +0200 Vít Ondruch vondruch@redhat.com wrote:
Dne 27.4.2017 v 09:38 Miroslav Suchý napsal(a):
Dne 26.4.2017 v 20:35 Dennis Gilmore napsal(a):
Please do not push this stable until there has been sufficient time to test in koji and possibly develop new features in koji to make
OK, I switched off "Auto-request stable" for now. Well kind off. I discovered it cannot be switched off once set [1], but I raised the karma treshold to very high number.
[1] https://github.com/fedora-infra/bodhi/issues/1482
How many days you need for testing? Is one week enough?
supporting chroot or systemd-nspawn configurable per tag/target
Why would you enable/disable nspawn per chroot? It does not make sense to me. You can even build EL5 build inside of nspawn. What is important is the host, not the target.
To be honest, I experience some issues with RHEL6 buildroot on my Rawhide. For example, this does not work:
$ mock -r rhel-6-x86_64 shell --unpriv --new-chroot INFO: mock.py version 1.4.1 starting (python version = 3.6.1)... Start: init plugins INFO: selinux disabled Finish: init plugins Start: init plugins INFO: selinux disabled Finish: init plugins Start: run Start: chroot init INFO: LVM plugin enabled. Allocated pool data: 51.41%. Allocated metadata: 28.79%. INFO: calling preinit hooks INFO: enabled root cache INFO: enabled yum cache Start: cleaning yum metadata Finish: cleaning yum metadata INFO: enabled HW Info plugin Finish: chroot init INFO: Installed packages: Start: shell Child died too early. getent initgroups failed with error code 1. Failed to parse group data from getent. Finish: shell
while '--old-chroot' works just fine. I did not bothered too much to analyze, but I'd be cautious.
I'm getting that as well. I see a bug from last year that looks related (https://bugzilla.redhat.com/show_bug.cgi?id=1301953), in which the conclusion seemed to be not to use nspawn for EL-6 roots.
I also have an issue with repos using file:// baseurls (which I have for my local repos and mirrors of distribution repos). Previously these worked fine but now that mock runs yum/dnf within the chroot, I need to use the bind mount plugin to map the necessary directories into the chroot.
Paul.
Dne 29.4.2017 v 12:58 Paul Howarth napsal(a):
I also have an issue with repos using file:// baseurls (which I have for my local repos and mirrors of distribution repos). Previously these worked fine but now that mock runs yum/dnf within the chroot, I need to use the bind mount plugin to map the necessary directories into the chroot.
Nice catch. I will document this.
Dne 2.5.2017 v 09:21 Miroslav Suchý napsal(a):
Dne 29.4.2017 v 12:58 Paul Howarth napsal(a):
I also have an issue with repos using file:// baseurls (which I have for my local repos and mirrors of distribution repos). Previously these worked fine but now that mock runs yum/dnf within the chroot, I need to use the bind mount plugin to map the necessary directories into the chroot.
Nice catch. I will document this.
https://github.com/rpm-software-management/mock/wiki#using-file-urls-in-conf...
On Tue, 2 May 2017 10:59:46 +0200 Miroslav Suchý msuchy@redhat.com wrote:
Dne 2.5.2017 v 09:21 Miroslav Suchý napsal(a):
Dne 29.4.2017 v 12:58 Paul Howarth napsal(a):
I also have an issue with repos using file:// baseurls (which I have for my local repos and mirrors of distribution repos). Previously these worked fine but now that mock runs yum/dnf within the chroot, I need to use the bind mount plugin to map the necessary directories into the chroot.
Nice catch. I will document this.
https://github.com/rpm-software-management/mock/wiki#using-file-urls-in-conf...
which means having to do 2 steps to configure one thing and higher chance for mis-configuring, can't mock do it automagically?
Dan
Dne 2.5.2017 v 11:11 Dan Horák napsal(a):
which means having to do 2 steps to configure one thing and higher chance for mis-configuring, can't mock do it automagically?
It can. Patches are welcome :)
On Wed, Apr 26, 2017 at 2:35 PM, Dennis Gilmore dennis@ausil.us wrote:
Please do not push this stable until there has been sufficient time to test in koji and possibly develop new features in koji to make supporting chroot or systemd-nspawn configurable per tag/target
There's no reason to do that. All the Koji builders in Fedora infrastructure are Fedora based, so nspawn will work fine.
That's just unnecessary panic.
On Thu, Apr 27, 2017 at 03:41:21AM -0400, Neal Gompa wrote:
Please do not push this stable until there has been sufficient time to test in koji and possibly develop new features in koji to make supporting chroot or systemd-nspawn configurable per tag/target
There's no reason to do that. All the Koji builders in Fedora infrastructure are Fedora based, so nspawn will work fine. That's just unnecessary panic.
nspawn *should* work fine, but there's a lot of change here. It seems reasonable to be cautious, especially since we're already into almost-July with this year's "May" release.
I have filed https://pagure.io/koji/issue/398 as an RFE for koji to provide support for choosing between chroot/nspawn.
Cheers -- Dennis
On 04/26/2017 02:35 PM, Dennis Gilmore wrote:
Please do not push this stable until there has been sufficient time to test in koji and possibly develop new features in koji to make supporting chroot or systemd-nspawn configurable per tag/target
Dennis
El mié, 26-04-2017 a las 15:52 +0200, Miroslav Suchý escribió:
Hi, I just released new version of Mock.
I submitted it to updates-testing F26, F25 and EPEL-7 so please test it before it hit stable.
From the release notes: https://github.com/rpm-software-management/mock/wiki/Release-Notes -1.4.1
There are new features:
- Mock previously used chroot technology. Few past releases Mock
offered systemd-nspawn which is modern container technology for better isolation. This release use systemd-nspawn as default. If you want to preserve previous behaviour you can use `--old-chroot` option.
- Mock now uses bootstrap chroot to install target chroot. This is
big change and see special paragraph at the bottom of this release notes.
- Chroot now contains `/dev/hwrng` and `/dev/prandom` when they
exists in host [[#33](https://github.com/rpm-software-management/mock/issues /33)]
- We added %distro_section macro to Mageia configs
There are some bugfixes:
- Resultdir is now chowned to user who executed mock so they can
delete the files.
- Previously we declared that package state plugin is enabled by
default, but the plugin was in fact disabled. It is now enabled by default (as stated in mock documentation) [[RHBZ#1277187](https://bugzilla.redhat.com/show_bug.cgi?id=1277187)] .
- Creating directories for mount points have been delayed after mount
of tmpfs [[#57](https://github.com/rpm-software-management/mock/issues/5 7)]
- Exit code of machinectl is now ignored as machinectl set non-zero
code even for non-fatal errors. Errors which are quite often not relevant nor important for mock.
- hw_info plugin does not crash when output contains non-ASCII
characters [[#68](https://github.com/rpm-software-management/mock/issues/68)]
Notes:
- This version has not been released for EL6. If you are using EL6
and you want to use latest Mock, please upgrade you infrastructure to EL7.
- Configs for s390 architecture has been removed as it is not
supported any more.
- Configs for aarch64 and ppc64le now use different GPG key as those
architectures has been moved from Secondary to Primary.
- Epel5 config points now to Vault.centos.org. Note that EL5 has
been EOLed. We will keep epel-5 config for some time. But any issue with building for epel-5 target will not be fixed.
## Bootstrap chroot
Mock is calling `dnf --installroot` to install packages for target architecture into target directory. This works. Mostly. The only problem that use host DNF and rpm to install packages. But this can cause problem when new RPM feature is introduces. Like Soft dependencies or Rich dependencies. When you have EL6 host and try to install Fedora rawhide package with Rich dependency then rpm will fail and you cannot do anything about it. You can upgrade your build machine to Fedora rawhide, but that is often not possible when it is part of critical infrastructure.
So we introduced Boostrap chroot. And 'we' actually means Michael Cullen who implement it. And Igor Gnatenko who proposed this idea. Big kudos for both of them.
Bootstrap chroot means that we first create very minimal chroot for target platform and we call DNF/YUM from that platform. For example: when you are on RHEL7 and you want to build package for `fedora-26-x86_64`, mock will first create chroot called `fedora-26-x86_64-bootstrap`, it will install DNF and rpm there (fc26 versions). Then it will call DNF from `fedora-26-x86_64-bootstrap` to install all needed packages to `fedora-26-x86_64` chroot.
The disadvantage is that you will need more storage in `/var/lib/mock`, the build is little bit slower. But you will hardly notice that unless you disabled `yum_cache` and `root_cache` plugins for some reasons.
The advantage is that you can use stable version of OS to build packages for even most recent OS. And vice versa.
If you want to preserve previous behaviour you can use `--no-bootstrap-chroot` command line option or set:
config_opts['use_bootstrap_container'] = False
in your configuration.
-- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys _______________________________________________ buildsys mailing list -- buildsys@lists.fedoraproject.org To unsubscribe send an email to buildsys-leave@lists.fedoraproject.or g
buildsys mailing list -- buildsys@lists.fedoraproject.org To unsubscribe send an email to buildsys-leave@lists.fedoraproject.org
Dne 26.4.2017 v 15:52 Miroslav Suchý napsal(a):
## Bootstrap chroot
This does not work as expected. Trying to setup RHEL6 (and 7 probably as well) buildroot on Rawhide fails:
https://bugzilla.redhat.com/show_bug.cgi?id=1446294
the "--no-bootstrap-chroot" option or "config_opts['use_bootstrap_container'] = False" described bellow should help.
Vít
Mock is calling `dnf --installroot` to install packages for target architecture into target directory. This works. Mostly. The only problem that use host DNF and rpm to install packages. But this can cause problem when new RPM feature is introduces. Like Soft dependencies or Rich dependencies. When you have EL6 host and try to install Fedora rawhide package with Rich dependency then rpm will fail and you cannot do anything about it. You can upgrade your build machine to Fedora rawhide, but that is often not possible when it is part of critical infrastructure.
So we introduced Boostrap chroot. And 'we' actually means Michael Cullen who implement it. And Igor Gnatenko who proposed this idea. Big kudos for both of them.
Bootstrap chroot means that we first create very minimal chroot for target platform and we call DNF/YUM from that platform. For example: when you are on RHEL7 and you want to build package for `fedora-26-x86_64`, mock will first create chroot called `fedora-26-x86_64-bootstrap`, it will install DNF and rpm there (fc26 versions). Then it will call DNF from `fedora-26-x86_64-bootstrap` to install all needed packages to `fedora-26-x86_64` chroot.
The disadvantage is that you will need more storage in `/var/lib/mock`, the build is little bit slower. But you will hardly notice that unless you disabled `yum_cache` and `root_cache` plugins for some reasons.
The advantage is that you can use stable version of OS to build packages for even most recent OS. And vice versa.
If you want to preserve previous behaviour you can use `--no-bootstrap-chroot` command line option or set:
config_opts['use_bootstrap_container'] = False
in your configuration.
Dne 27.4.2017 v 17:30 Vít Ondruch napsal(a):
Dne 26.4.2017 v 15:52 Miroslav Suchý napsal(a):
## Bootstrap chroot
This does not work as expected. Trying to setup RHEL6 (and 7 probably as well) buildroot on Rawhide fails:
https://bugzilla.redhat.com/show_bug.cgi?id=1446294
the "--no-bootstrap-chroot" option or "config_opts['use_bootstrap_container'] = False" described bellow should help.
This appears to be caused by remaint of old days:
$ cat ~/.config/mock.cfg | grep yum config_opts['yum_command'] = '/usr/bin/yum-deprecated'
Should not be issue for most of you.
Vít
Vít
Mock is calling `dnf --installroot` to install packages for target architecture into target directory. This works. Mostly. The only problem that use host DNF and rpm to install packages. But this can cause problem when new RPM feature is introduces. Like Soft dependencies or Rich dependencies. When you have EL6 host and try to install Fedora rawhide package with Rich dependency then rpm will fail and you cannot do anything about it. You can upgrade your build machine to Fedora rawhide, but that is often not possible when it is part of critical infrastructure.
So we introduced Boostrap chroot. And 'we' actually means Michael Cullen who implement it. And Igor Gnatenko who proposed this idea. Big kudos for both of them.
Bootstrap chroot means that we first create very minimal chroot for target platform and we call DNF/YUM from that platform. For example: when you are on RHEL7 and you want to build package for `fedora-26-x86_64`, mock will first create chroot called `fedora-26-x86_64-bootstrap`, it will install DNF and rpm there (fc26 versions). Then it will call DNF from `fedora-26-x86_64-bootstrap` to install all needed packages to `fedora-26-x86_64` chroot.
The disadvantage is that you will need more storage in `/var/lib/mock`, the build is little bit slower. But you will hardly notice that unless you disabled `yum_cache` and `root_cache` plugins for some reasons.
The advantage is that you can use stable version of OS to build packages for even most recent OS. And vice versa.
If you want to preserve previous behaviour you can use `--no-bootstrap-chroot` command line option or set:
config_opts['use_bootstrap_container'] = False
in your configuration.
buildsys mailing list -- buildsys@lists.fedoraproject.org To unsubscribe send an email to buildsys-leave@lists.fedoraproject.org
On Wed, Apr 26, 2017 at 7:52 AM, Miroslav Suchý msuchy@redhat.com wrote:
Hi, I just released new version of Mock.
I submitted it to updates-testing F26, F25 and EPEL-7 so please test it before it hit stable.
I'm seeing a regression in 1.4.1 compared to 1.3.4. On my computer, "fedpkg --dist epel7 mockbuild" fails with "Couldn't open file /etc/pki/mock/RPM-GPG-KEY-CentOS-7". Filed https://bugzilla.redhat.com/1450621 to track this.
- Ken
On Sat, May 13, 2017 at 7:37 PM, Ken Dreyer ktdreyer@ktdreyer.com wrote:
On Wed, Apr 26, 2017 at 7:52 AM, Miroslav Suchý msuchy@redhat.com wrote:
Hi, I just released new version of Mock.
I submitted it to updates-testing F26, F25 and EPEL-7 so please test it before it hit stable.
I'm seeing a regression in 1.4.1 compared to 1.3.4. On my computer, "fedpkg --dist epel7 mockbuild" fails with "Couldn't open file /etc/pki/mock/RPM-GPG-KEY-CentOS-7". Filed https://bugzilla.redhat.com/1450621 to track this.
I'm also unable to install any local .rpm file with "mock install" (this worked fine in mock 1.3.4). Filed https://bugzilla.redhat.com/1452902 to track this.
- Ken
buildsys@lists.fedoraproject.org