particle-os/deb-mock
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

enhance: Add comprehensive .gitignore for deb-mock project
Some checks failed
Build Deb-Mock Package / build (push) Successful in 54s
Details
Lint Code / Lint All Code (push) Failing after 1s
Details
Test Deb-Mock Build / test (push) Failing after 36s
Details

Browse source 
- Add mock-specific build artifacts (chroot/, mock-*, mockroot/)
- Include package build files (*.deb, *.changes, *.buildinfo)
- Add development tools (.coverage, .pytest_cache, .tox)
- Include system files (.DS_Store, Thumbs.db, ._*)
- Add temporary and backup files (*.tmp, *.bak, *.backup)
- Include local configuration overrides (config.local.yaml, .env.local)
- Add test artifacts and documentation builds
- Comprehensive coverage for Python build system project

This ensures build artifacts, chroot environments, and development
tools are properly ignored in version control.
This commit is contained in:
robojerk 2025-08-18 23:37:49 -07:00
parent 1a559245ea
commit 4c0dcb2522
329 changed files with 27394 additions and 965 deletions
Download patch file Download diff file Expand all files Collapse all files

141
.gitignore vendored
View file

@ -31,8 +31,12 @@ share/python-wheels/
MANIFEST MANIFEST
# PyInstaller # PyInstaller
# Usually these files are written by a python script from a template # Usually these files are written by a python
# before PyInstaller builds the exe, so as to inject date/other infos into it. script from a template
# before PyInstaller builds the exe, so as to
inject date/other infos into it.
*.manifest *.manifest
*.spec *.spec
@ -88,13 +92,22 @@ ipython_config.py
.python-version .python-version
# pipenv # pipenv
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control. # According to pypa/pipenv#598, it is recomme
# However, in case of collaboration, if having platform-specific dependencies or dependencies nded to include Pipfile.lock in version control
# having no cross-platform support, pipenv may install dependencies that don't work, or not .
# However, in case of collaboration, if havin
g platform-specific dependencies or dependencie
s
# having no cross-platform support, pipenv ma
y install dependencies that don't work, or not
# install all needed dependencies. # install all needed dependencies.
#Pipfile.lock #Pipfile.lock
# PEP 582; used by e.g. github.com/David-OConnor/pyflow # PEP 582; used by e.g. github.com/David-OConno
r/pyflow
__pypackages__/ __pypackages__/
# Celery stuff # Celery stuff
@ -150,10 +163,15 @@ metadata/
# Chroot environments # Chroot environments
/var/lib/deb-mock/ /var/lib/deb-mock/
/tmp/deb-mock-* /tmp/deb-mock-*
chroot/
chroots/
mock-chroot-*
# Build logs # Build logs
*.log *.log
logs/ logs/
build.log
mock.log
# IDE files # IDE files
.vscode/ .vscode/
@ -165,4 +183,115 @@ logs/
# OS files # OS files
.DS_Store .DS_Store
Thumbs.db Thumbs.db
._*
.Spotlight-V100
.Trashes
ehthumbs.db
# Temporary files
*.tmp
*.temp
*.bak
*.backup
*.old
*.orig
# Configuration overrides
config.local.yaml
config.local.yml
.env.local
.env.*.local
# Test artifacts
.pytest_cache/
test-results/
test-output/
coverage/
htmlcov/
# Mock-specific build artifacts
mock-build-*
mock-result-*
mock-*.log
mock-*.txt
# Package build artifacts
*.build
*.buildinfo
*.changes
*.dsc
*.deb
*.udeb
*.tar.gz
*.tar.xz
*.tar.bz2
*.diff.gz
*.orig.tar.gz
*.debian.tar.gz
# Chroot and build environment files
/var/lib/mock/
/var/cache/mock/
mock-*
mockroot/
# Development tools
.coverage
.pytest_cache/
.tox/
.nox/
.mypy_cache/
.pyre/
# Documentation builds
docs/_build/
site/
docs/build/
# Cache directories
.cache/
cache/
__pycache__/
# Backup and temporary files
*~
*.swp
*.swo
*.bak
*.backup
*.old
*.orig
*.tmp
*.temp
# Local development files
local/
dev/
development/
local_config.py
local_settings.py
# Database files
*.db
*.sqlite
*.sqlite3
# Log files
*.log
logs/
log/
*.log.*
# Archive files
*.zip
*.rar
*.7z
*.tar
*.gz
*.bz2
*.xz
# System files
.fuse_hidden*
.nfs*

340
LICENSE Normal file
View file

@ -0,0 +1,340 @@
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.

182
Makefile
View file

