Merge branch 'staging-next' into staging

15 files changed, 249 insertions, 213 deletions

diff --git a/doc/builders/images/dockertools.xml b/doc/builders/images/dockertools.xml
index 126698d0a9e..d881e712a04 100644
--- a/doc/builders/images/dockertools.xml
+++ b/doc/builders/images/dockertools.xml
@@ -132,11 +132,11 @@ buildImage {
    <para>
     By default <function>buildImage</function> will use a static date of one second past the UNIX Epoch. This allows <function>buildImage</function> to produce binary reproducible images. When listing images with <command>docker images</command>, the newly created images will be listed like this:
    </para>
-<screen><![CDATA[
-$ docker images
+<screen>
+<prompt>$ </prompt>docker images
 REPOSITORY   TAG      IMAGE ID       CREATED        SIZE
 hello        latest   08c791c7846e   48 years ago   25.2MB
-]]></screen>
+</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>
@@ -152,11 +152,11 @@ pkgs.dockerTools.buildImage {
 ]]></programlisting>
    <para>
     and now the Docker CLI will display a reasonable date and sort the images as expected:
-<screen><![CDATA[
-$ docker images
+<screen>
+<prompt>$ </prompt>docker images
 REPOSITORY   TAG      IMAGE ID       CREATED              SIZE
 hello        latest   de2bf4786de6   About a minute ago   25.2MB
-]]></screen>
+</screen>
     however, the produced images will not be binary reproducible.
    </para>
   </example>
diff --git a/doc/builders/images/ocitools.xml b/doc/builders/images/ocitools.xml
index e8cd3472f54..f26ed864427 100644
--- a/doc/builders/images/ocitools.xml
+++ b/doc/builders/images/ocitools.xml
@@ -38,8 +38,7 @@ buildContainer {
 
   readonly = false; <co xml:id='ex-ociTools-buildContainer-3' />
 }
-
-    </programlisting>
+</programlisting>
    <calloutlist>
     <callout arearefs='ex-ociTools-buildContainer-1'>
      <para>
diff --git a/doc/builders/packages/citrix.xml b/doc/builders/packages/citrix.xml
index 16f1bc6f8f2..803eb2e4fc4 100644
--- a/doc/builders/packages/citrix.xml
+++ b/doc/builders/packages/citrix.xml
@@ -22,10 +22,10 @@
   </para>
   <para>
    In order to set this up, you first have to <link xlink:href="https://its.uiowa.edu/support/article/102186">download the <literal>.cr</literal> file from the Netscaler Gateway</link>. After that you can configure the <command>selfservice</command> like this:
-   <screen>
-    <prompt>$ </prompt>storebrowse -C ~/Downloads/receiverconfig.cr
-    <prompt>$ </prompt>selfservice
-   </screen>
+<screen>
+<prompt>$ </prompt>storebrowse -C ~/Downloads/receiverconfig.cr
+<prompt>$ </prompt>selfservice
+</screen>
   </para>
  </section>
 
diff --git a/doc/builders/packages/urxvt.xml b/doc/builders/packages/urxvt.xml
index 135cc82a0b5..330e056b656 100644
--- a/doc/builders/packages/urxvt.xml
+++ b/doc/builders/packages/urxvt.xml
@@ -18,10 +18,13 @@
    includes all available plugins. To make use of this functionality, use an
    overlay or directly install an expression that overrides its configuration,
    such as
-   <programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {
+<programlisting>
+rxvt-unicode.override {
+  configure = { availablePlugins, ... }: {
     plugins = with availablePlugins; [ perls resize-font vtwheel ];
-  }
-}</programlisting>
+  };
+}
+</programlisting>
    If the <literal>configure</literal> function returns an attrset without the
    <literal>plugins</literal> attribute, <literal>availablePlugins</literal>
    will be used automatically.
@@ -30,18 +33,22 @@
   <para>
    In order to add plugins but also keep all default plugins installed, it is
    possible to use the following method:
-   <programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {
-     plugins = (builtins.attrValues availablePlugins) ++ [ custom-plugin ];
-   };
-}</programlisting>
+<programlisting>
+rxvt-unicode.override {
+  configure = { availablePlugins, ... }: {
+    plugins = (builtins.attrValues availablePlugins) ++ [ custom-plugin ];
+  };
+}
+</programlisting>
   </para>
 
   <para>
    To get a list of all the plugins available, open the Nix REPL and run
