Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Mock is a tool for building packages. It can build packages for different architectures and different Fedora, RHEL, and Mageia versions than the build host has. Mock creates chroots and builds packages in them. Its only task is to reliably populate a chroot and attempt to build a package in that chroot.
Mock also offers a multi-package tool, mockchain, that can build chains of packages that depend on each other.
Mock is capable of building SRPMs from source configuration management if the
mock-scm package is present, then building the SRPM into RPMs. See
--scm-enable in the documentation.
- 1.4.13 (2018-08-13)
- 1.4.11 (2018-06-12)
- 1.4.10 (2018-05-10)
- 1.4.9 (2018-02-12)
- 1.4.8 (2017-12-22)
- 1.4.7 (2017-10-31)
- 1.4.6 (2017-09-15)
- 1.4.4 (2017-08-22)
- 1.4.3 (2017-08-7)
- 1.4.2 (2017-06-20)
- 1.4.1 (2017-04-26)
- 1.3.5 - only for EL6
Tar balls can be found at: https://github.com/rpm-software-management/mock/releases
If you want to contribute to the code, please checkout https://github.com/rpm-software-management/mock for more information.
Otherwise just run
dnf install mock
All users that are to use mock must be added to the mock group.
usermod -a -G mock [User name]
Mock runs some parts of its code with root privileges. There are known ways to get root access once a user is in the mock group (and once he is able to run mock). This is possible when a user abuses the mock configuration options. Please do not add anyone who is not trustworthy to the mock group!
To have this change take effect you have to either log out and log back in or run command
Configuration files are in
/etc/mock. Mock versions 0.8.0 and higher cache the downloaded rpm packages (via the
yum_cache plugin), which speeds up subsequent builds by a considerable margin. Nevertheless, you may wish to change the default configuration to point to local repositories to speed up builds (see note below).
By default, builds are done in
/var/lib/mock, so be sure you have room. Starting with mock 0.8.0 and higher, you can change this via the
basedir config option.
- bind_mount - bind mountpoints inside the chroot
- ccache - compiler cache plugin
- chroot_scan - allows you to retrieve build artifacts from buildroot (e.g. additional logs, coredumps)
- compress_logs - compress logs
- hw_info - prints HW information of builder
- lvm_root - caching buildroots using LVM
- mount - allows you to mount directories into chroot
- overlayfs - plugin implementing snapshot functionality (similary to lvm_root)
- package_state - dumps list of available and installed packages
- pm_request - executes package manager commands requested by processes running in the chroot
- root_cache - cache buildroots (as tar file)
- scm - SCM integration module - builds directly from Git or Svn
- selinux - on SELinux enabled box, this plugin will pretend, that SELinux is disabled in build environment
- sign - call command on the produced rpm
- tmpfs - mount buildroot directory as tmpfs
yum_cache - mount
/var/cache/yumof your host machine to chroot
Plugins can be enabled on command line e.g
--enable-plugin=chroot_scan. And you can set plugin options using e.g.
Every plugin has a corresponding wiki page with docs.
- bootstrap - bootstrapping chroot. I.e., when building F28 on RHEL7, then first install very minimal bootstrap chroot with DNF and rpm from F28 and then use F28's rpm to install final F28 chroot.
- forcearch - build for foreign architecture using emulated virtualization.
nosync - speed up build by making
- modularity - support for Fedora Modularity.
Using Mock outside your git sandbox
Create your SRPM using
rpmbuild -bs. Then change to the directory where your SRPM was created.
Now you can start mock with
mock -r <configname> --rebuild package-1.2-3.src.rpm
<configname> is the name of a configuration file from
/etc/mock/, without the
/etc/mock path prefix and without the
Note that you can track the progress of mock using the logs stored in
Mock inside Docker
Since version 1.3.2 you can run mock inside of Docker. However you need to add
SYS_ADMIN to docker container. I.e. run:
docker run --cap-add=SYS_ADMIN ...
Please note, that Mock inside of Docker skips unsharing of namespace, so it run in the same namespace as other program in the same container. You should not run any other application inside of that container. Mock print warning about this. You can suppress this warning, when you put in config
config_opts['docker_unshare_warning'] = False
See separate page: FAQ
Mock have various exist codes to signalize problem in build. See https://github.com/rpm-software-management/mock/blob/master/mock/py/mockbuild/exception.py#L26
Generate custom config file
Mock main config file is
/etc/mock/site-defaults.cfg, which contains all defaults setting and all possible variables you can change.
Then you have
/etc/mock/<buildroot>.cfg for various buildroots, which contains settings for yum/dnf which are for various distribution different.
When you want to alter the config you may copy one and edit it manually, however if koji is already using such an config, then you can use
mock-config --help for information how to generate one. E.g.:
koji mock-config --tag f21-build --arch=aarch64 f21
You should not alter
site-defaults.cfg unless you want to change settings for all users. You should put your changes to
~/.mock/user.cfg or to
The order of reading and evaluating configuration files is:
file:// URLs in configs
- Using Mock to test package builds has some useful tips for using mock.
- Mock Setup Using Local Mirror Setting up a local mirror using Mock.
- Legacy/Mock has some useful tips for building packages in mock for older Fedora and Red Hat Linux releases.
- Increase Mock performance.
- RPM Packaging Guide
- Modularity Features in Mock