@ -1,95 +1,91 @@
.PHONY: help install install-dev test clean lint format docs # deb-mock Makefile
# Debian's equivalent to Fedora's Mock build environment manager
help: ## Show this help message .PHONY: all install clean test lint format dev-setup help
@echo "Deb-Mock - Debian Package Build Environment"
# Default target
all: install
# Install the package
install:
@echo "Installing deb-mock..."
@pip install -e .
# Install development dependencies
dev-setup: install
@echo "Installing development dependencies..."
@pip install -e ".[dev]"
# Run tests
test:
@echo "Running tests..."
@python -m pytest tests/ -v
# Run tests with coverage
test-cov:
@echo "Running tests with coverage..."
@python -m pytest tests/ --cov=deb_mock --cov-report=html
# Lint the code
lint:
@echo "Linting code..."
@flake8 deb_mock/ tests/
@mypy deb_mock/
# Format the code
format:
@echo "Formatting code..."
@black deb_mock/ tests/
# Clean build artifacts
clean:
@echo "Cleaning build artifacts..."
@rm -rf build/
@rm -rf dist/
@rm -rf *.egg-info/
@rm -rf .pytest_cache/
@rm -rf htmlcov/
@find . -type f -name "*.pyc" -delete
@find . -type d -name "__pycache__" -delete
# Development helpers
dev-install: dev-setup
@echo "Development environment ready!"
dev-test: dev-setup test
dev-lint: dev-setup lint
dev-format: dev-setup format
# Run the CLI
run:
@echo "Running deb-mock CLI..."
@python -m deb_mock.cli --help
# Create virtual environment (optional)
venv:
@echo "Creating virtual environment..."
@python3 -m venv venv
@echo "Virtual environment created. Activate with: source venv/bin/activate"
# Help
help:
@echo "deb-mock Makefile"
@echo "" @echo ""
@echo "Available targets:" @echo "Targets:"
@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf " \033[36m%-15s\033[0m %s\n", $$1, $$2}' @echo " all - Install the package"
@echo " install - Install the package"
install: ## Install deb-mock (for Debian package build) @echo " dev-setup - Install with development dependencies"
@echo "Installation handled by dh-python" @echo " test - Run tests"
@echo " test-cov - Run tests with coverage"
install-dev: ## Install deb-mock with development dependencies @echo " lint - Lint the code"
pip install -e . @echo " format - Format the code"
pip install -r requirements-dev.txt @echo " clean - Clean build artifacts"
@echo " dev-install - Set up development environment"
test: ## Run tests @echo " dev-test - Run tests in development environment"
python3 -m pytest tests/ -v @echo " dev-lint - Lint code in development environment"
@echo " dev-format - Format code in development environment"
test-coverage: ## Run tests with coverage @echo " run - Run the CLI"
python3 -m pytest tests/ --cov=deb_mock --cov-report=html --cov-report=term @echo " venv - Create virtual environment"
@echo " help - Show this help"
lint: ## Run linting checks
@echo "=== Running all linting checks with Docker container ==="
docker run --rm -v $(PWD):/app git.raines.xyz/robojerk/deb-mock-linter:latest /bin/bash -c "\
echo '=== Linting YAML files ===' && \
yamllint .forgejo/workflows/ deb_mock/configs/ test-config.yaml && \
echo '=== Linting Python files ===' && \
source /opt/venv/bin/activate && \
flake8 deb_mock/ tests/ --max-line-length=120 --ignore=E203,W503 && \
black --check --line-length=120 deb_mock/ tests/ && \
isort --check-only --profile=black deb_mock/ tests/ && \
echo '=== Linting shell scripts ===' && \
find . -name '*.sh' -exec shellcheck {} \; && \
echo '✅ All linting checks passed!'"
lint-local: ## Run linting checks locally (requires tools installed)
@echo "=== Running Python linting ==="
venv/bin/flake8 deb_mock/ tests/ --max-line-length=120 --ignore=E203,W503
venv/bin/black --check --line-length=120 deb_mock/ tests/
venv/bin/isort --check-only --profile=black deb_mock/ tests/
@echo "=== Running YAML linting ==="
yamllint .forgejo/workflows/ deb_mock/configs/ test-config.yaml
@echo "=== Running shell linting ==="
find . -name "*.sh" -exec shellcheck {} \;
@echo "✅ All linting checks passed!"
format: ## Format code with black
black deb_mock/ tests/
clean: ## Clean build artifacts
rm -rf build/
rm -rf dist/
rm -rf *.egg-info/
# rm -rf output/ # Temporarily disabled to preserve build artifacts
rm -rf metadata/
find . -type d -name __pycache__ -exec rm -rf {} +
find . -type f -name "*.pyc" -delete
docs: ## Build documentation
cd docs && make html
install-system-deps: ## Install system dependencies (requires sudo)
sudo apt update
sudo apt install -y sbuild schroot debhelper build-essential debootstrap yamllint shellcheck
install-lint-deps: ## Install linting dependencies
python3 -m venv venv
venv/bin/pip install flake8 black isort bandit
sudo apt install -y yamllint shellcheck nodejs npm
sudo npm install -g markdownlint-cli
setup-chroot: ## Setup initial chroot environment (requires sudo)
sudo mkdir -p /var/lib/deb-mock/chroots
sudo mkdir -p /etc/schroot/chroot.d
sudo chown -R $$USER:$$USER /var/lib/deb-mock
build-example: ## Build an example package (requires setup)
deb-mock init-chroot bookworm-amd64
deb-mock build examples/hello_1.0.dsc
check: ## Run all checks (lint, test, format)
$(MAKE) lint
$(MAKE) test
$(MAKE) format
dist: ## Build distribution package
python3 setup.py sdist bdist_wheel
upload: ## Upload to PyPI (requires twine)
twine upload dist/*
dev-setup: ## Complete development setup
$(MAKE) install-system-deps
$(MAKE) setup-chroot
$(MAKE) install-dev

355
README.md
View file

@ -1,355 +0,0 @@
# Deb-Mock
![Build Status](https://git.raines.xyz/robojerk/deb-mock/actions/workflows/build.yml/badge.svg)
A low-level utility to create clean, isolated build environments for single Debian packages. This tool is a direct functional replacement for Fedora's Mock, adapted specifically for Debian-based ecosystems.
**Last updated: 2025-01-22 12:00:00 UTC**
## Purpose
Deb-Mock provides:
- **sbuild Integration**: A wrapper around the native Debian sbuild tool to standardize its command-line arguments and behavior
- **Chroot Management**: Handles the creation, maintenance, and cleanup of the base chroot images used for building
- **Build Metadata Capture**: Captures and standardizes all build output, including logs, .deb files, and .changes files
- **Reproducible Build Enforcement**: Ensures that all build dependencies are satisfied within the isolated environment
## Features
- ✅ Isolated build environments using chroot
- ✅ Integration with Debian's native sbuild tool
- ✅ Standardized build metadata capture
- ✅ Reproducible build verification
- ✅ Clean environment management and cleanup
- ✅ **Chain building** for dependent packages (like Mock's `--chain`)
- ✅ **Shell access** to chroot environments (like Mock's `--shell`)
- ✅ **File operations** between host and chroot (like Mock's `--copyin`/`--copyout`)
- ✅ **Chroot scrubbing** for cleanup without removal (like Mock's `--scrub`)
- ✅ **Core configurations** for popular distributions (like Mock's `mock-core-configs`)
## CI/CD Status
This project uses Forgejo Actions for continuous integration and deployment:
- **Build**: Automatically builds and tests the package on every push
- **Test**: Comprehensive testing of all CLI commands and functionality
- **Release**: Automated releases when tags are pushed
- **Documentation**: Auto-updates README with build status
### Build Status
![Build Status](https://git.raines.xyz/robojerk/deb-mock/actions/workflows/build.yml/badge.svg)
![Test Status](https://git.raines.xyz/robojerk/deb-mock/actions/workflows/test.yml/badge.svg)
![Package Build Status](https://git.raines.xyz/robojerk/deb-mock/actions/workflows/build-deb.yml/badge.svg)
## Installation
### From Forgejo Package Registry (Recommended)
```bash
# Add the Deb-Mock repository from Forgejo
wget -O - https://git.raines.xyz/api/packages/robojerk/debian/gpg.key | sudo apt-key add -
echo 'deb [signed-by=/usr/share/keyrings/forgejo-robojerk.gpg] https://git.raines.xyz/api/packages/robojerk/debian unstable main' | sudo tee /etc/apt/sources.list.d/deb-mock.list
sudo apt update
# Install mock
sudo apt install -y mock
```
### From Debian Repository (Alternative)
```bash
# Add the Mock repository
wget -O - http://debian.raines.xyz/mock.gpg.key | sudo apt-key add -
echo 'deb http://debian.raines.xyz unstable main' | sudo tee /etc/apt/sources.list.d/mock.list
sudo apt update
# Install mock
sudo apt install -y mock
```
### From Source
```bash
# Clone the repository
git clone https://git.raines.xyz/robojerk/deb-mock.git
cd deb-mock
# Install dependencies
sudo apt install sbuild schroot debhelper build-essential debootstrap python3-venv python3-pip
# Create virtual environment and install
python3 -m venv venv
source venv/bin/activate
pip install -e .
```
### Building Debian Package
```bash
# Install build dependencies
sudo apt install -y build-essential devscripts debhelper dh-python python3-all python3-setuptools
# Build the package
dpkg-buildpackage -us -uc -b
# Install the built package
sudo dpkg -i ../deb-mock_*.deb
```
## Usage
### Basic Package Build (Similar to Mock)
```bash
# Build a source package (like: mock -r fedora-35-x86_64 package.src.rpm)
mock build package.dsc
# Build with specific chroot config (like: mock -r debian-bookworm-amd64 package.src.rpm)
mock -r debian-bookworm-amd64 build package.dsc
# Build with specific chroot
mock build --chroot=bookworm-amd64 package.dsc
# Build with specific architecture
mock build --arch=amd64 package.dsc
```
### Advanced Build Options (Mock's advanced CLI options)
```bash
# Skip running tests (like: mock --nocheck)
mock build --no-check package.dsc
# Build in offline mode (like: mock --offline)
mock build --offline package.dsc
# Set build timeout (like: mock --rpmbuild_timeout)
mock build --build-timeout 3600 package.dsc
# Force architecture (like: mock --forcearch)
mock build --force-arch amd64 package.dsc
# Unique extension for buildroot (like: mock --uniqueext)
mock build --unique-ext mybuild package.dsc
# Clean chroot after build (like: mock --cleanup-after)
mock build --cleanup-after package.dsc
# Don't clean chroot after build (like: mock --no-cleanup-after)
deb-mock build --no-cleanup-after package.dsc
```
### Core Configurations (Mock's `mock-core-configs` equivalent)
```bash
# List available core configurations
deb-mock list-configs
# Use core configurations (similar to Mock's -r option)
deb-mock -r debian-bookworm-amd64 build package.dsc
deb-mock -r debian-sid-amd64 build package.dsc
deb-mock -r ubuntu-jammy-amd64 build package.dsc
deb-mock -r ubuntu-noble-amd64 build package.dsc
```
### Chain Building (Mock's `--chain` equivalent)
```bash
# Build multiple packages that depend on each other
deb-mock chain package1.dsc package2.dsc package3.dsc
# Continue building even if one package fails
deb-mock chain --continue-on-failure package1.dsc package2.dsc package3.dsc
# Use core config with chain building
deb-mock -r debian-bookworm-amd64 chain package1.dsc package2.dsc
```
### Package Management (Mock's package management commands)
```bash
# Install build dependencies (like: mock --installdeps package.src.rpm)
deb-mock install-deps package.dsc
# Install packages in chroot (like: mock --install package)
deb-mock install package1 package2 package3
# Update packages in chroot (like: mock --update)
deb-mock update
deb-mock update package1 package2
# Remove packages from chroot (like: mock --remove package)
deb-mock remove package1 package2
# Execute APT commands (like: mock --pm-cmd "command")
deb-mock apt-cmd "update"
deb-mock apt-cmd "install package"
```
### Chroot Management (Similar to Mock)
```bash
# Initialize a new chroot (like: mock -r fedora-35-x86_64 --init)
deb-mock init-chroot bookworm-amd64
# List available chroots (like: mock --list-chroots)
deb-mock list-chroots
# Clean up a chroot (like: mock -r fedora-35-x86_64 --clean)
deb-mock clean-chroot bookworm-amd64
# Scrub a chroot without removing it (like: mock -r fedora-35-x86_64 --scrub)
deb-mock scrub-chroot bookworm-amd64
# Scrub all chroots (like: mock --scrub-all-chroots)
deb-mock scrub-all-chroots
```
### Debugging and Configuration (Mock's debugging commands)
```bash
# Show current configuration (like: mock --debug-config)
deb-mock config
# Show detailed configuration (like: mock --debug-config-expanded)
deb-mock debug-config
deb-mock debug-config --expand
# Show cache statistics
deb-mock cache-stats
# Clean up old cache files
deb-mock cleanup-caches
```
### Shell Access (Mock's `--shell` equivalent)
```bash
# Open a shell in the chroot environment
deb-mock shell
# Open a shell in a specific chroot
deb-mock shell --chroot=sid-amd64
# Use core config for shell access
deb-mock -r debian-sid-amd64 shell
```
### File Operations (Mock's `--copyin`/`--copyout` equivalents)
```bash
# Copy files from host to chroot (like: mock --copyin file.txt /tmp/)
deb-mock copyin file.txt /tmp/
# Copy files from chroot to host (like: mock --copyout /tmp/file.txt .)
deb-mock copyout /tmp/file.txt .
# Use core config with file operations
deb-mock -r debian-bookworm-amd64 copyin file.txt /tmp/
```
### Advanced Usage
```bash
# Build with custom configuration
deb-mock build --config=custom.conf package.dsc
# Build with verbose output
deb-mock build --verbose package.dsc
# Build with debug output
deb-mock build --debug package.dsc
# Keep chroot after build (for debugging)
deb-mock build --keep-chroot package.dsc
```
## Core Configurations
Deb-Mock includes pre-configured build environments for popular Debian-based distributions, similar to Mock's `mock-core-configs` package:
### **Debian Family**
- `debian-bookworm-amd64` - Debian 12 (Bookworm) - AMD64
- `debian-sid-amd64` - Debian Unstable (Sid) - AMD64
### **Ubuntu Family**
- `ubuntu-jammy-amd64` - Ubuntu 22.04 LTS (Jammy) - AMD64
- `ubuntu-noble-amd64` - Ubuntu 24.04 LTS (Noble) - AMD64
### **Usage Examples**
```bash
# Build for Debian Bookworm
deb-mock -r debian-bookworm-amd64 build package.dsc
# Build for Ubuntu Jammy
deb-mock -r ubuntu-jammy-amd64 build package.dsc
# Build for Debian Sid (unstable)
deb-mock -r debian-sid-amd64 build package.dsc
```
## Configuration
Deb-Mock uses YAML configuration files to define build environments. See `docs/configuration.md` for detailed configuration options.
### Example Configuration (Similar to Mock configs)
```yaml
# Basic configuration
chroot_name: bookworm-amd64
architecture: amd64
suite: bookworm
output_dir: ./output
keep_chroot: false
verbose: false
debug: false
# Build environment
build_env:
DEB_BUILD_OPTIONS: parallel=4,nocheck
DEB_BUILD_PROFILES: nocheck
# Build options
build_options:
- --verbose
- --no-run-lintian
```
## Comparison with Fedora Mock
| Mock Feature | Deb-Mock Equivalent | Status |
|--------------|-------------------|--------|
| `mock -r config package.src.rpm` | `deb-mock -r config package.dsc` | ✅ |
| `mock --chain` | `deb-mock chain package1.dsc package2.dsc` | ✅ |
| `mock --shell` | `deb-mock shell` | ✅ |
| `mock --copyin` | `deb-mock copyin` | ✅ |
| `mock --copyout` | `deb-mock copyout` | ✅ |
| `mock --scrub` | `deb-mock scrub-chroot` | ✅ |
| `mock --init` | `deb-mock init-chroot` | ✅ |
| `mock --clean` | `deb-mock clean-chroot` | ✅ |
| `mock --list-chroots` | `deb-mock list-chroots` | ✅ |
| `mock --installdeps` | `deb-mock install-deps` | ✅ |
| `mock --install` | `deb-mock install` | ✅ |
| `mock --update` | `deb-mock update` | ✅ |
| `mock --remove` | `deb-mock remove` | ✅ |
| `mock --pm-cmd` | `deb-mock apt-cmd` | ✅ |
| `mock --nocheck` | `deb-mock --no-check` | ✅ |
| `mock --offline` | `deb-mock --offline` | ✅ |
| `mock --forcearch` | `deb-mock --force-arch` | ✅ |
| `mock --debug-config` | `deb-mock debug-config` | ✅ |
| `mock-core-configs` | `deb-mock list-configs` | ✅ |
## Development
This project is part of the three-tool system for Debian build and assembly:
- **Deb-Mock** (this project): Low-level build environment utility
- **Deb-Orchestrator**: Central build management system
- **Tumbi-Assembler**: Distribution composition tool
## License
[License information to be added]
## Contributing
[Contribution guidelines to be added]

1
README.md Symbolic link
View file

@ -0,0 +1 @@
mock/README.md

0
behave/.vcs-diff-lint.yml Normal file
View file

14
behave/README.md Normal file
View file

@ -0,0 +1,14 @@
BDD for Mock
============
This test-suite can destroy your system! Not intentionally, but some steps
require us to use root (e.g. install or remove packages). **Never** execute
this test suite on your host system, allocate some disposable machine.
How to run the tests
--------------------
1. Install the Mock RPM that you want to test.
2. Run `$ behave` command in this directory, with `--tags tagname` if you want
to test only subset of all provided scenarios.

79
behave/environment.py Normal file
View file

@ -0,0 +1,79 @@
"""
Global configuration for Mock's behave tests
"""
import os
import pwd
import random
import shutil
import string
import tempfile
import requests
from testlib.mock import Mock
from testlib.commands import no_output
def _random_string(length):
return ''.join(random.choices(string.ascii_lowercase + string.digits,
k=length))
def _download(context, url):
print(f'Downloading {url}')
req = requests.get(url, timeout=60)
filename = os.path.join(context.workdir, os.path.basename(url))
with open(filename, 'wb') as dfd:
dfd.write(req.content)
return filename
def _download_rpm(context, rpm):
files = {
"always-installable":
"repo/always-installable-1-0.fc32.noarch.rpm",
"buildrequires-always-installable":
"buildrequires-always-installable-1-0.src.rpm",
}
return _download(context, "/".join([context.test_storage, files[rpm]]))
def before_all(context):
""" executed before all the testing starts, only once per behave run """
context.uniqueext = _random_string(8)
context.uniqueext_used = False
# detect the default used chroot from default.cfg link
default_config = os.readlink("/etc/mock/default.cfg")
context.chroot = default_config[:-4] # drop cfg suffix
context.test_storage = (
"https://github.com/"
"rpm-software-management/mock-test-data/raw/main/")
context.download = lambda url: _download(context, url)
context.download_rpm = lambda rpm: _download_rpm(context, rpm)
context.next_mock_options = []
def _cleanup_workdir(context):
shutil.rmtree(context.workdir)
context.workdir = None
context.custom_config = ""
def before_scenario(context, _scenario):
""" execute before - once for each - scenario """
context.workdir = tempfile.mkdtemp(prefix="mock-behave-tests-")
context.custom_config = ""
context.add_cleanup(_cleanup_workdir, context)
context.mock = Mock(context)
context.add_repos = []
context.current_user = pwd.getpwuid(os.getuid())[0]
def after_scenario(context, _scenario):
""" execute after - and for each - scenario """
with no_output():
context.mock.clean()

0
behave/features/__init__.py Normal file
View file

17
behave/features/add-repo.feature Normal file
View file

@ -0,0 +1,17 @@
Feature: The --addrepo commandline option.
Background:
Given an unique mock namespace
And pre-intitialized chroot
Scenario: Test that --addrepo works
Given a custom third-party repository is used for builds
When a build is depending on third-party repo requested
Then the build succeeds
Scenario: Test that --addrepo LOCAL_DIR works
Given a created local repository
And the local repo contains a "always-installable" RPM
And the local repo is used for builds
When a build which requires the "always-installable" RPM is requested
Then the build succeeds

8
behave/features/auto-download-of-srpm.feature Normal file
View file

@ -0,0 +1,8 @@
Feature: Check that we download source RPMs URLs
@autodownload
Scenario: Mock downloads SRPMs in --rebuild mode
Given an unique mock namespace
And pre-intitialized chroot
When an online source RPM is rebuilt
Then the build succeeds

19
behave/features/buildroot-image.feature Normal file
View file

@ -0,0 +1,19 @@
Feature: Mock 6.0+ supports --bootstrap-image feature and OCI buildroot exports
@buildroot_image
Scenario: Use image from registry for buildroot preparation
Given an unique mock namespace
Given mock is always executed with "--buildroot-image registry.fedoraproject.org/fedora:rawhide"
When an online source RPM is rebuilt against fedora-rawhide-x86_64
Then the build succeeds
@buildroot_image
Scenario: Image from 'export_buildroot_image' works with --buildroot-image
Given an unique mock namespace
Given next mock call uses --enable-plugin=export_buildroot_image option
# No need to do a full build here!
When deps for python-copr-999-1.src.rpm are calculated against fedora-rawhide-x86_64
And OCI tarball from fedora-rawhide-x86_64 backed up and will be used
And the fedora-rawhide-x86_64 chroot is scrubbed
And an online SRPM python-copr-999-1.src.rpm is rebuilt against fedora-rawhide-x86_64
Then the build succeeds

19
behave/features/chroot-scan.feature Normal file
View file

@ -0,0 +1,19 @@
Feature: The chroot_scan plugin
@chroot_scan
Scenario: Check that chroot_scan works and file permissions are correct
Given chroot_scan is enabled for dnf5.log
And an unique mock namespace
When an online source RPM is rebuilt
Then the build succeeds
And dnf5.log file is in chroot_scan result dir
And ownership of all chroot_scan files is correct
@chroot_scan
Scenario: Check that chroot_scan tarball is created correctly
Given an unique mock namespace
And chroot_scan is enabled for dnf5.log
And chroot_scan is configured to produce tarball
When an online source RPM is rebuilt
Then the build succeeds
And chroot_scan tarball has correct perms and provides dnf5.log

7
behave/features/cmdline-errors.feature Normal file
View file

@ -0,0 +1,7 @@
Feature: Test error reporting from argument parser
@errors
Scenario: The --resultdir option is incompatible with --chain
When mock is run with "--resultdir /tmp/dir --chain" options
Then the exit code is 5
And the one-liner error contains "ERROR: The --chain mode doesn't support --resultdir"

24
behave/features/dnf4.feature Normal file
View file

@ -0,0 +1,24 @@
Feature: Mock is able to work with dnf4 chroots
@dnf4 @no-bootstrap
Scenario: Building a DNF4 chroot without bootstrap chroot
Given an unique mock namespace
And mock is always executed with "--no-bootstrap-chroot --config-opts=dnf_warning=False"
When an online source RPM is rebuilt against centos-stream+epel-9-x86_64
Then the build succeeds
@dnf4 @no-bootstrap-image
Scenario: Building in DNF4 chroot with dnf4 on host, without bootstrap image
Given an unique mock namespace
And the python3-dnf package is installed on host
And mock is always executed with "--no-bootstrap-image"
When an online source RPM is rebuilt against centos-stream+epel-9-x86_64
Then the build succeeds
@dnf4 @no-bootstrap-image @with-dnf4
Scenario: Building a DNF4 chroot without dnf4 on host, without bootstrap image
Given an unique mock namespace
And the python3-dnf package not installed on host
And mock is always executed with "--no-bootstrap-image"
When an online source RPM is rebuilt against centos-stream+epel-9-x86_64
Then the build succeeds

15
behave/features/dnf5.feature Normal file
View file

@ -0,0 +1,15 @@
Feature: Mock correctly works with DNF5
@dnf5 @no-bootstrap
Scenario: Building in Rawhide with DNF5, without bootstrap chroot
Given mock is always executed with "--no-bootstrap-chroot"
And an unique mock namespace
When an online source RPM is rebuilt
Then the build succeeds
@dnf5 @no-bootstrap-image
Scenario: Building in Rawhide with DNF5 with DNF5 on host
Given mock is always executed with "--no-bootstrap-image"
And an unique mock namespace
When an online source RPM is rebuilt
Then the build succeeds

19
behave/features/hermetic-build.feature Normal file
View file

@ -0,0 +1,19 @@
Feature: Mock 5.7+ supports hermetic builds
@hermetic_build
Scenario: Hermetic build against a DNF5 distribution
Given an unique mock namespace
When deps for python-copr-999-1.src.rpm are calculated against fedora-rawhide-x86_64
And a local repository is created from lockfile
And a hermetic build is retriggered with the lockfile and repository
Then the build succeeds
And the produced lockfile is validated properly
@hermetic_build
Scenario: Hermetic build against a DNF4 distribution
Given an unique mock namespace
When deps for mock-test-bump-version-1-0.src.rpm are calculated against centos-stream+epel-9-x86_64
And a local repository is created from lockfile
And a hermetic build is retriggered with the lockfile and repository
Then the build succeeds
And the produced lockfile is validated properly

6
behave/features/library.feature Normal file
View file

@ -0,0 +1,6 @@
Feature: Test the "library" methods
@library @simple_load_config
Scenario: The --resultdir option is incompatible with --chain
When simple_load_config method from mockbuild.config is called with fedora-rawhide-x86_64 args
Then the return value contains a field "description=Fedora Rawhide"

8
behave/features/list-configs.feature Normal file
View file

@ -0,0 +1,8 @@
Feature: The --list-chroots commandline option
@list_chroots
Scenario: Test --list-chroots
When mock is run with "--list-chroots" options
Then the exit code is 0
And stdout contains "fedora-rawhide-x86_64 Fedora Rawhide"
And stdout contains "rhel+epel-8-x86_64 RHEL 8 + EPEL"

8
behave/features/scrub-all-chroots.feature Normal file
View file

@ -0,0 +1,8 @@
Feature: Clean all chroots
@clan_all_chroots
Scenario: The --scrub-all-chroots works as expected
When mock is run with "--shell true" options
And mock is run with "--scrub-all-chroots" options
Then the directory /var/lib/mock is empty
And the directory /var/cache/mock is empty

15
behave/pylintrc Normal file
View file

@ -0,0 +1,15 @@
# mock pylint configuration for behave/ subdir
[MESSAGES CONTROL]
# Reasoning for wide warning ignore
# ---------------------------------
# import-error
# This is here to silence Pylint in CI where we do not have all the
# build/runtime dependencies installed.
# cyclic-import
# Seems like cyclic-import is just a style check which is not going to be
# fixed: https://github.com/PyCQA/pylint/issues/6983
# function-redefined
# This is a Behave's policy to create all step methods as `step_impl()`.
disable=import-error,cyclic-import,function-redefined

333
behave/steps/other.py Normal file
View file

@ -0,0 +1,333 @@
""" Generic testing steps """
import glob
import importlib
import json
import os
import shutil
import tarfile
import tempfile
from pathlib import Path
from hamcrest import (
assert_that,
contains_string,
ends_with,
equal_to,
has_item,
has_entries,
has_length,
not_,
)
import jsonschema
from behave import given, when, then # pylint: disable=no-name-in-module
from testlib.commands import run, no_output
# flake8: noqa
# pylint: disable=missing-function-docstring,function-redefined
# mypy: disable-error-code="no-redef"
def _first_int(string, max_lines=20):
for line in string.split("\n")[:max_lines]:
if not line:
continue
first_word = line.split()[0]
if first_word.isdigit():
return first_word
raise RuntimeError("unexpected dnf history output")
def add_cleanup_last_transaction(context):
# DNF5 support https://github.com/rpm-software-management/dnf5/issues/140
dnf = ["sudo", "/usr/bin/dnf", "history"]
_, out, _ = run(dnf + ["list"])
transaction_id = _first_int(out)
def _revert_transaction(_context):
cmd = dnf + ["undo", transaction_id, "-y"]
with no_output():
assert_that(run(cmd)[0], equal_to(0))
context.add_cleanup(_revert_transaction, context)
@given('an unique mock namespace')
def step_impl(context):
print(f"using uniqueext {context.uniqueext}")
context.uniqueext_used = True
@given('the {package} package {state} installed on host')
def step_impl(context, package, state):
"""
Install the package, and uninstall in post- action. If state is "not", then
just check it is not installed.
"""
is_installed, _, _ = run(["rpm", "-q", package])
# exit_status 0 => installed
is_installed = bool(not is_installed)
if "not" in state:
if not is_installed:
return # nothing to do
# Remove the package and schedule its removal
cmd = ["sudo", "dnf", "-y", "remove", package]
assert_that(run(cmd)[0], equal_to(0))
# schedule removal
add_cleanup_last_transaction(context)
return
if is_installed:
return
# install the package, and schedule removal
def _uninstall_pkg(_context):
cmd = ["sudo", "dnf", "-y", "remove", package]
with no_output():
assert_that(run(cmd)[0], equal_to(0))
cmd = ["sudo", "dnf", "-y", "install", package]
assert_that(run(cmd)[0], equal_to(0))
context.add_cleanup(_uninstall_pkg, context)
@given('pre-intitialized chroot')
def step_impl(context):
context.mock.init()
@given('a custom third-party repository is used for builds')
def step_impl(context):
context.add_repos.append(
"https://raw.githubusercontent.com/rpm-software-management/"
"mock-test-data/main/repo/"
)
@given("a created local repository")
def step_impl(context):
context.local_repo = tempfile.mkdtemp(prefix="mock-tests-local-repo-")
run(["createrepo_c", context.local_repo])
@given('the local repo contains a "{rpm}" RPM')
def step_impl(context, rpm):
rpm = context.download_rpm(rpm)
shutil.move(rpm, context.local_repo)
run(["createrepo_c", context.local_repo])
@given("the local repo is used for builds")
def step_impl(context):
context.add_repos.append(context.local_repo)
@when('a build is depending on third-party repo requested')
@when('a build which requires the "always-installable" RPM is requested')
def step_impl(context):
local_file = context.download_rpm("buildrequires-always-installable")
context.mock.rebuild([local_file])
@then('the build succeeds')
def step_impl(context):
assert os.path.exists(context.mock.resultdir)
rpms = glob.glob(os.path.join(context.mock.resultdir, "*.rpm"))
print("Found RPMs: " + ", ".join(rpms))
assert_that(rpms, has_item(ends_with(".src.rpm")))
assert_that(rpms, has_item(not_(ends_with(".src.rpm"))))
@when('mock is run with "{options}" options')
def step_impl(context, options):
options = options.split()
context.last_cmd = run(['mock'] + options)
@given('mock is always executed with "{options}"')
def step_impl(context, options):
options = options.split()
context.mock.common_opts += options
@then('the exit code is {code}')
def step_impl(context, code):
code = int(code)
assert_that(context.last_cmd[0], equal_to(code))
@then('the one-liner error contains "{expected_message}"')
def step_impl(context, expected_message):
err = context.last_cmd[2].splitlines()
assert_that(err, has_length(1))
assert_that(err[0], contains_string(expected_message))
def _rebuild_online(context, chroot=None, package=None):
package = package or "mock-test-bump-version-1-0.src.rpm"
url = context.test_storage + package
if chroot:
context.mock.chroot = chroot
context.mock.chroot_opt = chroot
context.mock.rebuild([url])
@when('an online source RPM is rebuilt')
def step_impl(context):
_rebuild_online(context)
@when('an online source RPM is rebuilt against {chroot}')
def step_impl(context, chroot):
_rebuild_online(context, chroot)
@when('an online SRPM {package} is rebuilt against {chroot}')
def step_impl(context, package, chroot):
_rebuild_online(context, chroot, package)
@then('{output} contains "{text}"')
def step_impl(context, output, text):
index = 1 if output == "stdout" else 2
real_output = context.last_cmd[index]
assert_that(real_output, contains_string(text))
@when('{call} method from {module} is called with {args} args')
def step_impl(context, call, module, args):
imp = importlib.import_module(module)
method = getattr(imp, call)
args = args.split()
context.last_method_call_retval = method(*args)
@then('the return value contains a field "{field}={value}"')
def step_impl(context, field, value):
assert_that(context.last_method_call_retval[field],
equal_to(value))
@when('deps for {srpm} are calculated against {chroot}')
def step_impl(context, srpm, chroot):
url = context.test_storage + srpm
context.mock.calculate_deps(url, chroot)
@when('a local repository is created from lockfile')
def step_impl(context):
mock_run = context.mock_runs["calculate-build-deps"][-1]
lockfile = mock_run["lockfile"]
context.local_repo = tempfile.mkdtemp(prefix="mock-tests-local-repo-")
cmd = ["mock-hermetic-repo", "--lockfile", lockfile, "--output-repo",
context.local_repo]
assert_that(run(cmd)[0], equal_to(0))
@when('a hermetic build is retriggered with the lockfile and repository')
def step_impl(context):
context.mock.hermetic_build()
@then('the produced lockfile is validated properly')
def step_impl(context):
mock_run = context.mock_runs["calculate-build-deps"][-1]
lockfile = mock_run["lockfile"]
with open(lockfile, "r", encoding="utf-8") as fd:
lockfile_data = json.load(fd)
assert_that(lockfile_data["buildroot"]["rpms"],
has_item(has_entries({"name": "filesystem"})))
schemafile = os.path.join(os.path.dirname(__file__), '..', '..',
"mock", "docs",
"buildroot-lock-schema-1.1.0.json")
with open(schemafile, "r", encoding="utf-8") as fd:
schema = json.load(fd)
jsonschema.validate(lockfile_data, schema)
@given('next mock call uses {option} option')
def step_impl(context, option):
context.next_mock_options.append(option)
@then("the directory {directory} is empty")
def step_impl(_, directory):
assert_that(os.path.exists(directory), equal_to(True))
assert_that(not os.listdir(directory), equal_to(True))
@given('chroot_scan is enabled for {regex}')
def step_impl(context, regex):
context.custom_config += f"""\
config_opts['plugin_conf']['chroot_scan_enable'] = True
config_opts['plugin_conf']['chroot_scan_opts']['regexes'] = ["{regex}"]
config_opts['plugin_conf']['chroot_scan_opts']['only_failed'] = False
"""
@then('{file} file is in chroot_scan result dir')
def step_impl(context, file):
resultdir = os.path.join(context.mock.resultdir, 'chroot_scan')
# Find the expected file
found = False
print("resultdir: ", resultdir)
for _, _, files in os.walk(resultdir):
for f in files:
print(f)
if f == file:
found = True
break
if found:
break
assert_that(found, equal_to(True))
@given('chroot_scan is configured to produce tarball')
def step_impl(context):
context.custom_config += """\
config_opts['plugin_conf']['chroot_scan_opts']['write_tar'] = True
"""
@then('ownership of all chroot_scan files is correct')
def step_impl(context):
resultdir = os.path.join(context.mock.resultdir, 'chroot_scan')
for root, dirs, files in os.walk(resultdir):
for f in files + dirs:
path = Path(root) / f
assert_that(path.group(), equal_to("mock"))
assert_that(path.owner(), equal_to(context.current_user))
@then('chroot_scan tarball has correct perms and provides dnf5.log')
def step_impl(context):
tarball = Path(context.mock.resultdir, 'chroot_scan.tar.gz')
with tarfile.open(tarball, 'r:gz') as tarf:
for file in tarf.getnames():
if file.endswith("dnf5.log"):
break
assert_that(tarball.group(), equal_to("mock"))
assert_that(tarball.owner(), equal_to(context.current_user))
@when('OCI tarball from {chroot} backed up and will be used')
def step_impl(context, chroot):
resultdir = f"/var/lib/mock/{chroot}-{context.uniqueext}/result"
tarball_base = "buildroot-oci.tar"
tarball = os.path.join(resultdir, tarball_base)
assert os.path.exists(tarball)
shutil.copy(tarball, context.workdir)
context.mock.buildroot_image = os.path.join(context.workdir, tarball_base)
@when('the {chroot} chroot is scrubbed')
def step_impl(context, chroot):
context.mock.scrub(chroot)

1
behave/testlib/__init__.py Normal file
View file

@ -0,0 +1 @@
""" Helper library for Mock's BDD """

62
behave/testlib/commands.py Normal file
View file

@ -0,0 +1,62 @@
"""
Executing commands in Mock's behave test suite.
"""
from contextlib import contextmanager
import io
import shlex
import subprocess
import sys
@contextmanager
def no_output():
"""
Suppress stdout/stderr when it is not captured by behave
https://github.com/behave/behave/issues/863
"""
real_out = sys.stdout, sys.stderr
sys.stdout = io.StringIO()
sys.stderr = io.StringIO()
yield
sys.stdout, sys.stderr = real_out
def quoted_cmd(cmd):
""" shell quoted cmd array as string """
return " ".join(shlex.quote(arg) for arg in cmd)
def run(cmd):
"""
Return exitcode, stdout, stderr. It's bad there's no such thing in behave
directly.
"""
try:
with subprocess.Popen(
cmd,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
universal_newlines=True,
) as process:
stdout, stderr = process.communicate()
print(f"Exit code: {process.returncode} in: {quoted_cmd(cmd)}")
if stdout:
print("stdout:")
print(stdout)
if stderr:
print("stderr:")
print(stderr)
return process.returncode, stdout, stderr
except (FileNotFoundError, PermissionError) as e:
print(f"Error running command {quoted_cmd(cmd)}: {e}")
return -1, "", str(e)
def run_check(cmd):
""" run, but check nonzero exit status """
retcode, stdout, stderr = run(cmd)
if retcode != 0:
raise RuntimeError(f"Command failed with return code {retcode}: "
f"{quoted_cmd(cmd)}\n{stderr}")
return stdout, stderr

160
behave/testlib/mock.py Normal file
View file

@ -0,0 +1,160 @@
"""
Stateful "Mock" command object.
"""
from pathlib import Path
import os
from testlib.commands import run_check
class Mock:
""" /bin/mock wrapper """
def __init__(self, context):
self.context = context
self.common_opts = []
# The chroot being used (e.g. fedora-rawhide-x86_64). If None is used,
# it is automatically set to the default.cfg target.
self.chroot = context.chroot
# The -r/--root option being used. Sometimes it is convenient to use a
# custom config file that includes `fedora-rawhide-x86_64`
# configuration without overriding the `config_opts["root"]" opt.
# None means "no option used".
self.chroot_opt = None
# Sometimes we use multiple chroots. Clean them all.
self.more_cleanups = []
context.mock_runs = {
"init": [],
"rebuild": [],
"scrubs": [],
"calculate-build-deps": [],
}
self.buildroot_image = None
@property
def basecmd(self):
""" return the pre-configured mock base command """
cmd = ["mock"]
if self.chroot_opt:
cmd += ["-r", self.chroot_opt]
if self.context.uniqueext_used:
cmd += ["--uniqueext", self.context.uniqueext]
for repo in self.context.add_repos:
cmd += ["-a", repo]
if self.common_opts:
cmd += self.common_opts
if self.context.next_mock_options:
cmd += self.context.next_mock_options
self.context.next_mock_options = []
return cmd
def init(self):
""" initialize chroot """
out, err = run_check(self.basecmd + ["--init"])
self.context.mock_runs['init'] += [{
"status": 0,
"out": out,
"err": err,
}]
return out, err
def scrub(self, chroot=None):
""" initialize chroot """
opts = ["--scrub=all"]
if chroot is not None:
opts += ["-r", chroot]
out, err = run_check(self.basecmd + opts)
self.context.mock_runs['scrubs'] += [{
"status": 0,
"out": out,
"err": err,
}]
return out, err
def rebuild(self, srpms):
""" Rebuild source RPM(s) """
chrootspec = []
if self.context.custom_config:
config_file = Path(self.context.workdir) / "custom.cfg"
with config_file.open("w") as fd:
fd.write(f"include('{self.chroot}.cfg')\n")
fd.write(self.context.custom_config)
chrootspec = ["-r", str(config_file)]
opts = []
if self.buildroot_image:
# use and drop
opts += ["--buildroot-image", self.buildroot_image]
self.buildroot_image = None
opts += ["--rebuild"] + srpms
out, err = run_check(self.basecmd + chrootspec + opts)
self.context.mock_runs['rebuild'] += [{
"status": 0,
"out": out,
"err": err,
"srpms": srpms,
}]
def calculate_deps(self, srpm, chroot):
"""
Call Mock with --calculate-build-dependencies and produce lockfile
"""
call = self.basecmd + ["-r", chroot]
self.more_cleanups += [call]
out, err = run_check(call + ["--calculate-build-dependencies", srpm])
self.chroot = chroot
self.context.mock_runs["calculate-build-deps"].append({
"status": 0,
"out": out,
"err": err,
"srpm": srpm,
"chroot": chroot,
"lockfile": os.path.join(self.resultdir, "buildroot_lock.json")
})
def hermetic_build(self):
"""
From the previous calculate_deps() run, perform hermetic build
"""
mock_calc = self.context.mock_runs["calculate-build-deps"][-1]
out, err = run_check(self.basecmd + [
"--hermetic-build", mock_calc["lockfile"], self.context.local_repo,
mock_calc["srpm"]
])
self.context.mock_runs["rebuild"].append({
"status": 0,
"out": out,
"err": err,
})
# We built into a hermetic-build.cfg!
self.chroot = "hermetic-build"
self.chroot_opt = "hermetic-build"
def clean(self):
""" Clean chroot, but keep dnf/yum caches """
args = ["--scrub=bootstrap", "--scrub=root-cache", "--scrub=chroot"]
run_check(self.basecmd + args)
for call in self.more_cleanups:
run_check(call + args)
@property
def resultdir(self):
""" Where the results are stored """
resultdir = "/var/lib/mock/" + self.chroot
if self.context.uniqueext_used:
resultdir += "-" + self.context.uniqueext
return resultdir + "/result"
def assert_is_subset(set_a, set_b):
""" assert that SET_A is subset of SET_B """
if set_a.issubset(set_b):
return
raise AssertionError(f"Set {set_a} is not a subset of {set_b}")

117
config.yaml Normal file
View file

@ -0,0 +1,117 @@
# deb-mock configuration file
# Debian's equivalent to Fedora's Mock build environment manager
# Global configuration
global:
basedir: "/var/lib/deb-mock"
rootdir: "/var/lib/deb-mock/chroots"
resultdir: "/var/lib/deb-mock/results"
cache_dir: "/var/cache/deb-mock"
log_dir: "/var/log/deb-mock"
# Default chroot configuration
defaults:
distribution: "bookworm"
architecture: "amd64"
mirror: "http://deb.debian.org/debian"
security_mirror: "http://deb.debian.org/debian-security"
updates_mirror: "http://deb.debian.org/debian"
# Package installation
install_packages:
- "build-essential"
- "fakeroot"
- "devscripts"
- "debhelper"
- "dh-make"
- "sbuild"
- "schroot"
# Build dependencies
build_dependencies:
- "build-essential"
- "fakeroot"
- "devscripts"
- "debhelper"
- "dh-make"
# Chroot profiles
profiles:
bookworm-amd64:
distribution: "bookworm"
architecture: "amd64"
mirror: "http://deb.debian.org/debian"
security_mirror: "http://deb.debian.org/debian-security"
updates_mirror: "http://deb.debian.org/debian"
components: ["main", "contrib", "non-free"]
bookworm-arm64:
distribution: "bookworm"
architecture: "arm64"
mirror: "http://deb.debian.org/debian"
security_mirror: "http://deb.debian.org/debian-security"
updates_mirror: "http://deb.debian.org/debian"
components: ["main", "contrib", "non-free"]
sid-amd64:
distribution: "sid"
architecture: "amd64"
mirror: "http://deb.debian.org/debian"
components: ["main", "contrib", "non-free"]
# Plugin configuration
plugins:
mount:
enabled: true
mount_points:
- source: "/proc"
target: "/proc"
type: "proc"
- source: "/sys"
target: "/sys"
type: "sysfs"
- source: "/dev"
target: "/dev"
type: "bind"
cache:
enabled: true
root_cache: true
package_cache: true
build_cache: true
security:
enabled: true
user_isolation: true
network_isolation: true
resource_limits: true
# Integration settings
integration:
deb_orchestrator_url: "http://localhost:8080"
deb_compose_url: "http://localhost:8080"
# Build tools
sbuild_path: "/usr/bin/sbuild"
schroot_path: "/usr/bin/schroot"
debootstrap_path: "/usr/sbin/debootstrap"
# Package managers
apt_path: "/usr/bin/apt"
dpkg_path: "/usr/bin/dpkg"
# Logging configuration
logging:
level: "INFO"
format: "text"
file: "/var/log/deb-mock/deb-mock.log"
max_size: "100MB"
max_files: 5
# Performance settings
performance:
parallel_downloads: 4
max_retries: 3
timeout: 3600
memory_limit: "2G"
disk_limit: "10G"

334
docs/FAQ.md
View file

@ -1,327 +1,37 @@
# Deb-Mock FAQ ---
layout: default
title: FAQ
---
## Frequently Asked Questions ## FAQ
This FAQ addresses common issues and questions about **Deb-Mock**, a Debian-focused alternative to Fedora's Mock. ### How to preserve environment variable in chroot
### Environment Variables in Chroot Q: I put
**Q: I set environment variables in my configuration, but they're not preserved in the chroot environment.** config_opts['environment']['VAR'] = os.environ['VAR']
**A:** This is a common issue with chroot environments. **Deb-Mock** provides several solutions: into config, but the variable is not preserved.
#### Solution 1: Use the `--preserve-env` flag A: Environment is sanitized by consolehelper when elevating UID. You need to alter `/etc/security/console.apps/mock` too.
```bash
deb-mock shell --preserve-env
```
#### Solution 2: Configure specific environment variables ### I cannot build Fedora or RHEL8 beta package on RHEL/CentOS 7
```yaml
# deb-mock.yaml
preserve_environment:
- CC
- CXX
- CFLAGS
- CXXFLAGS
- DEB_BUILD_OPTIONS
- CCACHE_DIR
```
#### Solution 3: Disable environment sanitization Q: I am on RHEL 7 and when I run `mock -r fedora-28-x86_64 --init` (similarly for rhelbeta-8-x86_64) I get:
```yaml
# deb-mock.yaml
environment_sanitization: false
```
#### Solution 4: Use the `--env-var` option ....
```bash ---> Package patch.x86_64 0:2.7.6-4.fc28 will be installed
deb-mock shell --env-var CC=gcc --env-var CFLAGS="-O2" ---> Package redhat-rpm-config.noarch 0:108-1.fc28 will be installed
``` Error: Invalid version flag: if
**Why this happens:** Chroot environments sanitize environment variables for security reasons. **Deb-Mock** provides controlled ways to preserve necessary variables while maintaining security. A: This is not Mock error. This is because redhat-rpm-config in Fedora 28 (& RHEL 8 Beta) contains rich dependency: `Requires: (annobin if gcc)`. This is a new rpm's feature and is not recognized by RHEL7's rpm. When you are installing the fedora-28 chroot, mock is using host's rpm. And RHEL7 rpm cannot install this package, because of the new feature, which does not recognize.
### Cross-Distribution Package Building The solution is to use mock's [bootstrap feature](https://rpm-software-management.github.io/mock/Release-Notes-1.4.1#bootstrap-chroot). It is not enabled by default, because there are still some [unresolved issues](https://github.com/rpm-software-management/mock/labels/bootstrap), but generally it works. Try:
**Q: I'm on Debian Stable but need to build packages for Debian Sid. How can I do this?** mock -r fedora-28-x86_64 --init --bootstrap-chroot
**A:** Use **Deb-Mock**'s bootstrap chroot feature, similar to Mock's `--bootstrap-chroot`: ### When I can expect next release
#### Solution: Use bootstrap chroot Q: A developer merged my pull-request. When I can expect the next release with my fix?
```bash
# Create a Sid chroot using bootstrap
deb-mock init-chroot debian-sid-amd64 --suite sid --bootstrap
# Build packages in the Sid chroot A: I try to stick to two month cadence. Check the last release date and add two months and you can set your expectation. Of course things like Christmas or summer holidays can add a few weeks. On the other hand the branching event in Fedora can make it shorter as I usually do a mock release a day before Fedora branches, because I had to add new configs there anyway.
deb-mock -r debian-sid-amd64 build package.dsc
```
#### Configuration-based approach
```yaml
# deb-mock.yaml
use_bootstrap_chroot: true
bootstrap_chroot_name: "debian-stable-bootstrap"
suite: "sid"
architecture: "amd64"
```
**Why this is needed:** Building packages for newer distributions on older systems can fail due to package manager version incompatibilities. Bootstrap chroots create a minimal environment with the target distribution's tools to build the final chroot.
### Build Dependencies Not Found
**Q: My build fails with "Package not found" errors for build dependencies.**
**A:** This usually indicates repository or dependency resolution issues:
#### Solution 1: Update the chroot
```bash
deb-mock update-chroot debian-bookworm-amd64
```
#### Solution 2: Check repository configuration
```yaml
# deb-mock.yaml
mirror: "http://deb.debian.org/debian/"
security_mirror: "http://security.debian.org/debian-security/"
backports_mirror: "http://deb.debian.org/debian/"
```
#### Solution 3: Install missing dependencies manually
```bash
deb-mock shell debian-bookworm-amd64
# Inside chroot:
apt-get update
apt-get install build-essential devscripts
```
#### Solution 4: Use verbose output for debugging
```bash
deb-mock --verbose build package.dsc
```
### Chroot Creation Fails
**Q: I get permission errors when creating chroots.**
**A:** Chroot creation requires root privileges:
#### Solution 1: Use sudo
```bash
sudo deb-mock init-chroot debian-bookworm-amd64
```
#### Solution 2: Add user to appropriate groups
```bash
sudo usermod -a -G sbuild $USER
# Log out and back in
```
#### Solution 3: Check disk space
```bash
df -h /var/lib/deb-mock
```
#### Solution 4: Verify debootstrap installation
```bash
sudo apt-get install debootstrap schroot
```
### Build Performance Issues
**Q: My builds are slow. How can I speed them up?**
**A:** **Deb-Mock** provides several performance optimization features:
#### Solution 1: Enable caching
```yaml
# deb-mock.yaml
use_root_cache: true
use_package_cache: true
use_ccache: true
```
#### Solution 2: Use parallel builds
```yaml
# deb-mock.yaml
parallel_jobs: 8
parallel_compression: true
```
#### Solution 3: Use tmpfs for temporary files
```yaml
# deb-mock.yaml
use_tmpfs: true
tmpfs_size: "4G"
```
#### Solution 4: Clean up old caches
```bash
deb-mock cleanup-caches
```
### Network and Proxy Issues
**Q: I'm behind a proxy and can't download packages.**
**A:** Configure proxy settings in your configuration:
#### Solution: Configure proxy
```yaml
# deb-mock.yaml
http_proxy: "http://proxy.example.com:3128"
https_proxy: "http://proxy.example.com:3128"
no_proxy: "localhost,127.0.0.1"
```
### Package Signing Issues
**Q: How do I sign packages with GPG keys?**
**A:** **Deb-Mock** supports package signing through configuration:
#### Solution: Configure signing
```yaml
# deb-mock.yaml
sign_packages: true
gpg_key: "your-gpg-key-id"
gpg_passphrase: "your-passphrase" # Use environment variable in production
```
### Debugging Build Failures
**Q: My build failed. How can I debug it?**
**A:** **Deb-Mock** provides several debugging tools:
#### Solution 1: Use verbose output
```bash
deb-mock --verbose build package.dsc
```
#### Solution 2: Keep chroot for inspection
```bash
deb-mock build package.dsc --keep-chroot
deb-mock shell # Inspect the failed build environment
```
#### Solution 3: Check build logs
```bash
# Build logs are automatically captured
ls -la ./output/
cat ./output/build.log
```
#### Solution 4: Use debug mode
```bash
deb-mock --debug build package.dsc
```
### Chain Building Issues
**Q: My chain build fails because later packages can't find earlier packages.**
**A:** This is a common issue with chain builds:
#### Solution 1: Use the chain command
```bash
deb-mock chain package1.dsc package2.dsc package3.dsc
```
#### Solution 2: Continue on failure
```bash
deb-mock chain package1.dsc package2.dsc --continue-on-failure
```
#### Solution 3: Check package installation
```bash
deb-mock shell
# Inside chroot, check if packages are installed:
dpkg -l | grep package-name
```
### Configuration Issues
**Q: How do I create a custom configuration?**
**A:** **Deb-Mock** supports custom configurations:
#### Solution 1: Create a custom config file
```yaml
# my-config.yaml
chroot_name: "custom-debian"
architecture: "amd64"
suite: "bookworm"
mirror: "http://deb.debian.org/debian/"
use_root_cache: true
use_ccache: true
parallel_jobs: 4
```
#### Solution 2: Use the config file
```bash
deb-mock -c my-config.yaml build package.dsc
```
#### Solution 3: Use core configurations
```bash
# List available configurations
deb-mock list-configs
# Use a core configuration
deb-mock -r debian-bookworm-amd64 build package.dsc
```
### Common Error Messages
#### "Chroot does not exist"
```bash
# Create the chroot first
deb-mock init-chroot debian-bookworm-amd64
```
#### "Permission denied"
```bash
# Use sudo for chroot operations
sudo deb-mock init-chroot debian-bookworm-amd64
```
#### "Package not found"
```bash
# Update the chroot
deb-mock update-chroot debian-bookworm-amd64
```
#### "Build dependencies not satisfied"
```bash
# Install build dependencies
deb-mock shell
# Inside chroot:
apt-get install build-essential devscripts
```
### Getting Help
**Q: Where can I get more help?**
**A:** Several resources are available:
1. **Documentation**: Check the main README and configuration documentation
2. **Verbose Output**: Use `--verbose` and `--debug` flags for detailed information
3. **Error Messages**: **Deb-Mock** provides detailed error messages with suggestions
4. **Logs**: Check build logs in the output directory
5. **Community**: Report issues on the project's issue tracker
### Performance Tips
1. **Use caching**: Enable root cache, package cache, and ccache
2. **Parallel builds**: Set appropriate `parallel_jobs` for your system
3. **Clean up**: Regularly run `deb-mock cleanup-caches`
4. **Monitor resources**: Use `deb-mock cache-stats` to monitor cache usage
5. **Optimize chroots**: Use tmpfs for temporary files if you have sufficient RAM
### Security Considerations
1. **Environment sanitization**: Keep environment sanitization enabled unless necessary
2. **Root privileges**: Only use sudo when required for chroot operations
3. **Package verification**: Verify source packages before building
4. **Network security**: Use HTTPS mirrors and configure proxies securely
5. **Cache security**: Regularly clean caches to remove sensitive build artifacts

30
docs/Feature-bootstrap.md Normal file
View file

@ -0,0 +1,30 @@
---
layout: default
title: Feature bootstrap
---
## Bootstrap chroot
Mock is calling `dnf --installroot` to install packages for target architecture into the target directory. This works. Mostly. The only problem that use host DNF and rpm to install packages. But this can cause a problem when a new RPM feature is introduced. 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 implements 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 the target platform and we call DNF/YUM from that platform. For example: when you are on RHEL7 and you want to build a 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 a 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 a stable version of OS to build packages for even most recent OS. And vice versa.
This feature is enabled by default. If you want to disable it you should set:
```
config_opts['use_bootstrap'] = False
```
in your configuration.
This has been added in Mock 1.4.1.
### Using bootstrap with local repositories
It is possible to use `file://` local repositories with bootstrap chroot. However, you should not bind mount repositories located in `/tmp`, `/dev`, etc., as they might be over-mounted by systemd-nspawn.

42
docs/Feature-buildroot-image.md Normal file
View file

@ -0,0 +1,42 @@
---
layout: default
title: Feature buildroot image
---
Starting from version v6.0, Mock allows users to use an OCI container image for
pre-creating the buildroot (build chroot). It can be either an online container
image hosted in a registry (or cached locally), or a local image in the form of
a tarball.
Be cautious when using chroot-compatible images (e.g., it is not advisable to
combine EPEL `ppc64le` images with `fedora-rawhide-x86_64` chroot).
## Example Use-Case
1. Mock aggressively caches the build root, so clean up your chroot first:
```bash
$ mock -r fedora-rawhide-x86_64 --scrub=all
```
2. Perform any normal Mock operation, but select the OCI image on top of that:
```bash
$ mock -r fedora-rawhide-x86_64 \
--buildroot-image registry.fedoraproject.org/fedora:41 \
--rebuild /your/src.rpm
```
## Using Exported Buildroot Image
The [export_buildroot_image](Plugin-Export-Buildroot-Image) plugin allows you to
wrap a prepared buildroot as an OCI archive (tarball). If you have this
tarball, you may select it as well:
```bash
$ mock -r fedora-rawhide-x86_64 \
--buildroot-image /tmp/buildroot-oci.tar \
--rebuild /your/src.rpm
```
Again, ensure that you do not combine incompatible chroot and image pairs.

48
docs/Feature-container-for-bootstrap.md Normal file
View file

@ -0,0 +1,48 @@
---
layout: default
title: Feature container for bootstrap
---
## Container image for bootstrap
In past, we had some incompatibilities between host and build target. They were, in fact, small. Like using a different package manager. Some were big. Like, the introduction of Weak and Rich dependencies. For this reason, we introduced [bootstrap](Feature-bootstrap). But then comes [zstd payload](https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression). This is a new type of payload. And to install packages with this payload, you need an `rpm` binary, which supports this payload. This is true for all current Fedoras. Unfortunately, neither RHEL 8 nor RHEL 7 supports this payload. So even bootstrap will not help you to build Fedora packages on RHEL 8.
We come up with a nice feature. Mock will not install bootstrap chroot itself. Instead, it will download the container image, extract the image, and use this extracted directory as a bootstrap chroot. And from this bootstrapped chroot install the final one.
Using this feature, **any** incompatible feature in either RPM or DNF can be used in the target chroot. Now or in future. And you will be able to install the final chroot. You do not even need to have `rpm` on a host. So this should work on any system, even Debian-based ones. The only requirement for this feature is [Podman](https://podman.io/). Do not forget to install the `podman` package.
This feature is available since 1.4.20 and enabled by default from 5.0. You can disable it using:
config_opts['use_bootstrap_image'] = False
It can be enabled or disabled on the command line using `--use-bootstrap-image` or `--no-bootstrap-image` options.
Note however that also this is prerequisite:
config_opts['use_bootstrap_container'] = True # or --bootstrap-chroot option
To specify which image should be used for bootstrap container you can put in config:
config_opts['bootstrap_image'] = 'registry.fedoraproject.org/fedora:latest'
This is a general config. Each config has specified its own image specified. E.g. CentOS 7 has `config_opts['bootstrap_image'] = 'centos:7'` in config. So unless you use your own config, you can enable this feature, and the right image will be used.
The image contents are typically suboptimal for Mock's use-case. In particular,
Mock needs to have a correct package manager (as specified in the
`package_manager` configuration option) installed inside the image, along with
the `builddep` functionality (typically provided by `python3-dnf-plugins-core`).
This is why Mock still has to 'update the downloaded bootstrap' somehow. If you
happen to have an image with `builddep` pre-installed, you can set
`bootstrap_image_ready` to 'True':
config_opts['bootstrap_image_ready'] = True
This option will significantly reduce the bootstrap preparation time, as no
package management actions need to be performed for the bootstrap (no need to
download and initialize package manager caches).
There is one known issue:
* Neither Mageia 6 nor 7 works correctly now with this feature.
Technically, you can use any container, as long as there is the required package manager (DNF or YUM). The rest of the needed packages will be installed by mock.

43
docs/Feature-external-deps.md Normal file
View file

@ -0,0 +1,43 @@
---
layout: default
title: Feature external dependencies
---
## External dependencies
It can happen that you need some library that is not packaged. PyPI has ten times more modules than Fedora has packages. The same for Rubygems.org, Crates.io...
External dependencies allow you to install a package using the native package manager. I.e. not dnf or rpm, but rather using `pip`, `gem`, etc.
Right now it is possible to do that only for `BuildRequires`. Run-time `Requires` will need more co-operation with DNF and rpm.
This feature is disabled by default. It can be enabled using:
```
config_opts['external_buildrequires'] = True
```
## Modules
### PyPI
`BuildRequires: external:pypi:foo` - this will run `pip3 --install foo`
### Crate
`BuildRequires: external:crate:foo` - this will run `cargo install foo`
### Others
Do you miss other languages here? [File an issue](https://github.com/rpm-software-management/mock/issues) and let us know which language you want to add. There are two requirements. The native package manager needs to be available in Fedora. And the manager has to have `--root` or something similar which let you allow to install the files in the different root path. That is because we run this tool in bootstrap chroot.
## How it works
When we find the `external::` prefix in BuildRequires then Mock install the native package manager in bootstrap buildroot. E.g., for `external:pypi:foo` mock will install `pip3` and run `pip3 install --root MOCK_CHROOT foo`.
To satisfy rpm dependencies Mock calls `create-fake-rpm` and creates a fake rpm package that provides `external:pypi:foo` and installs it in chroot.
All this is logged in `root.log` and usually start with the line `Installing dependencies to satisfy external:*`
As of now, this feature requires [bootstrap chroot](Feature-bootstrap) enabled and requires `create-fake-rpm` to be present (package) in the target chroot.
Available since 2.7

35
docs/Feature-forcearch.md Normal file
View file

@ -0,0 +1,35 @@
---
layout: default
title: Feature forcearch
---
## Forcearch
Previously you were able to only build for compatible architectures. I.e., you can build `i386` package on `x86_64` architecture. When you tried to build for incompatible architecture, you get this error:
```
$ mock -r fedora-28-ppc64le shell
ERROR: Cannot build target ppc64le on arch x86_64, because it is not listed in legal_host_arches ('ppc64le',)
```
Now, you can build for any architecture using a new option --force-arch ARCH. [GH#120](https://github.com/rpm-software-management/mock/issues/120) You have to have installed package `qemu-user-static`, which is a new soft dependence. Try this:
```
$ sudo dnf install qemu-user-static
$ mock -r fedora-28-ppc64le --forcearch ppc64le shell
```
and you get the prompt in PPC64LE Fedora. You can do this for any architecture supported by QEMU.
You got just `INFO` in the log stating:
```
INFO: Unable to build arch ppc64le natively on arch x86_64. Setting forcearch to use software emulation.
```
Note: Do not confuse `--forcearch` and `--arch` which are very different options.
:warning: `qemu-user-static` emulates **user** space, but cannot emulate **kernel** space. If your package need some architecture specific kernel calls or e.g., is parsing output of `lscpu` then this feature is not for you. :(
This has been added to Mock 1.4.11.
Since version 2.0 you do not need to use `--forcearch` as Mock will detect that you want to use different than your native architecture and use qemu-user-static automatically.

41
docs/Feature-modularity.md Normal file
View file

@ -0,0 +1,41 @@
---
layout: default
title: Feature modularity support
---
## Modularity support
There is support for Fedora and RHEL Modularity. This requires `dnf`, not merely
`yum`. It is available for RHEL >= 8 and its clones, and built into
all supported releases of Fedora.
The new modularity format was added with release 2.4 and uses
`module_setup_commands`. Each command can be specified multiple times,
and mock respects the order of the commands when executing them.
* Artificial example:
* Disable any potentially enabled postgresql module stream.
* Enable _specific_ postgresql and ruby module streams.
* Install the development nodejs profile and (4) disable it immediately.
```
config_opts['module_setup_commands'] = [
('disable', 'postgresql'),
('enable', 'postgresql:12, ruby:2.6'),
('install', 'nodejs:13/development'),
('disable', 'nodejs'),
]
```
The obsolete, less flexible, but still available modularity syntax was added in Mock 1.4.2.
```
config_opts['module_enable'] = ['list', 'of', 'modules']
config_opts['module_install'] = ['module1/profile', 'module2/profile']
```
This would call these steps during the init phase.
* `dnf module enable list of modules`
* `dnf module install module1/profile module2/profile`
You can find more about this obsolete format in this comprehensive blogpost.
* [Modularity Features in Mock](http://frostyx.cz/posts/modularity-features-in-mock).

20
docs/Feature-nosync.md Normal file
View file

@ -0,0 +1,20 @@
---
layout: default
title: Feature nosync
---
# Nosync
One of the reasons why mock has always been quite slow is because installing a lot of packages generates a heavy IO load. But the main bottleneck regarding IO is not unpacking files from packages to disk but writing Yum DB entries. Yum DB access (used by both yum and dnf) generates a lot of `fsync`(2) calls. Those don't really make sense in mock because people generally don't try to recover mock buildroots after hardware failure. We discovered that getting rid of `fsync` improves the package installation speed by almost a factor of 4. Mikolaj Izdebski developed a small C library, `nosync`, that is `LD_PRELOAD`ed and replaces the `fsync` family of calls with (almost) empty implementations. I added support for it in mock.
How to activate it?
You need to install the `nosync` package and for multilib systems (`x86_64`), you need versions for both architectures. Then it can be enabled in mock by setting
```
# dnf install nosync
config_opts['nosync'] = True
```
If you cannot install both architectures of nosync (for example on RHEL) and still want mock to use it, you can force its usage. Then expect there can be harmless error messages from ld.so when a 32bit program is executed, but it should otherwise work fine for 64bit binaries. Forcing is done using
```
config_opts['nosync_force'] = True
```
It does require those extra steps to set up but it really pays off quickly.

39
docs/Feature-package-managers.md Normal file
View file

@ -0,0 +1,39 @@
---
layout: default
title: Feature DNF
---
## DNF
This is default package manager for mock. You can enforce it (e.g. in older Mock) using>
```
config_opts['package_manager'] = 'dnf'
```
## YUM
Yum is still used in RHEL 7 and olders. You can enable it using
```
config_opts['package_manager'] = 'yum'
```
## MicroDNF
MicroDNF is written in C and does not need Python. It is present in minimal OCI containers. It can be enabled using:
```
config_opts['package_manager'] = 'microdnf'
```
However, MicroDNF still [does not have `buildep` command](https://github.com/rpm-software-management/microdnf/issues/82). The current implementation still installs DNF (using microdnf) and use DNF to query the build deps.
You can use following options in the config:
```python
config_opts['microdnf_command'] = '/usr/bin/microdnf'
# "dnf-install" is special keyword which tells mock to use install but with DNF
config_opts['microdnf_install_command'] = 'dnf-install microdnf dnf dnf-plugins-core distribution-gpg-keys'
config_opts['microdnf_builddep_command'] = '/usr/bin/dnf'
config_opts['microdnf_builddep_opts'] = []
config_opts['microdnf_common_opts'] = []
```

44
docs/Feature-rhelchroots.md Normal file
View file

@ -0,0 +1,44 @@
---
layout: default
title: Feature RHEL chroots
---
## Build package for RHEL
Previously, when you had to build a package for RHEL you had to use `epel-7-x86_64` chroot (or similar). This chroot is made of CentOS plus EPEL. This causes a problem when you want to use real RHEL for some reason. E.g., when new RHEL is out, but CentOS not yet.
To build for RHEL you have to [Red Hat subscription](https://www.redhat.com/en/store/linux-platforms). You can use your existing subscription or you can use [free of charge subscription](https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscription-now-available/).
### Mock RHEL configs
Mock provides `rhel-<RELEASEVER>-<TARGET_ARCH>` configs which use pure RHEL.
There are also `rhel+epel-<RELEASEVER>-<TARGET_ARCH>` configs which use RHEL plus EPEL.
### Subscription configuration with Simple Content Access
If you have [Simple Content Access](https://access.redhat.com/articles/simple-content-access#how-do-i-enable-simple-content-access-for-red-hat-subscription-management-2) enabled,
all you need to do is register the machine you are running mock on.
The register command will prompt you for your username and password.
```
$ sudo subscription-manager register
```
After this the RHEL mock configs should work without further action.
```
$ mock -r rhel-9-x86_64 --shell
```
Optionally, you can disable the subscription-manager dnf plugin if you do not need subscription repos directly on your machine.
```sh
$ sudo subscription-manager config --rhsm.auto_enable_yum_plugins 0
$ sudo sed -e '/^enabled=/ s/1/0/' -i /etc/dnf/plugins/subscription-manager.conf
```
### Multiple client keys
If there are multiple client keys,
mock takes the first one in `glob("/etc/pki/entitlement/<numeric-part>-key.pem")` output.
But users still generate configure `config_opts['redhat_subscription_key_id']` in mock configuration,
or on command line `--config-opts=redhat_subscription_key_id=<ID>`.

9
docs/Gemfile Normal file
View file

@ -0,0 +1,9 @@
# frozen_string_literal: true
source "https://rubygems.org"
gem 'jekyll'
gem 'jekyll-theme-slate'
gem 'kramdown-parser-gfm'
gem 'webrick'
gem 'jemoji'

116
docs/LICENSE Normal file
View file

@ -0,0 +1,116 @@
CC0 1.0 Universal
Statement of Purpose
The laws of most jurisdictions throughout the world automatically confer
exclusive Copyright and Related Rights (defined below) upon the creator and
subsequent owner(s) (each and all, an "owner") of an original work of
authorship and/or a database (each, a "Work").
Certain owners wish to permanently relinquish those rights to a Work for the
purpose of contributing to a commons of creative, cultural and scientific
works ("Commons") that the public can reliably and without fear of later
claims of infringement build upon, modify, incorporate in other works, reuse
and redistribute as freely as possible in any form whatsoever and for any
purposes, including without limitation commercial purposes. These owners may
contribute to the Commons to promote the ideal of a free culture and the
further production of creative, cultural and scientific works, or to gain
reputation or greater distribution for their Work in part through the use and
efforts of others.
For these and/or other purposes and motivations, and without any expectation
of additional consideration or compensation, the person associating CC0 with a
Work (the "Affirmer"), to the extent that he or she is an owner of Copyright
and Related Rights in the Work, voluntarily elects to apply CC0 to the Work
and publicly distribute the Work under its terms, with knowledge of his or her
Copyright and Related Rights in the Work and the meaning and intended legal
effect of CC0 on those rights.
1. Copyright and Related Rights. A Work made available under CC0 may be
protected by copyright and related or neighboring rights ("Copyright and
Related Rights"). Copyright and Related Rights include, but are not limited
to, the following:
i. the right to reproduce, adapt, distribute, perform, display, communicate,
and translate a Work;
ii. moral rights retained by the original author(s) and/or performer(s);
iii. publicity and privacy rights pertaining to a person's image or likeness
depicted in a Work;
iv. rights protecting against unfair competition in regards to a Work,
subject to the limitations in paragraph 4(a), below;
v. rights protecting the extraction, dissemination, use and reuse of data in
a Work;
vi. database rights (such as those arising under Directive 96/9/EC of the
European Parliament and of the Council of 11 March 1996 on the legal
protection of databases, and under any national implementation thereof,
including any amended or successor version of such directive); and
vii. other similar, equivalent or corresponding rights throughout the world
based on applicable law or treaty, and any national implementations thereof.
2. Waiver. To the greatest extent permitted by, but not in contravention of,
applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and
unconditionally waives, abandons, and surrenders all of Affirmer's Copyright
and Related Rights and associated claims and causes of action, whether now
known or unknown (including existing as well as future claims and causes of
action), in the Work (i) in all territories worldwide, (ii) for the maximum
duration provided by applicable law or treaty (including future time
extensions), (iii) in any current or future medium and for any number of
copies, and (iv) for any purpose whatsoever, including without limitation
commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes
the Waiver for the benefit of each member of the public at large and to the
detriment of Affirmer's heirs and successors, fully intending that such Waiver
shall not be subject to revocation, rescission, cancellation, termination, or
any other legal or equitable action to disrupt the quiet enjoyment of the Work
by the public as contemplated by Affirmer's express Statement of Purpose.
3. Public License Fallback. Should any part of the Waiver for any reason be
judged legally invalid or ineffective under applicable law, then the Waiver
shall be preserved to the maximum extent permitted taking into account
Affirmer's express Statement of Purpose. In addition, to the extent the Waiver
is so judged Affirmer hereby grants to each affected person a royalty-free,
non transferable, non sublicensable, non exclusive, irrevocable and
unconditional license to exercise Affirmer's Copyright and Related Rights in
the Work (i) in all territories worldwide, (ii) for the maximum duration
provided by applicable law or treaty (including future time extensions), (iii)
in any current or future medium and for any number of copies, and (iv) for any
purpose whatsoever, including without limitation commercial, advertising or
promotional purposes (the "License"). The License shall be deemed effective as
of the date CC0 was applied by Affirmer to the Work. Should any part of the
License for any reason be judged legally invalid or ineffective under
applicable law, such partial invalidity or ineffectiveness shall not
invalidate the remainder of the License, and in such case Affirmer hereby
affirms that he or she will not (i) exercise any of his or her remaining
Copyright and Related Rights in the Work or (ii) assert any associated claims
and causes of action with respect to the Work, in either case contrary to
Affirmer's express Statement of Purpose.
4. Limitations and Disclaimers.
a. No trademark or patent rights held by Affirmer are waived, abandoned,
surrendered, licensed or otherwise affected by this document.
b. Affirmer offers the Work as-is and makes no representations or warranties
of any kind concerning the Work, express, implied, statutory or otherwise,
including without limitation warranties of title, merchantability, fitness
for a particular purpose, non infringement, or the absence of latent or
other defects, accuracy, or the present or absence of errors, whether or not
discoverable, all to the greatest extent permissible under applicable law.
c. Affirmer disclaims responsibility for clearing rights of other persons
that may apply to the Work or any use thereof, including without limitation
any person's Copyright and Related Rights in the Work. Further, Affirmer
disclaims responsibility for obtaining any necessary consents, permissions
or other rights required for any use of the Work.
d. Affirmer understands and acknowledges that Creative Commons is not a
party to this document and has no duty or obligation with respect to this
CC0 or use of the Work.
For more information, please see
<http://creativecommons.org/publicdomain/zero/1.0/>

70
docs/Mock-Core-Configs.md Normal file
View file

@ -0,0 +1,70 @@
---
layout: default
title: Mock Core Configs
---
# Mock core configs
Mock project provides the `mock-core-configs` package which installs the default
[configuration files](configuration) 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:
* [mock-core-configs](https://github.com/rpm-software-management/mock/tree/main/mock-core-configs) (this project)
* [mock-centos-sig-configs](https://pagure.io/centos-sig-hyperscale/mock-centos-sig-configs)
* [RPM Fusion Mock conifgs](https://github.com/rpmfusion-infra/mock-rpmfusion)
## Maintenance
The configuration in this package maintained by the community.
When encountering an issue please use your best judgement to decide
whether a Mock config is broken, or the distribution is broken.
#### Mock config issues
If a Mock config is broken (e.g. [#756][mock-756]), please
[create a ticket for this repository][mock-issues]
and tag the responsible maintainer from the table below.
#### Distribution or repository issues
If a distribution or repository is broken (e.g. [#889][mock-889]),
please report the issue to the appropriate issue tracker for the
distribution.
#### Table
| Distribution | Chroots | Maintainer | Distribution or repository issue tracker |
| ------------------------------------------------------------------------------ | ----------------- | --------------------------------------------------------------------- | ------------- |
| [AlmaLinux](https://almalinux.org/) | `almalinux-*` | [@Conan-Kudo](https://github.com/Conan-Kudo), [@javihernandez](https://github.com/javihernandez) | [Issues](https://bugs.almalinux.org/) |
| [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/) | `amazonlinux-2-*` | [@stewartsmith](https://github.com/stewartsmith) | NA |
| [Amazon Linux](https://aws.amazon.com/linux/amazon-linux-2023/) | `amazonlinux-*` | [@amazonlinux](https://github.com/amazonlinux) | [Issues](https://github.com/amazonlinux/amazon-linux-2023/issues) |
| [Anolis](https://openanolis.cn/) | `anolis-*` | [@geliwei-ali](https://github.com/geliwei-ali) | [Issues](https://bugzilla.openanolis.cn/) |
| [Azure Linux](https://github.com/microsoft/azurelinux) | `azure-linux-*` | [@scaronni](https://github.com/scaronni) | [Issues](https://github.com/microsoft/azurelinux/issues) |
| [CentOS Stream](https://www.centos.org/centos-stream/) | `centos-stream*` | [Mock team][] | [Issues](https://issues.redhat.com/projects/CS) |
| [CentOS Linux](https://www.centos.org/centos-linux/) | `centos*` | End-of-life. | End-of-life. |
| [Circle Linux](https://cclinux.org/) | `circlelinux-*` | [@bella485](https://github.com/bella485) | [Issues](https://bugzilla.cclinux.org/) |
| [EuroLinux](https://en.euro-linux.com/) | `eurolinux-*` | End-of-life. | End-of-life. |
| [Fedora ELN](https://docs.fedoraproject.org/en-US/eln/) | `fedora-eln-*` | [@fedora-eln](https://github.com/fedora-eln) | [Issues](https://github.com/fedora-eln/eln/issues) |
| [Fedora](https://fedoraproject.org/) | `fedora-*` | [Mock team][] | [Issues](https://github.com/rpm-software-management/mock/issues) |
| [Kylin](https://kylinos.cn/) | `kylin-*` | [@scaronni](https://github.com/scaronni) | NA |
| [Mageia](https://www.mageia.org/en/) | `mageia-*` | [@Conan-Kudo](https://github.com/Conan-Kudo) | [Issues](https://bugs.mageia.org/) |
| [Navy Linux](https://navylinux.org/) | `navy-*` | [@unixlabs](https://github.com/unixlabs) | [issues](https://github.com/navy-linux/issue-tracker/issues) |
| [openEuler](https://www.openeuler.org/en/) | `openeuler-*` | [@Yikun](https://github.com/Yikun) | NA |
| [OpenMandriva](https://www.openmandriva.org/) | `openmandriva-*` | [berolinux](https://github.com/berolinux) | [Issues](https://github.com/OpenMandrivaAssociation/distribution/issues) |
| [openSUSE](https://www.opensuse.org/) | `opensuse-*` | [@Conan-Kudo](https://github.com/Conan-Kudo), [@lkocman](https://github.com/lkocman) | [Issues](https://bugzilla.opensuse.org/) |
| [Oracle Linux](https://www.oracle.com/linux/) | `oraclelinux-*` | [@Mno-hime](https://github.com/Mno-hime), [sharewax](https://github.com/sharewax), [Djelibeybi](https://github.com/Djelibeybi) | [issues](https://github.com/oracle/oracle-linux/issues) |
| [RHEL](https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux)| `rhel-*` | [Mock team][] | [Issues](https://issues.redhat.com/projects/RHEL) |
| [Rocky Linux](https://rockylinux.org/) | `rocky-*` | [@nazunalika](https://github.com/nazunalika) | [Issues](https://bugs.rockylinux.org/) |
[Mock team]: https://github.com/orgs/rpm-software-management/teams/mock-team
[mock-issues]: https://github.com/rpm-software-management/mock/issues
[mock-756]: https://github.com/rpm-software-management/mock/issues/756
[mock-889]: https://github.com/rpm-software-management/mock/issues/889

55
docs/Plugin-BindMount.md Normal file
View file

@ -0,0 +1,55 @@
---
layout: default
title: Plugin BindMount
---
This plugin enables setting up bind mountpoints inside the chroot. It is enabled by default but has no paths setup for bind mounts.
## Configuration
In your config file insert the following lines:
config_opts['plugin_conf']['bind_mount_enable'] = True
config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/host/path', '/bind/mount/path/in/chroot/' ))
The `/host/path` is the path to a directory on the host that will be the source of a bind-mount, while the `/bind/mount/path/in/chroot` is the path where it will be mounted inside the chroot.
Starting from version 1.4.10 it will work for files too. Just be aware that files are still put in 'dirs' directive. E.g.,
config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/host/path/file.txt', '/bind/mount/path/in/chroot/file.txt' ))
If you want the bind mounts to be available to all configurations, edit [the configuration file](Home#generate-custom-config-file).
### `/builddir/` cleanup
**WARNING!** The build user's homedir (`/builddir`) is partially cleaned up even when `--no-clean` is
specified in order to prevent garbage from previous builds from altering
successive builds. Mock can be configured to exclude certain files/directories
from this. Default is `SOURCES` directory to support nosrc rpms:
config_opts['exclude_from_homedir_cleanup'] = ['build/SOURCES']
Paths are relative to build user's homedir.
So if you do something like this:
config_opts['plugin_conf']['bind_mount_opts']['dirs'].append((os.path.expanduser('~/MyProject'), '/builddir/MyProject' ))
Then you SHOULD do:
config_opts['exclude_from_homedir_cleanup'] = ['build/SOURCES', 'MyProject']
otherwise your `~/MyProject` will be wiped out!
Other option is to not mount it under `/builddir`, but somewhere else (`/opt`, `/mnt`...).
***
Set options from command line
```
mock '--plugin-option=bind_mount:dirs=[("/host/dir", "/mount/path/in/chroot/")]' --init
```
:warning: Note that command line arguments override configs (not append them).
:notebook: Since version mock-1.4.10 and newer you can bind mount even single files.

48
docs/Plugin-BuildrootLock.md Normal file
View file

@ -0,0 +1,48 @@
---
layout: default
title: Plugin buildroot_lock
---
buildroot_lock Plugin
=====================
This plugin generates an additional build artifact—the buildroot *lockfile*
(`buildroot_lock.json` file in the result directory).
The *lockfile* describes both the list of buildroot sources (e.g., a list of
installed RPMs, bootstrap image info, etc.) and a set of Mock configuration
options. Using this information, Mock can later reproduce the buildroot
preparation (see the [Hermetic Builds feature page](feature-hermetic-builds)).
This plugin is **disabled** by default but is automatically enabled with the
`--calculate-build-dependencies` option. You can enable it (for all builds) by
this configuration snippet:
```python
config_opts['plugin_conf']['buildroot_lock_enable'] = True
```
**Note:** This plugin does not work with the `--offline` option.
Format of the *buildroot_lock.json* file
----------------------------------------
The file `buildroot_lock.json` is a JSON file. List of JSON Schema files is
installed together with the Mock RPM package:
rpm -ql mock | grep schema
/usr/share/doc/mock/buildroot-lock-schema-1.0.0.json
/usr/share/doc/mock/buildroot-lock-schema-1.1.0.json
Currently, we do not provide a compatibility promise. Only the exact same
version of Mock that produced the file is guaranteed to read and process it.
For more information, see [Hermetic Builds](feature-hermetic-builds).
Also, in the future we plan to switch to a standardized tooling so we operate
with a standardized format, too. For more info see the [DNF5 feature
request][discussion], [rpm-lockfile-prototype][] and [libpkgmanifest][].
[discussion]: https://github.com/rpm-software-management/dnf5/issues/833
[rpm-lockfile-prototype]: https://github.com/konflux-ci/rpm-lockfile-prototype
[libpkgmanifest]: https://github.com/rpm-software-management/libpkgmanifest

46
docs/Plugin-CCache.md Normal file
View file

@ -0,0 +1,46 @@
---
layout: default
title: Plugin CCache
---
The ccache plugin is a compiler cache plugin. It is disabled by default and has an upper limit of 4GB of ccache data.
Note: this plugin was enabled by default in mock-1.2.14 and older.
## Configuration
The ccache plugin is disabled by default and has the following values built-in:
```python
config_opts['plugin_conf']['ccache_enable'] = False
config_opts['plugin_conf']['ccache_opts']['max_cache_size'] = '4G'
config_opts['plugin_conf']['ccache_opts']['compress'] = None
config_opts['plugin_conf']['ccache_opts']['dir'] = "%(cache_topdir)s/%(root)s/ccache/u%(chrootuid)s/"
config_opts['plugin_conf']['ccache_opts']['hashdir'] = True
config_opts['plugin_conf']['ccache_opts']['debug'] = False
config_opts['plugin_conf']['ccache_opts']['show_stats'] = False
```
To turn on ccache compression, use the following in a config file:
```python
config_opts['plugin_conf']['ccache_opts']['compress'] = 'on'
```
The value specified is not important, this just triggers the setting of the CCACHE_COMPRESS environment variable, which is what the ccache program uses to determine if compression of cache elements is desired.
Setting `hashdir` to `False` excludes the build working directory from the hash used to distinguish two
compilations when generating debuginfo. While this allows the compiler cache
to be shared across different package NEVRs, it might cause the debuginfo to be
incorrect.
The option can be used for issue bisecting if running the debugger is
unnecessary. ([issue 1395][]https://github.com/rpm-software-management/mock/issues/1395)
See [ccache documentation](https://ccache.dev/manual/4.10.html#config_hash_dir).
This option is available since Mock 5.7.
Setting `debug` to `True` creates per-object debug files that are helpful when debugging unexpected cache misses.
See [ccache documentation](https://ccache.dev/manual/4.10.html#config_debug).
This option is available since Mock 5.7.
If `show_stats` is set to True, Mock calls `ccache --zero-stats` first (before
doing the build), and then calls `ccache --show-stats`.
This option is available since Mock v5.7+.

27
docs/Plugin-ChrootScan.md Normal file
View file

@ -0,0 +1,27 @@
---
layout: default
title: Plugin Chroot Scan
---
The chroot_scan plugin is used to grab files of interest after a build attempt and copy them to the 'result directory' before the chroot is cleaned and data lost.
## Configuration
The chroot_scan plugin is disabled by default. To enable it and to add files to the detection logic, add this code to configure file:
```python
config_opts['plugin_conf']['chroot_scan_enable'] = True
config_opts['plugin_conf']['chroot_scan_opts']['regexes'] = [
"core(\.\d+)?",
"\.log$",
]
config_opts['plugin_conf']['chroot_scan_opts']['only_failed'] = True
config_opts['plugin_conf']['chroot_scan_opts']['write_tar'] = False
```
The above logic turns on the chroot_scan plugin and adds corefiles and log files to the scan plugin. When the 'postbuild' hook is run by mock, the chroot_scan will look through the chroot for files that match the regular expressions in it's list and any matching file will be copied to the mock result directory for the config file. Again if you want this to be enabled across all configs, edit the `/etc/mock/site-defaults.cfg` file.
When `only_failed` is set to False, then those files are always copied. When it is set to True (default when plugin enabled), then those files are only copied when build failed.
When `write_tar` is set to True, then instead of `chroot_scan` directory, `chroot_scan.tar.gz` is created with the directory archive.
The `only_failed` option is available since v1.2.8, `write_tar` since v5.5.

20
docs/Plugin-CompressLogs.md Normal file
View file

@ -0,0 +1,20 @@
---
layout: default
title: Plugin Compress Logs
---
This plugin compresses logs created by Mock in the result directory (build.log,
hw_info.log, installed_pkgs.log, root.log and state.log).
This plugin is **disabled** by default.
## Configuration
To compress your logs with XZ, you can put this into the
[configuration](configuration):
```python
config_opts['plugin_conf']['compress_logs_enable'] = True
config_opts['plugin_conf']['compress_logs_opts']['command'] = "/usr/bin/xz -9"
```
This plugin is available since mock-1.2.1.

64
docs/Plugin-Export-Buildroot-Image.md Normal file
View file

@ -0,0 +1,64 @@
---
layout: default
title: Plugin export_buildroot_image
---
This plugin allows you to (on demand) export the Mock chroot as an OCI image in
local archive format (tarball). This tarball can provide additional convenience
for local build reproducibility. See the example below for details.
By default, this plugin is **disabled**. You can enable it using the
`--enable-plugin export_buildroot_image` option in `--rebuild` mode.
This plugin has been added in Mock v6.0.
## Example use-case
First, let's start a standard Mock build, but enable the OCI archive generator:
$ mock -r fedora-rawhide-x86_64 --enable-plugin export_buildroot_image \
/tmp/quick-package/dummy-pkg-20241212_1114-1.src.rpm
... mock installs all build-deps, and does other chroot tweaks ...
Start: producing buildroot as OCI image
... mock performs the rpmbuild ...
INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
Finish: run
The archive has been saved in the result directory:
$ ls /var/lib/mock/fedora-rawhide-x86_64/result/*.tar
/var/lib/mock/fedora-rawhide-x86_64/result/buildroot-oci.tar
You may use this tarball together with [the `--buildroot-image` option
then](Feature-buildroot-image). But also, you can try re-running the
build without Mock, like this:
$ chmod a+r /tmp/quick-package/dummy-pkg-20241212_1114-1.src.rpm
$ podman run --rm -ti \
-v /tmp/quick-package/dummy-pkg-20241212_1114-1.src.rpm:/dummy-pkg.src.rpm:z \
oci-archive:/var/lib/mock/fedora-rawhide-x86_64/result/buildroot-oci.tar \
rpmbuild --rebuild /dummy-pkg.src.rpm
Installing /dummy-pkg.src.rpm
setting SOURCE_DATE_EPOCH=1401926400
Executing(%mkbuilddir): /bin/sh -e /var/tmp/rpm-tmp.XIm441
...
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.pqJ9hu
...
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.iaeMZG
...
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.SHktaE
...
Processing files: dummy-pkg-20241212_1114-1.fc42.x86_64
...
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.E71FWH
...
+ exit 0
**Warning:** This method of reproducing a Mock build is not recommended for
production use. During a normal/full Mock rebuild, Mock ensures the buildroot
is fully up-to-date. Using just plain `rpmbuild` within Podman may result in
outdated files, different structure in the kernel-driven filesystems like
`/proc`, `/dev`, and `/sys`, different SELinux assumptions, permissions, etc.
Proceed with caution, and be prepared to encounter some differences (and perhaps
different build failures).

37
docs/Plugin-Hooks.md Normal file
View file

@ -0,0 +1,37 @@
---
layout: default
title: Plugin Hooks
---
When you develop a new plugin, you can register your hook with:
plugins.add_hook("HOOK_NAME", self.your_method)
Where `HOOK_NAME` is one of:
* clean
* earlyprebuild - This is called during the very early stage of building RPM or SRPM. It is called even before SRPM is rebuilt or build dependencies have been installed.
* initfailed
* list_snapshots - when `--list-snapshots` or `-l` option is passed on command line, this hook is being called and then Mock exits.
* make_snapshot
* mount_root - This hook is intended for plugins which mount the chroot directory. This is called just before 'preinit' when only chroot directory exists. Result directory does not exist yet.
* postbuild - This hook is called just after RPM or SRPM have been build (with or without success).
* postchroot - This hook is called just after exiting from command in `mock chroot` command. This action is currently being used by `root_cache` plugin.
* postclean - This hook is called when the content of the chroot has been deleted. It is called after `umount_root`. E.g., `lvm_root` use this to delete the LVM volume.
* postdeps - Called when the build dependencies (both static and dynamic) are installed, but the build has not started, yet.
* postinit - Chroot have been initialized and it is ready for installing SRPM dependencies. E.g., root_cache plugin now packs the chroot and put it in a cache. This action is currently being used by `bind_mount`, `lvm_root`, `mount`, `root_cache` plugins.
* postshell - This hook is called just after exiting from the shell in `mock shell` command. This action is currently being used by `root_cache` plugin.
* postupdate - Mock attempts to cache buildroot contents, but tries to automatically update the packages inside the buildroot in subsequent executions (so up2date packages are used during build). This hook is called anytime such update is successful and any package is updated inside the buildroot. Any plugin taking care of the buildroot caches can then react and update the cache to avoid re-updating in the subsequent mock runs.
* postumount - This hook is called when everything in chroot finished or has been killed. All inner mounts have been umounted. E.g., tmpfs plugin uses this to umount tmpfs chroot. This action is currently being used by `lvm_root`, `tmpfs` plugins.
* postyum - This hook is called after any packager manager action is executed. This is e.g., used by the `package_state` plugin to list all available packages. This action is currently being used by `package_state`, `root_cache`, `selinux`, `yum_cache` plugins.
* prebuild - This hook is called after `BuildRequires` have been installed, but before RPM builds. This is not called for SRPM rebuilds.
* prechroot - This hook is called just before executing a command when `mock chroot` command has been used. This action is currently being used by `root_cache` plugin.
* preinit - Only chroot and result_dir directories exist. There may be no other content. No binary. Not even base directories. Root_cache plugin uses this hook to populate the content of chroot_from cache. HW_info gather information about hardware and store it in result_dir. This action is currently being used by `ccache`, `hw_info`, `root_cache`, `yum_cache` plugins.
* preshell - This hook is called just before giving a prompt to a user when `mock shell` command has been used. This action is currently being used by `pm_request`, `root_cache` plugins.
* preyum - This hook is called before any packager manager action is executed. This is, e.g., used by `root_cache` plugin when `--cache-alterations` option is used. This action is currently being used by `root_cache`, `selinux`, `yum_cache`.
* process_logs - Called once the build log files (root.log, build.log, ...) are completed so they can be processed (e.g. compressed by the `compress_logs` plugin).
* remove_snapshot
* rollback_to
* scrub
You can get inspired by existing [plugins](https://github.com/rpm-software-management/mock/tree/master/mock/py/mockbuild/plugins).

20
docs/Plugin-HwInfo.md Normal file
View file

@ -0,0 +1,20 @@
---
layout: default
title: Plugin HwInfo
---
This plugin allows prints your basic hardware information, which may help identify problems or reproduced the build.
It print information about CPU, memory (including swap) and storage (only of volume where chroot will be stored).
The information is stored in file hw_info.log in results directory.
## Configuration
You can enable the plugin using this settings:
```python
config_opts['plugin_conf']['hw_info_enable'] = True
config_opts['plugin_conf']['hw_info_opts'] = {}
```
Available since version 1.3.4.
This plugin is enabled by default.

101
docs/Plugin-LvmRoot.md Normal file
View file

@ -0,0 +1,101 @@
---
layout: default
title: Plugin LVM Root
---
Mock can use LVM as a backend for caching buildroots which is a bit faster than using root_cache and enables efficient snapshotting (copy-on-write). This feature is intended to be used by people who maintain a lot packages and find themselves waiting for mock to install the same set of `BuildRequires` over and over again.
Mock uses LVM thin provisioning which means that one logical volume (called
thinpool) can hold all thin logical volumes and snapshots used by all
buildroots (you have to set it like that in the config) without each of them
having fixed size. Thinpool is created by mock when it's starts initializing
and after the buildroot is initialized, it creates a postinit snapshot which
will be used as default. Default snapshot means that when you execute clean or
start a new build without `--no-clean` option, mock will rollback to the state in default snapshot. As you install more packages you can create your own snapshots (usually for dependency chains that are common to many of your packages).
## Expected workflow
You have multiple packages that all depend on something with big dependency chain, for example Java packages depend on maven-local, therefore it may be useful to create snapshot that would contain maven-local. With the next steps, you install the package and create the snapshot
mock --install maven-local
mock --snapshot mvn
Now there should be two snapshots - the initial one and the one you just created. You can verify it with the list-snapshots command (Note it also has short option `-l`)
mock --list-snapshots
Snapshots for fedora-20-x86_64:
postinit
* mvn
The new one is marked with an asterisk, which means it will be used as the default snapshot to which `--clean` will rollback whenever you build another package. When you want to rebuild a package that doesn't use maven-local, you can use
mock --rollback-to postinit
and the initial snapshot will be used for following builds. The mvn snapshot will still exist, so you can get back to it later using
mock --rollback-to mvn
To get delete a snapshot completely, use
mock --remove-snapshot mvn
Mock will leave the buildroot volume mounted by default (you can override it in the config), so you can easily access the build directory. When you need to umount it, use
mock --umount
To getting rid of LVM volumes completely, use
mock --scrub lvm
This will delete all volumes belonging to the current config and also the thinpool if and only if there are no other volumes left by other configurations.
## Setup
The plugin is distributed as separate subpackage `mock-lvm` because it pulls in additional dependencies which are not available on RHEL6.
You need to specify a volume group which mock will use to create it's thinpool. Therefore you need to have some unoccupied space in your volume group, so you'll probably need to shrink some partition a bit. Mock won't touch anything else in the VG, so don't be afraid to use the VG you have for your system. It won't touch any other logical volumes in the VG that don't belong to it.
## Configuration
```python
config_opts['plugin_conf']['root_cache_enable'] = False
config_opts['plugin_conf']['lvm_root_enable'] = True
config_opts['plugin_conf']['lvm_root_opts'] = {
'volume_group': 'my-volume-group',
'size': '8G',
'pool_name': 'mock',
'check_size': True,
}
```
Explanation: You need to disable root_cache - having two caches with the same contents would just slow you down. You need to specify a size for the thinpool. It can be shared across all mock buildroots so make sure it's big enough. Ideally there will be just one thinpool. Then specify name for the thinpool - all configs which have the same pool_name will share the thinpool, thus being more space-efficient. Make sure the name doesn't clash with existing volumes in your system (you can list existing volumes with lvs command).
Every run, the plugin write usage of data pool and metadata pool.
When utilization is over 75 % then plugin emit warning.
Usage over 90 % is fatal and mock stop with error, but it can be override by
config_opts['plugin_conf']['lvm_root_opts']['check_size'] = False
However this override is strongly discouraged as LVM2 have known error when thinpool is full.
### Other configuration options
`config_opts['plugin_conf']['lvm_root_opts']['poolmetadatasize']` - specifies separate size of the thinpool metadata. It needs to be big enough, thinpool with overflown metadata will become corrupted. When unspecified, the default value is determined by LVM
`config_opts['plugin_conf']['lvm_root_opts']['umount_root']` -
boolean option specifying whether the buildroot volume should stay mounted after mock exits. Default is `True`
`config_opts['plugin_conf']['lvm_root_opts']['filesystem']` -
filesystem name that will be used for the volume. It will use
`mkfs.$filesystem` binary to create it. Default is `ext4`
`config_opts['plugin_conf']['lvm_root_opts']['mkfs_command']` - the whole command for creating the filesystem that will get the volume path as an argument. When set, overrides above option.
`config_opts['plugin_conf']['lvm_root_opts']['mkfs_args']` - additional arguments passed to mkfs command. Default is empty.
`config_opts['plugin_conf']['lvm_root_opts']['mount_opts']` - will
be passed to `-o` option of mount when mounting the volume. Default is empty.
`config_opts['plugin_conf']['lvm_root_opts']['mount_opts']` - Let user configure mock to wait more patiently for LVM initialization. `lvs' call can be quite expensive, especially when there are hundreds of volumes and multiple parallel mocks waiting for common LVM initialization to complete. (Added in version 1.4.3)
Note: You can not combine Tmpfs plugin and Lvm_root plugin, because it is not possible to mount Logical Volume as tmpfs.

50
docs/Plugin-Mount.md Normal file
View file

@ -0,0 +1,50 @@
---
layout: default
title: Plugin Mount
---
This plugin allows you to mount directories into chroot. The mount plugin is enabled by default, but has no configured directories to mount.
## Configuration
You can disable this plugin by:
```python
config_opts['plugin_conf']['mount_enable'] = False
```
You can configure this plugin by:
```python
config_opts['plugin_conf']['mount_enable'] = True
config_opts['plugin_conf']['mount_opts']['dirs'].append(("/dev/device", "/mount/path/in/chroot/", "vfstype", "mount_options"))
```
A real life example:
```python
config_opts['plugin_conf']['mount_opts']['dirs'].append(("server.example.com:/exports/data", "/mnt/data", "nfs", "rw,hard,intr,nosuid,nodev,noatime,tcp"))
```
### `/builddir/` cleanup
**WARNING!** The build user's homedir (`/builddir`) is partially cleaned up even when `--no-clean` is
specified in order to prevent garbage from previous builds from altering
successive builds. Mock can be configured to exclude certain files/directories
from this. Default is `SOURCES` directory to support nosrc rpms:
```python
config_opts['exclude_from_homedir_cleanup'] = ['build/SOURCES']
```
Paths are relative to build user's homedir.
So if you do something like this:
```python
config_opts['plugin_conf']['bind_mount_opts']['dirs'].append((os.path.expanduser('~/MyProject'), '/builddir/MyProject' ))
```
Then you SHOULD do:
```python
config_opts['exclude_from_homedir_cleanup'] = ['build/SOURCES', 'MyProject']
```
otherwise your `~/MyProject` will be wiped out!
Other option is to not mount it under `/builddir`, but somewhere else (`/opt`, `/mnt`...).

77
docs/Plugin-Overlayfs.md Normal file
View file

@ -0,0 +1,77 @@
---
layout: default
title: Plugin OverlayFS
---
This plugin implements mock's snapshot functionality using overlayfs. From a user perspective, it works similar to LVM plugin, but unlike LVM plugin, it only needs a directory (not a volume group) for its data (snapshots). Plugin has no additional dependencies, it only requires a kernel with overlayfs support, but this is the case for both current Fedora and RHEL-7.
## Configuration
You can enable overlayfs plugin by adding this line to your configuration:
```python
config_opts['plugin_conf']['overlayfs_enable'] = True
```
It is recommended to disable root_cache plugin when overlayfs plugin is enabled. (Plugin does implicit snapshot named "postinit" after init phase similarly to LVM plugin, which makes root cache pointless)
```python
config_opts['plugin_conf']['root_cache_enable'] = False
```
Base directory sets directory, where places all its data (snapshots etc.) are placed. Multiple configurations can share base directory (every configuration will have its own directory there).
```python
config_opts['plugin_conf']['overlayfs_opts']['base_dir'] = "/some/directory"
```
Enabling touch_rpmd option causes the plugin to implicitly "touch" rpm database files after each mount overcoming issue with rpm/mock, caused by limitations of overlayfs. Option may be useful only when running yum/rpm directly. However, it is not necessary when using package-manager related mock commands (e.g., mock --install). For more details see the section: Limitations of overlayfs (lower).
Default: false
```python
config_opts['plugin_conf']['overlayfs_opts']['touch_rpmdb'] = True
```
## Usage
As said earlier, plugins allow you to use mock's snapshot functionality. Snapshots hold the state of (current config's) root fs, which can be recovered later.
To create snapshot run:
mock --snapshot [name]
You can then return to snapshot created earlier by running (It also makes that snapshot current for clean operation):
mock --rollback-to [name]
To list snapshots use:
mock --list-snapshots
Clean operation discards changes done "on top" of current snapshot. ( basically restores current snapshot ). As noted earlier, plugin implicitly creates a snapshot after init phase. So, if no user snapshots are done, plugin behaves more or less as root cache:
mock --clean # restores current snapshot
To remove all plugin's data associated with configuration (and therefore snapshots), use:
mock --scrub overlayfs
Alternatively, you can remove everything from current configuration:
mock --scrub all
You can also see more examples of snapshot commands usage in [LVM plugin wiki page](https://rpm-software-management.github.io/mock/Plugin-LvmRoot)
( Difference is, that LVM plugin keeps root mounted, while overlayfs not. )
## Shortly about overlayfs filesystem
Overlayfs is pseudo-filesystem in a kernel, which allows to place multiple directories on each other (as overlays) and combine them to a single filesystem. Upper directory and lower directory(ies) are supplied to mount command as the options. Files from lower files are visible, but all writes happen in a upper layer. Deleted files are represented by special files. For more details see [filesystem's documentation](https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt) This plugin uses overlayfs to implement snapshots.
## Notes about the implementation of snapshots
To avoid confusion (in some cases), snapshots as displayed by mock (when using this plugin) should be understood more like references/aliases to actual physical snapshots (internally called LAYERS). This means you can have multiple names for a single physical snapshot (LAYER). This also means, you can see multiple snapshots marked as current when listing snapshots (by mock). This can happen because layers are created lazily, so new LAYER is not allocated immediately after creating a snapshot, but prior to mount. So, for example, when 2 snapshots are done, and no mock action, which requires mount, is done in between, they will point to the same LAYER (expected, no changes have been done; same applies for snapshots created after restoring snapshot and after a clean operation). However, a user can still safely delete just one of these. This is possible because LAYERS are reference counted. So you just remove reference (alias), but LAYER (holding actual snapshot's data) is only deleted when no longer referenced. Apart from user-visible references, it may be referenced by other LAYERS (by ones based on it) and by "current state" (special references)). So, it is safe to remove any "snapshot" (as seen by mock), even current one, without having to worry about "breaking" the mock. If you are interested in even more implementation details, see detailed documentation in plugin's [source file](https://github.com/rpm-software-management/mock/blob/devel/mock/py/mockbuild/plugins/overlayfs.py) or maybe even [test file](https://github.com/rpm-software-management/mock/blob/devel/mock/tests/overlayfs_layers_test.py) (where LAYERS are tested).
## Limitations of overlayfs
Overlayfs has known limitations when it comes to POSIX compatibility. This may cause problems with some programs. The problem happens, when a file from the lower layer (directory) is open for writing (forcing overlayfs copy it to upper layer), while the same file is opened read-only. Open file descriptors then point to different files. Rpm/yum are known to be affected by this issue. See:
[yum/rpm bug on RH bugzilla](https://bugzilla.redhat.com/show_bug.cgi?id=1213602)
[docker overlayfs-driver page](https://docs.docker.com/storage/storagedriver/overlayfs-driver/#limitations-on-overlayfs-compatibility)
So, this is not a bug in the plugin. It is caused by nature/design decisions made in overlafs filesystem (and documented). Problem is work-arounded automatically for package manager related operations done using mock (e.g. mock --install). When running yum/rpm manually, an option can be used to overcome the issue automatically (see higher). If you find another program(s) affected by this issue, you should be able to work-around this simply by "touching" problematic files(s) prior to running that program.
touch /some/file # using mock --shell or mock --chroot
## Using inside docker
Not tested, but you may need to add additional mount where to place this plugin's base_dir. This is because docker may itself use overlayfs. ( Overlayfs cannot use directories which are part of another overlayfs mount. )

28
docs/Plugin-PMRequest.md Normal file
View file

@ -0,0 +1,28 @@
---
layout: default
title: Plugin PM Request
---
This plugin listens to requests for package management commands from within the buildroot, using a UNIX socket. It can be used by buildsystems, that have support for communicating with this plugin, to automatically install missing packages if they're available. It's not advised to enable it globally as it affects build reproducibility, instead, it's better to enable it per-build using `--enable-plugin pm_request`. If the plugin was used during the build, it emits a warning at the end that summarizes the commands that were executed.
Currently, automatic installation of build dependencies using this plugin is supported by Java packaging tooling when building with Maven, Gradle or Ivy.
## Configuration
To enable it globally, set the following:
```python
config_opts['plugin_conf']['pm_request_enable'] = True
```
To enable it for a single build, use:
mock --rebuild foo-1.0-1.src.rpm --enable-plugin pm_request
## The protocol
The plugin creates a Unix socket in /var/run/mock/pm-request inside of the chroot and will read the commands from the socket. It also exports environment variable PM_REQUEST_SOCKET with value of the socket path.
For single request, it reads a single line from the socket (don't forget the newline, otherwise it will wait for more input) that is parsed using shell-like quoting (via shlex) and passed to current package manager. After the command completes, it responds with a line containing either "ok" or "nok" denoting whether the command was successful. The output of the package management command is then written to the socket and the connection is closed. Example of a request:
install foo
Available since mock-1.2.9

26
docs/Plugin-PackageState.md Normal file
View file

@ -0,0 +1,26 @@
---
layout: default
title: Plugin PackageState
---
This plugin optionally dumps additional metadata files into the result dir:
* A list of all available pkgs + repos + other data. This file is named `available_pkgs.log`. This file is not created if you run mock with `--offline` option.
* A list of all installed pkgs + repos + other data. This file is name `installed_pkgs.log`.
Format of `installed_pkgs.log` file is:
%{nevra} %{buildtime} %{size} %{pkgid} installed
## Configuration
The Package_state plugin is enabled by default.
# in version 1.2.18 and older the default was False
config_opts['plugin_conf']['package_state_enable'] = True
The following sub-options may be turned off/on:
```python
config_opts['plugin_conf']['package_state_opts'] = {}
config_opts['plugin_conf']['package_state_opts']['available_pkgs'] = False
config_opts['plugin_conf']['package_state_opts']['installed_pkgs'] = True
```

22
docs/Plugin-ProcEnv.md Normal file
View file

@ -0,0 +1,22 @@
---
layout: default
title: Plugin ProcEnv
---
This plugin allows prints your build time environment, which may help identify problems or reproduced the build.
It prints information about the entire software build environment, any capabilities, and much more.
The information is stored in file procenv.log in the results directory.
It calls `procenv` command and stores its output.
## Configuration
You can enable the plugin using this settings:
```python
config_opts['plugin_conf']['procenv_enable'] = True
config_opts['plugin_conf']['procenv_opts'] = {}
```
Available since version 1.4.18.
This plugin is DISABLED by default.

37
docs/Plugin-RootCache.md Normal file
View file

@ -0,0 +1,37 @@
---
layout: default
title: Plugin RootCache
---
This plugin caches your buildroots. It creates archive of your buildroot and puts it in `config_opts['plugin_conf']['root_cache_opts']['dir']`, which is be default `/var/cache/mock/NAME_OF_CHROOT/root_cache/cache.tar.gz`. It is enabled by default.
## Configuration
This plugin is enabled by default and has the following values built-in:
```python
config_opts['plugin_conf']['root_cache_enable'] = True
config_opts['plugin_conf']['root_cache_opts'] = {}
config_opts['plugin_conf']['root_cache_opts']['age_check'] = True
config_opts['plugin_conf']['root_cache_opts']['max_age_days'] = 15
config_opts['plugin_conf']['root_cache_opts']['dir'] = "%(cache_topdir)s/%(root)s/root_cache/"
config_opts['plugin_conf']['root_cache_opts']['compress_program'] = "pigz"
config_opts['plugin_conf']['root_cache_opts']['extension'] = ".gz"
config_opts['plugin_conf']['root_cache_opts']['exclude_dirs'] = ["./proc", \
"./sys", "./dev", "./tmp/ccache", "./var/cache/yum" ]
```
* `age_check` - if set to `True` (which is default), then cache date is checked. See option `max_age_days` bellow. Additionally if some config is newer than cache file, then the cache is invalidated as well.
* `max_age_days` - if `age_check` is `True` and cache is older than this value, the cache is invalidated.
* `dir` - where to put cached files.
* `compress_program` - which compress program to use. By default `pigz` is used. If not present, then `gzip` is used.
* `extension` - the cache file is always named as `cache.tar$extension`. When you use different compress program e.g. `bzip2`, you should set different extension e.g. `".bz2"`.
* `exclude_dirs` - list of directories, which should not be archived.
**WARNING:** You should disable `root_cache` plugin when using `lvm_root` plugin - having two caches with the same contents would just slow you down.
**NOTE:** If you have enough disk storage you can speed-up it a bit by disabling archiving of cache:
```python
config_opts['plugin_conf']['root_cache_opts']['compress_program'] = ""
config_opts['plugin_conf']['root_cache_opts']['extension'] = ""
```

13
docs/Plugin-SELinux.md Normal file
View file

@ -0,0 +1,13 @@
---
layout: default
title: Plugin SELinux
---
On SELinux enabled box, this plugin will pretend, that SELinux is disabled in build environment.
* fake /proc/filesystems is mounted into build environment, excluding selinuxfs
* option `--setopt=tsflags=nocontext` is appended to each 'yum' command
This plugin is enabled by default and there is actually no way to disable it.
This plugin is not used with NSPAWN chroot (`--new-chroot` option) and will be removed when NSPAWN chroot will be only one option.

97
docs/Plugin-Scm.md Normal file
View file

@ -0,0 +1,97 @@
---
layout: default
title: Plugin SCM
---
This plugin provides integration to Scm systems (Git, Svn...).
This module does not use the plugin infrastructure of Mock, it is provided as a standalone package instead, mock-scm, so we dare to call it plugin.
## Configuration
In your config file insert the following lines:
```python
config_opts['scm'] = True
config_opts['scm_opts']['method'] = 'git'
config_opts['scm_opts']['cvs_get'] = 'cvs -d /srv/cvs co SCM_BRN SCM_PKG'
config_opts['scm_opts']['git_get'] = 'git clone --depth 1 SCM_BRN git://localhost/SCM_PKG.git SCM_PKG'
config_opts['scm_opts']['svn_get'] = 'svn co file:///srv/svn/SCM_PKG/SCM_BRN SCM_PKG'
config_opts['scm_opts']['distgit_get'] = 'rpkg clone -a --branch SCM_BRN SCM_PKG SCM_PKG'
config_opts['scm_opts']['distgit_src_get'] = 'rpkg sources'
config_opts['scm_opts']['spec'] = 'SCM_PKG.spec'
config_opts['scm_opts']['int_src_dir'] = None
config_opts['scm_opts']['ext_src_dir'] = '/dev/null'
config_opts['scm_opts']['write_tar'] = True
config_opts['scm_opts']['git_timestamps'] = True
config_opts['scm_opts']['exclude_vcs'] = True
config_opts['scm_opts']['package'] = 'mypkg'
config_opts['scm_opts']['branch'] = 'master'
```
While you can specify this in configuration file, this is less flexible and you may rather use command line options. E.g. `config_opts['scm_opts']['method'] = 'git'` is the same as `--scm-option method=git` or `config_opts['scm_opts']['branch'] = 'master'` is the same as `--scm-option branch=master`.
## Tar file
When either `write_tar` is set to `True` or `/var/lib/mock/<chroot>/root/builddir/build/SOURCES/` contains `.write_tar`. Mock will create tar file from whole SVN repo. This is what you probably want to. Otherwise you have to manually create the tar file and put it there yourself before you run mock command.
Extension and compression method is chosen automatically according your Source line in spec file. Therefore if there is:
Source: http://foo.com/%{name}-%{version}.tar.xz
then mock will create tar file with .tar.xz extension and compressed by xz. Similarly if you choose .tar.gz or .tar.bz2 or any other known extension.
### git_timestamps
When `git_timestamps` is set to True, then modification time of each file in GIT is altered to datetime of last commit relevant to each file.
This option is available only to Git method and not for others.
### exclude-vcs
When `exclude-vcs` is set to True, then `--exclude-vcs` option is passed to tar command.
### int_src_dir
When `int_src_dir` is specified, Mock will use that directory in the repository as the SOURCES instead of the repository root.
### ext_src_dir
When your source (or patch) file does not exist in `/var/lib/mock/<chroot>/root/builddir/build/SOURCES/` directory then it is looked up in `ext_src_dir` and copy there.
### dist-git
Since version 1.3.4, there is support for [dist-git](https://github.com/release-engineering/dist-git). In fact it can support any DistSVN or DistCVS method. You just specify which command clone the repository (`distgit_get`) and which command retrieve sources (`distgit_src_get`). Mock-scm will then construct SRPM from those spec file and sources. Do not forget to specify `config_opts['scm_opts']['method'] = 'distgit'`
## Example
In this example, mock will clone `master` branch of `github.com/xsuchy/rpmconf.git` and use `./rpmconf.spec` in that directory to build rpm package:
```sh
mock -r fedora-22-x86_64 \
--scm-enable \
--scm-option method=git \
--scm-option package=rpmconf \
--scm-option spec=rpmconf.spec \
--scm-option branch=master \
--scm-option write_tar=True \
--scm-option git_get='git clone https://github.com/xsuchy/rpmconf.git'
```
Or you can:
cp /etc/mock/fedora-22-x86_64.cfg ./my-config.cfg
vi ./my-config.cfg
put there those lines:
```python
config_opts['scm'] = True
config_opts['scm_opts']['method'] = 'git'
config_opts['scm_opts']['git_get'] = 'git clone https://github.com/xsuchy/rpmconf.git'
config_opts['scm_opts']['spec'] = 'rpmconf.spec'
config_opts['scm_opts']['write_tar'] = True
config_opts['scm_opts']['package'] = 'rpmconf'
config_opts['scm_opts']['branch'] = 'master'
```
and then just call
mock -r ./my-config.cfg

19
docs/Plugin-Showrc.md Normal file
View file

@ -0,0 +1,19 @@
---
layout: default
title: Plugin Showrc
---
This plugin dumps all the build time RPM macros (via `rpm --showrc`) into result directory as `showrc.log` file, which may help identify problems of (or reproduce) the build.
It prints information about all defined RPM macros.
## Configuration
You can enable the plugin using this settings:
```python
config_opts['plugin_conf']['showrc_enable'] = True
```
Available since version 2.5.
This plugin is DISABLED by default.

21
docs/Plugin-Sign.md Normal file
View file

@ -0,0 +1,21 @@
---
layout: default
title: Plugin Sign
---
The Sign plugin can call command (from the host) on the produced rpms.
It was primary created for signing packages, but can call anything you want to.
## Configuration
The Sign plugin is disabled by default. To enable it, add this code to configure file:
```python
config_opts['plugin_conf']['sign_enable'] = True
config_opts['plugin_conf']['sign_opts'] = {}
config_opts['plugin_conf']['sign_opts']['cmd'] = 'rpmsign'
config_opts['plugin_conf']['sign_opts']['opts'] = '--addsign %(rpms)s'
```
The variable %(rpms)s will be expanded to package file name. This command will run as unprivileged and will get all your environment variables and especially it will run in your $HOME. So `~/.rpmmacros` will be interpreted.
Since mock-1.2.14 there is also available variable `%(resultdir)`, which will be expanded to name of directory where are final rpm packages.

25
docs/Plugin-Tmpfs.md Normal file
View file

@ -0,0 +1,25 @@
---
layout: default
title: Plugin TmpFS
---
The TmpFS plugin allows you to mount a tmpfs on the chroot dir. This plugin is disabled by default.
## Configuration
You can enable the plugin using this settings:
```python
config_opts['plugin_conf']['tmpfs_enable'] = True
config_opts['plugin_conf']['tmpfs_opts'] = {}
config_opts['plugin_conf']['tmpfs_opts']['required_ram_mb'] = 1024
config_opts['plugin_conf']['tmpfs_opts']['max_fs_size'] = '768m'
config_opts['plugin_conf']['tmpfs_opts']['mode'] = '0755'
config_opts['plugin_conf']['tmpfs_opts']['keep_mounted'] = False
```
* `required_ram_mb` - If system has less memory than this value, the TmpFS plugin will be disabled and a warning is omitted, but `mock` will continue.
* `max_fs_size` - this is passed to `mount.tmpfs` as `-o size=X`
* `mode` - this is passed to to `mount.tmpfs` as `-o mode=X`
* `keep_mounted` - when set to `True`, the `buildroot` is not unmounted when mock exits (which will destroy it's content). Additionally when mock is starting and it detects the tmpfs from a previous run, it will reuse it.
:warning: You can not combine **Tmpfs plugin** and **Lvm_root plugin**, because it is not possible to mount Logical Volume as tmpfs.

25
docs/Plugin-YumCache.md Normal file
View file

@ -0,0 +1,25 @@
---
layout: default
title: Plugin YumCache
---
This plugin pre-mounts `/var/cache/{yum,dnf}` directories inside chroot, so the package manager's metadata don't have to be re-downloaded between subsequent mock commands (the caches survive `mock --clean` for example). This plugin is needed because dnf (or yum) `--installroot DIRECTORY` commands store caches below the `DIRECTORY`.
It mounts directories `/var/cache/mock/<chroot>/{dnf,yum}_cache` as `/var/cache/{dnf,yum}` in chroot.
You can explicitly clean the package manager caches by `--scrub=dnf-cache` option.
## Configuration
This plugin is **enabled by default** and has the following values built-in:
```python
config_opts['plugin_conf']['yum_cache_enable'] = True
config_opts['plugin_conf']['yum_cache_opts'] = {}
config_opts['plugin_conf']['yum_cache_opts']['max_age_days'] = 30
config_opts['plugin_conf']['yum_cache_opts']['max_metadata_age_days'] = 30
config_opts['plugin_conf']['yum_cache_opts']['online'] = True
```
* `max_age_days` - when files in cache directory is older than this number of days, then such files are removed
* `max_metadata_age_days` - when metadata (everything with suffix: ".sqlite", ".xml", ".bz2", ".gz") in cache directory is older than this number of days, then such files are removed.
* `online` - when `False`, mock doesn't apply policies for `max_*_age_days` options (complements `--offline` option)

51
docs/Plugin-rpkg-preprocessor.md Normal file
View file

@ -0,0 +1,51 @@
---
layout: default
title: Plugin rpkg preprocessor
---
This plugin allows you to run preprocessing on an input spec file just before srpm build is started.
Preprocessing is implemented by a simple `preproc` language which allows you to place: `{% raw %}{{{ bash_code }}}{% endraw %}` tags into any text file. When you run such text file through `preproc` command-line utility, a "rendered" text file is output where all the `{% raw %}{{{ bash_code }}}{% endraw %}` tags are now replaced by standard output of the executed `bash_code` that was inside the `{% raw %}{{{ }}}{% endraw %}` tags.
`preproc` also allows you to load a certain library of macros (by `-s` switch on its command-line) which are essentially just bash functions that you can afterward use from any `{% raw %}{{{&nbsp;}}}{% endraw %}` tag in the input text file.
One such library is called `rpkg-macros` and its macros are documented [here](https://docs.pagure.org/rpkg-util/v3/macro_reference.html). These macros are specialized to render rpm spec file's dynamically based on surrounding git metadata. They need the spec file you are building srpm from to be placed in a git repository.
`preproc` with the `rpkg-macros` library loaded is exactly what is used to perform preprocessing on spec file by the `rpkg_preprocessor` plugin. Instead of calling `preproc` directly with the `-s` switch to load `rpkg-macros`, we use a tiny `preproc-rpmspec` wrapper that does this for us but it could be done either way.
Note that just enabling the plugin is not enough to get spec file preprocessed. You additionally need `rpkg.conf` file placed next to the spec file with the following content:
```ini
[rpkg]
preprocess_spec = True
```
That's because for some packages you might want to have preprocessing disabled even though the plugin is globally enabled. Note that even if you have rpkg preprocessing globally enabled (e.g. in `/etc/mock/site-defaults.cfg`) and the `rpkg.conf` file is present with the required content to enable preprocessing, you still have an option to disable preprocessing on command-line by using mock's option `--disable-plugin=rpkg_preprocessor`. There is also `--enable-plugin=rpkg_preprocessor` to do the opposite.
There is currently only one mock command that does invoke the `rpkg_preprocessor` plugin (if all the conditions above are satisfied): `mock --buildsrpm`. This plugin is not employed for rebuilding existing srpms with `mock --rebuild` command or any other mock operation currently.
An example usage with the `mock --buildsrpm` command is:
$ cd <package_git_repository>
$ mock --buildsrpm --spec ./my_package.spec.rpkg --sources .
This will run preprocessing on `my_package.spec.rpkg` and the output spec file will be then handed over to `rpmbuild` to build srpm from it.
`.rpkg` extension for rpm spec files containing rpkg macros is optional but recommended.
## Configuration
The plugin supports the following configuration options (mentioned together with the default values):
```python
config_opts['plugin_conf']['rpkg_preprocessor_enable'] = False
config_opts['plugin_conf']['rpkg_preprocessor_opts']['requires'] = ['preproc-rpmspec']
config_opts['plugin_conf']['rpkg_preprocessor_opts']['cmd'] = '/usr/bin/preproc-rpmspec %(source_spec)s --output %(target_spec)s'
```
* `rpkg_preprocessor_enable` option switches the plugin on and off
* `requires` option specifies requirements to perform the preprocessing operation. The operation is done in a chroot where srpm is built afterwards so the tool(s) to perform preprocessing need to be installed there first
* `cmd` option defines the actual command to run the preprocessing operation.
`requires` and `cmd` options are there for possible future updates in the used tooling. You don't need to modify these options to get the default preprocessing functionality. The only line needed in `/etc/mock/site-defaults.cfg` to enable this plugin is:
```python
config_opts['plugin_conf']['rpkg_preprocessor_enable'] = True
```
This plugin is available since mock-x.x.x.

121
docs/README.md Normal file
View file

@ -0,0 +1,121 @@
---
layout: default
title: README
---
# The Slate theme
[![.github/workflows/ci.yaml](https://github.com/pages-themes/slate/actions/workflows/ci.yaml/badge.svg)](https://github.com/pages-themes/slate/actions/workflows/ci.yaml) [![Gem Version](https://badge.fury.io/rb/jekyll-theme-slate.svg)](https://badge.fury.io/rb/jekyll-theme-slate)
*Slate is a Jekyll theme for GitHub Pages. You can [preview the theme to see what it looks like](http://pages-themes.github.io/slate), or even [use it today](#usage).*
![Thumbnail of Slate](thumbnail.png)
## Usage
To use the Slate theme:
1. Add the following to your site's `_config.yml`:
```yml
remote_theme: pages-themes/slate@v0.2.0
plugins:
- jekyll-remote-theme # add this line to the plugins list if you already have one
```
2. Optionally, if you'd like to preview your site on your computer, add the following to your site's `Gemfile`:
```ruby
gem "github-pages", group: :jekyll_plugins
```
## Customizing
### Configuration variables
Slate will respect the following variables, if set in your site's `_config.yml`:
```yml
title: [The title of your site]
description: [A short description of your site's purpose]
```
Additionally, you may choose to set the following optional variables:
```yml
show_downloads: ["true" or "false" (unquoted) to indicate whether to provide a download URL]
google_analytics: [Your Google Analytics tracking ID]
```
### Stylesheet
If you'd like to add your own custom styles:
1. Create a file called `/assets/css/style.scss` in your site
2. Add the following content to the top of the file, exactly as shown:
```scss
---
---
@import "{{ site.theme }}";
```
3. Add any custom CSS (or Sass, including imports) you'd like immediately after the `@import` line
*Note: If you'd like to change the theme's Sass variables, you must set new values before the `@import` line in your stylesheet.*
### Layouts
If you'd like to change the theme's HTML layout:
1. For some changes such as a custom `favicon`, you can add custom files in your local `_includes` folder. The files [provided with the theme](https://github.com/pages-themes/slate/tree/master/_includes) provide a starting point and are included by the [original layout template](https://github.com/pages-themes/slate/blob/master/_layouts/default.html).
2. For more extensive changes, [copy the original template](https://github.com/pages-themes/slate/blob/master/_layouts/default.html) from the theme's repository<br />(*Pro-tip: click "raw" to make copying easier*)
3. Create a file called `/_layouts/default.html` in your site
4. Paste the default layout content copied in the first step
5. Customize the layout as you'd like
### Customizing Google Analytics code
Google has released several iterations to their Google Analytics code over the years since this theme was first created. If you would like to take advantage of the latest code, paste it into `_includes/head-custom-google-analytics.html` in your Jekyll site.
### Overriding GitHub-generated URLs
Templates often rely on URLs supplied by GitHub such as links to your repository or links to download your project. If you'd like to override one or more default URLs:
1. Look at [the template source](https://github.com/pages-themes/slate/blob/master/_layouts/default.html) to determine the name of the variable. It will be in the form of `{{ site.github.zip_url }}`.
2. Specify the URL that you'd like the template to use in your site's `_config.yml`. For example, if the variable was `site.github.url`, you'd add the following:
```yml
github:
zip_url: http://example.com/download.zip
another_url: another value
```
3. When your site is built, Jekyll will use the URL you specified, rather than the default one provided by GitHub.
*Note: You must remove the `site.` prefix, and each variable name (after the `github.`) should be indent with two space below `github:`.*
For more information, see [the Jekyll variables documentation](https://jekyllrb.com/docs/variables/).
## Roadmap
See the [open issues](https://github.com/pages-themes/slate/issues) for a list of proposed features (and known issues).
## Project philosophy
The Slate theme is intended to make it quick and easy for GitHub Pages users to create their first (or 100th) website. The theme should meet the vast majority of users' needs out of the box, erring on the side of simplicity rather than flexibility, and provide users the opportunity to opt-in to additional complexity if they have specific needs or wish to further customize their experience (such as adding custom CSS or modifying the default layout). It should also look great, but that goes without saying.
## Contributing
Interested in contributing to Slate? We'd love your help. Slate is an open source project, built one contribution at a time by users like you. See [the CONTRIBUTING file](docs/CONTRIBUTING.md) for instructions on how to contribute.
### Previewing the theme locally
If you'd like to preview the theme locally (for example, in the process of proposing a change):
1. Clone down the theme's repository (`git clone https://github.com/pages-themes/slate`)
2. `cd` into the theme's directory
3. Run `script/bootstrap` to install the necessary dependencies
4. Run `bundle exec jekyll serve` to start the preview server
5. Visit [`localhost:4000`](http://localhost:4000) in your browser to preview the theme
### Running tests
The theme contains a minimal test suite, to ensure a site with the theme would build successfully. To run the tests, simply run `script/cibuild`. You'll need to run `script/bootstrap` once before the test script will work.

17
docs/Release-Notes-1.2.13.md Normal file
View file

@ -0,0 +1,17 @@
---
layout: default
title: Release Notes 1.2.13
---
mock-1.2.13 is bugfix release, but some bugfix may be interesting for you:
* Fedora 23 configs are reverted back to use yum again. To be on pair
with Koji
* Lot of fixes for --new-chroot option
* Mockchain can download SRPM from Dropbox
* DNF does not install weak dependencies by default
* When cleaning up chroots, mock now exclude mountpoints
* When you build using DNF (rawhide) on systems, which does not have DNF (EL6, 7), mock will print warning, wait for confirmation, tell you how to suppress this warning next time. Nevertheless this warning is not fatal and Mock can continue using YUM.
* Previously package_state plugin always used YUM, now it use DNF when chroot is configured to use DNF.
* When file `/usr/bin/yum-deprecated` is present on your machine, then variable `config_opts['yum_command']` is set to this value by default.
* Several others bugfixes

12
docs/Release-Notes-1.2.14.md Normal file
View file

@ -0,0 +1,12 @@
---
layout: default
title: Release Notes 1.2.14
---
mock-1.2.14 is bugfix release, but some bugfix may be interesting for you:
* --new-chroot now works on rhel7
* create tmpfs with unlimited inodes [RHBZ#1266453](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1266453) - otherwise architectures with large pages (e.g. PPC64) can use only fraction of the tmpfs capacity.
* Add %(resultdir) placeholder for sign plugin. [RHBZ#1272123](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1272123)
* use --setopt=deltarpm=false as default value for dnf_common_opts [RHBZ#1281355](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1281355)
* fixed issue with /home mount on nfs [RHBZ#1281369](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1281369)

14
docs/Release-Notes-1.2.15.md Normal file
View file

@ -0,0 +1,14 @@
---
layout: default
title: Release Notes 1.2.15
---
mock-1.2.15 introduce these changes:
* Fedora 24 chroot configs (and Fedora 21 was removed).
* ccache plugin is by default off - to copy behaviour of Koji and Copr.
* ~/.config/mock.cfg is parsed too (beside ~/.mock/user.cfg).
And several bugfixes:
* buildroot is removed as root [RHBZ#1294979](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1294979)
* "local" dnf plugin is disable [RHBZ#1264215](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1264215)

19
docs/Release-Notes-1.2.16.md Normal file
View file

@ -0,0 +1,19 @@
---
layout: default
title: Release Notes 1.2.16
---
mock-1.2.16 has been released to get rid of annoying errors due selinux [RHBZ#1312820](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1312820).
Additionally mock-1.2.16 introduces these changes:
* sparc configs has been removed
* instead of systemd-nspawn mock now requires systemd-container in F24+
And several bugfixes:
* do not call /bin/su and rather utilize --user of systemd-nspawn [RHBZ#1301953](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1301953)
* tell nspawn which variables it should set [RHBZ#1311796](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1311796)
Known issue:
* When you run mockchain with several SRPMs, then it may fails due deluser bug [RHBZ#1315864](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1315864)

6
docs/Release-Notes-1.2.17.md Normal file
View file

@ -0,0 +1,6 @@
---
layout: default
title: Release Notes 1.2.17
---
mock-1.2.17 is just quick release, which is fixing major issue in 1.2.16 and which was not catch during release testing.

47
docs/Release-Notes-1.2.18.md Normal file
View file

@ -0,0 +1,47 @@
---
layout: default
title: Release Notes 1.2.18
---
mock-1.2.18 has several bugfixes:
* copy just content of SRPM not the attributes ([RHBZ#1301985](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1301985))
* do not fail when we cannot link default.cfg ([RHBZ#1305367](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1305367))
* Build always fails when using --nocheck ([RHBZ#1327594](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1327594))
* keep machine-id in /etc/machine-id ([RHBZ#1344305](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1344305))
And several changes:
* Unconditionally setup resolver config
* use DNF for F24 chroot
* requires rpm-python
* Escape the escape sequences in PROMPT_COMMAND, improve prompt
* Use root name instead config name for backups dir
* Add MIPS personalities
* scm plugin handle better submodules
And there are two new groups of configs. There are new [Mageia](https://www.mageia.org) configs:
* mageia-cauldron-armv5tl
* mageia-cauldron-armv7hl
* mageia-cauldron-i586
* mageia-cauldron-x86_64
* mageia-6-armv5tl
* mageia-6-armv7hl
* mageia-6-i586
* mageia-6-x86_64
And there are new custom configs:
* custom-1-aarch64
* custom-1-armhfp
* custom-1-i386
* custom-1-ppc64
* custom-1-ppc64le
* custom-1-s390
* custom-1-s390x
* custom-1-x86_64
Those configs does not have any repository configured and base is empty. I.e:
config_opts['chroot_setup_cmd'] = ""
This is useful if you want to prepare the chroot yourself. Or when you use it with mockchain with `--addrepo=REPOS` option. This was added on request of [Koschei](https://fedoraproject.org/wiki/Koschei), which will use it.

19
docs/Release-Notes-1.2.19.md Normal file
View file

@ -0,0 +1,19 @@
---
layout: default
title: Release Notes 1.2.19
---
Mock version 1.2.19 has those changes:
* plugin [PackageState](Plugin/PackageState) is now enabled by default and it has new options. By default this plugin now generate list of installed packages. List of available packages is disabled by default.
* Fedora 25 configs has been added
* GPG keys in configs are now used from package `distribution-gpg-keys`. Keys in `/etc/pki/mock` will be still shipped for some time, so we do not break old user config. But new one will not be added and users are encouraged to migrate their paths to GPG keys.
* you can include some other config using:
``include('/path/to/config/to/be/included/include.cfg')``
* there is new option available which will install additional package to minimal chroot. This is extension of already existing option `chroot_setup_cmd`. It was added to easy automated changed of minimal buildroot in Copr.:
``config_opts['chroot_additional_packages'] = 'some_package other_package'``
* And it resolves those bugs: RHBZ#1272381, RHBZ#1358397, RHBZ#1362478, RHBZ#1277187, RHBZ#1298220, RHBZ#1264508.
And few notes about future release:
* in next release will be very likely resolved [RHBZ#1246810](https://bugzilla.redhat.com/show_bug.cgi?id=1246810). I.e. /usr/sbin/mock will be moved to /usr/libexec/mock/mock. Since this is very big change, next release will likely be 1.3.0
* Development and documentation will likely move to Github or Pagure. Please follow buildsys mailing list.

6
docs/Release-Notes-1.2.20.md Normal file
View file

@ -0,0 +1,6 @@
---
layout: default
title: Release Notes 1.2.20
---
Mock 1.2.20 is just bugfix release, which use correct gpg keys for epel in epel* configs.

13
docs/Release-Notes-1.2.21.md Normal file
View file

@ -0,0 +1,13 @@
---
layout: default
title: Release Notes 1.2.21
---
Mock version 1.2.21 is security release. It fixes:
* CVE-2016-6299 - privilige escalation via mock-scm [RHBZ#1375493](https://bugzilla.redhat.com/show_bug.cgi?id=1375493)
Additionally it has those changes:
- root_cache: Mention _root_ cache being created in state updates (log messages)
- Rename mageia pubkey to RPM-GPG-KEY-Mageia
- require generic system-release rather than fedora-release [RHBZ#1367746](https://bugzilla.redhat.com/show_bug.cgi?id=1367746)

33
docs/Release-Notes-1.3.2.md Normal file
View file

@ -0,0 +1,33 @@
---
layout: default
title: Release Notes 1.3.2
---
This is a release with big changes. Prior to this release there have been version 1.3.1, but it was never actually released. It was just tagged commit and was intended just for developers for testing. This is first public release after big internal changes.
There are those changes:
* move `/usr/sbin/mock` to `/usr/libexec/mock/mock` [RHBZ#1246810](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1246810)
Previously there were /usr/bin/mock and /usr/sbin/mock. It caused some confusion. Script `/usr/sbin/mock` should not be run directly, but some people (and containers) had /usr/sbin first in their path. So this script is now in `/usr/libexec/`, which are not in `$PATH`. In other word: you can still type "mock" and mock will start. If you ever seen this error
`ERROR: The most common cause for this error is trying to run `/usr/sbin/mock` as an unprivileged user.` then you should not see it anymore.
* F22 configs has been removed
* Just for developers: I removed the automake and it will use Tito now. If you are new to tito, then just:
```bash
sudo dnf install tito
tito build --rpm --test -i # install code from last commit
tito build --rpm # build latest tagged version
```
The benefits are that release process is now *much* easier. And there are no more build artefacts directly in git repo.
* `--nocheck` is working again [GH#2](https://github.com/rpm-software-management/mock/issues/2)
* You can now run mock inside of Docker [RHBZ#1336750](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1336750) - however you need to run docker with `-cap-add=SYS_ADMIN`.
* When building for Fedora 25+ target in container, then buildhost is set to name of host and not to name of container. [RHBZ#1302040](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1302040)
These are the new defaults:
```
## When RPM is build in container then build hostname is set to name of
## container. This sets the build hostname to name of container's host.
## Works only in F25+ chroots
# config_opts['use_container_host_hostname'] = True
## This works in F25+ chroots. This overrides 'use_container_host_hostname' option
# config_opts['macros']['%_buildhost'] = 'my.own.hostname'
```
* There was a lot of flake8/pep8/pycodestyle clean up of code.

32
docs/Release-Notes-1.3.3.md Normal file
View file

@ -0,0 +1,32 @@
---
layout: default
title: Release Notes 1.3.3
---
There are new features:
* All chroot (but rawhide) configs now contains `best=1`. This way DNF will always try to install latest package.
If its dependence cannot be satisfied DNF will report an error. Without this DNF may silently install some older
version which does not have broken deps.
This is fine for regular user, but not for buildsystems, where maintainers usually want to
use latest version.
Note that this change may result in sudden build failure, which previously silently succedded.
In this case, please check your BuildRequires and ask maintainers of those build deps to resolve broken dependency.
This option was not added to rawhide chroots as there are broken dependencied very often.
Additionaly option `best=1` is used for repos passed to mockchain using `-a` option.
* new config for epel-7-aarch64 chroot
* You can use new variable `hostname`: `config_opts['hostname'] = 'my.own.hostname'`
This unconditionally calls `sethostname()`, however
variable `use_container_host_hostname` or `%_buildhost` macro can override this (on F25+).
* Use DNF on RHEL, when it is installed and configured [RHBZ#1405783](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1405783)
* Temporary directories now use `tmp.mock.` prefix.
* Temporary directories are now removed even when buildroot is not cleaned.
* Add bash completion for .cfg files outside /etc/mock [#20](https://github.com/rpm-software-management/mock/pull/20)
There are some bugfixes:
* Handle working directories which contains spaces [RHBZ#1389663](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1389663)
* Error: is not iterable [RHBZ#1387895](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1387895)
* Delay mounting of user-defined mountpoints [RHBZ#1386544](http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1386544)
* Added example how to use `more_buildreqs` when you need more packages
* Added example how to use `--plugin-option`

29
docs/Release-Notes-1.3.4.md Normal file
View file

@ -0,0 +1,29 @@
---
layout: default
title: Release Notes 1.3.4
---
There are new features:
* [scm plugin](Plugin-Scm) now supports [DistGit](https://github.com/release-engineering/dist-git/) (or DistSVN etc.) .
* log files of [package_state plugin](Plugin-PackageState) got `.log` extension. I.e. `available_pkgs.log` and `installed_pkgs.log`.
* Configuration files for Fedora 26 has been added.
* Configuration files for Fedora 23 has been removed.
* Even rawhide configs now use best=1.
* when Mock is run directly without consolehelper it now return exit code 2.
* You can pass additional arguments to systemd-nspawn using this config option: `config_opts['nspawn_args'] = []`.
* kojipkgs urls now use https instead of http.
* new plugin [hw_info](Plugin-HwInfo) which prints HW information of builder. This plugin is enabled by default.
There are some bugfixes:
* reflect change of "Rawhide" to "rawhide" in /etc/os-release [RHBZ#1409735](https://bugzilla.redhat.com/show_bug.cgi?id=1409735)
* in site-defaults.cfg is more examples of how to set up PS1 [RHBZ#1183733](https://bugzilla.redhat.com/show_bug.cgi?id=1183733)
* preserve mode of files when doing chroot_scan [RHBZ#1297430](https://bugzilla.redhat.com/show_bug.cgi?id=1297430)
* shell in systemd-nspawn is run as PID 2 [RHBZ#1372234](https://bugzilla.redhat.com/show_bug.cgi?id=1372234) - this is not done in EL7 version of systemd-nspawn does not support it
* debuginfo repos has been renamed so `mock --dnf-cmd debuginfo-install PACKAGE` works now [RHBZ#1409734](https://bugzilla.redhat.com/show_bug.cgi?id=1409734)
Notes:
* next version will have systemd-nspawn as default. This can break your scripts built on top of Mock. You can try the new behaviour using `--new-chroot` option.
* next version will not be released for EL6. You are advised to upgrade to EL7.

10
docs/Release-Notes-1.3.5.md Normal file
View file

@ -0,0 +1,10 @@
---
layout: default
title: Release Notes 1.3.5
---
This is bugfix release only for EL6:
* Change path to "df" in hw-info plugin [RHBZ#1428301](https://bugzilla.redhat.com/show_bug.cgi?id=1428301)
EL7 and Fedoras are not affected, therefore I did not release this version there.

47
docs/Release-Notes-1.4.1.md Normal file
View file

@ -0,0 +1,47 @@
---
layout: default
title: 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. *NOTE*: network is disabled inside container by default now; take a look into `site-defaults.cfg` for desired options (like `rpmbuild_networking`).
* 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.
* `hw_info` plugin chown logs to user who executed mock also.
* 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.

51
docs/Release-Notes-1.4.10.md Normal file
View file

@ -0,0 +1,51 @@
---
layout: default
title: Release Notes 1.4.10
---
Released on 2018-05-10.
Features:
- There is a new plugin [overlayfs](Plugin-Overlayfs). This plugin implements mock's snapshot functionality using overlayfs. From a user perspective, it works similar to LVM plugin, but unlike LVM plugin, it only needs a directory (not a volume group) for its data (snapshots).
- Previously a [bind_mount](Plugin-BindMount) plugin allowed to mount just a directory. Now, you can bind mount even a single file.
- Previously a [chroot_scan](Plugin-ChrootScan) allowed retrieving artifacts from chroot where build started. Now, it can extract objects even from chroot which failed to initialize.
Bugfixes:
- Change sign plugin to sign only built RPMs and not every file in results directory [RHBZ#1217495](https://bugzilla.redhat.com/show_bug.cgi?id=1217495)
- encode content before writing [GH#176](https://github.com/rpm-software-management/mock/issues/176)
- revert workaround introduced in 057c51d6 [RHBZ#1544801](https://bugzilla.redhat.com/show_bug.cgi?id=1544801)
Note:
Few weeks ago, I released a new `mock-core-configs` package and there is a new feature.
It contains:
```
$ ls -l /etc/mock
...
lrwxrwxrwx. 1 root mock 26 May 2 09:13 fedora-29-aarch64.cfg -> fedora-rawhide-aarch64.cfg
lrwxrwxrwx. 1 root mock 25 May 2 09:13 fedora-29-armhfp.cfg -> fedora-rawhide-armhfp.cfg
lrwxrwxrwx. 1 root mock 23 May 2 09:13 fedora-29-i386.cfg -> fedora-rawhide-i386.cfg
lrwxrwxrwx. 1 root mock 24 May 2 09:13 fedora-29-ppc64.cfg -> fedora-rawhide-ppc64.cfg
lrwxrwxrwx. 1 root mock 26 May 2 09:13 fedora-29-ppc64le.cfg -> fedora-rawhide-ppc64le.cfg
lrwxrwxrwx. 1 root mock 24 May 2 09:13 fedora-29-s390x.cfg -> fedora-rawhide-s390x.cfg
lrwxrwxrwx. 1 root mock 25 May 2 09:13 fedora-29-x86_64.cfg -> fedora-rawhide-x86_64.cfg
```
The plan is that during Fedora branching event I will:
* remove those symlinks and create regular files pointing to Fedora 29 repos
* create fedora-30-* as symlinks to fedora-rawhide-*
This will give you a choice to target rawhide using "rawhide" string or using the number.
Following contributors contributed to this release:
* Martin Necas
* Michal Novotný
* Neal Gompa
* Todd Zullinger
* Zdenek Zambersky
Thank you.

86
docs/Release-Notes-1.4.11.md Normal file
View file

@ -0,0 +1,86 @@
---
layout: default
title: Release Notes 1.4.11
---
Released on 2018-06-12.
## Features:
- Previously you were able to only build for compatible architectures. I.e., you can build `i386` package on `x86_64` architecture. When you tried to build for incompatible architecture, you get this error:
```
$ mock -r fedora-28-ppc64le shell
ERROR: Cannot build target ppc64le on arch x86_64, because it is not listed in legal_host_arches ('ppc64le',)
```
Now, you can build for any architecture using new option --force-arch ARCH. [GH#120](https://github.com/rpm-software-management/mock/issues/120) You have to have installed package `qemu-user-static`, which is a new soft dependence. Try this:
```
$ sudo dnf install qemu-user-static
$ mock -r fedora-28-ppc64le --forcearch ppc64le shell
```
and you get the prompt in PPC64LE Fedora. You can do this for any architecture supported by QEMU. Note: Do not confuse `--forcearch` and `--arch` which are very different options.
- Mock previously only supported GNU Tar. Now Mock supports BSD Tar as well. [GH#169](https://github.com/rpm-software-management/mock/issues/169) There is a new option in config available:
```
# You can configure which tar is used (for root cache and SCM plugin)
# valid options are: "gnutar" or "bsdtar"
# config_opts['tar'] = "gnutar"
```
Be aware that if you created a cache using gnutar then you cannot extract it using bsdtar. Therefore when changing this option, you have to scrub all caches.
- There is a new config option:
```
# name of user that is used when executing commands inside the chroot
# config_opts['chrootuser'] = 'mockbuild'
```
This can be changed to different value. E.g., 'root'. However, be aware that any other value than 'mockbuild' is not tested by upstream.
- There is initial support for MicroDnf [GH#76](https://github.com/rpm-software-management/mock/issues/76) Be aware the due MicroDNF is missing `--installroot` option, the buildroot and build dependencies are still installed by DNF. These are new options related to MicroDNF:
```
# config_opts['microdnf_command'] = '/usr/bin/microdnf'
## "dnf-install" is special keyword which tells mock to use install but with DNF
# config_opts['microdnf_install_command'] = 'dnf-install microdnf dnf dnf-plugins-core distribution-gpg-keys'
# config_opts['microdnf_builddep_command'] = '/usr/bin/dnf'
# config_opts['microdnf_builddep_opts'] = []
# config_opts['microdnf_common_opts'] = []
# config_opts['microdnf_command'] = '/usr/bin/microdnf'
config_opts['package_manager'] = 'microdnf'
```
Right now, Mock does not ship any config which use this package manager.
- There is a new option `--spec`, which you can use to build an SRPM.
```
# dnf download --source foo
# rpm2cpio foo.src.rpm | cpio -dimv
(Add/modify compilation flags in .spec file)
# mock --spec foo.spec foo.src.rpm --postinstall
(or)
# mock --spec foo.spec --sources ./
```
## Bugfixes:
- The file `/etc/resolv.conf` is now empty when networking is disabled. [RHBZ#1514028](https://bugzilla.redhat.com/show_bug.cgi?id=1514028) This reduces timeout when code tries to connect to a network. Note that option `config_opts['use_host_resolv']` changed from True to False as networking is disabled by default too. Note that `--enable-network` automatically set `config_opts['use_host_resolv']` to True now.
Following contributors contributed to this release:
* ArrayMy
* Ken Dreyer
* Neal Gompa
* Neil Horman
* Sam Fowler
* Todd Zullinger
Thank you.

52
docs/Release-Notes-1.4.13.md Normal file
View file

@ -0,0 +1,52 @@
---
layout: default
title: Release Notes 1.4.13
---
Released on 2018-08-13.
## Features:
- Starting with mock-core-configs version 29.1 the gpg keys for rawhide are checked now.
- There is a new config option `print_main_output`, which allows you to override default behavior:
```
# By default, mock only prints the build log to stderr if it is a tty; you can
# force it on here (for CI builds where there is no tty, for example) by
# setting this to True, or force it off by setting it to False.
# config_opts['print_main_output'] = None
```
- Following new environment variables are passed to mock from user environment: `http_proxy`, `ftp_proxy`, `https_proxy`, `no_proxy`.
- bash completion has been reworked and is now much simple and hopefully better
- There are new configs for Fedora 30.
## Bugfixes:
- Mockchain will again stop after the first failure if -c or --recurse is not used.
- Commands started by mock will be using `C.UTF-8` locale instead of `en_US.UTF-8`, which does not need to be available.
- There is new default for `nspawn_args`: `config_opts['nspawn_args'] = ['--capability=cap_ipc_lock']`. This will enable cap_ipc_lock in nspawn container, which will allow to use `mlock()` [RHBZ#1580435](https://bugzilla.redhat.com/show_bug.cgi?id=1580435).
- Do not get spec from the command line when using scm [GH#203](https://github.com/rpm-software-management/mock/issues/203)
- use host's resolv.conf when --enable-network is set on cml [RHBZ#1593212](https://bugzilla.redhat.com/show_bug.cgi?id=1593212)
Following contributors contributed to this release:
* Bruno Vernay
* Chuck Wilson
* Jaroslav Škarvada
* Neal Gompa
* Owen W. Taylor
* Seth Wright
* Todd Zullinger
* Tomasz Torcz
Thank you.
Note: version 1.4.12 has been skipped due error discovered during releasing.

79
docs/Release-Notes-1.4.14.md Normal file
View file

@ -0,0 +1,79 @@
---
layout: default
title: Release Notes 1.4.14
---
Released on 2019-02-19.
Release together with `mock-core-configs-30.1` which has these changes:
- Added repositories for Fedora 30 (and Fedora 31 repos now points to rawhide).
- distribution-gpg-keys for rhel8beta is being installed directly from Koji, because EPEL8 does not exist yet.
- Fedora 27 config has been moved to `eol` directory.
- `gpgcheck` is enabled for testing and debuginfo now.
- Fedoras 29+ have included modular repos now. Additionally, there is now `module_platform_id` defined in these configs, which allows you to install modules without errors.
## Mock new features:
- All mock configs are parsed and evaluated by [Jinja2](http://jinja.pocoo.org/). Here is small example how it can be used:
```
# define your own config variable
config_opts['fedora_number'] = '30'
config_opts['root'] = 'fedora-{{ fedora_number }}-x86_64'
config_opts['dist'] = 'fc{{ fedora_number }}'
```
Another - more general - example from `site-defaults.cfg`:
```
# You can use jinja templates, e.g.:
# config_opts['foobar'] = '{{ foo }} bar'
# which will result in 'bar bar' (using value defined few lines above)
# more complicated example:
# config_opts['foo'] = "{{ plugin_conf['package_state_enable'] }}"
# which will result in "True"
```
This feature can simplify mock's configs in the future. I intentionally did not use it now, because it is too fresh. Please experiment with this feature on your own and report any error or issues. If there would be none, then I will start using it in main configs.
- Use 32-bit personality for armv7*/armv8* builds.
- You can now specify decompress program for root_cache. This is new default in `site-defaults.cfg` [GH#230](https://github.com/rpm-software-management/mock/issues/230):
```
## decompress_program is needed only for bsdtar, otherwise `compress_program` with `-d` is used
## for bsdtar use "unpigz" or "gunzip"
# config_opts['plugin_conf']['root_cache_opts']['decompress_program'] = "pigz"
```
## Bugfixes:
- Added Scientific Linux on the list of RHEL clones [GH#228](https://github.com/rpm-software-management/mock/issues/228)
- Fixed exclude pattern for BSDTar [GH#219](https://github.com/rpm-software-management/mock/issues/219)
- There used to be living part of `site-defaults.cfg`:
```
config_opts['bootstrap_chroot_additional_packages'] = []
config_opts['bootstrap_module_enable'] = []
config_opts['bootstrap_module_install'] = []
```
This is now commented out by default, and the defaults are set in mock code. You can still override it in `site-defaults.cfg`.
Following contributors contributed to this release:
* Bernhard Rosenkränzer
* František Zatloukal
* Pavel Raiskup
* Petr Junák
* Sam Fowler
Thank you.

50
docs/Release-Notes-1.4.15.md Normal file
View file

@ -0,0 +1,50 @@
---
layout: default
title: Release-Notes 1.4.15
---
Released on 2019-04-22.
## Mock new features:
- Mock supports [Dynamic Build Requires](https://fedoraproject.org/wiki/Changes/DynamicBuildRequires). There is still ongoing work in `rpmbuild`; therefore you cannot use it yet. Once the new rpmbuild lands in Fedora you can immediately use it with Mock. [[GH#245](https://github.com/rpm-software-management/mock/issues/245)]
- I have seen people who do not know about [setup](https://rpm-software-management.github.io/mock/#setup). Now, when you are not in the `mock` group, and Mock asks you via `consolehelper` for root password, it prints this banner: `You are not in the `mock` group. See https://github.com/rpm-software-management/mock/wiki#setup` [[GH#244](https://github.com/rpm-software-management/mock/issues/228)]
- Previously when Mock executed DNF, then Mock disabled DNF plugin `local`. Now the list of plugins which will be disabled can be configured via:
```
config_opts['dnf_disable_plugins'] = ['local', 'spacewalk']
```
The above is the new default, i.e., the plugin `spacewalk` is now disabled as well. [[GH#210](https://github.com/rpm-software-management/mock/issues/210)]
This change simplified `dnf_common_opts` default, which is now:
```
config_opts['dnf_common_opts'] = ['--setopt=deltarpm=False']
```
## Bugfixes:
- In Flatpak, the method `distro.version()` returns float, which produced fatal error in Mock. This is now fixed [[RHBZ#1690374](https://bugzilla.redhat.com/show_bug.cgi?id=1690374)]
- new rpm library now returns strings instead of bytes. Mock has been altered that it can accept both types [[RHBZ#1693759](https://bugzilla.redhat.com/show_bug.cgi?id=1693759)]
- Mock used FileNotFoundError class for a error handling. This class is not defined in Python 2 and caused a traceback during an error handling [[RHBZ#1696234](https://bugzilla.redhat.com/show_bug.cgi?id=1696234)]
## Known issues:
- On Fedora 30+, the createrepo_c prints its output to STDERR, which is fatal to mockchain. For the time being, I changed the mockchain behavior and creterepo_c errors are not fatal. However, mockchain print them as an error even there is no error at all. [GH#249](https://github.com/rpm-software-management/mock/issues/249)
Following contributors contributed to this release:
* Igor Gnatenko
* Jeroen van Meeuwen (Kolab Systems)
* Jo Shields
* Martin Kutlák
* Neal Gompa
* Pat Riehecky
* Toshio Kuratomi
Thank you.

20
docs/Release-Notes-1.4.16.md Normal file
View file

@ -0,0 +1,20 @@
---
layout: default
title: Release Notes 1.4.16
---
Released on 2019-05-22.
## Mock new features and bugfixes:
- switch to python3 on el7
- respect use_host_resolv config even with use_nspawn (praiskup@redhat.com)
- Fix crash on non-ascii dnf log messages (bkorren@redhat.com)
Following contributors contributed to this release:
* Barak Korren
* Miro Hrončok
* Pavel Raiskup
Thank you.

72
docs/Release-Notes-1.4.17.md Normal file
View file

@ -0,0 +1,72 @@
---
layout: default
title: Release Notes 1.4.17
---
Released on 2019-08-08.
## Mock-core-configs new features:
* Added updates-modular to Fedora 29 and Fedora 30, but with `enabled=0` for now due
[bug in DNF](https://bugzilla.redhat.com/show_bug.cgi?id=1737469).
* Removed info about metadata expire.
* Replace groupadd using sysusers.d.
* epel-7 profiles to use mirrorlists.
* EOLed Fedora 28.
* Do not protect packages in chroot [[GH#286]](https://github.com/rpm-software-management/mock/pull/286).
* Fix value for dist for OpenMandriva 4.0 configs.
* Add initial OpenMandriva distribution targets.
## Mock new features and bugfixes:
* Mockchain has been replaced by `mock --chain`. This new command inherited most
mockchain command-line options. The [return codes](https://github.com/rpm-software-management/mock/blob/master/mock/py/mockbuild/exception.py#L26) are little different.
This has been done to remove duality - mockchain parsed configs differently than mock.
Now, the behavior should be unified. Mockchain has been marked obsolete - it even prints warning
when you execute, and you are encouraged to migrate to `mock --chain`. I will try to preserve `mockchain` for next
12 months, but mockchain will not be receiving any new functionality.
* Mock is now able to run in [Fedora Toolbox](https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/).
* Added support for [Cheat](https://github.com/cheat/cheat) - try running `cheat mock`.
* There is a new tool `mock-parse-buildlog --path FILE` which tries to parse build.log file and give you nice
human friendly description, why the build failed. Right now, it support just two use cases. Feel free to
send pull request to enhance it.
* Secondary groups are now loaded [[RHBZ#1264005]](https://bugzilla.redhat.com/show_bug.cgi?id=1264005).
* When installing dependencies, Mock pass --allowerasing to DNF now. [[GH#251]](https://github.com/rpm-software-management/mock/pull/251).
* make include() functional for --chain [[GH#263]](https://github.com/rpm-software-management/mock/pull/263).
* Removing BUILDSTDERR from log - it is now configurable via `config_opts['_mock_stderr_line_prefix`]', which is by default empty string.
* Use rpm -qa --root instead of running rpm -qa in chroot.
* Run more that one loop for DynamicBuildrequires if it is neeed.
* Number of loop devices is now configurable using `config_opts['dev_loop_count'] = 12` and the new default has been raised from 4 to 12. This change only affects `--old-chroot`. We are working on making it functional in nspawn chroot as well.
* Return back to call binaries using /bin for split-usr setups.
* Repeat [dynamic requires](https://fedoraproject.org/wiki/Changes/DynamicBuildRequires) loop if needed [[GH#276]](https://github.com/rpm-software-management/mock/pull/276)
* Fix compatibility with pre-4.15 RPM versions with DynamicBuildRequires.
* Enable [Dynamic BuildRequires](https://fedoraproject.org/wiki/Changes/DynamicBuildRequires) by default.
* Independent network configuration [[GH269]](https://github.com/rpm-software-management/mock/pull/269)
* Now, when you execute `mock -r FOO`, mock will check if `~/.config/mock/FOO.cfg` exists and use this config. If it does not exists, it will use the `/etc/mock/FOO.cfg`. This is useful if you want to localy override default configs.
* respect use_host_resolv config even with use_nspawn.
* Fix crash on non-ascii dnf log messages.
* switch to python3 on el7 (msuchy@redhat.com)
## Future
Note that in upcoming versions, I would like to:
* drop python2 support as even EL7 version is running on python3 now.
* drop EL7 support (likely spring 2020). I mean to stop building Mock for EL7. Building packages for EL7 using Mock will be still supported.
* make DNF default package manager. E.g., you will have to state in config that you want to use yum explicitly.
* Pavel Raiskup is preparing support for building for RHEL 8 targets. So besides traditional CentOS targets, you will be able to build for RHEL, if you have Red Hat subscription. This will allows you to not wait for CentOS release when RHEL has already been released.
Following contributors contributed to this release:
* Barak Korren
* Bernhard Rosenkränzer
* Igor Gnatenko
* khoitd1997
* Martin Necas
* Miro Hrončok
* Neal Gompa
* Owen W. Taylor
* Pavel Raiskup
* Silvie Chlupova
Thank you.

41
docs/Release-Notes-1.4.18.md Normal file
View file

@ -0,0 +1,41 @@
---
layout: default
title: Release Notes 1.4.18
---
Released on 2019-08-27.
## Mock-core-configs new features:
* New configs for RHEL. See [separate page](Feature-rhelchroots) for more info.
* Fedora 31 has been added
* Add local-source repo definition to Fedora Rawhide.
* revert sysusers setting [RHBZ#1740545](https://bugzilla.redhat.com/show_bug.cgi?id=1737469)
## Mock new features and bugfixes:
* When a foreign architect is detected, Mock will automatically enable `--forcearch`.
* Support for subscription-manager has been added. See [RHEL chroots](Feature-rhelchroots) page.
* bootstrap-chroot always explicitly install shadow-utils
* Add [procenv plugin](Plugin-ProcEnv.md) for more detailed build time information. This plugin is disabled by default.
* Resolved issues with SELinux from the previous release. You may still experience some warnings, but none of them should be fatal.
* SIGTERM, SIGPIPE, and SIGHUP signals are now propagated to chroot.
## Future
Note that in upcoming versions, I would like to:
* drop python2 support as even EL7 version is running on python3 now.
* drop EL7 support (likely spring 2020). I mean to stop building Mock for EL7. Building packages for EL7 using Mock will be still supported.
* make DNF default package manager. E.g., you will have to state in the config that you want to use yum explicitly.
Following contributors contributed to this release:
* Dominik Turecek
* Jan Buchmaier
* Jiri Konecny
* Miro Hrončok
* Pat Riehecky
* Pavel Raiskup
Thank you.

17
docs/Release-Notes-1.4.19.md Normal file
View file

@ -0,0 +1,17 @@
---
layout: default
title: Release Notes 1.4.19
---
Released on 2019-09-10.
## Mock bugfixes:
* Biggest reason for this release have been regression that results are owned by root user instead of unpriv user [[GH#322]](https://github.com/rpm-software-management/mock/issues/322)
* Previously resultdir variable in config has not been documented. This is now fixed.
Following contributors contributed to this release:
* Silvie Chlupová
Thank you.

28
docs/Release-Notes-1.4.2.md Normal file
View file

@ -0,0 +1,28 @@
---
layout: default
title: Release Notes 1.4.2
---
There are new features:
* The bootstrap feature is now disabled by default. There were too many issues with it. You can enable it locally with `--bootstrap-chroot`, but first see knows [bugs](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&component=mock&known_name=mock-all&list_id=7491839&product=Fedora&product=Fedora%20EPEL&query_based_on=mock-all&query_format=advanced) and [issues](https://github.com/rpm-software-management/mock/issues).
* There is initial support for Fedora Modularity. You can add to config:
```
config_opts['module_enable'] = ['list', 'of', 'modules']
config_opts['module_install'] = ['module1/profile', 'module2/profile']
```
This will call `dnf module enable list of modules` and `dnf module install module1/profile module2/profile` during the init phase. EDIT: If you want to use this feature you have to have experimental DNF, it can be obtained from this [Copr project](https://copr.fedorainfracloud.org/coprs/mhatina/DNF-Modules/).
There are some bugfixes:
* NSpawn chroot is switched off for EL6 targets [[RHBZ#1456421](https://bugzilla.redhat.com/show_bug.cgi?id=1456421)].
* LVM root is not umounted when `umount_root` is set to false [[RHBZ#1447658](https://bugzilla.redhat.com/show_bug.cgi?id=1447658)]
* Shell in NSpawn container is now called with `--login` so `profile.d` scripts are executed [[RHBZ#1450516](https://bugzilla.redhat.com/show_bug.cgi?id=1450516)] [[RHBZ#1462373](https://bugzilla.redhat.com/show_bug.cgi?id=1462373)]
* yum rather then yum-deprecated is used when using bootstrap chroot [[RHBZ#1446294](https://bugzilla.redhat.com/show_bug.cgi?id=1446294)]
* Custom chroot does not use bootstrap [[RHBZ#1448321](https://bugzilla.redhat.com/show_bug.cgi?id=1448321)]
* Mock now use `dnf repoquery` instead of repoquery for chroots which uses DNF.
* LVM's scrub hook for bootstrap chroot is called [[RHBZ#1446297](https://bugzilla.redhat.com/show_bug.cgi?id=1446297)]
* `--mount` will mount LVM volumes [[RHBZ#1448017](https://bugzilla.redhat.com/show_bug.cgi?id=1448017)]

90
docs/Release-Notes-1.4.20.md Normal file
View file

@ -0,0 +1,90 @@
---
layout: default
title: Release Notes 1.4.20
---
Released on 2019-10-04.
## Mock new features:
### Container image for bootstrap
Previously we have some incompatibilities between host and build target. They were, in fact, small. Like using a different package manager. Some were big. Like, the introduction of Weak and Rich dependencies. For this reason, we introduced [bootstrap](Feature-bootstrap). But then comes [zstd payload](https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression). This is a new type of payload. And to install packages with this payload, you need rpm binary, which supports this payload. This is true for all current Fedoras. Unfortunately, neither RHEL 8 nor RHEL 7 supports this payload. So even bootstrap will not help you to build Fedora packages on RHEL 8.
We come up with a nice feature. Mock will not install bootstrap chroot itself. Instead, it will download the container image, extract the image, and use this extracted directory as a bootstrap chroot. And from this bootstrapped chroot install the final one.
Using this feature, **any** incompatible feature in either RPM or DNF can be used in the target chroot. Now or in future. And you will be able to install the final chroot. You do not even need to have RPM on a host. So this should work on any system. Even Debian based. The only requirement for this feature is [Podman](https://podman.io/).
This feature is now disabled by default. You can enable it using:
config_opts['use_bootstrap_image'] = True
It can be enabled or disabled on the command line using `--use-bootstrap-image` or `--no-bootstrap-image` options.
Note however that also this is prerequisite:
config_opts['use_bootstrap_container'] = True # or --bootstrap-chroot option
To specify which image should be used for bootstrap container you can put in config:
config_opts['bootstrap_image'] = 'fedora:latest'
This is a general config. Each config has specified its own image specified. E.g. CentOS 7 has `config_opts['bootstrap_image'] = 'centos:7'` in config. So unless you use your own config, you can enable this feature, and the right image will be used.
There is one known issue:
* Neither Mageia 6 nor 7 works correctly now with this feature.
Technically, you can use any container, as long as there is the required package manager (DNF or YUM). The rest of the needed packages will be installed by mock.
### Mockchain removed
Mockchain has been removed. I wanted to keep it longer, but because of [[RHBZ#1757388](https://bugzilla.redhat.com/show_bug.cgi?id=1757388)] I decided to remove it now. You should use `mock --chain` instead of `mockchain`. There is present simple wrapper `/usr/bin/mockchain` which calls `mock --chain`. Most of the mockchain parameters are still preserved for `mock --chain`.
### New config option `package_manager_max_attempts`
When your infrastructure is not reliable and you see failing builds because of network issues, you can increase number of attemps to execute package manager's action. This can be now tuned using:
config_opts['package_manager_max_attempts'] = 1
config_opts['package_manager_attempt_delay'] = 10
### Bind mount local repos to bootstrap chroot
Previously when you have in your config something like:
config_opts['yum.conf'] = """
...
[myrepo]
baseurl=file:///srv/myrepo
then the path `/srv/myrepo` was not available inside of bootstrap container. The package manager was then unable to fetch those repositories.
This is now fixed and those directories are now automatically bind-mounted to bootstrap chroot.
This was actually the last known issue with bootstrap chroots. You may expect that in a future version of Mock, the bootstrap chroot will be enabled by default.
## Mock-core-config bugfixes
* Fix baseurl typo in centos-stream config
* Disabled modular repo for f29 - this was accidentally enabled during transition to templates.
## Mock bugfixes
* Several files - mainly logs - are created as unprivileged user now. This will fix several issues when you use NFS. [[#341](https://github.com/rpm-software-management/mock/issues/341)], [[#322](https://github.com/rpm-software-management/mock/issues/322)], [[RHBZ#1751944](https://bugzilla.redhat.com/show_bug.cgi?id=1751944)]
* `/var/log` is now ignored when creating root cache.
* `mock --chain` now creates local repositories using `skip_if_unavailable=0`
Following contributors contributed to this release:
* Daniel Mach
* Denis Ollier
* Chuanhao jin
* Jakub Kadlcik
* Jiri 'Ghormoon' Novak
* Pavel Raiskup
* Silvie Chlupova
Thank you.

31
docs/Release-Notes-1.4.21.md Normal file
View file

@ -0,0 +1,31 @@
---
layout: default
title: Release Notes 1.4.21
---
Released on 2019-11-01.
## Mock-core-configs 31.7
* Added configs for epel8-playground
* Added 3 base packages to epel-playground and epel buildroot [RHBZ#1764445](https://bugzilla.redhat.com/show_bug.cgi?id=1764445)
## Mock 1.4.21 bugfixes:
This is a bugfix-only release. There is already ongoing work on 1.5.0 version. I cherry-picked some commits, which resolves some painfull bugs:
There were some issue with initialization of "Container image for bootstrap" feature. [GH#380](https://github.com/rpm-software-management/mock/issues/380). This is now fixed. As side effect there are two changes. Download of container image has been moved from `root_cache` plugin to main Mock code. As result you do not need to have root cache enabled to use this feature. Second, distribution-gpg-keys are always copied to bootstrap chroot if you use bootstrap container feature.
Commands `--install` and `--installdeps` now works with bootstrap [RHBZ#1447627](https://bugzilla.redhat.com/show_bug.cgi?id=1447627)
There was an ugly bug, which involved systemd, CGroups v2 and SELinux and can lead to complete freeze of a system. This has been now resolved. [RHBZ#1756972](https://bugzilla.redhat.com/show_bug.cgi?id=1756972)
Rarely you may hit bug with incorrect rpmbuildstate. This is now fixed. [GH#349](https://github.com/rpm-software-management/mock/issues/349).
Following contributors contributed to this release:
* Jakub Kadlcik
* Merlin Mathesius
* Pavel Raiskup
Thank you.

24
docs/Release-Notes-1.4.3.md Normal file
View file

@ -0,0 +1,24 @@
---
layout: default
title: Release Notes 1.4.3
---
This is bug fix release, we fixed following issues:
* `--nocheck` macro was not properly escaped [[RHBZ#1473359](https://bugzilla.redhat.com/show_bug.cgi?id=1473359)].
* Use python3 and dnf module on Fedoras to guess architecture in `%post` scriptlet [[RHBZ#1462310](https://bugzilla.redhat.com/show_bug.cgi?id=1462310)].
* enhanced detection of RHEL [[RHBZ#1470189](https://bugzilla.redhat.com/show_bug.cgi?id=1470189)].
* scm: define `_sourcedir` to checkout directory [[PR#98](https://github.com/rpm-software-management/mock/pull/98)].
* Mageia Cauldron `releasever` is now 7 [[PR#95](https://github.com/rpm-software-management/mock/pull/95)]
* Create `/dev` nodes even when using `nspawn` [[RHBZ#1467299](https://bugzilla.redhat.com/show_bug.cgi?id=1467299)].
* SELinux: do not try to import yum when PM is dnf [[RHBZ#1474513](https://bugzilla.redhat.com/show_bug.cgi?id=1474513)].
* When you have hundreds of volumes in LVM you can tell mock to wait longer using `config_opts['plugin_conf']['lvm_root_opts']['sleep_time'] = 1`.
Thanks to following contributors:
* Igor Gnatenko
* Jonathan Lebon
* Mikolaj Izdebski
* Neal Gompa
* Ville Skyttä
* pixdrift

11
docs/Release-Notes-1.4.4.md Normal file
View file

@ -0,0 +1,11 @@
---
layout: default
title: Release Notes 1.4.4
---
This is bug fix release, we fixed following issues:
* Fedora 27 configs have been added.
* /etc/dnf/dnf.conf is used instead of /etc/dnf.conf
* /etc/dnf/dnf.conf is populated even when yum is used
* Rename group inside of chroot from mockbuild to mock - this will allow you to install mock inside of mock' chroot. Please invalidate your previous caches.

33
docs/Release-Notes-1.4.6.md Normal file
View file

@ -0,0 +1,33 @@
---
layout: default
title: Release Notes 1.4.6
---
Released on 2017-09-15.
This is mostly a bugfix release, but there are some features too:
Features:
* All chroot configs have been moved to new package mock-base-configs. This will allow us to release new chroot configs independently of Mock main code.
* There is a new command --debug-config available. This command print current mock config (including defaults) to standard output and exit. This can be useful when you experience some issue, which you cannot reproduce anywhere else.
* There is a new script, which can add a default route to loopback for a container with private-network. This is an experimental feature, not used automatically, and will very likely change in future.
* There is short option `-N` for `--no-cleanup-after`.
Bugfixes:
* Mock again create /dev/loop nodes. This caused a lot of pain to Lorax users. [RHBZ#1481370](https://bugzilla.redhat.com/show_bug.cgi?id=1481370)
* Comment about nspawn/chroot default in site-defaults.cfg was previously incorrect, this has been fixed now.
* Previously when you used --private-network then the isolated network was used only during rpm build phase. And, e.g., for shell command, it was not used. This caused some confusion. Now the network is always switched when you specify --private-network.
* The bug "The buildroot LVM volume is not kept mounted after build" [RHBZ#1447658](https://bugzilla.redhat.com/show_bug.cgi?id=1447658) has been fixed once again. Hopefully this time correctly.
Following contributors contributed to this release:
* Brian C. Lane
* Jan Synacek
* Matej Kudera
* Michael Simacek
* Ville Skyttä
P.S. I did not skip 1.4.5. I just find a serious bug in requirement just after the release. So I made two releases in one day. :) This is united release notes.

38
docs/Release-Notes-1.4.7.md Normal file
View file

@ -0,0 +1,38 @@
---
layout: default
title: Release Notes 1.4.7
---
Released on 2017-10-31.
Features:
* There is a new option in config `config_opts['chrootgroup']`, which allows you to change name of group inside of chroot.
* Any key for `config_opts` you specify with 'bootstrap_*' will be copied to bootstrap config e.g., `config_opts['bootstrap_system_yum_command'] = '/usr/bin/yum-deprecated'` will become `config_opts['system_yum_command'] = '/usr/bin/yum-deprecated'` for bootstrap config.
* There are three new default:
```
config_opts['bootstrap_chroot_additional_packages'] = []
config_opts['bootstrap_module_enable'] = []
config_opts['bootstrap_module_install'] = []
```
This will not install any additional packages or modules into bootstrap chroot.
* Mock now recognize DeskOS.
* Previously when `config_opts['rpmbuild_networking']` was enabled we passed `--private-network` to systemd-nspawn. However that lead there was no default route. And you cannot bind() UDP socket to all IP addresses and then join multicast group, without having default route. Now we do onot add `--private-network` to systemd-nspawn, instead we setup network namespace ourselves and we also add default route pointing to loopback interface (only interface in the new namespace). This feature introduce new dependency on pyroute2.
Bugfixes:
* Delete rootdir as well when calling clean. In case one overrides the rootdir option, and the rootdir is located outside of basedir, it was not cleaned up when calling --clean. Fix this case by checking if the rootdir is outside basedir. If that is the case, run an extra rmtree() on it.
* Choose good symbolic link of default.cfg on Mageia.
* Ccache is now mounted to /var/tmp as /tmp gets over-mounted with tmpfs when system-nspawn is used.
* Output of `--debug-config` is now sorted.
* Use primary key for Fedora 27+ on s390x.
Following contributors contributed to this release:
* Andreas Thienemann
* Dan Horák
* Jan Pokorný
* Mark D Horn
* Michal Sekletar
* Neal Gompa
* Ricardo Arguello

77
docs/Release-Notes-1.4.8.md Normal file
View file

@ -0,0 +1,77 @@
---
layout: default
title: Release Notes 1.4.8
---
Released on 2017-12-22.
Features:
* There is a new option --config-opts [GH#138](https://github.com/rpm-software-management/mock/issues/138)
You can run:
```
mock --config-opts yum_command=/usr/bin/yum-deprecated --enable-network
```
which will set:
```
config_opts['system_yum_command'] = '/usr/bin/yum'
```
or for a list:
```
mock --config-opts extra_chroot_dirs=/mnt/b --config-opts extra_chroot_dirs=/mnt/a
```
which will set
```
config_opts['extra_chroot_dirs'] = ['/mnt/b', '/mnt/a']
```
or list with a single item:
```
mock --config-opts extra_chroot_dirs=/mnt/b --config-opts extra_chroot_dirs=
```
which will set
```
config_opts['extra_chroot_dirs'] = ['/mnt/b']
```
It can detect boolean:
```
mock --config-opts nosync=False --debug-config |grep nosync
config_opts['nosync'] = False
```
A specialized option has priority. Therefore:
```
mock --config-opts rpmbuild_networking=False --enable-network --debug-config |grep rpmbuild_networking
config_opts['rpmbuild_networking'] = True
```
It is unable to set complicated variables. Like config_opts['plugin_conf']['package_state_opts'] or anything which has dictionary as value.
* There is a new option. `--enable-network` which is equivalent to `config_opts['rpmbuild_networking'] = True`
Bugfixes:
* orphanskill now emits SIGKILL when SIGTERM is not enough [RHBZ#1495214](https://bugzilla.redhat.com/show_bug.cgi?id=1495214)
* when mock tries to force umount, it will try umount recursively
* do not change to directory if nspawn is used [GH#108](https://github.com/rpm-software-management/mock/issues/108)
* when creating yum/dnf.conf, mock now copy timestamp from the host [RHBZ#1293910](https://bugzilla.redhat.com/show_bug.cgi?id=1293910)
* We now mount /proc and /sys in chroot before executing any package manager command (outside of chroot)[RHBZ#1467299](https://bugzilla.redhat.com/show_bug.cgi?id=1467299)
* Dependencies of mock-scm (git, cvs, tar, subversion) are now soft dependencies (Recommends) [RHBZ#1515989](https://bugzilla.redhat.com/show_bug.cgi?id=1515989)
* Previously job control in `mock shell` does not work. [RHBZ#1468837](https://bugzilla.redhat.com/show_bug.cgi?id=1468837). This was a glibc bug and it is resolved in rawhide now.
Following contributors contributed to this release:
* Matt Wheeler
* Matthew Stoltenberg

50
docs/Release-Notes-1.4.9.md Normal file
View file

@ -0,0 +1,50 @@
---
layout: default
title: Release Notes 1.4.9
---
Released on 2018-02-12.
Note:
In this release, there are several fixes to bootstrap feature. This is especially important for users who run Mock on EL7. Rich dependencies are now allowed in Fedora and maintainers are starting to use them. So sooner or later, you will be unable to build packages for Fedoras on EL7 host. Unless you start using bootstrap feature (`--bootstrap-chroot`), which is still by default off.
Features:
* Stdout and stderr in build.log has been split. All stderr output lines are prefixed by `BUILDSTDERR:`
* There is a new config option `opstimeout`:
```
# Set timeout in seconds for common mock operations
# if 0 is set, then no time limit is used
# config_opts['opstimeout'] = 0
```
The default is 0, which means that Mock is waiting until command exit.
Bugfixes:
* Builds for EL5 are working again - EL5 is sensitive to order of params of adduser [RHBZ#1535328](https://bugzilla.redhat.com/show_bug.cgi?id=1535328)
* Use correct builddep when bootstrap is used. Additionally, ccache is not installed into bootstrap chroot. [RHBZ#1540813](https://bugzilla.redhat.com/show_bug.cgi?id=1540813).
* User defined mounts are not mounted in bootstrap chroot.
* Detect if essential mounts are already mounted - previously, mock assumed that essential mounts (procfs, sysfs) are never mounted when mock starts up. That's not true, as multiple non-destructive mock processes are allowed (`--shell`, `--install`, etc.) to run concurrently. So when you use `mock --shell` and do a `mock --install` in parallel, it breaks your shell, because it unmounts its proc. This improves the situation by first asking whether the mounts aren't there already.
* fix quoting in sign_opts example in site-defaults.cfg [RHBZ#1537797](https://bugzilla.redhat.com/show_bug.cgi?id=1537797).
* Honor the "cwd" flag when nspawn is being used and "chrootPath" is not set.
* Do not produce a warning when we are using different PM for a bootstrap container.
* Default for config_opts['dnf_warning'] in site-defaults.cfg according to docs.
Additionally, there are several major changes in mock-core-config. This package is independent now, and a new version has been released two weeks ago and will be pushed to Fedora stable next week. I will repeat here changes in that package:
* Fedora 28 configs has been added.
* `failovermethod=priority` has been removed for repos which use DNF. This is the only method which DNF recognize and it cannot be changed.
* Set `skip_if_unavailable=False` for all repos. If a repository is unreachable, then build fails.
Following contributors contributed to this release:
* Barak Korren
* Michael Simacek
* Mikhail Campos Guadamuz
* mprahl
* Pavel Raiskup
* Todd Zullinger
Thank you.

150
docs/Release-Notes-2.0.md Normal file
View file

@ -0,0 +1,150 @@
---
layout: default
title: Release Notes 2.0
---
Released on 2020-02-07.
## Mock 2.0 highlights:
* The mock versioning policy (or rather style) has changed from three to
two-number pattern. Don't panic, this isn't really special major
release - the change was only done to move from the
`<UNUSED>.<MAJOR>.<MINOR>` pattern to `<MAJOR>.<MINOR>`, so practically
we went with *v2.0* instead of previously planned *v1.5.0*.
* The `--bootstrap-chroot` option is newly enabled by default, this can be
disabled by `--no-bootstrap-chroot`, or by
`config_opts['use_bootstrap'] = False`. The content of bootstrap chroot
is cached by default and never automatically updated, but one
can use the new `--scrub=bootstrap` to remove related caches. The
`--scrub=all` was updated to clean bootstrap as well (but `--clean`
doesn't touch bootstrap chroot at all).
* The `use_bootstrap_container` configuration option was renamed to
`use_bootstrap` to better describe it's purpose (it never implied usage
of container technology) and to align with `use_bootstrap_image`
option. Please migrate your custom configuration.
* The output from `--debug-config` option now only shows the differences
from mock's defaults, and the output doesn't have the Jinja templates
expanded.
* The `config_opts['dnf.conf']` replaced `config_opts['yum.conf']`. Both
still work, but only one of them can exist one config file.
* The `--old-chroot` and `--new-chroot` options were obsoleted by
`--isolation=chroot|nspawn`, and still default to `--isolation=nspawn`.
Please migrate your tooling.
* Mock now can now pre-configure DNF variables ([#346](../issues/346)), e.g.
`config_opts['dnf_vars'] = { 'stream': '8-stream' }`
* The regression in `--use-bootstrap-image` implementation was fixed (did
not work at all in `v1.4.21`), and should work reliably now (`podman`
still needs to be installed manually to make it work).
* In mock config files we now prefer Jinja templates, instead of
previously used python expansion `"%(variable)" % ..`. It is not
likely, but if you use this in your custom config files, please
migrate.
## Mock 2.0 other fixes and enhancements:
* Loop device files are pre-populated even in `--isolation=nspawn`
chroots, similarly to what is done with `--isolation=chroot`
([#298](../issues/298)).
* The `include()` statement in mock config now also accepts relative path
names (relative against `config_opts['config_path']` for now).
* The host local repositories from mock config files
(like `baseurl=file://`) are now correctly bind-mounted to bootstrap
chroot. So installing RPM from such repositories with
`--bootstrap-chroot` now works (related [#381](../issues/381)).
* Non-interactive commands in chroot are executed through
`systemd-nspawn --console=pipe` (when `--isolation=nspawn`, default)
([#432](../issues/432)).
* Better detection of host's package manager (DNF vs. YUM), for both
bootstrap and normal chroot. This should demotivate people from using
`--dnf` and `--yum` options ([#233](../issues/233)). More, on Fedora 31+ there's no
real YUM package manager anymore (there only is `yum.rpm` which actually
provides `/bin/yum` symlink to `/bin/dnf`). This situation is now
properly detected in mock, and the symlink is ignored (we fallback to
DNF).
* Better re-using of DNF/YUM caches, in both normal and bootstrap chroot.
This is mostly given by previous bullet (YUM vs. DNF detection). To be
100% sure, we also newly rather bind-mount both DNF and DNF cache
directories into the chroot.
* Mock expands the config templates (aka `include()`) completely before
executing it by eval(), and the implementation is now much simpler and
clear.
* Mock doesn't ignore `cleanup_on_success` configuration option after
`--postinstall` action.
* `mock --chain` file descriptor leak was fixed, so the descriptor usage
is constant with multiple builds.
* The Jinja templating is now iteratively re-rendered (when Jinja template
expands to another Jinja template), till there is something to expand. Also
we start the Jinja rendering mechanism a bit earlier in the codebase so the
mock configuration isn't really order-dependant (no matter which
configuration option is set first).
* Fix lvm plugin volume removal feature on modern systems
([rhbz#1762728](https://bugzilla.redhat.com/1762728)).
* We don't install `shadow-utils` (we don't need this one) and
`distribution-gpg-keys` (we copy the keys from host instead), so this
makes the initial `dnf_install_command` transaction shorter, and more
reliable across all the variety distributions we support.
* The `--sources` parameter is not mandatory in `--buildsrpm` mode.
* Mock now copies `/etc/pkg/ca-trust/extracted` into chroot
([#397](../issues/397)).
* The `success` and `fail` files are created under mockbuild user, not root.
* The `compress_logs`, when turned on, have predefined default `gzip` method.
* We turned `--forcearch` on long time ago, but mock exited with cryptic
error when `qemu-user-static` wasn't installed. Mock now detects that
`qemu-user-static` is missing and throws instructions instead.
## Mock-core-configs 32.0
* Added configs for **Fedora 32**, Fedora Rawhide configs moved to F33. The new
package depends on updated **distribution-gpg-keys 1.36** package (avaiable
in Fedora updates at the time of release).
* Fedora 29 configs EOLed (moved below `eol` subdirectory).
* All the configuration files were modified to use templates, to de-duplicate
a lot of stuff and many inconsistencies were fixed.
* On el7, mock/mock-core-configs automatically enable `use_bootstrap_image`
option for **Fedora 31+** chroots (ZSTD compression enabled for RPMs) because without
this option it wouldn't make sense to do anything (neither bootstrap chroot
is installable).
Both mock and mock-core-configs packages need to be updated together as pair.
Following contributors contributed to this release:
* Dominik Tureček
* Jakub Čajka
* Jakub Kadlčík
* Merlin Mathesius
* Scott K Logan
* Sérgio M. Basto
* Silvie Chlupová
* Tomas Hrnciar
Thank you.

65
docs/Release-Notes-2.1.md Normal file
View file

@ -0,0 +1,65 @@
---
layout: default
title: Release Notes 2.1
---
Released on 2020-03-11.
## Mock 2.1 bugfixes:
* Fixed `mock --install <sth>` request when `<sth>` is a file or directory
in CWD, or an absolute path on host (#474).
* We do not emit the warning `WARNING: Not using '/usr/bin/yum', it is symlink
to '/usr/bin/dnf-3'` anymore for installing bootstrap chroot (#477,
rhbz#1802930).
* The `config_opts['dnf.conf']` option is made equivalent to
`config_opts['yum.conf']` (#486).
* Allow specifying host-local repositories with `baseurl=/absolute/path`, not
only with `baseurl=file:///absolute/path`. This did not work with bootstrap
mode before (#480).
* Fixed broken sign plugin (#476, rhbz#1806577).
* Fixed too deep jinja recursion caused by trailing newlines in `dnf.conf`
config option (rhbz#1806482).
* The `mock --scrub` with lvm_root plugin enabled did not work (rhbz#1805179).
* Do not fail when host doesn't provide CA certificates on expected locations
(#492).
* Traceback fix for `mock --chain` with tmpfs `keep_mounted` enabled (#479).
* Dnf caches aren't cleaned for consecutive builds with `mock --chain` (#483).
## Mock 2.1 new features:
* Mock expects that `rpmbuild -br` (for %generate_buildrequires spec statement,
aka "dynamic BuildRequires") can return both exit status 0 and 11. Currently
released RPM always returns 11, but the plan is to fix that to return 0.
* New option `ssl_ca_bundle_path`. When specified, the CA certificate bundle
is copied from host to the specified path in chroot (usually it is enough to
keep the default behavior when whole `/etc/pki/ca-trust/extracted` is
copied, but e.g. OpenSUSE has different path to bundle) (#500).
## Mock-core-configs 32.4
* Specify CA bundle path for OpenSUSE chroots (#500).
* EOL Mageia 6 configs.
* Temporarily disable package_state plugin for openmandriva 4.0 and Cooker (#525).
Following contributors contributed to this release:
* Jakub Kadlcik
* Miroslav Suchý
* Remi Collet
* Tomas Hrnciar
Thank you.

49
docs/Release-Notes-2.10.md Normal file
View file

@ -0,0 +1,49 @@
---
layout: default
title: Release Notes 2.10
---
Released on - 2021-04-27.
## Mock 2.10 bugfixes:
* The `podman run` command which is used to pre-prepare the base mock bootstrap chroot
is now called just with `-i`, not with `-i -t`. That's because the new Podman
variants dislike `-t` when no tty is on the input.
* Fixed traceback for copying the Katello configs into the bootstrap chroot,
[PR 678][PR#678].
* Mount point handling was fixed; newly we use the correct and expected
mount-point options for recursive mounts (mostly needed for older util-linux
variants), and we correctly umount sub-set of already ḿounted mountpoints
upon some failure (traceback). [PR 712][PR#712]
## Mock-core-configs v34.3:
* Added Oracle Linux 7 and 8 configs.
* Add openSUSE Leap 15.3 configs.
* The openSUSE Leap 15.1 config was marked to EOL in configs.
* Add openSUSE Tumbleweed s390x config
* AlmaLinux 8 configs added
* The 'make' package was removed from the minimal ELN buildroot.
The following contributors contributed to this release:
* David Ward
* Miro Hrončok
* Miroslav Suchý
* Neal Gompa
Thank you!
[PR#712]: https://github.com/rpm-software-management/mock/pull/712
[PR#678]: https://github.com/rpm-software-management/mock/pull/678

59
docs/Release-Notes-2.11.md Normal file
View file

@ -0,0 +1,59 @@
---
layout: default
title: Release Notes 2.11
---
Released on - 2021-06-09
## Mock 2.11 features:
* You can use `--cwd` together with `--shell` now. [[PR 732][PR#732]]
* You can use `mock --install 'external:pypi:hwdata'` now. [[PR 733][PR#733]]
* Mock now defines macro `%{_platform_multiplier}` which is set to 1 by default. However, when [forcearch][forcearch] is used, then it is set to 10. [[PR 730][PR#730]]
This can be used to tune timeouts in e.g., `%check` and reflects that emulated platforms can take longer to finish task. Suggested use case can be:
```
%{!?_platform_multiplier:%global _platform_multiplier 1}
timeout $(( 60*%_platform_multiplier )) the-long-running-task
```
This will timeout after 60 seconds but on emulated platforms after 600 seconds.
If you have slow builder for some architecture, you can put in your config
```
config_opts['macros']['%_platform_multiplier'] = 5
```
to tune up this macro.
## Mock 2.11 bugfixes:
* Plug-in `compress_logs` now compresses log files even in case of DNF
repository failures [[PR 736][PR#736]].
* Broken "usage" section in `mock --help` output was fixed [[issue 738][#738]].
## Mock-core-configs v34.4:
* centos-stream-8 repositories use mirrorlist now. And have additional repositories which are presented in default centos-stream-8 installation [[PR 729][PR#729]]
The following contributors contributed to this release:
* Neal Gompa
* Miroslav Suchý
Thank you!
[PR#729]: https://github.com/rpm-software-management/mock/pull/729
[PR#730]: https://github.com/rpm-software-management/mock/pull/730
[PR#732]: https://github.com/rpm-software-management/mock/pull/732
[PR#733]: https://github.com/rpm-software-management/mock/pull/733
[PR#736]: https://github.com/rpm-software-management/mock/pull/736
[#738]: https://github.com/rpm-software-management/mock/issues/738
[forcearch]: https://github.com/rpm-software-management/mock/wiki/Feature-forcearch

58
docs/Release-Notes-2.12.md Normal file
View file

@ -0,0 +1,58 @@
---
layout: default
title: Release Notes 2.12
---
Released on - 2021-07-19
## Mock 2.12 bugfixes:
This is rather a small bugfix release, the most interesting stuff has been done
in mock-core-configs package (see below).
* We don't set --cwd for --shell mode when a systemd-nspawn without the
`--chdir` option is installed on the sytem (typically el7)
* An RPM `addMacro()` traceback fixed. The SCM plugin was fixed to explicitly
convert the configured macro macro values (in e.g.
`config_opts['macros']['%_platform_multiplier'] = 10`) to strings.
[[PR 753][PR#753]]
* Explicitly disabled versionlock DNF plugin by default, as we don't want to
affect the builds. [[PR 747][PR#747]]
* Mock package requirement on `shadow-utils` was removed from
`mock-core-configs` to proper `mock-filesystem`. [[PR 743][PR#743]]
## Mock-core-configs v34.6:
* CentOS Stream 9 "preview" files added
* Rocky Linux configs added
* AlmaLinux 8 AArch64 configs added.
* Add AlmaLinux Devel repo as an optional repo for AlmaLinux 8.
* Fixed GPG key path for SLE updates in openSUSE Leap 15.3.
* Switch CentOS templates to use quay.io images for bootstrap.
* EPEL Next 8 configs added.
The following contributors contributed to this release:
* Carl George
* Igor Raits
* Louis Abel
* Miroslav Suchý
* Neal Gompa
* Scott K Loga
Thank you!
[PR#747]: https://github.com/rpm-software-management/mock/pull/743
[PR#747]: https://github.com/rpm-software-management/mock/pull/747
[PR#753]: https://github.com/rpm-software-management/mock/pull/753

65
docs/Release-Notes-2.13.md Normal file
View file

@ -0,0 +1,65 @@
---
layout: default
title: Release Notes 2.13
---
Released on - 2021-11-02
## New Mock 2.13 features:
* A new option `--additional-package` is added. During package
development, this option can be used with `mock --rebuild` mode to specify
an additional set of build requirements (still, properly setting
`BuildRequires:` is a preferred way to achieve this) [[PR 776][PR#776]].
* A new option `--debug-config-expanded` is now available. It provides a very
similar mock configuration output to the `--debug-config` option, except that
the `{{ Jinja }}` constructs the configuration are expanded
[[PR 765][PR#765]].
## Mock 2.13 bugfixes:
* The [`external:` dependencies](Feature-external-deps) are now properly
installed into a proper build chroot, not into a bootstrap chroot
[[PR 771][PR#771]].
* The option parsing mechanism was migrated from the `optparse` library to
`argparse`. This in particular shouldn't be a user visible change, so please
report changes in mock behavior if you observe any.
* The repositories generated locally by mock are not automatically signed. But
since Mock did not specify the default `gpgpcheck=` option before, and some of
our config files didn't have `gpgcheck=0` in the `[main]` section,
DNF applied its own `gpgcheck=1` default and it led to `mock --chain` build
failures. Newly we set `gpgcheck=0` by default by Mock and any GPG signed
repository used in mock configuration needs to overwrite this explicitly
[[PR 782][PR#782]].
* When re-mounting, we newly don't specify the source of the mountpoint as it is
not needed in our case, and because the other (preferred) `mount --target ...`
variant is more portable (behaves correctly with older `util-linux`
implementations). [[issue 715][issue#715]]
* The `distro.linux_distribution()` call is now deprecated, we use
`distro.id()` instead. [[PR 767][PR#767]]
* Fixed LVM error message caused by copy/paste error [[PR 758][PR#758]].
The following contributors contributed to this release:
* Gustavo Costa
* Kamil Dudka
* Miroslav Suchý
* Sérgio M. Basto
Thank you!
[PR#758]: https://github.com/rpm-software-management/mock/pull/758
[PR#765]: https://github.com/rpm-software-management/mock/pull/765
[PR#767]: https://github.com/rpm-software-management/mock/pull/767
[PR#776]: https://github.com/rpm-software-management/mock/pull/776
[PR#782]: https://github.com/rpm-software-management/mock/pull/782
[PR#771]: https://github.com/rpm-software-management/mock/pull/771
[issue#715]: https://github.com/rpm-software-management/mock/issues/715

Some files were not shown because too many files have changed in this diff Show more