-   <programlisting>$ nix repl
+<screen>
+<prompt>$ </prompt>nix repl
 :l &lt;nixpkgs&gt;
 map (p: p.name) pkgs.rxvt-unicode.plugins
-   </programlisting>
+</screen>
    Alternatively, if your shell is bash or zsh and have completion enabled,
    simply type <literal>nixpkgs.rxvt-unicode.plugins.&lt;tab&gt;</literal>.
   </para>
@@ -53,18 +60,24 @@ map (p: p.name) pkgs.rxvt-unicode.plugins
     <literal>extraDeps</literal> can be used, for example, to provide
     <literal>xsel</literal> (a clipboard manager) to the clipboard plugin,
     without installing it globally:
-    <programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {
-     pluginsDeps = [ xsel ];
-   }
-}</programlisting>
+<programlisting>
+rxvt-unicode.override {
+  configure = { availablePlugins, ... }: {
+    pluginsDeps = [ xsel ];
+  };
+}
+</programlisting>
 
     <literal>perlDeps</literal> is a handy way to provide Perl packages to
     your custom plugins (in <literal>$HOME/.urxvt/ext</literal>). For example,
     if you need <literal>AnyEvent</literal> you can do:
-    <programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {
-     perlDeps = with perlPackages; [ AnyEvent ];
-   }
-}</programlisting>
+<programlisting>
+rxvt-unicode.override {
+  configure = { availablePlugins, ... }: {
+    perlDeps = with perlPackages; [ AnyEvent ];
+  };
+}
+</programlisting>
   </para>
 
  </section>
@@ -90,7 +103,8 @@ map (p: p.name) pkgs.rxvt-unicode.plugins
   <para>
    If the plugin is itself a perl package that needs to be imported from
    other plugins or scripts, add the following passthrough:
-   <programlisting>passthru.perlPackages = [ "self" ];
+<programlisting>
+passthru.perlPackages = [ "self" ];
 </programlisting>
    This will make the urxvt wrapper pick up the dependency and set up the perl
    path accordingly.
diff --git a/doc/contributing/submitting-changes.xml b/doc/contributing/submitting-changes.xml
index a88965f5cc6..22389c24ea2 100644
--- a/doc/contributing/submitting-changes.xml
+++ b/doc/contributing/submitting-changes.xml
@@ -209,12 +209,12 @@ Additional information.
   </para>
 
 <programlisting>
-   (fetchpatch {
-     name = "CVE-2019-11068.patch";
-     url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
-     sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
-   })
-  </programlisting>
+(fetchpatch {
+  name = "CVE-2019-11068.patch";
+  url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
+  sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
+})
+</programlisting>
 
   <para>
    If a security fix applies to both master and a stable release then, similar to regular changes, they are preferably delivered via master first and cherry-picked to the release branch.
diff --git a/doc/languages-frameworks/beam.xml b/doc/languages-frameworks/beam.xml
index 1d307e1d6dc..addab24f7f6 100644
--- a/doc/languages-frameworks/beam.xml
+++ b/doc/languages-frameworks/beam.xml
@@ -72,9 +72,9 @@
    To install any of those builders into your profile, refer to them by their attribute path <literal>beamPackages.rebar3</literal>:
   </para>
 
-  <screen>
-  <prompt>$ </prompt>nix-env -f &quot;&lt;nixpkgs&gt;&quot; -iA beamPackages.rebar3
-  </screen>
+<screen>
+<prompt>$ </prompt>nix-env -f &quot;&lt;nixpkgs&gt;&quot; -iA beamPackages.rebar3
+</screen>
 </section>
 
  <section xml:id="packaging-beam-applications">
