View on GitHub

Mock

A 'simple' chroot build environment manager for building RPMs.

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 -r fedora-35-x86_64 package.src.rpm
...
Finish: rpmbuild packagei-1.98-1.fc35.src.rpm
Finish: build phase for package-1.98-1.fc35.src.rpm
INFO: Done(package.src.rpm) Config(fedora-35-x86_64) 2 minutes 14 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-35-x86_64/result
$  ls /var/lib/mock/fedora-35-x86_64/result
build.log  package-1.98-1.fc35.noarch.rpm  package-1.98-1.fc35.src.rpm  hw_info.log  installed_pkgs.log  root.log  state.log

$ mock -r centos-stream+epel-9-s390x package.src.rpm
...
$ mock -r alma+epel-8-x86_64 package.src.rpm
...

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

Content

Status

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

Versions in Linux distributions:

mock versions mock-core-configs versions

Release Notes

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]

:warning: 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!

:notebook: To have this change take effect you have to either log out and log back in or run command newgrp -

Mock caches 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.

By default, builds are done in /var/lib/mock, so be sure you have room there. You can change this via the basedir config option.

Chroot config files

Mock project provides the mock-core-configs package which installs the default configuration files for various RPM-based Linux distributions. This packages is typically installed with Mock by default (runtime dependency).

Other projects can provide their own configuration files in other packages, we know of:

Plugins

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

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 Podman, Fedora Toolbox or Docker container

By default, Mock uses systemd-nspawn to isolate the build in chroot. This is not necessary though if you run Mock inside a container, and Mock is the only service running there. NB spawning containers inside containers isn’t implemented in Mock, so switching to --isolation=simple is mandatory. Mock is, though, able to automatically detect a container environment, and switch to --isolation=simple.

One can even run Mock in a rootless Podman container without any special tweaks - the only necessary step is to run the container with --privileged option. Read the podman-run manual page for more info, but --privileged - by the Podman nature - can not give the process more permissions than the UID running the podman process already has; in other words - podman run --privileged is a completely different thing from docker run --privileged!

So simply, as any non-privileged user, do:

$ podman run --rm --privileged -ti fedora:32 bash
# dnf install -y mock
# useradd mockbuilder
# usermod -a -G mock mockbuilder
# su - mockbuilder
$ mock https://some/online.src.rpm
$ mock --shell
#> ...
# etc

And similarly in toolbox enter.

You can run Mock in Docker container, however, you need to add SYS_ADMIN capability to the docker container (or use --privileged). I.e. run the container like:

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

:warning: Please note that Mock run inside of Docker container skips unsharing of a namespace, so it runs in the same namespace as any other program in the same container. That means you should not run any other application inside of that container. Mock prints warning about this. You can suppress this warning when you put in the config

config_opts['docker_unshare_warning'] = False

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).

See Also