Some phrasing modifications, a few typos and syntax highlighting (mostly

for configuration blocks).

Author: jessp01

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.