diff --git a/doc/languages-frameworks/go.xml b/doc/languages-frameworks/go.xml
index 7cff7a85c62..ebdcf616054 100644
--- a/doc/languages-frameworks/go.xml
+++ b/doc/languages-frameworks/go.xml
@@ -38,11 +38,7 @@ pet = buildGoModule rec {
 
   vendorSha256 = "1879j77k96684wi554rkjxydrj8g3hpp0kvxz03sd8dmwr3lh83j"; <co xml:id='ex-buildGoModule-1' />
 
-  subPackages = [ "." ]; <co xml:id='ex-buildGoModule-2' />
-
-  deleteVendor = true; <co xml:id='ex-buildGoModule-3' />
-
-  runVend = true; <co xml:id='ex-buildGoModule-4' />
+  runVend = true; <co xml:id='ex-buildGoModule-2' />
 
   meta = with lib; {
     description = "Simple command-line snippet manager, written in Go";
@@ -65,16 +61,6 @@ pet = buildGoModule rec {
     </callout>
     <callout arearefs='ex-buildGoModule-2'>
      <para>
-      <varname>subPackages</varname> limits the builder from building child packages that have not been listed. If <varname>subPackages</varname> is not specified, all child packages will be built.
-     </para>
-    </callout>
-    <callout arearefs='ex-buildGoModule-3'>
-     <para>
-      <varname>deleteVendor</varname> removes the pre-existing vendor directory and fetches the dependencies. This should only be used if the dependencies included in the vendor folder are broken or incomplete.
-     </para>
-    </callout>
-    <callout arearefs='ex-buildGoModule-4'>
-     <para>
       <varname>runVend</varname> runs the vend command to generate the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build.
      </para>
     </callout>
@@ -82,12 +68,7 @@ pet = buildGoModule rec {
   </para>
 
   <para>
-    <varname>vendorSha256</varname> can also take <varname>null</varname> as an input.
-
-    When `null` is used as a value, rather than fetching the dependencies
-    and vendoring them, we use the vendoring included within the source repo.
-    If you'd like to not have to update this field on dependency changes,
-    run `go mod vendor` in your source repo and set 'vendorSha256 = null;'
+   <varname>vendorSha256</varname> can also take <varname>null</varname> as an input. When `null` is used as a value, rather than fetching the dependencies and vendoring them, we use the vendoring included within the source repo. If you'd like to not have to update this field on dependency changes, run `go mod vendor` in your source repo and set 'vendorSha256 = null;'
   </para>
  </section>
 
@@ -106,7 +87,6 @@ deis = buildGoPackage rec {
   version = "1.13.0";
 
   goPackagePath = "github.com/deis/deis"; <co xml:id='ex-buildGoPackage-1' />
-  subPackages = [ "client" ]; <co xml:id='ex-buildGoPackage-2' />
 
   src = fetchFromGitHub {
     owner = "deis";
@@ -115,11 +95,7 @@ deis = buildGoPackage rec {
     sha256 = "1qv9lxqx7m18029lj8cw3k7jngvxs4iciwrypdy0gd2nnghc68sw";
   };
 
-  goDeps = ./deps.nix; <co xml:id='ex-buildGoPackage-3' />
-
-  deleteVendor = true; <co xml:id='ex-buildGoPackage-4' />
-
-  buildFlags = [ "--tags" "release" ]; <co xml:id='ex-buildGoPackage-5' />
+  goDeps = ./deps.nix; <co xml:id='ex-buildGoPackage-2' />
 }
 </programlisting>
   </example>
@@ -134,27 +110,9 @@ deis = buildGoPackage rec {
     </callout>
     <callout arearefs='ex-buildGoPackage-2'>
      <para>
-      <varname>subPackages</varname> limits the builder from building child packages that have not been listed. If <varname>subPackages</varname> is not specified, all child packages will be built.
-     </para>
-     <para>
-      In this example only <literal>github.com/deis/deis/client</literal> will be built.
-     </para>
-    </callout>
-    <callout arearefs='ex-buildGoPackage-3'>
-     <para>
       <varname>goDeps</varname> is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate <varname>deps.nix</varname> file for readability. The dependency data structure is described below.
      </para>
     </callout>
-    <callout arearefs='ex-buildGoPackage-4'>
-     <para>
-      <varname>deleteVendor</varname> removes the pre-existing vendor directory. This should only be used if the dependencies included in the vendor folder are broken or incomplete.
-     </para>
-    </callout>
-    <callout arearefs='ex-buildGoPackage-5'>
-     <para>
-      <varname>buildFlags</varname> is a list of flags passed to the go build command.
-     </para>
-    </callout>
    </calloutlist>
   </para>
 
@@ -221,4 +179,70 @@ done
 </screen>
   </para>
  </section>
+
+ <section xml:id="ssec-go-common-attributes">
+  <title>Attributes used by the builders</title>
+
+  <para>
+   Both <link xlink:href="#ssec-go-modules"><varname>buildGoModule</varname></link> and <link xlink:href="#ssec-go-modules"><varname>buildGoPackage</varname></link> can be tweaked to behave slightly differently, if the following attributes are used:
+  </para>
+
+  <variablelist>
+   <varlistentry xml:id="var-go-buildFlagsArray">
+    <term>
+     <varname>buildFlagsArray</varname> and <varname>buildFlags</varname>
+    </term>
+    <listitem>
+     <para>
+      These attributes set build flags supported by <varname>go build</varname>. We recommend using <varname>buildFlagsArray</varname>. The most common use case of these attributes is to make the resulting executable aware of its own version. For example:
+     </para>
+     <example xml:id='ex-goBuildFlags-nospaces'>
+      <title>buildFlagsArray</title>
+<programlisting>
+  buildFlagsArray = [
+    "-ldflags=-X main.Version=${version} -X main.Commit=${version}" <co xml:id='ex-goBuildFlags-1' />
+  ];
+</programlisting>
+     </example>
+     <calloutlist>
+      <callout arearefs='ex-goBuildFlags-1'>
+       <para>
+        Note: single quotes are not needed.
+       </para>
+      </callout>
+     </calloutlist>
+     <example xml:id='ex-goBuildFlags-noarray'>
+      <title>buildFlagsArray</title>
+<programlisting>
+  buildFlagsArray = ''
+    -ldflags=
+    -X main.Version=${version}
+    -X main.Commit=${version}
+  '';
+</programlisting>
+     </example>
+    </listitem>
+   </varlistentry>
+   <varlistentry xml:id="var-go-deleteVendor">
+    <term>
+     <varname>deleteVendor</varname>
+    </term>
+    <listitem>
+     <para>
+      Removes the pre-existing vendor directory. This should only be used if the dependencies included in the vendor folder are broken or incomplete.
+     </para>
+    </listitem>
+   </varlistentry>
+   <varlistentry xml:id="var-go-subPackages">
+    <term>
+     <varname>subPackages</varname>
+    </term>
+    <listitem>
+     <para>
+      Limits the builder from building child packages that have not been listed. If <varname>subPackages</varname> is not specified, all child packages will be built.
+     </para>
+    </listitem>
+   </varlistentry>
+  </variablelist>
+ </section>
 </section>
diff --git a/doc/languages-frameworks/perl.xml b/doc/languages-frameworks/perl.xml
index ff0f350e99c..b017c028f64 100644
--- a/doc/languages-frameworks/perl.xml
+++ b/doc/languages-frameworks/perl.xml
@@ -8,28 +8,28 @@
 
   <para>
    When executing a Perl script, it is possible you get an error such as <literal>./myscript.pl: bad interpreter: /usr/bin/perl: no such file or directory</literal>. This happens when the script expects Perl to be installed at <filename>/usr/bin/perl</filename>, which is not the case when using Perl from nixpkgs. You can fix the script by changing the first line to:
-  <programlisting>
-  #!/usr/bin/env perl
-  </programlisting>
+<programlisting>
+#!/usr/bin/env perl
+</programlisting>
   to take the Perl installation from the <literal>PATH</literal> environment variable, or invoke Perl directly with:
-  <screen>
-  <prompt>$ </prompt>perl ./myscript.pl
-  </screen>
+<screen>
+<prompt>$ </prompt>perl ./myscript.pl
+</screen>
   </para>
 
   <para>
    When the script is using a Perl library that is not installed globally, you might get an error such as <literal>Can't locate DB_File.pm in @INC (you may need to install the DB_File module)</literal>. In that case, you can use <command>nix-shell</command> to start an ad-hoc shell with that library installed, for instance:
-  <screen>
-  <prompt>$ </prompt>nix-shell -p perl perlPackages.DBFile --run ./myscript.pl
-  </screen>
+<screen>
+<prompt>$ </prompt>nix-shell -p perl perlPackages.DBFile --run ./myscript.pl
+</screen>
   </para>
 
   <para>
   If you are always using the script in places where <command>nix-shell</command> is available, you can embed the <command>nix-shell</command> invocation in the shebang like this:
-  <programlisting>
-  #!/usr/bin/env nix-shell
-  #! nix-shell -i perl -p perl perlPackages.DBFile
-  </programlisting>
+<programlisting>
+#!/usr/bin/env nix-shell
+#! nix-shell -i perl -p perl perlPackages.DBFile
+</programlisting>
   </para>
  </section>
 
@@ -44,30 +44,30 @@
   <para>
    Perl packages from CPAN are defined in <link
  xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix"><filename>pkgs/top-level/perl-packages.nix</filename></link>, rather than <filename>pkgs/all-packages.nix</filename>. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from <filename>perl-packages.nix</filename>. However, more complicated packages should be put in a separate file, typically in <filename>pkgs/development/perl-modules</filename>. Here is an example of the former:
- <programlisting>
- ClassC3 = buildPerlPackage rec {
-   name = "Class-C3-0.21";
-   src = fetchurl {
-     url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz";
-     sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
-   };
- };
- </programlisting>
+<programlisting>
+ClassC3 = buildPerlPackage rec {
+  name = "Class-C3-0.21";
+  src = fetchurl {
+    url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz";
+    sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
+  };
+};
+</programlisting>
    Note the use of <literal>mirror://cpan/</literal>, and the <literal>${name}</literal> in the URL definition to ensure that the name attribute is consistent with the source that we’re actually downloading. Perl packages are made available in <filename>all-packages.nix</filename> through the variable <varname>perlPackages</varname>. For instance, if you have a package that needs <varname>ClassC3</varname>, you would typically write
- <programlisting>
- foo = import ../path/to/foo.nix {
-   inherit stdenv fetchurl ...;
-   inherit (perlPackages) ClassC3;
- };
- </programlisting>
+<programlisting>
+foo = import ../path/to/foo.nix {
+  inherit stdenv fetchurl ...;
+  inherit (perlPackages) ClassC3;
+};
+</programlisting>
    in <filename>all-packages.nix</filename>. You can test building a Perl package as follows:
- <screen>
- <prompt>$ </prompt>nix-build -A perlPackages.ClassC3
- </screen>
+<screen>
+<prompt>$ </prompt>nix-build -A perlPackages.ClassC3
+</screen>
    <varname>buildPerlPackage</varname> adds <literal>perl-</literal> to the start of the name attribute, so the package above is actually called <literal>perl-Class-C3-0.21</literal>. So to install it, you can say:
- <screen>
- <prompt>$ </prompt>nix-env -i perl-Class-C3
- </screen>
+<screen>
+<prompt>$ </prompt>nix-env -i perl-Class-C3
+</screen>
    (Of course you can also install using the attribute name: <literal>nix-env -i -A perlPackages.ClassC3</literal>.)
   </para>
 
@@ -94,61 +94,61 @@
 
   <para>
    <varname>buildPerlPackage</varname> is built on top of <varname>stdenv</varname>, so everything can be customised in the usual way. For instance, the <literal>BerkeleyDB</literal> module has a <varname>preConfigure</varname> hook to generate a configuration file used by <filename>Makefile.PL</filename>:
- <programlisting>
- { buildPerlPackage, fetchurl, db }:
-
- buildPerlPackage rec {
-   name = "BerkeleyDB-0.36";
-
-   src = fetchurl {
-     url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz";
-     sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
-   };
-
-   preConfigure = ''
-     echo "LIB = ${db.out}/lib" > config.in
-     echo "INCLUDE = ${db.dev}/include" >> config.in
-   '';
- }
- </programlisting>
+<programlisting>
+{ buildPerlPackage, fetchurl, db }:
+
+buildPerlPackage rec {
+  name = "BerkeleyDB-0.36";
+
+  src = fetchurl {
+    url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz";
+    sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
+  };
+
+  preConfigure = ''
+    echo "LIB = ${db.out}/lib" > config.in
+    echo "INCLUDE = ${db.dev}/include" >> config.in
+  '';
+}
+</programlisting>
   </para>
 
   <para>
    Dependencies on other Perl packages can be specified in the <varname>buildInputs</varname> and <varname>propagatedBuildInputs</varname> attributes. If something is exclusively a build-time dependency, use <varname>buildInputs</varname>; if it’s (also) a runtime dependency, use <varname>propagatedBuildInputs</varname>. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules:
- <programlisting>
- ClassC3Componentised = buildPerlPackage rec {
-   name = "Class-C3-Componentised-1.0004";
-   src = fetchurl {
-     url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz";
-     sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
-   };
-   propagatedBuildInputs = [
-     ClassC3 ClassInspector TestException MROCompat
-   ];
- };
- </programlisting>
+<programlisting>
+ClassC3Componentised = buildPerlPackage rec {
+  name = "Class-C3-Componentised-1.0004";
+  src = fetchurl {
+    url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz";
+    sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
+  };
+  propagatedBuildInputs = [
+    ClassC3 ClassInspector TestException MROCompat
+  ];
+};
+</programlisting>
   </para>
 
   <para>
    On Darwin, if a script has too many <literal>-I<replaceable>dir</replaceable></literal> flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the <literal>shortenPerlShebang</literal> function from the <literal>postInstall</literal> phase:
- <programlisting>
- { stdenv, buildPerlPackage, fetchurl, shortenPerlShebang }:
-
- ImageExifTool = buildPerlPackage {
-   pname = "Image-ExifTool";
-   version = "11.50";
-
-   src = fetchurl {
-     url = "https://www.sno.phy.queensu.ca/~phil/exiftool/Image-ExifTool-11.50.tar.gz";
-     sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3";
-   };
-
-   buildInputs = stdenv.lib.optional stdenv.isDarwin shortenPerlShebang;
-   postInstall = stdenv.lib.optional stdenv.isDarwin ''
-     shortenPerlShebang $out/bin/exiftool
-   '';
- };
- </programlisting>
+<programlisting>
+{ stdenv, buildPerlPackage, fetchurl, shortenPerlShebang }:
+
+ImageExifTool = buildPerlPackage {
+  pname = "Image-ExifTool";
+  version = "11.50";
+
+  src = fetchurl {
+    url = "https://www.sno.phy.queensu.ca/~phil/exiftool/Image-ExifTool-11.50.tar.gz";
+    sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3";
+  };
+
+  buildInputs = stdenv.lib.optional stdenv.isDarwin shortenPerlShebang;
+  postInstall = stdenv.lib.optional stdenv.isDarwin ''
+    shortenPerlShebang $out/bin/exiftool
+  '';
+};
+</programlisting>
    This will remove the <literal>-I</literal> flags from the shebang line, rewrite them in the <literal>use lib</literal> form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place.
   </para>
 
@@ -159,27 +159,27 @@
     Nix expressions for Perl packages can be generated (almost) automatically from CPAN. This is done by the program <command>nix-generate-from-cpan</command>, which can be installed as follows:
    </para>
 
- <screen>
- <prompt>$ </prompt>nix-env -i nix-generate-from-cpan
- </screen>
+<screen>
+<prompt>$ </prompt>nix-env -i nix-generate-from-cpan
+</screen>
 
    <para>
     This program takes a Perl module name, looks it up on CPAN, fetches and unpacks the corresponding package, and prints a Nix expression on standard output. For example:
- <screen>
- <prompt>$ </prompt>nix-generate-from-cpan XML::Simple
-   XMLSimple = buildPerlPackage rec {
-     name = "XML-Simple-2.22";
-     src = fetchurl {
-       url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz";
-       sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
-     };
-     propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
-     meta = {
-       description = "An API for simple XML files";
-       license = with stdenv.lib.licenses; [ artistic1 gpl1Plus ];
-     };
-   };
- </screen>
+<screen>
+<prompt>$ </prompt>nix-generate-from-cpan XML::Simple
+  XMLSimple = buildPerlPackage rec {
+    name = "XML-Simple-2.22";
+    src = fetchurl {
+      url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz";
+      sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
+    };
+    propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
+    meta = {
+      description = "An API for simple XML files";
+      license = with stdenv.lib.licenses; [ artistic1 gpl1Plus ];
+    };
+  };
+</screen>
     The output can be pasted into <filename>pkgs/top-level/perl-packages.nix</filename> or wherever else you need it.
    </para>
   </section>
diff --git a/doc/languages-frameworks/qt.xml b/doc/languages-frameworks/qt.xml
index 8d97de504ad..ec95621d8ff 100644
--- a/doc/languages-frameworks/qt.xml
+++ b/doc/languages-frameworks/qt.xml
@@ -18,7 +18,7 @@ mkDerivation { <co xml:id='qt-default-nix-co-2' />
 
   buildInputs = [ qtbase ]; <co xml:id='qt-default-nix-co-3' />
 }
-   </programlisting>
+</programlisting>
  </example>
 
  <calloutlist>
diff --git a/doc/languages-frameworks/ruby.xml b/doc/languages-frameworks/ruby.xml
index 9b36801fb96..9b579d6804f 100644
--- a/doc/languages-frameworks/ruby.xml
+++ b/doc/languages-frameworks/ruby.xml
@@ -12,14 +12,14 @@
  </para>
 
 <screen>
-<![CDATA[$ cd pkgs/servers/monitoring
-$ mkdir sensu
-$ cd sensu
-$ cat > Gemfile
+<prompt>$ </prompt>cd pkgs/servers/monitoring
+<prompt>$ </prompt>mkdir sensu
+<prompt>$ </prompt>cd sensu
+<prompt>$ </prompt>cat > Gemfile
 source 'https://rubygems.org'
 gem 'sensu'
-$ $(nix-build '<nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic
-$ cat > default.nix
+<prompt>$ </prompt>$(nix-build '&lt;nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic
+<prompt>$ </prompt>cat > default.nix
 { lib, bundlerEnv, ruby }:
 
 bundlerEnv rec {
@@ -37,7 +37,7 @@ bundlerEnv rec {
     maintainers = with maintainers; [ theuni ];
     platforms   = platforms.unix;
   };
-}]]>
+}
 </screen>
 
  <para>
@@ -49,17 +49,16 @@ bundlerEnv rec {
  </para>
 
 <screen>
-<![CDATA[$ cd pkgs/servers/monitoring/sensu
-$ nix-shell -p bundler --run 'bundle lock --update'
-$ nix-shell -p bundix --run 'bundix'
-]]>
+<prompt>$ </prompt>cd pkgs/servers/monitoring/sensu
+<prompt>$ </prompt>nix-shell -p bundler --run 'bundle lock --update'
+<prompt>$ </prompt>nix-shell -p bundix --run 'bundix'
 </screen>
 
  <para>
   For tools written in Ruby - i.e. where the desire is to install a package and then execute e.g. <command>rake</command> at the command line, there is an alternative builder called <literal>bundlerApp</literal>. Set up the <filename>gemset.nix</filename> the same way, and then, for example:
  </para>
 
-<screen>
+<programlisting>
 <![CDATA[{ lib, bundlerApp }:
 
 bundlerApp {
@@ -75,7 +74,7 @@ bundlerApp {
     platforms   = platforms.unix;
   };
 }]]>
-</screen>
+</programlisting>
 
  <para>
   The chief advantage of <literal>bundlerApp</literal> over <literal>bundlerEnv</literal> is the executables introduced in the environment are precisely those selected in the <literal>exes</literal> list, as opposed to <literal>bundlerEnv</literal> which adds all the executables made available by gems in the gemset, which can mean e.g. <command>rspec</command> or <command>rake</command> in unpredictable versions available from various packages.
diff --git a/doc/languages-frameworks/texlive.xml b/doc/languages-frameworks/texlive.xml
index a581ec5911c..141c46e5a62 100644
--- a/doc/languages-frameworks/texlive.xml
+++ b/doc/languages-frameworks/texlive.xml
@@ -44,11 +44,11 @@ texlive.combine {
    <listitem>
     <para>
      You can list packages e.g. by <command>nix repl</command>.
-<programlisting><![CDATA[
-$ nix repl
-nix-repl> :l <nixpkgs>
-nix-repl> texlive.collection-<TAB>
-]]></programlisting>
+<programlisting>
+<prompt>$ </prompt>nix repl
+<prompt>nix-repl> </prompt>:l &lt;nixpkgs>
+<prompt>nix-repl> </prompt>texlive.collection-<keycap function="tab" />
+</programlisting>
     </para>
    </listitem>
    <listitem>
diff --git a/doc/manual.xml b/doc/manual.xml
index 1f69872d2a7..4ca497e234e 100644
--- a/doc/manual.xml
+++ b/doc/manual.xml
@@ -1,7 +1,7 @@
 <book xmlns="http://docbook.org/ns/docbook"
       xmlns:xi="http://www.w3.org/2001/XInclude">
  <info>
-  <title>Nixpkgs Users and Contributors Guide</title>
+  <title>Nixpkgs Manual</title>
   <subtitle>Version <xi:include href=".version" parse="text" />
   </subtitle>
  </info>
diff --git a/doc/stdenv/multiple-output.xml b/doc/stdenv/multiple-output.xml
index 0f177ec719f..20658918db7 100644
--- a/doc/stdenv/multiple-output.xml
+++ b/doc/stdenv/multiple-output.xml
@@ -67,7 +67,7 @@
     <para>
      <command>nix-env</command> silenty disregards the outputs selected by the user, and instead installs the outputs from <varname>meta.outputsToInstall</varname>. For example,
     </para>
-<programlisting>$ nix-env -iA nixpkgs.coreutils.info</programlisting>
+<screen><prompt>$ </prompt>nix-env -iA nixpkgs.coreutils.info</screen>
     <para>
      installs the <literal>"out"</literal> output (<varname>coreutils.meta.outputsToInstall</varname> is <literal>[ "out" ]</literal>) instead of the requested <literal>"info"</literal>.
     </para>
diff --git a/doc/using/configuration.xml b/doc/using/configuration.xml
index b670f78f28b..3e21b0e2284 100644
--- a/doc/using/configuration.xml
+++ b/doc/using/configuration.xml
@@ -66,7 +66,7 @@
    <listitem>
     <para>
      For allowing the build of a broken package once, you can use an environment variable for a single invocation of the nix tools:
-<programlisting>$ export NIXPKGS_ALLOW_BROKEN=1</programlisting>
+<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_BROKEN=1</screen>
     </para>
    </listitem>
    <listitem>
@@ -92,7 +92,7 @@
    <listitem>
     <para>
      For allowing the build of an unsupported package once, you can use an environment variable for a single invocation of the nix tools:
-<programlisting>$ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1</programlisting>
+<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1</screen>
     </para>
    </listitem>
    <listitem>
@@ -122,7 +122,7 @@
    <listitem>
     <para>
      To temporarily allow all unfree packages, you can use an environment variable for a single invocation of the nix tools:
-<programlisting>$ export NIXPKGS_ALLOW_UNFREE=1</programlisting>
+<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_UNFREE=1</screen>
     </para>
    </listitem>
    <listitem>
@@ -187,7 +187,7 @@
    <listitem>
     <para>
      To temporarily allow all insecure packages, you can use an environment variable for a single invocation of the nix tools:
-<programlisting>$ export NIXPKGS_ALLOW_INSECURE=1</programlisting>
+<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_INSECURE=1</screen>
     </para>
    </listitem>
    <listitem>
diff --git a/doc/using/overlays.xml b/doc/using/overlays.xml
index f6e02b969ea..4937e950885 100644
--- a/doc/using/overlays.xml
+++ b/doc/using/overlays.xml
@@ -240,7 +240,7 @@ self: super:
     lapackProvider = self.mkl;
   }
 }
-     </programlisting>
+</programlisting>
      <para>
        This overlay uses Intel’s MKL library for both BLAS and LAPACK
        interfaces. Note that the same can be accomplished at runtime
@@ -248,9 +248,9 @@ self: super:
        <literal>libblas.so.3</literal> and
        <literal>liblapack.so.3</literal>. For instance:
      </para>
-     <programlisting>
-$ LD_LIBRARY_PATH=$(nix-build -A mkl)/lib:$LD_LIBRARY_PATH nix-shell -p octave --run octave
-     </programlisting>
+<screen>
+<prompt>$ </prompt>LD_LIBRARY_PATH=$(nix-build -A mkl)/lib:$LD_LIBRARY_PATH nix-shell -p octave --run octave
+</screen>
      <para>
        Intel MKL requires an <literal>openmp</literal> implementation
        when running with multiple processors. By default,
@@ -288,7 +288,7 @@ assert (!blas.isILP64) &amp;&amp; (!lapack.isILP64);
 stdenv.mkDerivation {
   ...
 }
-     </programlisting>
+</programlisting>
    </section>
  </section>
 </chapter>