NixOS · Aug 30, 2019 · Sep 9, 2019 · Sep 9, 2019 · Sep 9, 2019 · Sep 9, 2019
Showing 784 changed files with 28,221 additions and 17,385 deletions.
diff --git a/README.md b/README.md
@@ -44,9 +44,9 @@ Nixpkgs and NixOS are built and tested by our continuous integration
 system, [Hydra](https://hydra.nixos.org/).
 
 * [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
-* [Continuous package builds for the NixOS 19.03 release](https://hydra.nixos.org/jobset/nixos/release-19.03)
+* [Continuous package builds for the NixOS 19.09 release](https://hydra.nixos.org/jobset/nixos/release-19.09)
 * [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
-* [Tests for the NixOS 19.03 release](https://hydra.nixos.org/job/nixos/release-19.03/tested#tabs-constituents)
+* [Tests for the NixOS 19.09 release](https://hydra.nixos.org/job/nixos/release-19.09/tested#tabs-constituents)
 
 Artifacts successfully built with Hydra are published to cache at
 https://cache.nixos.org/. When successful build and test criteria are

diff --git a/doc/coding-conventions.xml b/doc/coding-conventions.xml
diff --git a/doc/configuration.xml b/doc/configuration.xml
diff --git a/doc/contributing.xml b/doc/contributing.xml
@@ -3,10 +3,8 @@
          xml:id="chap-contributing">
  <title>Contributing to this documentation</title>
  <para>
-  The DocBook sources of the Nixpkgs manual are in the
-  <filename
-xlink:href="https://github.com/NixOS/nixpkgs/tree/master/doc">doc</filename>
-  subdirectory of the Nixpkgs repository.
+  The DocBook sources of the Nixpkgs manual are in the <filename
+xlink:href="https://github.com/NixOS/nixpkgs/tree/master/doc">doc</filename> subdirectory of the Nixpkgs repository.
  </para>
  <para>
   You can quickly check your edits with <command>make</command>:
@@ -17,19 +15,16 @@ xlink:href="https://github.com/NixOS/nixpkgs/tree/master/doc">doc</filename>
 <prompt>[nix-shell]$ </prompt>make
 </screen>
  <para>
-  If you experience problems, run <command>make debug</command> to help
-  understand the docbook errors.
+  If you experience problems, run <command>make debug</command> to help understand the docbook errors.
  </para>
  <para>
-  After making modifications to the manual, it's important to build it before
-  committing. You can do that as follows:
+  After making modifications to the manual, it's important to build it before committing. You can do that as follows:
 <screen>
 <prompt>$ </prompt>cd /path/to/nixpkgs/doc
 <prompt>$ </prompt>nix-shell
 <prompt>[nix-shell]$ </prompt>make clean
 <prompt>[nix-shell]$ </prompt>nix-build .
 </screen>
-  If the build succeeds, the manual will be in
-  <filename>./result/share/doc/nixpkgs/manual.html</filename>.
+  If the build succeeds, the manual will be in <filename>./result/share/doc/nixpkgs/manual.html</filename>.
  </para>
 </chapter>
diff --git a/doc/cross-compilation.xml b/doc/cross-compilation.xml
diff --git a/doc/functions.xml b/doc/functions.xml
@@ -4,8 +4,7 @@
          xml:id="chap-functions">
  <title>Functions reference</title>
  <para>
-  The nixpkgs repository has several utility functions to manipulate Nix
-  expressions.
+  The nixpkgs repository has several utility functions to manipulate Nix expressions.
  </para>
  <xi:include href="functions/library.xml" />
  <xi:include href="functions/overrides.xml" />

diff --git a/doc/functions/appimagetools.xml b/doc/functions/appimagetools.xml
@@ -5,27 +5,20 @@
  <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>
 
  <section xml:id="ssec-pkgs-appimageTools-formats">
   <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,17 +48,15 @@ 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>
 
  <section xml:id="ssec-pkgs-appimageTools-wrapping">
   <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/doc/functions/debug.xml b/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/doc/functions/dockertools.xml b/doc/functions/dockertools.xml
diff --git a/doc/functions/fetchers.xml b/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/doc/functions/fhs-environments.xml b/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/doc/functions/generators.xml b/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/doc/functions/library.xml b/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/doc/functions/library/asserts.xml b/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/doc/functions/library/attrsets.xml b/doc/functions/library/attrsets.xml
diff --git a/doc/functions/nix-gitignore.xml b/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/doc/functions/ocitools.xml b/doc/functions/ocitools.xml
@@ -5,26 +5,18 @@
  <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'>
@@ -51,23 +43,17 @@ buildContainer {
    <calloutlist>
     <callout arearefs='ex-ociTools-buildContainer-1'>
      <para>
-      <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
+      <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/doc/functions/overrides.xml b/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,23 +42,15 @@ 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>
 
  <section xml:id="sec-pkg-overrideAttrs">
   <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/doc/functions/prefer-remote-fetch.xml b/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/doc/functions/shell.xml b/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/doc/functions/snaptools.xml b/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/doc/functions/trivial-builders.xml b/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>

diff --git a/doc/languages-frameworks/beam.xml b/doc/languages-frameworks/beam.xml
diff --git a/doc/languages-frameworks/bower.xml b/doc/languages-frameworks/bower.xml
@@ -4,32 +4,22 @@
  <title>Bower</title>
 
  <para>
-  <link xlink:href="http://bower.io">Bower</link> is a package manager for web
-  site front-end components. Bower packages (comprising of build artefacts and
-  sometimes sources) are stored in <command>git</command> repositories,
-  typically on Github. The package registry is run by the Bower team with
-  package metadata coming from the <filename>bower.json</filename> file within
-  each package.
+  <link xlink:href="http://bower.io">Bower</link> is a package manager for web site front-end components. Bower packages (comprising of build artefacts and sometimes sources) are stored in <command>git</command> repositories, typically on Github. The package registry is run by the Bower team with package metadata coming from the <filename>bower.json</filename> file within each package.
  </para>
 
  <para>
-  The end result of running Bower is a <filename>bower_components</filename>
-  directory which can be included in the web app's build process.
+  The end result of running Bower is a <filename>bower_components</filename> directory which can be included in the web app's build process.
  </para>
 
  <para>
-  Bower can be run interactively, by installing
-  <varname>nodePackages.bower</varname>. More interestingly, the Bower
-  components can be declared in a Nix derivation, with the help of
-  <varname>nodePackages.bower2nix</varname>.
+  Bower can be run interactively, by installing <varname>nodePackages.bower</varname>. More interestingly, the Bower components can be declared in a Nix derivation, with the help of <varname>nodePackages.bower2nix</varname>.
  </para>
 
  <section xml:id="ssec-bower2nix-usage">
   <title><command>bower2nix</command> usage</title>
 
   <para>
-   Suppose you have a <filename>bower.json</filename> with the following
-   contents:
+   Suppose you have a <filename>bower.json</filename> with the following contents:
    <example xml:id="ex-bowerJson">
     <title><filename>bower.json</filename></title>
 <programlisting language="json">
@@ -45,8 +35,7 @@
   </para>
 
   <para>
-   Running <command>bower2nix</command> will produce something like the
-   following output:
+   Running <command>bower2nix</command> will produce something like the following output:
 <programlisting language="nix">
 <![CDATA[{ fetchbower, buildEnv }:
 buildEnv { name = "bower-env"; ignoreCollisions = true; paths = [
@@ -58,26 +47,19 @@ buildEnv { name = "bower-env"; ignoreCollisions = true; paths = [
   </para>
 
   <para>
-   Using the <command>bower2nix</command> command line arguments, the output
-   can be redirected to a file. A name like
-   <filename>bower-packages.nix</filename> would be fine.
+   Using the <command>bower2nix</command> command line arguments, the output can be redirected to a file. A name like <filename>bower-packages.nix</filename> would be fine.
   </para>
 
   <para>
-   The resulting derivation is a union of all the downloaded Bower packages
-   (and their dependencies). To use it, they still need to be linked together
-   by Bower, which is where <varname>buildBowerComponents</varname> is useful.
+   The resulting derivation is a union of all the downloaded Bower packages (and their dependencies). To use it, they still need to be linked together by Bower, which is where <varname>buildBowerComponents</varname> is useful.
   </para>
  </section>
 
  <section xml:id="ssec-build-bower-components">
   <title><varname>buildBowerComponents</varname> function</title>
 
   <para>
-   The function is implemented in
-   <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/bower-modules/generic/default.nix">
-   <filename>pkgs/development/bower-modules/generic/default.nix</filename></link>.
-   Example usage:
+   The function is implemented in <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/bower-modules/generic/default.nix"> <filename>pkgs/development/bower-modules/generic/default.nix</filename></link>. Example usage:
    <example xml:id="ex-buildBowerComponents">
     <title>buildBowerComponents</title>
 <programlisting language="nix">
@@ -91,34 +73,27 @@ bowerComponents = buildBowerComponents {
   </para>
 
   <para>
-   In <xref linkend="ex-buildBowerComponents" />, the following arguments are
-   of special significance to the function:
+   In <xref linkend="ex-buildBowerComponents" />, the following arguments are of special significance to the function:
    <calloutlist>
     <callout arearefs="ex-buildBowerComponents-1">
      <para>
-      <varname>generated</varname> specifies the file which was created by
-      <command>bower2nix</command>.
+      <varname>generated</varname> specifies the file which was created by <command>bower2nix</command>.
      </para>
     </callout>
     <callout arearefs="ex-buildBowerComponents-2">
      <para>
-      <varname>src</varname> is your project's sources. It needs to contain a
-      <filename>bower.json</filename> file.
+      <varname>src</varname> is your project's sources. It needs to contain a <filename>bower.json</filename> file.
      </para>
     </callout>
    </calloutlist>
   </para>
 
   <para>
-   <varname>buildBowerComponents</varname> will run Bower to link together the
-   output of <command>bower2nix</command>, resulting in a
-   <filename>bower_components</filename> directory which can be used.
+   <varname>buildBowerComponents</varname> will run Bower to link together the output of <command>bower2nix</command>, resulting in a <filename>bower_components</filename> directory which can be used.
   </para>
 
   <para>
-   Here is an example of a web frontend build process using
-   <command>gulp</command>. You might use <command>grunt</command>, or anything
-   else.
+   Here is an example of a web frontend build process using <command>gulp</command>. You might use <command>grunt</command>, or anything else.
   </para>
 
   <example xml:id="ex-bowerGulpFile">
@@ -174,21 +149,17 @@ pkgs.stdenv.mkDerivation {
    <calloutlist>
     <callout arearefs="ex-buildBowerComponentsDefault-1">
      <para>
-      The result of <varname>buildBowerComponents</varname> is an input to the
-      frontend build.
+      The result of <varname>buildBowerComponents</varname> is an input to the frontend build.
      </para>
     </callout>
     <callout arearefs="ex-buildBowerComponentsDefault-2">
      <para>
-      Whether to symlink or copy the <filename>bower_components</filename>
-      directory depends on the build tool in use. In this case a copy is used
-      to avoid <command>gulp</command> silliness with permissions.
+      Whether to symlink or copy the <filename>bower_components</filename> directory depends on the build tool in use. In this case a copy is used to avoid <command>gulp</command> silliness with permissions.
      </para>
     </callout>
     <callout arearefs="ex-buildBowerComponentsDefault-3">
      <para>
-      <command>gulp</command> requires <varname>HOME</varname> to refer to a
-      writeable directory.
+      <command>gulp</command> requires <varname>HOME</varname> to refer to a writeable directory.
      </para>
     </callout>
     <callout arearefs="ex-buildBowerComponentsDefault-4">
@@ -210,17 +181,13 @@ pkgs.stdenv.mkDerivation {
     </term>
     <listitem>
      <para>
-      This means that Bower was looking for a package version which doesn't
-      exist in the generated <filename>bower-packages.nix</filename>.
+      This means that Bower was looking for a package version which doesn't exist in the generated <filename>bower-packages.nix</filename>.
      </para>
      <para>
-      If <filename>bower.json</filename> has been updated, then run
-      <command>bower2nix</command> again.
+      If <filename>bower.json</filename> has been updated, then run <command>bower2nix</command> again.
      </para>
      <para>
-      It could also be a bug in <command>bower2nix</command> or
-      <command>fetchbower</command>. If possible, try reformulating the version
-      specification in <filename>bower.json</filename>.
+      It could also be a bug in <command>bower2nix</command> or <command>fetchbower</command>. If possible, try reformulating the version specification in <filename>bower.json</filename>.
      </para>
     </listitem>
    </varlistentry>

diff --git a/doc/languages-frameworks/coq.xml b/doc/languages-frameworks/coq.xml
@@ -4,31 +4,19 @@
  <title>Coq</title>
 
  <para>
-  Coq libraries should be installed in
-  <literal>$(out)/lib/coq/${coq.coq-version}/user-contrib/</literal>. Such
-  directories are automatically added to the <literal>$COQPATH</literal>
-  environment variable by the hook defined in the Coq derivation.
+  Coq libraries should be installed in <literal>$(out)/lib/coq/${coq.coq-version}/user-contrib/</literal>. Such directories are automatically added to the <literal>$COQPATH</literal> environment variable by the hook defined in the Coq derivation.
  </para>
 
  <para>
-  Some extensions (plugins) might require OCaml and sometimes other OCaml
-  packages. The <literal>coq.ocamlPackages</literal> attribute can be used to
-  depend on the same package set Coq was built against.
+  Some extensions (plugins) might require OCaml and sometimes other OCaml packages. The <literal>coq.ocamlPackages</literal> attribute can be used to depend on the same package set Coq was built against.
  </para>
 
  <para>
-  Coq libraries may be compatible with some specific versions of Coq only. The
-  <literal>compatibleCoqVersions</literal> attribute is used to precisely
-  select those versions of Coq that are compatible with this derivation.
+  Coq libraries may be compatible with some specific versions of Coq only. The <literal>compatibleCoqVersions</literal> attribute is used to precisely select those versions of Coq that are compatible with this derivation.
  </para>
 
  <para>
-  Here is a simple package example. It is a pure Coq library, thus it depends
-  on Coq. It builds on the Mathematical Components library, thus it also takes
-  <literal>mathcomp</literal> as <literal>buildInputs</literal>. Its
-  <literal>Makefile</literal> has been generated using
-  <literal>coq_makefile</literal> so we only have to set the
-  <literal>$COQLIB</literal> variable at install time.
+  Here is a simple package example. It is a pure Coq library, thus it depends on Coq. It builds on the Mathematical Components library, thus it also takes <literal>mathcomp</literal> as <literal>buildInputs</literal>. Its <literal>Makefile</literal> has been generated using <literal>coq_makefile</literal> so we only have to set the <literal>$COQLIB</literal> variable at install time.
  </para>
 
 <programlisting>

diff --git a/doc/languages-frameworks/gnome.xml b/doc/languages-frameworks/gnome.xml
@@ -0,0 +1,263 @@
+<section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-language-gnome">
+ <title>GNOME</title>
+
+ <section xml:id="ssec-gnome-packaging">
+  <title>Packaging GNOME applications</title>
+
+  <para>
+   Programs in the GNOME universe are written in various languages but they all use GObject-based libraries like GLib, GTK or GStreamer. These libraries are often modular, relying on looking into certain directories to find their modules. However, due to Nix’s specific file system organization, this will fail without our intervention. Fortunately, the libraries usually allow overriding the directories through environment variables, either natively or thanks to a patch in nixpkgs. <link xlink:href="#fun-wrapProgram">Wrapping</link> the executables to ensure correct paths are available to the application constitutes a significant part of packaging a modern desktop application. In this section, we will describe various modules needed by such applications, environment variables needed to make the modules load, and finally a script that will do the work for us.
+  </para>
+
+  <section xml:id="ssec-gnome-settings">
+   <title>Settings</title>
+
+   <para>
+    <link xlink:href="https://developer.gnome.org/gio/stable/GSettings.html">GSettings</link> API is often used for storing settings. GSettings schemas are required, to know the type and other metadata of the stored values. GLib looks for <filename>glib-2.0/schemas/gschemas.compiled</filename> files inside the directories of <envar>XDG_DATA_DIRS</envar>.
+   </para>
+
+   <para>
+    On Linux, GSettings API is implemented using <link xlink:href="https://wiki.gnome.org/Projects/dconf">dconf</link> backend. You will need to add <literal>dconf</literal> GIO module to <envar>GIO_EXTRA_MODULES</envar> variable, otherwise the <literal>memory</literal> backend will be used and the saved settings will not be persistent.
+   </para>
+
+   <para>
+    Last you will need the dconf database D-Bus service itself. You can enable it using <option>programs.dconf.enable</option>.
+   </para>
+
+   <para>
+    Some applications will also require <package>gsettings-desktop-schemas</package> for things like reading proxy configuration or user interface customization. This dependency is often not mentioned by upstream, you should grep for <literal>org.gnome.desktop</literal> and <literal>org.gnome.system</literal> to see if the schemas are needed.
+   </para>
+  </section>
+
+  <section xml:id="ssec-gnome-icons">
+   <title>Icons</title>
+
+   <para>
+    When an application uses icons, an icon theme should be available in <envar>XDG_DATA_DIRS</envar>. The package for the default, icon-less <link xlink:href="https://www.freedesktop.org/wiki/Software/icon-theme/">hicolor-icon-theme</link> contains <link linkend="ssec-gnome-hooks-hicolor-icon-theme">a setup hook</link> that will pick up icon themes from <literal>buildInputs</literal> and pass it to our wrapper. Unfortunately, relying on that would mean every user has to download the theme included in the package expression no matter their preference. For that reason, we leave the installation of icon theme on the user. If you use one of the desktop environments, you probably already have an icon theme installed.
+   </para>
+  </section>
+
+  <section xml:id="ssec-gnome-themes">
+   <title>GTK Themes</title>
+
+   <para>
+    Previously, a GTK theme needed to be in <envar>XDG_DATA_DIRS</envar>. This is no longer necessary for most programs since GTK incorporated Adwaita theme. Some programs (for example, those designed for <link xlink:href="https://elementary.io/docs/human-interface-guidelines#human-interface-guidelines">elementary HIG</link>) might require a special theme like <package>pantheon.elementary-gtk-theme</package>.
+   </para>
+  </section>
+
+  <section xml:id="ssec-gnome-typelibs">
+   <title>GObject introspection typelibs</title>
+
+   <para>
+    <link xlink:href="https://wiki.gnome.org/Projects/GObjectIntrospection">GObject introspection</link> allows applications to use C libraries in other languages easily. It does this through <literal>typelib</literal> files searched in <envar>GI_TYPELIB_PATH</envar>.
+   </para>
+  </section>
+
+  <section xml:id="ssec-gnome-plugins">
+   <title>Various plug-ins</title>
+
+   <para>
+    If your application uses <link xlink:href="https://gstreamer.freedesktop.org/">GStreamer</link> or <link xlink:href="https://wiki.gnome.org/Projects/Grilo">Grilo</link>, you should set <envar>GST_PLUGIN_SYSTEM_PATH_1_0</envar> and <envar>GRL_PLUGIN_PATH</envar>, respectively.
+   </para>
+  </section>
+ </section>
+
+ <section xml:id="ssec-gnome-hooks">
+  <title>Onto <package>wrapGAppsHook</package></title>
+
+  <para>
+   Given the requirements above, the package expression would become messy quickly:
+<programlisting>
+preFixup = ''
+  for f in $(find $out/bin/ $out/libexec/ -type f -executable); do
+    wrapProgram "$f" \
+      --prefix GIO_EXTRA_MODULES : "${getLib gnome3.dconf}/lib/gio/modules" \
+      --prefix XDG_DATA_DIRS : "$out/share" \
+      --prefix XDG_DATA_DIRS : "$out/share/gsettings-schemas/${name}" \
+      --prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \
+      --prefix XDG_DATA_DIRS : "${hicolor-icon-theme}/share" \
+      --prefix GI_TYPELIB_PATH : "${lib.makeSearchPath "lib/girepository-1.0" [ pango json-glib ]}"
+  done
+'';
+</programlisting>
+   Fortunately, there is <package>wrapGAppsHook</package>, that does the wrapping for us. In particular, it works in conjunction with other setup hooks that will populate the variable:
+   <itemizedlist>
+    <listitem xml:id="ssec-gnome-hooks-wrapgappshook">
+     <para>
+      <package>wrapGAppsHook</package> itself will add the package’s <filename>share</filename> directory to <envar>XDG_DATA_DIRS</envar>.
+     </para>
+    </listitem>
+    <listitem xml:id="ssec-gnome-hooks-glib">
+     <para>
+      <package>glib</package> setup hook will populate <envar>GSETTINGS_SCHEMAS_PATH</envar> and then <package>wrapGAppsHook</package> will prepend it to <envar>XDG_DATA_DIRS</envar>.
+     </para>
+    </listitem>
+    <listitem xml:id="ssec-gnome-hooks-dconf">
+     <para>
+      <package>gnome3.dconf.lib</package> is a dependency of <package>wrapGAppsHook</package>, which then also adds it to the <envar>GIO_EXTRA_MODULES</envar> variable.
+     </para>
+    </listitem>
+    <listitem xml:id="ssec-gnome-hooks-hicolor-icon-theme">
+     <para>
+      <package>hicolor-icon-theme</package>’s setup hook will add icon themes to <envar>XDG_ICON_DIRS</envar> which is prepended to <envar>XDG_DATA_DIRS</envar> by <package>wrapGAppsHook</package>.
+     </para>
+    </listitem>
+    <listitem xml:id="ssec-gnome-hooks-gobject-introspection">
+     <para>
+      <package>gobject-introspection</package> setup hook populates <envar>GI_TYPELIB_PATH</envar> variable with <filename>lib/girepository-1.0</filename> directories of dependencies, which is then added to wrapper by <package>wrapGAppsHook</package>. It also adds <filename>share</filename> directories of dependencies to <envar>XDG_DATA_DIRS</envar>, which is intended to promote GIR files but it also <link xlink:href="https://github.com/NixOS/nixpkgs/issues/32790">pollutes the closures</link> of packages using <package>wrapGAppsHook</package>.
+     </para>
+     <warning>
+      <para>
+       The setup hook <link xlink:href="https://github.com/NixOS/nixpkgs/issues/56943">currently</link> does not work in expressions with <literal>strictDeps</literal> enabled, like Python packages. In those cases, you will need to disable it with <code>strictDeps = false;</code>.
+      </para>
+     </warning>
+    </listitem>
+    <listitem xml:id="ssec-gnome-hooks-gst-grl-plugins">
+     <para>
+      Setup hooks of <package>gst_all_1.gstreamer</package> and <package>gnome3.grilo</package> will populate the <envar>GST_PLUGIN_SYSTEM_PATH_1_0</envar> and <envar>GRL_PLUGIN_PATH</envar> variables, respectively, which will then be added to the wrapper by <literal>wrapGAppsHook</literal>.
+     </para>
+    </listitem>
+   </itemizedlist>
+  </para>
+
+  <para>
+   You can also pass additional arguments to <literal>makeWrapper</literal> using <literal>gappsWrapperArgs</literal> in <literal>preFixup</literal> hook:
+<programlisting>
+preFixup = ''
+  gappsWrapperArgs+=(
+    # Thumbnailers
+    --prefix XDG_DATA_DIRS : "${gdk-pixbuf}/share"
+    --prefix XDG_DATA_DIRS : "${librsvg}/share"
+    --prefix XDG_DATA_DIRS : "${shared-mime-info}/share"
+  )
+'';
+</programlisting>
+  </para>
+ </section>
+
+ <section xml:id="ssec-gnome-updating">
+  <title>Updating GNOME packages</title>
+
+  <para>
+   Most GNOME package offer <link linkend="var-passthru-updateScript"><literal>updateScript</literal></link>, it is therefore possible to update to latest source tarball by running <command>nix-shell maintainers/scripts/update.nix --argstr package gnome3.nautilus</command> or even en masse with <command>nix-shell maintainers/scripts/update.nix --argstr path gnome3</command>. Read the package’s <filename>NEWS</filename> file to see what changed.
+  </para>
+ </section>
+
+ <section xml:id="ssec-gnome-common-issues">
+  <title>Frequently encountered issues</title>
+
+  <variablelist>
+   <varlistentry xml:id="ssec-gnome-common-issues-no-schemas">
+    <term>
+     <computeroutput>GLib-GIO-ERROR **: <replaceable>06:04:50.903</replaceable>: No GSettings schemas are installed on the system</computeroutput>
+    </term>
+    <listitem>
+     <para>
+      There are no schemas avalable in <envar>XDG_DATA_DIRS</envar>. Temporarily add a random package containing schemas like <package>gsettings-desktop-schemas</package> to <literal>buildInputs</literal>. <link linkend="ssec-gnome-hooks-glib"><package>glib</package></link> and <link linkend="ssec-gnome-hooks-wrapgappshook"><package>wrapGAppsHook</package></link> setup hooks will take care of making the schemas available to application and you will see the actual missing schemas with the <link linkend="ssec-gnome-common-issues-missing-schema">next error</link>. Or you can try looking through the source code for the actual schemas used.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry xml:id="ssec-gnome-common-issues-missing-schema">
+    <term>
+     <computeroutput>GLib-GIO-ERROR **: <replaceable>06:04:50.903</replaceable>: Settings schema ‘<replaceable>org.gnome.foo</replaceable>’ is not installed</computeroutput>
+    </term>
+    <listitem>
+     <para>
+      Package is missing some GSettings schemas. You can find out the package containing the schema with <command>nix-locate <replaceable>org.gnome.foo</replaceable>.gschema.xml</command> and let the hooks handle the wrapping as <link linkend="ssec-gnome-common-issues-no-schemas">above</link>.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry xml:id="ssec-gnome-common-issues-double-wrapped">
+    <term>
+     When using <package>wrapGAppsHook</package> with special derivers you can end up with double wrapped binaries.
+    </term>
+    <listitem>
+     <para>
+      This is because derivers like <function>python.pkgs.buildPythonApplication</function> or <function>qt5.mkDerivation</function> have setup-hooks automatically added that produce wrappers with <package>makeWrapper</package>. The simplest way to workaround that is to disable the <package>wrapGAppsHook</package> automatic wrapping with <code>dontWrapGApps = true;</code> and pass the arguments it intended to pass to <package>makeWrapper</package> to another.
+     </para>
+     <para>
+      In the case of a Python application it could look like:
+<programlisting>
+python3.pkgs.buildPythonApplication {
+  pname = "gnome-music";
+  version = "3.32.2";
+
+  nativeBuildInputs = [
+    wrapGAppsHook
+    gobject-introspection
+    ...
+  ];
+
+  dontWrapGApps = true;
+
+  # Arguments to be passed to `makeWrapper`, only used by buildPython*
+  makeWrapperArgs = [
+    "\${gappsWrapperArgs[@]}"
+  ];
+}
+</programlisting>
+      And for a QT app like:
+<programlisting>
+mkDerivation {
+  pname = "calibre";
+  version = "3.47.0";
+
+  nativeBuildInputs = [
+    wrapGAppsHook
+    qmake
+    ...
+  ];
+
+  dontWrapGApps = true;
+
+  # Arguments to be passed to `makeWrapper`, only used by qt5’s mkDerivation
+  qtWrapperArgs [
+    "\${gappsWrapperArgs[@]}"
+  ];
+}
+</programlisting>
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry xml:id="ssec-gnome-common-issues-unwrappable-package">
+    <term>
+     I am packaging a project that cannot be wrapped, like a library or GNOME Shell extension.
+    </term>
+    <listitem>
+     <para>
+      You can rely on applications depending on the library set the necessary environment variables but that it often easy to miss. Instead we recommend to patch the paths in the source code whenever possible. Here are some examples:
+      <itemizedlist>
+       <listitem xml:id="ssec-gnome-common-issues-unwrappable-package-gnome-shell-ext">
+        <para>
+         <link xlink:href="https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/gnome-3/core/gnome-shell-extensions/default.nix#L21-L24">Replacing a <envar>GI_TYPELIB_PATH</envar> in GNOME Shell extension</link> – we are using <function>substituteAll</function> to include the path to a typelib into a patch.
+        </para>
+       </listitem>
+       <listitem xml:id="ssec-gnome-common-issues-unwrappable-package-gsettings">
+        <para>
+         The following examples are hardcoding GSettings schema paths. To get the schema paths we use the functions
+         <itemizedlist>
+          <listitem>
+           <para>
+            <function>glib.getSchemaPath</function> Takes a nix package attribute as an argument.
+           </para>
+          </listitem>
+          <listitem>
+           <para>
+            <function>glib.makeSchemaPath</function> Takes a package output like <literal>$out</literal> and a derivation name. You should use this if the schemas you need to hardcode are in the same derivation.
+           </para>
+          </listitem>
+         </itemizedlist>
+        </para>
+        <para xml:id="ssec-gnome-common-issues-unwrappable-package-gsettings-vala">
+         <link xlink:href="https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/pantheon/apps/elementary-files/default.nix#L78-L86">Hard-coding GSettings schema path in Vala plug-in (dynamically loaded library)</link> – here, <function>substituteAll</function> cannot be used since the schema comes from the same package preventing us from pass its path to the function, probably due to a <link xlink:href="https://github.com/NixOS/nix/issues/1846">Nix bug</link>.
+        </para>
+        <para xml:id="ssec-gnome-common-issues-unwrappable-package-gsettings-c">
+         <link xlink:href="https://github.com/NixOS/nixpkgs/blob/29c120c065d03b000224872251bed93932d42412/pkgs/development/libraries/glib-networking/default.nix#L31-L34">Hard-coding GSettings schema path in C library</link> – nothing special other than using <link xlink:href="https://github.com/NixOS/nixpkgs/pull/67957#issuecomment-527717467">Coccinelle patch</link> to generate the patch itself.
+        </para>
+       </listitem>
+      </itemizedlist>
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+ </section>
+</section>
diff --git a/doc/languages-frameworks/go.xml b/doc/languages-frameworks/go.xml
@@ -7,21 +7,16 @@
   <title>Go modules</title>
 
   <para>
-   The function <varname> buildGoModule </varname> builds Go programs managed
-   with Go modules. It builds a
-   <link xlink:href="https://github.com/golang/go/wiki/Modules">Go
-   modules</link> through a two phase build:
+   The function <varname> buildGoModule </varname> builds Go programs managed with Go modules. It builds a <link xlink:href="https://github.com/golang/go/wiki/Modules">Go modules</link> through a two phase build:
    <itemizedlist>
     <listitem>
      <para>
-      An intermediate fetcher derivation. This derivation will be used to fetch
-      all of the dependencies of the Go module.
+      An intermediate fetcher derivation. This derivation will be used to fetch all of the dependencies of the Go module.
      </para>
     </listitem>
     <listitem>
      <para>
-      A final derivation will use the output of the intermediate derivation to
-      build the binaries and produce the final output.
+      A final derivation will use the output of the intermediate derivation to build the binaries and produce the final output.
      </para>
     </listitem>
    </itemizedlist>
@@ -57,21 +52,16 @@ pet = buildGoModule rec {
   </example>
 
   <para>
-   <xref linkend='ex-buildGoModule'/> is an example expression using
-   buildGoModule, the following arguments are of special significance to the
-   function:
+   <xref linkend='ex-buildGoModule'/> is an example expression using buildGoModule, the following arguments are of special significance to the function:
    <calloutlist>
     <callout arearefs='ex-buildGoModule-1'>
      <para>
-      <varname>modSha256</varname> is the hash of the output of the
-      intermediate fetcher derivation.
+      <varname>modSha256</varname> is the hash of the output of the intermediate fetcher derivation.
      </para>
     </callout>
     <callout arearefs='ex-buildGoModule-2'>
      <para>
-      <varname>subPackages</varname> limits the builder from building child
-      packages that have not been listed. If <varname>subPackages</varname> is
-      not specified, all child packages will be built.
+      <varname>subPackages</varname> limits the builder from building child packages that have not been listed. If <varname>subPackages</varname> is not specified, all child packages will be built.
      </para>
     </callout>
    </calloutlist>
@@ -82,8 +72,7 @@ pet = buildGoModule rec {
   <title>Go legacy</title>
 
   <para>
-   The function <varname> buildGoPackage </varname> builds legacy Go programs,
-   not supporting Go modules.
+   The function <varname> buildGoPackage </varname> builds legacy Go programs, not supporting Go modules.
   </para>
 
   <example xml:id='ex-buildGoPackage'>
@@ -111,49 +100,36 @@ deis = buildGoPackage rec {
   </example>
 
   <para>
-   <xref linkend='ex-buildGoPackage'/> is an example expression using
-   buildGoPackage, the following arguments are of special significance to the
-   function:
+   <xref linkend='ex-buildGoPackage'/> is an example expression using buildGoPackage, the following arguments are of special significance to the function:
    <calloutlist>
     <callout arearefs='ex-buildGoPackage-1'>
      <para>
-      <varname>goPackagePath</varname> specifies the package's canonical Go
-      import path.
+      <varname>goPackagePath</varname> specifies the package's canonical Go import path.
      </para>
     </callout>
     <callout arearefs='ex-buildGoPackage-2'>
      <para>
-      <varname>subPackages</varname> limits the builder from building child
-      packages that have not been listed. If <varname>subPackages</varname> is
-      not specified, all child packages will be built.
+      <varname>subPackages</varname> limits the builder from building child packages that have not been listed. If <varname>subPackages</varname> is not specified, all child packages will be built.
      </para>
      <para>
-      In this example only <literal>github.com/deis/deis/client</literal> will
-      be built.
+      In this example only <literal>github.com/deis/deis/client</literal> will be built.
      </para>
     </callout>
     <callout arearefs='ex-buildGoPackage-3'>
      <para>
-      <varname>goDeps</varname> is where the Go dependencies of a Go program
-      are listed as a list of package source identified by Go import path. It
-      could be imported as a separate <varname>deps.nix</varname> file for
-      readability. The dependency data structure is described below.
+      <varname>goDeps</varname> is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate <varname>deps.nix</varname> file for readability. The dependency data structure is described below.
      </para>
     </callout>
     <callout arearefs='ex-buildGoPackage-4'>
      <para>
-      <varname>buildFlags</varname> is a list of flags passed to the go build
-      command.
+      <varname>buildFlags</varname> is a list of flags passed to the go build command.
      </para>
     </callout>
    </calloutlist>
   </para>
 
   <para>
-   The <varname>goDeps</varname> attribute can be imported from a separate
-   <varname>nix</varname> file that defines which Go libraries are needed and
-   should be included in <varname>GOPATH</varname> for
-   <varname>buildPhase</varname>.
+   The <varname>goDeps</varname> attribute can be imported from a separate <varname>nix</varname> file that defines which Go libraries are needed and should be included in <varname>GOPATH</varname> for <varname>buildPhase</varname>.
   </para>
 
   <example xml:id='ex-goDeps'>
@@ -196,41 +172,30 @@ deis = buildGoPackage rec {
     </callout>
     <callout arearefs='ex-goDeps-3'>
      <para>
-      <varname>fetch type</varname> that needs to be used to get package
-      source. If <varname>git</varname> is used there should be
-      <varname>url</varname>, <varname>rev</varname> and
-      <varname>sha256</varname> defined next to it.
+      <varname>fetch type</varname> that needs to be used to get package source. If <varname>git</varname> is used there should be <varname>url</varname>, <varname>rev</varname> and <varname>sha256</varname> defined next to it.
      </para>
     </callout>
    </calloutlist>
   </para>
 
   <para>
-   To extract dependency information from a Go package in automated way use
-   <link xlink:href="https://github.com/kamilchm/go2nix">go2nix</link>. It can
-   produce complete derivation and <varname>goDeps</varname> file for Go
-   programs.
+   To extract dependency information from a Go package in automated way use <link xlink:href="https://github.com/kamilchm/go2nix">go2nix</link>. It can produce complete derivation and <varname>goDeps</varname> file for Go programs.
   </para>
 
   <para>
-   <varname>buildGoPackage</varname> produces
-   <xref linkend='chap-multiple-output' xrefstyle="select: title" /> where
-   <varname>bin</varname> includes program binaries. You can test build a Go
-   binary as follows:
+   <varname>buildGoPackage</varname> produces <xref linkend='chap-multiple-output' xrefstyle="select: title" /> where <varname>bin</varname> includes program binaries. You can test build a Go binary as follows:
 <screen>
 <prompt>$ </prompt>nix-build -A deis.bin
 </screen>
    or build all outputs with:
 <screen>
 <prompt>$ </prompt>nix-build -A deis.all
 </screen>
-   <varname>bin</varname> output will be installed by default with
-   <varname>nix-env -i</varname> or <varname>systemPackages</varname>.
+   <varname>bin</varname> output will be installed by default with <varname>nix-env -i</varname> or <varname>systemPackages</varname>.
   </para>
 
   <para>
-   You may use Go packages installed into the active Nix profiles by adding the
-   following to your ~/.bashrc:
+   You may use Go packages installed into the active Nix profiles by adding the following to your ~/.bashrc:
 <screen>
 for p in $NIX_PROFILES; do
     GOPATH="$p/share/go:$GOPATH"

diff --git a/doc/languages-frameworks/index.xml b/doc/languages-frameworks/index.xml
@@ -3,17 +3,13 @@
          xml:id="chap-language-support">
  <title>Support for specific programming languages and frameworks</title>
  <para>
-  The <link linkend="chap-stdenv">standard build environment</link> makes it
-  easy to build typical Autotools-based packages with very little code. Any
-  other kind of package can be accomodated by overriding the appropriate phases
-  of <literal>stdenv</literal>. However, there are specialised functions in
-  Nixpkgs to easily build packages for other programming languages, such as
-  Perl or Haskell. These are described in this chapter.
+  The <link linkend="chap-stdenv">standard build environment</link> makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accomodated by overriding the appropriate phases of <literal>stdenv</literal>. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
  </para>
  <xi:include href="android.section.xml" />
  <xi:include href="beam.xml" />
  <xi:include href="bower.xml" />
  <xi:include href="coq.xml" />
+ <xi:include href="gnome.xml" />
  <xi:include href="go.xml" />
  <xi:include href="haskell.section.xml" />
  <xi:include href="idris.section.xml" />

diff --git a/doc/languages-frameworks/java.xml b/doc/languages-frameworks/java.xml
@@ -15,37 +15,24 @@ stdenv.mkDerivation {
   buildPhase = "ant";
 }
 </programlisting>
-  Note that <varname>jdk</varname> is an alias for the OpenJDK (self-built
-  where available, or pre-built via Zulu). Platforms with OpenJDK not (yet) in
-  Nixpkgs (<literal>Aarch32</literal>, <literal>Aarch64</literal>) point to the
-  (unfree) <literal>oraclejdk</literal>.
+  Note that <varname>jdk</varname> is an alias for the OpenJDK (self-built where available, or pre-built via Zulu). Platforms with OpenJDK not (yet) in Nixpkgs (<literal>Aarch32</literal>, <literal>Aarch64</literal>) point to the (unfree) <literal>oraclejdk</literal>.
  </para>
 
  <para>
-  JAR files that are intended to be used by other packages should be installed
-  in <filename>$out/share/java</filename>. JDKs have a stdenv setup hook that
-  add any JARs in the <filename>share/java</filename> directories of the build
-  inputs to the <envar>CLASSPATH</envar> environment variable. For instance, if
-  the package <literal>libfoo</literal> installs a JAR named
-  <filename>foo.jar</filename> in its <filename>share/java</filename>
-  directory, and another package declares the attribute
+  JAR files that are intended to be used by other packages should be installed in <filename>$out/share/java</filename>. JDKs have a stdenv setup hook that add any JARs in the <filename>share/java</filename> directories of the build inputs to the <envar>CLASSPATH</envar> environment variable. For instance, if the package <literal>libfoo</literal> installs a JAR named <filename>foo.jar</filename> in its <filename>share/java</filename> directory, and another package declares the attribute
 <programlisting>
 buildInputs = [ libfoo ];
 nativeBuildInputs = [ jdk ];
 </programlisting>
-  then <envar>CLASSPATH</envar> will be set to
-  <filename>/nix/store/...-libfoo/share/java/foo.jar</filename>.
+  then <envar>CLASSPATH</envar> will be set to <filename>/nix/store/...-libfoo/share/java/foo.jar</filename>.
  </para>
 
  <para>
-  Private JARs should be installed in a location like
-  <filename>$out/share/<replaceable>package-name</replaceable></filename>.
+  Private JARs should be installed in a location like <filename>$out/share/<replaceable>package-name</replaceable></filename>.
  </para>
 
  <para>
-  If your Java package provides a program, you need to generate a wrapper
-  script to run it using the OpenJRE. You can use
-  <literal>makeWrapper</literal> for this:
+  If your Java package provides a program, you need to generate a wrapper script to run it using the OpenJRE. You can use <literal>makeWrapper</literal> for this:
 <programlisting>
 nativeBuildInputs = [ makeWrapper ];
 
@@ -56,30 +43,21 @@ installPhase =
       --add-flags "-cp $out/share/java/foo.jar org.foo.Main"
   '';
 </programlisting>
-  Note the use of <literal>jre</literal>, which is the part of the OpenJDK
-  package that contains the Java Runtime Environment. By using
-  <literal>${jre}/bin/java</literal> instead of
-  <literal>${jdk}/bin/java</literal>, you prevent your package from depending
-  on the JDK at runtime.
+  Note the use of <literal>jre</literal>, which is the part of the OpenJDK package that contains the Java Runtime Environment. By using <literal>${jre}/bin/java</literal> instead of <literal>${jdk}/bin/java</literal>, you prevent your package from depending on the JDK at runtime.
  </para>
 
  <para>
-  Note all JDKs passthru <literal>home</literal>, so if your application
-  requires environment variables like <envar>JAVA_HOME</envar> being set, that
-  can be done in a generic fashion with the <literal>--set</literal> argument
-  of <literal>makeWrapper</literal>:
+  Note all JDKs passthru <literal>home</literal>, so if your application requires environment variables like <envar>JAVA_HOME</envar> being set, that can be done in a generic fashion with the <literal>--set</literal> argument of <literal>makeWrapper</literal>:
 <programlisting>
 --set JAVA_HOME ${jdk.home}
 </programlisting>
  </para>
 
  <para>
-  It is possible to use a different Java compiler than <command>javac</command>
-  from the OpenJDK. For instance, to use the GNU Java Compiler:
+  It is possible to use a different Java compiler than <command>javac</command> from the OpenJDK. For instance, to use the GNU Java Compiler:
 <programlisting>
 nativeBuildInputs = [ gcj ant ];
 </programlisting>
-  Here, Ant will automatically use <command>gij</command> (the GNU Java
-  Runtime) instead of the OpenJRE.
+  Here, Ant will automatically use <command>gij</command> (the GNU Java Runtime) instead of the OpenJRE.
  </para>
 </section>
diff --git a/doc/languages-frameworks/lua.xml b/doc/languages-frameworks/lua.xml
@@ -4,18 +4,11 @@
  <title>Lua</title>
 
  <para>
-  Lua packages are built by the <varname>buildLuaPackage</varname> function.
-  This function is implemented in
-  <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/lua-modules/generic/default.nix">
-  <filename>pkgs/development/lua-modules/generic/default.nix</filename></link>
-  and works similarly to <varname>buildPerlPackage</varname>. (See
-  <xref linkend="sec-language-perl"/> for details.)
+  Lua packages are built by the <varname>buildLuaPackage</varname> function. This function is implemented in <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/lua-modules/generic/default.nix"> <filename>pkgs/development/lua-modules/generic/default.nix</filename></link> and works similarly to <varname>buildPerlPackage</varname>. (See <xref linkend="sec-language-perl"/> for details.)
  </para>
 
  <para>
-  Lua packages are defined in
-  <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/lua-packages.nix"><filename>pkgs/top-level/lua-packages.nix</filename></link>.
-  Most of them are simple. For example:
+  Lua packages are defined in <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/lua-packages.nix"><filename>pkgs/top-level/lua-packages.nix</filename></link>. Most of them are simple. For example:
 <programlisting>
 fileSystem = buildLuaPackage {
   name = "filesystem-1.6.2";
@@ -33,16 +26,11 @@ fileSystem = buildLuaPackage {
  </para>
 
  <para>
-  Though, more complicated package should be placed in a seperate file in
-  <link
+  Though, more complicated package should be placed in a seperate file in <link
   xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/lua-modules"><filename>pkgs/development/lua-modules</filename></link>.
  </para>
 
  <para>
-  Lua packages accept additional parameter <varname>disabled</varname>, which
-  defines the condition of disabling package from luaPackages. For example, if
-  package has <varname>disabled</varname> assigned to <literal>lua.luaversion
-  != "5.1"</literal>, it will not be included in any luaPackages except
-  lua51Packages, making it only be built for lua 5.1.
+  Lua packages accept additional parameter <varname>disabled</varname>, which defines the condition of disabling package from luaPackages. For example, if package has <varname>disabled</varname> assigned to <literal>lua.luaversion != "5.1"</literal>, it will not be included in any luaPackages except lua51Packages, making it only be built for lua 5.1.
  </para>
 </section>