Merge commit '262b328b0bad0c4b97ed495679208e4a2eb87704'

16 files changed, 188 insertions, 625 deletions

diff --git a/nixpkgs/doc/functions/appimagetools.xml b/nixpkgs/doc/functions/appimagetools.xml
index e6dbc22f48dd..37e4251cda2e 100644
--- a/nixpkgs/doc/functions/appimagetools.xml
+++ b/nixpkgs/doc/functions/appimagetools.xml
@@ -5,17 +5,12 @@
  <title>pkgs.appimageTools</title>
 
  <para>
-  <varname>pkgs.appimageTools</varname> is a set of functions for extracting
-  and wrapping <link xlink:href="https://appimage.org/">AppImage</link> files.
-  They are meant to be used if traditional packaging from source is infeasible,
-  or it would take too long. To quickly run an AppImage file,
-  <literal>pkgs.appimage-run</literal> can be used as well.
+  <varname>pkgs.appimageTools</varname> is a set of functions for extracting and wrapping <link xlink:href="https://appimage.org/">AppImage</link> files. They are meant to be used if traditional packaging from source is infeasible, or it would take too long. To quickly run an AppImage file, <literal>pkgs.appimage-run</literal> can be used as well.
  </para>
 
  <warning>
   <para>
-   The <varname>appimageTools</varname> API is unstable and may be subject to
-   backwards-incompatible changes in the future.
+   The <varname>appimageTools</varname> API is unstable and may be subject to backwards-incompatible changes in the future.
   </para>
  </warning>
 
@@ -23,9 +18,7 @@
   <title>AppImage formats</title>
 
   <para>
-   There are different formats for AppImages, see
-   <link xlink:href="https://github.com/AppImage/AppImageSpec/blob/74ad9ca2f94bf864a4a0dac1f369dd4f00bd1c28/draft.md#image-format">the
-   specification</link> for details.
+   There are different formats for AppImages, see <link xlink:href="https://github.com/AppImage/AppImageSpec/blob/74ad9ca2f94bf864a4a0dac1f369dd4f00bd1c28/draft.md#image-format">the specification</link> for details.
   </para>
 
   <itemizedlist>
@@ -55,8 +48,7 @@ type2.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) (Lepton 3.x)
 </screen>
 
   <para>
-   Note how the type 1 AppImage is described as an <literal>ISO 9660 CD-ROM
-   filesystem</literal>, and the type 2 AppImage is not.
+   Note how the type 1 AppImage is described as an <literal>ISO 9660 CD-ROM filesystem</literal>, and the type 2 AppImage is not.
   </para>
  </section>
 
@@ -64,8 +56,7 @@ type2.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) (Lepton 3.x)
   <title>Wrapping</title>
 
   <para>
-   Depending on the type of AppImage you're wrapping, you'll have to use
-   <varname>wrapType1</varname> or <varname>wrapType2</varname>.
+   Depending on the type of AppImage you're wrapping, you'll have to use <varname>wrapType1</varname> or <varname>wrapType2</varname>.
   </para>
 
 <programlisting>
