nixos/doc: Updates release date for 18.09

(cherry picked from commit 82d1bf9691)

README.md

@@ -12,12 +12,12 @@ build daemon as so-called channels. To get channel information via git, add
 ```
 
 For stability and maximum binary package support, it is recommended to maintain
-custom changes on top of one of the channels, e.g. `nixos-18.03` for the latest
+custom changes on top of one of the channels, e.g. `nixos-18.09` for the latest
 release and `nixos-unstable` for the latest successful build of master:
 
 ```
 % git remote update channels
-% git rebase channels/nixos-18.03
+% git rebase channels/nixos-18.09
 ```
 
 For pull-requests, please rebase onto nixpkgs `master`.
@@ -31,9 +31,9 @@ For pull-requests, please rebase onto nixpkgs `master`.
 * [Manual (NixOS)](https://nixos.org/nixos/manual/)
 * [Community maintained wiki](https://nixos.wiki/)
 * [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
-* [Continuous package builds for 18.03 release](https://hydra.nixos.org/jobset/nixos/release-18.03)
+* [Continuous package builds for 18.09 release](https://hydra.nixos.org/jobset/nixos/release-18.09)
 * [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
-* [Tests for 18.03 release](https://hydra.nixos.org/job/nixos/release-18.03/tested#tabs-constituents)
+* [Tests for 18.09 release](https://hydra.nixos.org/job/nixos/release-18.09/tested#tabs-constituents)
 
 Communication:
 

doc/.gitignore

@@ -4,3 +4,4 @@
 out
 manual-full.xml
 highlightjs
+functions/library/locations.xml

doc/Makefile

@@ -19,7 +19,7 @@ fix-misc-xml:
 
 .PHONY: clean
 clean:
-	rm -f ${MD_TARGETS} .version manual-full.xml
+	rm -f ${MD_TARGETS} .version manual-full.xml functions/library/locations.xml
 	rm -rf ./out/ ./highlightjs
 
 .PHONY: validate
@@ -69,13 +69,17 @@ highlightjs:
 	cp -r "$$HIGHLIGHTJS/loader.js" highlightjs/
 
 
-manual-full.xml: ${MD_TARGETS} .version *.xml
+manual-full.xml: ${MD_TARGETS} .version functions/library/locations.xml *.xml **/*.xml **/**/*.xml
 	xmllint --nonet --xinclude --noxincludenode manual.xml --output manual-full.xml
 
 .version:
 	nix-instantiate --eval \
 		-E '(import ../lib).version' > .version
 
+functions/library/locations.xml:
+	nix-build ./lib-function-locations.nix \
+		--out-link ./functions/library/locations.xml
+
 %.section.xml: %.section.md
 	pandoc $^ -w docbook+smart \
 		-f markdown+smart \

doc/cross-compilation.xml

@@ -47,9 +47,10 @@
 
    <para>
     In Nixpkgs, these three platforms are defined as attribute sets under the
-    names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>, and
-    <literal>targetPlatform</literal>. They are always defined as attributes in
-    the standard environment. That means one can access them like:
+    names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>,
+    and <literal>targetPlatform</literal>. They are always defined as
+    attributes in the standard environment. That means one can access them
+    like:
 <programlisting>{ stdenv, fooDep, barDep, .. }: ...stdenv.buildPlatform...</programlisting>
     .
    </para>

doc/default.nix

@@ -1,6 +1,7 @@
+{ pkgs ? (import ./.. { }), nixpkgs ? { }}:
 let
-  pkgs = import ./.. { };
   lib = pkgs.lib;
+  locationsXml = import ./lib-function-locations.nix { inherit pkgs nixpkgs; };
 in
 pkgs.stdenv.mkDerivation {
   name = "nixpkgs-manual";
@@ -29,6 +30,8 @@ pkgs.stdenv.mkDerivation {
   ];
 
   postPatch = ''
+    rm -rf ./functions/library/locations.xml
+    ln -s ${locationsXml} ./functions/library/locations.xml
     echo ${lib.version} > .version
   '';
 

doc/functions.xml

@@ -7,793 +7,12 @@
   The nixpkgs repository has several utility functions to manipulate Nix
   expressions.
  </para>
- <section xml:id="sec-overrides">
-  <title>Overriding</title>
 
-  <para>
-   Sometimes one wants to override parts of <literal>nixpkgs</literal>, e.g.
-   derivation attributes, the results of derivations or even the whole package
-   set.
-  </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>).
-   </para>
-
-   <para>
-    It is used to override the arguments passed to a function.
-   </para>
-
-   <para>
-    Example usages:
-<programlisting>pkgs.foo.override { arg1 = val1; arg2 = val2; ... }</programlisting>
-<programlisting>import pkgs.path { overlays = [ (self: super: {
-    foo = super.foo.override { barSupport = true ; };
-  })]};</programlisting>
-<programlisting>mypkg = pkgs.callPackage ./mypkg.nix {
-    mydep = pkgs.mydep.override { ... };
-  }</programlisting>
-   </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.
-   </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>.
-   </para>
-
-   <para>
-    Example usage:
-<programlisting>helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
-    separateDebugInfo = true;
-  });</programlisting>
-   </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.
-   </para>
-
-   <para>
-    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>sdenv.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 involves less typing.
-    </para>
-   </note>
-  </section>
-
-  <section xml:id="sec-pkg-overrideDerivation">
-   <title>&lt;pkg&gt;.overrideDerivation</title>
-
-   <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>.
-    </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>.
-    </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.
-   </para>
-
-   <para>
-    Example usage:
-<programlisting>mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
-    name = "sed-4.2.2-pre";
-    src = fetchurl {
-      url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2;
-      sha256 = "11nq06d131y4wmf3drm0yk502d2xc6n5qy82cg88rb9nqd2lj41k";
-    };
-    patches = [];
-  });</programlisting>
-   </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.
-   </para>
-
-   <para>
-    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.
-    </para>
-   </note>
-  </section>
-
-  <section xml:id="sec-lib-makeOverridable">
-   <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.
-   </para>
-
-   <para>
-    Example usage:
-<programlisting>f = { a, b }: { result = a+b; }
-  c = lib.makeOverridable f { a = 1; b = 2; }</programlisting>
-   </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.
-   </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.
-   </para>
-  </section>
- </section>
- <section xml:id="sec-generators">
-  <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>
-  </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.
-  </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:
-  </para>
-
-<programlisting>
-with lib;
-let
-  customToINI = generators.toINI {
-    # specifies how to format a key/value pair
-    mkKeyValue = generators.mkKeyValueDefault {
-      # specifies the generated string for a subset of nix values
-      mkValueString = v:
-             if v == true then ''"yes"''
-        else if v == false then ''"no"''
-        else if isString v then ''"${v}"''
-        # and delegats all other values to the default generator
-        else generators.mkValueStringDefault {} v;
-    } ":";
-  };
-
-# the INI file can now be given as plain old nix values
-in customToINI {
-  main = {
-    pushinfo = true;
-    autopush = false;
-    host = "localhost";
-    port = 42;
-  };
-  mergetool = {
-    merge = "diff3";
-  };
-}
-</programlisting>
-
-  <para>
-   This will produce the following INI file as nix string:
-  </para>
-
-<programlisting>
-[main]
-autopush:"no"
-host:"localhost"
-port:42
-pushinfo:"yes"
-str\:ange:"very::strange"
-
-[mergetool]
-merge:"diff3"
-</programlisting>
-
-  <note>
-   <para>
-    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>.
-  </para>
- </section>
- <section xml:id="sec-debug">
-  <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.
-  </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.
-  </para>
- </section>
- <section xml:id="sec-fhs-environments">
-  <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:
-  </para>
-
-  <variablelist>
-   <varlistentry>
-    <term>
-     <literal>name</literal>
-    </term>
-    <listitem>
-     <para>
-      Environment name.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <literal>targetPkgs</literal>
-    </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.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <literal>multiPkgs</literal>
-    </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.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <literal>extraBuildCommands</literal>
-    </term>
-    <listitem>
-     <para>
-      Additional commands to be executed for finalizing the directory
-      structure.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <literal>extraBuildCommandsMulti</literal>
-    </term>
-    <listitem>
-     <para>
-      Like <literal>extraBuildCommands</literal>, but executed only on multilib
-      architectures.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <literal>extraOutputsToInstall</literal>
-    </term>
-    <listitem>
-     <para>
-      Additional derivation outputs to be linked for both target and
-      multi-architecture packages.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <literal>extraInstallCommands</literal>
-    </term>
-    <listitem>
-     <para>
-      Additional commands to be executed for finalizing the derivation with
-      runner script.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <literal>runScript</literal>
-    </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>.
-     </para>
-    </listitem>
-   </varlistentry>
-  </variablelist>
-
-  <para>
-   One can create a simple environment using a <literal>shell.nix</literal>
-   like that:
-  </para>
-
-<programlisting><![CDATA[
-{ pkgs ? import <nixpkgs> {} }:
-
-(pkgs.buildFHSUserEnv {
-  name = "simple-x11-env";
-  targetPkgs = pkgs: (with pkgs;
-    [ udev
-      alsaLib
-    ]) ++ (with pkgs.xorg;
-    [ libX11
-      libXcursor
-      libXrandr
-    ]);
-  multiPkgs = pkgs: (with pkgs;
-    [ udev
-      alsaLib
-    ]);
-  runScript = "bash";
-}).env
-]]></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.
-  </para>
- </section>
- <xi:include href="shell.section.xml" />
- <section xml:id="sec-pkgs-dockerTools">
-  <title>pkgs.dockerTools</title>
-
-  <para>
-   <varname>pkgs.dockerTools</varname> is a set of functions for creating and
-   manipulating Docker images according to the
-   <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#docker-image-specification-v120">
-   Docker Image Specification v1.2.0 </link>. Docker itself is not used to
-   perform any of the operations done by these functions.
-  </para>
-
-  <warning>
-   <para>
-    The <varname>dockerTools</varname> API is unstable and may be subject to
-    backwards-incompatible changes in the future.
-   </para>
-  </warning>
-
-  <section xml:id="ssec-pkgs-dockerTools-buildImage">
-   <title>buildImage</title>
-
-   <para>
-    This function is analogous to the <command>docker build</command> command,
-    in that can used to build a Docker-compatible repository tarball containing
-    a single image with one or multiple layers. As such, the result is suitable
-    for being loaded in Docker with <command>docker load</command>.
-   </para>
-
-   <para>
-    The parameters of <varname>buildImage</varname> with relative example
-    values are described below:
-   </para>
-
-   <example xml:id='ex-dockerTools-buildImage'>
-    <title>Docker build</title>
-<programlisting>
-  buildImage {
-    name = "redis"; <co xml:id='ex-dockerTools-buildImage-1' />
-    tag = "latest"; <co xml:id='ex-dockerTools-buildImage-2' />
-
-    fromImage = someBaseImage; <co xml:id='ex-dockerTools-buildImage-3' />
-    fromImageName = null; <co xml:id='ex-dockerTools-buildImage-4' />
-    fromImageTag = "latest"; <co xml:id='ex-dockerTools-buildImage-5' />
-
-    contents = pkgs.redis; <co xml:id='ex-dockerTools-buildImage-6' />
-    runAsRoot = '' <co xml:id='ex-dockerTools-buildImage-runAsRoot' />
-      #!${stdenv.shell}
-      mkdir -p /data
-    '';
-
-    config = { <co xml:id='ex-dockerTools-buildImage-8' />
-      Cmd = [ "/bin/redis-server" ];
-      WorkingDir = "/data";
-      Volumes = {
-        "/data" = {};
-      };
-    };
-  }
-  </programlisting>
-   </example>
-
-   <para>
-    The above example will build a Docker image <literal>redis/latest</literal>
-    from the given base image. Loading and running this image in Docker results
-    in <literal>redis-server</literal> being started automatically.
-   </para>
-
-   <calloutlist>
-    <callout arearefs='ex-dockerTools-buildImage-1'>
-     <para>
-      <varname>name</varname> specifies the name of the resulting image. This
-      is the only required argument for <varname>buildImage</varname>.
-     </para>
-    </callout>
-    <callout arearefs='ex-dockerTools-buildImage-2'>
-     <para>
-      <varname>tag</varname> specifies the tag of the resulting image. By
-      default it's <literal>null</literal>, which indicates that the nix output
-      hash will be used as tag.
-     </para>
-    </callout>
-    <callout arearefs='ex-dockerTools-buildImage-3'>
-     <para>
-      <varname>fromImage</varname> is the repository tarball containing the
-      base image. It must be a valid Docker image, such as exported by
-      <command>docker save</command>. By default it's <literal>null</literal>,
-      which can be seen as equivalent to <literal>FROM scratch</literal> of a
-      <filename>Dockerfile</filename>.
-     </para>
-    </callout>
-    <callout arearefs='ex-dockerTools-buildImage-4'>
-     <para>
-      <varname>fromImageName</varname> can be used to further specify the base
-      image within the repository, in case it contains multiple images. By
-      default it's <literal>null</literal>, in which case
-      <varname>buildImage</varname> will peek the first image available in the
-      repository.
-     </para>
-    </callout>
-    <callout arearefs='ex-dockerTools-buildImage-5'>
-     <para>
-      <varname>fromImageTag</varname> can be used to further specify the tag of
-      the base image within the repository, in case an image contains multiple
-      tags. By default it's <literal>null</literal>, in which case
-      <varname>buildImage</varname> will peek the first tag available for the
-      base image.
-     </para>
-    </callout>
-    <callout arearefs='ex-dockerTools-buildImage-6'>
-     <para>
-      <varname>contents</varname> is a derivation that will be copied in the
-      new layer of the resulting image. This can be similarly seen as
-      <command>ADD contents/ /</command> in a <filename>Dockerfile</filename>.
-      By default it's <literal>null</literal>.
-     </para>
-    </callout>
-    <callout arearefs='ex-dockerTools-buildImage-runAsRoot'>
-     <para>
-      <varname>runAsRoot</varname> is a bash script that will run as root in an
-      environment that overlays the existing layers of the base image with the
-      new resulting layer, including the previously copied
-      <varname>contents</varname> derivation. This can be similarly seen as
-      <command>RUN ...</command> in a <filename>Dockerfile</filename>.
-      <note>
-       <para>
-        Using this parameter requires the <literal>kvm</literal> device to be
-        available.
-       </para>
-      </note>
-     </para>
-    </callout>
-    <callout arearefs='ex-dockerTools-buildImage-8'>
-     <para>
-      <varname>config</varname> is used to specify the configuration of the
-      containers that will be started off the built image in Docker. The
-      available options are listed in the
-      <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions">
-      Docker Image Specification v1.2.0 </link>.
-     </para>
-    </callout>
-   </calloutlist>
-
-   <para>
-    After the new layer has been created, its closure (to which
-    <varname>contents</varname>, <varname>config</varname> and
-    <varname>runAsRoot</varname> contribute) will be copied in the layer
-    itself. Only new dependencies that are not already in the existing layers
-    will be copied.
-   </para>
-
-   <para>
-    At the end of the process, only one new single layer will be produced and
-    added to the resulting image.
-   </para>
-
-   <para>
-    The resulting repository will only list the single image
-    <varname>image/tag</varname>. In the case of
-    <xref linkend='ex-dockerTools-buildImage'/> it would be
-    <varname>redis/latest</varname>.
-   </para>
-
-   <para>
-    It is possible to inspect the arguments with which an image was built using
-    its <varname>buildArgs</varname> attribute.
-   </para>
-
-   <note>
-    <para>
-     If you see errors similar to <literal>getProtocolByName: does not exist
-     (no such protocol name: tcp)</literal> you may need to add
-     <literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
-    </para>
-   </note>
-
-   <note>
-    <para>
-     If you see errors similar to <literal>Error_Protocol ("certificate has
-     unknown CA",True,UnknownCa)</literal> you may need to add
-     <literal>pkgs.cacert</literal> to <varname>contents</varname>.
-    </para>
-   </note>
-  </section>
-
-  <section xml:id="ssec-pkgs-dockerTools-fetchFromRegistry">
-   <title>pullImage</title>
-
-   <para>
-    This function is analogous to the <command>docker pull</command> command,
-    in that can be used to pull a Docker image from a Docker registry. By
-    default <link xlink:href="https://hub.docker.com/">Docker Hub</link> is
-    used to pull images.
-   </para>
-
-   <para>
-    Its parameters are described in the example below:
-   </para>
-
-   <example xml:id='ex-dockerTools-pullImage'>
-    <title>Docker pull</title>
-<programlisting>
-  pullImage {
-    imageName = "nixos/nix"; <co xml:id='ex-dockerTools-pullImage-1' />
-    imageDigest = "sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b"; <co xml:id='ex-dockerTools-pullImage-2' />
-    finalImageTag = "1.11";  <co xml:id='ex-dockerTools-pullImage-3' />
-    sha256 = "0mqjy3zq2v6rrhizgb9nvhczl87lcfphq9601wcprdika2jz7qh8"; <co xml:id='ex-dockerTools-pullImage-4' />
-    os = "linux"; <co xml:id='ex-dockerTools-pullImage-5' />
-    arch = "x86_64"; <co xml:id='ex-dockerTools-pullImage-6' />
-  }
-  </programlisting>
-   </example>
-
-   <calloutlist>
-    <callout arearefs='ex-dockerTools-pullImage-1'>
-     <para>
-      <varname>imageName</varname> specifies the name of the image to be
-      downloaded, which can also include the registry namespace (e.g.
-      <literal>nixos</literal>). This argument is required.
-     </para>
-    </callout>
-    <callout arearefs='ex-dockerTools-pullImage-2'>
-     <para>
-      <varname>imageDigest</varname> specifies the digest of the image to be
-      downloaded. Skopeo can be used to get the digest of an image, with its
-      <varname>inspect</varname> subcommand. Since a given
-      <varname>imageName</varname> may transparently refer to a manifest list
-      of images which support multiple architectures and/or operating systems,
-      supply the `--override-os` and `--override-arch` arguments to specify
-      exactly which image you want. By default it will match the OS and
-      architecture of the host the command is run on.
-<programlisting>
-  $ nix-shell --packages skopeo jq --command "skopeo --override-os linux --override-arch x86_64 inspect docker://docker.io/nixos/nix:1.11 | jq -r '.Digest'"
-  sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
-  </programlisting>
-      This argument is required.
-     </para>
-    </callout>
-    <callout arearefs='ex-dockerTools-pullImage-3'>
-     <para>
-      <varname>finalImageTag</varname>, if specified, this is the tag of the
-      image to be created. Note it is never used to fetch the image since we
-      prefer to rely on the immutable digest ID. By default it's
-      <literal>latest</literal>.
-     </para>
-    </callout>
-    <callout arearefs='ex-dockerTools-pullImage-4'>
-     <para>
-      <varname>sha256</varname> is the checksum of the whole fetched image.
-      This argument is required.
-     </para>
-    </callout>
-    <callout arearefs='ex-dockerTools-pullImage-5'>
-     <para>
-      <varname>os</varname>, if specified, is the operating system of the
-      fetched image. By default it's <literal>linux</literal>.
-     </para>
-    </callout>
-    <callout arearefs='ex-dockerTools-pullImage-6'>
-     <para>
-      <varname>arch</varname>, if specified, is the cpu architecture of the
-      fetched image. By default it's <literal>x86_64</literal>.
-     </para>
-    </callout>
-   </calloutlist>
-  </section>
-
-  <section xml:id="ssec-pkgs-dockerTools-exportImage">
-   <title>exportImage</title>
-
-   <para>
-    This function is analogous to the <command>docker export</command> command,
-    in that can used to flatten a Docker image that contains multiple layers.
-    It is in fact the result of the merge of all the layers of the image. As
-    such, the result is suitable for being imported in Docker with
-    <command>docker import</command>.
-   </para>
-
-   <note>
-    <para>
-     Using this function requires the <literal>kvm</literal> device to be
-     available.
-    </para>
-   </note>
-
-   <para>
-    The parameters of <varname>exportImage</varname> are the following:
-   </para>
-
-   <example xml:id='ex-dockerTools-exportImage'>
-    <title>Docker export</title>
-<programlisting>
-  exportImage {
-    fromImage = someLayeredImage;
-    fromImageName = null;
-    fromImageTag = null;
-
-    name = someLayeredImage.name;
-  }
-  </programlisting>
-   </example>
-
-   <para>
-    The parameters relative to the base image have the same synopsis as
-    described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except
-    that <varname>fromImage</varname> is the only required argument in this
-    case.
-   </para>
-
-   <para>
-    The <varname>name</varname> argument is the name of the derivation output,
-    which defaults to <varname>fromImage.name</varname>.
-   </para>
-  </section>
-
-  <section xml:id="ssec-pkgs-dockerTools-shadowSetup">
-   <title>shadowSetup</title>
-
-   <para>
-    This constant string is a helper for setting up the base files for managing
-    users and groups, only if such files don't exist already. It is suitable
-    for being used in a <varname>runAsRoot</varname>
-    <xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like
-    in the example below:
-   </para>
-
-   <example xml:id='ex-dockerTools-shadowSetup'>
-    <title>Shadow base files</title>
-<programlisting>
-  buildImage {
-    name = "shadow-basic";
-
-    runAsRoot = ''
-      #!${stdenv.shell}
-      ${shadowSetup}
-      groupadd -r redis
-      useradd -r -g redis redis
-      mkdir /data
-      chown redis:redis /data
-    '';
-  }
-  </programlisting>
-   </example>
-
-   <para>
-    Creating base files like <literal>/etc/passwd</literal> or
-    <literal>/etc/login.defs</literal> are necessary for shadow-utils to
-    manipulate users and groups.
-   </para>
-  </section>
- </section>
+ <xi:include href="functions/library.xml" />
+ <xi:include href="functions/overrides.xml" />
+ <xi:include href="functions/generators.xml" />
+ <xi:include href="functions/debug.xml" />
+ <xi:include href="functions/fhs-environments.xml" />
+ <xi:include href="functions/shell.xml" />
+ <xi:include href="functions/dockertools.xml" />
 </chapter>

doc/functions/debug.xml

@@ -0,0 +1,21 @@
+<section xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xmlns:xi="http://www.w3.org/2001/XInclude"
+         xml:id="sec-debug">
+ <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.
+ </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.
+ </para>
+</section>

doc/functions/dockertools.xml

@@ -0,0 +1,393 @@
+<section xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xmlns:xi="http://www.w3.org/2001/XInclude"
+         xml:id="sec-pkgs-dockerTools">
+ <title>pkgs.dockerTools</title>
+
+ <para>
+  <varname>pkgs.dockerTools</varname> is a set of functions for creating and
+  manipulating Docker images according to the
+  <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#docker-image-specification-v120">
+  Docker Image Specification v1.2.0 </link>. Docker itself is not used to
+  perform any of the operations done by these functions.
+ </para>
+
+ <warning>
+  <para>
+   The <varname>dockerTools</varname> API is unstable and may be subject to
+   backwards-incompatible changes in the future.
+  </para>
+ </warning>
+
+ <section xml:id="ssec-pkgs-dockerTools-buildImage">
+  <title>buildImage</title>
+
+  <para>
+   This function is analogous to the <command>docker build</command> command,
+   in that can used to build a Docker-compatible repository tarball containing
+   a single image with one or multiple layers. As such, the result is suitable
+   for being loaded in Docker with <command>docker load</command>.
+  </para>
+
+  <para>
+   The parameters of <varname>buildImage</varname> with relative example values
+   are described below:
+  </para>
+
+  <example xml:id='ex-dockerTools-buildImage'>
+   <title>Docker build</title>
+<programlisting>
+  buildImage {
+    name = "redis"; <co xml:id='ex-dockerTools-buildImage-1' />
+    tag = "latest"; <co xml:id='ex-dockerTools-buildImage-2' />
+
+    fromImage = someBaseImage; <co xml:id='ex-dockerTools-buildImage-3' />
+    fromImageName = null; <co xml:id='ex-dockerTools-buildImage-4' />
+    fromImageTag = "latest"; <co xml:id='ex-dockerTools-buildImage-5' />
+
+    contents = pkgs.redis; <co xml:id='ex-dockerTools-buildImage-6' />
+    runAsRoot = '' <co xml:id='ex-dockerTools-buildImage-runAsRoot' />
+      #!${stdenv.shell}
+      mkdir -p /data
+    '';
+
+    config = { <co xml:id='ex-dockerTools-buildImage-8' />
+      Cmd = [ "/bin/redis-server" ];
+      WorkingDir = "/data";
+      Volumes = {
+        "/data" = {};
+      };
+    };
+  }
+  </programlisting>
+  </example>
+
+  <para>
+   The above example will build a Docker image <literal>redis/latest</literal>
+   from the given base image. Loading and running this image in Docker results
+   in <literal>redis-server</literal> being started automatically.
+  </para>
+
+  <calloutlist>
+   <callout arearefs='ex-dockerTools-buildImage-1'>
+    <para>
+     <varname>name</varname> specifies the name of the resulting image. This is
+     the only required argument for <varname>buildImage</varname>.
+    </para>
+   </callout>
+   <callout arearefs='ex-dockerTools-buildImage-2'>
+    <para>
+     <varname>tag</varname> specifies the tag of the resulting image. By
+     default it's <literal>null</literal>, which indicates that the nix output
+     hash will be used as tag.
+    </para>
+   </callout>
+   <callout arearefs='ex-dockerTools-buildImage-3'>
+    <para>
+     <varname>fromImage</varname> is the repository tarball containing the base
+     image. It must be a valid Docker image, such as exported by
+     <command>docker save</command>. By default it's <literal>null</literal>,
+     which can be seen as equivalent to <literal>FROM scratch</literal> of a
+     <filename>Dockerfile</filename>.
+    </para>
+   </callout>
+   <callout arearefs='ex-dockerTools-buildImage-4'>
+    <para>
+     <varname>fromImageName</varname> can be used to further specify the base
+     image within the repository, in case it contains multiple images. By
+     default it's <literal>null</literal>, in which case
+     <varname>buildImage</varname> will peek the first image available in the
+     repository.
+    </para>
+   </callout>
+   <callout arearefs='ex-dockerTools-buildImage-5'>
+    <para>
+     <varname>fromImageTag</varname> can be used to further specify the tag of
+     the base image within the repository, in case an image contains multiple
+     tags. By default it's <literal>null</literal>, in which case
+     <varname>buildImage</varname> will peek the first tag available for the
+     base image.
+    </para>
+   </callout>
+   <callout arearefs='ex-dockerTools-buildImage-6'>
+    <para>
+     <varname>contents</varname> is a derivation that will be copied in the new
+     layer of the resulting image. This can be similarly seen as <command>ADD
+     contents/ /</command> in a <filename>Dockerfile</filename>. By default
+     it's <literal>null</literal>.
+    </para>
+   </callout>
+   <callout arearefs='ex-dockerTools-buildImage-runAsRoot'>
+    <para>
+     <varname>runAsRoot</varname> is a bash script that will run as root in an
+     environment that overlays the existing layers of the base image with the
+     new resulting layer, including the previously copied
+     <varname>contents</varname> derivation. This can be similarly seen as
+     <command>RUN ...</command> in a <filename>Dockerfile</filename>.
+     <note>
+      <para>
+       Using this parameter requires the <literal>kvm</literal> device to be
+       available.
+      </para>
+     </note>
+    </para>
+   </callout>
+   <callout arearefs='ex-dockerTools-buildImage-8'>
+    <para>
+     <varname>config</varname> is used to specify the configuration of the
+     containers that will be started off the built image in Docker. The
+     available options are listed in the
+     <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions">
+     Docker Image Specification v1.2.0 </link>.
+    </para>
+   </callout>
+  </calloutlist>
+
+  <para>
+   After the new layer has been created, its closure (to which
+   <varname>contents</varname>, <varname>config</varname> and
+   <varname>runAsRoot</varname> contribute) will be copied in the layer itself.
+   Only new dependencies that are not already in the existing layers will be
+   copied.
+  </para>
+
+  <para>
+   At the end of the process, only one new single layer will be produced and
+   added to the resulting image.
+  </para>
+
+  <para>
+   The resulting repository will only list the single image
+   <varname>image/tag</varname>. In the case of
+   <xref linkend='ex-dockerTools-buildImage'/> it would be
+   <varname>redis/latest</varname>.
+  </para>
+
+  <para>
+   It is possible to inspect the arguments with which an image was built using
+   its <varname>buildArgs</varname> attribute.
+  </para>
+
+  <note>
+   <para>
+    If you see errors similar to <literal>getProtocolByName: does not exist (no
+    such protocol name: tcp)</literal> you may need to add
+    <literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
+   </para>
+  </note>
+
+  <note>
+   <para>
+    If you see errors similar to <literal>Error_Protocol ("certificate has
+    unknown CA",True,UnknownCa)</literal> you may need to add
+    <literal>pkgs.cacert</literal> to <varname>contents</varname>.
+   </para>
+  </note>
+
+  <example xml:id="example-pkgs-dockerTools-buildImage-creation-date">
+   <title>Impurely Defining a Docker Layer's Creation Date</title>
+   <para>
+    By default <function>buildImage</function> will use a static date of one
+    second past the UNIX Epoch. This allows <function>buildImage</function> to
+    produce binary reproducible images. When listing images with
+    <command>docker list images</command>, the newly created images will be
+    listed like this:
+   </para>
+<screen><![CDATA[
+$ docker image list
+REPOSITORY   TAG      IMAGE ID       CREATED        SIZE
+hello        latest   08c791c7846e   48 years ago   25.2MB
+]]></screen>
+   <para>
+    You can break binary reproducibility but have a sorted, meaningful
+    <literal>CREATED</literal> column by setting <literal>created</literal> to
+    <literal>now</literal>.
+   </para>
+<programlisting><![CDATA[
+pkgs.dockerTools.buildImage {
+  name = "hello";
+  tag = "latest";
+  created = "now";
+  contents = pkgs.hello;
+
+  config.Cmd = [ "/bin/hello" ];
+}
+]]></programlisting>
+   <para>
+    and now the Docker CLI will display a reasonable date and sort the images
+    as expected:
+<screen><![CDATA[
+$ docker image list
+REPOSITORY   TAG      IMAGE ID       CREATED              SIZE
+hello        latest   de2bf4786de6   About a minute ago   25.2MB
+]]></screen>
+    however, the produced images will not be binary reproducible.
+   </para>
+  </example>
+ </section>
+
+ <section xml:id="ssec-pkgs-dockerTools-fetchFromRegistry">
+  <title>pullImage</title>
+
+  <para>
+   This function is analogous to the <command>docker pull</command> command, in
+   that can be used to pull a Docker image from a Docker registry. By default
+   <link xlink:href="https://hub.docker.com/">Docker Hub</link> is used to pull
+   images.
+  </para>
+
+  <para>
+   Its parameters are described in the example below:
+  </para>
+
+  <example xml:id='ex-dockerTools-pullImage'>
+   <title>Docker pull</title>
+<programlisting>
+  pullImage {
+    imageName = "nixos/nix"; <co xml:id='ex-dockerTools-pullImage-1' />
+    imageDigest = "sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b"; <co xml:id='ex-dockerTools-pullImage-2' />
+    finalImageTag = "1.11";  <co xml:id='ex-dockerTools-pullImage-3' />
+    sha256 = "0mqjy3zq2v6rrhizgb9nvhczl87lcfphq9601wcprdika2jz7qh8"; <co xml:id='ex-dockerTools-pullImage-4' />
+    os = "linux"; <co xml:id='ex-dockerTools-pullImage-5' />
+    arch = "x86_64"; <co xml:id='ex-dockerTools-pullImage-6' />
+  }
+  </programlisting>
+  </example>
+
+  <calloutlist>
+   <callout arearefs='ex-dockerTools-pullImage-1'>
+    <para>
+     <varname>imageName</varname> specifies the name of the image to be
+     downloaded, which can also include the registry namespace (e.g.
+     <literal>nixos</literal>). This argument is required.
+    </para>
+   </callout>
+   <callout arearefs='ex-dockerTools-pullImage-2'>
+    <para>
+     <varname>imageDigest</varname> specifies the digest of the image to be
+     downloaded. Skopeo can be used to get the digest of an image, with its
+     <varname>inspect</varname> subcommand. Since a given
+     <varname>imageName</varname> may transparently refer to a manifest list of
+     images which support multiple architectures and/or operating systems,
+     supply the `--override-os` and `--override-arch` arguments to specify
+     exactly which image you want. By default it will match the OS and
+     architecture of the host the command is run on.
+<programlisting>
+  $ nix-shell --packages skopeo jq --command "skopeo --override-os linux --override-arch x86_64 inspect docker://docker.io/nixos/nix:1.11 | jq -r '.Digest'"
+  sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
+  </programlisting>
+     This argument is required.
+    </para>
+   </callout>
+   <callout arearefs='ex-dockerTools-pullImage-3'>
+    <para>
+     <varname>finalImageTag</varname>, if specified, this is the tag of the
+     image to be created. Note it is never used to fetch the image since we
+     prefer to rely on the immutable digest ID. By default it's
+     <literal>latest</literal>.
+    </para>
+   </callout>
+   <callout arearefs='ex-dockerTools-pullImage-4'>
+    <para>
+     <varname>sha256</varname> is the checksum of the whole fetched image. This
+     argument is required.
+    </para>
+   </callout>
+   <callout arearefs='ex-dockerTools-pullImage-5'>
+    <para>
+     <varname>os</varname>, if specified, is the operating system of the
+     fetched image. By default it's <literal>linux</literal>.
+    </para>
+   </callout>
+   <callout arearefs='ex-dockerTools-pullImage-6'>
+    <para>
+     <varname>arch</varname>, if specified, is the cpu architecture of the
+     fetched image. By default it's <literal>x86_64</literal>.
+    </para>
+   </callout>
+  </calloutlist>
+ </section>
+
+ <section xml:id="ssec-pkgs-dockerTools-exportImage">
+  <title>exportImage</title>
+
+  <para>
+   This function is analogous to the <command>docker export</command> command,
+   in that can used to flatten a Docker image that contains multiple layers. It
+   is in fact the result of the merge of all the layers of the image. As such,
+   the result is suitable for being imported in Docker with <command>docker
+   import</command>.
+  </para>
+
+  <note>
+   <para>
+    Using this function requires the <literal>kvm</literal> device to be
+    available.
+   </para>
+  </note>
+
+  <para>
+   The parameters of <varname>exportImage</varname> are the following:
+  </para>
+
+  <example xml:id='ex-dockerTools-exportImage'>
+   <title>Docker export</title>
+<programlisting>
+  exportImage {
+    fromImage = someLayeredImage;
+    fromImageName = null;
+    fromImageTag = null;
+
+    name = someLayeredImage.name;
+  }
+  </programlisting>
+  </example>
+
+  <para>
+   The parameters relative to the base image have the same synopsis as
+   described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except that
+   <varname>fromImage</varname> is the only required argument in this case.
+  </para>
+
+  <para>
+   The <varname>name</varname> argument is the name of the derivation output,
+   which defaults to <varname>fromImage.name</varname>.
+  </para>
+ </section>
+
+ <section xml:id="ssec-pkgs-dockerTools-shadowSetup">
+  <title>shadowSetup</title>
+
+  <para>
+   This constant string is a helper for setting up the base files for managing
+   users and groups, only if such files don't exist already. It is suitable for
+   being used in a <varname>runAsRoot</varname>
+   <xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like
+   in the example below:
+  </para>
+
+  <example xml:id='ex-dockerTools-shadowSetup'>
+   <title>Shadow base files</title>
+<programlisting>
+  buildImage {
+    name = "shadow-basic";
+
+    runAsRoot = ''
+      #!${stdenv.shell}
+      ${shadowSetup}
+      groupadd -r redis
+      useradd -r -g redis redis
+      mkdir /data
+      chown redis:redis /data
+    '';
+  }
+  </programlisting>
+  </example>
+
+  <para>
+   Creating base files like <literal>/etc/passwd</literal> or
+   <literal>/etc/login.defs</literal> are necessary for shadow-utils to
+   manipulate users and groups.
+  </para>
+ </section>
+</section>

doc/functions/fhs-environments.xml

@@ -0,0 +1,142 @@
+<section xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xmlns:xi="http://www.w3.org/2001/XInclude"
+         xml:id="sec-fhs-environments">
+ <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:
+ </para>
+
+ <variablelist>
+  <varlistentry>
+   <term>
+    <literal>name</literal>
+   </term>
+   <listitem>
+    <para>
+     Environment name.
+    </para>
+   </listitem>
+  </varlistentry>
+  <varlistentry>
+   <term>
+    <literal>targetPkgs</literal>
+   </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.
+    </para>
+   </listitem>
+  </varlistentry>
+  <varlistentry>
+   <term>
+    <literal>multiPkgs</literal>
+   </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.
+    </para>
+   </listitem>
+  </varlistentry>
+  <varlistentry>
+   <term>
+    <literal>extraBuildCommands</literal>
+   </term>
+   <listitem>
+    <para>
+     Additional commands to be executed for finalizing the directory structure.
+    </para>
+   </listitem>
+  </varlistentry>
+  <varlistentry>
+   <term>
+    <literal>extraBuildCommandsMulti</literal>
+   </term>
+   <listitem>
+    <para>
+     Like <literal>extraBuildCommands</literal>, but executed only on multilib
+     architectures.
+    </para>
+   </listitem>
+  </varlistentry>
+  <varlistentry>
+   <term>
+    <literal>extraOutputsToInstall</literal>
+   </term>
+   <listitem>
+    <para>
+     Additional derivation outputs to be linked for both target and
+     multi-architecture packages.
+    </para>
+   </listitem>
+  </varlistentry>
+  <varlistentry>
+   <term>
+    <literal>extraInstallCommands</literal>
+   </term>
+   <listitem>
+    <para>
+     Additional commands to be executed for finalizing the derivation with
+     runner script.
+    </para>
+   </listitem>
+  </varlistentry>
+  <varlistentry>
+   <term>
+    <literal>runScript</literal>
+   </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>.
+    </para>
+   </listitem>
+  </varlistentry>
+ </variablelist>
+
+ <para>
+  One can create a simple environment using a <literal>shell.nix</literal> like
+  that:
+ </para>
+
+<programlisting><![CDATA[
+{ pkgs ? import <nixpkgs> {} }:
+
+(pkgs.buildFHSUserEnv {
+  name = "simple-x11-env";
+  targetPkgs = pkgs: (with pkgs;
+    [ udev
+      alsaLib
+    ]) ++ (with pkgs.xorg;
+    [ libX11
+      libXcursor
+      libXrandr
+    ]);
+  multiPkgs = pkgs: (with pkgs;
+    [ udev
+      alsaLib
+    ]);
+  runScript = "bash";
+}).env
+]]></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.
+ </para>
+</section>

doc/functions/generators.xml

@@ -0,0 +1,89 @@
+<section xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xmlns:xi="http://www.w3.org/2001/XInclude"
+         xml:id="sec-generators">
+ <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>
+ </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.
+ </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:
+ </para>
+
+<programlisting>
+with lib;
+let
+  customToINI = generators.toINI {
+    # specifies how to format a key/value pair
+    mkKeyValue = generators.mkKeyValueDefault {
+      # specifies the generated string for a subset of nix values
+      mkValueString = v:
+             if v == true then ''"yes"''
+        else if v == false then ''"no"''
+        else if isString v then ''"${v}"''
+        # and delegats all other values to the default generator
+        else generators.mkValueStringDefault {} v;
+    } ":";
+  };
+
+# the INI file can now be given as plain old nix values
+in customToINI {
+  main = {
+    pushinfo = true;
+    autopush = false;
+    host = "localhost";
+    port = 42;
+  };
+  mergetool = {
+    merge = "diff3";
+  };
+}
+</programlisting>
+
+ <para>
+  This will produce the following INI file as nix string:
+ </para>
+
+<programlisting>
+[main]
+autopush:"no"
+host:"localhost"
+port:42
+pushinfo:"yes"
+str\:ange:"very::strange"
+
+[mergetool]
+merge:"diff3"
+</programlisting>
+
+ <note>
+  <para>
+   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>.
+ </para>
+</section>

doc/functions/library.xml

@@ -0,0 +1,13 @@
+<section xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xmlns:xi="http://www.w3.org/2001/XInclude"
+         xml:id="sec-functions-library">
+ <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>.
+ </para>
+
+ <xi:include href="./library/attrsets.xml" />
+</section>

doc/functions/library/attrsets.xml

@@ -0,0 +1,970 @@
+<section xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xmlns:xi="http://www.w3.org/2001/XInclude"
+         xml:id="sec-functions-library-attrset">
+ <title>Attribute-Set Functions</title>
+
+ <section xml:id="function-library-lib.attrsets.attrByPath">
+  <title><function>lib.attrset.attrByPath</function></title>
+
+  <subtitle><literal>attrByPath :: [String] -> Any -> AttrSet</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.attrByPath" />
+
+  <para>
+   Return an attribute from within nested attribute sets.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>attrPath</varname>
+    </term>
+    <listitem>
+     <para>
+      A list of strings representing the path through the nested attribute set
+      <varname>set</varname>.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>default</varname>
+    </term>
+    <listitem>
+     <para>
+      Default value if <varname>attrPath</varname> does not resolve to an
+      existing value.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>set</varname>
+    </term>
+    <listitem>
+     <para>
+      The nested attributeset to select values from.
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrset.attrByPath-example-value-exists">
+   <title>Extracting a value from a nested attribute set</title>
+<programlisting><![CDATA[
+let set = { a = { b = 3; }; };
+in lib.attrsets.attrByPath [ "a" "b" ] 0 set
+=> 3
+]]></programlisting>
+  </example>
+
+  <example xml:id="function-library-lib.attrset.attrByPath-example-default-value">
+   <title>No value at the path, instead using the default</title>
+<programlisting><![CDATA[
+lib.attrsets.attrByPath [ "a" "b" ] 0 {}
+=> 0
+]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.hasAttrByPath">
+  <title><function>lib.attrsets.hasAttrByPath</function></title>
+
+  <subtitle><literal>hasAttrByPath :: [String] -> AttrSet -> Bool</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.hasAttrByPath" />
+
+  <para>
+   Determine if an attribute exists within a nested attribute set.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>attrPath</varname>
+    </term>
+    <listitem>
+     <para>
+      A list of strings representing the path through the nested attribute set
+      <varname>set</varname>.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>set</varname>
+    </term>
+    <listitem>
+     <para>
+      The nested attributeset to check.
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.hasAttrByPath-example">
+   <title>A nested value does exist inside a set</title>
+<programlisting><![CDATA[
+lib.attrsets.hasAttrByPath
+  [ "a" "b" "c" "d" ]
+  { a = { b = { c = { d = 123; }; }; }; }
+=> true
+]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.setAttrByPath">
+  <title><function>lib.attrsets.setAttrByPath</function></title>
+
+  <subtitle><literal>setAttrByPath :: [String] -> Any -> AttrSet</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.setAttrByPath" />
+
+  <para>
+   Create a new attribute set with <varname>value</varname> set at the nested
+   attribute location specified in <varname>attrPath</varname>.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>attrPath</varname>
+    </term>
+    <listitem>
+     <para>
+      A list of strings representing the path through the nested attribute set.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>value</varname>
+    </term>
+    <listitem>
+     <para>
+      The value to set at the location described by
+      <varname>attrPath</varname>.
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.setAttrByPath-example">
+   <title>Creating a new nested attribute set</title>
+<programlisting><![CDATA[
+lib.attrsets.setAttrByPath [ "a" "b" ] 3
+=> { a = { b = 3; }; }
+]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.getAttrFromPath">
+  <title><function>lib.attrsets.getAttrFromPath</function></title>
+
+  <subtitle><literal>getAttrFromPath :: [String] -> AttrSet -> Value</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.getAttrFromPath" />
+
+  <para>
+   Like <xref linkend="function-library-lib.attrsets.attrByPath" /> except
+   without a default, and it will throw if the value doesn't exist.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>attrPath</varname>
+    </term>
+    <listitem>
+     <para>
+      A list of strings representing the path through the nested attribute set
+      <varname>set</varname>.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>set</varname>
+    </term>
+    <listitem>
+     <para>
+      The nested attribute set to find the value in.
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.getAttrPath-example-success">
+   <title>Succesfully getting a value from an attribute set</title>
+<programlisting><![CDATA[
+lib.attrsets.getAttrFromPath [ "a" "b" ] { a = { b = 3; }; }
+=> 3
+]]></programlisting>
+  </example>
+
+  <example xml:id="function-library-lib.attrsets.getAttrPath-example-throw">
+   <title>Throwing after failing to get a value from an attribute set</title>
+<programlisting><![CDATA[
+lib.attrsets.getAttrFromPath [ "x" "y" ] { }
+=> error: cannot find attribute `x.y'
+]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.attrVals">
+  <title><function>lib.attrsets.attrVals</function></title>
+
+  <subtitle><literal>attrVals :: [String] -> AttrSet -> [Any]</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.attrVals" />
+
+  <para>
+   Return the specified attributes from a set. All values must exist.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>nameList</varname>
+    </term>
+    <listitem>
+     <para>
+      The list of attributes to fetch from <varname>set</varname>. Each
+      attribute name must exist on the attrbitue set.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>set</varname>
+    </term>
+    <listitem>
+     <para>
+      The set to get attribute values from.
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.attrVals-example-success">
+   <title>Getting several values from an attribute set</title>
+<programlisting><![CDATA[
+lib.attrsets.attrVals [ "a" "b" "c" ] { a = 1; b = 2; c = 3; }
+=> [ 1 2 3 ]
+]]></programlisting>
+  </example>
+
+  <example xml:id="function-library-lib.attrsets.attrVals-failure">
+   <title>Getting missing values from an attribute set</title>
+<programlisting><![CDATA[
+lib.attrsets.attrVals [ "d" ] { }
+error: attribute 'd' missing
+]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.attrValues">
+  <title><function>lib.attrsets.attrValues</function></title>
+
+  <subtitle><literal>attrValues :: AttrSet -> [Any]</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.attrValues" />
+
+  <para>
+   Get all the attribute values from an attribute set.
+  </para>
+
+  <para>
+   Provides a backwards-compatible interface of
+   <function>builtins.attrValues</function> for Nix version older than 1.8.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>attrs</varname>
+    </term>
+    <listitem>
+     <para>
+      The attribute set.
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.attrValues-example">
+   <title></title>
+<programlisting><![CDATA[
+lib.attrsets.attrValues { a = 1; b = 2; c = 3; }
+=> [ 1 2 3 ]
+]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.catAttrs">
+  <title><function>lib.attrsets.catAttrs</function></title>
+
+  <subtitle><literal>catAttrs :: String -> AttrSet -> [Any]</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.catAttrs" />
+
+  <para>
+   Collect each attribute named `attr' from the list of attribute sets,
+   <varname>sets</varname>. Sets that don't contain the named attribute are
+   ignored.
+  </para>
+
+  <para>
+   Provides a backwards-compatible interface of
+   <function>builtins.catAttrs</function> for Nix version older than 1.9.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>attr</varname>
+    </term>
+    <listitem>
+     <para>
+      Attribute name to select from each attribute set in
+      <varname>sets</varname>.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>sets</varname>
+    </term>
+    <listitem>
+     <para>
+      The list of attribute sets to select <varname>attr</varname> from.
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.catAttrs-example">
+   <title>Collect an attribute from a list of attribute sets.</title>
+   <para>
+    Attribute sets which don't have the attribute are ignored.
+   </para>
+<programlisting><![CDATA[
+catAttrs "a" [{a = 1;} {b = 0;} {a = 2;}]
+=> [ 1 2 ]
+      ]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.filterAttrs">
+  <title><function>lib.attrsets.filterAttrs</function></title>
+
+  <subtitle><literal>filterAttrs :: (String -> Any -> Bool) -> AttrSet -> AttrSet</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.filterAttrs" />
+
+  <para>
+   Filter an attribute set by removing all attributes for which the given
+   predicate return false.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>pred</varname>
+    </term>
+    <listitem>
+     <para>
+      <literal>String -> Any -> Bool</literal>
+     </para>
+     <para>
+      Predicate which returns true to include an attribute, or returns false to
+      exclude it.
+     </para>
+     <variablelist>
+      <varlistentry>
+       <term>
+        <varname>name</varname>
+       </term>
+       <listitem>
+        <para>
+         The attribute's name
+        </para>
+       </listitem>
+      </varlistentry>
+      <varlistentry>
+       <term>
+        <varname>value</varname>
+       </term>
+       <listitem>
+        <para>
+         The attribute's value
+        </para>
+       </listitem>
+      </varlistentry>
+     </variablelist>
+     <para>
+      Returns <literal>true</literal> to include the attribute,
+      <literal>false</literal> to exclude the attribute.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>set</varname>
+    </term>
+    <listitem>
+     <para>
+      The attribute set to filter
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.filterAttrs-example">
+   <title>Filtering an attributeset</title>
+<programlisting><![CDATA[
+filterAttrs (n: v: n == "foo") { foo = 1; bar = 2; }
+=> { foo = 1; }
+]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.filterAttrsRecursive">
+  <title><function>lib.attrsets.filterAttrsRecursive</function></title>
+
+  <subtitle><literal>filterAttrsRecursive :: (String -> Any -> Bool) -> AttrSet -> AttrSet</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.filterAttrsRecursive" />
+
+  <para>
+   Filter an attribute set recursively by removing all attributes for which the
+   given predicate return false.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>pred</varname>
+    </term>
+    <listitem>
+     <para>
+      <literal>String -> Any -> Bool</literal>
+     </para>
+     <para>
+      Predicate which returns true to include an attribute, or returns false to
+      exclude it.
+     </para>
+     <variablelist>
+      <varlistentry>
+       <term>
+        <varname>name</varname>
+       </term>
+       <listitem>
+        <para>
+         The attribute's name
+        </para>
+       </listitem>
+      </varlistentry>
+      <varlistentry>
+       <term>
+        <varname>value</varname>
+       </term>
+       <listitem>
+        <para>
+         The attribute's value
+        </para>
+       </listitem>
+      </varlistentry>
+     </variablelist>
+     <para>
+      Returns <literal>true</literal> to include the attribute,
+      <literal>false</literal> to exclude the attribute.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>set</varname>
+    </term>
+    <listitem>
+     <para>
+      The attribute set to filter
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.filterAttrsRecursive-example">
+   <title>Recursively filtering an attribute set</title>
+<programlisting><![CDATA[
+lib.attrsets.filterAttrsRecursive
+  (n: v: v != null)
+  {
+    levelA = {
+      example = "hi";
+      levelB = {
+        hello = "there";
+        this-one-is-present = {
+          this-is-excluded = null;
+        };
+      };
+      this-one-is-also-excluded = null;
+    };
+    also-excluded = null;
+  }
+=> {
+     levelA = {
+       example = "hi";
+       levelB = {
+         hello = "there";
+         this-one-is-present = { };
+       };
+     };
+   }
+     ]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.foldAttrs">
+  <title><function>lib.attrsets.foldAttrs</function></title>
+
+  <subtitle><literal>foldAttrs :: (Any -> Any -> Any) -> Any -> [AttrSets] -> Any</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.foldAttrs" />
+
+  <para>
+   Apply fold function to values grouped by key.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>op</varname>
+    </term>
+    <listitem>
+     <para>
+      <literal>Any -> Any -> Any</literal>
+     </para>
+     <para>
+      Given a value <varname>val</varname> and a collector
+      <varname>col</varname>, combine the two.
+     </para>
+     <variablelist>
+      <varlistentry>
+       <term>
+        <varname>val</varname>
+       </term>
+       <listitem>
+        <para>
+         An attribute's value
+        </para>
+       </listitem>
+      </varlistentry>
+      <varlistentry>
+       <term>
+        <varname>col</varname>
+       </term>
+       <listitem>
+<!-- TODO: make this not bad, use more fold-ey terms -->
+        <para>
+         The result of previous <function>op</function> calls with other values
+         and <function>nul</function>.
+        </para>
+       </listitem>
+      </varlistentry>
+     </variablelist>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>nul</varname>
+    </term>
+    <listitem>
+     <para>
+      The null-value, the starting value.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>list_of_attrs</varname>
+    </term>
+    <listitem>
+     <para>
+      A list of attribute sets to fold together by key.
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.foldAttrs-example">
+   <title>Combining an attribute of lists in to one attribute set</title>
+<programlisting><![CDATA[
+lib.attrsets.foldAttrs
+  (n: a: [n] ++ a) []
+  [
+    { a = 2; b = 7; }
+    { a = 3; }
+    { b = 6; }
+  ]
+=> { a = [ 2 3 ]; b = [ 7 6 ]; }
+]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.collect">
+  <title><function>lib.attrsets.collect</function></title>
+
+  <subtitle><literal>collect :: (Any -> Bool) -> AttrSet -> [Any]</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.collect" />
+
+  <para>
+   Recursively collect sets that verify a given predicate named
+   <varname>pred</varname> from the set <varname>attrs</varname>. The recursion
+   stops when <varname>pred</varname> returns <literal>true</literal>.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>pred</varname>
+    </term>
+    <listitem>
+     <para>
+      <literal>Any -> Bool</literal>
+     </para>
+     <para>
+      Given an attribute's value, determine if recursion should stop.
+     </para>
+     <variablelist>
+      <varlistentry>
+       <term>
+        <varname>value</varname>
+       </term>
+       <listitem>
+        <para>
+         The attribute set value.
+        </para>
+       </listitem>
+      </varlistentry>
+     </variablelist>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>attrs</varname>
+    </term>
+    <listitem>
+     <para>
+      The attribute set to recursively collect.
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.collect-example-lists">
+   <title>Collecting all lists from an attribute set</title>
+<programlisting><![CDATA[
+lib.attrsets.collect isList { a = { b = ["b"]; }; c = [1]; }
+=> [["b"] [1]]
+]]></programlisting>
+  </example>
+
+  <example xml:id="function-library-lib.attrsets.collect-example-outpath">
+   <title>Collecting all attribute-sets which contain the <literal>outPath</literal> attribute name.</title>
+<programlisting><![CDATA[
+collect (x: x ? outPath)
+  { a = { outPath = "a/"; }; b = { outPath = "b/"; }; }
+=> [{ outPath = "a/"; } { outPath = "b/"; }]
+]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.nameValuePair">
+  <title><function>lib.attrsets.nameValuePair</function></title>
+
+  <subtitle><literal>nameValuePair :: String -> Any -> AttrSet</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.nameValuePair" />
+
+  <para>
+   Utility function that creates a <literal>{name, value}</literal> pair as
+   expected by <function>builtins.listToAttrs</function>.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>name</varname>
+    </term>
+    <listitem>
+     <para>
+      The attribute name.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>value</varname>
+    </term>
+    <listitem>
+     <para>
+      The attribute value.
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.nameValuePair-example">
+   <title>Creating a name value pair</title>
+<programlisting><![CDATA[
+nameValuePair "some" 6
+=> { name = "some"; value = 6; }
+]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.mapAttrs">
+  <title><function>lib.attrsets.mapAttrs</function></title>
+
+  <subtitle><literal></literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrs" />
+
+  <para>
+   Apply a function to each element in an attribute set, creating a new
+   attribute set.
+  </para>
+
+  <para>
+   Provides a backwards-compatible interface of
+   <function>builtins.mapAttrs</function> for Nix version older than 2.1.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>fn</varname>
+    </term>
+    <listitem>
+     <para>
+      <literal>String -> Any -> Any</literal>
+     </para>
+     <para>
+      Given an attribute's name and value, return a new value.
+     </para>
+     <variablelist>
+      <varlistentry>
+       <term>
+        <varname>name</varname>
+       </term>
+       <listitem>
+        <para>
+         The name of the attribute.
+        </para>
+       </listitem>
+      </varlistentry>
+      <varlistentry>
+       <term>
+        <varname>value</varname>
+       </term>
+       <listitem>
+        <para>
+         The attribute's value.
+        </para>
+       </listitem>
+      </varlistentry>
+     </variablelist>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.mapAttrs-example">
+   <title>Modifying each value of an attribute set</title>
+<programlisting><![CDATA[
+lib.attrsets.mapAttrs
+  (name: value: name + "-" value)
+  { x = "foo"; y = "bar"; }
+=> { x = "x-foo"; y = "y-bar"; }
+]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.mapAttrs-prime">
+  <title><function>lib.attrsets.mapAttrs&apos;</function></title>
+
+  <subtitle><literal>mapAttrs' :: (String -> Any -> { name = String; value = Any }) -> AttrSet -> AttrSet</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrs-prime" />
+
+  <para>
+   Like <function>mapAttrs</function>, but allows the name of each attribute to
+   be changed in addition to the value. The applied function should return both
+   the new name and value as a <function>nameValuePair</function>.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>fn</varname>
+    </term>
+    <listitem>
+     <para>
+      <literal>String -> Any -> { name = String; value = Any }</literal>
+     </para>
+     <para>
+      Given an attribute's name and value, return a new
+      <link
+       linkend="function-library-lib.attrsets.nameValuePair">name
+      value pair</link>.
+     </para>
+     <variablelist>
+      <varlistentry>
+       <term>
+        <varname>name</varname>
+       </term>
+       <listitem>
+        <para>
+         The name of the attribute.
+        </para>
+       </listitem>
+      </varlistentry>
+      <varlistentry>
+       <term>
+        <varname>value</varname>
+       </term>
+       <listitem>
+        <para>
+         The attribute's value.
+        </para>
+       </listitem>
+      </varlistentry>
+     </variablelist>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>set</varname>
+    </term>
+    <listitem>
+     <para>
+      The attribute set to map over.
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.mapAttrs-prime-example">
+   <title>Change the name and value of each attribute of an attribute set</title>
+<programlisting><![CDATA[
+lib.attrsets.mapAttrs' (name: value: lib.attrsets.nameValuePair ("foo_" + name) ("bar-" + value))
+   { x = "a"; y = "b"; }
+=> { foo_x = "bar-a"; foo_y = "bar-b"; }
+
+    ]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.mapAttrsToList">
+  <title><function>lib.attrsets.mapAttrsToList</function></title>
+
+  <subtitle><literal>mapAttrsToList :: (String -> Any -> Any) ->
+   AttrSet -> Any</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrsToList" />
+
+  <para>
+   Call <varname>fn</varname> for each attribute in the given
+   <varname>set</varname> and return the result in a list.
+  </para>
+
+  <variablelist>
+   <varlistentry>
+    <term>
+     <varname>fn</varname>
+    </term>
+    <listitem>
+     <para>
+      <literal>String -> Any -> Any</literal>
+     </para>
+     <para>
+      Given an attribute's name and value, return a new value.
+     </para>
+     <variablelist>
+      <varlistentry>
+       <term>
+        <varname>name</varname>
+       </term>
+       <listitem>
+        <para>
+         The name of the attribute.
+        </para>
+       </listitem>
+      </varlistentry>
+      <varlistentry>
+       <term>
+        <varname>value</varname>
+       </term>
+       <listitem>
+        <para>
+         The attribute's value.
+        </para>
+       </listitem>
+      </varlistentry>
+     </variablelist>
+    </listitem>
+   </varlistentry>
+   <varlistentry>
+    <term>
+     <varname>set</varname>
+    </term>
+    <listitem>
+     <para>
+      The attribute set to map over.
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+
+  <example xml:id="function-library-lib.attrsets.mapAttrsToList-example">
+   <title>Combine attribute values and names in to a list</title>
+<programlisting><![CDATA[
+lib.attrsets.mapAttrsToList (name: value: "${name}=${value}")
+   { x = "a"; y = "b"; }
+=> [ "x=a" "y=b" ]
+]]></programlisting>
+  </example>
+ </section>
+
+ <section xml:id="function-library-lib.attrsets.mapAttrsRecursive">
+  <title><function>lib.attrsets.mapAttrsRecursive</function></title>
+
+  <subtitle><literal>mapAttrsRecursive :: ([String] > Any -> Any) -> AttrSet -> AttrSet</literal>
+  </subtitle>
+
+  <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrsRecursive" />
+
+  <para>
+   Like <function>mapAttrs</function>, except that it recursively applies
+   itself to attribute sets. Also, the first argument of the argument function
+   is a <emphasis>list</emphasis> of the names of the containing attributes.
+  </para>
+ </section>
+</section>

doc/functions/overrides.xml

@@ -0,0 +1,193 @@
+<section xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xmlns:xi="http://www.w3.org/2001/XInclude"
+         xml:id="sec-overrides">
+ <title>Overriding</title>
+
+ <para>
+  Sometimes one wants to override parts of <literal>nixpkgs</literal>, e.g.
+  derivation attributes, the results of derivations or even the whole package
+  set.
+ </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>).
+  </para>
+
+  <para>
+   It is used to override the arguments passed to a function.
+  </para>
+
+  <para>
+   Example usages:
+<programlisting>pkgs.foo.override { arg1 = val1; arg2 = val2; ... }</programlisting>
+<programlisting>import pkgs.path { overlays = [ (self: super: {
+    foo = super.foo.override { barSupport = true ; };
+  })]};</programlisting>
+<programlisting>mypkg = pkgs.callPackage ./mypkg.nix {
+    mydep = pkgs.mydep.override { ... };
+  }</programlisting>
+  </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.
+  </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>.
+  </para>
+
+  <para>
+   Example usage:
+<programlisting>helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
+    separateDebugInfo = true;
+  });</programlisting>
+  </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.
+  </para>
+
+  <para>
+   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>sdenv.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 involves less typing.
+   </para>
+  </note>
+ </section>
+
+ <section xml:id="sec-pkg-overrideDerivation">
+  <title>&lt;pkg&gt;.overrideDerivation</title>
+
+  <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>.
+   </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>.
+   </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.
+  </para>
+
+  <para>
+   Example usage:
+<programlisting>mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
+    name = "sed-4.2.2-pre";
+    src = fetchurl {
+      url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2;
+      sha256 = "11nq06d131y4wmf3drm0yk502d2xc6n5qy82cg88rb9nqd2lj41k";
+    };
+    patches = [];
+  });</programlisting>
+  </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.
+  </para>
+
+  <para>
+   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.
+   </para>
+  </note>
+ </section>
+
+ <section xml:id="sec-lib-makeOverridable">
+  <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.
+  </para>
+
+  <para>
+   Example usage:
+<programlisting>f = { a, b }: { result = a+b; }
+  c = lib.makeOverridable f { a = 1; b = 2; }</programlisting>
+  </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.
+  </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.
+  </para>
+ </section>
+</section>

doc/functions/shell.xml

@@ -0,0 +1,26 @@
+<section xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xmlns:xi="http://www.w3.org/2001/XInclude"
+         xml:id="sec-pkgs-mkShell">
+ <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>.
+ </para>
+
+ <section xml:id="sec-pkgs-mkShell-usage">
+  <title>Usage</title>
+
+<programlisting><![CDATA[
+{ pkgs ? import <nixpkgs> {} }:
+pkgs.mkShell {
+  # this will make all the build inputs from hello and gnutar
+  # available to the shell environment
+  inputsFrom = with pkgs; [ hello gnutar ];
+  buildInputs = [ pkgs.gnumake ];
+}
+]]></programlisting>
+ </section>
+</section>

doc/languages-frameworks/rust.section.md

@@ -64,9 +64,6 @@ When the `Cargo.lock`, provided by upstream, is not in sync with the
 added in `cargoPatches` will also be prepended to the patches in `patches` at
 build-time.
 
-To install crates with nix there is also an experimental project called
-[nixcrates](https://github.com/fractalide/nixcrates).
-
 ## Compiling Rust crates using Nix instead of Cargo
 
 ### Simple operation

doc/languages-frameworks/vim.section.md

@@ -5,11 +5,16 @@ date: 2016-06-25
 ---
 # User's Guide to Vim Plugins/Addons/Bundles/Scripts in Nixpkgs
 
-You'll get a vim(-your-suffix) in PATH also loading the plugins you want.
+Both Neovim and Vim can be configured to include your favorite plugins
+and additional libraries.
+
 Loading can be deferred; see examples.
 
-Vim packages, VAM (=vim-addon-manager) and Pathogen are supported to load
-packages.
+At the moment we support three different methods for managing plugins:
+
+- Vim packages (*recommend*)
+- VAM (=vim-addon-manager)
+- Pathogen
 
 ## Custom configuration
 
@@ -25,7 +30,19 @@ vim_configurable.customize {
 }
 ```
 
-## Vim packages
+For Neovim the `configure` argument can be overridden to achieve the same:
+
+```
+neovim.override {
+  configure = {
+    customRC = ''
+      # here your custom configuration goes!
+    '';
+  };
+}
+```
+
+## Managing plugins with Vim packages
 
 To store you plugins in Vim packages the following example can be used:
 
@@ -38,13 +55,50 @@ vim_configurable.customize {
     opt = [ phpCompletion elm-vim ];
     # To automatically load a plugin when opening a filetype, add vimrc lines like:
     # autocmd FileType php :packadd phpCompletion
-  }
-};
+  };
+}
 ```
 
-## VAM
+For Neovim the syntax is
 
-### dependencies by Vim plugins
+```
+neovim.override {
+  configure = {
+    customRC = ''
+      # here your custom configuration goes!
+    '';
+    packages.myVimPackage = with pkgs.vimPlugins; {
+      # see examples below how to use custom packages
+      start = [ ];
+      opt = [ ];
+    };
+  };
+}
+```
+
+The resulting package can be added to `packageOverrides` in `~/.nixpkgs/config.nix` to make it installable:
+
+```
+{
+  packageOverrides = pkgs: with pkgs; {
+    myVim = vim_configurable.customize {
+      name = "vim-with-plugins";
+      # add here code from the example section
+    };
+    myNeovim = neovim.override {
+      configure = {
+      # add here code from the example section
+      };
+    };
+  };
+}
+```
+
+After that you can install your special grafted `myVim` or `myNeovim` packages.
+
+## Managing plugins with VAM
+
+### Handling dependencies of Vim plugins
 
 VAM introduced .json files supporting dependencies without versioning
 assuming that "using latest version" is ok most of the time.

doc/lib-function-locations.nix

@@ -0,0 +1,85 @@
+{ pkgs ? (import ./.. { }), nixpkgs ? { }}:
+let
+  revision = pkgs.lib.trivial.revisionWithDefault (nixpkgs.revision or "master");
+
+  libDefPos = set:
+    builtins.map
+      (name: {
+        name = name;
+        location = builtins.unsafeGetAttrPos name set;
+      })
+      (builtins.attrNames set);
+
+  libset = toplib:
+    builtins.map
+      (subsetname: {
+        subsetname = subsetname;
+        functions = libDefPos toplib."${subsetname}";
+      })
+      (builtins.filter
+        (name: builtins.isAttrs toplib."${name}")
+        (builtins.attrNames toplib));
+
+  nixpkgsLib = pkgs.lib;
+
+  flattenedLibSubset = { subsetname, functions }:
+  builtins.map
+    (fn: {
+      name = "lib.${subsetname}.${fn.name}";
+      value = fn.location;
+    })
+    functions;
+
+  locatedlibsets = libs: builtins.map flattenedLibSubset (libset libs);
+  removeFilenamePrefix = prefix: filename:
+    let
+    prefixLen = (builtins.stringLength prefix) + 1; # +1 to remove the leading /
+      filenameLen = builtins.stringLength filename;
+      substr = builtins.substring prefixLen filenameLen filename;
+      in substr;
+
+  removeNixpkgs = removeFilenamePrefix (builtins.toString pkgs.path);
+
+  liblocations =
+    builtins.filter
+      (elem: elem.value != null)
+      (nixpkgsLib.lists.flatten
+        (locatedlibsets nixpkgsLib));
+
+  fnLocationRelative = { name, value }:
+    {
+      inherit name;
+      value = value // { file = removeNixpkgs value.file; };
+    };
+
+  relativeLocs = (builtins.map fnLocationRelative liblocations);
+  sanitizeId = builtins.replaceStrings
+    [ "'"      ]
+    [ "-prime" ];
+
+  urlPrefix = "https://github.com/NixOS/nixpkgs/blob/${revision}";
+  xmlstrings = (nixpkgsLib.strings.concatMapStrings
+      ({ name, value }:
+      ''
+      <section><title>${name}</title>
+        <para xml:id="${sanitizeId name}">
+        Located at
+        <link
+          xlink:href="${urlPrefix}/${value.file}#L${builtins.toString value.line}">${value.file}:${builtins.toString value.line}</link>
+        in  <literal>&lt;nixpkgs&gt;</literal>.
+        </para>
+        </section>
+      '')
+      relativeLocs);
+
+in pkgs.writeText
+    "locations.xml"
+    ''
+    <section xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         version="5">
+         <title>All the locations for every lib function</title>
+         <para>This file is only for inclusion by other files.</para>
+         ${xmlstrings}
+    </section>
+    ''

doc/package-notes.xml

@@ -671,6 +671,9 @@ overrides = self: super: rec {
     plugins = with availablePlugins; [ python perl ];
   }
 }</programlisting>
+   If the <literal>configure</literal> function returns an attrset without the
+   <literal>plugins</literal> attribute, <literal>availablePlugins</literal>
+   will be used automatically.
   </para>
 
   <para>
@@ -704,6 +707,61 @@ overrides = self: super: rec {
 }; }
 </programlisting>
   </para>
+
+  <para>
+   WeeChat allows to set defaults on startup using the
+   <literal>--run-command</literal>. The <literal>configure</literal> method
+   can be used to pass commands to the program:
+<programlisting>weechat.override {
+  configure = { availablePlugins, ... }: {
+    init = ''
+      /set foo bar
+      /server add freenode chat.freenode.org
+    '';
+  };
+}</programlisting>
+   Further values can be added to the list of commands when running
+   <literal>weechat --run-command "your-commands"</literal>.
+  </para>
+
+  <para>
+   Additionally it's possible to specify scripts to be loaded when starting
+   <literal>weechat</literal>. These will be loaded before the commands from
+   <literal>init</literal>:
+<programlisting>weechat.override {
+  configure = { availablePlugins, ... }: {
+    scripts = with pkgs.weechatScripts; [
+      weechat-xmpp weechat-matrix-bridge wee-slack
+    ];
+    init = ''
+      /set plugins.var.python.jabber.key "val"
+    '':
+  };
+}</programlisting>
+  </para>
+
+  <para>
+   In <literal>nixpkgs</literal> there's a subpackage which contains
+   derivations for WeeChat scripts. Such derivations expect a
+   <literal>passthru.scripts</literal> attribute which contains a list of all
+   scripts inside the store path. Furthermore all scripts have to live in
+   <literal>$out/share</literal>. An exemplary derivation looks like this:
+<programlisting>{ stdenv, fetchurl }:
+
+stdenv.mkDerivation {
+  name = "exemplary-weechat-script";
+  src = fetchurl {
+    url = "https://scripts.tld/your-scripts.tar.gz";
+    sha256 = "...";
+  };
+  passthru.scripts = [ "foo.py" "bar.lua" ];
+  installPhase = ''
+    mkdir $out/share
+    cp foo.py $out/share
+    cp bar.lua $out/share
+  '';
+}</programlisting>
+  </para>
  </section>
  <section xml:id="sec-citrix">
   <title>Citrix Receiver</title>

doc/shell.nix

@@ -1,5 +1,5 @@
 { pkgs ? import ../. {} }:
-(import ./default.nix).overrideAttrs (x: {
+(import ./default.nix {}).overrideAttrs (x: {
   buildInputs = x.buildInputs ++ [ pkgs.xmloscopy pkgs.ruby ];
 
 })

doc/shell.section.md

@@ -1,22 +0,0 @@
----
-title: pkgs.mkShell
-author: zimbatm
-date: 2017-10-30
----
-
-# mkShell
-
-pkgs.mkShell is a special kind of derivation that is only useful when using
-it combined with nix-shell. It will in fact fail to instantiate when invoked
-with nix-build.
-
-## Usage
-
-```nix
-{ pkgs ? import <nixpkgs> {} }:
-pkgs.mkShell {
-  # this will make all the build inputs from hello and gnutar available to the shell environment
-  inputsFrom = with pkgs; [ hello gnutar ];
-  buildInputs = [ pkgs.gnumake ];
-}
-```

lib/licenses.nix

@@ -355,6 +355,11 @@ lib.mapAttrs (n: v: v // { shortName = n; }) rec {
     fullName = "Independent JPEG Group License";
   };
 
+  imagemagick = spdx {
+    fullName = "ImageMagick License";
+    spdxId = "imagemagick";
+  };
+
   inria-compcert = {
     fullName  = "INRIA Non-Commercial License Agreement for the CompCert verified compiler";
     url       = "http://compcert.inria.fr/doc/LICENSE";

lib/minver.nix

@@ -1,2 +1,2 @@
 # Expose the minimum required version for evaluating Nixpkgs
-"2.0"
+"1.11"

lib/trivial.nix

@@ -36,18 +36,18 @@ rec {
 
   /* bitwise “and” */
   bitAnd = builtins.bitAnd
-    or import ./zip-int-bits.nix
-      (a: b: if a==1 && b==1 then 1 else 0);
+    or (import ./zip-int-bits.nix
+        (a: b: if a==1 && b==1 then 1 else 0));
 
   /* bitwise “or” */
   bitOr = builtins.bitOr
-    or import ./zip-int-bits.nix
-      (a: b: if a==1 || b==1 then 1 else 0);
+    or (import ./zip-int-bits.nix
+        (a: b: if a==1 || b==1 then 1 else 0));
 
   /* bitwise “xor” */
   bitXor = builtins.bitXor
-    or import ./zip-int-bits.nix
-      (a: b: if a!=b then 1 else 0);
+    or (import ./zip-int-bits.nix
+        (a: b: if a!=b then 1 else 0));
 
   /* bitwise “not” */
   bitNot = builtins.sub (-1);
@@ -105,6 +105,16 @@ rec {
     then lib.strings.fileContents suffixFile
     else "pre-git";
 
+  # Attempt to get the revision nixpkgs is from
+  revisionWithDefault = default:
+    let
+      revisionFile = "${toString ./..}/.git-revision";
+      gitRepo      = "${toString ./..}/.git";
+    in if lib.pathIsDirectory gitRepo
+       then lib.commitIdFromGitRepo gitRepo
+       else if lib.pathExists revisionFile then lib.fileContents revisionFile
+       else default;
+
   nixpkgsVersion = builtins.trace "`lib.nixpkgsVersion` is deprecated, use `lib.version` instead!" version;
 
   # Whether we're being called by nix-shell.

maintainers/maintainer-list.nix

@@ -18,6 +18,11 @@
   for an example on how to work with this data.
   */
 {
+  "1000101" = {
+    email = "jan.hrnko@satoshilabs.com";
+    github = "1000101";
+    name = "Jan Hrnko";
+  };
   a1russell = {
     email = "adamlr6+pub@gmail.com";
     github = "a1russell";
@@ -3259,6 +3264,11 @@
     github = "proglodyte";
     name = "Proglodyte";
   };
+  prusnak = {
+    email = "stick@gk2.sk";
+    github = "prusnak";
+    name = "Pavol Rusnak";
+  };
   pshendry = {
     email = "paul@pshendry.com";
     github = "pshendry";
@@ -3888,6 +3898,11 @@
     github = "StillerHarpo";
     name = "Florian Engel";
   };
+  stites = {
+    email = "sam@stites.io";
+    github = "stites";
+    name = "Sam Stites";
+  };
   stumoss = {
     email = "samoss@gmail.com";
     github = "stumoss";

nixos/doc/manual/Makefile

@@ -4,7 +4,7 @@ all: manual-combined.xml format
 .PHONY: debug
 debug: generated manual-combined.xml
 
-manual-combined.xml: generated *.xml
+manual-combined.xml: generated *.xml **/*.xml
 	rm -f ./manual-combined.xml
 	nix-shell --packages xmloscopy \
 		--run "xmloscopy --docbook5 ./manual.xml ./manual-combined.xml"

nixos/doc/manual/administration/imperative-containers.xml

@@ -73,8 +73,7 @@ Linux foo 3.4.82 #1-NixOS SMP Thu Mar 20 14:44:05 UTC 2014 x86_64 GNU/Linux
  </para>
 
  <para>
-  There are several ways to change the configuration of the container. First,
-  on the host, you can edit
+  To change the configuration of the container, you can edit
   <literal>/var/lib/container/<replaceable>name</replaceable>/etc/nixos/configuration.nix</literal>,
   and run
 <screen>
@@ -87,8 +86,7 @@ Linux foo 3.4.82 #1-NixOS SMP Thu Mar 20 14:44:05 UTC 2014 x86_64 GNU/Linux
   <xref linkend="opt-services.httpd.enable"/> = true;
   <xref linkend="opt-services.httpd.adminAddr"/> = "foo@example.org";
   <xref linkend="opt-networking.firewall.allowedTCPPorts"/> = [ 80 ];
-'
-
+  '
 # curl http://$(nixos-container show-ip foo)/
 &lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">…
 </screen>
@@ -97,11 +95,13 @@ Linux foo 3.4.82 #1-NixOS SMP Thu Mar 20 14:44:05 UTC 2014 x86_64 GNU/Linux
  </para>
 
  <para>
-  Alternatively, you can change the configuration from within the container
-  itself by running <command>nixos-rebuild switch</command> inside the
-  container. Note that the container by default does not have a copy of the
-  NixOS channel, so you should run <command>nix-channel --update</command>
-  first.
+  Note that in previous versions of NixOS (17.09 and earlier) one could also
+  use all nix-related commands (like <command>nixos-rebuild switch</command>)
+  from inside the container. However, since the release of Nix 2.0 this is not
+  supported anymore. Supporting Nix commands inside the container might be
+  possible again in future versions. See
+  <link xlink:href="https://github.com/NixOS/nixpkgs/issues/40355">the github
+  issue</link> for tracking progress on this issue.
  </para>
 
  <para>

nixos/doc/manual/configuration/linux-kernel.xml

@@ -84,18 +84,17 @@ nixpkgs.config.packageOverrides = pkgs:
     allowImportFromDerivation = true;
   };
   ]]></screen>
-
-You can edit the config with this snippet (by default <command>make menuconfig</command> won't work
-  out of the box on nixos):
-  <screen><![CDATA[
+   You can edit the config with this snippet (by default <command>make
+   menuconfig</command> won't work out of the box on nixos):
+<screen><![CDATA[
       nix-shell -E 'with import <nixpkgs> {}; kernelToOverride.overrideAttrs (o: {nativeBuildInputs=o.nativeBuildInputs ++ [ pkgconfig ncurses ];})'
   ]]></screen>
-
-
-  or you can let nixpkgs generate the configuration.
-  Nixpkgs generates it via answering the interactive kernel utility <command>make config</command>.
-  The answers depend on parameters passed to <filename>pkgs/os-specific/linux/kernel/generic.nix</filename>
-  (which you can influence by overriding <literal>extraConfig, autoModules, modDirVersion, preferBuiltin, extraConfig</literal>).
+   or you can let nixpkgs generate the configuration. Nixpkgs generates it via
+   answering the interactive kernel utility <command>make config</command>. The
+   answers depend on parameters passed to
+   <filename>pkgs/os-specific/linux/kernel/generic.nix</filename> (which you
+   can influence by overriding <literal>extraConfig, autoModules,
+   modDirVersion, preferBuiltin, extraConfig</literal>).
 <screen><![CDATA[
 
   mptcp93.override ({

nixos/doc/manual/default.nix

@@ -90,7 +90,9 @@ let
     fi
     ${buildPackages.libxslt.bin}/bin/xsltproc \
       --stringparam revision '${revision}' \
-      -o $out ${./options-to-docbook.xsl} $optionsXML
+      -o intermediate.xml ${./options-to-docbook.xsl} $optionsXML
+    ${buildPackages.libxslt.bin}/bin/xsltproc \
+      -o "$out" ${./postprocess-option-descriptions.xsl} intermediate.xml
   '';
 
   sources = lib.sourceFilesBySuffices ./. [".xml"];

nixos/doc/manual/development/debugging-nixos-tests.xml

@@ -0,0 +1,37 @@
+<section xmlns="http://docbook.org/ns/docbook"
+        xmlns:xlink="http://www.w3.org/1999/xlink"
+        xmlns:xi="http://www.w3.org/2001/XInclude"
+        version="5.0"
+        xml:id="sec-debugging-nixos-tests">
+ <title>Debugging NixOS tests</title>
+
+ <para>
+  Tests may fail and infrastructure offers access to inspect machine state.
+ </para>
+
+ <para>
+  To prevent test from stopping and cleaning up, insert a sleep command:
+ </para>
+
+<programlisting>
+$machine->succeed("sleep 84000");
+</programlisting>
+
+ <para>
+  As soon as machine starts run as root:
+ </para>
+
+<programlisting>
+nix-shell -p socat --run "socat STDIO,raw,echo=0,escape=0x11 UNIX:/tmp/nix-build-vm-test-run-*.drv-0/vm-state-machine/backdoor"
+</programlisting>
+
+ <para>
+  You may need to find the correct path, replacing <literal>/tmp</literal>,
+  <literal>*</literal> or <literal>machine</literal>.
+ </para>
+
+ <para>
+  Press "enter" to open up console and login as "root". After you're done,
+  press "ctrl-q" to exit the console.
+ </para>
+</section>

nixos/doc/manual/development/nixos-tests.xml

@@ -16,4 +16,5 @@ xlink:href="https://github.com/NixOS/nixpkgs/tree/master/nixos/tests">nixos/test
  <xi:include href="writing-nixos-tests.xml" />
  <xi:include href="running-nixos-tests.xml" />
  <xi:include href="running-nixos-tests-interactively.xml" />
+ <xi:include href="debugging-nixos-tests.xml" />
 </chapter>

nixos/doc/manual/installation/installing-behind-a-proxy.xml

@@ -5,28 +5,29 @@
          xml:id="sec-installing-behind-proxy">
  <title>Installing behind a proxy</title>
 
-<para>
+ <para>
   To install NixOS behind a proxy, do the following before running
   <literal>nixos-install</literal>.
-</para>
-<orderedlist numeration="arabic">
+ </para>
+
+ <orderedlist numeration="arabic">
   <listitem>
-    <para>
-      Update proxy configuration in
-      <literal>/mnt/etc/nixos/configuration.nix</literal> to keep the
-      internet accessible after reboot.
-    </para>
-    <programlisting>
+   <para>
+    Update proxy configuration in
+    <literal>/mnt/etc/nixos/configuration.nix</literal> to keep the internet
+    accessible after reboot.
+   </para>
+<programlisting>
 networking.proxy.default = &quot;http://user:password@proxy:port/&quot;;
 networking.proxy.noProxy = &quot;127.0.0.1,localhost,internal.domain&quot;;
 </programlisting>
   </listitem>
   <listitem>
-    <para>
-      Setup the proxy environment variables in the shell where you are
-      running <literal>nixos-install</literal>.
-    </para>
-    <programlisting>
+   <para>
+    Setup the proxy environment variables in the shell where you are running
+    <literal>nixos-install</literal>.
+   </para>
+<programlisting>
 # proxy_url=&quot;http://user:password@proxy:port/&quot;
 # export http_proxy=&quot;$proxy_url&quot;
 # export HTTP_PROXY=&quot;$proxy_url&quot;
@@ -34,14 +35,14 @@ networking.proxy.noProxy = &quot;127.0.0.1,localhost,internal.domain&quot;;
 # export HTTPS_PROXY=&quot;$proxy_url&quot;
 </programlisting>
   </listitem>
-</orderedlist>
+ </orderedlist>
 
-<note>
-<para>
-  If you are switching networks with different proxy configurations, use the
-  <literal>nesting.clone</literal> option in
-  <literal>configuration.nix</literal> to switch proxies at runtime.
-  Refer to <xref linkend="ch-options" /> for more information.
-</para>
-</note>
+ <note>
+  <para>
+   If you are switching networks with different proxy configurations, use the
+   <literal>nesting.clone</literal> option in
+   <literal>configuration.nix</literal> to switch proxies at runtime. Refer to
+   <xref linkend="ch-options" /> for more information.
+  </para>
+ </note>
 </section>

nixos/doc/manual/installation/installing-usb.xml

@@ -9,13 +9,12 @@
   For systems without CD drive, the NixOS live CD can be booted from a USB
   stick. You can use the <command>dd</command> utility to write the image:
   <command>dd if=<replaceable>path-to-image</replaceable>
-  of=<replaceable>/dev/sdb</replaceable></command>. Be careful about specifying
+  of=<replaceable>/dev/sdX</replaceable></command>. Be careful about specifying
   the correct drive; you can use the <command>lsblk</command> command to get a
   list of block devices.
- </para>
-
- <para>
-  On macOS:
+  <note>
+   <title>On macOS</title>
+   <para>
 <programlisting>
 $ diskutil list
 [..]
@@ -26,43 +25,16 @@ $ diskutil unmountDisk diskN
 Unmount of all volumes on diskN was successful
 $ sudo dd bs=1m if=nix.iso of=/dev/rdiskN
 </programlisting>
-  Using the 'raw' <command>rdiskN</command> device instead of
-  <command>diskN</command> completes in minutes instead of hours. After
-  <command>dd</command> completes, a GUI dialog "The disk you inserted was not
-  readable by this computer" will pop up, which can be ignored.
+    Using the 'raw' <command>rdiskN</command> device instead of
+    <command>diskN</command> completes in minutes instead of hours. After
+    <command>dd</command> completes, a GUI dialog "The disk you inserted was
+    not readable by this computer" will pop up, which can be ignored.
+   </para>
+  </note>
  </para>
 
  <para>
   The <command>dd</command> utility will write the image verbatim to the drive,
   making it the recommended option for both UEFI and non-UEFI installations.
-  For non-UEFI installations, you can alternatively use
-  <link xlink:href="http://unetbootin.sourceforge.net/">unetbootin</link>. If
-  you cannot use <command>dd</command> for a UEFI installation, you can also
-  mount the ISO, copy its contents verbatim to your drive, then either:
-  <itemizedlist>
-   <listitem>
-    <para>
-     Change the label of the disk partition to the label of the ISO (visible
-     with the blkid command), or
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     Edit <filename>loader/entries/nixos-livecd.conf</filename> on the drive
-     and change the <literal>root=</literal> field in the
-     <literal>options</literal> line to point to your drive (see the
-     documentation on <literal>root=</literal> in
-     <link xlink:href="https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt">
-     the kernel documentation</link> for more details).
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     If you want to load the contents of the ISO to ram after bootin (So you
-     can remove the stick after bootup) you can append the parameter
-     <literal>copytoram</literal> to the <literal>options</literal> field.
-    </para>
-   </listitem>
-  </itemizedlist>
  </para>
 </section>

nixos/doc/manual/installation/installing.xml

@@ -4,60 +4,46 @@
             version="5.0"
             xml:id="sec-installation">
  <title>Installing NixOS</title>
- <para>
-  NixOS can be installed on BIOS or UEFI systems. The procedure for a UEFI
-  installation is by and large the same as a BIOS installation. The differences
-  are mentioned in the steps that follow.
- </para>
- <orderedlist>
-  <listitem>
-   <para>
-    Boot from the CD.
-   </para>
-   <variablelist>
-    <varlistentry>
-     <term>
-      UEFI systems
-     </term>
-     <listitem>
-      <para>
-       You should boot the live CD in UEFI mode (consult your specific
-       hardware's documentation for instructions). You may find the
-       <link xlink:href="http://www.rodsbooks.com/refind">rEFInd boot
-       manager</link> useful.
-      </para>
-     </listitem>
-    </varlistentry>
-   </variablelist>
-  </listitem>
-  <listitem>
-   <para>
-    The CD contains a basic NixOS installation. (It also contains Memtest86+,
-    useful if you want to test new hardware). When it’s finished booting, it
-    should have detected most of your hardware.
-   </para>
-  </listitem>
-  <listitem>
-   <para>
-    The NixOS manual is available on virtual console 8 (press Alt+F8 to access)
-    or by running <command>nixos-help</command>.
-   </para>
-  </listitem>
-  <listitem>
-   <para>
-    You get logged in as <literal>root</literal> (with empty password).
-   </para>
-  </listitem>
-  <listitem>
-   <para>
-    If you downloaded the graphical ISO image, you can run <command>systemctl
-    start display-manager</command> to start KDE. If you want to continue on
-    the terminal, you can use <command>loadkeys</command> to switch to your
-    preferred keyboard layout. (We even provide neo2 via <command>loadkeys de
-    neo</command>!)
-   </para>
-  </listitem>
-  <listitem>
+ <section xml:id="sec-installation-booting">
+  <title>Booting the system</title>
+
+  <para>
+   NixOS can be installed on BIOS or UEFI systems. The procedure for a UEFI
+   installation is by and large the same as a BIOS installation. The
+   differences are mentioned in the steps that follow.
+  </para>
+
+  <para>
+   The installation media can be burned to a CD, or now more commonly, "burned"
+   to a USB drive (see <xref linkend="sec-booting-from-usb"/>).
+  </para>
+
+  <para>
+   The installation media contains a basic NixOS installation. When it’s
+   finished booting, it should have detected most of your hardware.
+  </para>
+
+  <para>
+   The NixOS manual is available on virtual console 8 (press Alt+F8 to access)
+   or by running <command>nixos-help</command>.
+  </para>
+
+  <para>
+   You are logged-in automatically as <literal>root</literal>. (The
+   <literal>root</literal> user account has an empty password.)
+  </para>
+
+  <para>
+   If you downloaded the graphical ISO image, you can run <command>systemctl
+   start display-manager</command> to start KDE. If you want to continue on the
+   terminal, you can use <command>loadkeys</command> to switch to your
+   preferred keyboard layout. (We even provide neo2 via <command>loadkeys de
+   neo</command>!)
+  </para>
+
+  <section xml:id="sec-installation-booting-networking">
+   <title>Networking in the installer</title>
+
    <para>
     The boot process should have brought up networking (check <command>ip
     a</command>). Networking is necessary for the installer, since it will
@@ -65,58 +51,165 @@
     binaries). It’s best if you have a DHCP server on your network. Otherwise
     configure networking manually using <command>ifconfig</command>.
    </para>
+
    <para>
     To manually configure the network on the graphical installer, first disable
     network-manager with <command>systemctl stop network-manager</command>.
    </para>
+
    <para>
     To manually configure the wifi on the minimal installer, run
     <command>wpa_supplicant -B -i interface -c &lt;(wpa_passphrase 'SSID'
     'key')</command>.
    </para>
-  </listitem>
-  <listitem>
+
    <para>
     If you would like to continue the installation from a different machine you
     need to activate the SSH daemon via <literal>systemctl start
     sshd</literal>. In order to be able to login you also need to set a
     password for <literal>root</literal> using <literal>passwd</literal>.
    </para>
-  </listitem>
-  <listitem>
+  </section>
+ </section>
+ <section xml:id="sec-installation-partitioning">
+  <title>Partitioning and formatting</title>
+
+  <para>
+   The NixOS installer doesn’t do any partitioning or formatting, so you need
+   to do that yourself.
+  </para>
+
+  <para>
+   The NixOS installer ships with multiple partitioning tools. The examples
+   below use <command>parted</command>, but also provides
+   <command>fdisk</command>, <command>gdisk</command>,
+   <command>cfdisk</command>, and <command>cgdisk</command>.
+  </para>
+
+  <para>
+   The recommended partition scheme differs depending if the computer uses
+   <emphasis>Legacy Boot</emphasis> or <emphasis>UEFI</emphasis>.
+  </para>
+
+  <section xml:id="sec-installation-partitioning-UEFI">
+   <title>UEFI (GPT)</title>
+
    <para>
-    The NixOS installer doesn’t do any partitioning or formatting yet, so you
-    need to do that yourself. Use the following commands:
-    <itemizedlist>
+    Here's an example partition scheme for UEFI, using
+    <filename>/dev/sda</filename> as the device.
+    <note>
+     <para>
+      You can safely ignore <command>parted</command>'s informational message
+      about needing to update /etc/fstab.
+     </para>
+    </note>
+   </para>
+
+   <para>
+    <orderedlist>
      <listitem>
       <para>
-       For partitioning: <command>fdisk</command>.
-<screen>
-# fdisk /dev/sda # <lineannotation>(or whatever device you want to install on)</lineannotation>
--- for UEFI systems only
-> n      # <lineannotation>(create a new partition for /boot)</lineannotation>
-> 3      # <lineannotation>(make it a partition number 3)</lineannotation>
->        # <lineannotation>(press enter to accept the default)</lineannotation>
-> +512M  # <lineannotation>(the size of the UEFI boot partition)</lineannotation>
-> t      # <lineannotation>(change the partition type ...)</lineannotation>
-> 3      # <lineannotation>(... of the boot partition ...)</lineannotation>
-> 1      # <lineannotation>(... to 'UEFI System')</lineannotation>
--- for BIOS or UEFI systems
-> n      # <lineannotation>(create a new partition for /swap)</lineannotation>
-> 2      # <lineannotation>(make it a partition number 2)</lineannotation>
->        # <lineannotation>(press enter to accept the default)</lineannotation>
-> +8G    # <lineannotation>(the size of the swap partition, set to whatever you like)</lineannotation>
-> n      # <lineannotation>(create a new partition for /)</lineannotation>
-> 1      # <lineannotation>(make it a partition number 1)</lineannotation>
->        # <lineannotation>(press enter to accept the default)</lineannotation>
->        # <lineannotation>(press enter to accept the default and use the rest of the remaining space)</lineannotation>
-> a      # <lineannotation>(make the partition bootable)</lineannotation>
-> x      # <lineannotation>(enter expert mode)</lineannotation>
-> f      # <lineannotation>(fix up the partition ordering)</lineannotation>
-> r      # <lineannotation>(exit expert mode)</lineannotation>
-> w      # <lineannotation>(write the partition table to disk and exit)</lineannotation></screen>
+       Create a <emphasis>GPT</emphasis> partition table.
+<screen language="commands"># parted /dev/sda -- mklabel gpt</screen>
       </para>
      </listitem>
+     <listitem>
+      <para>
+       Add a <emphasis>swap</emphasis> partition. The size required will vary
+       according to needs, here a 8GiB one is created. The space left in front
+       (512MiB) will be used by the boot partition.
+<screen language="commands"># parted /dev/sda -- mkpart primary linux-swap 512MiB 8.5GiB</screen>
+       <note>
+        <para>
+         The swap partition size rules are no different than for other Linux
+         distributions.
+        </para>
+       </note>
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       Next, add the <emphasis>root</emphasis> partition. This will fill the
+       remainder ending part of the disk.
+<screen language="commands"># parted /dev/sda -- mkpart primary 8.5GiB -1MiB</screen>
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       Finally, the <emphasis>boot</emphasis> partition. NixOS by default uses
+       the ESP (EFI system partition) as its <emphasis>/boot</emphasis>
+       partition. It uses the initially reserved 512MiB at the start of the
+       disk.
+<screen language="commands"># parted /dev/sda -- mkpart ESP fat32 1M 512MiB
+# parted /dev/sda -- set 3 boot on</screen>
+      </para>
+     </listitem>
+    </orderedlist>
+   </para>
+
+   <para>
+    Once complete, you can follow with
+    <xref linkend="sec-installation-partitioning-formatting"/>.
+   </para>
+  </section>
+
+  <section xml:id="sec-installation-partitioning-MBR">
+   <title>Legacy Boot (MBR)</title>
+
+   <para>
+    Here's an example partition scheme for Legacy Boot, using
+    <filename>/dev/sda</filename> as the device.
+    <note>
+     <para>
+      You can safely ignore <command>parted</command>'s informational message
+      about needing to update /etc/fstab.
+     </para>
+    </note>
+   </para>
+
+   <para>
+    <orderedlist>
+     <listitem>
+      <para>
+       Create a <emphasis>MBR</emphasis> partition table.
+<screen language="commands"># parted /dev/sda -- mklabel msdos</screen>
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       Add a <emphasis>swap</emphasis> partition. The size required will vary
+       according to needs, here a 8GiB one is created.
+<screen language="commands"># parted /dev/sda -- mkpart primary linux-swap 1M 8GiB</screen>
+       <note>
+        <para>
+         The swap partition size rules are no different than for other Linux
+         distributions.
+        </para>
+       </note>
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       Finally, add the <emphasis>root</emphasis> partition. This will fill the
+       remainder of the disk.
+<screen language="commands"># parted /dev/sda -- mkpart primary 8GiB -1s</screen>
+      </para>
+     </listitem>
+    </orderedlist>
+   </para>
+
+   <para>
+    Once complete, you can follow with
+    <xref linkend="sec-installation-partitioning-formatting"/>.
+   </para>
+  </section>
+
+  <section xml:id="sec-installation-partitioning-formatting">
+   <title>Formatting</title>
+
+   <para>
+    Use the following commands:
+    <itemizedlist>
      <listitem>
       <para>
        For initialising Ext4 partitions: <command>mkfs.ext4</command>. It is
@@ -169,242 +262,249 @@
      </listitem>
     </itemizedlist>
    </para>
-  </listitem>
-  <listitem>
-   <para>
-    Mount the target file system on which NixOS should be installed on
-    <filename>/mnt</filename>, e.g.
+  </section>
+ </section>
+ <section xml:id="sec-installation-installing">
+  <title>Installing</title>
+
+  <orderedlist>
+   <listitem>
+    <para>
+     Mount the target file system on which NixOS should be installed on
+     <filename>/mnt</filename>, e.g.
 <screen>
 # mount /dev/disk/by-label/nixos /mnt
 </screen>
-   </para>
-  </listitem>
-  <listitem>
-   <variablelist>
-    <varlistentry>
-     <term>
-      UEFI systems
-     </term>
-     <listitem>
-      <para>
-       Mount the boot file system on <filename>/mnt/boot</filename>, e.g.
+    </para>
+   </listitem>
+   <listitem>
+    <variablelist>
+     <varlistentry>
+      <term>
+       UEFI systems
+      </term>
+      <listitem>
+       <para>
+        Mount the boot file system on <filename>/mnt/boot</filename>, e.g.
 <screen>
 # mkdir -p /mnt/boot
 # mount /dev/disk/by-label/boot /mnt/boot
 </screen>
-      </para>
-     </listitem>
-    </varlistentry>
-   </variablelist>
-  </listitem>
-  <listitem>
-   <para>
-    If your machine has a limited amount of memory, you may want to activate
-    swap devices now (<command>swapon
-    <replaceable>device</replaceable></command>). The installer (or rather, the
-    build actions that it may spawn) may need quite a bit of RAM, depending on
-    your configuration.
+       </para>
+      </listitem>
+     </varlistentry>
+    </variablelist>
+   </listitem>
+   <listitem>
+    <para>
+     If your machine has a limited amount of memory, you may want to activate
+     swap devices now (<command>swapon
+     <replaceable>device</replaceable></command>). The installer (or rather,
+     the build actions that it may spawn) may need quite a bit of RAM,
+     depending on your configuration.
 <screen>
 # swapon /dev/sda2</screen>
-   </para>
-  </listitem>
-  <listitem>
-   <para>
-    You now need to create a file
-    <filename>/mnt/etc/nixos/configuration.nix</filename> that specifies the
-    intended configuration of the system. This is because NixOS has a
-    <emphasis>declarative</emphasis> configuration model: you create or edit a
-    description of the desired configuration of your system, and then NixOS
-    takes care of making it happen. The syntax of the NixOS configuration file
-    is described in <xref linkend="sec-configuration-syntax"/>, while a list of
-    available configuration options appears in
-    <xref
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     You now need to create a file
+     <filename>/mnt/etc/nixos/configuration.nix</filename> that specifies the
+     intended configuration of the system. This is because NixOS has a
+     <emphasis>declarative</emphasis> configuration model: you create or edit a
+     description of the desired configuration of your system, and then NixOS
+     takes care of making it happen. The syntax of the NixOS configuration file
+     is described in <xref linkend="sec-configuration-syntax"/>, while a list
+     of available configuration options appears in
+     <xref
     linkend="ch-options"/>. A minimal example is shown in
-    <xref
+     <xref
     linkend="ex-config"/>.
-   </para>
-   <para>
-    The command <command>nixos-generate-config</command> can generate an
-    initial configuration file for you:
+    </para>
+    <para>
+     The command <command>nixos-generate-config</command> can generate an
+     initial configuration file for you:
 <screen>
 # nixos-generate-config --root /mnt</screen>
-    You should then edit <filename>/mnt/etc/nixos/configuration.nix</filename>
-    to suit your needs:
+     You should then edit <filename>/mnt/etc/nixos/configuration.nix</filename>
+     to suit your needs:
 <screen>
 # nano /mnt/etc/nixos/configuration.nix
 </screen>
-    If you’re using the graphical ISO image, other editors may be available
-    (such as <command>vim</command>). If you have network access, you can also
-    install other editors — for instance, you can install Emacs by running
-    <literal>nix-env -i emacs</literal>.
-   </para>
-   <variablelist>
-    <varlistentry>
-     <term>
-      BIOS systems
-     </term>
-     <listitem>
-      <para>
-       You <emphasis>must</emphasis> set the option
-       <xref linkend="opt-boot.loader.grub.device"/> to specify on which disk
-       the GRUB boot loader is to be installed. Without it, NixOS cannot boot.
-      </para>
-     </listitem>
-    </varlistentry>
-    <varlistentry>
-     <term>
-      UEFI systems
-     </term>
-     <listitem>
-      <para>
-       You <emphasis>must</emphasis> set the option
-       <xref linkend="opt-boot.loader.systemd-boot.enable"/> to
-       <literal>true</literal>. <command>nixos-generate-config</command> should
-       do this automatically for new configurations when booted in UEFI mode.
-      </para>
-      <para>
-       You may want to look at the options starting with
-       <option><link linkend="opt-boot.loader.efi.canTouchEfiVariables">boot.loader.efi</link></option>
-       and
-       <option><link linkend="opt-boot.loader.systemd-boot.enable">boot.loader.systemd</link></option>
-       as well.
-      </para>
-     </listitem>
-    </varlistentry>
-   </variablelist>
-   <para>
-    If there are other operating systems running on the machine before
-    installing NixOS, the <xref linkend="opt-boot.loader.grub.useOSProber"/>
-    option can be set to <literal>true</literal> to automatically add them to
-    the grub menu.
-   </para>
-   <para>
-    Another critical option is <option>fileSystems</option>, specifying the
-    file systems that need to be mounted by NixOS. However, you typically
-    don’t need to set it yourself, because
-    <command>nixos-generate-config</command> sets it automatically in
-    <filename>/mnt/etc/nixos/hardware-configuration.nix</filename> from your
-    currently mounted file systems. (The configuration file
-    <filename>hardware-configuration.nix</filename> is included from
-    <filename>configuration.nix</filename> and will be overwritten by future
-    invocations of <command>nixos-generate-config</command>; thus, you
-    generally should not modify it.)
-   </para>
-   <note>
-    <para>
-     Depending on your hardware configuration or type of file system, you may
-     need to set the option <option>boot.initrd.kernelModules</option> to
-     include the kernel modules that are necessary for mounting the root file
-     system, otherwise the installed system will not be able to boot. (If this
-     happens, boot from the CD again, mount the target file system on
-     <filename>/mnt</filename>, fix
-     <filename>/mnt/etc/nixos/configuration.nix</filename> and rerun
-     <filename>nixos-install</filename>.) In most cases,
-     <command>nixos-generate-config</command> will figure out the required
-     modules.
+     If you’re using the graphical ISO image, other editors may be available
+     (such as <command>vim</command>). If you have network access, you can also
+     install other editors — for instance, you can install Emacs by running
+     <literal>nix-env -i emacs</literal>.
     </para>
-   </note>
-  </listitem>
-  <listitem>
-   <para>
-    Do the installation:
+    <variablelist>
+     <varlistentry>
+      <term>
+       BIOS systems
+      </term>
+      <listitem>
+       <para>
+        You <emphasis>must</emphasis> set the option
+        <xref linkend="opt-boot.loader.grub.device"/> to specify on which disk
+        the GRUB boot loader is to be installed. Without it, NixOS cannot boot.
+       </para>
+      </listitem>
+     </varlistentry>
+     <varlistentry>
+      <term>
+       UEFI systems
+      </term>
+      <listitem>
+       <para>
+        You <emphasis>must</emphasis> set the option
+        <xref linkend="opt-boot.loader.systemd-boot.enable"/> to
+        <literal>true</literal>. <command>nixos-generate-config</command>
+        should do this automatically for new configurations when booted in UEFI
+        mode.
+       </para>
+       <para>
+        You may want to look at the options starting with
+        <option><link linkend="opt-boot.loader.efi.canTouchEfiVariables">boot.loader.efi</link></option>
+        and
+        <option><link linkend="opt-boot.loader.systemd-boot.enable">boot.loader.systemd</link></option>
+        as well.
+       </para>
+      </listitem>
+     </varlistentry>
+    </variablelist>
+    <para>
+     If there are other operating systems running on the machine before
+     installing NixOS, the <xref linkend="opt-boot.loader.grub.useOSProber"/>
+     option can be set to <literal>true</literal> to automatically add them to
+     the grub menu.
+    </para>
+    <para>
+     Another critical option is <option>fileSystems</option>, specifying the
+     file systems that need to be mounted by NixOS. However, you typically
+     don’t need to set it yourself, because
+     <command>nixos-generate-config</command> sets it automatically in
+     <filename>/mnt/etc/nixos/hardware-configuration.nix</filename> from your
+     currently mounted file systems. (The configuration file
+     <filename>hardware-configuration.nix</filename> is included from
+     <filename>configuration.nix</filename> and will be overwritten by future
+     invocations of <command>nixos-generate-config</command>; thus, you
+     generally should not modify it.)
+    </para>
+    <note>
+     <para>
+      Depending on your hardware configuration or type of file system, you may
+      need to set the option <option>boot.initrd.kernelModules</option> to
+      include the kernel modules that are necessary for mounting the root file
+      system, otherwise the installed system will not be able to boot. (If this
+      happens, boot from the installation media again, mount the target file
+      system on <filename>/mnt</filename>, fix
+      <filename>/mnt/etc/nixos/configuration.nix</filename> and rerun
+      <filename>nixos-install</filename>.) In most cases,
+      <command>nixos-generate-config</command> will figure out the required
+      modules.
+     </para>
+    </note>
+   </listitem>
+   <listitem>
+    <para>
+     Do the installation:
 <screen>
 # nixos-install</screen>
-    Cross fingers. If this fails due to a temporary problem (such as a network
-    issue while downloading binaries from the NixOS binary cache), you can just
-    re-run <command>nixos-install</command>. Otherwise, fix your
-    <filename>configuration.nix</filename> and then re-run
-    <command>nixos-install</command>.
-   </para>
-   <para>
-    As the last step, <command>nixos-install</command> will ask you to set the
-    password for the <literal>root</literal> user, e.g.
+     Cross fingers. If this fails due to a temporary problem (such as a network
+     issue while downloading binaries from the NixOS binary cache), you can
+     just re-run <command>nixos-install</command>. Otherwise, fix your
+     <filename>configuration.nix</filename> and then re-run
+     <command>nixos-install</command>.
+    </para>
+    <para>
+     As the last step, <command>nixos-install</command> will ask you to set the
+     password for the <literal>root</literal> user, e.g.
 <screen>
 setting root password...
 Enter new UNIX password: ***
-Retype new UNIX password: ***
-    </screen>
-    <note>
-     <para>
-      For unattended installations, it is possible to use
-      <command>nixos-install --no-root-passwd</command>
-      in order to disable the password prompt entirely.
-     </para>
-    </note>
-   </para>
-  </listitem>
-  <listitem>
-   <para>
-    If everything went well:
+Retype new UNIX password: ***</screen>
+     <note>
+      <para>
+       For unattended installations, it is possible to use
+       <command>nixos-install --no-root-passwd</command> in order to disable
+       the password prompt entirely.
+      </para>
+     </note>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     If everything went well:
 <screen>
-        # reboot</screen>
-   </para>
-  </listitem>
-  <listitem>
-   <para>
-    You should now be able to boot into the installed NixOS. The GRUB boot menu
-    shows a list of <emphasis>available configurations</emphasis> (initially
-    just one). Every time you change the NixOS configuration (see
-    <link
+# reboot</screen>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     You should now be able to boot into the installed NixOS. The GRUB boot
+     menu shows a list of <emphasis>available configurations</emphasis>
+     (initially just one). Every time you change the NixOS configuration (see
+     <link
         linkend="sec-changing-config">Changing Configuration</link>
-    ), a new item is added to the menu. This allows you to easily roll back to
-    a previous configuration if something goes wrong.
-   </para>
-   <para>
-    You should log in and change the <literal>root</literal> password with
-    <command>passwd</command>.
-   </para>
-   <para>
-    You’ll probably want to create some user accounts as well, which can be
-    done with <command>useradd</command>:
+     ), a new item is added to the menu. This allows you to easily roll back to
+     a previous configuration if something goes wrong.
+    </para>
+    <para>
+     You should log in and change the <literal>root</literal> password with
+     <command>passwd</command>.
+    </para>
+    <para>
+     You’ll probably want to create some user accounts as well, which can be
+     done with <command>useradd</command>:
 <screen>
 $ useradd -c 'Eelco Dolstra' -m eelco
 $ passwd eelco</screen>
-   </para>
-   <para>
-    You may also want to install some software. For instance,
+    </para>
+    <para>
+     You may also want to install some software. For instance,
 <screen>
 $ nix-env -qa \*</screen>
-    shows what packages are available, and
+     shows what packages are available, and
 <screen>
 $ nix-env -i w3m</screen>
-    install the <literal>w3m</literal> browser.
-   </para>
-  </listitem>
- </orderedlist>
- <para>
-  To summarise, <xref linkend="ex-install-sequence" /> shows a typical sequence
-  of commands for installing NixOS on an empty hard drive (here
-  <filename>/dev/sda</filename>). <xref linkend="ex-config"
+     install the <literal>w3m</literal> browser.
+    </para>
+   </listitem>
+  </orderedlist>
+ </section>
+ <section xml:id="sec-installation-summary">
+  <title>Installation summary</title>
+
+  <para>
+   To summarise, <xref linkend="ex-install-sequence" /> shows a typical
+   sequence of commands for installing NixOS on an empty hard drive (here
+   <filename>/dev/sda</filename>). <xref linkend="ex-config"
 /> shows a
-  corresponding configuration Nix expression.
- </para>
- <example xml:id='ex-install-sequence'>
-  <title>Commands for Installing NixOS on <filename>/dev/sda</filename></title>
-<screen>
-# fdisk /dev/sda # <lineannotation>(or whatever device you want to install on)</lineannotation>
--- for UEFI systems only
-> n      # <lineannotation>(create a new partition for /boot)</lineannotation>
-> 3      # <lineannotation>(make it a partition number 3)</lineannotation>
->        # <lineannotation>(press enter to accept the default)</lineannotation>
-> +512M  # <lineannotation>(the size of the UEFI boot partition)</lineannotation>
-> t      # <lineannotation>(change the partition type ...)</lineannotation>
-> 3      # <lineannotation>(... of the boot partition ...)</lineannotation>
-> 1      # <lineannotation>(... to 'UEFI System')</lineannotation>
--- for BIOS or UEFI systems
-> n      # <lineannotation>(create a new partition for /swap)</lineannotation>
-> 2      # <lineannotation>(make it a partition number 2)</lineannotation>
->        # <lineannotation>(press enter to accept the default)</lineannotation>
-> +8G    # <lineannotation>(the size of the swap partition)</lineannotation>
-> n      # <lineannotation>(create a new partition for /)</lineannotation>
-> 1      # <lineannotation>(make it a partition number 1)</lineannotation>
->        # <lineannotation>(press enter to accept the default)</lineannotation>
->        # <lineannotation>(press enter to accept the default and use the rest of the remaining space)</lineannotation>
-> a      # <lineannotation>(make the partition bootable)</lineannotation>
-> x      # <lineannotation>(enter expert mode)</lineannotation>
-> f      # <lineannotation>(fix up the partition ordering)</lineannotation>
-> r      # <lineannotation>(exit expert mode)</lineannotation>
-> w      # <lineannotation>(write the partition table to disk and exit)</lineannotation>
+   corresponding configuration Nix expression.
+  </para>
+
+  <example xml:id="ex-partition-scheme-MBR">
+   <title>Example partition schemes for NixOS on <filename>/dev/sda</filename> (MBR)</title>
+<screen language="commands">
+# parted /dev/sda -- mklabel msdos
+# parted /dev/sda -- mkpart primary linux-swap 1M 8GiB
+# parted /dev/sda -- mkpart primary 8GiB -1s</screen>
+  </example>
+
+  <example xml:id="ex-partition-scheme-UEFI">
+   <title>Example partition schemes for NixOS on <filename>/dev/sda</filename> (UEFI)</title>
+<screen language="commands">
+# parted /dev/sda -- mklabel gpt
+# parted /dev/sda -- mkpart primary linux-swap 512MiB 8.5GiB
+# parted /dev/sda -- mkpart primary 8.5GiB -1MiB
+# parted /dev/sda -- mkpart ESP fat32 1M 512MiB
+# parted /dev/sda -- set 3 boot on</screen>
+  </example>
+
+  <example xml:id="ex-install-sequence">
+   <title>Commands for Installing NixOS on <filename>/dev/sda</filename></title>
+   <para>
+    With a partitioned disk.
+<screen language="commands">
 # mkfs.ext4 -L nixos /dev/sda1
 # mkswap -L swap /dev/sda2
 # swapon /dev/sda2
@@ -416,9 +516,11 @@ $ nix-env -i w3m</screen>
 # nano /mnt/etc/nixos/configuration.nix
 # nixos-install
 # reboot</screen>
- </example>
- <example xml:id='ex-config'>
-  <title>NixOS Configuration</title>
+   </para>
+  </example>
+
+  <example xml:id='ex-config'>
+   <title>NixOS Configuration</title>
 <screen>
 { config, pkgs, ... }: {
   imports = [
@@ -438,10 +540,19 @@ $ nix-env -i w3m</screen>
   services.sshd.enable = true;
 }
   </screen>
- </example>
- <xi:include href="installing-usb.xml" />
- <xi:include href="installing-pxe.xml" />
- <xi:include href="installing-virtualbox-guest.xml" />
- <xi:include href="installing-from-other-distro.xml" />
- <xi:include href="installing-behind-a-proxy.xml" />
+  </example>
+ </section>
+ <section xml:id="sec-installation-additional-notes">
+  <title>Additional installation notes</title>
+
+  <xi:include href="installing-usb.xml" />
+
+  <xi:include href="installing-pxe.xml" />
+
+  <xi:include href="installing-virtualbox-guest.xml" />
+
+  <xi:include href="installing-from-other-distro.xml" />
+
+  <xi:include href="installing-behind-a-proxy.xml" />
+ </section>
 </chapter>

nixos/doc/manual/installation/upgrading.xml

@@ -52,10 +52,13 @@
    </listitem>
   </itemizedlist>
   To see what channels are available, go to
-  <link
-xlink:href="https://nixos.org/channels"/>. (Note that the URIs of the
+  <link xlink:href="https://nixos.org/channels"/>. (Note that the URIs of the
   various channels redirect to a directory that contains the channel’s latest
-  version and includes ISO images and VirtualBox appliances.)
+  version and includes ISO images and VirtualBox appliances.) Please note that
+  during the release process, channels that are not yet released will be
+  present here as well. See the Getting NixOS page
+  <link xlink:href="https://nixos.org/nixos/download.html"/> to find the newest
+  supported stable release.
  </para>
  <para>
   When you first install NixOS, you’re automatically subscribed to the NixOS

nixos/doc/manual/manual.xml

@@ -17,8 +17,8 @@
   <para>
    If you encounter problems, please report them on the
    <literal
-    xlink:href="https://discourse.nixos.org">Discourse</literal>
-   or on the <link
+    xlink:href="https://discourse.nixos.org">Discourse</literal> or
+   on the <link
     xlink:href="irc://irc.freenode.net/#nixos">
    <literal>#nixos</literal> channel on Freenode</link>. Bugs should be
    reported in

nixos/doc/manual/options-to-docbook.xsl

@@ -4,6 +4,7 @@
                 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                 xmlns:str="http://exslt.org/strings"
                 xmlns:xlink="http://www.w3.org/1999/xlink"
+                xmlns:nixos="tag:nixos.org"
                 xmlns="http://docbook.org/ns/docbook"
                 extension-element-prefixes="str"
                 >
@@ -30,10 +31,12 @@
 
             <listitem>
 
-              <para>
-                <xsl:value-of disable-output-escaping="yes"
-                              select="attr[@name = 'description']/string/@value" />
-              </para>
+              <nixos:option-description>
+                <para>
+                  <xsl:value-of disable-output-escaping="yes"
+                                select="attr[@name = 'description']/string/@value" />
+                </para>
+              </nixos:option-description>
 
               <xsl:if test="attr[@name = 'type']">
                 <para>

nixos/doc/manual/postprocess-option-descriptions.xsl

@@ -0,0 +1,115 @@
+<?xml version="1.0"?>
+
+<xsl:stylesheet version="1.0"
+                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+                xmlns:str="http://exslt.org/strings"
+                xmlns:exsl="http://exslt.org/common"
+                xmlns:db="http://docbook.org/ns/docbook"
+                xmlns:nixos="tag:nixos.org"
+                extension-element-prefixes="str exsl">
+  <xsl:output method='xml' encoding="UTF-8" />
+
+  <xsl:template match="@*|node()">
+    <xsl:copy>
+      <xsl:apply-templates select="@*|node()" />
+    </xsl:copy>
+  </xsl:template>
+
+  <xsl:template name="break-up-description">
+    <xsl:param name="input" />
+    <xsl:param name="buffer" />
+
+    <!-- Every time we have two newlines following each other, we want to
+         break it into </para><para>. -->
+    <xsl:variable name="parbreak" select="'&#xa;&#xa;'" />
+
+    <!-- Similar to "(head:tail) = input" in Haskell. -->
+    <xsl:variable name="head" select="$input[1]" />
+    <xsl:variable name="tail" select="$input[position() &gt; 1]" />
+
+    <xsl:choose>
+      <xsl:when test="$head/self::text() and contains($head, $parbreak)">
+        <!-- If the haystack provided to str:split() directly starts or
+             ends with $parbreak, it doesn't generate a <token/> for that,
+             so we are doing this here. -->
+        <xsl:variable name="splitted-raw">
+          <xsl:if test="starts-with($head, $parbreak)"><token /></xsl:if>
+          <xsl:for-each select="str:split($head, $parbreak)">
+            <token><xsl:value-of select="node()" /></token>
+          </xsl:for-each>
+          <!-- Something like ends-with($head, $parbreak), but there is
+               no ends-with() in XSLT, so we need to use substring(). -->
+          <xsl:if test="
+            substring($head, string-length($head) -
+                             string-length($parbreak) + 1) = $parbreak
+          "><token /></xsl:if>
+        </xsl:variable>
+        <xsl:variable name="splitted"
+                      select="exsl:node-set($splitted-raw)/token" />
+        <!-- The buffer we had so far didn't contain any text nodes that
+             contain a $parbreak, so we can put the buffer along with the
+             first token of $splitted into a para element. -->
+        <para xmlns="http://docbook.org/ns/docbook">
+          <xsl:apply-templates select="exsl:node-set($buffer)" />
+          <xsl:apply-templates select="$splitted[1]/node()" />
+        </para>
+        <!-- We have already emitted the first splitted result, so the
+             last result is going to be set as the new $buffer later
+             because its contents may not be directly followed up by a
+             $parbreak. -->
+        <xsl:for-each select="$splitted[position() &gt; 1
+                              and position() &lt; last()]">
+          <para xmlns="http://docbook.org/ns/docbook">
+            <xsl:apply-templates select="node()" />
+          </para>
+        </xsl:for-each>
+        <xsl:call-template name="break-up-description">
+          <xsl:with-param name="input" select="$tail" />
+          <xsl:with-param name="buffer" select="$splitted[last()]/node()" />
+        </xsl:call-template>
+      </xsl:when>
+      <!-- Either non-text node or one without $parbreak, which we just
+           want to buffer and continue recursing. -->
+      <xsl:when test="$input">
+        <xsl:call-template name="break-up-description">
+          <xsl:with-param name="input" select="$tail" />
+          <!-- This essentially appends $head to $buffer. -->
+          <xsl:with-param name="buffer">
+            <xsl:if test="$buffer">
+              <xsl:for-each select="exsl:node-set($buffer)">
+                <xsl:apply-templates select="." />
+              </xsl:for-each>
+            </xsl:if>
+            <xsl:apply-templates select="$head" />
+          </xsl:with-param>
+        </xsl:call-template>
+      </xsl:when>
+      <!-- No more $input, just put the remaining $buffer in a para. -->
+      <xsl:otherwise>
+        <para xmlns="http://docbook.org/ns/docbook">
+          <xsl:apply-templates select="exsl:node-set($buffer)" />
+        </para>
+      </xsl:otherwise>
+    </xsl:choose>
+  </xsl:template>
+
+  <xsl:template match="nixos:option-description">
+    <xsl:choose>
+      <!--
+        Only process nodes that are comprised of a single <para/> element,
+        because if that's not the case the description already contains
+        </para><para> in between and we need no further processing.
+      -->
+      <xsl:when test="count(db:para) > 1">
+        <xsl:apply-templates select="node()" />
+      </xsl:when>
+      <xsl:otherwise>
+        <xsl:call-template name="break-up-description">
+          <xsl:with-param name="input"
+                          select="exsl:node-set(db:para/node())" />
+        </xsl:call-template>
+      </xsl:otherwise>
+    </xsl:choose>
+  </xsl:template>
+
+</xsl:stylesheet>

nixos/doc/manual/release-notes/rl-1509.xml

@@ -435,11 +435,11 @@ system.autoUpgrade.enable = true;
 <programlisting>
 system.stateVersion = "14.12";
 </programlisting>
-     The new option <option>system.stateVersion</option> ensures that
-     certain configuration changes that could break existing systems (such as
-     the <command>sshd</command> host key setting) will maintain compatibility
-     with the specified NixOS release. NixOps sets the state version of
-     existing deployments automatically.
+     The new option <option>system.stateVersion</option> ensures that certain
+     configuration changes that could break existing systems (such as the
+     <command>sshd</command> host key setting) will maintain compatibility with
+     the specified NixOS release. NixOps sets the state version of existing
+     deployments automatically.
     </para>
    </listitem>
    <listitem>

nixos/doc/manual/release-notes/rl-1809.xml

@@ -3,7 +3,7 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="sec-release-18.09">
- <title>Release 18.09 (“Jellyfish”, 2018/09/??)</title>
+ <title>Release 18.09 (“Jellyfish”, 2018/10/05)</title>
 
  <section xmlns="http://docbook.org/ns/docbook"
          xmlns:xlink="http://www.w3.org/1999/xlink"
@@ -14,18 +14,56 @@
 
   <para>
    In addition to numerous new and upgraded packages, this release has the
-   following highlights:
+   following notable updates:
   </para>
 
   <itemizedlist>
    <listitem>
-     <para>
-       Support for wrapping binaries using <literal>firejail</literal> has been
-       added through <varname>programs.firejail.wrappedBinaries</varname>.
-     </para>
-     <para>
-       For example
-     </para>
+    <para>
+     End of support is planned for end of April 2019, handing over to 19.03.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Platform support: x86_64-linux and x86_64-darwin as always. Support for
+     aarch64-linux is as with the previous releases, not equivalent to the
+     x86-64-linux release, but with efforts to reach parity.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Nix has been updated to 2.1; see its
+     <link xlink:href="https://nixos.org/nix/manual/#ssec-relnotes-2.1">release
+     notes</link>.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Core versions: linux: 4.14 LTS (unchanged), glibc: 2.26 → 2.27, gcc: 7
+     (unchanged), systemd: 237 → 239.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Desktop version changes: gnome: 3.26 → 3.28, (KDE) plasma-desktop: 5.12
+     → 5.13.
+    </para>
+   </listitem>
+  </itemizedlist>
+
+  <para>
+   Notable changes and additions for 18.09 include:
+  </para>
+
+  <itemizedlist>
+   <listitem>
+    <para>
+     Support for wrapping binaries using <literal>firejail</literal> has been
+     added through <varname>programs.firejail.wrappedBinaries</varname>.
+    </para>
+    <para>
+     For example
+    </para>
 <programlisting>
 programs.firejail = {
   enable = true;
@@ -35,9 +73,10 @@ programs.firejail = {
   };
 };
 </programlisting>
-      <para>
-        This will place <literal>firefox</literal> and <literal>mpv</literal> binaries in the global path wrapped by firejail.
-      </para>
+    <para>
+     This will place <literal>firefox</literal> and <literal>mpv</literal>
+     binaries in the global path wrapped by firejail.
+    </para>
    </listitem>
    <listitem>
     <para>
@@ -69,52 +108,355 @@ $ nix-instantiate -E '(import &lt;nixpkgsunstable&gt; {}).gitFull'
   <title>New Services</title>
 
   <para>
-   The following new services were added since the last release:
+   A curated selection of new services that were added since the last release:
   </para>
 
   <itemizedlist>
    <listitem>
     <para>
-     The <varname>services.cassandra</varname> module has been reworked and
-     was rewritten from scratch. The service has succeeding tests for
-     the versions 2.1, 2.2, 3.0 and 3.11 of <link
-     xlink:href="https://cassandra.apache.org/">Apache Cassandra</link>.
+     The <varname>services.cassandra</varname> module has been reworked and was
+     rewritten from scratch. The service has succeeding tests for the versions
+     2.1, 2.2, 3.0 and 3.11 of
+     <link
+     xlink:href="https://cassandra.apache.org/">Apache
+     Cassandra</link>.
     </para>
    </listitem>
    <listitem>
     <para>
-     There is a new <varname>services.foundationdb</varname> module for deploying
-     <link xlink:href="https://www.foundationdb.org">FoundationDB</link> clusters.
+     There is a new <varname>services.foundationdb</varname> module for
+     deploying
+     <link xlink:href="https://www.foundationdb.org">FoundationDB</link>
+     clusters.
     </para>
    </listitem>
    <listitem>
     <para>
      When enabled the <literal>iproute2</literal> will copy the files expected
      by ip route (e.g., <filename>rt_tables</filename>) in
-     <filename>/run/iproute2</filename>. This allows to write aliases for
+     <filename>/etc/iproute2</filename>. This allows to write aliases for
      routing tables for instance.
     </para>
    </listitem>
    <listitem>
     <para>
-      <varname>services.strongswan-swanctl</varname>
-      is a modern replacement for <varname>services.strongswan</varname>.
-      You can use either one of them to setup IPsec VPNs but not both at the same time.
+     <varname>services.strongswan-swanctl</varname> is a modern replacement for
+     <varname>services.strongswan</varname>. You can use either one of them to
+     setup IPsec VPNs but not both at the same time.
     </para>
     <para>
-      <varname>services.strongswan-swanctl</varname> uses the
-      <link xlink:href="https://wiki.strongswan.org/projects/strongswan/wiki/swanctl">swanctl</link>
-      command which uses the modern
-      <link xlink:href="https://github.com/strongswan/strongswan/blob/master/src/libcharon/plugins/vici/README.md">vici</link>
-      <emphasis>Versatile IKE Configuration Interface</emphasis>.
-      The deprecated <literal>ipsec</literal> command used in <varname>services.strongswan</varname> is using the legacy
-      <link xlink:href="https://github.com/strongswan/strongswan/blob/master/README_LEGACY.md">stroke configuration interface</link>.
+     <varname>services.strongswan-swanctl</varname> uses the
+     <link xlink:href="https://wiki.strongswan.org/projects/strongswan/wiki/swanctl">swanctl</link>
+     command which uses the modern
+     <link xlink:href="https://github.com/strongswan/strongswan/blob/master/src/libcharon/plugins/vici/README.md">vici</link>
+     <emphasis>Versatile IKE Configuration Interface</emphasis>. The deprecated
+     <literal>ipsec</literal> command used in
+     <varname>services.strongswan</varname> is using the legacy
+     <link xlink:href="https://github.com/strongswan/strongswan/blob/master/README_LEGACY.md">stroke
+     configuration interface</link>.
     </para>
    </listitem>
    <listitem>
     <para>
-      The new <varname>services.elasticsearch-curator</varname> service
-      periodically curates or manages, your Elasticsearch indices and snapshots.
+     The new <varname>services.elasticsearch-curator</varname> service
+     periodically curates or manages, your Elasticsearch indices and snapshots.
+    </para>
+   </listitem>
+  </itemizedlist>
+
+  <para>
+   Every new services:
+  </para>
+
+  <itemizedlist>
+   <listitem>
+    <para>
+     <literal>./config/xdg/autostart.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./config/xdg/icons.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./config/xdg/menus.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./config/xdg/mime.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./hardware/brightnessctl.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./hardware/onlykey.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./hardware/video/uvcvideo/default.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./misc/documentation.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./programs/firejail.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./programs/iftop.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./programs/sedutil.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./programs/singularity.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./programs/xss-lock.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./programs/zsh/zsh-autosuggestions.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/admin/oxidized.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/backup/duplicati.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/backup/restic.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/backup/restic-rest-server.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/cluster/hadoop/default.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/databases/aerospike.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/databases/monetdb.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/desktops/bamf.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/desktops/flatpak.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/desktops/zeitgeist.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/development/bloop.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/development/jupyter/default.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/hardware/lcd.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/hardware/undervolt.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/misc/clipmenu.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/misc/gitweb.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/misc/serviio.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/misc/safeeyes.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/misc/sysprof.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/misc/weechat.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/monitoring/datadog-agent.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/monitoring/incron.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/networking/dnsdist.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/networking/freeradius.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/networking/hans.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/networking/morty.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/networking/ndppd.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/networking/ocserv.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/networking/owamp.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/networking/quagga.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/networking/shadowsocks.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/networking/stubby.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/networking/zeronet.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/security/certmgr.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/security/cfssl.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/security/oauth2_proxy_nginx.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/web-apps/virtlyst.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/web-apps/youtrack.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/web-servers/hitch/default.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/web-servers/hydron.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/web-servers/meguca.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./services/web-servers/nginx/gitweb.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./virtualisation/kvmgt.nix</literal>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     <literal>./virtualisation/qemu-guest-agent.nix</literal>
     </para>
    </listitem>
   </itemizedlist>
@@ -135,8 +477,8 @@ $ nix-instantiate -E '(import &lt;nixpkgsunstable&gt; {}).gitFull'
   <itemizedlist>
    <listitem>
     <para>
-     The deprecated <varname>services.cassandra</varname> module has
-     seen a complete rewrite. (See above.)
+     The deprecated <varname>services.cassandra</varname> module has seen a
+     complete rewrite. (See above.)
     </para>
    </listitem>
    <listitem>
@@ -186,41 +528,44 @@ $ nix-instantiate -E '(import &lt;nixpkgsunstable&gt; {}).gitFull'
    </listitem>
    <listitem>
     <para>
-     <varname>services.munge</varname> now runs as user (and group) <literal>munge</literal> instead of root.
-     Make sure the key file is accessible to the daemon.
+     <varname>services.munge</varname> now runs as user (and group)
+     <literal>munge</literal> instead of root. Make sure the key file is
+     accessible to the daemon.
     </para>
    </listitem>
    <listitem>
     <para>
-      <varname>dockerTools.buildImage</varname> now uses <literal>null</literal> as default value for <varname>tag</varname>,
-      which indicates that the nix output hash will be used as tag.
+     <varname>dockerTools.buildImage</varname> now uses <literal>null</literal>
+     as default value for <varname>tag</varname>, which indicates that the nix
+     output hash will be used as tag.
     </para>
    </listitem>
    <listitem>
     <para>
-     The ELK stack: <varname>elasticsearch</varname>, <varname>logstash</varname> and <varname>kibana</varname>
-     has been upgraded from 2.* to 6.3.*.
-     The 2.* versions have been <link xlink:href="https://www.elastic.co/support/eol">unsupported since last year</link>
-     so they have been removed. You can still use the 5.* versions under the names
-     <varname>elasticsearch5</varname>, <varname>logstash5</varname> and
-     <varname>kibana5</varname>.
+     The ELK stack: <varname>elasticsearch</varname>,
+     <varname>logstash</varname> and <varname>kibana</varname> has been
+     upgraded from 2.* to 6.3.*. The 2.* versions have been
+     <link xlink:href="https://www.elastic.co/support/eol">unsupported since
+     last year</link> so they have been removed. You can still use the 5.*
+     versions under the names <varname>elasticsearch5</varname>,
+     <varname>logstash5</varname> and <varname>kibana5</varname>.
     </para>
     <para>
-     The elastic beats:
-     <varname>filebeat</varname>, <varname>heartbeat</varname>,
-     <varname>metricbeat</varname> and <varname>packetbeat</varname>
-     have had the same treatment: they now target 6.3.* as well.
-     The 5.* versions are available under the names:
+     The elastic beats: <varname>filebeat</varname>,
+     <varname>heartbeat</varname>, <varname>metricbeat</varname> and
+     <varname>packetbeat</varname> have had the same treatment: they now target
+     6.3.* as well. The 5.* versions are available under the names:
      <varname>filebeat5</varname>, <varname>heartbeat5</varname>,
      <varname>metricbeat5</varname> and <varname>packetbeat5</varname>
     </para>
     <para>
      The ELK-6.3 stack now comes with
-     <link xlink:href="https://www.elastic.co/products/x-pack/open">X-Pack by default</link>.
-     Since X-Pack is licensed under the
-     <link xlink:href="https://github.com/elastic/elasticsearch/blob/master/licenses/ELASTIC-LICENSE.txt">Elastic License</link>
-     the ELK packages now have an unfree license. To use them you need to specify
-     <literal>allowUnfree = true;</literal> in your nixpkgs configuration.
+     <link xlink:href="https://www.elastic.co/products/x-pack/open">X-Pack by
+     default</link>. Since X-Pack is licensed under the
+     <link xlink:href="https://github.com/elastic/elasticsearch/blob/master/licenses/ELASTIC-LICENSE.txt">Elastic
+     License</link> the ELK packages now have an unfree license. To use them
+     you need to specify <literal>allowUnfree = true;</literal> in your nixpkgs
+     configuration.
     </para>
     <para>
      Fortunately there is also a free variant of the ELK stack without X-Pack.
@@ -231,20 +576,23 @@ $ nix-instantiate -E '(import &lt;nixpkgsunstable&gt; {}).gitFull'
    </listitem>
    <listitem>
     <para>
-      Options
-      <literal>boot.initrd.luks.devices.<replaceable>name</replaceable>.yubikey.ramfsMountPoint</literal>
-      <literal>boot.initrd.luks.devices.<replaceable>name</replaceable>.yubikey.storage.mountPoint</literal>
-      were removed. <literal>luksroot.nix</literal> module never supported more than one YubiKey at
-      a time anyway, hence those options never had any effect. You should be able to remove them
-      from your config without any issues.
+     Options
+     <literal>boot.initrd.luks.devices.<replaceable>name</replaceable>.yubikey.ramfsMountPoint</literal>
+     <literal>boot.initrd.luks.devices.<replaceable>name</replaceable>.yubikey.storage.mountPoint</literal>
+     were removed. <literal>luksroot.nix</literal> module never supported more
+     than one YubiKey at a time anyway, hence those options never had any
+     effect. You should be able to remove them from your config without any
+     issues.
     </para>
    </listitem>
    <listitem>
     <para>
-      <literal>stdenv.system</literal> and <literal>system</literal> in nixpkgs now refer to the host platform instead of the build platform.
-      For native builds this is not change, let alone a breaking one.
-      For cross builds, it is a breaking change, and <literal>stdenv.buildPlatform.system</literal> can be used instead for the old behavior.
-      They should be using that anyways for clarity.
+     <literal>stdenv.system</literal> and <literal>system</literal> in nixpkgs
+     now refer to the host platform instead of the build platform. For native
+     builds this is not change, let alone a breaking one. For cross builds, it
+     is a breaking change, and <literal>stdenv.buildPlatform.system</literal>
+     can be used instead for the old behavior. They should be using that
+     anyways for clarity.
     </para>
    </listitem>
   </itemizedlist>
@@ -298,26 +646,33 @@ $ nix-instantiate -E '(import &lt;nixpkgsunstable&gt; {}).gitFull'
    </listitem>
    <listitem>
     <para>
-      The <literal>pkgs</literal> argument to NixOS modules can now be set directly using <literal>nixpkgs.pkgs</literal>. Previously, only the <literal>system</literal>, <literal>config</literal> and <literal>overlays</literal> arguments could be used to influence <literal>pkgs</literal>.
+     The <literal>pkgs</literal> argument to NixOS modules can now be set
+     directly using <literal>nixpkgs.pkgs</literal>. Previously, only the
+     <literal>system</literal>, <literal>config</literal> and
+     <literal>overlays</literal> arguments could be used to influence
+     <literal>pkgs</literal>.
     </para>
    </listitem>
    <listitem>
     <para>
-      A NixOS system can now be constructed more easily based on a preexisting invocation of Nixpkgs. For example:
-      <programlisting>
+     A NixOS system can now be constructed more easily based on a preexisting
+     invocation of Nixpkgs. For example:
+<programlisting>
 inherit (pkgs.nixos {
   boot.loader.grub.enable = false;
   fileSystems."/".device = "/dev/xvda1";
 }) toplevel kernel initialRamdisk manual;
       </programlisting>
-
-      This benefits evaluation performance, lets you write Nixpkgs packages that depend on NixOS images and is consistent with a deployment architecture that would be centered around Nixpkgs overlays.
+     This benefits evaluation performance, lets you write Nixpkgs packages that
+     depend on NixOS images and is consistent with a deployment architecture
+     that would be centered around Nixpkgs overlays.
     </para>
    </listitem>
    <listitem>
     <para>
-      <literal>lib.traceValIfNot</literal> has been deprecated. Use
-      <literal>if/then/else</literal> and <literal>lib.traceValSeq</literal> instead.
+     <literal>lib.traceValIfNot</literal> has been deprecated. Use
+     <literal>if/then/else</literal> and <literal>lib.traceValSeq</literal>
+     instead.
     </para>
    </listitem>
    <listitem>
@@ -336,9 +691,9 @@ inherit (pkgs.nixos {
    </listitem>
    <listitem>
     <para>
-     <literal>lib.recursiveUpdateUntil</literal> was not acting according to its
-     specification. It has been fixed to act according to the docstring, and a
-     test has been added.
+     <literal>lib.recursiveUpdateUntil</literal> was not acting according to
+     its specification. It has been fixed to act according to the docstring,
+     and a test has been added.
     </para>
    </listitem>
    <listitem>
@@ -408,11 +763,11 @@ inherit (pkgs.nixos {
     </para>
    </listitem>
    <listitem>
-     <para>
-     The Kubernetes package has been bumped to major version 1.11.
-     Please consult the
-     <link xlink:href="https://github.com/kubernetes/kubernetes/blob/release-1.11/CHANGELOG-1.11.md">release notes</link>
-     for details on new features and api changes.
+    <para>
+     The Kubernetes package has been bumped to major version 1.11. Please
+     consult the
+     <link xlink:href="https://github.com/kubernetes/kubernetes/blob/release-1.11/CHANGELOG-1.11.md">release
+     notes</link> for details on new features and api changes.
     </para>
    </listitem>
    <listitem>
@@ -432,8 +787,8 @@ inherit (pkgs.nixos {
    </listitem>
    <listitem>
     <para>
-     The option <varname>services.kubernetes.apiserver.address</varname>
-     was renamed to <varname>services.kubernetes.apiserver.bindAddress</varname>.
+     The option <varname>services.kubernetes.apiserver.address</varname> was
+     renamed to <varname>services.kubernetes.apiserver.bindAddress</varname>.
      Note that the default value has changed from 127.0.0.1 to 0.0.0.0.
     </para>
    </listitem>
@@ -445,76 +800,86 @@ inherit (pkgs.nixos {
    </listitem>
    <listitem>
     <para>
-     The option <varname>services.kubernetes.addons.dashboard.enableRBAC</varname>
-     was renamed to <varname>services.kubernetes.addons.dashboard.rbac.enable</varname>.
+     The option
+     <varname>services.kubernetes.addons.dashboard.enableRBAC</varname> was
+     renamed to
+     <varname>services.kubernetes.addons.dashboard.rbac.enable</varname>.
     </para>
    </listitem>
    <listitem>
     <para>
      The Kubernetes Dashboard now has only minimal RBAC permissions by default.
-     If dashboard cluster-admin rights are desired,
-     set <varname>services.kubernetes.addons.dashboard.rbac.clusterAdmin</varname> to true.
-     On existing clusters, in order for the revocation of privileges to take effect,
-     the current ClusterRoleBinding for kubernetes-dashboard must be manually removed:
-     <literal>kubectl delete clusterrolebinding kubernetes-dashboard</literal>
+     If dashboard cluster-admin rights are desired, set
+     <varname>services.kubernetes.addons.dashboard.rbac.clusterAdmin</varname>
+     to true. On existing clusters, in order for the revocation of privileges
+     to take effect, the current ClusterRoleBinding for kubernetes-dashboard
+     must be manually removed: <literal>kubectl delete clusterrolebinding
+     kubernetes-dashboard</literal>
     </para>
    </listitem>
    <listitem>
     <para>
      The <varname>programs.screen</varname> module provides allows to configure
-     <literal>/etc/screenrc</literal>, however the module behaved fairly counterintuitive as
-     the config exists, but the package wasn't available. Since 18.09 <literal>pkgs.screen</literal>
-     will be added to <literal>environment.systemPackages</literal>.
+     <literal>/etc/screenrc</literal>, however the module behaved fairly
+     counterintuitive as the config exists, but the package wasn't available.
+     Since 18.09 <literal>pkgs.screen</literal> will be added to
+     <literal>environment.systemPackages</literal>.
     </para>
    </listitem>
    <listitem>
     <para>
-      The module <option>services.networking.hostapd</option> now uses WPA2 by default.
+     The module <option>services.networking.hostapd</option> now uses WPA2 by
+     default.
     </para>
    </listitem>
    <listitem>
     <para>
-      <varname>s6Dns</varname>, <varname>s6Networking</varname>,
-      <varname>s6LinuxUtils</varname> and <varname>s6PortableUtils</varname>
-      renamed to
-      <varname>s6-dns</varname>, <varname>s6-networking</varname>,
-      <varname>s6-linux-utils</varname> and <varname>s6-portable-utils</varname> respectively.
+     <varname>s6Dns</varname>, <varname>s6Networking</varname>,
+     <varname>s6LinuxUtils</varname> and <varname>s6PortableUtils</varname>
+     renamed to <varname>s6-dns</varname>, <varname>s6-networking</varname>,
+     <varname>s6-linux-utils</varname> and <varname>s6-portable-utils</varname>
+     respectively.
     </para>
-  </listitem>
-  <listitem>
+   </listitem>
+   <listitem>
     <para>
-      The module option <option>nix.useSandbox</option> is now defaulted to <literal>true</literal>.
+     The module option <option>nix.useSandbox</option> is now defaulted to
+     <literal>true</literal>.
     </para>
-  </listitem>
-  <listitem>
+   </listitem>
+   <listitem>
     <para>
-      The config activation script of <literal>nixos-rebuild</literal> now
-      <link xlink:href="https://www.freedesktop.org/software/systemd/man/systemctl.html#Manager%20Lifecycle%20Commands">reloads</link>
-      all user units for each authenticated user.
+     The config activation script of <literal>nixos-rebuild</literal> now
+     <link xlink:href="https://www.freedesktop.org/software/systemd/man/systemctl.html#Manager%20Lifecycle%20Commands">reloads</link>
+     all user units for each authenticated user.
     </para>
-  </listitem>
-  <listitem>
+   </listitem>
+   <listitem>
     <para>
-      The default display manager is now LightDM.
-      To use SLiM set <literal>services.xserver.displayManager.slim.enable</literal>
-      to <literal>true</literal>.
+     The default display manager is now LightDM. To use SLiM set
+     <literal>services.xserver.displayManager.slim.enable</literal> to
+     <literal>true</literal>.
     </para>
-  </listitem>
-  <listitem>
+   </listitem>
+   <listitem>
     <para>
-      NixOS option descriptions are now automatically broken up into individual
-      paragraphs if the text contains two consecutive newlines, so it's no
-      longer necessary to use <code>&lt;/para&gt;&lt;para&gt;</code> to start
-      a new paragraph.
+     NixOS option descriptions are now automatically broken up into individual
+     paragraphs if the text contains two consecutive newlines, so it's no
+     longer necessary to use <code>&lt;/para&gt;&lt;para&gt;</code> to start a
+     new paragraph.
     </para>
-  </listitem>
-  <listitem>
+   </listitem>
+   <listitem>
     <para>
-      Top-level <literal>buildPlatform</literal>, <literal>hostPlatform</literal>, and <literal>targetPlatform</literal> in Nixpkgs are deprecated.
-      Please use their equivalents in <literal>stdenv</literal> instead:
-      <literal>stdenv.buildPlatform</literal>, <literal>stdenv.hostPlatform</literal>, and <literal>stdenv.targetPlatform</literal>.
+     Top-level <literal>buildPlatform</literal>,
+     <literal>hostPlatform</literal>, and <literal>targetPlatform</literal> in
+     Nixpkgs are deprecated. Please use their equivalents in
+     <literal>stdenv</literal> instead:
+     <literal>stdenv.buildPlatform</literal>,
+     <literal>stdenv.hostPlatform</literal>, and
+     <literal>stdenv.targetPlatform</literal>.
     </para>
-  </listitem>
+   </listitem>
   </itemizedlist>
  </section>
 </section>

nixos/lib/test-driver/Machine.pm

@@ -155,8 +155,10 @@ sub start {
         $ENV{USE_TMPDIR} = 1;
         $ENV{QEMU_OPTS} =
             ($self->{allowReboot} ? "" : "-no-reboot ") .
-            "-monitor unix:./monitor -chardev socket,id=shell,path=./shell " .
-            "-device virtio-serial -device virtconsole,chardev=shell " .
+            "-monitor unix:./monitor " .
+            "-chardev socket,id=shell,path=./shell -device virtio-serial -device virtconsole,chardev=shell " .
+            # socket backdoor, see "Debugging NixOS tests" section in NixOS manual
+            "-chardev socket,id=backdoor,path=./backdoor,server,nowait -device virtio-serial -device virtconsole,chardev=backdoor " .
             "-device virtio-rng-pci " .
             ($showGraphics ? "-serial stdio" : "-nographic") . " " . ($ENV{QEMU_OPTS} || "");
         chdir $self->{stateDir} or die;

nixos/modules/config/iproute2.nix

@@ -4,20 +4,29 @@ with lib;
 
 let
   cfg = config.networking.iproute2;
-  confDir = "/run/iproute2";
 in
 {
-  options.networking.iproute2.enable = mkEnableOption "copy IP route configuration files";
-
-  config = mkMerge [
-    ({ nixpkgs.config.iproute2.confDir = confDir; })
-
-    (mkIf cfg.enable {
-      system.activationScripts.iproute2 = ''
-        cp -R ${pkgs.iproute}/etc/iproute2 ${confDir}
-        chmod -R 664 ${confDir}
-        chmod +x ${confDir}
+  options.networking.iproute2 = {
+    enable = mkEnableOption "copy IP route configuration files";
+    rttablesExtraConfig = mkOption {
+      type = types.lines;
+      default = "";
+      description = ''
+        Verbatim lines to add to /etc/iproute2/rt_tables
       '';
-    })
-  ];
+    };
+  };
+
+  config = mkIf cfg.enable {
+    environment.etc."iproute2/bpf_pinning" = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/bpf_pinning"; };
+    environment.etc."iproute2/ematch_map"  = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/ematch_map";  };
+    environment.etc."iproute2/group"       = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/group";       };
+    environment.etc."iproute2/nl_protos"   = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/nl_protos";   };
+    environment.etc."iproute2/rt_dsfield"  = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/rt_dsfield";  };
+    environment.etc."iproute2/rt_protos"   = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/rt_protos";   };
+    environment.etc."iproute2/rt_realms"   = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/rt_realms";   };
+    environment.etc."iproute2/rt_scopes"   = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/rt_scopes";   };
+    environment.etc."iproute2/rt_tables"   = { mode = "0644"; text = (fileContents "${pkgs.iproute}/etc/iproute2/rt_tables")
+                                                                   + (optionalString (cfg.rttablesExtraConfig != "") "\n\n${cfg.rttablesExtraConfig}"); };
+  };
 }

nixos/modules/config/shells-environment.nix

@@ -163,15 +163,24 @@ in
         /bin/sh
       '';
 
+    # For resetting environment with `. /etc/set-environment` when needed
+    # and discoverability (see motivation of #30418).
+    environment.etc."set-environment".source = config.system.build.setEnvironment;
+
     system.build.setEnvironment = pkgs.writeText "set-environment"
-       ''
-         ${exportedEnvVars}
+      ''
+        # DO NOT EDIT -- this file has been generated automatically.
 
-         ${cfg.extraInit}
+        # Prevent this file from being sourced by child shells.
+        export __NIXOS_SET_ENVIRONMENT_DONE=1
 
-         # ~/bin if it exists overrides other bin directories.
-         export PATH="$HOME/bin:$PATH"
-       '';
+        ${exportedEnvVars}
+
+        ${cfg.extraInit}
+
+        # ~/bin if it exists overrides other bin directories.
+        export PATH="$HOME/bin:$PATH"
+      '';
 
     system.activationScripts.binsh = stringAfter [ "stdio" ]
       ''

nixos/modules/config/xdg/mime.nix

@@ -23,7 +23,7 @@ with lib;
     ];
 
     environment.extraSetup = ''
-      if [ -w $out/share/mime ]; then
+      if [ -w $out/share/mime ] && [ -d $out/share/mime/packages ]; then
         XDG_DATA_DIRS=$out/share ${pkgs.shared-mime-info}/bin/update-mime-database -V $out/share/mime > /dev/null
       fi
 

nixos/modules/i18n/input-method/default.xml

@@ -3,32 +3,50 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="module-services-input-methods">
+ <title>Input Methods</title>
+ <para>
+  Input methods are an operating system component that allows any data, such as
+  keyboard strokes or mouse movements, to be received as input. In this way
+  users can enter characters and symbols not found on their input devices.
+  Using an input method is obligatory for any language that has more graphemes
+  than there are keys on the keyboard.
+ </para>
+ <para>
+  The following input methods are available in NixOS:
+ </para>
+ <itemizedlist>
+  <listitem>
+   <para>
+    IBus: The intelligent input bus.
+   </para>
+  </listitem>
+  <listitem>
+   <para>
+    Fcitx: A customizable lightweight input method.
+   </para>
+  </listitem>
+  <listitem>
+   <para>
+    Nabi: A Korean input method based on XIM.
+   </para>
+  </listitem>
+  <listitem>
+   <para>
+    Uim: The universal input method, is a library with a XIM bridge.
+   </para>
+  </listitem>
+ </itemizedlist>
+ <section xml:id="module-services-input-methods-ibus">
+  <title>IBus</title>
 
-<title>Input Methods</title>
+  <para>
+   IBus is an Intelligent Input Bus. It provides full featured and user
+   friendly input method user interface.
+  </para>
 
-<para>Input methods are an operating system component that allows any data, such
-  as keyboard strokes or mouse movements, to be received as input. In this way
-  users can enter characters and symbols not found on their input devices. Using
-  an input method is obligatory for any language that has more graphemes than
-  there are keys on the keyboard.</para>
-
-<para>The following input methods are available in NixOS:</para>
-
-<itemizedlist>
-  <listitem><para>IBus: The intelligent input bus.</para></listitem>
-  <listitem><para>Fcitx: A customizable lightweight input
-      method.</para></listitem>
-  <listitem><para>Nabi: A Korean input method based on XIM.</para></listitem>
-  <listitem><para>Uim: The universal input method, is a library with a XIM
-      bridge.</para></listitem>
-</itemizedlist>
-
-<section xml:id="module-services-input-methods-ibus"><title>IBus</title>
-
-<para>IBus is an Intelligent Input Bus. It provides full featured and user
-  friendly input method user interface.</para>
-
-<para>The following snippet can be used to configure IBus:</para>
+  <para>
+   The following snippet can be used to configure IBus:
+  </para>
 
 <programlisting>
 i18n.inputMethod = {
@@ -37,57 +55,89 @@ i18n.inputMethod = {
 };
 </programlisting>
 
-<para><literal>i18n.inputMethod.ibus.engines</literal> is optional and can be
-  used to add extra IBus engines.</para>
+  <para>
+   <literal>i18n.inputMethod.ibus.engines</literal> is optional and can be used
+   to add extra IBus engines.
+  </para>
 
-<para>Available extra IBus engines are:</para>
+  <para>
+   Available extra IBus engines are:
+  </para>
 
-<itemizedlist>
-  <listitem><para>Anthy (<literal>ibus-engines.anthy</literal>): Anthy is a
-      system for Japanese input method. It converts Hiragana text to Kana Kanji
-      mixed text.</para></listitem>
-  <listitem><para>Hangul (<literal>ibus-engines.hangul</literal>): Korean input
-      method.</para></listitem>
-  <listitem><para>m17n (<literal>ibus-engines.m17n</literal>): m17n is an input
-      method that uses input methods and corresponding icons in the m17n
-      database.</para></listitem>
-  <listitem><para>mozc (<literal>ibus-engines.mozc</literal>): A Japanese input
-      method from Google.</para></listitem>
-  <listitem><para>Table (<literal>ibus-engines.table</literal>): An input method
-      that load tables of input methods.</para></listitem>
-  <listitem><para>table-others (<literal>ibus-engines.table-others</literal>):
-      Various table-based input methods. To use this, and any other table-based
-      input methods, it must appear in the list of engines along with
-      <literal>table</literal>. For example:
+  <itemizedlist>
+   <listitem>
+    <para>
+     Anthy (<literal>ibus-engines.anthy</literal>): Anthy is a system for
+     Japanese input method. It converts Hiragana text to Kana Kanji mixed text.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Hangul (<literal>ibus-engines.hangul</literal>): Korean input method.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     m17n (<literal>ibus-engines.m17n</literal>): m17n is an input method that
+     uses input methods and corresponding icons in the m17n database.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     mozc (<literal>ibus-engines.mozc</literal>): A Japanese input method from
+     Google.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Table (<literal>ibus-engines.table</literal>): An input method that load
+     tables of input methods.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     table-others (<literal>ibus-engines.table-others</literal>): Various
+     table-based input methods. To use this, and any other table-based input
+     methods, it must appear in the list of engines along with
+     <literal>table</literal>. For example:
 <programlisting>
 ibus.engines = with pkgs.ibus-engines; [ table table-others ];
 </programlisting>
-  </para></listitem>
-</itemizedlist>
+    </para>
+   </listitem>
+  </itemizedlist>
 
-<para>To use any input method, the package must be added in the configuration,
-  as shown above, and also (after running <literal>nixos-rebuild</literal>) the
-  input method must be added from IBus' preference dialog.</para>
+  <para>
+   To use any input method, the package must be added in the configuration, as
+   shown above, and also (after running <literal>nixos-rebuild</literal>) the
+   input method must be added from IBus' preference dialog.
+  </para>
 
-<simplesect xml:id="module-services-input-methods-troubleshooting">
-  <title>Troubleshooting</title>
-  <para>If IBus works in some applications but not others, a likely cause of
-  this is that IBus is depending on a different version of
-  <literal>glib</literal> to what the applications are depending on. This can
-  be checked by running <literal>nix-store -q --requisites &lt;path&gt; | grep
-  glib</literal>, where <literal>&lt;path&gt;</literal> is the path of either
-  IBus or an application in the Nix store. The <literal>glib</literal>
-  packages must match exactly. If they do not, uninstalling and reinstalling
-  the application is a likely fix.</para>
-</simplesect>
-</section>
+  <simplesect xml:id="module-services-input-methods-troubleshooting">
+   <title>Troubleshooting</title>
+   <para>
+    If IBus works in some applications but not others, a likely cause of this
+    is that IBus is depending on a different version of <literal>glib</literal>
+    to what the applications are depending on. This can be checked by running
+    <literal>nix-store -q --requisites &lt;path&gt; | grep glib</literal>,
+    where <literal>&lt;path&gt;</literal> is the path of either IBus or an
+    application in the Nix store. The <literal>glib</literal> packages must
+    match exactly. If they do not, uninstalling and reinstalling the
+    application is a likely fix.
+   </para>
+  </simplesect>
+ </section>
+ <section xml:id="module-services-input-methods-fcitx">
+  <title>Fcitx</title>
 
-<section xml:id="module-services-input-methods-fcitx"><title>Fcitx</title>
+  <para>
+   Fcitx is an input method framework with extension support. It has three
+   built-in Input Method Engine, Pinyin, QuWei and Table-based input methods.
+  </para>
 
-<para>Fcitx is an input method framework with extension support. It has three
-  built-in Input Method Engine, Pinyin, QuWei and Table-based input
-  methods.</para>
-<para>The following snippet can be used to configure Fcitx:</para>
+  <para>
+   The following snippet can be used to configure Fcitx:
+  </para>
 
 <programlisting>
 i18n.inputMethod = {
@@ -96,51 +146,89 @@ i18n.inputMethod = {
 };
 </programlisting>
 
-<para><literal>i18n.inputMethod.fcitx.engines</literal> is optional and can be
-  used to add extra Fcitx engines.</para>
+  <para>
+   <literal>i18n.inputMethod.fcitx.engines</literal> is optional and can be
+   used to add extra Fcitx engines.
+  </para>
 
-<para>Available extra Fcitx engines are:</para>
+  <para>
+   Available extra Fcitx engines are:
+  </para>
 
-<itemizedlist>
-  <listitem><para>Anthy (<literal>fcitx-engines.anthy</literal>): Anthy is a
-      system for Japanese input method. It converts Hiragana text to Kana Kanji
-      mixed text.</para></listitem>
-  <listitem><para>Chewing (<literal>fcitx-engines.chewing</literal>): Chewing is
-      an intelligent Zhuyin input method. It is one of the most popular input
-      methods among Traditional Chinese Unix users.</para></listitem>
-  <listitem><para>Hangul (<literal>fcitx-engines.hangul</literal>): Korean input
-      method.</para></listitem>
-  <listitem><para>Unikey (<literal>fcitx-engines.unikey</literal>): Vietnamese input
-      method.</para></listitem>
-  <listitem><para>m17n (<literal>fcitx-engines.m17n</literal>): m17n is an input
-      method that uses input methods and corresponding icons in the m17n
-      database.</para></listitem>
-  <listitem><para>mozc (<literal>fcitx-engines.mozc</literal>): A Japanese input
-      method from Google.</para></listitem>
-  <listitem><para>table-others (<literal>fcitx-engines.table-others</literal>):
-      Various table-based input methods.</para></listitem>
-</itemizedlist>
-</section>
+  <itemizedlist>
+   <listitem>
+    <para>
+     Anthy (<literal>fcitx-engines.anthy</literal>): Anthy is a system for
+     Japanese input method. It converts Hiragana text to Kana Kanji mixed text.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Chewing (<literal>fcitx-engines.chewing</literal>): Chewing is an
+     intelligent Zhuyin input method. It is one of the most popular input
+     methods among Traditional Chinese Unix users.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Hangul (<literal>fcitx-engines.hangul</literal>): Korean input method.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Unikey (<literal>fcitx-engines.unikey</literal>): Vietnamese input method.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     m17n (<literal>fcitx-engines.m17n</literal>): m17n is an input method that
+     uses input methods and corresponding icons in the m17n database.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     mozc (<literal>fcitx-engines.mozc</literal>): A Japanese input method from
+     Google.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     table-others (<literal>fcitx-engines.table-others</literal>): Various
+     table-based input methods.
+    </para>
+   </listitem>
+  </itemizedlist>
+ </section>
+ <section xml:id="module-services-input-methods-nabi">
+  <title>Nabi</title>
 
-<section xml:id="module-services-input-methods-nabi"><title>Nabi</title>
+  <para>
+   Nabi is an easy to use Korean X input method. It allows you to enter
+   phonetic Korean characters (hangul) and pictographic Korean characters
+   (hanja).
+  </para>
 
-<para>Nabi is an easy to use Korean X input method. It allows you to enter
-  phonetic Korean characters (hangul) and pictographic Korean characters
-  (hanja).</para>
-<para>The following snippet can be used to configure Nabi:</para>
+  <para>
+   The following snippet can be used to configure Nabi:
+  </para>
 
 <programlisting>
 i18n.inputMethod = {
   <link linkend="opt-i18n.inputMethod.enabled">enabled</link> = "nabi";
 };
 </programlisting>
-</section>
+ </section>
+ <section xml:id="module-services-input-methods-uim">
+  <title>Uim</title>
 
-<section xml:id="module-services-input-methods-uim"><title>Uim</title>
+  <para>
+   Uim (short for "universal input method") is a multilingual input method
+   framework. Applications can use it through so-called bridges.
+  </para>
 
-<para>Uim (short for "universal input method") is a multilingual input method
-  framework. Applications can use it through so-called bridges.</para>
-<para>The following snippet can be used to configure uim:</para>
+  <para>
+   The following snippet can be used to configure uim:
+  </para>
 
 <programlisting>
 i18n.inputMethod = {
@@ -148,8 +236,9 @@ i18n.inputMethod = {
 };
 </programlisting>
 
-<para>Note: The <xref linkend="opt-i18n.inputMethod.uim.toolbar"/> option can be
-  used to choose uim toolbar.</para>
-
-</section>
+  <para>
+   Note: The <xref linkend="opt-i18n.inputMethod.uim.toolbar"/> option can be
+   used to choose uim toolbar.
+  </para>
+ </section>
 </chapter>

nixos/modules/installer/cd-dvd/iso-image.nix

@@ -233,7 +233,7 @@ let
             "
     # Make our own efi program, we can't rely on "grub-install" since it seems to
     # probe for devices, even with --skip-fs-probe.
-    ${pkgs.grub2_efi}/bin/grub-mkimage -o $out/EFI/boot/${if targetArch == "x64" then "bootx64" else "bootx32"}.efi -p /EFI/boot -O ${if targetArch == "x64" then "x86_64" else "i386"}-efi \
+    ${pkgs.grub2_efi}/bin/grub-mkimage -o $out/EFI/boot/${if targetArch == "x64" then "bootx64" else "bootia32"}.efi -p /EFI/boot -O ${if targetArch == "x64" then "x86_64" else "i386"}-efi \
       $MODULES
     cp ${pkgs.grub2_efi}/share/grub/unicode.pf2 $out/EFI/boot/
 

nixos/modules/installer/tools/nix-fallback-paths.nix

@@ -1,6 +1,6 @@
 {
-  x86_64-linux = "/nix/store/0d60i73mcv8z1m8d2m74yfn84980gfsa-nix-2.0.4";
-  i686-linux = "/nix/store/6ssafj2s5a2g9x28yld7b70vwd6vw6lb-nix-2.0.4";
-  aarch64-linux = "/nix/store/3wwch7bp7n7xsl8apgy2a4b16yzyij1z-nix-2.0.4";
-  x86_64-darwin = "/nix/store/771l8i0mz4c8kry8cz3sz8rr3alalckg-nix-2.0.4";
+  x86_64-linux = "/nix/store/h180y3n5k1ypxgm1pcvj243qix5j45zz-nix-2.1.1";
+  i686-linux = "/nix/store/v2y4k4v9ml07jmfq739wyflapg3b7b5k-nix-2.1.1";
+  aarch64-linux = "/nix/store/v485craglq7xm5996ci8qy5dyc17dab0-nix-2.1.1";
+  x86_64-darwin = "/nix/store/lc3ymlix73kaad5srjdgaxp9ngr1sg6g-nix-2.1.1";
 }

nixos/modules/installer/tools/nixos-generate-config.pl

@@ -277,8 +277,7 @@ if ($virt eq "qemu" || $virt eq "kvm" || $virt eq "bochs") {
 
 # Also for Hyper-V.
 if ($virt eq "microsoft") {
-    push @initrdAvailableKernelModules, "hv_storvsc";
-    $videoDriver = "fbdev";
+    push @attrs, "virtualisation.hypervGuest.enable = true;"
 }
 
 

nixos/modules/installer/tools/nixos-option.sh

@@ -82,7 +82,7 @@ evalNix(){
   set -e
 
   if test $exit_code -eq 0; then
-      cat <<EOF
+      sed '/^warning: Nix search path/d' <<EOF
 $result
 EOF
       return 0;
@@ -90,7 +90,7 @@ EOF
       sed -n '
   /^error/ { s/, at (string):[0-9]*:[0-9]*//; p; };
   /^warning: Nix search path/ { p; };
-' <<EOF
+' >&2 <<EOF
 $result
 EOF
     exit_code=1

nixos/modules/misc/version.nix

@@ -5,7 +5,6 @@ with lib;
 let
   cfg = config.system.nixos;
 
-  revisionFile = "${toString pkgs.path}/.git-revision";
   gitRepo      = "${toString pkgs.path}/.git";
   gitCommitId  = lib.substring 0 7 (commitIdFromGitRepo gitRepo);
 in
@@ -37,9 +36,7 @@ in
     nixos.revision = mkOption {
       internal = true;
       type = types.str;
-      default = if pathIsDirectory gitRepo then commitIdFromGitRepo gitRepo
-                else if pathExists revisionFile then fileContents revisionFile
-                else "master";
+      default = lib.trivial.revisionWithDefault "master";
       description = "The Git revision from which this NixOS configuration was built.";
     };
 
@@ -68,7 +65,7 @@ in
     defaultChannel = mkOption {
       internal = true;
       type = types.str;
-      default = https://nixos.org/channels/nixos-unstable;
+      default = https://nixos.org/channels/nixos-18.09;
       description = "Default NixOS channel to which the root user is subscribed.";
     };
 

nixos/modules/module-list.nix

@@ -406,6 +406,7 @@
   ./services/misc/taskserver
   ./services/misc/tzupdate.nix
   ./services/misc/uhub.nix
+  ./services/misc/weechat.nix
   ./services/misc/xmr-stak.nix
   ./services/misc/zookeeper.nix
   ./services/monitoring/apcupsd.nix

nixos/modules/profiles/graphical.nix

@@ -11,5 +11,5 @@
     libinput.enable = true; # for touchpad support on many laptops
   };
 
-  environment.systemPackages = [ pkgs.glxinfo ];
+  environment.systemPackages = [ pkgs.glxinfo pkgs.firefox ];
 }

nixos/modules/programs/bash/bash.nix

@@ -126,7 +126,9 @@ in
     programs.bash = {
 
       shellInit = ''
-        ${config.system.build.setEnvironment.text}
+        if [ -z "$__NIXOS_SET_ENVIRONMENT_DONE" ]; then
+            . ${config.system.build.setEnvironment}
+        fi
 
         ${cfge.shellInit}
       '';
@@ -166,11 +168,11 @@ in
 
         # Read system-wide modifications.
         if test -f /etc/profile.local; then
-          . /etc/profile.local
+            . /etc/profile.local
         fi
 
         if [ -n "''${BASH_VERSION:-}" ]; then
-          . /etc/bashrc
+            . /etc/bashrc
         fi
       '';
 
@@ -191,12 +193,12 @@ in
 
         # We are not always an interactive shell.
         if [ -n "$PS1" ]; then
-          ${cfg.interactiveShellInit}
+            ${cfg.interactiveShellInit}
         fi
 
         # Read system-wide modifications.
         if test -f /etc/bashrc.local; then
-          . /etc/bashrc.local
+            . /etc/bashrc.local
         fi
       '';
 

nixos/modules/programs/digitalbitbox/doc.xml

@@ -3,75 +3,64 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="module-programs-digitalbitbox">
-
-  <title>Digital Bitbox</title>
-
-  <para>
-    Digital Bitbox is a hardware wallet and second-factor authenticator.
-  </para>
-
-  <para>
-    The <literal>digitalbitbox</literal> programs module may be
-    installed by setting <literal>programs.digitalbitbox</literal>
-    to <literal>true</literal> in a manner similar to
-
+ <title>Digital Bitbox</title>
+ <para>
+  Digital Bitbox is a hardware wallet and second-factor authenticator.
+ </para>
+ <para>
+  The <literal>digitalbitbox</literal> programs module may be installed by
+  setting <literal>programs.digitalbitbox</literal> to <literal>true</literal>
+  in a manner similar to
 <programlisting>
 <xref linkend="opt-programs.digitalbitbox.enable"/> = true;
 </programlisting>
-
-    and bundles the <literal>digitalbitbox</literal> package (see <xref
+  and bundles the <literal>digitalbitbox</literal> package (see
+  <xref
       linkend="sec-digitalbitbox-package" />), which contains the
-    <literal>dbb-app</literal> and <literal>dbb-cli</literal> binaries,
-    along with the hardware module (see <xref
+  <literal>dbb-app</literal> and <literal>dbb-cli</literal> binaries, along
+  with the hardware module (see
+  <xref
       linkend="sec-digitalbitbox-hardware-module" />) which sets up the
-    necessary udev rules to access the device.
-  </para>
+  necessary udev rules to access the device.
+ </para>
+ <para>
+  Enabling the digitalbitbox module is pretty much the easiest way to get a
+  Digital Bitbox device working on your system.
+ </para>
+ <para>
+  For more information, see
+  <link xlink:href="https://digitalbitbox.com/start_linux" />.
+ </para>
+ <section xml:id="sec-digitalbitbox-package">
+  <title>Package</title>
 
   <para>
-    Enabling the digitalbitbox module is pretty much the easiest way to
-    get a Digital Bitbox device working on your system.
-  </para>
-
-  <para>
-    For more information, see
-    <link xlink:href="https://digitalbitbox.com/start_linux" />.
-  </para>
-
-  <section xml:id="sec-digitalbitbox-package">
-    <title>Package</title>
-
-    <para>
-      The binaries, <literal>dbb-app</literal> (a GUI tool) and
-      <literal>dbb-cli</literal> (a CLI tool), are available through the
-      <literal>digitalbitbox</literal> package which could be installed
-      as follows:
-
+   The binaries, <literal>dbb-app</literal> (a GUI tool) and
+   <literal>dbb-cli</literal> (a CLI tool), are available through the
+   <literal>digitalbitbox</literal> package which could be installed as
+   follows:
 <programlisting>
 <xref linkend="opt-environment.systemPackages"/> = [
   pkgs.digitalbitbox
 ];
 </programlisting>
-    </para>
-  </section>
-
-
-  <section xml:id="sec-digitalbitbox-hardware-module">
-    <title>Hardware</title>
-
-    <para>
-      The digitalbitbox hardware package enables the udev rules for
-      Digital Bitbox devices and may be installed as follows:
+  </para>
+ </section>
+ <section xml:id="sec-digitalbitbox-hardware-module">
+  <title>Hardware</title>
 
+  <para>
+   The digitalbitbox hardware package enables the udev rules for Digital Bitbox
+   devices and may be installed as follows:
 <programlisting>
 <xref linkend="opt-hardware.digitalbitbox.enable"/> = true;
 </programlisting>
-    </para>
-
-    <para>
-      In order to alter the udev rules, one may provide different values for
-      the <literal>udevRule51</literal> and <literal>udevRule52</literal>
-      attributes by means of overriding as follows:
+  </para>
 
+  <para>
+   In order to alter the udev rules, one may provide different values for the
+   <literal>udevRule51</literal> and <literal>udevRule52</literal> attributes
+   by means of overriding as follows:
 <programlisting>
 programs.digitalbitbox = {
   <link linkend="opt-programs.digitalbitbox.enable">enable</link> = true;
@@ -80,6 +69,6 @@ programs.digitalbitbox = {
   };
 };
 </programlisting>
-    </para>
-  </section>
+  </para>
+ </section>
 </chapter>

nixos/modules/programs/fish.nix

@@ -27,7 +27,7 @@ in
         '';
         type = types.bool;
       };
-      
+
       vendor.config.enable = mkOption {
         type = types.bool;
         default = true;
@@ -43,7 +43,7 @@ in
           Whether fish should use completion files provided by other packages.
         '';
       };
-      
+
       vendor.functions.enable = mkOption {
         type = types.bool;
         default = true;
@@ -107,9 +107,11 @@ in
       # This happens before $__fish_datadir/config.fish sets fish_function_path, so it is currently
       # unset. We set it and then completely erase it, leaving its configuration to $__fish_datadir/config.fish
       set fish_function_path ${pkgs.fish-foreign-env}/share/fish-foreign-env/functions $__fish_datadir/functions
-      
+
       # source the NixOS environment config
-      fenv source ${config.system.build.setEnvironment}
+      if [ -z "$__NIXOS_SET_ENVIRONMENT_DONE" ]
+          fenv source ${config.system.build.setEnvironment}
+      end
 
       # clear fish_function_path so that it will be correctly set when we return to $__fish_datadir/config.fish
       set -e fish_function_path
@@ -123,7 +125,7 @@ in
         set fish_function_path ${pkgs.fish-foreign-env}/share/fish-foreign-env/functions $fish_function_path
         fenv source /etc/fish/foreign-env/shellInit > /dev/null
         set -e fish_function_path[1]
-        
+
         ${cfg.shellInit}
 
         # and leave a note so we don't source this config section again from
@@ -137,7 +139,7 @@ in
         set fish_function_path ${pkgs.fish-foreign-env}/share/fish-foreign-env/functions $fish_function_path
         fenv source /etc/fish/foreign-env/loginShellInit > /dev/null
         set -e fish_function_path[1]
-        
+
         ${cfg.loginShellInit}
 
         # and leave a note so we don't source this config section again from
@@ -149,12 +151,11 @@ in
       status --is-interactive; and not set -q __fish_nixos_interactive_config_sourced
       and begin
         ${fishAliases}
-        
 
         set fish_function_path ${pkgs.fish-foreign-env}/share/fish-foreign-env/functions $fish_function_path
         fenv source /etc/fish/foreign-env/interactiveShellInit > /dev/null
         set -e fish_function_path[1]
-        
+
         ${cfg.promptInit}
         ${cfg.interactiveShellInit}
 
@@ -170,7 +171,7 @@ in
       ++ optional cfg.vendor.config.enable "/share/fish/vendor_conf.d"
       ++ optional cfg.vendor.completions.enable "/share/fish/vendor_completions.d"
       ++ optional cfg.vendor.functions.enable "/share/fish/vendor_functions.d";
-    
+
     environment.systemPackages = [ pkgs.fish ];
 
     environment.shells = [

nixos/modules/programs/plotinus.xml

@@ -3,23 +3,28 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="module-program-plotinus">
-
-<title>Plotinus</title>
-
-<para><emphasis>Source:</emphasis> <filename>modules/programs/plotinus.nix</filename></para>
-
-<para><emphasis>Upstream documentation:</emphasis> <link xlink:href="https://github.com/p-e-w/plotinus"/></para>
-
-<para>Plotinus is a searchable command palette in every modern GTK+ application.</para>
-
-<para>When in a GTK+3 application and Plotinus is enabled, you can press <literal>Ctrl+Shift+P</literal> to open the command palette.  The command palette provides a searchable list of of all menu items in the application.</para>
-
-<para>To enable Plotinus, add the following to your <filename>configuration.nix</filename>:
-
+ <title>Plotinus</title>
+ <para>
+  <emphasis>Source:</emphasis>
+  <filename>modules/programs/plotinus.nix</filename>
+ </para>
+ <para>
+  <emphasis>Upstream documentation:</emphasis>
+  <link xlink:href="https://github.com/p-e-w/plotinus"/>
+ </para>
+ <para>
+  Plotinus is a searchable command palette in every modern GTK+ application.
+ </para>
+ <para>
+  When in a GTK+3 application and Plotinus is enabled, you can press
+  <literal>Ctrl+Shift+P</literal> to open the command palette. The command
+  palette provides a searchable list of of all menu items in the application.
+ </para>
+ <para>
+  To enable Plotinus, add the following to your
+  <filename>configuration.nix</filename>:
 <programlisting>
 <xref linkend="opt-programs.plotinus.enable"/> = true;
 </programlisting>
-
-</para>
-
+ </para>
 </chapter>

nixos/modules/programs/yabar.nix

@@ -44,10 +44,23 @@ in
       enable = mkEnableOption "yabar";
 
       package = mkOption {
-        default = pkgs.yabar;
-        example = literalExample "pkgs.yabar-unstable";
+        default = pkgs.yabar-unstable;
+        example = literalExample "pkgs.yabar";
         type = types.package;
 
+        # `yabar-stable` segfaults under certain conditions.
+        apply = x: if x == pkgs.yabar-unstable then x else flip warn x ''
+          It's not recommended to use `yabar' with `programs.yabar', the (old) stable release
+          tends to segfault under certain circumstances:
+
+          * https://github.com/geommer/yabar/issues/86
+          * https://github.com/geommer/yabar/issues/68
+          * https://github.com/geommer/yabar/issues/143
+
+          Most of them don't occur on master anymore, until a new release is published, it's recommended
+          to use `yabar-unstable'.
+        '';
+
         description = ''
           The package which contains the `yabar` binary.
 

nixos/modules/programs/zsh/oh-my-zsh.xml

@@ -3,18 +3,20 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="module-programs-zsh-ohmyzsh">
+ <title>Oh my ZSH</title>
+ <para>
+  <literal><link xlink:href="https://ohmyz.sh/">oh-my-zsh</link></literal> is a
+  framework to manage your <link xlink:href="https://www.zsh.org/">ZSH</link>
+  configuration including completion scripts for several CLI tools or custom
+  prompt themes.
+ </para>
+ <section xml:id="module-programs-oh-my-zsh-usage">
+  <title>Basic usage</title>
 
-<title>Oh my ZSH</title>
-
-<para><literal><link xlink:href="https://ohmyz.sh/">oh-my-zsh</link></literal> is a framework
-to manage your <link xlink:href="https://www.zsh.org/">ZSH</link> configuration
-including completion scripts for several CLI tools or custom prompt themes.</para>
-
-<section xml:id="module-programs-oh-my-zsh-usage"><title>Basic usage</title>
-<para>The module uses the <literal>oh-my-zsh</literal> package with all available features.  The
-initial setup using Nix expressions is fairly similar to the configuration format
-of <literal>oh-my-zsh</literal>.
-
+  <para>
+   The module uses the <literal>oh-my-zsh</literal> package with all available
+   features. The initial setup using Nix expressions is fairly similar to the
+   configuration format of <literal>oh-my-zsh</literal>.
 <programlisting>
 {
   programs.ohMyZsh = {
@@ -24,39 +26,50 @@ of <literal>oh-my-zsh</literal>.
   };
 }
 </programlisting>
+   For a detailed explanation of these arguments please refer to the
+   <link xlink:href="https://github.com/robbyrussell/oh-my-zsh/wiki"><literal>oh-my-zsh</literal>
+   docs</link>.
+  </para>
 
-For a detailed explanation of these arguments please refer to the
-<link xlink:href="https://github.com/robbyrussell/oh-my-zsh/wiki"><literal>oh-my-zsh</literal> docs</link>.
-</para>
-<para>The expression generates the needed
-configuration and writes it into your <literal>/etc/zshrc</literal>.
-</para></section>
+  <para>
+   The expression generates the needed configuration and writes it into your
+   <literal>/etc/zshrc</literal>.
+  </para>
+ </section>
+ <section xml:id="module-programs-oh-my-zsh-additions">
+  <title>Custom additions</title>
 
-<section xml:id="module-programs-oh-my-zsh-additions"><title>Custom additions</title>
-
-<para>Sometimes third-party or custom scripts such as a modified theme may be needed.
-<literal>oh-my-zsh</literal> provides the
-<link xlink:href="https://github.com/robbyrussell/oh-my-zsh/wiki/Customization#overriding-internals"><literal>ZSH_CUSTOM</literal></link> 
-environment variable for this which points to a directory with additional scripts.</para>
-
-<para>The module can do this as well:
+  <para>
+   Sometimes third-party or custom scripts such as a modified theme may be
+   needed. <literal>oh-my-zsh</literal> provides the
+   <link xlink:href="https://github.com/robbyrussell/oh-my-zsh/wiki/Customization#overriding-internals"><literal>ZSH_CUSTOM</literal></link>
+   environment variable for this which points to a directory with additional
+   scripts.
+  </para>
 
+  <para>
+   The module can do this as well:
 <programlisting>
 {
   programs.ohMyZsh.custom = "~/path/to/custom/scripts";
 }
 </programlisting>
-</para></section>
+  </para>
+ </section>
+ <section xml:id="module-programs-oh-my-zsh-environments">
+  <title>Custom environments</title>
 
-<section xml:id="module-programs-oh-my-zsh-environments"><title>Custom environments</title>
-
-<para>There are several extensions for <literal>oh-my-zsh</literal> packaged in <literal>nixpkgs</literal>.
-One of them is <link xlink:href="https://github.com/spwhitt/nix-zsh-completions">nix-zsh-completions</link>
-which bundles completion scripts and a plugin for <literal>oh-my-zsh</literal>.</para>
-
-<para>Rather than using a single mutable path for <literal>ZSH_CUSTOM</literal>, it's also possible to
-generate this path from a list of Nix packages:
+  <para>
+   There are several extensions for <literal>oh-my-zsh</literal> packaged in
+   <literal>nixpkgs</literal>. One of them is
+   <link xlink:href="https://github.com/spwhitt/nix-zsh-completions">nix-zsh-completions</link>
+   which bundles completion scripts and a plugin for
+   <literal>oh-my-zsh</literal>.
+  </para>
 
+  <para>
+   Rather than using a single mutable path for <literal>ZSH_CUSTOM</literal>,
+   it's also possible to generate this path from a list of Nix packages:
 <programlisting>
 { pkgs, ... }:
 {
@@ -66,42 +79,59 @@ generate this path from a list of Nix packages:
   ];
 }
 </programlisting>
+   Internally a single store path will be created using
+   <literal>buildEnv</literal>. Please refer to the docs of
+   <link xlink:href="https://nixos.org/nixpkgs/manual/#sec-building-environment"><literal>buildEnv</literal></link>
+   for further reference.
+  </para>
 
-Internally a single store path will be created using <literal>buildEnv</literal>.
-Please refer to the docs of
-<link xlink:href="https://nixos.org/nixpkgs/manual/#sec-building-environment"><literal>buildEnv</literal></link>
-for further reference.</para>
+  <para>
+   <emphasis>Please keep in mind that this is not compatible with
+   <literal>programs.ohMyZsh.custom</literal> as it requires an immutable store
+   path while <literal>custom</literal> shall remain mutable! An evaluation
+   failure will be thrown if both <literal>custom</literal> and
+   <literal>customPkgs</literal> are set.</emphasis>
+  </para>
+ </section>
+ <section xml:id="module-programs-oh-my-zsh-packaging-customizations">
+  <title>Package your own customizations</title>
 
-<para><emphasis>Please keep in mind that this is not compatible with <literal>programs.ohMyZsh.custom</literal>
-as it requires an immutable store path while <literal>custom</literal> shall remain mutable! An evaluation failure
-will be thrown if both <literal>custom</literal> and <literal>customPkgs</literal> are set.</emphasis>
-</para></section>
+  <para>
+   If third-party customizations (e.g. new themes) are supposed to be added to
+   <literal>oh-my-zsh</literal> there are several pitfalls to keep in mind:
+  </para>
 
-<section xml:id="module-programs-oh-my-zsh-packaging-customizations"><title>Package your own customizations</title>
-
-<para>If third-party customizations (e.g. new themes) are supposed to be added to <literal>oh-my-zsh</literal>
-there are several pitfalls to keep in mind:</para>
-
-<itemizedlist>
-  <listitem>
-    <para>To comply with the default structure of <literal>ZSH</literal> the entire output needs to be written to
-    <literal>$out/share/zsh.</literal></para>
-  </listitem>
-  <listitem>
-    <para>Completion scripts are supposed to be stored at <literal>$out/share/zsh/site-functions</literal>. This directory
-    is part of the <literal><link xlink:href="http://zsh.sourceforge.net/Doc/Release/Functions.html">fpath</link></literal>
-    and the package should be compatible with pure <literal>ZSH</literal> setups. The module will automatically link
-    the contents of <literal>site-functions</literal> to completions directory in the proper store path.</para>
-  </listitem>
-  <listitem>
-    <para>The <literal>plugins</literal> directory needs the structure <literal>pluginname/pluginname.plugin.zsh</literal>
-    as structured in the <link xlink:href="https://github.com/robbyrussell/oh-my-zsh/tree/91b771914bc7c43dd7c7a43b586c5de2c225ceb7/plugins">upstream repo.</link>
+  <itemizedlist>
+   <listitem>
+    <para>
+     To comply with the default structure of <literal>ZSH</literal> the entire
+     output needs to be written to <literal>$out/share/zsh.</literal>
     </para>
-  </listitem>
-</itemizedlist>
+   </listitem>
+   <listitem>
+    <para>
+     Completion scripts are supposed to be stored at
+     <literal>$out/share/zsh/site-functions</literal>. This directory is part
+     of the
+     <literal><link xlink:href="http://zsh.sourceforge.net/Doc/Release/Functions.html">fpath</link></literal>
+     and the package should be compatible with pure <literal>ZSH</literal>
+     setups. The module will automatically link the contents of
+     <literal>site-functions</literal> to completions directory in the proper
+     store path.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     The <literal>plugins</literal> directory needs the structure
+     <literal>pluginname/pluginname.plugin.zsh</literal> as structured in the
+     <link xlink:href="https://github.com/robbyrussell/oh-my-zsh/tree/91b771914bc7c43dd7c7a43b586c5de2c225ceb7/plugins">upstream
+     repo.</link>
+    </para>
+   </listitem>
+  </itemizedlist>
 
-<para>
-A derivation for <literal>oh-my-zsh</literal> may look like this:
+  <para>
+   A derivation for <literal>oh-my-zsh</literal> may look like this:
 <programlisting>
 { stdenv, fetchFromGitHub }:
 
@@ -120,6 +150,6 @@ stdenv.mkDerivation rec {
   '';
 }
 </programlisting>
-</para>
-</section>
+  </para>
+ </section>
 </chapter>

nixos/modules/programs/zsh/zsh.nix

@@ -70,7 +70,7 @@ in
       promptInit = mkOption {
         default = ''
           if [ "$TERM" != dumb ]; then
-            autoload -U promptinit && promptinit && prompt walters
+              autoload -U promptinit && promptinit && prompt walters
           fi
         '';
         description = ''
@@ -116,7 +116,9 @@ in
         if [ -n "$__ETC_ZSHENV_SOURCED" ]; then return; fi
         export __ETC_ZSHENV_SOURCED=1
 
-        ${config.system.build.setEnvironment.text}
+        if [ -z "$__NIXOS_SET_ENVIRONMENT_DONE" ]; then
+            . ${config.system.build.setEnvironment}
+        fi
 
         ${cfge.shellInit}
 
@@ -124,7 +126,7 @@ in
 
         # Read system-wide modifications.
         if test -f /etc/zshenv.local; then
-          . /etc/zshenv.local
+            . /etc/zshenv.local
         fi
       '';
 
@@ -143,7 +145,7 @@ in
 
         # Read system-wide modifications.
         if test -f /etc/zprofile.local; then
-          . /etc/zprofile.local
+            . /etc/zprofile.local
         fi
       '';
 
@@ -169,7 +171,7 @@ in
 
         # Tell zsh how to find installed completions
         for p in ''${(z)NIX_PROFILES}; do
-          fpath+=($p/share/zsh/site-functions $p/share/zsh/$ZSH_VERSION/functions $p/share/zsh/vendor-completions)
+            fpath+=($p/share/zsh/site-functions $p/share/zsh/$ZSH_VERSION/functions $p/share/zsh/vendor-completions)
         done
 
         ${optionalString cfg.enableGlobalCompInit "autoload -U compinit && compinit"}
@@ -184,7 +186,7 @@ in
 
         # Read system-wide modifications.
         if test -f /etc/zshrc.local; then
-          . /etc/zshrc.local
+            . /etc/zshrc.local
         fi
       '';
 

nixos/modules/security/acme.nix

@@ -302,15 +302,15 @@ in
                       workdir="$(mktemp -d)"
 
                       # Create CA
-                      openssl genrsa -des3 -passout pass:x -out $workdir/ca.pass.key 2048
-                      openssl rsa -passin pass:x -in $workdir/ca.pass.key -out $workdir/ca.key
+                      openssl genrsa -des3 -passout pass:xxxx -out $workdir/ca.pass.key 2048
+                      openssl rsa -passin pass:xxxx -in $workdir/ca.pass.key -out $workdir/ca.key
                       openssl req -new -key $workdir/ca.key -out $workdir/ca.csr \
                         -subj "/C=UK/ST=Warwickshire/L=Leamington/O=OrgName/OU=Security Department/CN=example.com"
                       openssl x509 -req -days 1 -in $workdir/ca.csr -signkey $workdir/ca.key -out $workdir/ca.crt
 
                       # Create key
-                      openssl genrsa -des3 -passout pass:x -out $workdir/server.pass.key 2048
-                      openssl rsa -passin pass:x -in $workdir/server.pass.key -out $workdir/server.key
+                      openssl genrsa -des3 -passout pass:xxxx -out $workdir/server.pass.key 2048
+                      openssl rsa -passin pass:xxxx -in $workdir/server.pass.key -out $workdir/server.key
                       openssl req -new -key $workdir/server.key -out $workdir/server.csr \
                         -subj "/C=UK/ST=Warwickshire/L=Leamington/O=OrgName/OU=IT Department/CN=example.com"
                       openssl x509 -req -days 1 -in $workdir/server.csr -CA $workdir/ca.crt \

nixos/modules/security/acme.xml

@@ -3,23 +3,25 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="module-security-acme">
+ <title>SSL/TLS Certificates with ACME</title>
+ <para>
+  NixOS supports automatic domain validation &amp; certificate retrieval and
+  renewal using the ACME protocol. This is currently only implemented by and
+  for Let's Encrypt. The alternative ACME client <literal>simp_le</literal> is
+  used under the hood.
+ </para>
+ <section xml:id="module-security-acme-prerequisites">
+  <title>Prerequisites</title>
 
-<title>SSL/TLS Certificates with ACME</title>
-
-<para>NixOS supports automatic domain validation &amp; certificate
-retrieval and renewal using the ACME protocol. This is currently only
-implemented by and for Let's Encrypt. The alternative ACME client
-<literal>simp_le</literal> is used under the hood.</para>
-
-<section xml:id="module-security-acme-prerequisites"><title>Prerequisites</title>
-
-<para>You need to have a running HTTP server for verification. The server must
-have a webroot defined that can serve
-<filename>.well-known/acme-challenge</filename>. This directory must be
-writeable by the user that will run the ACME client.</para>
-
-<para>For instance, this generic snippet could be used for Nginx:
+  <para>
+   You need to have a running HTTP server for verification. The server must
+   have a webroot defined that can serve
+   <filename>.well-known/acme-challenge</filename>. This directory must be
+   writeable by the user that will run the ACME client.
+  </para>
 
+  <para>
+   For instance, this generic snippet could be used for Nginx:
 <programlisting>
 http {
   server {
@@ -37,43 +39,47 @@ http {
   }
 }
 </programlisting>
-</para>
-
-</section>
-
-<section xml:id="module-security-acme-configuring"><title>Configuring</title>
-
-<para>To enable ACME certificate retrieval &amp; renewal for a certificate for
-<literal>foo.example.com</literal>, add the following in your
-<filename>configuration.nix</filename>:
+  </para>
+ </section>
+ <section xml:id="module-security-acme-configuring">
+  <title>Configuring</title>
 
+  <para>
+   To enable ACME certificate retrieval &amp; renewal for a certificate for
+   <literal>foo.example.com</literal>, add the following in your
+   <filename>configuration.nix</filename>:
 <programlisting>
 <xref linkend="opt-security.acme.certs"/>."foo.example.com" = {
   <link linkend="opt-security.acme.certs._name_.webroot">webroot</link> = "/var/www/challenges";
   <link linkend="opt-security.acme.certs._name_.email">email</link> = "foo@example.com";
 };
 </programlisting>
-</para>
+  </para>
 
-<para>The private key <filename>key.pem</filename> and certificate
-<filename>fullchain.pem</filename> will be put into
-<filename>/var/lib/acme/foo.example.com</filename>. The target directory can
-be configured with the option <xref linkend="opt-security.acme.directory"/>.
-</para>
+  <para>
+   The private key <filename>key.pem</filename> and certificate
+   <filename>fullchain.pem</filename> will be put into
+   <filename>/var/lib/acme/foo.example.com</filename>. The target directory can
+   be configured with the option <xref linkend="opt-security.acme.directory"/>.
+  </para>
 
-<para>Refer to <xref linkend="ch-options" /> for all available configuration
-options for the <link linkend="opt-security.acme.certs">security.acme</link> module.</para>
+  <para>
+   Refer to <xref linkend="ch-options" /> for all available configuration
+   options for the <link linkend="opt-security.acme.certs">security.acme</link>
+   module.
+  </para>
+ </section>
+ <section xml:id="module-security-acme-nginx">
+  <title>Using ACME certificates in Nginx</title>
 
-</section>
-
-<section xml:id="module-security-acme-nginx"><title>Using ACME certificates in Nginx</title>
-<para>NixOS supports fetching ACME certificates for you by setting
-  <literal><link linkend="opt-services.nginx.virtualHosts._name_.enableACME">enableACME</link> = true;</literal> in a virtualHost config. We
-first create self-signed placeholder certificates in place of the
-real ACME certs. The placeholder certs are overwritten when the ACME
-certs arrive. For <literal>foo.example.com</literal> the config would
-look like.
-</para>
+  <para>
+   NixOS supports fetching ACME certificates for you by setting
+   <literal><link linkend="opt-services.nginx.virtualHosts._name_.enableACME">enableACME</link>
+   = true;</literal> in a virtualHost config. We first create self-signed
+   placeholder certificates in place of the real ACME certs. The placeholder
+   certs are overwritten when the ACME certs arrive. For
+   <literal>foo.example.com</literal> the config would look like.
+  </para>
 
 <programlisting>
 services.nginx = {
@@ -89,5 +95,5 @@ services.nginx = {
   };
 }
 </programlisting>
-</section>
+ </section>
 </chapter>

nixos/modules/security/hidepid.xml

@@ -3,31 +3,26 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="sec-hidepid">
-
-  <title>Hiding process information</title>
-
-  <para>
-    Setting
+ <title>Hiding process information</title>
+ <para>
+  Setting
 <programlisting>
 <xref linkend="opt-security.hideProcessInformation"/> = true;
 </programlisting>
-    ensures that access to process information is restricted to the
-    owning user.  This implies, among other things, that command-line
-    arguments remain private.  Unless your deployment relies on unprivileged
-    users being able to inspect the process information of other users, this
-    option should be safe to enable.
-  </para>
-
-  <para>
-    Members of the <literal>proc</literal> group are exempt from process
-    information hiding.
-  </para>
-
-  <para>
-    To allow a service <replaceable>foo</replaceable> to run without process information hiding, set
+  ensures that access to process information is restricted to the owning user.
+  This implies, among other things, that command-line arguments remain private.
+  Unless your deployment relies on unprivileged users being able to inspect the
+  process information of other users, this option should be safe to enable.
+ </para>
+ <para>
+  Members of the <literal>proc</literal> group are exempt from process
+  information hiding.
+ </para>
+ <para>
+  To allow a service <replaceable>foo</replaceable> to run without process
+  information hiding, set
 <programlisting>
 <link linkend="opt-systemd.services._name_.serviceConfig">systemd.services.<replaceable>foo</replaceable>.serviceConfig</link>.SupplementaryGroups = [ "proc" ];
 </programlisting>
-  </para>
-
+ </para>
 </chapter>

nixos/modules/services/databases/foundationdb.xml

@@ -3,42 +3,50 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="module-services-foundationdb">
+ <title>FoundationDB</title>
+ <para>
+  <emphasis>Source:</emphasis>
+  <filename>modules/services/databases/foundationdb.nix</filename>
+ </para>
+ <para>
+  <emphasis>Upstream documentation:</emphasis>
+  <link xlink:href="https://apple.github.io/foundationdb/"/>
+ </para>
+ <para>
+  <emphasis>Maintainer:</emphasis> Austin Seipp
+ </para>
+ <para>
+  <emphasis>Available version(s):</emphasis> 5.1.x, 5.2.x, 6.0.x
+ </para>
+ <para>
+  FoundationDB (or "FDB") is an open source, distributed, transactional
+  key-value store.
+ </para>
+ <section xml:id="module-services-foundationdb-configuring">
+  <title>Configuring and basic setup</title>
 
-<title>FoundationDB</title>
-
-<para><emphasis>Source:</emphasis> <filename>modules/services/databases/foundationdb.nix</filename></para>
-
-<para><emphasis>Upstream documentation:</emphasis> <link xlink:href="https://apple.github.io/foundationdb/"/></para>
-
-<para><emphasis>Maintainer:</emphasis> Austin Seipp</para>
-
-<para><emphasis>Available version(s):</emphasis> 5.1.x, 5.2.x, 6.0.x</para>
-
-<para>FoundationDB (or "FDB") is an open source, distributed, transactional
-key-value store.</para>
-
-<section xml:id="module-services-foundationdb-configuring"><title>Configuring and basic setup</title>
-
-<para>To enable FoundationDB, add the following to your
-<filename>configuration.nix</filename>:
-
+  <para>
+   To enable FoundationDB, add the following to your
+   <filename>configuration.nix</filename>:
 <programlisting>
 services.foundationdb.enable = true;
 services.foundationdb.package = pkgs.foundationdb52; # FoundationDB 5.2.x
 </programlisting>
-</para>
+  </para>
 
-<para>The <option>services.foundationdb.package</option> option is required,
-and must always be specified. Due to the fact FoundationDB network protocols and
-on-disk storage formats may change between (major) versions, and upgrades must
-be explicitly handled by the user, you must always manually specify this
-yourself so that the NixOS module will use the proper version. Note that minor,
-bugfix releases are always compatible.</para>
-
-<para>After running <command>nixos-rebuild</command>, you can verify whether
-FoundationDB is running by executing <command>fdbcli</command> (which is added
-to <option>environment.systemPackages</option>):
+  <para>
+   The <option>services.foundationdb.package</option> option is required, and
+   must always be specified. Due to the fact FoundationDB network protocols and
+   on-disk storage formats may change between (major) versions, and upgrades
+   must be explicitly handled by the user, you must always manually specify
+   this yourself so that the NixOS module will use the proper version. Note
+   that minor, bugfix releases are always compatible.
+  </para>
 
+  <para>
+   After running <command>nixos-rebuild</command>, you can verify whether
+   FoundationDB is running by executing <command>fdbcli</command> (which is
+   added to <option>environment.systemPackages</option>):
 <programlisting>
 $ sudo -u foundationdb fdbcli
 Using cluster file `/etc/foundationdb/fdb.cluster'.
@@ -66,14 +74,14 @@ Cluster:
 
 fdb>
 </programlisting>
-</para>
-
-<para>You can also write programs using the available client libraries.
-For example, the following Python program can be run in order to grab the
-cluster status, as a quick example. (This example uses
-<command>nix-shell</command> shebang support to automatically supply the
-necessary Python modules).
+  </para>
 
+  <para>
+   You can also write programs using the available client libraries. For
+   example, the following Python program can be run in order to grab the
+   cluster status, as a quick example. (This example uses
+   <command>nix-shell</command> shebang support to automatically supply the
+   necessary Python modules).
 <programlisting>
 a@link> cat fdb-status.py
 #! /usr/bin/env nix-shell
@@ -100,255 +108,336 @@ a@link> ./fdb-status.py
 FoundationDB available: True
 a@link>
 </programlisting>
-</para>
+  </para>
 
-<para>FoundationDB is run under the <command>foundationdb</command> user and
-group by default, but this may be changed in the NixOS configuration. The
-systemd unit <command>foundationdb.service</command> controls the
-<command>fdbmonitor</command> process.</para>
+  <para>
+   FoundationDB is run under the <command>foundationdb</command> user and group
+   by default, but this may be changed in the NixOS configuration. The systemd
+   unit <command>foundationdb.service</command> controls the
+   <command>fdbmonitor</command> process.
+  </para>
 
-<para>By default, the NixOS module for FoundationDB creates a single
-SSD-storage based database for development and basic usage. This storage engine
-is designed for SSDs and will perform poorly on HDDs; however it can handle far
-more data than the alternative "memory" engine and is a better default choice
-for most deployments. (Note that you can change the storage backend on-the-fly
-for a given FoundationDB cluster using <command>fdbcli</command>.)</para>
+  <para>
+   By default, the NixOS module for FoundationDB creates a single SSD-storage
+   based database for development and basic usage. This storage engine is
+   designed for SSDs and will perform poorly on HDDs; however it can handle far
+   more data than the alternative "memory" engine and is a better default
+   choice for most deployments. (Note that you can change the storage backend
+   on-the-fly for a given FoundationDB cluster using
+   <command>fdbcli</command>.)
+  </para>
 
-<para>Furthermore, only 1 server process and 1 backup agent are started in the
-default configuration. See below for more on scaling to increase this.</para>
-
-<para>FoundationDB stores all data for all server processes under
-<filename>/var/lib/foundationdb</filename>. You can override this using
-<option>services.foundationdb.dataDir</option>, e.g.
+  <para>
+   Furthermore, only 1 server process and 1 backup agent are started in the
+   default configuration. See below for more on scaling to increase this.
+  </para>
 
+  <para>
+   FoundationDB stores all data for all server processes under
+   <filename>/var/lib/foundationdb</filename>. You can override this using
+   <option>services.foundationdb.dataDir</option>, e.g.
 <programlisting>
 services.foundationdb.dataDir = "/data/fdb";
 </programlisting>
+  </para>
 
-</para>
+  <para>
+   Similarly, logs are stored under <filename>/var/log/foundationdb</filename>
+   by default, and there is a corresponding
+   <option>services.foundationdb.logDir</option> as well.
+  </para>
+ </section>
+ <section xml:id="module-services-foundationdb-scaling">
+  <title>Scaling processes and backup agents</title>
 
-<para>Similarly, logs are stored under
-<filename>/var/log/foundationdb</filename> by default, and there is a
-corresponding <option>services.foundationdb.logDir</option> as well.</para>
+  <para>
+   Scaling the number of server processes is quite easy; simply specify
+   <option>services.foundationdb.serverProcesses</option> to be the number of
+   FoundationDB worker processes that should be started on the machine.
+  </para>
 
-</section>
+  <para>
+   FoundationDB worker processes typically require 4GB of RAM per-process at
+   minimum for good performance, so this option is set to 1 by default since
+   the maximum amount of RAM is unknown. You're advised to abide by this
+   restriction, so pick a number of processes so that each has 4GB or more.
+  </para>
 
-<section xml:id="module-services-foundationdb-scaling"><title>Scaling processes and backup agents</title>
+  <para>
+   A similar option exists in order to scale backup agent processes,
+   <option>services.foundationdb.backupProcesses</option>. Backup agents are
+   not as performance/RAM sensitive, so feel free to experiment with the number
+   of available backup processes.
+  </para>
+ </section>
+ <section xml:id="module-services-foundationdb-clustering">
+  <title>Clustering</title>
 
-<para>Scaling the number of server processes is quite easy; simply specify
-<option>services.foundationdb.serverProcesses</option> to be the number of
-FoundationDB worker processes that should be started on the machine.</para>
+  <para>
+   FoundationDB on NixOS works similarly to other Linux systems, so this
+   section will be brief. Please refer to the full FoundationDB documentation
+   for more on clustering.
+  </para>
 
-<para>FoundationDB worker processes typically require 4GB of RAM per-process at
-minimum for good performance, so this option is set to 1 by default since the
-maximum amount of RAM is unknown. You're advised to abide by this restriction,
-so pick a number of processes so that each has 4GB or more.</para>
+  <para>
+   FoundationDB organizes clusters using a set of
+   <emphasis>coordinators</emphasis>, which are just specially-designated
+   worker processes. By default, every installation of FoundationDB on NixOS
+   will start as its own individual cluster, with a single coordinator: the
+   first worker process on <command>localhost</command>.
+  </para>
 
-<para>A similar option exists in order to scale backup agent processes,
-<option>services.foundationdb.backupProcesses</option>. Backup agents are not
-as performance/RAM sensitive, so feel free to experiment with the number of
-available backup processes.</para>
+  <para>
+   Coordinators are specified globally using the
+   <command>/etc/foundationdb/fdb.cluster</command> file, which all servers and
+   client applications will use to find and join coordinators. Note that this
+   file <emphasis>can not</emphasis> be managed by NixOS so easily:
+   FoundationDB is designed so that it will rewrite the file at runtime for all
+   clients and nodes when cluster coordinators change, with clients
+   transparently handling this without intervention. It is fundamentally a
+   mutable file, and you should not try to manage it in any way in NixOS.
+  </para>
 
-</section>
+  <para>
+   When dealing with a cluster, there are two main things you want to do:
+  </para>
 
-<section xml:id="module-services-foundationdb-clustering"><title>Clustering</title>
+  <itemizedlist>
+   <listitem>
+    <para>
+     Add a node to the cluster for storage/compute.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Promote an ordinary worker to a coordinator.
+    </para>
+   </listitem>
+  </itemizedlist>
 
-<para>FoundationDB on NixOS works similarly to other Linux systems, so this
-section will be brief. Please refer to the full FoundationDB documentation for
-more on clustering.</para>
+  <para>
+   A node must already be a member of the cluster in order to properly be
+   promoted to a coordinator, so you must always add it first if you wish to
+   promote it.
+  </para>
 
-<para>FoundationDB organizes clusters using a set of
-<emphasis>coordinators</emphasis>, which are just specially-designated worker
-processes. By default, every installation of FoundationDB on NixOS will start
-as its own individual cluster, with a single coordinator: the first worker
-process on <command>localhost</command>.</para>
+  <para>
+   To add a machine to a FoundationDB cluster:
+  </para>
 
-<para>Coordinators are specified globally using the
-<command>/etc/foundationdb/fdb.cluster</command> file, which all servers and
-client applications will use to find and join coordinators. Note that this file
-<emphasis>can not</emphasis> be managed by NixOS so easily: FoundationDB is
-designed so that it will rewrite the file at runtime for all clients and nodes
-when cluster coordinators change, with clients transparently handling this
-without intervention. It is fundamentally a mutable file, and you should not
-try to manage it in any way in NixOS.</para>
+  <itemizedlist>
+   <listitem>
+    <para>
+     Choose one of the servers to start as the initial coordinator.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Copy the <command>/etc/foundationdb/fdb.cluster</command> file from this
+     server to all the other servers. Restart FoundationDB on all of these
+     other servers, so they join the cluster.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     All of these servers are now connected and working together in the
+     cluster, under the chosen coordinator.
+    </para>
+   </listitem>
+  </itemizedlist>
 
-<para>When dealing with a cluster, there are two main things you want to
-do:</para>
+  <para>
+   At this point, you can add as many nodes as you want by just repeating the
+   above steps. By default there will still be a single coordinator: you can
+   use <command>fdbcli</command> to change this and add new coordinators.
+  </para>
 
-<itemizedlist>
-  <listitem><para>Add a node to the cluster for storage/compute.</para></listitem>
-  <listitem><para>Promote an ordinary worker to a coordinator.</para></listitem>
-</itemizedlist>
+  <para>
+   As a convenience, FoundationDB can automatically assign coordinators based
+   on the redundancy mode you wish to achieve for the cluster. Once all the
+   nodes have been joined, simply set the replication policy, and then issue
+   the <command>coordinators auto</command> command
+  </para>
 
-<para>A node must already be a member of the cluster in order to properly be
-promoted to a coordinator, so you must always add it first if you wish to
-promote it.</para>
-
-<para>To add a machine to a FoundationDB cluster:</para>
-
-<itemizedlist>
-  <listitem><para>Choose one of the servers to start as the initial coordinator.
-      </para></listitem>
-  <listitem><para>Copy the <command>/etc/foundationdb/fdb.cluster</command> file
-      from this server to all the other servers. Restart FoundationDB on all of
-      these other servers, so they join the cluster.</para></listitem>
-  <listitem><para>All of these servers are now connected and working together
-      in the cluster, under the chosen coordinator.</para></listitem>
-</itemizedlist>
-
-<para>At this point, you can add as many nodes as you want by just repeating
-the above steps. By default there will still be a single coordinator: you can
-use <command>fdbcli</command> to change this and add new coordinators.</para>
-
-<para>As a convenience, FoundationDB can automatically assign coordinators
-based on the redundancy mode you wish to achieve for the cluster. Once all the
-nodes have been joined, simply set the replication policy, and then issue the
-<command>coordinators auto</command> command</para>
-
-<para>For example, assuming we have 3 nodes available, we can enable double
-redundancy mode, then auto-select coordinators. For double redundancy, 3
-coordinators is ideal: therefore FoundationDB will make
-<emphasis>every</emphasis> node a coordinator automatically:</para>
+  <para>
+   For example, assuming we have 3 nodes available, we can enable double
+   redundancy mode, then auto-select coordinators. For double redundancy, 3
+   coordinators is ideal: therefore FoundationDB will make
+   <emphasis>every</emphasis> node a coordinator automatically:
+  </para>
 
 <programlisting>
 fdbcli> configure double ssd
 fdbcli> coordinators auto
 </programlisting>
 
-<para>This will transparently update all the servers within seconds, and
-appropriately rewrite the <command>fdb.cluster</command> file, as well as
-informing all client processes to do the same.</para>
+  <para>
+   This will transparently update all the servers within seconds, and
+   appropriately rewrite the <command>fdb.cluster</command> file, as well as
+   informing all client processes to do the same.
+  </para>
+ </section>
+ <section xml:id="module-services-foundationdb-connectivity">
+  <title>Client connectivity</title>
 
-</section>
+  <para>
+   By default, all clients must use the current <command>fdb.cluster</command>
+   file to access a given FoundationDB cluster. This file is located by default
+   in <command>/etc/foundationdb/fdb.cluster</command> on all machines with the
+   FoundationDB service enabled, so you may copy the active one from your
+   cluster to a new node in order to connect, if it is not part of the cluster.
+  </para>
+ </section>
+ <section xml:id="module-services-foundationdb-authorization">
+  <title>Client authorization and TLS</title>
 
-<section xml:id="module-services-foundationdb-connectivity"><title>Client connectivity</title>
+  <para>
+   By default, any user who can connect to a FoundationDB process with the
+   correct cluster configuration can access anything. FoundationDB uses a
+   pluggable design to transport security, and out of the box it supports a
+   LibreSSL-based plugin for TLS support. This plugin not only does in-flight
+   encryption, but also performs client authorization based on the given
+   endpoint's certificate chain. For example, a FoundationDB server may be
+   configured to only accept client connections over TLS, where the client TLS
+   certificate is from organization <emphasis>Acme Co</emphasis> in the
+   <emphasis>Research and Development</emphasis> unit.
+  </para>
 
-<para>By default, all clients must use the current
-<command>fdb.cluster</command> file to access a given FoundationDB cluster.
-This file is located by default in
-<command>/etc/foundationdb/fdb.cluster</command> on all machines with the
-FoundationDB service enabled, so you may copy the active one from your cluster
-to a new node in order to connect, if it is not part of the cluster.</para>
+  <para>
+   Configuring TLS with FoundationDB is done using the
+   <option>services.foundationdb.tls</option> options in order to control the
+   peer verification string, as well as the certificate and its private key.
+  </para>
 
-</section>
+  <para>
+   Note that the certificate and its private key must be accessible to the
+   FoundationDB user account that the server runs under. These files are also
+   NOT managed by NixOS, as putting them into the store may reveal private
+   information.
+  </para>
 
-<section xml:id="module-services-foundationdb-authorization"><title>Client authorization and TLS</title>
-
-<para>By default, any user who can connect to a FoundationDB process with the
-correct cluster configuration can access anything. FoundationDB uses a
-pluggable design to transport security, and out of the box it supports a
-LibreSSL-based plugin for TLS support. This plugin not only does in-flight
-encryption, but also performs client authorization based on the given
-endpoint's certificate chain. For example, a FoundationDB server may be
-configured to only accept client connections over TLS, where the client TLS
-certificate is from organization <emphasis>Acme Co</emphasis> in the
-<emphasis>Research and Development</emphasis> unit.</para>
-
-<para>Configuring TLS with FoundationDB is done using the
-<option>services.foundationdb.tls</option> options in order to control the peer
-verification string, as well as the certificate and its private key.</para>
-
-<para>Note that the certificate and its private key must be accessible to the
-FoundationDB user account that the server runs under. These files are also NOT
-managed by NixOS, as putting them into the store may reveal private
-information.</para>
-
-<para>After you have a key and certificate file in place, it is not enough to
-simply set the NixOS module options -- you must also configure the
-<command>fdb.cluster</command> file to specify that a given set of coordinators
-use TLS. This is as simple as adding the suffix <command>:tls</command> to your
-cluster coordinator configuration, after the port number. For example, assuming
-you have a coordinator on localhost with the default configuration, simply
-specifying:</para>
+  <para>
+   After you have a key and certificate file in place, it is not enough to
+   simply set the NixOS module options -- you must also configure the
+   <command>fdb.cluster</command> file to specify that a given set of
+   coordinators use TLS. This is as simple as adding the suffix
+   <command>:tls</command> to your cluster coordinator configuration, after the
+   port number. For example, assuming you have a coordinator on localhost with
+   the default configuration, simply specifying:
+  </para>
 
 <programlisting>
 XXXXXX:XXXXXX@127.0.0.1:4500:tls
 </programlisting>
 
-<para>will configure all clients and server processes to use TLS from now
-on.</para>
+  <para>
+   will configure all clients and server processes to use TLS from now on.
+  </para>
+ </section>
+ <section xml:id="module-services-foundationdb-disaster-recovery">
+  <title>Backups and Disaster Recovery</title>
 
-</section>
+  <para>
+   The usual rules for doing FoundationDB backups apply on NixOS as written in
+   the FoundationDB manual. However, one important difference is the security
+   profile for NixOS: by default, the <command>foundationdb</command> systemd
+   unit uses <emphasis>Linux namespaces</emphasis> to restrict write access to
+   the system, except for the log directory, data directory, and the
+   <command>/etc/foundationdb/</command> directory. This is enforced by default
+   and cannot be disabled.
+  </para>
 
-<section xml:id="module-services-foundationdb-disaster-recovery"><title>Backups and Disaster Recovery</title>
+  <para>
+   However, a side effect of this is that the <command>fdbbackup</command>
+   command doesn't work properly for local filesystem backups: FoundationDB
+   uses a server process alongside the database processes to perform backups
+   and copy the backups to the filesystem. As a result, this process is put
+   under the restricted namespaces above: the backup process can only write to
+   a limited number of paths.
+  </para>
 
-<para>The usual rules for doing FoundationDB backups apply on NixOS as written
-in the FoundationDB manual. However, one important difference is the security
-profile for NixOS: by default, the <command>foundationdb</command> systemd unit
-uses <emphasis>Linux namespaces</emphasis> to restrict write access to the
-system, except for the log directory, data directory, and the
-<command>/etc/foundationdb/</command> directory. This is enforced by default
-and cannot be disabled.</para>
+  <para>
+   In order to allow flexible backup locations on local disks, the FoundationDB
+   NixOS module supports a
+   <option>services.foundationdb.extraReadWritePaths</option> option. This
+   option takes a list of paths, and adds them to the systemd unit, allowing
+   the processes inside the service to write (and read) the specified
+   directories.
+  </para>
 
-<para>However, a side effect of this is that the <command>fdbbackup</command>
-command doesn't work properly for local filesystem backups: FoundationDB uses a
-server process alongside the database processes to perform backups and copy the
-backups to the filesystem. As a result, this process is put under the
-restricted namespaces above: the backup process can only write to a limited
-number of paths.</para>
-
-<para>In order to allow flexible backup locations on local disks, the
-FoundationDB NixOS module supports a
-<option>services.foundationdb.extraReadWritePaths</option> option. This option
-takes a list of paths, and adds them to the systemd unit, allowing the
-processes inside the service to write (and read) the specified
-directories.</para>
-
-<para>For example, to create backups in <command>/opt/fdb-backups</command>,
-first set up the paths in the module options:</para>
+  <para>
+   For example, to create backups in <command>/opt/fdb-backups</command>, first
+   set up the paths in the module options:
+  </para>
 
 <programlisting>
 services.foundationdb.extraReadWritePaths = [ "/opt/fdb-backups" ];
 </programlisting>
 
-<para>Restart the FoundationDB service, and it will now be able to write to
-this directory (even if it does not yet exist.) Note: this path
-<emphasis>must</emphasis> exist before restarting the unit. Otherwise, systemd
-will not include it in the private FoundationDB namespace (and it will not add
-it dynamically at runtime).</para>
+  <para>
+   Restart the FoundationDB service, and it will now be able to write to this
+   directory (even if it does not yet exist.) Note: this path
+   <emphasis>must</emphasis> exist before restarting the unit. Otherwise,
+   systemd will not include it in the private FoundationDB namespace (and it
+   will not add it dynamically at runtime).
+  </para>
 
-<para>You can now perform a backup:</para>
+  <para>
+   You can now perform a backup:
+  </para>
 
 <programlisting>
 $ sudo -u foundationdb fdbbackup start  -t default -d file:///opt/fdb-backups
 $ sudo -u foundationdb fdbbackup status -t default
 </programlisting>
+ </section>
+ <section xml:id="module-services-foundationdb-limitations">
+  <title>Known limitations</title>
 
-</section>
+  <para>
+   The FoundationDB setup for NixOS should currently be considered beta.
+   FoundationDB is not new software, but the NixOS compilation and integration
+   has only undergone fairly basic testing of all the available functionality.
+  </para>
 
-<section xml:id="module-services-foundationdb-limitations"><title>Known limitations</title>
+  <itemizedlist>
+   <listitem>
+    <para>
+     There is no way to specify individual parameters for individual
+     <command>fdbserver</command> processes. Currently, all server processes
+     inherit all the global <command>fdbmonitor</command> settings.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Ruby bindings are not currently installed.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Go bindings are not currently installed.
+    </para>
+   </listitem>
+  </itemizedlist>
+ </section>
+ <section xml:id="module-services-foundationdb-options">
+  <title>Options</title>
 
-<para>The FoundationDB setup for NixOS should currently be considered beta.
-FoundationDB is not new software, but the NixOS compilation and integration has
-only undergone fairly basic testing of all the available functionality.</para>
-
-<itemizedlist>
-  <listitem><para>There is no way to specify individual parameters for
-      individual <command>fdbserver</command> processes. Currently, all server
-      processes inherit all the global <command>fdbmonitor</command> settings.
-      </para></listitem>
-  <listitem><para>Ruby bindings are not currently installed.</para></listitem>
-  <listitem><para>Go bindings are not currently installed.</para></listitem>
-</itemizedlist>
-
-</section>
-
-<section xml:id="module-services-foundationdb-options"><title>Options</title>
-
-<para>NixOS's FoundationDB module allows you to configure all of the most
-relevant configuration options for <command>fdbmonitor</command>, matching it
-quite closely. A complete list of options for the FoundationDB module may be
-found <link linkend="opt-services.foundationdb.enable">here</link>. You should
-also read the FoundationDB documentation as well.</para>
-
-</section>
-
-<section xml:id="module-services-foundationdb-full-docs"><title>Full documentation</title>
-
-<para>FoundationDB is a complex piece of software, and requires careful
-administration to properly use. Full documentation for administration can be
-found here: <link xlink:href="https://apple.github.io/foundationdb/"/>.</para>
-
-</section>
+  <para>
+   NixOS's FoundationDB module allows you to configure all of the most relevant
+   configuration options for <command>fdbmonitor</command>, matching it quite
+   closely. A complete list of options for the FoundationDB module may be found
+   <link linkend="opt-services.foundationdb.enable">here</link>. You should
+   also read the FoundationDB documentation as well.
+  </para>
+ </section>
+ <section xml:id="module-services-foundationdb-full-docs">
+  <title>Full documentation</title>
 
+  <para>
+   FoundationDB is a complex piece of software, and requires careful
+   administration to properly use. Full documentation for administration can be
+   found here: <link xlink:href="https://apple.github.io/foundationdb/"/>.
+  </para>
+ </section>
 </chapter>

nixos/modules/services/databases/postgresql.nix

@@ -188,6 +188,8 @@ in
         uid = config.ids.uids.postgres;
         group = "postgres";
         description = "PostgreSQL server user";
+        home = "${cfg.dataDir}";
+        useDefaultShell = true;
       };
 
     users.groups.postgres.gid = config.ids.gids.postgres;

nixos/modules/services/databases/postgresql.xml

@@ -3,36 +3,39 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="module-postgresql">
-
-<title>PostgreSQL</title>
-
+ <title>PostgreSQL</title>
 <!-- FIXME: render nicely -->
-
 <!-- FIXME: source can be added automatically -->
-<para><emphasis>Source:</emphasis> <filename>modules/services/databases/postgresql.nix</filename></para>
-
-<para><emphasis>Upstream documentation:</emphasis> <link xlink:href="http://www.postgresql.org/docs/"/></para>
-
+ <para>
+  <emphasis>Source:</emphasis>
+  <filename>modules/services/databases/postgresql.nix</filename>
+ </para>
+ <para>
+  <emphasis>Upstream documentation:</emphasis>
+  <link xlink:href="http://www.postgresql.org/docs/"/>
+ </para>
 <!-- FIXME: more stuff, like maintainer? -->
+ <para>
+  PostgreSQL is an advanced, free relational database.
+<!-- MORE -->
+ </para>
+ <section xml:id="module-services-postgres-configuring">
+  <title>Configuring</title>
 
-<para>PostgreSQL is an advanced, free relational database.<!-- MORE --></para>
-
-<section xml:id="module-services-postgres-configuring"><title>Configuring</title>
-
-<para>To enable PostgreSQL, add the following to your
-<filename>configuration.nix</filename>:
-
+  <para>
+   To enable PostgreSQL, add the following to your
+   <filename>configuration.nix</filename>:
 <programlisting>
 <xref linkend="opt-services.postgresql.enable"/> = true;
 <xref linkend="opt-services.postgresql.package"/> = pkgs.postgresql94;
 </programlisting>
-
-Note that you are required to specify the desired version of
-PostgreSQL (e.g. <literal>pkgs.postgresql94</literal>). Since
-upgrading your PostgreSQL version requires a database dump and reload
-(see below), NixOS cannot provide a default value for
-<xref linkend="opt-services.postgresql.package"/> such as the most recent
-release of PostgreSQL.</para>
+   Note that you are required to specify the desired version of PostgreSQL
+   (e.g. <literal>pkgs.postgresql94</literal>). Since upgrading your PostgreSQL
+   version requires a database dump and reload (see below), NixOS cannot
+   provide a default value for
+   <xref linkend="opt-services.postgresql.package"/> such as the most recent
+   release of PostgreSQL.
+  </para>
 
 <!--
 <para>After running <command>nixos-rebuild</command>, you can verify
@@ -47,31 +50,28 @@ alice=>
 </screen>
 -->
 
-<para>By default, PostgreSQL stores its databases in
-<filename>/var/db/postgresql</filename>. You can override this using
-<xref linkend="opt-services.postgresql.dataDir"/>, e.g.
-
+  <para>
+   By default, PostgreSQL stores its databases in
+   <filename>/var/db/postgresql</filename>. You can override this using
+   <xref linkend="opt-services.postgresql.dataDir"/>, e.g.
 <programlisting>
 <xref linkend="opt-services.postgresql.dataDir"/> = "/data/postgresql";
 </programlisting>
+  </para>
+ </section>
+ <section xml:id="module-services-postgres-upgrading">
+  <title>Upgrading</title>
 
-</para>
-
-</section>
-
-
-<section xml:id="module-services-postgres-upgrading"><title>Upgrading</title>
-
-<para>FIXME: document dump/upgrade/load cycle.</para>
-
-</section>
-
-
-<section xml:id="module-services-postgres-options"><title>Options</title>
-
-  <para>A complete list of options for the PostgreSQL module may be found <link linkend="opt-services.postgresql.enable">here</link>.</para>
-
-</section>
-
+  <para>
+   FIXME: document dump/upgrade/load cycle.
+  </para>
+ </section>
+ <section xml:id="module-services-postgres-options">
+  <title>Options</title>
 
+  <para>
+   A complete list of options for the PostgreSQL module may be found
+   <link linkend="opt-services.postgresql.enable">here</link>.
+  </para>
+ </section>
 </chapter>

nixos/modules/services/desktops/flatpak.xml

@@ -3,51 +3,54 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="module-services-flatpak">
-
-<title>Flatpak</title>
-
-<para><emphasis>Source:</emphasis> <filename>modules/services/desktop/flatpak.nix</filename></para>
-
-<para><emphasis>Upstream documentation:</emphasis> <link xlink:href="https://github.com/flatpak/flatpak/wiki"/></para>
-
-<para>Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux.</para>
-
-<para>
-  To enable Flatpak, add the following to your <filename>configuration.nix</filename>:
-
-  <programlisting>
+ <title>Flatpak</title>
+ <para>
+  <emphasis>Source:</emphasis>
+  <filename>modules/services/desktop/flatpak.nix</filename>
+ </para>
+ <para>
+  <emphasis>Upstream documentation:</emphasis>
+  <link xlink:href="https://github.com/flatpak/flatpak/wiki"/>
+ </para>
+ <para>
+  Flatpak is a system for building, distributing, and running sandboxed desktop
+  applications on Linux.
+ </para>
+ <para>
+  To enable Flatpak, add the following to your
+  <filename>configuration.nix</filename>:
+<programlisting>
   <xref linkend="opt-services.flatpak.enable"/> = true;
   </programlisting>
-</para>
-
-<para>
-  For the sandboxed apps to work correctly, desktop integration portals need to be installed. If you run GNOME, this will be handled automatically for you; in other cases, you will need to add something like the following to your <filename>configuration.nix</filename>:
-
-  <programlisting>
+ </para>
+ <para>
+  For the sandboxed apps to work correctly, desktop integration portals need to
+  be installed. If you run GNOME, this will be handled automatically for you;
+  in other cases, you will need to add something like the following to your
+  <filename>configuration.nix</filename>:
+<programlisting>
   <xref linkend="opt-services.flatpak.extraPortals"/> = [ pkgs.xdg-desktop-portal-gtk ];
   </programlisting>
-</para>
-
-<para>
-  Then, you will need to add a repository, for example, <link xlink:href="https://github.com/flatpak/flatpak/wiki">Flathub</link>, either using the following commands:
-
-  <programlisting>
+ </para>
+ <para>
+  Then, you will need to add a repository, for example,
+  <link xlink:href="https://github.com/flatpak/flatpak/wiki">Flathub</link>,
+  either using the following commands:
+<programlisting>
   flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
   flatpak update
   </programlisting>
-
-  or by opening the <link xlink:href="https://flathub.org/repo/flathub.flatpakrepo">repository file</link> in GNOME Software.
-</para>
-
-<para>
+  or by opening the
+  <link xlink:href="https://flathub.org/repo/flathub.flatpakrepo">repository
+  file</link> in GNOME Software.
+ </para>
+ <para>
   Finally, you can search and install programs:
-
-  <programlisting>
+<programlisting>
   flatpak search bustle
   flatpak install flathub org.freedesktop.Bustle
   flatpak run org.freedesktop.Bustle
   </programlisting>
-
   Again, GNOME Software offers graphical interface for these tasks.
-</para>
+ </para>
 </chapter>

nixos/modules/services/editors/emacs.xml

@@ -3,150 +3,148 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="module-services-emacs">
-
-  <title>Emacs</title>
-
-  <!--
+ <title>Emacs</title>
+<!--
     Documentation contributors:
       Damien Cassou @DamienCassou
       Thomas Tuegel @ttuegel
       Rodney Lorrimar @rvl
   -->
+ <para>
+  <link xlink:href="http://www.gnu.org/software/emacs/">Emacs</link> is an
+  extensible, customizable, self-documenting real-time display editor — and
+  more. At its core is an interpreter for Emacs Lisp, a dialect of the Lisp
+  programming language with extensions to support text editing.
+ </para>
+ <para>
+  Emacs runs within a graphical desktop environment using the X Window System,
+  but works equally well on a text terminal. Under
+  <productname>macOS</productname>, a "Mac port" edition is available, which
+  uses Apple's native GUI frameworks.
+ </para>
+ <para>
+  <productname>Nixpkgs</productname> provides a superior environment for
+  running <application>Emacs</application>. It's simple to create custom builds
+  by overriding the default packages. Chaotic collections of Emacs Lisp code
+  and extensions can be brought under control using declarative package
+  management. <productname>NixOS</productname> even provides a
+  <command>systemd</command> user service for automatically starting the Emacs
+  daemon.
+ </para>
+ <section xml:id="module-services-emacs-installing">
+  <title>Installing <application>Emacs</application></title>
 
   <para>
-    <link xlink:href="http://www.gnu.org/software/emacs/">Emacs</link>
-    is an extensible, customizable, self-documenting real-time display
-    editor — and more. At its core is an interpreter for Emacs Lisp, a
-    dialect of the Lisp programming language with extensions to
-    support text editing.
+   Emacs can be installed in the normal way for Nix (see
+   <xref linkend="sec-package-management" />). In addition, a NixOS
+   <emphasis>service</emphasis> can be enabled.
   </para>
 
-  <para>
-    Emacs runs within a graphical desktop environment using the X
-    Window System, but works equally well on a text terminal. Under
-    <productname>macOS</productname>, a "Mac port" edition is
-    available, which uses Apple's native GUI frameworks.
-  </para>
+  <section xml:id="module-services-emacs-releases">
+   <title>The Different Releases of Emacs</title>
 
-  <para>
-    <productname>Nixpkgs</productname> provides a superior environment
-    for running <application>Emacs</application>. It's simple to
-    create custom builds by overriding the default packages. Chaotic
-    collections of Emacs Lisp code and extensions can be brought under
-    control using declarative package
-    management. <productname>NixOS</productname> even provides a
-    <command>systemd</command> user service for automatically
-    starting the Emacs daemon.
-  </para>
+   <para>
+    <productname>Nixpkgs</productname> defines several basic Emacs packages.
+    The following are attributes belonging to the <varname>pkgs</varname> set:
+    <variablelist>
+     <varlistentry>
+      <term>
+       <varname>emacs</varname>
+      </term>
+      <term>
+       <varname>emacs25</varname>
+      </term>
+      <listitem>
+       <para>
+        The latest stable version of Emacs 25 using the
+        <link
+                xlink:href="http://www.gtk.org">GTK+ 2</link>
+        widget toolkit.
+       </para>
+      </listitem>
+     </varlistentry>
+     <varlistentry>
+      <term>
+       <varname>emacs25-nox</varname>
+      </term>
+      <listitem>
+       <para>
+        Emacs 25 built without any dependency on X11 libraries.
+       </para>
+      </listitem>
+     </varlistentry>
+     <varlistentry>
+      <term>
+       <varname>emacsMacport</varname>
+      </term>
+      <term>
+       <varname>emacs25Macport</varname>
+      </term>
+      <listitem>
+       <para>
+        Emacs 25 with the "Mac port" patches, providing a more native look and
+        feel under macOS.
+       </para>
+      </listitem>
+     </varlistentry>
+    </variablelist>
+   </para>
 
-  <section xml:id="module-services-emacs-installing">
-    <title>Installing <application>Emacs</application></title>
+   <para>
+    If those aren't suitable, then the following imitation Emacs editors are
+    also available in Nixpkgs:
+    <link xlink:href="https://www.gnu.org/software/zile/">Zile</link>,
+    <link xlink:href="http://homepage.boetes.org/software/mg/">mg</link>,
+    <link xlink:href="http://yi-editor.github.io/">Yi</link>.
+   </para>
+  </section>
 
-    <para>
-      Emacs can be installed in the normal way for Nix (see
-      <xref linkend="sec-package-management" />).
-      In addition, a NixOS <emphasis>service</emphasis>
-      can be enabled.
-    </para>
+  <section xml:id="module-services-emacs-adding-packages">
+   <title>Adding Packages to Emacs</title>
 
-    <section xml:id="module-services-emacs-releases">
-      <title>The Different Releases of Emacs</title>
+   <para>
+    Emacs includes an entire ecosystem of functionality beyond text editing,
+    including a project planner, mail and news reader, debugger interface,
+    calendar, and more.
+   </para>
 
-      <para>
-        <productname>Nixpkgs</productname> defines several basic Emacs
-        packages. The following are attributes belonging to the
-        <varname>pkgs</varname> set:
-
-        <variablelist>
-          <varlistentry>
-            <term><varname>emacs</varname></term>
-            <term><varname>emacs25</varname></term>
-            <listitem>
-              <para>
-                The latest stable version of Emacs 25 using the <link
-                xlink:href="http://www.gtk.org">GTK+ 2</link> widget
-                toolkit.
-              </para>
-            </listitem>
-          </varlistentry>
-          <varlistentry>
-            <term><varname>emacs25-nox</varname></term>
-            <listitem>
-              <para>
-                Emacs 25 built without any dependency on X11
-                libraries.
-              </para>
-            </listitem>
-          </varlistentry>
-          <varlistentry>
-            <term><varname>emacsMacport</varname></term>
-            <term><varname>emacs25Macport</varname></term>
-            <listitem>
-              <para>
-                Emacs 25 with the "Mac port" patches, providing a more
-                native look and feel under macOS.
-              </para>
-            </listitem>
-          </varlistentry>
-        </variablelist>
-      </para>
-
-      <para>
-        If those aren't suitable, then the following imitation Emacs
-        editors are also available in Nixpkgs:
-        <link xlink:href="https://www.gnu.org/software/zile/">Zile</link>,
-        <link xlink:href="http://homepage.boetes.org/software/mg/">mg</link>,
-        <link xlink:href="http://yi-editor.github.io/">Yi</link>.
-      </para>
-
-    </section>
-    <section xml:id="module-services-emacs-adding-packages">
-      <title>Adding Packages to Emacs</title>
-      <para>
-        Emacs includes an entire ecosystem of functionality beyond
-        text editing, including a project planner, mail and news
-        reader, debugger interface, calendar, and more.
-      </para>
-
-      <para>
-        Most extensions are gotten with the Emacs packaging system
-        (<filename>package.el</filename>) from <link
+   <para>
+    Most extensions are gotten with the Emacs packaging system
+    (<filename>package.el</filename>) from
+    <link
         xlink:href="https://elpa.gnu.org/">Emacs Lisp Package Archive
-        (<acronym>ELPA</acronym>)</link>,
-        <link xlink:href="https://melpa.org/"><acronym>MELPA</acronym></link>,
-        <link xlink:href="https://stable.melpa.org/">MELPA Stable</link>,
-        and <link xlink:href="http://orgmode.org/elpa.html">Org ELPA</link>.
-        Nixpkgs is regularly updated to mirror all these archives.
-      </para>
+    (<acronym>ELPA</acronym>)</link>,
+    <link xlink:href="https://melpa.org/"><acronym>MELPA</acronym></link>,
+    <link xlink:href="https://stable.melpa.org/">MELPA Stable</link>, and
+    <link xlink:href="http://orgmode.org/elpa.html">Org ELPA</link>. Nixpkgs is
+    regularly updated to mirror all these archives.
+   </para>
 
-      <para>
-        Under NixOS, you can continue to use
-        <function>package-list-packages</function> and
-        <function>package-install</function> to install packages. You
-        can also declare the set of Emacs packages you need using the
-        derivations from Nixpkgs. The rest of this section discusses
-        declarative installation of Emacs packages through nixpkgs.
-      </para>
+   <para>
+    Under NixOS, you can continue to use
+    <function>package-list-packages</function> and
+    <function>package-install</function> to install packages. You can also
+    declare the set of Emacs packages you need using the derivations from
+    Nixpkgs. The rest of this section discusses declarative installation of
+    Emacs packages through nixpkgs.
+   </para>
 
-      <note>
-        <para>
-          This documentation describes the new Emacs packages
-          framework in NixOS 16.03
-          (<varname>emacsPackagesNg</varname>) which should not be
-          confused with the previous and deprecated framework
-          (<varname>emacs24Packages</varname>).
-        </para>
-      </note>
+   <note>
+    <para>
+     This documentation describes the new Emacs packages framework in NixOS
+     16.03 (<varname>emacsPackagesNg</varname>) which should not be confused
+     with the previous and deprecated framework
+     (<varname>emacs24Packages</varname>).
+    </para>
+   </note>
 
-      <para>
-        The first step to declare the list of packages you want in
-        your Emacs installation is to create a dedicated
-        derivation. This can be done in a dedicated
-        <filename>emacs.nix</filename> file such as:
-
-      <example xml:id="ex-emacsNix">
-        <title>Nix expression to build Emacs with packages (<filename>emacs.nix</filename>)</title>
-        <programlisting language="nix">
+   <para>
+    The first step to declare the list of packages you want in your Emacs
+    installation is to create a dedicated derivation. This can be done in a
+    dedicated <filename>emacs.nix</filename> file such as:
+    <example xml:id="ex-emacsNix">
+     <title>Nix expression to build Emacs with packages (<filename>emacs.nix</filename>)</title>
+<programlisting language="nix">
 /*
 This is a nix expression to build Emacs and some Emacs packages I like
 from source on any distribution where Nix is installed. This will install
@@ -181,119 +179,104 @@ in
     pkgs.notmuch   # From main packages set <co xml:id="ex-emacsNix-7" />
   ])
 </programlisting>
-      </example>
-
-      <calloutlist>
-        <callout arearefs="ex-emacsNix-1">
-          <para>
-            The first non-comment line in this file
-            (<literal>{ pkgs ? ... }</literal>)
-            indicates that the whole file represents a function.
-          </para>
-        </callout>
-
-        <callout arearefs="ex-emacsNix-2">
-          <para>
-            The <varname>let</varname> expression below defines a
-            <varname>myEmacs</varname> binding pointing to the current
-            stable version of Emacs. This binding is here to separate the
-            choice of the Emacs binary from the specification of the
-            required packages.
-          </para>
-        </callout>
-
-        <callout arearefs="ex-emacsNix-3">
-          <para>
-            This generates an <varname>emacsWithPackages</varname>
-            function. It takes a single argument: a function from a
-            package set to a list of packages (the packages that will
-            be available in Emacs).
-          </para>
-        </callout>
-
-        <callout arearefs="ex-emacsNix-4">
-          <para>
-            The rest of the file specifies the list of packages to
-            install. In the example, two packages
-            (<varname>magit</varname> and
-            <varname>zerodark-theme</varname>) are taken from MELPA
-            stable.
-          </para>
-        </callout>
-
-        <callout arearefs="ex-emacsNix-5">
-          <para>
-            Two packages (<varname>undo-tree</varname> and
-            <varname>zoom-frm</varname>) are taken from MELPA.
-          </para>
-        </callout>
-
-        <callout arearefs="ex-emacsNix-6">
-          <para>Three packages are taken from GNU ELPA.</para>
-        </callout>
-
-        <callout arearefs="ex-emacsNix-7">
-          <para>
-            <varname>notmuch</varname> is taken from a nixpkgs derivation
-            which contains an Emacs mode.
-          </para>
-        </callout>
-
-      </calloutlist>
-      </para>
-
+    </example>
+    <calloutlist>
+     <callout arearefs="ex-emacsNix-1">
       <para>
-        The result of this configuration will be an
-        <command>emacs</command> command which launches Emacs with all
-        of your chosen packages in the <varname>load-path</varname>.
+       The first non-comment line in this file (<literal>{ pkgs ? ...
+       }</literal>) indicates that the whole file represents a function.
       </para>
-
+     </callout>
+     <callout arearefs="ex-emacsNix-2">
       <para>
-        You can check that it works by executing this in a terminal:
+       The <varname>let</varname> expression below defines a
+       <varname>myEmacs</varname> binding pointing to the current stable
+       version of Emacs. This binding is here to separate the choice of the
+       Emacs binary from the specification of the required packages.
+      </para>
+     </callout>
+     <callout arearefs="ex-emacsNix-3">
+      <para>
+       This generates an <varname>emacsWithPackages</varname> function. It
+       takes a single argument: a function from a package set to a list of
+       packages (the packages that will be available in Emacs).
+      </para>
+     </callout>
+     <callout arearefs="ex-emacsNix-4">
+      <para>
+       The rest of the file specifies the list of packages to install. In the
+       example, two packages (<varname>magit</varname> and
+       <varname>zerodark-theme</varname>) are taken from MELPA stable.
+      </para>
+     </callout>
+     <callout arearefs="ex-emacsNix-5">
+      <para>
+       Two packages (<varname>undo-tree</varname> and
+       <varname>zoom-frm</varname>) are taken from MELPA.
+      </para>
+     </callout>
+     <callout arearefs="ex-emacsNix-6">
+      <para>
+       Three packages are taken from GNU ELPA.
+      </para>
+     </callout>
+     <callout arearefs="ex-emacsNix-7">
+      <para>
+       <varname>notmuch</varname> is taken from a nixpkgs derivation which
+       contains an Emacs mode.
+      </para>
+     </callout>
+    </calloutlist>
+   </para>
 
+   <para>
+    The result of this configuration will be an <command>emacs</command>
+    command which launches Emacs with all of your chosen packages in the
+    <varname>load-path</varname>.
+   </para>
+
+   <para>
+    You can check that it works by executing this in a terminal:
 <screen>
 $ nix-build emacs.nix
 $ ./result/bin/emacs -q
 </screen>
+    and then typing <literal>M-x package-initialize</literal>. Check that you
+    can use all the packages you want in this Emacs instance. For example, try
+    switching to the zerodark theme through <literal>M-x load-theme &lt;RET&gt;
+    zerodark &lt;RET&gt; y</literal>.
+   </para>
 
-        and then typing <literal>M-x package-initialize</literal>.
-        Check that you can use all the packages you want in this
-        Emacs instance. For example, try switching to the zerodark
-        theme through
-        <literal>M-x load-theme &lt;RET&gt; zerodark &lt;RET&gt; y</literal>.
-      </para>
+   <tip>
+    <para>
+     A few popular extensions worth checking out are: auctex, company,
+     edit-server, flycheck, helm, iedit, magit, multiple-cursors, projectile,
+     and yasnippet.
+    </para>
+   </tip>
 
-      <tip>
-        <para>
-          A few popular extensions worth checking out are: auctex,
-          company, edit-server, flycheck, helm, iedit, magit,
-          multiple-cursors, projectile, and yasnippet.
-        </para>
-      </tip>
-
-      <para>
-        The list of available packages in the various ELPA
-        repositories can be seen with the following commands:
-        <example xml:id="module-services-emacs-querying-packages">
-          <title>Querying Emacs packages</title>
-          <programlisting><![CDATA[
+   <para>
+    The list of available packages in the various ELPA repositories can be seen
+    with the following commands:
+    <example xml:id="module-services-emacs-querying-packages">
+     <title>Querying Emacs packages</title>
+<programlisting><![CDATA[
 nix-env -f "<nixpkgs>" -qaP -A emacsPackagesNg.elpaPackages
 nix-env -f "<nixpkgs>" -qaP -A emacsPackagesNg.melpaPackages
 nix-env -f "<nixpkgs>" -qaP -A emacsPackagesNg.melpaStablePackages
 nix-env -f "<nixpkgs>" -qaP -A emacsPackagesNg.orgPackages
 ]]></programlisting>
-        </example>
-      </para>
+    </example>
+   </para>
 
-      <para>
-        If you are on NixOS, you can install this particular Emacs for
-        all users by adding it to the list of system packages
-        (see <xref linkend="sec-declarative-package-mgmt" />). Simply
-        modify your file <filename>configuration.nix</filename> to
-        make it contain:
-        <example xml:id="module-services-emacs-configuration-nix">
-          <title>Custom Emacs in <filename>configuration.nix</filename></title>
-          <programlisting><![CDATA[
+   <para>
+    If you are on NixOS, you can install this particular Emacs for all users by
+    adding it to the list of system packages (see
+    <xref linkend="sec-declarative-package-mgmt" />). Simply modify your file
+    <filename>configuration.nix</filename> to make it contain:
+    <example xml:id="module-services-emacs-configuration-nix">
+     <title>Custom Emacs in <filename>configuration.nix</filename></title>
+<programlisting><![CDATA[
 {
  environment.systemPackages = [
    # [...]
@@ -301,60 +284,59 @@ nix-env -f "<nixpkgs>" -qaP -A emacsPackagesNg.orgPackages
   ];
 }
 ]]></programlisting>
-        </example>
-      </para>
+    </example>
+   </para>
 
-      <para>
-        In this case, the next <command>nixos-rebuild switch</command>
-        will take care of adding your <command>emacs</command> to the
-        <varname>PATH</varname> environment variable
-        (see <xref linkend="sec-changing-config" />).
-      </para>
+   <para>
+    In this case, the next <command>nixos-rebuild switch</command> will take
+    care of adding your <command>emacs</command> to the <varname>PATH</varname>
+    environment variable (see <xref linkend="sec-changing-config" />).
+   </para>
 
 <!-- fixme: i think the following is better done with config.nix
 https://nixos.org/nixpkgs/manual/#sec-modify-via-packageOverrides
 -->
-      <para>
-        If you are not on NixOS or want to install this particular
-        Emacs only for yourself, you can do so by adding it to your
-        <filename>~/.config/nixpkgs/config.nix</filename>
-        (see <link xlink:href="http://nixos.org/nixpkgs/manual/#sec-modify-via-packageOverrides">Nixpkgs manual</link>):
-        <example xml:id="module-services-emacs-config-nix">
-          <title>Custom Emacs in <filename>~/.config/nixpkgs/config.nix</filename></title>
-          <programlisting><![CDATA[
+
+   <para>
+    If you are not on NixOS or want to install this particular Emacs only for
+    yourself, you can do so by adding it to your
+    <filename>~/.config/nixpkgs/config.nix</filename> (see
+    <link xlink:href="http://nixos.org/nixpkgs/manual/#sec-modify-via-packageOverrides">Nixpkgs
+    manual</link>):
+    <example xml:id="module-services-emacs-config-nix">
+     <title>Custom Emacs in <filename>~/.config/nixpkgs/config.nix</filename></title>
+<programlisting><![CDATA[
 {
   packageOverrides = super: let self = super.pkgs; in {
     myemacs = import /path/to/emacs.nix { pkgs = self; };
   };
 }
 ]]></programlisting>
-        </example>
-      </para>
+    </example>
+   </para>
 
-      <para>
-        In this case, the next
-        <literal>nix-env -f '&lt;nixpkgs&gt;' -iA myemacs</literal>
-        will take care of adding your emacs to the
-        <varname>PATH</varname> environment variable.
-      </para>
-    </section>
+   <para>
+    In this case, the next <literal>nix-env -f '&lt;nixpkgs&gt;' -iA
+    myemacs</literal> will take care of adding your emacs to the
+    <varname>PATH</varname> environment variable.
+   </para>
+  </section>
 
-    <section xml:id="module-services-emacs-advanced">
-      <title>Advanced Emacs Configuration</title>
+  <section xml:id="module-services-emacs-advanced">
+   <title>Advanced Emacs Configuration</title>
 
-      <para>
-        If you want, you can tweak the Emacs package itself from your
-        <filename>emacs.nix</filename>. For example, if you want to
-        have a GTK+3-based Emacs instead of the default GTK+2-based
-        binary and remove the automatically generated
-        <filename>emacs.desktop</filename> (useful is you only use
-        <command>emacsclient</command>), you can change your file
-        <filename>emacs.nix</filename> in this way:
-      </para>
+   <para>
+    If you want, you can tweak the Emacs package itself from your
+    <filename>emacs.nix</filename>. For example, if you want to have a
+    GTK+3-based Emacs instead of the default GTK+2-based binary and remove the
+    automatically generated <filename>emacs.desktop</filename> (useful is you
+    only use <command>emacsclient</command>), you can change your file
+    <filename>emacs.nix</filename> in this way:
+   </para>
 
-      <example xml:id="ex-emacsGtk3Nix">
-        <title>Custom Emacs build</title>
-        <programlisting><![CDATA[
+   <example xml:id="ex-emacsGtk3Nix">
+    <title>Custom Emacs build</title>
+<programlisting><![CDATA[
 { pkgs ? import <nixpkgs> {} }:
 let
   myEmacs = (pkgs.emacs.override {
@@ -370,161 +352,143 @@ let
   });
 in [...]
 ]]></programlisting>
-      </example>
+   </example>
 
-      <para>
-        After building this file as shown in <xref linkend="ex-emacsNix" />,
-        you will get an GTK3-based Emacs binary pre-loaded with your
-        favorite packages.
-      </para>
-    </section>
+   <para>
+    After building this file as shown in <xref linkend="ex-emacsNix" />, you
+    will get an GTK3-based Emacs binary pre-loaded with your favorite packages.
+   </para>
   </section>
-
-<section xml:id="module-services-emacs-running">
+ </section>
+ <section xml:id="module-services-emacs-running">
   <title>Running Emacs as a Service</title>
+
   <para>
-    <productname>NixOS</productname> provides an optional
-    <command>systemd</command> service which launches
-    <link xlink:href="https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html">
-      Emacs daemon
-    </link>
-    with the user's login session.
+   <productname>NixOS</productname> provides an optional
+   <command>systemd</command> service which launches
+   <link xlink:href="https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html">
+   Emacs daemon </link> with the user's login session.
   </para>
 
   <para>
-    <emphasis>Source:</emphasis>
-    <filename>modules/services/editors/emacs.nix</filename>
+   <emphasis>Source:</emphasis>
+   <filename>modules/services/editors/emacs.nix</filename>
   </para>
 
   <section xml:id="module-services-emacs-enabling">
-    <title>Enabling the Service</title>
-
-    <para>
-      To install and enable the <command>systemd</command>
-      user service for Emacs daemon, add the following to your
-      <filename>configuration.nix</filename>:
+   <title>Enabling the Service</title>
 
+   <para>
+    To install and enable the <command>systemd</command> user service for Emacs
+    daemon, add the following to your <filename>configuration.nix</filename>:
 <programlisting>
 <xref linkend="opt-services.emacs.enable"/> = true;
 <xref linkend="opt-services.emacs.package"/> = import /home/cassou/.emacs.d { pkgs = pkgs; };
 </programlisting>
-    </para>
+   </para>
 
-    <para>
-      The <varname>services.emacs.package</varname> option allows a
-      custom derivation to be used, for example, one created by
-      <function>emacsWithPackages</function>.
-    </para>
+   <para>
+    The <varname>services.emacs.package</varname> option allows a custom
+    derivation to be used, for example, one created by
+    <function>emacsWithPackages</function>.
+   </para>
 
-    <para>
-      Ensure that the Emacs server is enabled for your user's Emacs
-      configuration, either by customizing the
-      <varname>server-mode</varname> variable, or by adding
-      <literal>(server-start)</literal> to
-      <filename>~/.emacs.d/init.el</filename>.
-    </para>
-
-    <para>
-      To start the daemon, execute the following:
+   <para>
+    Ensure that the Emacs server is enabled for your user's Emacs
+    configuration, either by customizing the <varname>server-mode</varname>
+    variable, or by adding <literal>(server-start)</literal> to
+    <filename>~/.emacs.d/init.el</filename>.
+   </para>
 
+   <para>
+    To start the daemon, execute the following:
 <screen>
 $ nixos-rebuild switch  # to activate the new configuration.nix
 $ systemctl --user daemon-reload        # to force systemd reload
 $ systemctl --user start emacs.service  # to start the Emacs daemon
 </screen>
-
-      The server should now be ready to serve Emacs clients.
-    </para>
-
+    The server should now be ready to serve Emacs clients.
+   </para>
   </section>
 
   <section xml:id="module-services-emacs-starting-client">
-    <title>Starting the client</title>
-    <para>
-      Ensure that the emacs server is enabled, either by customizing
-      the <varname>server-mode</varname> variable, or by adding
-      <literal>(server-start)</literal> to
-      <filename>~/.emacs</filename>.
-    </para>
+   <title>Starting the client</title>
 
-    <para>
-      To connect to the emacs daemon, run one of the following:
-      <programlisting><![CDATA[
+   <para>
+    Ensure that the emacs server is enabled, either by customizing the
+    <varname>server-mode</varname> variable, or by adding
+    <literal>(server-start)</literal> to <filename>~/.emacs</filename>.
+   </para>
+
+   <para>
+    To connect to the emacs daemon, run one of the following:
+<programlisting><![CDATA[
 emacsclient FILENAME
 emacsclient --create-frame  # opens a new frame (window)
 emacsclient --create-frame --tty  # opens a new frame on the current terminal
 ]]></programlisting>
-    </para>
+   </para>
   </section>
 
   <section xml:id="module-services-emacs-editor-variable">
-    <title>Configuring the <varname>EDITOR</varname> variable</title>
-    <!--<title><command>emacsclient</command> as the Default Editor</title>-->
+   <title>Configuring the <varname>EDITOR</varname> variable</title>
 
-    <para>
-      If <xref linkend="opt-services.emacs.defaultEditor"/> is
-      <literal>true</literal>, the <varname>EDITOR</varname> variable
-      will be set to a wrapper script which launches
-      <command>emacsclient</command>.
-    </para>
+<!--<title><command>emacsclient</command> as the Default Editor</title>-->
 
-    <para>
-      Any setting of <varname>EDITOR</varname> in the shell config
-      files will override
-      <varname>services.emacs.defaultEditor</varname>.
-      To make sure <varname>EDITOR</varname> refers to the Emacs
-      wrapper script, remove any existing <varname>EDITOR</varname>
-      assignment from <filename>.profile</filename>,
-      <filename>.bashrc</filename>, <filename>.zshenv</filename> or
-      any other shell config file.
-    </para>
+   <para>
+    If <xref linkend="opt-services.emacs.defaultEditor"/> is
+    <literal>true</literal>, the <varname>EDITOR</varname> variable will be set
+    to a wrapper script which launches <command>emacsclient</command>.
+   </para>
 
-    <para>
-      If you have formed certain bad habits when editing files,
-      these can be corrected with a shell alias to the wrapper
-      script:
-      <programlisting>alias vi=$EDITOR</programlisting>
-    </para>
+   <para>
+    Any setting of <varname>EDITOR</varname> in the shell config files will
+    override <varname>services.emacs.defaultEditor</varname>. To make sure
+    <varname>EDITOR</varname> refers to the Emacs wrapper script, remove any
+    existing <varname>EDITOR</varname> assignment from
+    <filename>.profile</filename>, <filename>.bashrc</filename>,
+    <filename>.zshenv</filename> or any other shell config file.
+   </para>
+
+   <para>
+    If you have formed certain bad habits when editing files, these can be
+    corrected with a shell alias to the wrapper script:
+<programlisting>alias vi=$EDITOR</programlisting>
+   </para>
   </section>
 
   <section xml:id="module-services-emacs-per-user">
-    <title>Per-User Enabling of the Service</title>
-
-    <para>
-      In general, <command>systemd</command> user services
-      are globally enabled by symlinks in
-      <filename>/etc/systemd/user</filename>. In the case where
-      Emacs daemon is not wanted for all users, it is possible to
-      install the service but not globally enable it:
+   <title>Per-User Enabling of the Service</title>
 
+   <para>
+    In general, <command>systemd</command> user services are globally enabled
+    by symlinks in <filename>/etc/systemd/user</filename>. In the case where
+    Emacs daemon is not wanted for all users, it is possible to install the
+    service but not globally enable it:
 <programlisting>
 <xref linkend="opt-services.emacs.enable"/> = false;
 <xref linkend="opt-services.emacs.install"/> = true;
 </programlisting>
-    </para>
+   </para>
 
-    <para>
-      To enable the <command>systemd</command> user service for just
-      the currently logged in user, run:
-
-      <programlisting>systemctl --user enable emacs</programlisting>
-
-      This will add the symlink
-      <filename>~/.config/systemd/user/emacs.service</filename>.
-    </para>
+   <para>
+    To enable the <command>systemd</command> user service for just the
+    currently logged in user, run:
+<programlisting>systemctl --user enable emacs</programlisting>
+    This will add the symlink
+    <filename>~/.config/systemd/user/emacs.service</filename>.
+   </para>
   </section>
-</section>
-
-<section xml:id="module-services-emacs-configuring">
+ </section>
+ <section xml:id="module-services-emacs-configuring">
   <title>Configuring Emacs</title>
 
   <para>
-    The Emacs init file should be changed to load the extension
-    packages at startup:
-
-    <example xml:id="module-services-emacs-package-initialisation">
-      <title>Package initialization in <filename>.emacs</filename></title>
-      <programlisting><![CDATA[
+   The Emacs init file should be changed to load the extension packages at
+   startup:
+   <example xml:id="module-services-emacs-package-initialisation">
+    <title>Package initialization in <filename>.emacs</filename></title>
+<programlisting><![CDATA[
 (require 'package)
 
 ;; optional. makes unpure packages archives unavailable
@@ -533,66 +497,71 @@ emacsclient --create-frame --tty  # opens a new frame on the current terminal
 (setq package-enable-at-startup nil)
 (package-initialize)
 ]]></programlisting>
-    </example>
+   </example>
   </para>
 
   <para>
-    After the declarative emacs package configuration has been
-    tested, previously downloaded packages can be cleaned up by
-    removing <filename>~/.emacs.d/elpa</filename> (do make a backup
-    first, in case you forgot a package).
+   After the declarative emacs package configuration has been tested,
+   previously downloaded packages can be cleaned up by removing
+   <filename>~/.emacs.d/elpa</filename> (do make a backup first, in case you
+   forgot a package).
   </para>
 
-  <!--
+<!--
       todo: is it worth documenting customizations for
       server-switch-hook, server-done-hook?
   -->
 
   <section xml:id="module-services-emacs-major-mode">
-    <title>A Major Mode for Nix Expressions</title>
+   <title>A Major Mode for Nix Expressions</title>
 
-    <para>
-      Of interest may be <varname>melpaPackages.nix-mode</varname>,
-      which provides syntax highlighting for the Nix language. This is
-      particularly convenient if you regularly edit Nix files.
-    </para>
+   <para>
+    Of interest may be <varname>melpaPackages.nix-mode</varname>, which
+    provides syntax highlighting for the Nix language. This is particularly
+    convenient if you regularly edit Nix files.
+   </para>
   </section>
 
   <section xml:id="module-services-emacs-man-pages">
-    <title>Accessing man pages</title>
-    <para>
-      You can use <function>woman</function> to get completion of all
-      available man pages. For example, type <literal>M-x woman
-      &lt;RET&gt; nixos-rebuild &lt;RET&gt;.</literal>
-    </para>
+   <title>Accessing man pages</title>
+
+   <para>
+    You can use <function>woman</function> to get completion of all available
+    man pages. For example, type <literal>M-x woman &lt;RET&gt; nixos-rebuild
+    &lt;RET&gt;.</literal>
+   </para>
   </section>
 
   <section xml:id="sec-emacs-docbook-xml">
-    <title>Editing DocBook 5 XML Documents</title>
-    <para>
-      Emacs includes <link
+   <title>Editing DocBook 5 XML Documents</title>
+
+   <para>
+    Emacs includes
+    <link
       xlink:href="https://www.gnu.org/software/emacs/manual/html_node/nxml-mode/Introduction.html">nXML</link>,
-      a major-mode for validating and editing XML documents.
-      When editing DocBook 5.0 documents, such as
-      <link linkend="book-nixos-manual">this one</link>,
-      nXML needs to be configured with the relevant schema, which is
-      not included.
-    </para>
+    a major-mode for validating and editing XML documents. When editing DocBook
+    5.0 documents, such as <link linkend="book-nixos-manual">this one</link>,
+    nXML needs to be configured with the relevant schema, which is not
+    included.
+   </para>
 
-    <para>
-      To install the DocBook 5.0 schemas, either add
-      <varname>pkgs.docbook5</varname> to
-      <xref linkend="opt-environment.systemPackages"/> (<link
+   <para>
+    To install the DocBook 5.0 schemas, either add
+    <varname>pkgs.docbook5</varname> to
+    <xref linkend="opt-environment.systemPackages"/>
+    (<link
       linkend="sec-declarative-package-mgmt">NixOS</link>), or run
-      <literal>nix-env -i pkgs.docbook5</literal>
-      (<link linkend="sec-ad-hoc-packages">Nix</link>).
-    </para>
+    <literal>nix-env -i pkgs.docbook5</literal>
+    (<link linkend="sec-ad-hoc-packages">Nix</link>).
+   </para>
 
-    <para>
-      Then customize the variable <varname>rng-schema-locating-files</varname> to include <filename>~/.emacs.d/schemas.xml</filename> and put the following text into that file:
-      <example xml:id="ex-emacs-docbook-xml">
-        <title>nXML Schema Configuration (<filename>~/.emacs.d/schemas.xml</filename>)</title>
-        <programlisting language="xml"><![CDATA[
+   <para>
+    Then customize the variable <varname>rng-schema-locating-files</varname> to
+    include <filename>~/.emacs.d/schemas.xml</filename> and put the following
+    text into that file:
+    <example xml:id="ex-emacs-docbook-xml">
+     <title>nXML Schema Configuration (<filename>~/.emacs.d/schemas.xml</filename>)</title>
+<programlisting language="xml"><![CDATA[
 <?xml version="1.0"?>
 <!--
   To let emacs find this file, evaluate:
@@ -612,9 +581,7 @@ emacsclient --create-frame --tty  # opens a new frame on the current terminal
 </locatingRules>
 ]]></programlisting>
     </example>
-  </para>
-
+   </para>
   </section>
-</section>
-
+ </section>
 </chapter>

nixos/modules/services/hardware/trezord.nix

@@ -26,15 +26,14 @@ in {
       name = "trezord-udev-rules";
       destination = "/etc/udev/rules.d/51-trezor.rules";
       text = ''
-        # Trezor 1
-        SUBSYSTEM=="usb",  ATTR{idVendor}=="534c",  ATTR{idProduct}=="0001",  MODE="0666", GROUP="dialout", SYMLINK+="trezor%n"
-        KERNEL=="hidraw*", ATTRS{idVendor}=="534c", ATTRS{idProduct}=="0001", MODE="0666", GROUP="dialout"
+        # TREZOR v1 (One)
+        SUBSYSTEM=="usb", ATTR{idVendor}=="534c", ATTR{idProduct}=="0001", MODE="0666", GROUP="dialout", TAG+="uaccess", TAG+="udev-acl", SYMLINK+="trezor%n"
+        KERNEL=="hidraw*", ATTRS{idVendor}=="534c", ATTRS{idProduct}=="0001",  MODE="0666", GROUP="dialout", TAG+="uaccess", TAG+="udev-acl"
 
-        # Trezor 2 (Model-T)
-        SUBSYSTEM=="usb",  ATTR{idVendor}=="1209",  ATTR{idProduct}=="53c0",  MODE="0661", GROUP="dialout", TAG+="uaccess", TAG+="udev-acl", SYMLINK+="trezor%n"
-        SUBSYSTEM=="usb",  ATTR{idVendor}=="1209",  ATTR{idProduct}=="53c1",  MODE="0660", GROUP="dialout", TAG+="uaccess", TAG+="udev-acl", SYMLINK+="trezor%n"
-        KERNEL=="hidraw*", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="53c1", MODE="0660", GROUP="dialout", TAG+="uaccess", TAG+="udev-acl"
-  ];
+        # TREZOR v2 (T)
+        SUBSYSTEM=="usb", ATTR{idVendor}=="1209", ATTR{idProduct}=="53c0", MODE="0661", GROUP="dialout", TAG+="uaccess", TAG+="udev-acl", SYMLINK+="trezor%n"
+        SUBSYSTEM=="usb", ATTR{idVendor}=="1209", ATTR{idProduct}=="53c1", MODE="0666", GROUP="dialout", TAG+="uaccess", TAG+="udev-acl", SYMLINK+="trezor%n"
+        KERNEL=="hidraw*", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="53c1", MODE="0666", GROUP="dialout", TAG+="uaccess", TAG+="udev-acl"
       '';
     });
 

nixos/modules/services/mail/exim.nix

@@ -2,7 +2,7 @@
 
 let
   inherit (lib) mkIf mkOption singleton types;
-  inherit (pkgs) coreutils exim;
+  inherit (pkgs) coreutils;
   cfg = config.services.exim;
 in
 
@@ -57,6 +57,16 @@ in
         '';
       };
 
+      package = mkOption {
+        type = types.package;
+        default = pkgs.exim;
+        defaultText = "pkgs.exim";
+        description = ''
+          The Exim derivation to use.
+          This can be used to enable features such as LDAP or PAM support.
+        '';
+      };
+
     };
 
   };
@@ -74,7 +84,7 @@ in
         spool_directory = ${cfg.spoolDir}
         ${cfg.config}
       '';
-      systemPackages = [ exim ];
+      systemPackages = [ cfg.package ];
     };
 
     users.users = singleton {
@@ -89,14 +99,14 @@ in
       gid = config.ids.gids.exim;
     };
 
-    security.wrappers.exim.source = "${exim}/bin/exim";
+    security.wrappers.exim.source = "${cfg.package}/bin/exim";
 
     systemd.services.exim = {
       description = "Exim Mail Daemon";
       wantedBy = [ "multi-user.target" ];
       restartTriggers = [ config.environment.etc."exim.conf".source ];
       serviceConfig = {
-        ExecStart   = "${exim}/bin/exim -bdf -q30m";
+        ExecStart   = "${cfg.package}/bin/exim -bdf -q30m";
         ExecReload  = "${coreutils}/bin/kill -HUP $MAINPID";
       };
       preStart = ''

nixos/modules/services/mail/rmilter.nix

@@ -89,7 +89,7 @@ in
 
       bindSocket.path = mkOption {
        type = types.str;
-       default = "/run/rmilter/rmilter.sock";
+       default = "/run/rmilter.sock";
        description = ''
           Path to Unix domain socket to listen on.
         '';
@@ -193,6 +193,9 @@ in
   config = mkMerge [
 
     (mkIf cfg.enable {
+      warnings = [
+        ''`config.services.rmilter' is deprecated, `rmilter' deprecated and unsupported by upstream, and will be removed from next releases. Use built-in rspamd milter instead.''
+      ];
 
       users.users = singleton {
         name = cfg.user;

nixos/modules/services/mail/rspamd.nix

@@ -115,36 +115,10 @@ let
     };
   };
 
-  indexOf = default: start: list: e:
-    if list == []
-    then default
-    else if (head list) == e then start
-    else (indexOf default (start + (length (listenStreams (head list).socket))) (tail list) e);
-
-  systemdSocket = indexOf (abort "Socket not found") 0 allSockets;
-
   isUnixSocket = socket: hasPrefix "/" (if (isString socket) then socket else socket.socket);
-  isPort = hasPrefix "*:";
-  isIPv4Socket = hasPrefix "*v4:";
-  isIPv6Socket = hasPrefix "*v6:";
-  isLocalHost = hasPrefix "localhost:";
-  listenStreams = socket:
-    if (isLocalHost socket) then
-      let port = (removePrefix "localhost:" socket);
-      in [ "127.0.0.1:${port}" ] ++ (if config.networking.enableIPv6 then ["[::1]:${port}"] else [])
-    else if (isIPv6Socket socket) then [removePrefix "*v6:" socket]
-    else if (isPort socket) then [removePrefix "*:" socket]
-    else if (isIPv4Socket socket) then
-      throw "error: IPv4 only socket not supported in rspamd with socket activation"
-    else if (length (splitString " " socket)) != 1 then
-      throw "error: string options not supported in rspamd with socket activation"
-    else [socket];
 
-  mkBindSockets = enabled: socks: concatStringsSep "\n  " (flatten (map (each:
-    if cfg.socketActivation && enabled != false then
-      let systemd = (systemdSocket each);
-      in (imap (idx: e: "bind_socket = \"systemd:${toString (systemd + idx - 1)}\";") (listenStreams each.socket))
-    else "bind_socket = \"${each.rawEntry}\";") socks));
+  mkBindSockets = enabled: socks: concatStringsSep "\n  "
+    (flatten (map (each: "bind_socket = \"${each.rawEntry}\";") socks));
 
   rspamdConfFile = pkgs.writeText "rspamd.conf"
     ''
@@ -175,18 +149,6 @@ let
       ${cfg.extraConfig}
    '';
 
-  allMappedSockets = flatten (mapAttrsToList (name: value:
-    if value.enable != false
-    then imap (idx: each: {
-        name = "${name}";
-        index = idx;
-        value = each;
-      }) value.bindSockets
-    else []) cfg.workers);
-  allSockets = map (e: e.value) allMappedSockets;
-
-  allSocketNames = map (each: "rspamd-${each.name}-${toString each.index}.socket") allMappedSockets;
-
 in
 
 {
@@ -205,13 +167,6 @@ in
         description = "Whether to run the rspamd daemon in debug mode.";
       };
 
-      socketActivation = mkOption {
-        type = types.bool;
-        description = ''
-          Enable systemd socket activation for rspamd.
-        '';
-      };
-
       workers = mkOption {
         type = with types; attrsOf (submodule workerOpts);
         description = ''
@@ -272,13 +227,6 @@ in
 
   config = mkIf cfg.enable {
 
-    services.rspamd.socketActivation = mkDefault (!opts.bindSocket.isDefined && !opts.bindUISocket.isDefined);
-
-    assertions = [ {
-      assertion = !cfg.socketActivation || !(opts.bindSocket.isDefined || opts.bindUISocket.isDefined);
-      message = "Can't use socketActivation for rspamd when using renamed bind socket options";
-    } ];
-
     # Allow users to run 'rspamc' and 'rspamadm'.
     environment.systemPackages = [ pkgs.rspamd ];
 
@@ -299,17 +247,14 @@ in
     systemd.services.rspamd = {
       description = "Rspamd Service";
 
-      wantedBy = mkIf (!cfg.socketActivation) [ "multi-user.target" ];
-      after = [ "network.target" ] ++
-       (if cfg.socketActivation then allSocketNames else []);
-      requires = mkIf cfg.socketActivation allSocketNames;
+      wantedBy = [ "multi-user.target" ];
+      after = [ "network.target" ];
 
       serviceConfig = {
         ExecStart = "${pkgs.rspamd}/bin/rspamd ${optionalString cfg.debug "-d"} --user=${cfg.user} --group=${cfg.group} --pid=/run/rspamd.pid -c ${rspamdConfFile} -f";
         Restart = "always";
         RuntimeDirectory = "rspamd";
         PrivateTmp = true;
-        Sockets = mkIf cfg.socketActivation (concatStringsSep " " allSocketNames);
       };
 
       preStart = ''
@@ -317,24 +262,10 @@ in
         ${pkgs.coreutils}/bin/chown ${cfg.user}:${cfg.group} /var/lib/rspamd
       '';
     };
-    systemd.sockets = mkIf cfg.socketActivation
-      (listToAttrs (map (each: {
-        name = "rspamd-${each.name}-${toString each.index}";
-        value = {
-          description = "Rspamd socket ${toString each.index} for worker ${each.name}";
-          wantedBy = [ "sockets.target" ];
-          listenStreams = (listenStreams each.value.socket);
-          socketConfig = {
-            BindIPv6Only = mkIf (isIPv6Socket each.value.socket) "ipv6-only";
-            Service = "rspamd.service";
-            SocketUser = mkIf (isUnixSocket each.value.socket) each.value.owner;
-            SocketGroup = mkIf (isUnixSocket each.value.socket) each.value.group;
-            SocketMode = mkIf (isUnixSocket each.value.socket) each.value.mode;
-          };
-        };
-      }) allMappedSockets));
   };
   imports = [
+    (mkRemovedOptionModule [ "services" "rspamd" "socketActivation" ]
+	     "Socket activation never worked correctly and could at this time not be fixed and so was removed")
     (mkRenamedOptionModule [ "services" "rspamd" "bindSocket" ] [ "services" "rspamd" "workers" "normal" "bindSockets" ])
     (mkRenamedOptionModule [ "services" "rspamd" "bindUISocket" ] [ "services" "rspamd" "workers" "controller" "bindSockets" ])
   ];

nixos/modules/services/misc/gitlab.nix

@@ -162,7 +162,7 @@ let
       makeWrapper ${cfg.packages.gitlab.rubyEnv}/bin/rake $out/bin/gitlab-rake \
           ${concatStrings (mapAttrsToList (name: value: "--set ${name} '${value}' ") gitlabEnv)} \
           --set GITLAB_CONFIG_PATH '${cfg.statePath}/config' \
-          --set PATH '${lib.makeBinPath [ pkgs.nodejs pkgs.gzip pkgs.git pkgs.gnutar config.services.postgresql.package ]}:$PATH' \
+          --set PATH '${lib.makeBinPath [ pkgs.nodejs pkgs.gzip pkgs.git pkgs.gnutar config.services.postgresql.package pkgs.coreutils pkgs.procps ]}:$PATH' \
           --set RAKEOPT '-f ${cfg.packages.gitlab}/share/gitlab/Rakefile' \
           --run 'cd ${cfg.packages.gitlab}/share/gitlab'
      '';
@@ -203,6 +203,7 @@ in {
         default = pkgs.gitlab;
         defaultText = "pkgs.gitlab";
         description = "Reference to the gitlab package";
+        example = "pkgs.gitlab-ee";
       };
 
       packages.gitlab-shell = mkOption {
@@ -501,7 +502,7 @@ in {
     };
 
     systemd.services.gitlab-workhorse = {
-      after = [ "network.target" "gitlab.service" ];
+      after = [ "network.target" ];
       wantedBy = [ "multi-user.target" ];
       environment.HOME = gitlabEnv.HOME;
       environment.GITLAB_SHELL_CONFIG_PATH = gitlabEnv.GITLAB_SHELL_CONFIG_PATH;
@@ -569,9 +570,9 @@ in {
 
         mkdir -p /run/gitlab
         mkdir -p ${cfg.statePath}/log
-        ln -sf ${cfg.statePath}/log /run/gitlab/log
-        ln -sf ${cfg.statePath}/tmp /run/gitlab/tmp
-        ln -sf ${cfg.statePath}/uploads /run/gitlab/uploads
+        [ -d /run/gitlab/log ] || ln -sf ${cfg.statePath}/log /run/gitlab/log
+        [ -d /run/gitlab/tmp ] || ln -sf ${cfg.statePath}/tmp /run/gitlab/tmp
+        [ -d /run/gitlab/uploads ] || ln -sf ${cfg.statePath}/uploads /run/gitlab/uploads
         ln -sf $GITLAB_SHELL_CONFIG_PATH /run/gitlab/shell-config.yml
         chown -R ${cfg.user}:${cfg.group} /run/gitlab
 
@@ -629,6 +630,10 @@ in {
           touch "${cfg.statePath}/db-seeded"
         fi
 
+        # The gitlab:shell:setup regenerates the authorized_keys file so that
+        # the store path to the gitlab-shell in it gets updated
+        ${pkgs.sudo}/bin/sudo -u ${cfg.user} force=yes ${gitlab-rake}/bin/gitlab-rake gitlab:shell:setup RAILS_ENV=production
+
         # The gitlab:shell:create_hooks task seems broken for fixing links
         # so we instead delete all the hooks and create them anew
         rm -f ${cfg.statePath}/repositories/**/*.git/hooks

nixos/modules/services/misc/gitlab.xml

@@ -3,20 +3,22 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="module-services-gitlab">
+ <title>Gitlab</title>
+ <para>
+  Gitlab is a feature-rich git hosting service.
+ </para>
+ <section xml:id="module-services-gitlab-prerequisites">
+  <title>Prerequisites</title>
 
-<title>Gitlab</title>
-
-<para>Gitlab is a feature-rich git hosting service.</para>
-
-<section xml:id="module-services-gitlab-prerequisites"><title>Prerequisites</title>
-
-<para>The gitlab service exposes only an Unix socket at
-<literal>/run/gitlab/gitlab-workhorse.socket</literal>. You need to configure a
-webserver to proxy HTTP requests to the socket.</para>
-
-<para>For instance, the following configuration could be used to use nginx as
-    frontend proxy:
+  <para>
+   The gitlab service exposes only an Unix socket at
+   <literal>/run/gitlab/gitlab-workhorse.socket</literal>. You need to
+   configure a webserver to proxy HTTP requests to the socket.
+  </para>
 
+  <para>
+   For instance, the following configuration could be used to use nginx as
+   frontend proxy:
 <programlisting>
 <link linkend="opt-services.nginx.enable">services.nginx</link> = {
   <link linkend="opt-services.nginx.enable">enable</link> = true;
@@ -31,21 +33,24 @@ webserver to proxy HTTP requests to the socket.</para>
   };
 };
 </programlisting>
-</para>
+  </para>
+ </section>
+ <section xml:id="module-services-gitlab-configuring">
+  <title>Configuring</title>
 
-</section>
+  <para>
+   Gitlab depends on both PostgreSQL and Redis and will automatically enable
+   both services. In the case of PostgreSQL, a database and a role will be
+   created.
+  </para>
 
-<section xml:id="module-services-gitlab-configuring"><title>Configuring</title>
-
-<para>Gitlab depends on both PostgreSQL and Redis and will automatically enable
-both services. In the case of PostgreSQL, a database and a role will be created.
-</para>
-
-<para>The default state dir is <literal>/var/gitlab/state</literal>. This is where
-all data like the repositories and uploads will be stored.</para>
-
-<para>A basic configuration with some custom settings could look like this:
+  <para>
+   The default state dir is <literal>/var/gitlab/state</literal>. This is where
+   all data like the repositories and uploads will be stored.
+  </para>
 
+  <para>
+   A basic configuration with some custom settings could look like this:
 <programlisting>
 services.gitlab = {
   <link linkend="opt-services.gitlab.enable">enable</link> = true;
@@ -105,40 +110,41 @@ services.gitlab = {
   };
 };
 </programlisting>
-</para>
+  </para>
 
-<para>If you're setting up a new Gitlab instance, generate new secrets. You
-for instance use <literal>tr -dc A-Za-z0-9 &lt; /dev/urandom | head -c 128</literal>
-to generate a new secret. Gitlab encrypts sensitive data stored in the database.
-If you're restoring an existing Gitlab instance, you must specify the secrets
-secret from <literal>config/secrets.yml</literal> located in your Gitlab state
-folder.</para>
+  <para>
+   If you're setting up a new Gitlab instance, generate new secrets. You for
+   instance use <literal>tr -dc A-Za-z0-9 &lt; /dev/urandom | head -c
+   128</literal> to generate a new secret. Gitlab encrypts sensitive data
+   stored in the database. If you're restoring an existing Gitlab instance, you
+   must specify the secrets secret from <literal>config/secrets.yml</literal>
+   located in your Gitlab state folder.
+  </para>
 
-<para>Refer to <xref linkend="ch-options" /> for all available configuration
-options for the <link linkend="opt-services.gitlab.enable">services.gitlab</link> module.</para>
+  <para>
+   Refer to <xref linkend="ch-options" /> for all available configuration
+   options for the
+   <link linkend="opt-services.gitlab.enable">services.gitlab</link> module.
+  </para>
+ </section>
+ <section xml:id="module-services-gitlab-maintenance">
+  <title>Maintenance</title>
 
-</section>
-
-<section xml:id="module-services-gitlab-maintenance"><title>Maintenance</title>
-
-<para>You can run Gitlab's rake tasks with <literal>gitlab-rake</literal>
-which will be available on the system when gitlab is enabled. You will
-have to run the command as the user that you configured to run gitlab
-with.</para>
-
-<para>For example, to backup a Gitlab instance:
+  <para>
+   You can run Gitlab's rake tasks with <literal>gitlab-rake</literal> which
+   will be available on the system when gitlab is enabled. You will have to run
+   the command as the user that you configured to run gitlab with.
+  </para>
 
+  <para>
+   For example, to backup a Gitlab instance:
 <programlisting>
 $ sudo -u git -H gitlab-rake gitlab:backup:create
 </programlisting>
-
-A list of all availabe rake tasks can be obtained by running:
-
+   A list of all availabe rake tasks can be obtained by running:
 <programlisting>
 $ sudo -u git -H gitlab-rake -T
 </programlisting>
-</para>
-
-</section>
-
+  </para>
+ </section>
 </chapter>

nixos/modules/services/misc/nix-daemon.nix

@@ -345,7 +345,6 @@ in
         type = types.listOf types.str;
         default =
           [
-            "$HOME/.nix-defexpr/channels"
             "nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos"
             "nixos-config=/etc/nixos/configuration.nix"
             "/nix/var/nix/profiles/per-user/root/channels"
@@ -436,7 +435,7 @@ in
 
     # Set up the environment variables for running Nix.
     environment.sessionVariables = cfg.envVars //
-      { NIX_PATH = concatStringsSep ":" cfg.nixPath;
+      { NIX_PATH = cfg.nixPath;
       };
 
     environment.extraInit = optionalString (!isNix20)
@@ -446,6 +445,10 @@ in
         if [ "$USER" != root -o ! -w /nix/var/nix/db ]; then
             export NIX_REMOTE=daemon
         fi
+      '' + ''
+        if [ -e "$HOME/.nix-defexpr/channels" ]; then
+          export NIX_PATH="$HOME/.nix-defexpr/channels''${NIX_PATH:+:$NIX_PATH}"
+        fi
       '';
 
     nix.nrBuildUsers = mkDefault (lib.max 32 cfg.maxJobs);

nixos/modules/services/misc/taskserver/doc.xml

@@ -2,101 +2,93 @@
     xmlns:xlink="http://www.w3.org/1999/xlink"
     version="5.0"
     xml:id="module-taskserver">
-
-  <title>Taskserver</title>
+ <title>Taskserver</title>
+ <para>
+  Taskserver is the server component of
+  <link xlink:href="https://taskwarrior.org/">Taskwarrior</link>, a free and
+  open source todo list application.
+ </para>
+ <para>
+  <emphasis>Upstream documentation:</emphasis>
+  <link xlink:href="https://taskwarrior.org/docs/#taskd"/>
+ </para>
+ <section xml:id="module-services-taskserver-configuration">
+  <title>Configuration</title>
 
   <para>
-    Taskserver is the server component of
-    <link xlink:href="https://taskwarrior.org/">Taskwarrior</link>, a free and
-    open source todo list application.
+   Taskserver does all of its authentication via TLS using client certificates,
+   so you either need to roll your own CA or purchase a certificate from a
+   known CA, which allows creation of client certificates. These certificates
+   are usually advertised as <quote>server certificates</quote>.
   </para>
 
   <para>
-    <emphasis>Upstream documentation:</emphasis>
-    <link xlink:href="https://taskwarrior.org/docs/#taskd"/>
+   So in order to make it easier to handle your own CA, there is a helper tool
+   called <command>nixos-taskserver</command> which manages the custom CA along
+   with Taskserver organisations, users and groups.
   </para>
 
-  <section xml:id="module-services-taskserver-configuration">
-    <title>Configuration</title>
+  <para>
+   While the client certificates in Taskserver only authenticate whether a user
+   is allowed to connect, every user has its own UUID which identifies it as an
+   entity.
+  </para>
 
-    <para>
-      Taskserver does all of its authentication via TLS using client
-      certificates, so you either need to roll your own CA or purchase a
-      certificate from a known CA, which allows creation of client
-      certificates.
+  <para>
+   With <command>nixos-taskserver</command> the client certificate is created
+   along with the UUID of the user, so it handles all of the credentials needed
+   in order to setup the Taskwarrior client to work with a Taskserver.
+  </para>
+ </section>
+ <section xml:id="module-services-taskserver-nixos-taskserver-tool">
+  <title>The nixos-taskserver tool</title>
 
-      These certificates are usually advertised as
-      <quote>server certificates</quote>.
-    </para>
+  <para>
+   Because Taskserver by default only provides scripts to setup users
+   imperatively, the <command>nixos-taskserver</command> tool is used for
+   addition and deletion of organisations along with users and groups defined
+   by <xref linkend="opt-services.taskserver.organisations"/> and as well for
+   imperative set up.
+  </para>
 
-    <para>
-      So in order to make it easier to handle your own CA, there is a helper
-      tool called <command>nixos-taskserver</command> which manages the custom
-      CA along with Taskserver organisations, users and groups.
-    </para>
+  <para>
+   The tool is designed to not interfere if the command is used to manually set
+   up some organisations, users or groups.
+  </para>
 
-    <para>
-      While the client certificates in Taskserver only authenticate whether a
-      user is allowed to connect, every user has its own UUID which identifies
-      it as an entity.
-    </para>
+  <para>
+   For example if you add a new organisation using <command>nixos-taskserver
+   org add foo</command>, the organisation is not modified and deleted no
+   matter what you define in
+   <option>services.taskserver.organisations</option>, even if you're adding
+   the same organisation in that option.
+  </para>
 
-    <para>
-      With <command>nixos-taskserver</command> the client certificate is created
-      along with the UUID of the user, so it handles all of the credentials
-      needed in order to setup the Taskwarrior client to work with a Taskserver.
-    </para>
-  </section>
+  <para>
+   The tool is modelled to imitate the official <command>taskd</command>
+   command, documentation for each subcommand can be shown by using the
+   <option>--help</option> switch.
+  </para>
+ </section>
+ <section xml:id="module-services-taskserver-declarative-ca-management">
+  <title>Declarative/automatic CA management</title>
 
-  <section xml:id="module-services-taskserver-nixos-taskserver-tool">
-    <title>The nixos-taskserver tool</title>
+  <para>
+   Everything is done according to what you specify in the module options,
+   however in order to set up a Taskwarrior client for synchronisation with a
+   Taskserver instance, you have to transfer the keys and certificates to the
+   client machine.
+  </para>
 
-    <para>
-      Because Taskserver by default only provides scripts to setup users
-      imperatively, the <command>nixos-taskserver</command> tool is used for
-      addition and deletion of organisations along with users and groups defined
-      by <xref linkend="opt-services.taskserver.organisations"/> and as well for
-      imperative set up.
-    </para>
+  <para>
+   This is done using <command>nixos-taskserver user export $orgname
+   $username</command> which is printing a shell script fragment to stdout
+   which can either be used verbatim or adjusted to import the user on the
+   client machine.
+  </para>
 
-    <para>
-      The tool is designed to not interfere if the command is used to manually
-      set up some organisations, users or groups.
-    </para>
-
-    <para>
-      For example if you add a new organisation using
-      <command>nixos-taskserver org add foo</command>, the organisation is not
-      modified and deleted no matter what you define in
-      <option>services.taskserver.organisations</option>, even if you're adding
-      the same organisation in that option.
-    </para>
-
-    <para>
-      The tool is modelled to imitate the official <command>taskd</command>
-      command, documentation for each subcommand can be shown by using the
-      <option>--help</option> switch.
-    </para>
-  </section>
-  <section xml:id="module-services-taskserver-declarative-ca-management">
-    <title>Declarative/automatic CA management</title>
-
-    <para>
-      Everything is done according to what you specify in the module options,
-      however in order to set up a Taskwarrior client for synchronisation with a
-      Taskserver instance, you have to transfer the keys and certificates to the
-      client machine.
-    </para>
-
-    <para>
-      This is done using
-      <command>nixos-taskserver user export $orgname $username</command> which
-      is printing a shell script fragment to stdout which can either be used
-      verbatim or adjusted to import the user on the client machine.
-    </para>
-
-    <para>
-      For example, let's say you have the following configuration:
+  <para>
+   For example, let's say you have the following configuration:
 <screen>
 {
   <xref linkend="opt-services.taskserver.enable"/> = true;
@@ -105,40 +97,39 @@
   <link linkend="opt-services.taskserver.organisations._name_.users">services.taskserver.organisations.my-company.users</link> = [ "alice" ];
 }
 </screen>
-      This creates an organisation called <literal>my-company</literal> with the
-      user <literal>alice</literal>.
-    </para>
+   This creates an organisation called <literal>my-company</literal> with the
+   user <literal>alice</literal>.
+  </para>
 
-    <para>
-      Now in order to import the <literal>alice</literal> user to another
-      machine <literal>alicebox</literal>, all we need to do is something like
-      this:
+  <para>
+   Now in order to import the <literal>alice</literal> user to another machine
+   <literal>alicebox</literal>, all we need to do is something like this:
 <screen>
 $ ssh server nixos-taskserver user export my-company alice | sh
 </screen>
-      Of course, if no SSH daemon is available on the server you can also copy
-      &amp; paste it directly into a shell.
-    </para>
+   Of course, if no SSH daemon is available on the server you can also copy
+   &amp; paste it directly into a shell.
+  </para>
 
-    <para>
-      After this step the user should be set up and you can start synchronising
-      your tasks for the first time with <command>task sync init</command> on
-      <literal>alicebox</literal>.
-    </para>
+  <para>
+   After this step the user should be set up and you can start synchronising
+   your tasks for the first time with <command>task sync init</command> on
+   <literal>alicebox</literal>.
+  </para>
 
-    <para>
-      Subsequent synchronisation requests merely require the command
-      <command>task sync</command> after that stage.
-    </para>
-  </section>
-  <section xml:id="module-services-taskserver-manual-ca-management">
-    <title>Manual CA management</title>
+  <para>
+   Subsequent synchronisation requests merely require the command <command>task
+   sync</command> after that stage.
+  </para>
+ </section>
+ <section xml:id="module-services-taskserver-manual-ca-management">
+  <title>Manual CA management</title>
 
-    <para>
-      If you set any options within
-      <link linkend="opt-services.taskserver.pki.manual.ca.cert">service.taskserver.pki.manual</link>.*,
-      <command>nixos-taskserver</command> won't issue certificates, but you can
-      still use it for adding or removing user accounts.
-    </para>
-  </section>
+  <para>
+   If you set any options within
+   <link linkend="opt-services.taskserver.pki.manual.ca.cert">service.taskserver.pki.manual</link>.*,
+   <command>nixos-taskserver</command> won't issue certificates, but you can
+   still use it for adding or removing user accounts.
+  </para>
+ </section>
 </chapter>

nixos/modules/services/misc/weechat.nix

@@ -0,0 +1,56 @@
+{ config, lib, pkgs, ... }:
+
+with lib;
+
+let
+  cfg = config.services.weechat;
+in
+
+{
+  options.services.weechat = {
+    enable = mkEnableOption "weechat";
+    root = mkOption {
+      description = "Weechat state directory.";
+      type = types.str;
+      default = "/var/lib/weechat";
+    };
+    sessionName = mkOption {
+      description = "Name of the `screen' session for weechat.";
+      default = "weechat-screen";
+      type = types.str;
+    };
+    binary = mkOption {
+      description = "Binary to execute (by default \${weechat}/bin/weechat).";
+      example = literalExample ''
+        ''${pkgs.weechat}/bin/weechat-headless
+      '';
+      default = "${pkgs.weechat}/bin/weechat";
+    };
+  };
+
+  config = mkIf cfg.enable {
+    users = {
+      groups.weechat = {};
+      users.weechat = {
+        createHome = true;
+        group = "weechat";
+        home = cfg.root;
+        isSystemUser = true;
+      };
+    };
+
+    systemd.services.weechat = {
+      environment.WEECHAT_HOME = cfg.root;
+      serviceConfig = {
+        User = "weechat";
+        Group = "weechat";
+        RemainAfterExit = "yes";
+      };
+      script = "exec ${pkgs.screen}/bin/screen -Dm -S ${cfg.sessionName} ${cfg.binary}";
+      wantedBy = [ "multi-user.target" ];
+      wants = [ "network.target" ];
+    };
+  };
+
+  meta.doc = ./weechat.xml;
+}

nixos/modules/services/misc/weechat.xml

@@ -0,0 +1,66 @@
+<chapter xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xmlns:xi="http://www.w3.org/2001/XInclude"
+         version="5.0"
+         xml:id="module-services-weechat">
+ <title>WeeChat</title>
+ <para>
+  <link xlink:href="https://weechat.org/">WeeChat</link> is a fast and
+  extensible IRC client.
+ </para>
+ <section>
+  <title>Basic Usage</title>
+
+  <para>
+   By default, the module creates a
+   <literal><link xlink:href="https://www.freedesktop.org/wiki/Software/systemd/">systemd</link></literal>
+   unit which runs the chat client in a detached
+   <literal><link xlink:href="https://www.gnu.org/software/screen/">screen</link></literal>
+   session.
+  </para>
+
+  <para>
+   This can be done by enabling the <literal>weechat</literal> service:
+<programlisting>
+{ ... }:
+
+{
+  <link linkend="opt-services.weechat.enable">services.weechat.enable</link> = true;
+}
+</programlisting>
+  </para>
+
+  <para>
+   The service is managed by a dedicated user named <literal>weechat</literal>
+   in the state directory <literal>/var/lib/weechat</literal>.
+  </para>
+ </section>
+ <section>
+  <title>Re-attaching to WeeChat</title>
+
+  <para>
+   WeeChat runs in a screen session owned by a dedicated user. To explicitly
+   allow your another user to attach to this session, the
+   <literal>screenrc</literal> needs to be tweaked by adding
+   <link xlink:href="https://www.gnu.org/software/screen/manual/html_node/Multiuser.html#Multiuser">multiuser</link>
+   support:
+<programlisting>
+{
+  <link linkend="opt-programs.screen.screenrc">programs.screen.screenrc</link> = ''
+    multiuser on
+    acladd normal_user
+  '';
+}
+</programlisting>
+   Now, the session can be re-attached like this:
+<programlisting>
+screen -r weechat-screen
+</programlisting>
+  </para>
+
+  <para>
+   <emphasis>The session name can be changed using
+   <link linkend="opt-services.weechat.sessionName">services.weechat.sessionName.</link></emphasis>
+  </para>
+ </section>
+</chapter>

nixos/modules/services/monitoring/datadog-agent.nix

@@ -8,7 +8,6 @@ let
   ddConf = {
     dd_url              = "https://app.datadoghq.com";
     skip_ssl_validation = "no";
-    api_key             = "";
     confd_path          = "/etc/datadog-agent/conf.d";
     additional_checksd  = "/etc/datadog-agent/checks.d";
     use_dogstatsd       = true;
@@ -16,6 +15,7 @@ let
   // optionalAttrs (cfg.logLevel != null) { log_level = cfg.logLevel; }
   // optionalAttrs (cfg.hostname != null) { inherit (cfg) hostname; }
   // optionalAttrs (cfg.tags != null ) { tags = concatStringsSep ", " cfg.tags; }
+  // optionalAttrs (cfg.enableLiveProcessCollection) { process_config = { enabled = "true"; }; }
   // cfg.extraConfig;
 
   # Generate Datadog configuration files for each configured checks.
@@ -125,6 +125,13 @@ in {
       '';
      };
 
+    enableLiveProcessCollection = mkOption {
+      description = ''
+        Whether to enable the live process collection agent.
+      '';
+      default = false;
+      type = types.bool;
+    };
     checks = mkOption {
       description = ''
         Configuration for all Datadog checks. Keys of this attribute
@@ -206,7 +213,6 @@ in {
           Group = "datadog";
           Restart = "always";
           RestartSec = 2;
-          PrivateTmp = true;
         };
         restartTriggers = [ datadogPkg ] ++ map (etc: etc.source) etcfiles;
       } attrs;
@@ -229,6 +235,15 @@ in {
         path = [ datadogPkg pkgs.python pkgs.sysstat pkgs.procps pkgs.jdk ];
         serviceConfig.ExecStart = "${datadogPkg}/bin/dd-jmxfetch";
       });
+
+      datadog-process-agent = lib.mkIf cfg.enableLiveProcessCollection (makeService {
+        description = "Datadog Live Process Agent";
+        path = [ ];
+        script = ''
+          export DD_API_KEY=$(head -n 1 ${cfg.apiKeyFile})
+          ${pkgs.datadog-process-agent}/bin/agent --config /etc/datadog-agent/datadog.yaml
+        '';
+      });
     };
 
     environment.etc = etcfiles;

nixos/modules/services/monitoring/grafana.nix

@@ -235,7 +235,7 @@ in {
         but without GF_ prefix
       '';
       default = {};
-      type = types.attrsOf types.str;
+      type = with types; attrsOf (either str path);
     };
   };
 

nixos/modules/services/monitoring/prometheus/exporters.xml

@@ -3,13 +3,19 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="module-services-prometheus-exporters">
+ <title>Prometheus exporters</title>
+ <para>
+  Prometheus exporters provide metrics for the
+  <link xlink:href="https://prometheus.io">prometheus monitoring system</link>.
+ </para>
+ <section xml:id="module-services-prometheus-exporters-configuration">
+  <title>Configuration</title>
 
-<title>Prometheus exporters</title>
-
-<para>Prometheus exporters provide metrics for the <link xlink:href="https://prometheus.io">prometheus monitoring system</link>.</para>
-
-<section xml:id="module-services-prometheus-exporters-configuration"><title>Configuration</title>
-  <para>One of the most common exporters is the <link xlink:href="https://github.com/prometheus/node_exporter">node exporter</link>, it provides hardware and OS metrics from the host it's running on. The exporter could be configured as follows:
+  <para>
+   One of the most common exporters is the
+   <link xlink:href="https://github.com/prometheus/node_exporter">node
+   exporter</link>, it provides hardware and OS metrics from the host it's
+   running on. The exporter could be configured as follows:
 <programlisting>
   services.promtheus.exporters.node = {
     enable = true;
@@ -24,43 +30,88 @@
     firewallFilter = "-i br0 -p tcp -m tcp --dport 9100";
   };
 </programlisting>
-It should now serve all metrics from the collectors
-that are explicitly enabled and the ones that are
-<link xlink:href="https://github.com/prometheus/node_exporter#enabled-by-default">enabled by default</link>, via http under <literal>/metrics</literal>. In this example the firewall should just
-allow incoming connections to the exporter's port on the bridge interface <literal>br0</literal>
-(this would have to be configured seperately of course).
-For more information about configuration see <literal>man configuration.nix</literal> or
-search through the <link xlink:href="https://nixos.org/nixos/options.html#prometheus.exporters">available options</link>.
-</para>
-</section>
-<section xml:id="module-services-prometheus-exporters-new-exporter"><title>Adding a new exporter</title>
-  <para>To add a new exporter, it has to be packaged first (see <literal>nixpkgs/pkgs/servers/monitoring/prometheus/</literal> for examples), then a module can be added. The postfix exporter is used in this example:</para>
-<itemizedlist>
-  <listitem>
+   It should now serve all metrics from the collectors that are explicitly
+   enabled and the ones that are
+   <link xlink:href="https://github.com/prometheus/node_exporter#enabled-by-default">enabled
+   by default</link>, via http under <literal>/metrics</literal>. In this
+   example the firewall should just allow incoming connections to the
+   exporter's port on the bridge interface <literal>br0</literal> (this would
+   have to be configured seperately of course). For more information about
+   configuration see <literal>man configuration.nix</literal> or search through
+   the
+   <link xlink:href="https://nixos.org/nixos/options.html#prometheus.exporters">available
+   options</link>.
+  </para>
+ </section>
+ <section xml:id="module-services-prometheus-exporters-new-exporter">
+  <title>Adding a new exporter</title>
+
+  <para>
+   To add a new exporter, it has to be packaged first (see
+   <literal>nixpkgs/pkgs/servers/monitoring/prometheus/</literal> for
+   examples), then a module can be added. The postfix exporter is used in this
+   example:
+  </para>
+
+  <itemizedlist>
+   <listitem>
     <para>
-      Some default options for all exporters are provided by
-      <literal>nixpkgs/nixos/modules/services/monitoring/prometheus/exporters.nix</literal>:
+     Some default options for all exporters are provided by
+     <literal>nixpkgs/nixos/modules/services/monitoring/prometheus/exporters.nix</literal>:
     </para>
-  </listitem>
-  <listitem override='none'>
+   </listitem>
+   <listitem override='none'>
     <itemizedlist>
-      <listitem><para><literal>enable</literal></para></listitem>
-      <listitem><para><literal>port</literal></para></listitem>
-      <listitem><para><literal>listenAddress</literal></para></listitem>
-      <listitem><para><literal>extraFlags</literal></para></listitem>
-      <listitem><para><literal>openFirewall</literal></para></listitem>
-      <listitem><para><literal>firewallFilter</literal></para></listitem>
-      <listitem><para><literal>user</literal></para></listitem>
-      <listitem><para><literal>group</literal></para></listitem>
+     <listitem>
+      <para>
+       <literal>enable</literal>
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       <literal>port</literal>
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       <literal>listenAddress</literal>
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       <literal>extraFlags</literal>
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       <literal>openFirewall</literal>
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       <literal>firewallFilter</literal>
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       <literal>user</literal>
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       <literal>group</literal>
+      </para>
+     </listitem>
     </itemizedlist>
-  </listitem>
-  <listitem>
-    <para>As there is already a package available, the module can now be added.
-      This is accomplished by adding a new file to the
-      <literal>nixos/modules/services/monitoring/prometheus/exporters/</literal> directory,
-      which will be called postfix.nix and contains all exporter specific options
-      and configuration:
-      <programlisting>
+   </listitem>
+   <listitem>
+    <para>
+     As there is already a package available, the module can now be added. This
+     is accomplished by adding a new file to the
+     <literal>nixos/modules/services/monitoring/prometheus/exporters/</literal>
+     directory, which will be called postfix.nix and contains all exporter
+     specific options and configuration:
+<programlisting>
         # nixpgs/nixos/modules/services/prometheus/exporters/postfix.nix
         { config, lib, pkgs }:
 
@@ -121,15 +172,16 @@ search through the <link xlink:href="https://nixos.org/nixos/options.html#promet
         }
       </programlisting>
     </para>
-  </listitem>
-  <listitem>
+   </listitem>
+   <listitem>
     <para>
-      This should already be enough for the postfix exporter. Additionally one could
-      now add assertions and conditional default values. This can be done in the
-      'meta-module' that combines all exporter definitions and generates the submodules:
-      <literal>nixpkgs/nixos/modules/services/prometheus/exporters.nix</literal>
+     This should already be enough for the postfix exporter. Additionally one
+     could now add assertions and conditional default values. This can be done
+     in the 'meta-module' that combines all exporter definitions and generates
+     the submodules:
+     <literal>nixpkgs/nixos/modules/services/prometheus/exporters.nix</literal>
     </para>
-  </listitem>
-</itemizedlist>
-</section>
+   </listitem>
+  </itemizedlist>
+ </section>
 </chapter>

nixos/modules/services/networking/chrony.nix

@@ -3,12 +3,10 @@
 with lib;
 
 let
+  cfg = config.services.chrony;
 
   stateDir = "/var/lib/chrony";
-
-  keyFile = "/etc/chrony.keys";
-
-  cfg = config.services.chrony;
+  keyFile = "${stateDir}/chrony.keys";
 
   configFile = pkgs.writeText "chrony.conf" ''
     ${concatMapStringsSep "\n" (server: "server " + server) cfg.servers}
@@ -19,7 +17,6 @@ let
     }
 
     driftfile ${stateDir}/chrony.drift
-
     keyfile ${keyFile}
 
     ${optionalString (!config.time.hardwareClockInLocalTime) "rtconutc"}
@@ -27,18 +24,11 @@ let
     ${cfg.extraConfig}
   '';
 
-  chronyFlags = "-n -m -u chrony -f ${configFile} ${toString cfg.extraFlags}";
-
+  chronyFlags = "-m -u chrony -f ${configFile} ${toString cfg.extraFlags}";
 in
-
 {
-
-  ###### interface
-
   options = {
-
     services.chrony = {
-
       enable = mkOption {
         default = false;
         description = ''
@@ -83,15 +73,9 @@ in
         description = "Extra flags passed to the chronyd command.";
       };
     };
-
   };
 
-
-  ###### implementation
-
   config = mkIf cfg.enable {
-
-    # Make chronyc available in the system path
     environment.systemPackages = [ pkgs.chrony ];
 
     users.groups = singleton
@@ -113,26 +97,30 @@ in
       { description = "chrony NTP daemon";
 
         wantedBy = [ "multi-user.target" ];
-        wants = [ "time-sync.target" ];
-        before = [ "time-sync.target" ];
-        after = [ "network.target" ];
+        wants    = [ "time-sync.target" ];
+        before   = [ "time-sync.target" ];
+        after    = [ "network.target" ];
         conflicts = [ "ntpd.service" "systemd-timesyncd.service" ];
 
         path = [ pkgs.chrony ];
 
-        preStart =
-          ''
-            mkdir -m 0755 -p ${stateDir}
-            touch ${keyFile}
-            chmod 0640 ${keyFile}
-            chown chrony:chrony ${stateDir} ${keyFile}
-          '';
+        preStart = ''
+          mkdir -m 0755 -p ${stateDir}
+          touch ${keyFile}
+          chmod 0640 ${keyFile}
+          chown chrony:chrony ${stateDir} ${keyFile}
+        '';
 
         serviceConfig =
-          { ExecStart = "${pkgs.chrony}/bin/chronyd ${chronyFlags}";
+          { Type = "forking";
+            ExecStart = "${pkgs.chrony}/bin/chronyd ${chronyFlags}";
+
+            ProtectHome = "yes";
+            ProtectSystem = "full";
+            PrivateTmp = "yes";
+
+            ConditionCapability = "CAP_SYS_TIME";
           };
       };
-
   };
-
 }

nixos/modules/services/networking/dnscrypt-proxy.xml

@@ -3,67 +3,64 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="sec-dnscrypt-proxy">
-
-  <title>DNSCrypt client proxy</title>
+ <title>DNSCrypt client proxy</title>
+ <para>
+  The DNSCrypt client proxy relays DNS queries to a DNSCrypt enabled upstream
+  resolver. The traffic between the client and the upstream resolver is
+  encrypted and authenticated, mitigating the risk of MITM attacks, DNS
+  poisoning attacks, and third-party snooping (assuming the upstream is
+  trustworthy).
+ </para>
+ <sect1 xml:id="sec-dnscrypt-proxy-configuration">
+  <title>Basic configuration</title>
 
   <para>
-    The DNSCrypt client proxy relays DNS queries to a DNSCrypt enabled
-    upstream resolver. The traffic between the client and the upstream
-    resolver is encrypted and authenticated, mitigating the risk of MITM
-    attacks, DNS poisoning attacks, and third-party snooping (assuming the
-    upstream is trustworthy).
-  </para>
-
-  <sect1 xml:id="sec-dnscrypt-proxy-configuration"><title>Basic configuration</title>
-
-  <para>
-    To enable the client proxy, set
-    <programlisting>
+   To enable the client proxy, set
+<programlisting>
 <xref linkend="opt-services.dnscrypt-proxy.enable"/> = true;
     </programlisting>
   </para>
 
   <para>
-    Enabling the client proxy does not alter the system nameserver; to
-    relay local queries, prepend <literal>127.0.0.1</literal> to
-    <option>networking.nameservers</option>.
+   Enabling the client proxy does not alter the system nameserver; to relay
+   local queries, prepend <literal>127.0.0.1</literal> to
+   <option>networking.nameservers</option>.
   </para>
-
-  </sect1>
-
-  <sect1 xml:id="sec-dnscrypt-proxy-forwarder"><title>As a forwarder for another DNS client</title>
+ </sect1>
+ <sect1 xml:id="sec-dnscrypt-proxy-forwarder">
+  <title>As a forwarder for another DNS client</title>
 
   <para>
-    To run the DNSCrypt proxy client as a forwarder for another
-    DNS client, change the default proxy listening port to a
-    non-standard value and point the other client to it:
-    <programlisting>
+   To run the DNSCrypt proxy client as a forwarder for another DNS client,
+   change the default proxy listening port to a non-standard value and point
+   the other client to it:
+<programlisting>
 <xref linkend="opt-services.dnscrypt-proxy.localPort"/> = 43;
     </programlisting>
   </para>
 
-  <sect2 xml:id="sec-dnscrypt-proxy-forwarder-dsnmasq"><title>dnsmasq</title>
-  <para>
-    <programlisting>
+  <sect2 xml:id="sec-dnscrypt-proxy-forwarder-dsnmasq">
+   <title>dnsmasq</title>
+   <para>
+<programlisting>
 {
   <xref linkend="opt-services.dnsmasq.enable"/> = true;
   <xref linkend="opt-services.dnsmasq.servers"/> = [ "127.0.0.1#43" ];
 }
     </programlisting>
-  </para>
+   </para>
   </sect2>
 
-  <sect2 xml:id="sec-dnscrypt-proxy-forwarder-unbound"><title>unbound</title>
-  <para>
-    <programlisting>
+  <sect2 xml:id="sec-dnscrypt-proxy-forwarder-unbound">
+   <title>unbound</title>
+   <para>
+<programlisting>
 {
   <xref linkend="opt-services.unbound.enable"/> = true;
   <xref linkend="opt-services.unbound.forwardAddresses"/> = [ "127.0.0.1@43" ];
 }
     </programlisting>
-  </para>
+   </para>
   </sect2>
-
-  </sect1>
-
+ </sect1>
 </chapter>

nixos/modules/services/networking/networkmanager.nix

@@ -406,25 +406,25 @@ in {
       { source = configFile;
         target = "NetworkManager/NetworkManager.conf";
       }
-      { source = "${networkmanager-openvpn}/etc/NetworkManager/VPN/nm-openvpn-service.name";
+      { source = "${networkmanager-openvpn}/lib/NetworkManager/VPN/nm-openvpn-service.name";
         target = "NetworkManager/VPN/nm-openvpn-service.name";
       }
-      { source = "${networkmanager-vpnc}/etc/NetworkManager/VPN/nm-vpnc-service.name";
+      { source = "${networkmanager-vpnc}/lib/NetworkManager/VPN/nm-vpnc-service.name";
         target = "NetworkManager/VPN/nm-vpnc-service.name";
       }
-      { source = "${networkmanager-openconnect}/etc/NetworkManager/VPN/nm-openconnect-service.name";
+      { source = "${networkmanager-openconnect}/lib/NetworkManager/VPN/nm-openconnect-service.name";
         target = "NetworkManager/VPN/nm-openconnect-service.name";
       }
-      { source = "${networkmanager-fortisslvpn}/etc/NetworkManager/VPN/nm-fortisslvpn-service.name";
+      { source = "${networkmanager-fortisslvpn}/lib/NetworkManager/VPN/nm-fortisslvpn-service.name";
         target = "NetworkManager/VPN/nm-fortisslvpn-service.name";
       }
-      { source = "${networkmanager-l2tp}/etc/NetworkManager/VPN/nm-l2tp-service.name";
+      { source = "${networkmanager-l2tp}/lib/NetworkManager/VPN/nm-l2tp-service.name";
         target = "NetworkManager/VPN/nm-l2tp-service.name";
       }
-      { source = "${networkmanager_strongswan}/etc/NetworkManager/VPN/nm-strongswan-service.name";
+      { source = "${networkmanager_strongswan}/lib/NetworkManager/VPN/nm-strongswan-service.name";
         target = "NetworkManager/VPN/nm-strongswan-service.name";
       }
-      { source = "${networkmanager-iodine}/etc/NetworkManager/VPN/nm-iodine-service.name";
+      { source = "${networkmanager-iodine}/lib/NetworkManager/VPN/nm-iodine-service.name";
         target = "NetworkManager/VPN/nm-iodine-service.name";
       }
     ] ++ optional (cfg.appendNameservers == [] || cfg.insertNameservers == [])

nixos/modules/services/networking/shairport-sync.nix

@@ -27,7 +27,7 @@ in
       };
 
       arguments = mkOption {
-        default = "-v -o pulse";
+        default = "-v -d pulse";
         description = ''
           Arguments to pass to the daemon. Defaults to a local pulseaudio
           server.
@@ -72,6 +72,7 @@ in
         serviceConfig = {
           User = cfg.user;
           ExecStart = "${pkgs.shairport-sync}/bin/shairport-sync ${cfg.arguments}";
+          RuntimeDirectory = "shairport-sync";
         };
       };
 

nixos/modules/services/networking/zeronet.nix

@@ -12,6 +12,8 @@ let
       log_dir = ${cfg.logDir}
     '' + lib.optionalString (cfg.port != null) ''
       ui_port = ${toString cfg.port}
+    '' + lib.optionalString (cfg.torAlways) ''
+      tor = always
     '' + cfg.extraConfig;
   };
 in with lib; {
@@ -35,11 +37,17 @@ in with lib; {
     port = mkOption {
       type = types.nullOr types.int;
       default = null;
-      example = 15441;
-      description = "Optional zeronet port.";
+      example = 43110;
+      description = "Optional zeronet web UI port.";
     };
 
     tor = mkOption {
+      type = types.bool;
+      default = false;
+      description = "Use TOR for zeronet traffic where possible.";
+    };
+
+    torAlways = mkOption {
       type = types.bool;
       default = false;
       description = "Use TOR for all zeronet traffic.";
@@ -60,9 +68,13 @@ in with lib; {
     services.tor = mkIf cfg.tor {
       enable = true;
       controlPort = 9051;
-      extraConfig = "CookieAuthentication 1";
+      extraConfig = ''
+        CacheDirectoryGroupReadable 1
+        CookieAuthentication 1
+        CookieAuthFileGroupReadable 1
+      '';
     };
-    
+
     systemd.services.zeronet = {
       description = "zeronet";
       after = [ "network.target" (optionalString cfg.tor "tor.service") ];

nixos/modules/services/security/clamav.nix

@@ -95,7 +95,7 @@ in
     environment.etc."clamav/freshclam.conf".source = freshclamConfigFile;
     environment.etc."clamav/clamd.conf".source = clamdConfigFile;
 
-    systemd.services.clamav-daemon = optionalAttrs cfg.daemon.enable {
+    systemd.services.clamav-daemon = mkIf cfg.daemon.enable {
       description = "ClamAV daemon (clamd)";
       after = optional cfg.updater.enable "clamav-freshclam.service";
       requires = optional cfg.updater.enable "clamav-freshclam.service";
@@ -116,7 +116,7 @@ in
       };
     };
 
-    systemd.timers.clamav-freshclam = optionalAttrs cfg.updater.enable {
+    systemd.timers.clamav-freshclam = mkIf cfg.updater.enable {
       description = "Timer for ClamAV virus database updater (freshclam)";
       wantedBy = [ "timers.target" ];
       timerConfig = {
@@ -125,7 +125,7 @@ in
       };
     };
 
-    systemd.services.clamav-freshclam = optionalAttrs cfg.updater.enable {
+    systemd.services.clamav-freshclam = mkIf cfg.updater.enable {
       description = "ClamAV virus database updater (freshclam)";
       restartTriggers = [ freshclamConfigFile ];
 
@@ -137,6 +137,7 @@ in
       serviceConfig = {
         Type = "oneshot";
         ExecStart = "${pkg}/bin/freshclam";
+        SuccessExitStatus = "1"; # if databases are up to date
         PrivateTmp = "yes";
         PrivateDevices = "yes";
       };

nixos/modules/services/security/tor.nix

@@ -208,7 +208,7 @@ in
           enable = mkOption {
             type = types.bool;
             default = false;
-            description = "Whether to enable tor transaprent proxy";
+            description = "Whether to enable tor transparent proxy";
           };
 
           listenAddress = mkOption {

nixos/modules/services/web-apps/matomo-doc.xml

@@ -3,28 +3,24 @@
          xmlns:xi="http://www.w3.org/2001/XInclude"
          version="5.0"
          xml:id="module-services-matomo">
-
-  <title>Matomo</title>
-  <para>
-    Matomo is a real-time web analytics application.
-    This module configures php-fpm as backend for Matomo, optionally configuring an nginx vhost as well.
-  </para>
+ <title>Matomo</title>
+ <para>
+  Matomo is a real-time web analytics application. This module configures
+  php-fpm as backend for Matomo, optionally configuring an nginx vhost as well.
+ </para>
+ <para>
+  An automatic setup is not suported by Matomo, so you need to configure Matomo
+  itself in the browser-based Matomo setup.
+ </para>
+ <section xml:id="module-services-matomo-database-setup">
+  <title>Database Setup</title>
 
   <para>
-    An automatic setup is not suported by Matomo, so you need to configure Matomo itself in the browser-based Matomo setup.
-  </para>
-
-
-  <section xml:id="module-services-matomo-database-setup">
-    <title>Database Setup</title>
-
-    <para>
-      You also need to configure a MariaDB or MySQL database and -user for Matomo yourself,
-      and enter those credentials in your browser.
-      You can use passwordless database authentication via the UNIX_SOCKET authentication plugin
-      with the following SQL commands:
-
-      <programlisting>
+   You also need to configure a MariaDB or MySQL database and -user for Matomo
+   yourself, and enter those credentials in your browser. You can use
+   passwordless database authentication via the UNIX_SOCKET authentication
+   plugin with the following SQL commands:
+<programlisting>
         # For MariaDB
         INSTALL PLUGIN unix_socket SONAME 'auth_socket';
         CREATE DATABASE matomo;
@@ -37,59 +33,58 @@
         CREATE USER 'matomo'@'localhost' IDENTIFIED WITH auth_socket;
         GRANT ALL PRIVILEGES ON matomo.* TO 'matomo'@'localhost';
       </programlisting>
+   Then fill in <literal>matomo</literal> as database user and database name,
+   and leave the password field blank. This authentication works by allowing
+   only the <literal>matomo</literal> unix user to authenticate as the
+   <literal>matomo</literal> database user (without needing a password), but no
+   other users. For more information on passwordless login, see
+   <link xlink:href="https://mariadb.com/kb/en/mariadb/unix_socket-authentication-plugin/" />.
+  </para>
 
-      Then fill in <literal>matomo</literal> as database user and database name, and leave the password field blank.
-      This authentication works by allowing only the <literal>matomo</literal> unix user to authenticate as the
-      <literal>matomo</literal> database user (without needing a password), but no other users.
-      For more information on passwordless login, see
-      <link xlink:href="https://mariadb.com/kb/en/mariadb/unix_socket-authentication-plugin/" />.
-    </para>
+  <para>
+   Of course, you can use password based authentication as well, e.g. when the
+   database is not on the same host.
+  </para>
+ </section>
+ <section xml:id="module-services-matomo-backups">
+  <title>Backup</title>
 
+  <para>
+   You only need to take backups of your MySQL database and the
+   <filename>/var/lib/matomo/config/config.ini.php</filename> file. Use a user
+   in the <literal>matomo</literal> group or root to access the file. For more
+   information, see
+   <link xlink:href="https://matomo.org/faq/how-to-install/faq_138/" />.
+  </para>
+ </section>
+ <section xml:id="module-services-matomo-issues">
+  <title>Issues</title>
+
+  <itemizedlist>
+   <listitem>
     <para>
-      Of course, you can use password based authentication as well, e.g. when the database is not on the same host.
+     Matomo's file integrity check will warn you. This is due to the patches
+     necessary for NixOS, you can safely ignore this.
     </para>
-  </section>
-
-
-  <section xml:id="module-services-matomo-backups">
-    <title>Backup</title>
+   </listitem>
+   <listitem>
     <para>
-      You only need to take backups of your MySQL database and the
-      <filename>/var/lib/matomo/config/config.ini.php</filename> file.
-      Use a user in the <literal>matomo</literal> group or root to access the file.
-      For more information, see <link xlink:href="https://matomo.org/faq/how-to-install/faq_138/" />.
+     Matomo will warn you that the JavaScript tracker is not writable. This is
+     because it's located in the read-only nix store. You can safely ignore
+     this, unless you need a plugin that needs JavaScript tracker access.
     </para>
-  </section>
+   </listitem>
+  </itemizedlist>
+ </section>
+ <section xml:id="module-services-matomo-other-web-servers">
+  <title>Using other Web Servers than nginx</title>
 
-
-  <section xml:id="module-services-matomo-issues">
-    <title>Issues</title>
-    <itemizedlist>
-      <listitem>
-        <para>
-          Matomo's file integrity check will warn you.
-          This is due to the patches necessary for NixOS, you can safely ignore this.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          Matomo will warn you that the JavaScript tracker is not writable.
-          This is because it's located in the read-only nix store.
-          You can safely ignore this, unless you need a plugin that needs JavaScript tracker access.
-        </para>
-      </listitem>
-    </itemizedlist>
-  </section>
-
-
-  <section xml:id="module-services-matomo-other-web-servers">
-    <title>Using other Web Servers than nginx</title>
-
-    <para>
-      You can use other web servers by forwarding calls for <filename>index.php</filename> and
-      <filename>piwik.php</filename> to the <literal>/run/phpfpm-matomo.sock</literal> fastcgi unix socket.
-      You can use the nginx configuration in the module code as a reference to what else should be configured.
-    </para>
-  </section>
+  <para>
+   You can use other web servers by forwarding calls for
+   <filename>index.php</filename> and <filename>piwik.php</filename> to the
+   <literal>/run/phpfpm-matomo.sock</literal> fastcgi unix socket. You can use
+   the nginx configuration in the module code as a reference to what else
+   should be configured.
+  </para>
+ </section>
 </chapter>

nixos/modules/services/x11/desktop-managers/plasma5.nix

@@ -81,6 +81,7 @@ in
           kconfig
           kconfigwidgets
           kcoreaddons
+          kdoctools
           kdbusaddons
           kdeclarative
           kded
@@ -224,11 +225,8 @@ in
       security.pam.services.sddm.enableKwallet = true;
       security.pam.services.slim.enableKwallet = true;
 
-      # Update the start menu for each user that has `isNormalUser` set.
-      system.activationScripts.plasmaSetup = stringAfter [ "users" "groups" ]
-        (concatStringsSep "\n"
-          (mapAttrsToList (name: value: "${pkgs.su}/bin/su ${name} -c ${pkgs.libsForQt5.kservice}/bin/kbuildsycoca5")
-            (filterAttrs (n: v: v.isNormalUser) config.users.users)));
+      # Update the start menu for each user that is currently logged in
+      system.userActivationScripts.plasmaSetup = "${pkgs.libsForQt5.kservice}/bin/kbuildsycoca5";
     })
   ];
 

nixos/modules/services/x11/display-managers/lightdm.nix

@@ -197,7 +197,7 @@ in
       # lightdm relaunches itself via just `lightdm`, so needs to be on the PATH
       execCmd = ''
         export PATH=${lightdm}/sbin:$PATH
-        exec ${lightdm}/sbin/lightdm --log-dir=/var/log --run-dir=/run
+        exec ${lightdm}/sbin/lightdm
       '';
     };
 
@@ -246,12 +246,19 @@ in
     '';
 
     users.users.lightdm = {
-      createHome = true;
-      home = "/var/lib/lightdm-data";
+      home = "/var/lib/lightdm";
       group = "lightdm";
       uid = config.ids.uids.lightdm;
     };
 
+    systemd.tmpfiles.rules = [
+      "d /run/lightdm 0711 lightdm lightdm 0"
+      "d /var/cache/lightdm 0711 root lightdm -"
+      "d /var/lib/lightdm 1770 lightdm lightdm -"
+      "d /var/lib/lightdm-data 1775 lightdm lightdm -"
+      "d /var/log/lightdm 0711 root lightdm -"
+    ];
+
     users.groups.lightdm.gid = config.ids.gids.lightdm;
     services.xserver.tty     = null; # We might start multiple X servers so let the tty increment themselves..
     services.xserver.display = null; # We specify our own display (and logfile) in xserver-wrapper up there

nixos/modules/system/activation/activation-script.nix

@@ -100,6 +100,52 @@ in
             exit $_status
           '';
       };
+    };
+
+    system.userActivationScripts = mkOption {
+      default = {};
+
+      example = literalExample ''
+        { plasmaSetup = {
+            text = '''
+              ${pkgs.libsForQt5.kservice}/bin/kbuildsycoca5"
+            ''';
+            deps = [];
+          };
+        }
+      '';
+
+      description = ''
+        A set of shell script fragments that are executed by a systemd user
+        service when a NixOS system configuration is activated. Examples are
+        rebuilding the .desktop file cache for showing applications in the menu.
+        Since these are executed every time you run
+        <command>nixos-rebuild</command>, it's important that they are
+        idempotent and fast.
+      '';
+
+      type = types.attrsOf types.unspecified;
+
+      apply = set: {
+        script = ''
+          unset PATH
+          for i in ${toString path}; do
+            PATH=$PATH:$i/bin:$i/sbin
+          done
+
+          _status=0
+          trap "_status=1 _localstatus=\$?" ERR
+
+          ${
+            let
+              set' = mapAttrs (n: v: if isString v then noDepEntry v else v) set;
+              withHeadlines = addAttributeName set';
+            in textClosureMap id (withHeadlines) (attrNames withHeadlines)
+          }
+
+          exit $_status
+        '';
+      };
 
     };
 
@@ -177,6 +223,14 @@ in
         source ${config.system.build.earlyMountScript}
       '';
 
+    systemd.user = {
+      services.nixos-activation = {
+        description = "Run user specific NixOS activation";
+        script = config.system.userActivationScripts.script;
+        unitConfig.ConditionUser = "!@system";
+        serviceConfig.Type = "oneshot";
+      };
+    };
   };
 
 }

nixos/modules/system/activation/switch-to-configuration.pl

@@ -419,7 +419,8 @@ while (my $f = <$listActiveUsers>) {
     my ($uid, $name) = ($+{uid}, $+{user});
     print STDERR "reloading user units for $name...\n";
 
-    system("su", "-l", $name, "-c", "XDG_RUNTIME_DIR=/run/user/$uid @systemd@/bin/systemctl --user daemon-reload");
+    system("@su@", "-s", "@shell@", "-l", $name, "-c", "XDG_RUNTIME_DIR=/run/user/$uid @systemd@/bin/systemctl --user daemon-reload");
+    system("@su@", "-s", "@shell@", "-l", $name, "-c", "XDG_RUNTIME_DIR=/run/user/$uid @systemd@/bin/systemctl --user start nixos-activation.service");
 }
 
 close $listActiveUsers;

nixos/modules/system/activation/top-level.nix

@@ -115,6 +115,8 @@ let
 
       inherit (pkgs) utillinux coreutils;
       systemd = config.systemd.package;
+      shell = "${pkgs.bash}/bin/sh";
+      su = "${pkgs.shadow.su}/bin/su";
 
       inherit children;
       kernelParams = config.boot.kernelParams;

nixos/modules/system/boot/kexec.nix

@@ -1,7 +1,7 @@
 { pkgs, lib, ... }:
 
 {
-  config = lib.mkIf (pkgs.kexectools.meta.available) {
+  config = lib.mkIf (lib.any (lib.meta.platformMatch pkgs.stdenv.hostPlatform) pkgs.kexectools.meta.platforms) {
     environment.systemPackages = [ pkgs.kexectools ];
 
     systemd.services."prepare-kexec" =

nixos/modules/system/boot/systemd-unit-options.nix

@@ -394,7 +394,7 @@ in rec {
         Each attribute in this set specifies an option in the
         <literal>[Timer]</literal> section of the unit.  See
         <citerefentry><refentrytitle>systemd.timer</refentrytitle>
-        <manvolnum>7</manvolnum></citerefentry> and
+        <manvolnum>5</manvolnum></citerefentry> and
         <citerefentry><refentrytitle>systemd.time</refentrytitle>
         <manvolnum>7</manvolnum></citerefentry> for details.
       '';

nixos/modules/system/boot/systemd.nix

@@ -886,6 +886,9 @@ in
     #systemd.services.systemd-logind.restartTriggers = [ config.environment.etc."systemd/logind.conf".source ];
     systemd.services.systemd-logind.restartIfChanged = false;
     systemd.services.systemd-logind.stopIfChanged = false;
+    # The user-runtime-dir@ service is managed by systemd-logind we should not touch it or else we break the users' sessions.
+    systemd.services."user-runtime-dir@".stopIfChanged = false;
+    systemd.services."user-runtime-dir@".restartIfChanged = false;
     systemd.services.systemd-journald.restartTriggers = [ config.environment.etc."systemd/journald.conf".source ];
     systemd.services.systemd-journald.stopIfChanged = false;
     systemd.targets.local-fs.unitConfig.X-StopOnReconfiguration = true;

nixos/modules/tasks/network-interfaces.nix

@@ -341,7 +341,7 @@ in
         You should try to make this ID unique among your machines. You can
         generate a random 32-bit ID using the following commands:
 
-        <literal>cksum /etc/machine-id | while read c rest; do printf "%x" $c; done</literal>
+        <literal>head -c 8 /etc/machine-id</literal>
 
         (this derives it from the machine-id that systemd generates) or
 

nixos/modules/testing/test-instrumentation.nix

@@ -55,7 +55,8 @@ with import ../../lib/qemu-flags.nix { inherit pkgs; };
     systemd.services."serial-getty@hvc0".enable = false;
 
     # Only use a serial console, no TTY.
-    virtualisation.qemu.consoles = [ qemuSerialDevice ];
+    # hvc1: socket backdoor, see "Debugging NixOS tests" section in NixOS manual
+    virtualisation.qemu.consoles = [ "hvc1" qemuSerialDevice ];
 
     boot.initrd.preDeviceCommands =
       ''

nixos/modules/virtualisation/google-compute-image.nix

@@ -97,8 +97,8 @@ in
       "google-instance-setup.service"
       "google-network-setup.service"
     ];
-    wantedBy = [ "multi-user.target" ];
     requires = ["network.target"];
+    wantedBy = ["multi-user.target"];
     path = with pkgs; [ shadow ];
     serviceConfig = {
       Type = "simple";
@@ -113,8 +113,8 @@ in
       "google-instance-setup.service"
       "google-network-setup.service"
     ];
-    requires = [ "network.target" ];
-    wantedBy = [ "multi-user.target" ];
+    requires = ["network.target"];
+    wantedBy = ["multi-user.target"];
     serviceConfig = {
       Type = "simple";
       ExecStart = "${gce}/bin/google_clock_skew_daemon --debug";
@@ -123,7 +123,7 @@ in
 
   systemd.services.google-instance-setup = {
     description = "Google Compute Engine Instance Setup";
-    after = ["fs.target" "network-online.target" "network.target" "rsyslog.service"];
+    after = ["local-fs.target" "network-online.target" "network.target" "rsyslog.service"];
     before = ["sshd.service"];
     wants = ["local-fs.target" "network-online.target" "network.target"];
     wantedBy = [ "sshd.service" "multi-user.target" ];
@@ -134,15 +134,17 @@ in
     };
   };
 
-  systemd.services.google-ip-forwarding-daemon = {
-    description = "Google Compute Engine IP Forwarding Daemon";
-    after = ["network.target" "google-instance-setup.service" "google-network-setup.service"];
+  systemd.services.google-network-daemon = {
+    description = "Google Compute Engine Network Daemon";
+    after = ["local-fs.target" "network-online.target" "network.target" "rsyslog.service" "google-instance-setup.service"];
+    wants = ["local-fs.target" "network-online.target" "network.target"];
     requires = ["network.target"];
+    partOf = ["network.target"];
     wantedBy = [ "multi-user.target" ];
     path = with pkgs; [ iproute ];
     serviceConfig = {
-      Type = "simple";
-      ExecStart = "${gce}/bin/google_ip_forwarding_daemon --debug";
+      ExecStart = "${gce}/bin/google_network_daemon --debug";
+      Type = "oneshot";
     };
   };
 
@@ -153,8 +155,9 @@ in
       "network-online.target"
       "network.target"
       "rsyslog.service"
+      "systemd-resolved.service"
       "google-instance-setup.service"
-      "google-network-setup.service"
+      "google-network-daemon.service"
     ];
     wants = [ "local-fs.target" "network-online.target" "network.target"];
     wantedBy = [ "multi-user.target" ];
@@ -167,23 +170,6 @@ in
     };
   };
 
-  systemd.services.google-network-setup = {
-    description = "Google Compute Engine Network Setup";
-    after = [
-      "local-fs.target"
-      "network-online.target"
-      "network.target"
-      "rsyslog.service"
-    ];
-    wants = [ "local-fs.target" "network-online.target" "network.target"];
-    wantedBy = [ "multi-user.target" ];
-    serviceConfig = {
-      ExecStart = "${gce}/bin/google_network_setup --debug";
-      KillMode = "process";
-      Type = "oneshot";
-    };
-  };
-
   systemd.services.google-startup-scripts = {
     description = "Google Compute Engine Startup Scripts";
     after = [
@@ -192,9 +178,9 @@ in
       "network.target"
       "rsyslog.service"
       "google-instance-setup.service"
-      "google-network-setup.service"
+      "google-network-daemon.service"
     ];
-    wants = [ "local-fs.target" "network-online.target" "network.target"];
+    wants = ["local-fs.target" "network-online.target" "network.target"];
     wantedBy = [ "multi-user.target" ];
     serviceConfig = {
       ExecStart = "${gce}/bin/google_metadata_script_runner --debug --script-type startup";

nixos/modules/virtualisation/hyperv-guest.nix

@@ -9,20 +9,47 @@ in {
   options = {
     virtualisation.hypervGuest = {
       enable = mkEnableOption "Hyper-V Guest Support";
+
+      videoMode = mkOption {
+        type = types.str;
+        default = "1152x864";
+        example = "1024x768";
+        description = ''
+          Resolution at which to initialize the video adapter.
+
+          Supports screen resolution up to Full HD 1920x1080 with 32 bit color
+          on Windows Server 2012, and 1600x1200 with 16 bit color on Windows
+          Server 2008 R2 or earlier.
+        '';
+      };
     };
   };
 
   config = mkIf cfg.enable {
+    boot = {
+      initrd.kernelModules = [
+        "hv_balloon" "hv_netvsc" "hv_storvsc" "hv_utils" "hv_vmbus"
+      ];
+
+      kernelParams = [
+        "video=hyperv_fb:${cfg.videoMode}"
+      ];
+    };
+
     environment.systemPackages = [ config.boot.kernelPackages.hyperv-daemons.bin ];
 
     security.rngd.enable = false;
 
-    # enable hotadding memory
+    # enable hotadding cpu/memory
     services.udev.packages = lib.singleton (pkgs.writeTextFile {
-      name = "hyperv-memory-hotadd-udev-rules";
-      destination = "/etc/udev/rules.d/99-hyperv-memory-hotadd.rules";
+      name = "hyperv-cpu-and-memory-hotadd-udev-rules";
+      destination = "/etc/udev/rules.d/99-hyperv-cpu-and-memory-hotadd.rules";
       text = ''
-        ACTION="add", SUBSYSTEM=="memory", ATTR{state}="online"
+        # Memory hotadd
+        SUBSYSTEM=="memory", ACTION=="add", DEVPATH=="/devices/system/memory/memory[0-9]*", TEST=="state", ATTR{state}="online"
+
+        # CPU hotadd
+        SUBSYSTEM=="cpu", ACTION=="add", DEVPATH=="/devices/system/cpu/cpu[0-9]*", TEST=="online", ATTR{online}="1"
       '';
     });
 

nixos/release.nix

@@ -10,7 +10,7 @@ let
 
   version = fileContents ../.version;
   versionSuffix =
-    (if stableBranch then "." else "pre") + "${toString nixpkgs.revCount}.${nixpkgs.shortRev}";
+    (if stableBranch then "." else "beta") + "${toString (nixpkgs.revCount - 151577)}.${nixpkgs.shortRev}";
 
   importTest = fn: args: system: import fn ({
     inherit system;
@@ -284,7 +284,8 @@ in rec {
   tests.ecryptfs = callTest tests/ecryptfs.nix {};
   tests.etcd = callTestOnMatchingSystems ["x86_64-linux"] tests/etcd.nix {};
   tests.ec2-nixops = (callSubTestsOnMatchingSystems ["x86_64-linux"] tests/ec2.nix {}).boot-ec2-nixops or {};
-  tests.ec2-config = (callSubTestsOnMatchingSystems ["x86_64-linux"] tests/ec2.nix {}).boot-ec2-config or {};
+  # ec2-config doesn't work in a sandbox as the simulated ec2 instance needs network access
+  #tests.ec2-config = (callSubTestsOnMatchingSystems ["x86_64-linux"] tests/ec2.nix {}).boot-ec2-config or {};
   tests.elk = callSubTestsOnMatchingSystems ["x86_64-linux"] tests/elk.nix {};
   tests.env = callTest tests/env.nix {};
   tests.ferm = callTest tests/ferm.nix {};
@@ -327,7 +328,6 @@ in rec {
   tests.keymap = callSubTests tests/keymap.nix {};
   tests.initrdNetwork = callTest tests/initrd-network.nix {};
   tests.kafka = callSubTests tests/kafka.nix {};
-  tests.kernel-copperhead = callTest tests/kernel-copperhead.nix {};
   tests.kernel-latest = callTest tests/kernel-latest.nix {};
   tests.kernel-lts = callTest tests/kernel-lts.nix {};
   tests.kubernetes.dns = callSubTestsOnMatchingSystems ["x86_64-linux"] tests/kubernetes/dns.nix {};
@@ -400,7 +400,7 @@ in rec {
   tests.slurm = callTest tests/slurm.nix {};
   tests.smokeping = callTest tests/smokeping.nix {};
   tests.snapper = callTest tests/snapper.nix {};
-  tests.statsd = callTest tests/statsd.nix {};
+  #tests.statsd = callTest tests/statsd.nix {}; # statsd is broken: #45946
   tests.strongswan-swanctl = callTest tests/strongswan-swanctl.nix {};
   tests.sudo = callTest tests/sudo.nix {};
   tests.systemd = callTest tests/systemd.nix {};