Doc mods (label no-release-notes)

docs/Feature-container-for-bootstrap.md

@@ -5,11 +5,11 @@ 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 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.
+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. The only requirement for this feature is [Podman](https://podman.io/). Do not forget to install the `podman` package.
+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:
 

docs/Feature-external-deps.md

@@ -8,9 +8,9 @@ It can happen that you need some library that is not packaged. PyPI has ten time
 
 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.
+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 by default disabled. It can be enabled using:
+This feature is disabled by default. It can be enabled using:
 
 ```
 config_opts['external_buildrequires'] = True

docs/Feature-package-managers.md

@@ -29,7 +29,7 @@ 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'

docs/Feature-rhelchroots.md

@@ -31,7 +31,7 @@ $ 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
 ```

docs/Plugin-CCache.md

@@ -10,18 +10,21 @@ 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:
-
-    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
+```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:
 
-    config_opts['plugin_conf']['ccache_opts']['compress'] = 'on'
+```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.
 

docs/Plugin-ChrootScan.md

@@ -8,14 +8,15 @@ The chroot_scan plugin is used to grab files of interest after a build attempt a
 ## 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:
-
-    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
+```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.
 

docs/Plugin-CompressLogs.md

@@ -13,8 +13,8 @@ This plugin is **disabled** by default.
 
 To compress your logs with XZ, you can put this into the
 [configuration](configuration):
-
-    config_opts['plugin_conf']['compress_logs_enable'] = True
-    config_opts['plugin_conf']['compress_logs_opts']['command'] = "/usr/bin/xz -9"
-
+```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.

docs/Plugin-Hooks.md

@@ -24,7 +24,7 @@ Where `HOOK_NAME` is one of:
 * 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.
+* 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.

docs/Plugin-HwInfo.md

@@ -11,10 +11,10 @@ The information is stored in file hw_info.log in results directory.
 ## Configuration
 
 You can enable the plugin using this settings:
-
-    config_opts['plugin_conf']['hw_info_enable'] = True
-    config_opts['plugin_conf']['hw_info_opts'] = {}
-
+```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.

docs/Plugin-LvmRoot.md

@@ -3,7 +3,7 @@ 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 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
@@ -58,6 +58,7 @@ You need to specify a volume group which mock will use to create it's thinpool.
 
 ## 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'] = {
@@ -66,7 +67,7 @@ You need to specify a volume group which mock will use to create it's thinpool.
         '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.

docs/Plugin-Mount.md

@@ -8,17 +8,20 @@ This plugin allows you to mount directories into chroot. The mount plugin is ena
 ## Configuration
 
 You can disable this plugin by:
+```python
+config_opts['plugin_conf']['mount_enable'] = False
+```
 
-    config_opts['plugin_conf']['mount_enable'] = False
-
-you can configure this plugin by:
-
-    config_opts['plugin_conf']['mount_enable'] = True
-    config_opts['plugin_conf']['mount_opts']['dirs'].append(("/dev/device", "/mount/path/in/chroot/", "vfstype", "mount_options"))
+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:
-
-    config_opts['plugin_conf']['mount_opts']['dirs'].append(("server.example.com:/exports/data", "/mnt/data", "nfs", "rw,hard,intr,nosuid,nodev,noatime,tcp"))
+```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
 
@@ -27,20 +30,21 @@ 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']
-
+```python
+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' ))
+```python
+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']
+```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`...).
 
-
-

docs/Plugin-Overlayfs.md

@@ -6,24 +6,25 @@ 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
-U can enable overlayfs plugin by adding this line to your configuration:
-
-    config_opts['plugin_conf']['overlayfs_enable'] = True
+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)
-
-    config_opts['plugin_conf']['root_cache_enable'] = False
-
+```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).
-
-    config_opts['plugin_conf']['overlayfs_opts']['base_dir'] = "/some/directory"
-
+```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
-
-    config_opts['plugin_conf']['overlayfs_opts']['touch_rpmdb'] = True
-
+```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.
@@ -48,7 +49,7 @@ To remove all plugin's data associated with configuration (and therefore snapsho
 
     mock --scrub overlayfs
 
-alternatively, you can remove everything from current configuration:
+Alternatively, you can remove everything from current configuration:
 
     mock --scrub all
 

docs/Plugin-PMRequest.md

@@ -3,15 +3,16 @@ layout: default
 title: Plugin PM Request
 ---
 
-This plugin listens to requests for package management commands from within the buildroot, using 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.
+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:
-
-    config_opts['plugin_conf']['pm_request_enable'] = True
+```python
+config_opts['plugin_conf']['pm_request_enable'] = True
+```
 
 To enable it for a single build, use:
 

docs/Plugin-PackageState.md

@@ -19,7 +19,8 @@ The Package_state plugin is enabled by default.
     config_opts['plugin_conf']['package_state_enable'] = True
 
 The following sub-options may be turned off/on:
-
-    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
+```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
+```

docs/Plugin-ProcEnv.md

@@ -12,9 +12,10 @@ It calls `procenv` command and stores its output.
 ## Configuration
 
 You can enable the plugin using this settings:
-
-    config_opts['plugin_conf']['procenv_enable'] = True
-    config_opts['plugin_conf']['procenv_opts'] = {}
+```python
+config_opts['plugin_conf']['procenv_enable'] = True
+config_opts['plugin_conf']['procenv_opts'] = {}
+```
 
 Available since version 1.4.18.