@@ -91,23 +82,16 @@ appimageTools.wrapType2 { # or wrapType1
    </callout>
    <callout arearefs='ex-appimageTools-wrapping-2'>
     <para>
-     <varname>extraPkgs</varname> allows you to pass a function to include
-     additional packages inside the FHS environment your AppImage is going to
-     run in. There are a few ways to learn which dependencies an application
-     needs:
+     <varname>extraPkgs</varname> allows you to pass a function to include additional packages inside the FHS environment your AppImage is going to run in. There are a few ways to learn which dependencies an application needs:
      <itemizedlist>
       <listitem>
        <para>
-        Looking through the extracted AppImage files, reading its scripts and
-        running <command>patchelf</command> and <command>ldd</command> on its
-        executables. This can also be done in <command>appimage-run</command>,
-        by setting <command>APPIMAGE_DEBUG_EXEC=bash</command>.
+        Looking through the extracted AppImage files, reading its scripts and running <command>patchelf</command> and <command>ldd</command> on its executables. This can also be done in <command>appimage-run</command>, by setting <command>APPIMAGE_DEBUG_EXEC=bash</command>.
        </para>
       </listitem>
       <listitem>
        <para>
-        Running <command>strace -vfefile</command> on the wrapped executable,
-        looking for libraries that can't be found.
+        Running <command>strace -vfefile</command> on the wrapped executable, looking for libraries that can't be found.
        </para>
       </listitem>
      </itemizedlist>
diff --git a/nixpkgs/doc/functions/debug.xml b/nixpkgs/doc/functions/debug.xml
index c6b3611eea53..c27421f12e76 100644
--- a/nixpkgs/doc/functions/debug.xml
+++ b/nixpkgs/doc/functions/debug.xml
@@ -5,17 +5,10 @@
  <title>Debugging Nix Expressions</title>
 
  <para>
-  Nix is a unityped, dynamic language, this means every value can potentially
-  appear anywhere. Since it is also non-strict, evaluation order and what
-  ultimately is evaluated might surprise you. Therefore it is important to be
-  able to debug nix expressions.
+  Nix is a unityped, dynamic language, this means every value can potentially appear anywhere. Since it is also non-strict, evaluation order and what ultimately is evaluated might surprise you. Therefore it is important to be able to debug nix expressions.
  </para>
 
  <para>
-  In the <literal>lib/debug.nix</literal> file you will find a number of
-  functions that help (pretty-)printing values while evaluation is runnnig. You
-  can even specify how deep these values should be printed recursively, and
-  transform them on the fly. Please consult the docstrings in
-  <literal>lib/debug.nix</literal> for usage information.
+  In the <literal>lib/debug.nix</literal> file you will find a number of functions that help (pretty-)printing values while evaluation is runnnig. You can even specify how deep these values should be printed recursively, and transform them on the fly. Please consult the docstrings in <literal>lib/debug.nix</literal> for usage information.
  </para>
 </section>
diff --git a/nixpkgs/doc/functions/dockertools.xml b/nixpkgs/doc/functions/dockertools.xml
index a284182bb047..2243453c3e97 100644
--- a/nixpkgs/doc/functions/dockertools.xml
+++ b/nixpkgs/doc/functions/dockertools.xml
@@ -5,17 +5,12 @@
  <title>pkgs.dockerTools</title>
 
  <para>
-  <varname>pkgs.dockerTools</varname> is a set of functions for creating and
-  manipulating Docker images according to the
-  <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#docker-image-specification-v120">
-  Docker Image Specification v1.2.0 </link>. Docker itself is not used to
-  perform any of the operations done by these functions.
+  <varname>pkgs.dockerTools</varname> is a set of functions for creating and manipulating Docker images according to the <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#docker-image-specification-v120"> Docker Image Specification v1.2.0 </link>. Docker itself is not used to perform any of the operations done by these functions.
  </para>
 
  <warning>
   <para>
-   The <varname>dockerTools</varname> API is unstable and may be subject to
-   backwards-incompatible changes in the future.
+   The <varname>dockerTools</varname> API is unstable and may be subject to backwards-incompatible changes in the future.
   </para>
  </warning>
 
@@ -23,15 +18,11 @@
   <title>buildImage</title>
 
   <para>
-   This function is analogous to the <command>docker build</command> command,
-   in that it can be used to build a Docker-compatible repository tarball
-   containing a single image with one or multiple layers. As such, the result
-   is suitable for being loaded in Docker with <command>docker load</command>.
+   This function is analogous to the <command>docker build</command> command, in that it can be used to build a Docker-compatible repository tarball containing a single image with one or multiple layers. As such, the result is suitable for being loaded in Docker with <command>docker load</command>.
   </para>
 
   <para>
-   The parameters of <varname>buildImage</varname> with relative example values
-   are described below:
+   The parameters of <varname>buildImage</varname> with relative example values are described below:
   </para>
 
   <example xml:id='ex-dockerTools-buildImage'>
@@ -63,135 +54,89 @@ buildImage {
   </example>
 
   <para>
-   The above example will build a Docker image <literal>redis/latest</literal>
-   from the given base image. Loading and running this image in Docker results
-   in <literal>redis-server</literal> being started automatically.
+   The above example will build a Docker image <literal>redis/latest</literal> from the given base image. Loading and running this image in Docker results in <literal>redis-server</literal> being started automatically.
   </para>
 
   <calloutlist>
    <callout arearefs='ex-dockerTools-buildImage-1'>
     <para>
-     <varname>name</varname> specifies the name of the resulting image. This is
-     the only required argument for <varname>buildImage</varname>.
+     <varname>name</varname> specifies the name of the resulting image. This is the only required argument for <varname>buildImage</varname>.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-buildImage-2'>
     <para>
-     <varname>tag</varname> specifies the tag of the resulting image. By
-     default it's <literal>null</literal>, which indicates that the nix output
-     hash will be used as tag.
+     <varname>tag</varname> specifies the tag of the resulting image. By default it's <literal>null</literal>, which indicates that the nix output hash will be used as tag.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-buildImage-3'>
     <para>
-     <varname>fromImage</varname> is the repository tarball containing the base
-     image. It must be a valid Docker image, such as exported by
-     <command>docker save</command>. By default it's <literal>null</literal>,
-     which can be seen as equivalent to <literal>FROM scratch</literal> of a
-     <filename>Dockerfile</filename>.
+     <varname>fromImage</varname> is the repository tarball containing the base image. It must be a valid Docker image, such as exported by <command>docker save</command>. By default it's <literal>null</literal>, which can be seen as equivalent to <literal>FROM scratch</literal> of a <filename>Dockerfile</filename>.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-buildImage-4'>
     <para>
-     <varname>fromImageName</varname> can be used to further specify the base
-     image within the repository, in case it contains multiple images. By
-     default it's <literal>null</literal>, in which case
-     <varname>buildImage</varname> will peek the first image available in the
-     repository.
+     <varname>fromImageName</varname> can be used to further specify the base image within the repository, in case it contains multiple images. By default it's <literal>null</literal>, in which case <varname>buildImage</varname> will peek the first image available in the repository.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-buildImage-5'>
     <para>
-     <varname>fromImageTag</varname> can be used to further specify the tag of
-     the base image within the repository, in case an image contains multiple
-     tags. By default it's <literal>null</literal>, in which case
-     <varname>buildImage</varname> will peek the first tag available for the
-     base image.
+     <varname>fromImageTag</varname> can be used to further specify the tag of the base image within the repository, in case an image contains multiple tags. By default it's <literal>null</literal>, in which case <varname>buildImage</varname> will peek the first tag available for the base image.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-buildImage-6'>
     <para>
-     <varname>contents</varname> is a derivation that will be copied in the new
-     layer of the resulting image. This can be similarly seen as <command>ADD
-     contents/ /</command> in a <filename>Dockerfile</filename>. By default
-     it's <literal>null</literal>.
+     <varname>contents</varname> is a derivation that will be copied in the new layer of the resulting image. This can be similarly seen as <command>ADD contents/ /</command> in a <filename>Dockerfile</filename>. By default it's <literal>null</literal>.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-buildImage-runAsRoot'>
     <para>
-     <varname>runAsRoot</varname> is a bash script that will run as root in an
-     environment that overlays the existing layers of the base image with the
-     new resulting layer, including the previously copied
-     <varname>contents</varname> derivation. This can be similarly seen as
-     <command>RUN ...</command> in a <filename>Dockerfile</filename>.
+     <varname>runAsRoot</varname> is a bash script that will run as root in an environment that overlays the existing layers of the base image with the new resulting layer, including the previously copied <varname>contents</varname> derivation. This can be similarly seen as <command>RUN ...</command> in a <filename>Dockerfile</filename>.
      <note>
       <para>
-       Using this parameter requires the <literal>kvm</literal> device to be
-       available.
+       Using this parameter requires the <literal>kvm</literal> device to be available.
       </para>
      </note>
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-buildImage-8'>
     <para>
-     <varname>config</varname> is used to specify the configuration of the
-     containers that will be started off the built image in Docker. The
-     available options are listed in the
-     <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions">
-     Docker Image Specification v1.2.0 </link>.
+     <varname>config</varname> is used to specify the configuration of the containers that will be started off the built image in Docker. The available options are listed in the <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions"> Docker Image Specification v1.2.0 </link>.
     </para>
    </callout>
   </calloutlist>
 
   <para>
-   After the new layer has been created, its closure (to which
-   <varname>contents</varname>, <varname>config</varname> and
-   <varname>runAsRoot</varname> contribute) will be copied in the layer itself.
-   Only new dependencies that are not already in the existing layers will be
-   copied.
+   After the new layer has been created, its closure (to which <varname>contents</varname>, <varname>config</varname> and <varname>runAsRoot</varname> contribute) will be copied in the layer itself. Only new dependencies that are not already in the existing layers will be copied.
   </para>
 
   <para>
-   At the end of the process, only one new single layer will be produced and
-   added to the resulting image.
+   At the end of the process, only one new single layer will be produced and added to the resulting image.
   </para>
 
   <para>
-   The resulting repository will only list the single image
-   <varname>image/tag</varname>. In the case of
-   <xref linkend='ex-dockerTools-buildImage'/> it would be
-   <varname>redis/latest</varname>.
+   The resulting repository will only list the single image <varname>image/tag</varname>. In the case of <xref linkend='ex-dockerTools-buildImage'/> it would be <varname>redis/latest</varname>.
   </para>
 
   <para>
-   It is possible to inspect the arguments with which an image was built using
-   its <varname>buildArgs</varname> attribute.
+   It is possible to inspect the arguments with which an image was built using its <varname>buildArgs</varname> attribute.
   </para>
 
   <note>
    <para>
-    If you see errors similar to <literal>getProtocolByName: does not exist (no
-    such protocol name: tcp)</literal> you may need to add
-    <literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
+    If you see errors similar to <literal>getProtocolByName: does not exist (no such protocol name: tcp)</literal> you may need to add <literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
    </para>
   </note>
 
   <note>
    <para>
-    If you see errors similar to <literal>Error_Protocol ("certificate has
-    unknown CA",True,UnknownCa)</literal> you may need to add
-    <literal>pkgs.cacert</literal> to <varname>contents</varname>.
+    If you see errors similar to <literal>Error_Protocol ("certificate has unknown CA",True,UnknownCa)</literal> you may need to add <literal>pkgs.cacert</literal> to <varname>contents</varname>.
    </para>
   </note>
 
   <example xml:id="example-pkgs-dockerTools-buildImage-creation-date">
    <title>Impurely Defining a Docker Layer's Creation Date</title>
    <para>
-    By default <function>buildImage</function> will use a static date of one
-    second past the UNIX Epoch. This allows <function>buildImage</function> to
-    produce binary reproducible images. When listing images with
-    <command>docker images</command>, the newly created images will be listed
-    like this:
+    By default <function>buildImage</function> will use a static date of one second past the UNIX Epoch. This allows <function>buildImage</function> to produce binary reproducible images. When listing images with <command>docker images</command>, the newly created images will be listed like this:
    </para>
 <screen><![CDATA[
 $ docker images
@@ -199,9 +144,7 @@ REPOSITORY   TAG      IMAGE ID       CREATED        SIZE
 hello        latest   08c791c7846e   48 years ago   25.2MB
 ]]></screen>
    <para>
-    You can break binary reproducibility but have a sorted, meaningful
-    <literal>CREATED</literal> column by setting <literal>created</literal> to
-    <literal>now</literal>.
+    You can break binary reproducibility but have a sorted, meaningful <literal>CREATED</literal> column by setting <literal>created</literal> to <literal>now</literal>.
    </para>
 <programlisting><![CDATA[
 pkgs.dockerTools.buildImage {
@@ -214,8 +157,7 @@ pkgs.dockerTools.buildImage {
 }
 ]]></programlisting>
    <para>
-    and now the Docker CLI will display a reasonable date and sort the images
-    as expected:
+    and now the Docker CLI will display a reasonable date and sort the images as expected:
 <screen><![CDATA[
 $ docker images
 REPOSITORY   TAG      IMAGE ID       CREATED              SIZE
@@ -230,8 +172,7 @@ hello        latest   de2bf4786de6   About a minute ago   25.2MB
   <title>buildLayeredImage</title>
 
   <para>
-   Create a Docker image with many of the store paths being on their own layer
-   to improve sharing between images.
+   Create a Docker image with many of the store paths being on their own layer to improve sharing between images.
   </para>
 
   <variablelist>
@@ -264,8 +205,7 @@ hello        latest   de2bf4786de6   About a minute ago   25.2MB
     </term>
     <listitem>
      <para>
-      Top level paths in the container. Either a single derivation, or a list
-      of derivations.
+      Top level paths in the container. Either a single derivation, or a list of derivations.
      </para>
      <para>
       <emphasis>Default:</emphasis> <literal>[]</literal>
@@ -278,10 +218,7 @@ hello        latest   de2bf4786de6   About a minute ago   25.2MB
     </term>
     <listitem>
      <para>
-      Run-time configuration of the container. A full list of the options are
-      available at in the
-      <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions">
-      Docker Image Specification v1.2.0 </link>.
+      Run-time configuration of the container. A full list of the options are available at in the <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions"> Docker Image Specification v1.2.0 </link>.
      </para>
      <para>
       <emphasis>Default:</emphasis> <literal>{}</literal>
@@ -294,9 +231,7 @@ hello        latest   de2bf4786de6   About a minute ago   25.2MB
     </term>
     <listitem>
      <para>
-      Date and time the layers were created. Follows the same
-      <literal>now</literal> exception supported by
-      <literal>buildImage</literal>.
+      Date and time the layers were created. Follows the same <literal>now</literal> exception supported by <literal>buildImage</literal>.
      </para>
      <para>
       <emphasis>Default:</emphasis> <literal>1970-01-01T00:00:01Z</literal>
@@ -325,10 +260,7 @@ hello        latest   de2bf4786de6   About a minute ago   25.2MB
     </term>
     <listitem>
      <para>
-       Shell commands to run while building the final layer, without access
-       to most of the layer contents. Changes to this layer are "on top"
-       of all the other layers, so can create additional directories
-       and files.
+      Shell commands to run while building the final layer, without access to most of the layer contents. Changes to this layer are "on top" of all the other layers, so can create additional directories and files.
      </para>
     </listitem>
    </varlistentry>
@@ -338,8 +270,7 @@ hello        latest   de2bf4786de6   About a minute ago   25.2MB
    <title>Behavior of <varname>contents</varname> in the final image</title>
 
    <para>
-    Each path directly listed in <varname>contents</varname> will have a
-    symlink in the root of the image.
+    Each path directly listed in <varname>contents</varname> will have a symlink in the root of the image.
    </para>
 
    <para>
@@ -350,8 +281,7 @@ pkgs.dockerTools.buildLayeredImage {
   contents = [ pkgs.hello ];
 }
 ]]></programlisting>
-    will create symlinks for all the paths in the <literal>hello</literal>
-    package:
+    will create symlinks for all the paths in the <literal>hello</literal> package:
 <screen><![CDATA[
 /bin/hello -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/bin/hello
 /share/info/hello.info -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/share/info/hello.info
@@ -364,13 +294,11 @@ pkgs.dockerTools.buildLayeredImage {
    <title>Automatic inclusion of <varname>config</varname> references</title>
 
    <para>
-    The closure of <varname>config</varname> is automatically included in the
-    closure of the final image.
+    The closure of <varname>config</varname> is automatically included in the closure of the final image.
    </para>
 
    <para>
-    This allows you to make very simple Docker images with very little code.
-    This container will start up and run <command>hello</command>:
+    This allows you to make very simple Docker images with very little code. This container will start up and run <command>hello</command>:
 <programlisting><![CDATA[
 pkgs.dockerTools.buildLayeredImage {
   name = "hello";
@@ -384,31 +312,23 @@ pkgs.dockerTools.buildLayeredImage {
    <title>Adjusting <varname>maxLayers</varname></title>
 
    <para>
-    Increasing the <varname>maxLayers</varname> increases the number of layers
-    which have a chance to be shared between different images.
+    Increasing the <varname>maxLayers</varname> increases the number of layers which have a chance to be shared between different images.
    </para>
 
    <para>
-    Modern Docker installations support up to 128 layers, however older
-    versions support as few as 42.
+    Modern Docker installations support up to 128 layers, however older versions support as few as 42.
    </para>
 
    <para>
-    If the produced image will not be extended by other Docker builds, it is
-    safe to set <varname>maxLayers</varname> to <literal>128</literal>. However
-    it will be impossible to extend the image further.
+    If the produced image will not be extended by other Docker builds, it is safe to set <varname>maxLayers</varname> to <literal>128</literal>. However it will be impossible to extend the image further.
    </para>
 
    <para>
-    The first (<literal>maxLayers-2</literal>) most "popular" paths will have
-    their own individual layers, then layer #<literal>maxLayers-1</literal>
-    will contain all the remaining "unpopular" paths, and finally layer
-    #<literal>maxLayers</literal> will contain the Image configuration.
+    The first (<literal>maxLayers-2</literal>) most "popular" paths will have their own individual layers, then layer #<literal>maxLayers-1</literal> will contain all the remaining "unpopular" paths, and finally layer #<literal>maxLayers</literal> will contain the Image configuration.
    </para>
 
    <para>
-    Docker's Layers are not inherently ordered, they are content-addressable
-    and are not explicitly layered until they are composed in to an Image.
+    Docker's Layers are not inherently ordered, they are content-addressable and are not explicitly layered until they are composed in to an Image.
    </para>
   </section>
  </section>
@@ -417,10 +337,7 @@ pkgs.dockerTools.buildLayeredImage {
   <title>pullImage</title>
 
   <para>
-   This function is analogous to the <command>docker pull</command> command, in
-   that it can be used to pull a Docker image from a Docker registry. By
-   default <link xlink:href="https://hub.docker.com/">Docker Hub</link> is used
-   to pull images.
+   This function is analogous to the <command>docker pull</command> command, in that it can be used to pull a Docker image from a Docker registry. By default <link xlink:href="https://hub.docker.com/">Docker Hub</link> is used to pull images.
   </para>
 
   <para>
@@ -445,76 +362,51 @@ pullImage {
   <calloutlist>
    <callout arearefs='ex-dockerTools-pullImage-1'>
     <para>
-     <varname>imageName</varname> specifies the name of the image to be
-     downloaded, which can also include the registry namespace (e.g.
-     <literal>nixos</literal>). This argument is required.
+     <varname>imageName</varname> specifies the name of the image to be downloaded, which can also include the registry namespace (e.g. <literal>nixos</literal>). This argument is required.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-pullImage-2'>
     <para>
-     <varname>imageDigest</varname> specifies the digest of the image to be
-     downloaded. This argument is required.
+     <varname>imageDigest</varname> specifies the digest of the image to be downloaded. This argument is required.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-pullImage-3'>
     <para>
-     <varname>finalImageName</varname>, if specified, this is the name of the
-     image to be created. Note it is never used to fetch the image since we
-     prefer to rely on the immutable digest ID. By default it's equal to
-     <varname>imageName</varname>.
+     <varname>finalImageName</varname>, if specified, this is the name of the image to be created. Note it is never used to fetch the image since we prefer to rely on the immutable digest ID. By default it's equal to <varname>imageName</varname>.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-pullImage-4'>
     <para>
-     <varname>finalImageTag</varname>, if specified, this is the tag of the
-     image to be created. Note it is never used to fetch the image since we
-     prefer to rely on the immutable digest ID. By default it's
-     <literal>latest</literal>.
+     <varname>finalImageTag</varname>, if specified, this is the tag of the image to be created. Note it is never used to fetch the image since we prefer to rely on the immutable digest ID. By default it's <literal>latest</literal>.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-pullImage-5'>
     <para>
-     <varname>sha256</varname> is the checksum of the whole fetched image. This
-     argument is required.
+     <varname>sha256</varname> is the checksum of the whole fetched image. This argument is required.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-pullImage-6'>
     <para>
-     <varname>os</varname>, if specified, is the operating system of the
-     fetched image. By default it's <literal>linux</literal>.
+     <varname>os</varname>, if specified, is the operating system of the fetched image. By default it's <literal>linux</literal>.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-pullImage-7'>
     <para>
-     <varname>arch</varname>, if specified, is the cpu architecture of the
-     fetched image. By default it's <literal>x86_64</literal>.
+     <varname>arch</varname>, if specified, is the cpu architecture of the fetched image. By default it's <literal>x86_64</literal>.
     </para>
    </callout>
   </calloutlist>
 
   <para>
-    <literal>nix-prefetch-docker</literal> command can be used to get required
-    image parameters:
-
+   <literal>nix-prefetch-docker</literal> command can be used to get required image parameters:
 <screen>
 <prompt>$ </prompt>nix run nixpkgs.nix-prefetch-docker -c nix-prefetch-docker --image-name mysql --image-tag 5
 </screen>
-
-    Since a given <varname>imageName</varname> may transparently refer to a
-    manifest list of images which support multiple architectures and/or
-    operating systems, you can supply the <option>--os</option> and
-    <option>--arch</option> arguments to specify exactly which image you want.
-    By default it will match the OS and architecture of the host the command is
-    run on.
-
+   Since a given <varname>imageName</varname> may transparently refer to a manifest list of images which support multiple architectures and/or operating systems, you can supply the <option>--os</option> and <option>--arch</option> arguments to specify exactly which image you want. By default it will match the OS and architecture of the host the command is run on.
 <screen>
 <prompt>$ </prompt>nix-prefetch-docker --image-name mysql --image-tag 5 --arch x86_64 --os linux
 </screen>
-
-    Desired image name and tag can be set using
-    <option>--final-image-name</option> and <option>--final-image-tag</option>
-    arguments:
-
+   Desired image name and tag can be set using <option>--final-image-name</option> and <option>--final-image-tag</option> arguments:
 <screen>
 <prompt>$ </prompt>nix-prefetch-docker --image-name mysql --image-tag 5 --final-image-name eu.gcr.io/my-project/mysql --final-image-tag prod
 </screen>
@@ -525,17 +417,12 @@ pullImage {
   <title>exportImage</title>
 
   <para>
-   This function is analogous to the <command>docker export</command> command,
-   in that it can be used to flatten a Docker image that contains multiple
-   layers. It is in fact the result of the merge of all the layers of the
-   image. As such, the result is suitable for being imported in Docker with
-   <command>docker import</command>.
+   This function is analogous to the <command>docker export</command> command, in that it can be used to flatten a Docker image that contains multiple layers. It is in fact the result of the merge of all the layers of the image. As such, the result is suitable for being imported in Docker with <command>docker import</command>.
   </para>
 
   <note>
    <para>
-    Using this function requires the <literal>kvm</literal> device to be
-    available.
+    Using this function requires the <literal>kvm</literal> device to be available.
    </para>
   </note>
 
@@ -557,14 +444,11 @@ exportImage {
   </example>
 
   <para>
-   The parameters relative to the base image have the same synopsis as
-   described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except that
-   <varname>fromImage</varname> is the only required argument in this case.
+   The parameters relative to the base image have the same synopsis as described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except that <varname>fromImage</varname> is the only required argument in this case.
   </para>
 
   <para>
-   The <varname>name</varname> argument is the name of the derivation output,
-   which defaults to <varname>fromImage.name</varname>.
+   The <varname>name</varname> argument is the name of the derivation output, which defaults to <varname>fromImage.name</varname>.
   </para>
  </section>
 
@@ -572,11 +456,7 @@ exportImage {
   <title>shadowSetup</title>
 
   <para>
-   This constant string is a helper for setting up the base files for managing
-   users and groups, only if such files don't exist already. It is suitable for
-   being used in a <varname>runAsRoot</varname>
-   <xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like
-   in the example below:
+   This constant string is a helper for setting up the base files for managing users and groups, only if such files don't exist already. It is suitable for being used in a <varname>runAsRoot</varname> <xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like in the example below:
   </para>
 
   <example xml:id='ex-dockerTools-shadowSetup'>
@@ -598,9 +478,7 @@ buildImage {
   </example>
 
   <para>
-   Creating base files like <literal>/etc/passwd</literal> or
-   <literal>/etc/login.defs</literal> is necessary for shadow-utils to
-   manipulate users and groups.
+   Creating base files like <literal>/etc/passwd</literal> or <literal>/etc/login.defs</literal> is necessary for shadow-utils to manipulate users and groups.
   </para>
  </section>
 </section>
diff --git a/nixpkgs/doc/functions/fetchers.xml b/nixpkgs/doc/functions/fetchers.xml
index a736008c9d41..369c1fb153eb 100644
--- a/nixpkgs/doc/functions/fetchers.xml
+++ b/nixpkgs/doc/functions/fetchers.xml
@@ -5,18 +5,11 @@
  <title>Fetcher functions</title>
 
  <para>
-  When using Nix, you will frequently need to download source code and other
-  files from the internet. Nixpkgs comes with a few helper functions that allow
-  you to fetch fixed-output derivations in a structured way.
+  When using Nix, you will frequently need to download source code and other files from the internet. Nixpkgs comes with a few helper functions that allow you to fetch fixed-output derivations in a structured way.
  </para>
 
  <para>
-  The two fetcher primitives are <function>fetchurl</function> and
-  <function>fetchzip</function>. Both of these have two required arguments, a
-  URL and a hash. The hash is typically <literal>sha256</literal>, although
-  many more hash algorithms are supported. Nixpkgs contributors are currently
-  recommended to use <literal>sha256</literal>. This hash will be used by Nix
-  to identify your source. A typical usage of fetchurl is provided below.
+  The two fetcher primitives are <function>fetchurl</function> and <function>fetchzip</function>. Both of these have two required arguments, a URL and a hash. The hash is typically <literal>sha256</literal>, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use <literal>sha256</literal>. This hash will be used by Nix to identify your source. A typical usage of fetchurl is provided below.
  </para>
 
 <programlisting><![CDATA[
@@ -32,30 +25,15 @@ stdenv.mkDerivation {
 ]]></programlisting>
 
  <para>
-  The main difference between <function>fetchurl</function> and
-  <function>fetchzip</function> is in how they store the contents.
-  <function>fetchurl</function> will store the unaltered contents of the URL
-  within the Nix store. <function>fetchzip</function> on the other hand will
-  decompress the archive for you, making files and directories directly
-  accessible in the future. <function>fetchzip</function> can only be used with
-  archives. Despite the name, <function>fetchzip</function> is not limited to
-  .zip files and can also be used with any tarball.
+  The main difference between <function>fetchurl</function> and <function>fetchzip</function> is in how they store the contents. <function>fetchurl</function> will store the unaltered contents of the URL within the Nix store. <function>fetchzip</function> on the other hand will decompress the archive for you, making files and directories directly accessible in the future. <function>fetchzip</function> can only be used with archives. Despite the name, <function>fetchzip</function> is not limited to .zip files and can also be used with any tarball.
  </para>
 
  <para>
-  <function>fetchpatch</function> works very similarly to
-  <function>fetchurl</function> with the same arguments expected. It expects
-  patch files as a source and and performs normalization on them before
-  computing the checksum. For example it will remove comments or other unstable
-  parts that are sometimes added by version control systems and can change over
-  time.
+  <function>fetchpatch</function> works very similarly to <function>fetchurl</function> with the same arguments expected. It expects patch files as a source and and performs normalization on them before computing the checksum. For example it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
  </para>
 
  <para>
-  Other fetcher functions allow you to add source code directly from a VCS such
-  as subversion or git. These are mostly straightforward names based on the
-  name of the command used with the VCS system. Because they give you a working
-  repository, they act most like <function>fetchzip</function>.
+  Other fetcher functions allow you to add source code directly from a VCS such as subversion or git. These are mostly straightforward names based on the name of the command used with the VCS system. Because they give you a working repository, they act most like <function>fetchzip</function>.
  </para>
 
  <variablelist>
@@ -65,8 +43,7 @@ stdenv.mkDerivation {
    </term>
    <listitem>
     <para>
-     Used with Subversion. Expects <literal>url</literal> to a Subversion
-     directory, <literal>rev</literal>, and <literal>sha256</literal>.
+     Used with Subversion. Expects <literal>url</literal> to a Subversion directory, <literal>rev</literal>, and <literal>sha256</literal>.
     </para>
    </listitem>
   </varlistentry>
@@ -76,10 +53,7 @@ stdenv.mkDerivation {
    </term>
    <listitem>
     <para>
-     Used with Git. Expects <literal>url</literal> to a Git repo,
-     <literal>rev</literal>, and <literal>sha256</literal>.
-     <literal>rev</literal> in this case can be full the git commit id (SHA1
-     hash) or a tag name like <literal>refs/tags/v1.0</literal>.
+     Used with Git. Expects <literal>url</literal> to a Git repo, <literal>rev</literal>, and <literal>sha256</literal>. <literal>rev</literal> in this case can be full the git commit id (SHA1 hash) or a tag name like <literal>refs/tags/v1.0</literal>.
     </para>
    </listitem>
   </varlistentry>
@@ -89,8 +63,7 @@ stdenv.mkDerivation {
    </term>
    <listitem>
     <para>
-     Used with Fossil. Expects <literal>url</literal> to a Fossil archive,
-     <literal>rev</literal>, and <literal>sha256</literal>.
+     Used with Fossil. Expects <literal>url</literal> to a Fossil archive, <literal>rev</literal>, and <literal>sha256</literal>.
     </para>
    </listitem>
   </varlistentry>
@@ -100,8 +73,7 @@ stdenv.mkDerivation {
    </term>
    <listitem>
     <para>
-     Used with CVS. Expects <literal>cvsRoot</literal>, <literal>tag</literal>,
-     and <literal>sha256</literal>.
+     Used with CVS. Expects <literal>cvsRoot</literal>, <literal>tag</literal>, and <literal>sha256</literal>.
     </para>
    </listitem>
   </varlistentry>
@@ -111,18 +83,14 @@ stdenv.mkDerivation {
    </term>
    <listitem>
     <para>
-     Used with Mercurial. Expects <literal>url</literal>,
-     <literal>rev</literal>, and <literal>sha256</literal>.
+     Used with Mercurial. Expects <literal>url</literal>, <literal>rev</literal>, and <literal>sha256</literal>.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 
  <para>
-  A number of fetcher functions wrap part of <function>fetchurl</function> and
-  <function>fetchzip</function>. They are mainly convenience functions intended
-  for commonly used destinations of source code in Nixpkgs. These wrapper
-  fetchers are listed below.
+  A number of fetcher functions wrap part of <function>fetchurl</function> and <function>fetchzip</function>. They are mainly convenience functions intended for commonly used destinations of source code in Nixpkgs. These wrapper fetchers are listed below.
  </para>
 
  <variablelist>
@@ -132,17 +100,7 @@ stdenv.mkDerivation {
    </term>
    <listitem>
     <para>
-     <function>fetchFromGitHub</function> expects four arguments.
-     <literal>owner</literal> is a string corresponding to the GitHub user or
-     organization that controls this repository. <literal>repo</literal>
-     corresponds to the name of the software repository. These are located at
-     the top of every GitHub HTML page as
-     <literal>owner</literal>/<literal>repo</literal>. <literal>rev</literal>
-     corresponds to the Git commit hash or tag (e.g <literal>v1.0</literal>)
-     that will be downloaded from Git. Finally, <literal>sha256</literal>
-     corresponds to the hash of the extracted directory. Again, other hash
-     algorithms are also available but <literal>sha256</literal> is currently
-     preferred.
+     <function>fetchFromGitHub</function> expects four arguments. <literal>owner</literal> is a string corresponding to the GitHub user or organization that controls this repository. <literal>repo</literal> corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as <literal>owner</literal>/<literal>repo</literal>. <literal>rev</literal> corresponds to the Git commit hash or tag (e.g <literal>v1.0</literal>) that will be downloaded from Git. Finally, <literal>sha256</literal> corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but <literal>sha256</literal> is currently preferred.
     </para>
    </listitem>
   </varlistentry>
@@ -152,8 +110,7 @@ stdenv.mkDerivation {
    </term>
    <listitem>
     <para>
-     This is used with GitLab repositories. The arguments expected are very
-     similar to fetchFromGitHub above.
+     This is used with GitLab repositories. The arguments expected are very similar to fetchFromGitHub above.
     </para>
    </listitem>
   </varlistentry>
@@ -163,8 +120,7 @@ stdenv.mkDerivation {
    </term>
    <listitem>
     <para>
-     This is used with BitBucket repositories. The arguments expected are very
-     similar to fetchFromGitHub above.
+     This is used with BitBucket repositories. The arguments expected are very similar to fetchFromGitHub above.
     </para>
    </listitem>
   </varlistentry>
@@ -174,8 +130,7 @@ stdenv.mkDerivation {
    </term>
    <listitem>
     <para>
-     This is used with Savannah repositories. The arguments expected are very
-     similar to fetchFromGitHub above.
+     This is used with Savannah repositories. The arguments expected are very similar to fetchFromGitHub above.
     </para>
    </listitem>
   </varlistentry>
@@ -185,8 +140,7 @@ stdenv.mkDerivation {
    </term>
    <listitem>
     <para>
-     This is used with repo.or.cz repositories. The arguments expected are very
-     similar to fetchFromGitHub above.
+     This is used with repo.or.cz repositories. The arguments expected are very similar to fetchFromGitHub above.
     </para>
    </listitem>
   </varlistentry>
diff --git a/nixpkgs/doc/functions/fhs-environments.xml b/nixpkgs/doc/functions/fhs-environments.xml
index 79682080be31..e7b81e97a23f 100644
--- a/nixpkgs/doc/functions/fhs-environments.xml
+++ b/nixpkgs/doc/functions/fhs-environments.xml
@@ -5,15 +5,7 @@
  <title>buildFHSUserEnv</title>
 
  <para>
-  <function>buildFHSUserEnv</function> provides a way to build and run
-  FHS-compatible lightweight sandboxes. It creates an isolated root with bound
-  <filename>/nix/store</filename>, so its footprint in terms of disk space
-  needed is quite small. This allows one to run software which is hard or
-  unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions,
-  games distributed as tarballs, software with integrity checking and/or
-  external self-updated binaries. It uses Linux namespaces feature to create
-  temporary lightweight environments which are destroyed after all child
-  processes exit, without root user rights requirement. Accepted arguments are:
+  <function>buildFHSUserEnv</function> provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root with bound <filename>/nix/store</filename>, so its footprint in terms of disk space needed is quite small. This allows one to run software which is hard or unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries. It uses Linux namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without root user rights requirement. Accepted arguments are:
  </para>
 
  <variablelist>
@@ -33,8 +25,7 @@
    </term>
    <listitem>
     <para>
-     Packages to be installed for the main host's architecture (i.e. x86_64 on
-     x86_64 installations). Along with libraries binaries are also installed.
+     Packages to be installed for the main host's architecture (i.e. x86_64 on x86_64 installations). Along with libraries binaries are also installed.
     </para>
    </listitem>
   </varlistentry>
@@ -44,9 +35,7 @@
    </term>
    <listitem>
     <para>
-     Packages to be installed for all architectures supported by a host (i.e.
-     i686 and x86_64 on x86_64 installations). Only libraries are installed by
-     default.
+     Packages to be installed for all architectures supported by a host (i.e. i686 and x86_64 on x86_64 installations). Only libraries are installed by default.
     </para>
    </listitem>
   </varlistentry>
@@ -66,8 +55,7 @@
    </term>
    <listitem>
     <para>
-     Like <literal>extraBuildCommands</literal>, but executed only on multilib
-     architectures.
+     Like <literal>extraBuildCommands</literal>, but executed only on multilib architectures.
     </para>
    </listitem>
   </varlistentry>
@@ -77,8 +65,7 @@
    </term>
    <listitem>
     <para>
-     Additional derivation outputs to be linked for both target and
-     multi-architecture packages.
+     Additional derivation outputs to be linked for both target and multi-architecture packages.
     </para>
    </listitem>
   </varlistentry>
@@ -88,8 +75,7 @@
    </term>
    <listitem>
     <para>
-     Additional commands to be executed for finalizing the derivation with
-     runner script.
+     Additional commands to be executed for finalizing the derivation with runner script.
     </para>
    </listitem>
   </varlistentry>
@@ -99,16 +85,14 @@
    </term>
    <listitem>
     <para>
-     A command that would be executed inside the sandbox and passed all the
-     command line arguments. It defaults to <literal>bash</literal>.
+     A command that would be executed inside the sandbox and passed all the command line arguments. It defaults to <literal>bash</literal>.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 
  <para>
-  One can create a simple environment using a <literal>shell.nix</literal> like
-  that:
+  One can create a simple environment using a <literal>shell.nix</literal> like that:
  </para>
 
 <programlisting><![CDATA[
@@ -133,10 +117,6 @@
 ]]></programlisting>
 
  <para>
-  Running <literal>nix-shell</literal> would then drop you into a shell with
-  these libraries and binaries available. You can use this to run closed-source
-  applications which expect FHS structure without hassles: simply change
-  <literal>runScript</literal> to the application path, e.g.
-  <filename>./bin/start.sh</filename> -- relative paths are supported.
+  Running <literal>nix-shell</literal> would then drop you into a shell with these libraries and binaries available. You can use this to run closed-source applications which expect FHS structure without hassles: simply change <literal>runScript</literal> to the application path, e.g. <filename>./bin/start.sh</filename> -- relative paths are supported.
  </para>
 </section>
diff --git a/nixpkgs/doc/functions/generators.xml b/nixpkgs/doc/functions/generators.xml
index e860b10e8979..9ce1f85eb173 100644
--- a/nixpkgs/doc/functions/generators.xml
+++ b/nixpkgs/doc/functions/generators.xml
@@ -5,28 +5,15 @@
  <title>Generators</title>
 
  <para>
-  Generators are functions that create file formats from nix data structures,
-  e. g. for configuration files. There are generators available for:
-  <literal>INI</literal>, <literal>JSON</literal> and <literal>YAML</literal>
+  Generators are functions that create file formats from nix data structures, e. g. for configuration files. There are generators available for: <literal>INI</literal>, <literal>JSON</literal> and <literal>YAML</literal>
  </para>
 
  <para>
-  All generators follow a similar call interface: <code>generatorName
-  configFunctions data</code>, where <literal>configFunctions</literal> is an
-  attrset of user-defined functions that format nested parts of the content.
-  They each have common defaults, so often they do not need to be set manually.
-  An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]" ]
-  name)</code> from the <literal>INI</literal> generator. It receives the name
-  of a section and sanitizes it. The default <literal>mkSectionName</literal>
-  escapes <literal>[</literal> and <literal>]</literal> with a backslash.
+  All generators follow a similar call interface: <code>generatorName configFunctions data</code>, where <literal>configFunctions</literal> is an attrset of user-defined functions that format nested parts of the content. They each have common defaults, so often they do not need to be set manually. An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]" ] name)</code> from the <literal>INI</literal> generator. It receives the name of a section and sanitizes it. The default <literal>mkSectionName</literal> escapes <literal>[</literal> and <literal>]</literal> with a backslash.
  </para>
 
  <para>
-  Generators can be fine-tuned to produce exactly the file format required by
-  your application/service. One example is an INI-file format which uses
-  <literal>: </literal> as separator, the strings
-  <literal>"yes"</literal>/<literal>"no"</literal> as boolean values and
-  requires all string values to be quoted:
+  Generators can be fine-tuned to produce exactly the file format required by your application/service. One example is an INI-file format which uses <literal>: </literal> as separator, the strings <literal>"yes"</literal>/<literal>"no"</literal> as boolean values and requires all string values to be quoted:
  </para>
 
 <programlisting>
@@ -77,13 +64,11 @@ merge:"diff3"
 
  <note>
   <para>
-   Nix store paths can be converted to strings by enclosing a derivation
-   attribute like so: <code>"${drv}"</code>.
+   Nix store paths can be converted to strings by enclosing a derivation attribute like so: <code>"${drv}"</code>.
   </para>
  </note>
 
  <para>
-  Detailed documentation for each generator can be found in
-  <literal>lib/generators.nix</literal>.
+  Detailed documentation for each generator can be found in <literal>lib/generators.nix</literal>.
  </para>
 </section>
diff --git a/nixpkgs/doc/functions/library.xml b/nixpkgs/doc/functions/library.xml
index e6aedaa6efdd..6ffb944b5a60 100644
--- a/nixpkgs/doc/functions/library.xml
+++ b/nixpkgs/doc/functions/library.xml
@@ -5,8 +5,7 @@
  <title>Nixpkgs Library Functions</title>
 
  <para>
-  Nixpkgs provides a standard library at <varname>pkgs.lib</varname>, or
-  through <code>import &lt;nixpkgs/lib&gt;</code>.
+  Nixpkgs provides a standard library at <varname>pkgs.lib</varname>, or through <code>import &lt;nixpkgs/lib&gt;</code>.
  </para>
 
  <xi:include href="./library/asserts.xml" />
diff --git a/nixpkgs/doc/functions/library/asserts.xml b/nixpkgs/doc/functions/library/asserts.xml
index 437850e408bc..10891039e869 100644
--- a/nixpkgs/doc/functions/library/asserts.xml
+++ b/nixpkgs/doc/functions/library/asserts.xml
@@ -27,8 +27,7 @@
     </term>
     <listitem>
      <para>
-      Condition under which the <varname>msg</varname> should
-      <emphasis>not</emphasis> be printed.
+      Condition under which the <varname>msg</varname> should <emphasis>not</emphasis> be printed.
      </para>
     </listitem>
    </varlistentry>
@@ -64,9 +63,7 @@ stderr> assert failed
   <xi:include href="./locations.xml" xpointer="lib.asserts.assertOneOf" />
 
   <para>
-   Specialized <function>asserts.assertMsg</function> for checking if
-   <varname>val</varname> is one of the elements of <varname>xs</varname>.
-   Useful for checking enums.
+   Specialized <function>asserts.assertMsg</function> for checking if <varname>val</varname> is one of the elements of <varname>xs</varname>. Useful for checking enums.
   </para>
 
   <variablelist>
@@ -76,8 +73,7 @@ stderr> assert failed
     </term>
     <listitem>
      <para>
-      The name of the variable the user entered <varname>val</varname> into,
-      for inclusion in the error message.
+      The name of the variable the user entered <varname>val</varname> into, for inclusion in the error message.
      </para>
     </listitem>
    </varlistentry>
@@ -87,8 +83,7 @@ stderr> assert failed
     </term>
     <listitem>
      <para>
-      The value of what the user provided, to be compared against the values in
-      <varname>xs</varname>.
+      The value of what the user provided, to be compared against the values in <varname>xs</varname>.
      </para>
     </listitem>
    </varlistentry>
diff --git a/nixpkgs/doc/functions/library/attrsets.xml b/nixpkgs/doc/functions/library/attrsets.xml
index 65d0b40e2e82..f9234069392e 100644
--- a/nixpkgs/doc/functions/library/attrsets.xml
+++ b/nixpkgs/doc/functions/library/attrsets.xml
@@ -23,8 +23,7 @@
     </term>
     <listitem>
      <para>
-      A list of strings representing the path through the nested attribute set
-      <varname>set</varname>.
+      A list of strings representing the path through the nested attribute set <varname>set</varname>.
      </para>
     </listitem>
    </varlistentry>
@@ -34,8 +33,7 @@
     </term>
     <listitem>
      <para>
-      Default value if <varname>attrPath</varname> does not resolve to an
-      existing value.
+      Default value if <varname>attrPath</varname> does not resolve to an existing value.
      </para>
     </listitem>
    </varlistentry>
@@ -88,8 +86,7 @@ lib.attrsets.attrByPath [ "a" "b" ] 0 {}
     </term>
     <listitem>
      <para>
-      A list of strings representing the path through the nested attribute set
-      <varname>set</varname>.
+      A list of strings representing the path through the nested attribute set <varname>set</varname>.
      </para>
     </listitem>
    </varlistentry>
@@ -125,8 +122,7 @@ lib.attrsets.hasAttrByPath
   <xi:include href="./locations.xml" xpointer="lib.attrsets.setAttrByPath" />
 
   <para>
-   Create a new attribute set with <varname>value</varname> set at the nested
-   attribute location specified in <varname>attrPath</varname>.
+   Create a new attribute set with <varname>value</varname> set at the nested attribute location specified in <varname>attrPath</varname>.
   </para>
 
   <variablelist>
@@ -146,8 +142,7 @@ lib.attrsets.hasAttrByPath
     </term>
     <listitem>
      <para>
-      The value to set at the location described by
-      <varname>attrPath</varname>.
+      The value to set at the location described by <varname>attrPath</varname>.
      </para>
     </listitem>
    </varlistentry>
@@ -171,8 +166,7 @@ lib.attrsets.setAttrByPath [ "a" "b" ] 3
   <xi:include href="./locations.xml" xpointer="lib.attrsets.getAttrFromPath" />
 
   <para>
-   Like <xref linkend="function-library-lib.attrsets.attrByPath" /> except
-   without a default, and it will throw if the value doesn't exist.
+   Like <xref linkend="function-library-lib.attrsets.attrByPath" /> except without a default, and it will throw if the value doesn't exist.
   </para>
 
   <variablelist>
@@ -182,8 +176,7 @@ lib.attrsets.setAttrByPath [ "a" "b" ] 3
     </term>
     <listitem>
      <para>
-      A list of strings representing the path through the nested attribute set
-      <varname>set</varname>.
+      A list of strings representing the path through the nested attribute set <varname>set</varname>.
      </para>
     </listitem>
    </varlistentry>
@@ -235,8 +228,7 @@ lib.attrsets.getAttrFromPath [ "x" "y" ] { }
     </term>
     <listitem>
      <para>
-      The list of attributes to fetch from <varname>set</varname>. Each
-      attribute name must exist on the attrbitue set.
+      The list of attributes to fetch from <varname>set</varname>. Each attribute name must exist on the attrbitue set.
      </para>
     </listitem>
    </varlistentry>
@@ -282,8 +274,7 @@ error: attribute 'd' missing
   </para>
 
   <para>
-   Provides a backwards-compatible interface of
-   <function>builtins.attrValues</function> for Nix version older than 1.8.
+   Provides a backwards-compatible interface of <function>builtins.attrValues</function> for Nix version older than 1.8.
   </para>
 
   <variablelist>
@@ -317,14 +308,11 @@ lib.attrsets.attrValues { a = 1; b = 2; c = 3; }
   <xi:include href="./locations.xml" xpointer="lib.attrsets.catAttrs" />
 
   <para>
-   Collect each attribute named `attr' from the list of attribute sets,
-   <varname>sets</varname>. Sets that don't contain the named attribute are
-   ignored.
+   Collect each attribute named `attr' from the list of attribute sets, <varname>sets</varname>. Sets that don't contain the named attribute are ignored.
   </para>
 
   <para>
-   Provides a backwards-compatible interface of
-   <function>builtins.catAttrs</function> for Nix version older than 1.9.
+   Provides a backwards-compatible interface of <function>builtins.catAttrs</function> for Nix version older than 1.9.
   </para>
 
   <variablelist>
@@ -334,8 +322,7 @@ lib.attrsets.attrValues { a = 1; b = 2; c = 3; }
     </term>
     <listitem>
      <para>
-      Attribute name to select from each attribute set in
-      <varname>sets</varname>.
+      Attribute name to select from each attribute set in <varname>sets</varname>.
      </para>
     </listitem>
    </varlistentry>
@@ -372,8 +359,7 @@ catAttrs "a" [{a = 1;} {b = 0;} {a = 2;}]
   <xi:include href="./locations.xml" xpointer="lib.attrsets.filterAttrs" />
 
   <para>
-   Filter an attribute set by removing all attributes for which the given
-   predicate return false.
+   Filter an attribute set by removing all attributes for which the given predicate return false.
   </para>
 
   <variablelist>
@@ -386,8 +372,7 @@ catAttrs "a" [{a = 1;} {b = 0;} {a = 2;}]
       <literal>String -> Any -> Bool</literal>
      </para>
      <para>
-      Predicate which returns true to include an attribute, or returns false to
-      exclude it.
+      Predicate which returns true to include an attribute, or returns false to exclude it.
      </para>
      <variablelist>
       <varlistentry>
@@ -412,8 +397,7 @@ catAttrs "a" [{a = 1;} {b = 0;} {a = 2;}]
       </varlistentry>
      </variablelist>
      <para>
-      Returns <literal>true</literal> to include the attribute,
-      <literal>false</literal> to exclude the attribute.
+      Returns <literal>true</literal> to include the attribute, <literal>false</literal> to exclude the attribute.
      </para>
     </listitem>
    </varlistentry>
@@ -447,8 +431,7 @@ filterAttrs (n: v: n == "foo") { foo = 1; bar = 2; }
   <xi:include href="./locations.xml" xpointer="lib.attrsets.filterAttrsRecursive" />
 
   <para>
-   Filter an attribute set recursively by removing all attributes for which the
-   given predicate return false.
+   Filter an attribute set recursively by removing all attributes for which the given predicate return false.
   </para>
 
   <variablelist>
@@ -461,8 +444,7 @@ filterAttrs (n: v: n == "foo") { foo = 1; bar = 2; }
       <literal>String -> Any -> Bool</literal>
      </para>
      <para>
-      Predicate which returns true to include an attribute, or returns false to
-      exclude it.
+      Predicate which returns true to include an attribute, or returns false to exclude it.
      </para>
      <variablelist>
       <varlistentry>
@@ -487,8 +469,7 @@ filterAttrs (n: v: n == "foo") { foo = 1; bar = 2; }
       </varlistentry>
      </variablelist>
      <para>
-      Returns <literal>true</literal> to include the attribute,
-      <literal>false</literal> to exclude the attribute.
+      Returns <literal>true</literal> to include the attribute, <literal>false</literal> to exclude the attribute.
      </para>
     </listitem>
    </varlistentry>
@@ -557,8 +538,7 @@ lib.attrsets.filterAttrsRecursive
       <literal>Any -> Any -> Any</literal>
      </para>
      <para>
-      Given a value <varname>val</varname> and a collector
-      <varname>col</varname>, combine the two.
+      Given a value <varname>val</varname> and a collector <varname>col</varname>, combine the two.
      </para>
      <variablelist>
       <varlistentry>
@@ -578,8 +558,7 @@ lib.attrsets.filterAttrsRecursive
        <listitem>
 <!-- TODO: make this not bad, use more fold-ey terms -->
         <para>
-         The result of previous <function>op</function> calls with other values
-         and <function>nul</function>.
+         The result of previous <function>op</function> calls with other values and <function>nul</function>.
         </para>
        </listitem>
       </varlistentry>
@@ -632,9 +611,7 @@ lib.attrsets.foldAttrs
   <xi:include href="./locations.xml" xpointer="lib.attrsets.collect" />
 
   <para>
-   Recursively collect sets that verify a given predicate named
-   <varname>pred</varname> from the set <varname>attrs</varname>. The recursion
-   stops when <varname>pred</varname> returns <literal>true</literal>.
+   Recursively collect sets that verify a given predicate named <varname>pred</varname> from the set <varname>attrs</varname>. The recursion stops when <varname>pred</varname> returns <literal>true</literal>.
   </para>
 
   <variablelist>
@@ -702,8 +679,7 @@ collect (x: x ? outPath)
   <xi:include href="./locations.xml" xpointer="lib.attrsets.nameValuePair" />
 
   <para>
-   Utility function that creates a <literal>{name, value}</literal> pair as
-   expected by <function>builtins.listToAttrs</function>.
+   Utility function that creates a <literal>{name, value}</literal> pair as expected by <function>builtins.listToAttrs</function>.
   </para>
 
   <variablelist>
@@ -747,13 +723,11 @@ nameValuePair "some" 6
   <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrs" />
 
   <para>
-   Apply a function to each element in an attribute set, creating a new
-   attribute set.
+   Apply a function to each element in an attribute set, creating a new attribute set.
   </para>
 
   <para>
-   Provides a backwards-compatible interface of
-   <function>builtins.mapAttrs</function> for Nix version older than 2.1.
+   Provides a backwards-compatible interface of <function>builtins.mapAttrs</function> for Nix version older than 2.1.
   </para>
 
   <variablelist>
@@ -814,9 +788,7 @@ lib.attrsets.mapAttrs
   <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrs-prime" />
 
   <para>
-   Like <function>mapAttrs</function>, but allows the name of each attribute to
-   be changed in addition to the value. The applied function should return both
-   the new name and value as a <function>nameValuePair</function>.
+   Like <function>mapAttrs</function>, but allows the name of each attribute to be changed in addition to the value. The applied function should return both the new name and value as a <function>nameValuePair</function>.
   </para>
 
   <variablelist>
@@ -829,10 +801,8 @@ lib.attrsets.mapAttrs
       <literal>String -> Any -> { name = String; value = Any }</literal>
      </para>
      <para>
-      Given an attribute's name and value, return a new
-      <link
-       linkend="function-library-lib.attrsets.nameValuePair">name
-      value pair</link>.
+      Given an attribute's name and value, return a new <link
+       linkend="function-library-lib.attrsets.nameValuePair">name value pair</link>.
      </para>
      <variablelist>
       <varlistentry>
@@ -891,8 +861,7 @@ lib.attrsets.mapAttrs' (name: value: lib.attrsets.nameValuePair ("foo_" + name)
   <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrsToList" />
 
   <para>
-   Call <varname>fn</varname> for each attribute in the given
-   <varname>set</varname> and return the result in a list.
+   Call <varname>fn</varname> for each attribute in the given <varname>set</varname> and return the result in a list.
   </para>
 
   <variablelist>
@@ -962,9 +931,7 @@ lib.attrsets.mapAttrsToList (name: value: "${name}=${value}")
   <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrsRecursive" />
 
   <para>
-   Like <function>mapAttrs</function>, except that it recursively applies
-   itself to attribute sets. Also, the first argument of the argument function
-   is a <emphasis>list</emphasis> of the names of the containing attributes.
+   Like <function>mapAttrs</function>, except that it recursively applies itself to attribute sets. Also, the first argument of the argument function is a <emphasis>list</emphasis> of the names of the containing attributes.
   </para>
 
   <variablelist>
@@ -989,10 +956,7 @@ lib.attrsets.mapAttrsToList (name: value: "${name}=${value}")
          The list of attribute names to this value.
         </para>
         <para>
-         For example, the <varname>name_path</varname> for the
-         <literal>example</literal> string in the attribute set <literal>{ foo
-         = { bar = "example"; }; }</literal> is <literal>[ "foo" "bar"
-         ]</literal>.
+         For example, the <varname>name_path</varname> for the <literal>example</literal> string in the attribute set <literal>{ foo = { bar = "example"; }; }</literal> is <literal>[ "foo" "bar" ]</literal>.
         </para>
        </listitem>
       </varlistentry>
@@ -1059,11 +1023,7 @@ mapAttrsRecursive
   <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrsRecursiveCond" />
 
   <para>
-   Like <function>mapAttrsRecursive</function>, but it takes an additional
-   predicate function that tells it whether to recursive into an attribute set.
-   If it returns false, <function>mapAttrsRecursiveCond</function> does not
-   recurse, but does apply the map function. It is returns true, it does
-   recurse, and does not apply the map function.
+   Like <function>mapAttrsRecursive</function>, but it takes an additional predicate function that tells it whether to recursive into an attribute set. If it returns false, <function>mapAttrsRecursiveCond</function> does not recurse, but does apply the map function. It is returns true, it does recurse, and does not apply the map function.
   </para>
 
   <variablelist>
@@ -1076,8 +1036,7 @@ mapAttrsRecursive
       <literal>(AttrSet -> Bool)</literal>
      </para>
      <para>
-      Determine if <function>mapAttrsRecursive</function> should recurse deeper
-      in to the attribute set.
+      Determine if <function>mapAttrsRecursive</function> should recurse deeper in to the attribute set.
      </para>
      <variablelist>
       <varlistentry>
@@ -1114,10 +1073,7 @@ mapAttrsRecursive
          The list of attribute names to this value.
         </para>
         <para>
-         For example, the <varname>name_path</varname> for the
-         <literal>example</literal> string in the attribute set <literal>{ foo
-         = { bar = "example"; }; }</literal> is <literal>[ "foo" "bar"
-         ]</literal>.
+         For example, the <varname>name_path</varname> for the <literal>example</literal> string in the attribute set <literal>{ foo = { bar = "example"; }; }</literal> is <literal>[ "foo" "bar" ]</literal>.
         </para>
        </listitem>
       </varlistentry>
@@ -1181,8 +1137,7 @@ lib.attrsets.mapAttrsRecursiveCond
   <xi:include href="./locations.xml" xpointer="lib.attrsets.genAttrs" />
 
   <para>
-   Generate an attribute set by mapping a function over a list of attribute
-   names.
+   Generate an attribute set by mapping a function over a list of attribute names.
   </para>
 
   <variablelist>
@@ -1241,8 +1196,7 @@ lib.attrsets.genAttrs [ "foo" "bar" ] (name: "x_${name}")
   <xi:include href="./locations.xml" xpointer="lib.attrsets.isDerivation" />
 
   <para>
-   Check whether the argument is a derivation. Any set with <code>{ type =
-   "derivation"; }</code> counts as a derivation.
+   Check whether the argument is a derivation. Any set with <code>{ type = "derivation"; }</code> counts as a derivation.
   </para>
 
   <variablelist>
@@ -1320,8 +1274,7 @@ lib.attrsets.isDerivation "foobar"
     </term>
     <listitem>
      <para>
-      Condition under which the <varname>as</varname> attribute set is
-      returned.
+      Condition under which the <varname>as</varname> attribute set is returned.
      </para>
     </listitem>
    </varlistentry>
@@ -1363,8 +1316,7 @@ lib.attrsets.optionalAttrs false { my = "set"; }
   <xi:include href="./locations.xml" xpointer="lib.attrsets.zipAttrsWithNames" />
 
   <para>
-   Merge sets of attributes and use the function <varname>f</varname> to merge
-   attribute values where the attribute name is in <varname>names</varname>.
+   Merge sets of attributes and use the function <varname>f</varname> to merge attribute values where the attribute name is in <varname>names</varname>.
   </para>
 
   <variablelist>
@@ -1451,11 +1403,8 @@ lib.attrsets.zipAttrsWithNames
   <xi:include href="./locations.xml" xpointer="lib.attrsets.zipAttrsWith" />
 
   <para>
-   Merge sets of attributes and use the function <varname>f</varname> to merge
-   attribute values. Similar to
-   <xref
-   linkend="function-library-lib.attrsets.zipAttrsWithNames" /> where
-   all key names are passed for <varname>names</varname>.
+   Merge sets of attributes and use the function <varname>f</varname> to merge attribute values. Similar to <xref
+   linkend="function-library-lib.attrsets.zipAttrsWithNames" /> where all key names are passed for <varname>names</varname>.
   </para>
 
   <variablelist>
@@ -1531,9 +1480,7 @@ lib.attrsets.zipAttrsWith
   <xi:include href="./locations.xml" xpointer="lib.attrsets.zipAttrs" />
 
   <para>
-   Merge sets of attributes and combine each attribute value in to a list.
-   Similar to <xref linkend="function-library-lib.attrsets.zipAttrsWith" />
-   where the merge function returns a list of all values.
+   Merge sets of attributes and combine each attribute value in to a list. Similar to <xref linkend="function-library-lib.attrsets.zipAttrsWith" /> where the merge function returns a list of all values.
   </para>
 
   <variablelist>
@@ -1573,12 +1520,7 @@ lib.attrsets.zipAttrs
   <xi:include href="./locations.xml" xpointer="lib.attrsets.recursiveUpdateUntil" />
 
   <para>
-   Does the same as the update operator <literal>//</literal> except that
-   attributes are merged until the given predicate is verified. The predicate
-   should accept 3 arguments which are the path to reach the attribute, a part
-   of the first attribute set and a part of the second attribute set. When the
-   predicate is verified, the value of the first attribute set is replaced by
-   the value of the second attribute set.
+   Does the same as the update operator <literal>//</literal> except that attributes are merged until the given predicate is verified. The predicate should accept 3 arguments which are the path to reach the attribute, a part of the first attribute set and a part of the second attribute set. When the predicate is verified, the value of the first attribute set is replaced by the value of the second attribute set.
   </para>
 
   <variablelist>
@@ -1681,10 +1623,7 @@ lib.attrsets.recursiveUpdateUntil (path: l: r: path == ["foo"])
   <xi:include href="./locations.xml" xpointer="lib.attrsets.recursiveUpdate" />
 
   <para>
-   A recursive variant of the update operator <literal>//</literal>. The
-   recursion stops when one of the attribute values is not an attribute set, in
-   which case the right hand side value takes precedence over the left hand
-   side value.
+   A recursive variant of the update operator <literal>//</literal>. The recursion stops when one of the attribute values is not an attribute set, in which case the right hand side value takes precedence over the left hand side value.
   </para>
 
   <variablelist>
diff --git a/nixpkgs/doc/functions/nix-gitignore.xml b/nixpkgs/doc/functions/nix-gitignore.xml
index 9011570d1eae..37a82b196ccf 100644
--- a/nixpkgs/doc/functions/nix-gitignore.xml
+++ b/nixpkgs/doc/functions/nix-gitignore.xml
@@ -5,21 +5,14 @@
  <title>pkgs.nix-gitignore</title>
 
  <para>
-  <function>pkgs.nix-gitignore</function> is a function that acts similarly to
-  <literal>builtins.filterSource</literal> but also allows filtering with the
-  help of the gitignore format.
+  <function>pkgs.nix-gitignore</function> is a function that acts similarly to <literal>builtins.filterSource</literal> but also allows filtering with the help of the gitignore format.
  </para>
 
  <section xml:id="sec-pkgs-nix-gitignore-usage">
   <title>Usage</title>
 
   <para>
-   <literal>pkgs.nix-gitignore</literal> exports a number of functions, but
-   you'll most likely need either <literal>gitignoreSource</literal> or
-   <literal>gitignoreSourcePure</literal>. As their first argument, they both
-   accept either 1. a file with gitignore lines or 2. a string with gitignore
-   lines, or 3. a list of either of the two. They will be concatenated into a
-   single big string.
+   <literal>pkgs.nix-gitignore</literal> exports a number of functions, but you'll most likely need either <literal>gitignoreSource</literal> or <literal>gitignoreSourcePure</literal>. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
   </para>
 
 <programlisting><![CDATA[
@@ -40,8 +33,7 @@
   ]]></programlisting>
 
   <para>
-   These functions are derived from the <literal>Filter</literal> functions by
-   setting the first filter argument to <literal>(_: _: true)</literal>:
+   These functions are derived from the <literal>Filter</literal> functions by setting the first filter argument to <literal>(_: _: true)</literal>:
   </para>
 
 <programlisting><![CDATA[
@@ -50,12 +42,7 @@ gitignoreSource = gitignoreFilterSource (_: _: true);
   ]]></programlisting>
 
   <para>
-   Those filter functions accept the same arguments the
-   <literal>builtins.filterSource</literal> function would pass to its filters,
-   thus <literal>fn: gitignoreFilterSourcePure fn ""</literal> should be
-   extensionally equivalent to <literal>filterSource</literal>. The file is
-   blacklisted iff it's blacklisted by either your filter or the
-   gitignoreFilter.
+   Those filter functions accept the same arguments the <literal>builtins.filterSource</literal> function would pass to its filters, thus <literal>fn: gitignoreFilterSourcePure fn ""</literal> should be extensionally equivalent to <literal>filterSource</literal>. The file is blacklisted iff it's blacklisted by either your filter or the gitignoreFilter.
   </para>
 
   <para>
@@ -71,8 +58,7 @@ gitignoreFilter = ign: root: filterPattern (gitignoreToPatterns ign) root;
   <title>gitignore files in subdirectories</title>
 
   <para>
-   If you wish to use a filter that would search for .gitignore files in
-   subdirectories, just like git does by default, use this function:
+   If you wish to use a filter that would search for .gitignore files in subdirectories, just like git does by default, use this function:
   </para>
 
 <programlisting><![CDATA[
diff --git a/nixpkgs/doc/functions/ocitools.xml b/nixpkgs/doc/functions/ocitools.xml
index 4500c41a34ae..f61075b242f8 100644
--- a/nixpkgs/doc/functions/ocitools.xml
+++ b/nixpkgs/doc/functions/ocitools.xml
@@ -5,36 +5,28 @@
  <title>pkgs.ociTools</title>
 
  <para>
-  <varname>pkgs.ociTools</varname> is a set of functions for creating
-  containers according to the
-  <link xlink:href="https://github.com/opencontainers/runtime-spec">OCI
-  container specification v1.0.0</link>. Beyond that it makes no assumptions
-  about the container runner you choose to use to run the created container.
+  <varname>pkgs.ociTools</varname> is a set of functions for creating containers according to the <link xlink:href="https://github.com/opencontainers/runtime-spec">OCI container specification v1.0.0</link>. Beyond that it makes no assumptions about the container runner you choose to use to run the created container.
  </para>
 
  <section xml:id="ssec-pkgs-ociTools-buildContainer">
   <title>buildContainer</title>
 
   <para>
-   This function creates a simple OCI container that runs a single command
-   inside of it. An OCI container consists of a <varname>config.json</varname>
-   and a rootfs directory.The nix store of the container will contain all
-   referenced dependencies of the given command.
+   This function creates a simple OCI container that runs a single command inside of it. An OCI container consists of a <varname>config.json</varname> and a rootfs directory.The nix store of the container will contain all referenced dependencies of the given command.
   </para>
 
   <para>
-   The parameters of <varname>buildContainer</varname> with an example value
-   are described below:
+   The parameters of <varname>buildContainer</varname> with an example value are described below:
   </para>
 
   <example xml:id='ex-ociTools-buildContainer'>
    <title>Build Container</title>
 <programlisting>
 buildContainer {
-  cmd = with pkgs; writeScript "run.sh" ''
+  args = [ (with pkgs; writeScript "run.sh" ''
     #!${bash}/bin/bash
     ${coreutils}/bin/exec ${bash}/bin/bash
-  ''; <co xml:id='ex-ociTools-buildContainer-1' />
+  '').outPath ]; <co xml:id='ex-ociTools-buildContainer-1' />
 
   mounts = {
     "/data" = {
@@ -51,23 +43,17 @@ buildContainer {
    <calloutlist>
     <callout arearefs='ex-ociTools-buildContainer-1'>
      <para>
-      <varname>cmd</varname> specifies the program to run inside the container.
-      This is the only required argument for <varname>buildContainer</varname>.
-      All referenced packages inside the derivation will be made available
-      inside the container
+      <varname>args</varname> specifies a set of arguments to run inside the container. This is the only required argument for <varname>buildContainer</varname>. All referenced packages inside the derivation will be made available inside the container
      </para>
     </callout>
     <callout arearefs='ex-ociTools-buildContainer-2'>
      <para>
-      <varname>mounts</varname> specifies additional mount points chosen by the
-      user. By default only a minimal set of necessary filesystems are mounted
-      into the container (e.g procfs, cgroupfs)
+      <varname>mounts</varname> specifies additional mount points chosen by the user. By default only a minimal set of necessary filesystems are mounted into the container (e.g procfs, cgroupfs)
      </para>
     </callout>
     <callout arearefs='ex-ociTools-buildContainer-3'>
      <para>
-       <varname>readonly</varname> makes the container's rootfs read-only if it is set to true.
-       The default value is false <literal>false</literal>.
+      <varname>readonly</varname> makes the container's rootfs read-only if it is set to true. The default value is false <literal>false</literal>.
      </para>
     </callout>
    </calloutlist>
diff --git a/nixpkgs/doc/functions/overrides.xml b/nixpkgs/doc/functions/overrides.xml
index 1bd90d2a0c76..4ba4283c6094 100644
--- a/nixpkgs/doc/functions/overrides.xml
+++ b/nixpkgs/doc/functions/overrides.xml
@@ -5,23 +5,18 @@
  <title>Overriding</title>
 
  <para>
-  Sometimes one wants to override parts of <literal>nixpkgs</literal>, e.g.
-  derivation attributes, the results of derivations.
+  Sometimes one wants to override parts of <literal>nixpkgs</literal>, e.g. derivation attributes, the results of derivations.
  </para>
 
  <para>
-  These functions are used to make changes to packages, returning only single
-  packages. <link xlink:href="#chap-overlays">Overlays</link>, on the other
-  hand, can be used to combine the overridden packages across the entire
-  package set of Nixpkgs.
+  These functions are used to make changes to packages, returning only single packages. <link xlink:href="#chap-overlays">Overlays</link>, on the other hand, can be used to combine the overridden packages across the entire package set of Nixpkgs.
  </para>
 
  <section xml:id="sec-pkg-override">
   <title>&lt;pkg&gt;.override</title>
 
   <para>
-   The function <varname>override</varname> is usually available for all the
-   derivations in the nixpkgs expression (<varname>pkgs</varname>).
+   The function <varname>override</varname> is usually available for all the derivations in the nixpkgs expression (<varname>pkgs</varname>).
   </para>
 
   <para>
@@ -47,10 +42,7 @@ mypkg = pkgs.callPackage ./mypkg.nix {
   </para>
 
   <para>
-   In the first example, <varname>pkgs.foo</varname> is the result of a
-   function call with some default arguments, usually a derivation. Using
-   <varname>pkgs.foo.override</varname> will call the same function with the
-   given new arguments.
+   In the first example, <varname>pkgs.foo</varname> is the result of a function call with some default arguments, usually a derivation. Using <varname>pkgs.foo.override</varname> will call the same function with the given new arguments.
   </para>
  </section>
 
@@ -58,12 +50,7 @@ mypkg = pkgs.callPackage ./mypkg.nix {
   <title>&lt;pkg&gt;.overrideAttrs</title>
 
   <para>
-   The function <varname>overrideAttrs</varname> allows overriding the
-   attribute set passed to a <varname>stdenv.mkDerivation</varname> call,
-   producing a new derivation based on the original one. This function is
-   available on all derivations produced by the
-   <varname>stdenv.mkDerivation</varname> function, which is most packages in
-   the nixpkgs expression <varname>pkgs</varname>.
+   The function <varname>overrideAttrs</varname> allows overriding the attribute set passed to a <varname>stdenv.mkDerivation</varname> call, producing a new derivation based on the original one. This function is available on all derivations produced by the <varname>stdenv.mkDerivation</varname> function, which is most packages in the nixpkgs expression <varname>pkgs</varname>.
   </para>
 
   <para>
@@ -76,30 +63,16 @@ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
   </para>
 
   <para>
-   In the above example, the <varname>separateDebugInfo</varname> attribute is
-   overridden to be true, thus building debug info for
-   <varname>helloWithDebug</varname>, while all other attributes will be
-   retained from the original <varname>hello</varname> package.
+   In the above example, the <varname>separateDebugInfo</varname> attribute is overridden to be true, thus building debug info for <varname>helloWithDebug</varname>, while all other attributes will be retained from the original <varname>hello</varname> package.
   </para>
 
   <para>
-   The argument <varname>oldAttrs</varname> is conventionally used to refer to
-   the attr set originally passed to <varname>stdenv.mkDerivation</varname>.
+   The argument <varname>oldAttrs</varname> is conventionally used to refer to the attr set originally passed to <varname>stdenv.mkDerivation</varname>.
   </para>
 
   <note>
    <para>
-    Note that <varname>separateDebugInfo</varname> is processed only by the
-    <varname>stdenv.mkDerivation</varname> function, not the generated, raw Nix
-    derivation. Thus, using <varname>overrideDerivation</varname> will not work
-    in this case, as it overrides only the attributes of the final derivation.
-    It is for this reason that <varname>overrideAttrs</varname> should be
-    preferred in (almost) all cases to <varname>overrideDerivation</varname>,
-    i.e. to allow using <varname>stdenv.mkDerivation</varname> to process input
-    arguments, as well as the fact that it is easier to use (you can use the
-    same attribute names you see in your Nix code, instead of the ones
-    generated (e.g. <varname>buildInputs</varname> vs
-    <varname>nativeBuildInputs</varname>), and it involves less typing).
+    Note that <varname>separateDebugInfo</varname> is processed only by the <varname>stdenv.mkDerivation</varname> function, not the generated, raw Nix derivation. Thus, using <varname>overrideDerivation</varname> will not work in this case, as it overrides only the attributes of the final derivation. It is for this reason that <varname>overrideAttrs</varname> should be preferred in (almost) all cases to <varname>overrideDerivation</varname>, i.e. to allow using <varname>stdenv.mkDerivation</varname> to process input arguments, as well as the fact that it is easier to use (you can use the same attribute names you see in your Nix code, instead of the ones generated (e.g. <varname>buildInputs</varname> vs <varname>nativeBuildInputs</varname>), and it involves less typing).
    </para>
   </note>
  </section>
@@ -109,34 +82,18 @@ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
 
   <warning>
    <para>
-    You should prefer <varname>overrideAttrs</varname> in almost all cases, see
-    its documentation for the reasons why.
-    <varname>overrideDerivation</varname> is not deprecated and will continue
-    to work, but is less nice to use and does not have as many abilities as
-    <varname>overrideAttrs</varname>.
+    You should prefer <varname>overrideAttrs</varname> in almost all cases, see its documentation for the reasons why. <varname>overrideDerivation</varname> is not deprecated and will continue to work, but is less nice to use and does not have as many abilities as <varname>overrideAttrs</varname>.
    </para>
   </warning>
 
   <warning>
    <para>
-    Do not use this function in Nixpkgs as it evaluates a Derivation before
-    modifying it, which breaks package abstraction and removes error-checking
-    of function arguments. In addition, this evaluation-per-function
-    application incurs a performance penalty, which can become a problem if
-    many overrides are used. It is only intended for ad-hoc customisation, such
-    as in <filename>~/.config/nixpkgs/config.nix</filename>.
+    Do not use this function in Nixpkgs as it evaluates a Derivation before modifying it, which breaks package abstraction and removes error-checking of function arguments. In addition, this evaluation-per-function application incurs a performance penalty, which can become a problem if many overrides are used. It is only intended for ad-hoc customisation, such as in <filename>~/.config/nixpkgs/config.nix</filename>.
    </para>
   </warning>
 
   <para>
-   The function <varname>overrideDerivation</varname> creates a new derivation
-   based on an existing one by overriding the original's attributes with the
-   attribute set produced by the specified function. This function is available
-   on all derivations defined using the <varname>makeOverridable</varname>
-   function. Most standard derivation-producing functions, such as
-   <varname>stdenv.mkDerivation</varname>, are defined using this function,
-   which means most packages in the nixpkgs expression,
-   <varname>pkgs</varname>, have this function.
+   The function <varname>overrideDerivation</varname> creates a new derivation based on an existing one by overriding the original's attributes with the attribute set produced by the specified function. This function is available on all derivations defined using the <varname>makeOverridable</varname> function. Most standard derivation-producing functions, such as <varname>stdenv.mkDerivation</varname>, are defined using this function, which means most packages in the nixpkgs expression, <varname>pkgs</varname>, have this function.
   </para>
 
   <para>
@@ -154,27 +111,16 @@ mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
   </para>
 
   <para>
-   In the above example, the <varname>name</varname>, <varname>src</varname>,
-   and <varname>patches</varname> of the derivation will be overridden, while
-   all other attributes will be retained from the original derivation.
+   In the above example, the <varname>name</varname>, <varname>src</varname>, and <varname>patches</varname> of the derivation will be overridden, while all other attributes will be retained from the original derivation.
   </para>
 
   <para>
-   The argument <varname>oldAttrs</varname> is used to refer to the attribute
-   set of the original derivation.
+   The argument <varname>oldAttrs</varname> is used to refer to the attribute set of the original derivation.
   </para>
 
   <note>
    <para>
-    A package's attributes are evaluated *before* being modified by the
-    <varname>overrideDerivation</varname> function. For example, the
-    <varname>name</varname> attribute reference in <varname>url =
-    "mirror://gnu/hello/${name}.tar.gz";</varname> is filled-in *before* the
-    <varname>overrideDerivation</varname> function modifies the attribute set.
-    This means that overriding the <varname>name</varname> attribute, in this
-    example, *will not* change the value of the <varname>url</varname>
-    attribute. Instead, we need to override both the <varname>name</varname>
-    *and* <varname>url</varname> attributes.
+    A package's attributes are evaluated *before* being modified by the <varname>overrideDerivation</varname> function. For example, the <varname>name</varname> attribute reference in <varname>url = "mirror://gnu/hello/${name}.tar.gz";</varname> is filled-in *before* the <varname>overrideDerivation</varname> function modifies the attribute set. This means that overriding the <varname>name</varname> attribute, in this example, *will not* change the value of the <varname>url</varname> attribute. Instead, we need to override both the <varname>name</varname> *and* <varname>url</varname> attributes.
    </para>
   </note>
  </section>
@@ -183,9 +129,7 @@ mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
   <title>lib.makeOverridable</title>
 
   <para>
-   The function <varname>lib.makeOverridable</varname> is used to make the
-   result of a function easily customizable. This utility only makes sense for
-   functions that accept an argument set and return an attribute set.
+   The function <varname>lib.makeOverridable</varname> is used to make the result of a function easily customizable. This utility only makes sense for functions that accept an argument set and return an attribute set.
   </para>
 
   <para>
@@ -197,16 +141,11 @@ c = lib.makeOverridable f { a = 1; b = 2; };
   </para>
 
   <para>
-   The variable <varname>c</varname> is the value of the <varname>f</varname>
-   function applied with some default arguments. Hence the value of
-   <varname>c.result</varname> is <literal>3</literal>, in this example.
+   The variable <varname>c</varname> is the value of the <varname>f</varname> function applied with some default arguments. Hence the value of <varname>c.result</varname> is <literal>3</literal>, in this example.
   </para>
 
   <para>
-   The variable <varname>c</varname> however also has some additional
-   functions, like <link linkend="sec-pkg-override">c.override</link> which can
-   be used to override the default arguments. In this example the value of
-   <varname>(c.override { a = 4; }).result</varname> is 6.
+   The variable <varname>c</varname> however also has some additional functions, like <link linkend="sec-pkg-override">c.override</link> which can be used to override the default arguments. In this example the value of <varname>(c.override { a = 4; }).result</varname> is 6.
   </para>
  </section>
 </section>
diff --git a/nixpkgs/doc/functions/prefer-remote-fetch.xml b/nixpkgs/doc/functions/prefer-remote-fetch.xml
index 3e43fd28ade8..94d25d3d3aeb 100644
--- a/nixpkgs/doc/functions/prefer-remote-fetch.xml
+++ b/nixpkgs/doc/functions/prefer-remote-fetch.xml
@@ -5,16 +5,12 @@
  <title>prefer-remote-fetch overlay</title>
 
  <para>
-  <function>prefer-remote-fetch</function> is an overlay that download sources
-  on remote builder. This is useful when the evaluating machine has a slow
-  upload while the builder can fetch faster directly from the source. To use
-  it, put the following snippet as a new overlay:
+  <function>prefer-remote-fetch</function> is an overlay that download sources on remote builder. This is useful when the evaluating machine has a slow upload while the builder can fetch faster directly from the source. To use it, put the following snippet as a new overlay:
 <programlisting>
 self: super:
   (super.prefer-remote-fetch self super)
 </programlisting>
-  A full configuration example for that sets the overlay up for your own
-  account, could look like this
+  A full configuration example for that sets the overlay up for your own account, could look like this
 <screen>
 <prompt>$ </prompt>mkdir ~/.config/nixpkgs/overlays/
 <prompt>$ </prompt>cat &gt; ~/.config/nixpkgs/overlays/prefer-remote-fetch.nix &lt;&lt;EOF
diff --git a/nixpkgs/doc/functions/shell.xml b/nixpkgs/doc/functions/shell.xml
index e5031c9463c0..cef65d06b882 100644
--- a/nixpkgs/doc/functions/shell.xml
+++ b/nixpkgs/doc/functions/shell.xml
@@ -5,9 +5,7 @@
  <title>pkgs.mkShell</title>
 
  <para>
-  <function>pkgs.mkShell</function> is a special kind of derivation that is
-  only useful when using it combined with <command>nix-shell</command>. It will
-  in fact fail to instantiate when invoked with <command>nix-build</command>.
+  <function>pkgs.mkShell</function> is a special kind of derivation that is only useful when using it combined with <command>nix-shell</command>. It will in fact fail to instantiate when invoked with <command>nix-build</command>.
  </para>
 
  <section xml:id="sec-pkgs-mkShell-usage">
diff --git a/nixpkgs/doc/functions/snaptools.xml b/nixpkgs/doc/functions/snaptools.xml
index d0e3efdf6c67..422fcfa37d88 100644
--- a/nixpkgs/doc/functions/snaptools.xml
+++ b/nixpkgs/doc/functions/snaptools.xml
@@ -5,28 +5,22 @@
  <title>pkgs.snapTools</title>
 
  <para>
-  <varname>pkgs.snapTools</varname> is a set of functions for creating
-  Snapcraft images. Snap and Snapcraft is not used to perform these operations.
+  <varname>pkgs.snapTools</varname> is a set of functions for creating Snapcraft images. Snap and Snapcraft is not used to perform these operations.
  </para>
 
  <section xml:id="ssec-pkgs-snapTools-makeSnap-signature">
   <title>The makeSnap Function</title>
 
   <para>
-   <function>makeSnap</function> takes a single named argument,
-   <parameter>meta</parameter>. This argument mirrors
-   <link xlink:href="https://docs.snapcraft.io/snap-format">the upstream
-   <filename>snap.yaml</filename> format</link> exactly.
+   <function>makeSnap</function> takes a single named argument, <parameter>meta</parameter>. This argument mirrors <link xlink:href="https://docs.snapcraft.io/snap-format">the upstream <filename>snap.yaml</filename> format</link> exactly.
   </para>
 
   <para>
-   The <parameter>base</parameter> should not be be specified, as
-   <function>makeSnap</function> will force set it.
+   The <parameter>base</parameter> should not be be specified, as <function>makeSnap</function> will force set it.
   </para>
 
   <para>
-   Currently, <function>makeSnap</function> does not support creating GUI
-   stubs.
+   Currently, <function>makeSnap</function> does not support creating GUI stubs.
   </para>
  </section>
 
@@ -40,9 +34,7 @@
    </para>
 <programlisting><xi:include href="./snap/example-hello.nix" parse="text" /></programlisting>
    <para>
-    <command>nix-build</command> this expression and install it with
-    <command>snap install ./result --dangerous</command>.
-    <command>hello</command> will now be the Snapcraft version of the package.
+    <command>nix-build</command> this expression and install it with <command>snap install ./result --dangerous</command>. <command>hello</command> will now be the Snapcraft version of the package.
    </para>
   </example>
  </section>
@@ -53,21 +45,14 @@
   <example xml:id="ex-snapTools-buildSnap-firefox">
    <title>Making a Graphical Snap</title>
    <para>
-    Graphical programs require many more integrations with the host. This
-    example uses Firefox as an example, because it is one of the most
-    complicated programs we could package.
+    Graphical programs require many more integrations with the host. This example uses Firefox as an example, because it is one of the most complicated programs we could package.
    </para>
 <programlisting><xi:include href="./snap/example-firefox.nix" parse="text" /></programlisting>
    <para>
-    <command>nix-build</command> this expression and install it with
-    <command>snap install ./result --dangerous</command>.
-    <command>nix-example-firefox</command> will now be the Snapcraft version of
-    the Firefox package.
+    <command>nix-build</command> this expression and install it with <command>snap install ./result --dangerous</command>. <command>nix-example-firefox</command> will now be the Snapcraft version of the Firefox package.
    </para>
    <para>
-    The specific meaning behind plugs can be looked up in the
-    <link xlink:href="https://docs.snapcraft.io/supported-interfaces">Snapcraft
-    interface documentation</link>.
+    The specific meaning behind plugs can be looked up in the <link xlink:href="https://docs.snapcraft.io/supported-interfaces">Snapcraft interface documentation</link>.
    </para>
   </example>
  </section>
diff --git a/nixpkgs/doc/functions/trivial-builders.xml b/nixpkgs/doc/functions/trivial-builders.xml
index 0211a4f31728..ae9f3a1b255d 100644
--- a/nixpkgs/doc/functions/trivial-builders.xml
+++ b/nixpkgs/doc/functions/trivial-builders.xml
@@ -5,11 +5,7 @@
  <title>Trivial builders</title>
 
  <para>
-  Nixpkgs provides a couple of functions that help with building derivations.
-  The most important one, <function>stdenv.mkDerivation</function>, has already
-  been documented above. The following functions wrap
-  <function>stdenv.mkDerivation</function>, making it easier to use in certain
-  cases.
+  Nixpkgs provides a couple of functions that help with building derivations. The most important one, <function>stdenv.mkDerivation</function>, has already been documented above. The following functions wrap <function>stdenv.mkDerivation</function>, making it easier to use in certain cases.
  </para>
 
  <variablelist>
@@ -19,17 +15,7 @@
    </term>
    <listitem>
     <para>
-     This takes three arguments, <literal>name</literal>,
-     <literal>env</literal>, and <literal>buildCommand</literal>.
-     <literal>name</literal> is just the name that Nix will append to the store
-     path in the same way that <literal>stdenv.mkDerivation</literal> uses its
-     <literal>name</literal> attribute. <literal>env</literal> is an attribute
-     set specifying environment variables that will be set for this derivation.
-     These attributes are then passed to the wrapped
-     <literal>stdenv.mkDerivation</literal>. <literal>buildCommand</literal>
-     specifies the commands that will be run to create this derivation. Note
-     that you will need to create <literal>$out</literal> for Nix to register
-     the command as successful.
+     This takes three arguments, <literal>name</literal>, <literal>env</literal>, and <literal>buildCommand</literal>. <literal>name</literal> is just the name that Nix will append to the store path in the same way that <literal>stdenv.mkDerivation</literal> uses its <literal>name</literal> attribute. <literal>env</literal> is an attribute set specifying environment variables that will be set for this derivation. These attributes are then passed to the wrapped <literal>stdenv.mkDerivation</literal>. <literal>buildCommand</literal> specifies the commands that will be run to create this derivation. Note that you will need to create <literal>$out</literal> for Nix to register the command as successful.
     </para>
     <para>
      An example of using <literal>runCommand</literal> is provided below.
@@ -62,10 +48,7 @@
    </term>
    <listitem>
     <para>
-     This works just like <literal>runCommand</literal>. The only difference is
-     that it also provides a C compiler in <literal>buildCommand</literal>’s
-     environment. To minimize your dependencies, you should only use this if
-     you are sure you will need a C compiler as part of running your command.
+     This works just like <literal>runCommand</literal>. The only difference is that it also provides a C compiler in <literal>buildCommand</literal>’s environment. To minimize your dependencies, you should only use this if you are sure you will need a C compiler as part of running your command.
     </para>
    </listitem>
   </varlistentry>
@@ -75,20 +58,10 @@
    </term>
    <listitem>
     <para>
-     These functions write <literal>text</literal> to the Nix store. This is
-     useful for creating scripts from Nix expressions.
-     <literal>writeTextFile</literal> takes an attribute set and expects two
-     arguments, <literal>name</literal> and <literal>text</literal>.
-     <literal>name</literal> corresponds to the name used in the Nix store
-     path. <literal>text</literal> will be the contents of the file. You can
-     also set <literal>executable</literal> to true to make this file have the
-     executable bit set.
+     These functions write <literal>text</literal> to the Nix store. This is useful for creating scripts from Nix expressions. <literal>writeTextFile</literal> takes an attribute set and expects two arguments, <literal>name</literal> and <literal>text</literal>. <literal>name</literal> corresponds to the name used in the Nix store path. <literal>text</literal> will be the contents of the file. You can also set <literal>executable</literal> to true to make this file have the executable bit set.
     </para>
     <para>
-     Many more commands wrap <literal>writeTextFile</literal> including
-     <literal>writeText</literal>, <literal>writeTextDir</literal>,
-     <literal>writeScript</literal>, and <literal>writeScriptBin</literal>.
-     These are convenience functions over <literal>writeTextFile</literal>.
+     Many more commands wrap <literal>writeTextFile</literal> including <literal>writeText</literal>, <literal>writeTextDir</literal>, <literal>writeScript</literal>, and <literal>writeScriptBin</literal>. These are convenience functions over <literal>writeTextFile</literal>.
     </para>
    </listitem>
   </varlistentry>
@@ -98,14 +71,7 @@
    </term>
    <listitem>
     <para>
-     This can be used to put many derivations into the same directory
-     structure. It works by creating a new derivation and adding symlinks to
-     each of the paths listed. It expects two arguments,
-     <literal>name</literal>, and <literal>paths</literal>.
-     <literal>name</literal> is the name used in the Nix store path for the
-     created derivation. <literal>paths</literal> is a list of paths that will
-     be symlinked. These paths can be to Nix store derivations or any other
-     subdirectory contained within.
+     This can be used to put many derivations into the same directory structure. It works by creating a new derivation and adding symlinks to each of the paths listed. It expects two arguments, <literal>name</literal>, and <literal>paths</literal>. <literal>name</literal> is the name used in the Nix store path for the created derivation. <literal>paths</literal> is a list of paths that will be symlinked. These paths can be to Nix store derivations or any other subdirectory contained within.
     </para>
    </listitem>
   </varlistentry>