Home

Mock

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 have. 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 command (--chain), 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.

Scope

• Mock is a rpmbuild(8) wrapper. Mock tries to simplify some steps, which would otherwise be boring or complicated.
• Mock runs rpmbuild(8) in an isolated environment consisting of a minimal set of packages.
• Mock helps you find missing BuildRequires - if it is missing and package needs it, then the build fails.
• Mock can build packages for various platforms and architectures. Some combinations of hosts and targets may need an additional configuration depending on your host platform.
• Mock can prepare a fresh build/development environment for specific RPM-based operating systems.
• Mock needs to execute some tasks under root privileges, therefore malicious RPMs can put your system at risk. Mock is not safe for unknown RPMs. If you want to build packages from untrusted sources, then use some wrapper around Mock like OBS, Copr or run Mock in a virtual machine.
• Mock is neither container nor VM. Mock does some isolation, but it does not aim to be fully isolated.
• Mock helps you open a shell within the buildroot to retrieve artifacts, or run commands for the purpose of debugging the build. It is not intended to run any production or developer application from there. For such purposes, you can use podman or Flatpak.

Content

• Status
• Release Notes
• Tarballs
• Download
• Setup
• Plugins
• Features
• Using Mock outside your git sandbox
• FAQ
• Exit codes
• Problems
• Generate custom config file
• Using file:// URLs in configs
• See Also

Status

Mock is currently being used for all Fedora builds. It is called by Koji and Copr to build chroots and packages.

Release Notes

• 2.6 (2020-09-15) - bugfixing --chain mode and --isolation=nspawn
• 2.5 (2020-09-03) - setting DNFs user_agent, a new showrc plugin added, new mock-filesystem package introduced
• 2.4 (2020-07-21) - exposed btrfs-control, module_setup_commands configuration option, copy source CA certificates
• 2.3 (2020-05-22) - bugfixes, mostly related to (by default on) bootstrap
• 2.2 (2020-04-02) - bugfixing, mostly --bootstrap-chroot issues and mock-in-container use-cases
• 2.1 (2020-03-11) - bugfixing
• 2.0 (2020-02-07) - new major version, default --bootstrap-chroot
• 1.4.21 (2019-11-01) - bugfixing
• 1.4.20 (2019-10-04) - Container image for bootstrap, Mockchain removed, New config option package_manager_max_attempts, Bind mount local repos to bootstrap chroot
• 1.4.19 (2019-09-10) - bugfixing
• 1.4.18 (2019-08-27) - subscription-manager support; procenv plugin; automatic forcearch; signals propagated in chroot
• 1.4.17 (2019-08-08) - Toolbox support, OpenMandriva, mock --chain, Dynamic Build Requires enabled by default
• 1.4.16 (2019-05-22) - python3 on el7
• 1.4.15 (2019-04-22) - Dynamic Build Requires; configurable list of disabled plugins; nice error for people not in mock group
• 1.4.14 (2019-02-19) - Jinja2 templates; choose decompress program for root_cache
• 1.4.13 (2018-08-13) - rawhide is gpg checked; new option print_main_output; proxy environmnet variables passed to mock; improved bash completation
• 1.4.11 (2018-06-12) - new options --force-arch, --spec, chrootuser; MicroDNF support; BSDTar support
• 1.4.10 (2018-05-10) - new overlayfs plugin; bind_mount can mount even files; chroot_scan can retrieve artifacts even from failed builds; introduced symlinks to rawhide configs
• 1.4.9 (2018-02-12) - split of stdout and stderr; new option optstimeout
• 1.4.8 (2017-12-22) - new option --config-opts
• 1.4.7 (2017-10-31) - new option chrootgroup; config options for bootstrap; recognize DeskOS; handle network namespace in systemd container on our own
• 1.4.6 (2017-09-15) - separation of mock-core-configs; new command --debug-config; short option -N for --no-cleanup-after
• 1.4.4 (2017-08-22) - rename group inside of chroot from mockbuild to mock
• 1.4.3 (2017-08-7)
• 1.4.2 (2017-06-20)
• 1.4.1 (2017-04-26)
• 1.3.5 - only for EL6
• 1.3.4
• 1.3.3
• 1.3.2
• 1.2.21
• 1.2.20
• 1.2.19
• 1.2.18
• 1.2.17
• 1.2.16
• 1.2.15
• 1.2.14
• 1.2.13

Tarballs

Tarballs can be found at https://github.com/rpm-software-management/mock/releases

You can retrieve tarball from the command line:

git checkout --hard mock-1.4.20-1
cd mock
tito build --tgz

Download

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

For nightly builds, please refer to developer documentation

Setup

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 newgrp -

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.

Plugins

• 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
• procenv - dumps the build process runtime within 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
• showrc - Log the content of rpm --showrc for capturing all defined macros
• sign - call command on the produced rpm
• tmpfs - mount buildroot directory as tmpfs
• yum_cache - mount /var/cache/yum of 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. '--plugin-option=root_cache:age_check=False'

Every plugin has a corresponding wiki page with docs.

Order of plugins hooks.

Features

• container image for bootstrap - set up bootstrap chroot using Podman.
• 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 fsync(2) no-op.
• modularity - support for Fedora Modularity.
• rhel chroots - builds for RHEL

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

where <configname> is the name of a configuration file from /etc/mock/, without the /etc/mock path prefix and without the .cfg suffix.

Note that you can track the progress of mock using the logs stored in /var/lib/mock/<configfile>/result

Mock inside Docker

By default, Mock uses systemd-nspawn to isolate build chroot. This is not necessary if you are running Mock inside a container and Mock is only one service you are running there. You can pass --old-chroot which will save you a lot of problems. It uses chroot() instead of systemd-nspawn.

Since version 1.3.2 you can run mock inside of Docker. However, you need to add SYS_ADMIN to the docker container. I.e. run:

docker run --cap-add=SYS_ADMIN ...

⚠️ Please note, that Mock inside of Docker skips unsharing of a namespace, so it runs in the same namespace as another 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 the config

config_opts['docker_unshare_warning'] = False

Because /sys is mounted read-only in Docker you have to put into /etc/rpm/macros.netshared in a container the following line:

%_netsharedpath /sys:/proc

FAQ

See separate page: FAQ

Exit codes

Mock has various exit codes to signal a problem in the build. See https://github.com/rpm-software-management/mock/blob/master/mock/py/mockbuild/exception.py#L26

Problems

List of known issues

If you encounter a bug running mock, please file it in Bugzilla: product "Fedora", component mock (Open Bugs).

If your problem is specific to EPEL, then file it against the "Fedora EPEL" product instead (Open Bugs).

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 a 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 ~/.config/mock.cfg.

The order of reading and evaluating configuration files is:

1. /etc/mock/site-defaults.cfg
2. /etc/mock/<buildroot>.cfg
3. ~/.mock/user.cfg
4. ~/.config/mock.cfg (since mock-1.2.15)

Using file:// URLs in configs

Since version 1.4.1 you cannot use file:// in baseurl in Mock config's. If you want to use your local repo, you have to make it available inside of the chroot using bind_mount plugin. This has been fixed and automatically handled in 1.4.20.

See Also

• 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