Merge commit '7e567a3d092b7de69cdf5deaeb8d9526de230916'

# Conflicts:
#	nixpkgs/pkgs/top-level/all-packages.nix

13 files changed, 409 insertions, 227 deletions

diff --git a/nixpkgs/nixos/doc/manual/administration/boot-problems.section.md b/nixpkgs/nixos/doc/manual/administration/boot-problems.section.md
new file mode 100644
index 000000000000..eb9209602a32
--- /dev/null
+++ b/nixpkgs/nixos/doc/manual/administration/boot-problems.section.md
@@ -0,0 +1,35 @@
+# Boot Problems {#sec-boot-problems}
+
+If NixOS fails to boot, there are a number of kernel command line parameters that may help you to identify or fix the issue. You can add these parameters in the GRUB boot menu by pressing “e” to modify the selected boot entry and editing the line starting with `linux`. The following are some useful kernel command line parameters that are recognised by the NixOS boot scripts or by systemd:
+
+`boot.shell_on_fail`
+
+: Allows the user to start a root shell if something goes wrong in stage 1 of the boot process (the initial ramdisk). This is disabled by default because there is no authentication for the root shell.
+
+`boot.debug1`
+
+: Start an interactive shell in stage 1 before anything useful has been done. That is, no modules have been loaded and no file systems have been mounted, except for `/proc` and `/sys`.
+
+`boot.debug1devices`
+
+: Like `boot.debug1`, but runs stage1 until kernel modules are loaded and device nodes are created. This may help with e.g. making the keyboard work.
+
+`boot.debug1mounts`
+
+: Like `boot.debug1` or `boot.debug1devices`, but runs stage1 until all filesystems that are mounted during initrd are mounted (see [neededForBoot](#opt-fileSystems._name_.neededForBoot)). As a motivating example, this could be useful if you've forgotten to set [neededForBoot](options.html#opt-fileSystems._name_.neededForBoot) on a file system.
+
+`boot.trace`
+
+: Print every shell command executed by the stage 1 and 2 boot scripts.
+
+`single`
+
+: Boot into rescue mode (a.k.a. single user mode). This will cause systemd to start nothing but the unit `rescue.target`, which runs `sulogin` to prompt for the root password and start a root login shell. Exiting the shell causes the system to continue with the normal boot process.
+
+`systemd.log_level=debug` `systemd.log_target=console`
+
+: Make systemd very verbose and send log messages to the console instead of the journal. For more parameters recognised by systemd, see systemd(1).
+
+Notice that for `boot.shell_on_fail`, `boot.debug1`, `boot.debug1devices`, and `boot.debug1mounts`, if you did **not** select "start the new shell as pid 1", and you `exit` from the new shell, boot will proceed normally from the point where it failed, as if you'd chosen "ignore the error and continue".
+
+If no login prompts or X11 login screens appear (e.g. due to hanging dependencies), you can press Alt+ArrowUp. If you’re lucky, this will start rescue mode (described above). (Also note that since most units have a 90-second timeout before systemd gives up on them, the `agetty` login prompts should appear eventually unless something is very wrong.)
diff --git a/nixpkgs/nixos/doc/manual/administration/boot-problems.xml b/nixpkgs/nixos/doc/manual/administration/boot-problems.xml
deleted file mode 100644
index e0f662840101..000000000000
--- a/nixpkgs/nixos/doc/manual/administration/boot-problems.xml
+++ /dev/null
@@ -1,126 +0,0 @@
-<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-boot-problems">
- <title>Boot Problems</title>
-
- <para>
-  If NixOS fails to boot, there are a number of kernel command line parameters
-  that may help you to identify or fix the issue. You can add these parameters
-  in the GRUB boot menu by pressing “e” to modify the selected boot entry
-  and editing the line starting with <literal>linux</literal>. The following
-  are some useful kernel command line parameters that are recognised by the
-  NixOS boot scripts or by systemd:
-  <variablelist>
-   <varlistentry>
-    <term>
-     <literal>boot.shell_on_fail</literal>
-    </term>
-    <listitem>
-     <para>
-      Allows the user to start a root shell if something goes wrong in stage 1
-      of the boot process (the initial ramdisk). This is disabled by default
-      because there is no authentication for the root shell.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <literal>boot.debug1</literal>
-    </term>
-    <listitem>
-     <para>
-      Start an interactive shell in stage 1 before anything useful has been
-      done. That is, no modules have been loaded and no file systems have been
-      mounted, except for <filename>/proc</filename> and
-      <filename>/sys</filename>.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <literal>boot.debug1devices</literal>
-    </term>
-    <listitem>
-     <para>
-      Like <literal>boot.debug1</literal>, but runs stage1 until kernel modules are loaded and device nodes are created.
-      This may help with e.g. making the keyboard work.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <literal>boot.debug1mounts</literal>
-    </term>
-    <listitem>
-     <para>
-      Like <literal>boot.debug1</literal> or
-      <literal>boot.debug1devices</literal>, but runs stage1 until all
-      filesystems that are mounted during initrd are mounted (see
-      <option><link linkend="opt-fileSystems._name_.neededForBoot">neededForBoot</link></option>
-      ). As a motivating example, this could be useful if you've forgotten to set
-      <option><link linkend="opt-fileSystems._name_.neededForBoot">neededForBoot</link></option>
-      on a file system.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <literal>boot.trace</literal>
-    </term>
-    <listitem>
-     <para>
-      Print every shell command executed by the stage 1 and 2 boot scripts.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <literal>single</literal>
-    </term>
-    <listitem>
-     <para>
-      Boot into rescue mode (a.k.a. single user mode). This will cause systemd
-      to start nothing but the unit <literal>rescue.target</literal>, which
-      runs <command>sulogin</command> to prompt for the root password and start
-      a root login shell. Exiting the shell causes the system to continue with
-      the normal boot process.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <literal>systemd.log_level=debug systemd.log_target=console</literal>
-    </term>
-    <listitem>
-     <para>
-      Make systemd very verbose and send log messages to the console instead of
-      the journal.
-     </para>
-    </listitem>
-   </varlistentry>
-  </variablelist>
-  For more parameters recognised by systemd, see <citerefentry>
-  <refentrytitle>systemd</refentrytitle>
-  <manvolnum>1</manvolnum></citerefentry>.
- </para>
-
- <para>
-  Notice that for <literal>boot.shell_on_fail</literal>,
-  <literal>boot.debug1</literal>, <literal>boot.debug1devices</literal>, and
-  <literal>boot.debug1mounts</literal>, if you did <emphasis>not</emphasis>
-  select "start the new shell as pid 1", and you <literal>exit</literal> from
-  the new shell, boot will proceed normally from the point where it failed, as
-  if you'd chosen "ignore the error and continue".
- </para>
-
- <para>
-  If no login prompts or X11 login screens appear (e.g. due to hanging
-  dependencies), you can press Alt+ArrowUp. If you’re lucky, this will start
-  rescue mode (described above). (Also note that since most units have a
-  90-second timeout before systemd gives up on them, the
-  <command>agetty</command> login prompts should appear eventually unless
-  something is very wrong.)
- </para>
-</section>
diff --git a/nixpkgs/nixos/doc/manual/administration/troubleshooting.xml b/nixpkgs/nixos/doc/manual/administration/troubleshooting.xml
index 6496e7bde387..b055acadacf3 100644
--- a/nixpkgs/nixos/doc/manual/administration/troubleshooting.xml
+++ b/nixpkgs/nixos/doc/manual/administration/troubleshooting.xml
@@ -8,7 +8,7 @@
   This chapter describes solutions to common problems you might encounter when
   you manage your NixOS system.
  </para>
- <xi:include href="boot-problems.xml" />
+ <xi:include href="../from_md/administration/boot-problems.section.xml" />
  <xi:include href="maintenance-mode.xml" />
  <xi:include href="rollback.xml" />
  <xi:include href="store-corruption.xml" />
diff --git a/nixpkgs/nixos/doc/manual/configuration/x-windows.xml b/nixpkgs/nixos/doc/manual/configuration/x-windows.xml
index e72193897068..315ed3acf971 100644
--- a/nixpkgs/nixos/doc/manual/configuration/x-windows.xml
+++ b/nixpkgs/nixos/doc/manual/configuration/x-windows.xml
@@ -191,9 +191,12 @@
   <para>
    GTK themes can be installed either to user profile or system-wide (via
    <literal>environment.systemPackages</literal>). To make Qt 5 applications
-   look similar to GTK2 ones, you can install <literal>qt5.qtbase.gtk</literal>
-   package into your system environment. It should work for all Qt 5 library
-   versions.
+   look similar to GTK ones, you can use the following configuration:
+<programlisting>
+<xref linkend="opt-qt5.enable"/> = true;
+<xref linkend="opt-qt5.platformTheme"/> = "gtk2";
+<xref linkend="opt-qt5.style"/> = "gtk2";
+</programlisting>
   </para>
  </simplesect>
  <simplesect xml:id="custom-xkb-layouts">
diff --git a/nixpkgs/nixos/doc/manual/development/assertions.section.md b/nixpkgs/nixos/doc/manual/development/assertions.section.md
new file mode 100644
index 000000000000..cc6d81e56990
--- /dev/null
+++ b/nixpkgs/nixos/doc/manual/development/assertions.section.md
@@ -0,0 +1,40 @@
+# Warnings and Assertions {#sec-assertions}
+
+When configuration problems are detectable in a module, it is a good idea to write an assertion or warning. Doing so provides clear feedback to the user and prevents errors after the build.
+
+Although Nix has the `abort` and `builtins.trace` [functions](https://nixos.org/nix/manual/#ssec-builtins) to perform such tasks, they are not ideally suited for NixOS modules. Instead of these functions, you can declare your warnings and assertions using the NixOS module system.
+
+## Warnings {#sec-assertions-warnings}
+
+This is an example of using `warnings`.
+
+```nix
+{ config, lib, ... }:
+{
+  config = lib.mkIf config.services.foo.enable {
+    warnings =
+      if config.services.foo.bar
+      then [ ''You have enabled the bar feature of the foo service.
+               This is known to cause some specific problems in certain situations.
+               '' ]
+      else [];
+  }
+}
+```
+
+## Assertions {#sec-assertions-assetions}
+
+This example, extracted from the [`syslogd` module](https://github.com/NixOS/nixpkgs/blob/release-17.09/nixos/modules/services/logging/syslogd.nix) shows how to use `assertions`. Since there can only be one active syslog daemon at a time, an assertion is useful to prevent such a broken system from being built.
+
+```nix
+{ config, lib, ... }:
+{
+  config = lib.mkIf config.services.syslogd.enable {
+    assertions =
+      [ { assertion = !config.services.rsyslogd.enable;
+          message = "rsyslogd conflicts with syslogd";
+        }
+      ];
+  }
+}
+```
diff --git a/nixpkgs/nixos/doc/manual/development/assertions.xml b/nixpkgs/nixos/doc/manual/development/assertions.xml
deleted file mode 100644
index 32f90cf2e7c4..000000000000
--- a/nixpkgs/nixos/doc/manual/development/assertions.xml
+++ /dev/null
@@ -1,74 +0,0 @@
-<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-assertions">
- <title>Warnings and Assertions</title>
-
- <para>
-  When configuration problems are detectable in a module, it is a good idea to
-  write an assertion or warning. Doing so provides clear feedback to the user
-  and prevents errors after the build.
- </para>
-
- <para>
-  Although Nix has the <literal>abort</literal> and
-  <literal>builtins.trace</literal>
-  <link xlink:href="https://nixos.org/nix/manual/#ssec-builtins">functions</link>
-  to perform such tasks, they are not ideally suited for NixOS modules. Instead
-  of these functions, you can declare your warnings and assertions using the
-  NixOS module system.
- </para>
-
- <section xml:id="sec-assertions-warnings">
-  <title>Warnings</title>
-
-  <para>
-   This is an example of using <literal>warnings</literal>.
-  </para>
-
-<programlisting>
-<![CDATA[
-{ config, lib, ... }:
-{
-  config = lib.mkIf config.services.foo.enable {
-    warnings =
-      if config.services.foo.bar
-      then [ ''You have enabled the bar feature of the foo service.
-               This is known to cause some specific problems in certain situations.
-               '' ]
-      else [];
-  }
-}
-]]>
-</programlisting>
- </section>
-
- <section xml:id="sec-assertions-assertions">
-  <title>Assertions</title>
-
-  <para>
-   This example, extracted from the
-   <link xlink:href="https://github.com/NixOS/nixpkgs/blob/release-17.09/nixos/modules/services/logging/syslogd.nix">
-   <literal>syslogd</literal> module </link> shows how to use
-   <literal>assertions</literal>. Since there can only be one active syslog
-   daemon at a time, an assertion is useful to prevent such a broken system
-   from being built.
-  </para>
-
-<programlisting>
-<![CDATA[
-{ config, lib, ... }:
-{
-  config = lib.mkIf config.services.syslogd.enable {
-    assertions =
-      [ { assertion = !config.services.rsyslogd.enable;
-          message = "rsyslogd conflicts with syslogd";
-        }
-      ];
-  }
-}
-]]>
-</programlisting>
- </section>
-</section>
diff --git a/nixpkgs/nixos/doc/manual/development/writing-modules.xml b/nixpkgs/nixos/doc/manual/development/writing-modules.xml
index fad4637f51f0..04497db77b89 100644
--- a/nixpkgs/nixos/doc/manual/development/writing-modules.xml
+++ b/nixpkgs/nixos/doc/manual/development/writing-modules.xml
@@ -182,7 +182,7 @@ in {
  <xi:include href="option-declarations.xml" />
  <xi:include href="option-types.xml" />
  <xi:include href="option-def.xml" />
- <xi:include href="assertions.xml" />
+ <xi:include href="../from_md/development/assertions.section.xml" />
  <xi:include href="meta-attributes.xml" />
  <xi:include href="importing-modules.xml" />
  <xi:include href="replace-modules.xml" />
diff --git a/nixpkgs/nixos/doc/manual/from_md/administration/boot-problems.section.xml b/nixpkgs/nixos/doc/manual/from_md/administration/boot-problems.section.xml
new file mode 100644
index 000000000000..b484d075818a
--- /dev/null
+++ b/nixpkgs/nixos/doc/manual/from_md/administration/boot-problems.section.xml
@@ -0,0 +1,127 @@
+<section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-boot-problems">
+  <title>Boot Problems</title>
+  <para>
+    If NixOS fails to boot, there are a number of kernel command line
+    parameters that may help you to identify or fix the issue. You can
+    add these parameters in the GRUB boot menu by pressing “e” to modify
+    the selected boot entry and editing the line starting with
+    <literal>linux</literal>. The following are some useful kernel
+    command line parameters that are recognised by the NixOS boot
+    scripts or by systemd:
+  </para>
+  <variablelist>
+    <varlistentry>
+      <term>
+        <literal>boot.shell_on_fail</literal>
+      </term>
+      <listitem>
+        <para>
+          Allows the user to start a root shell if something goes wrong
+          in stage 1 of the boot process (the initial ramdisk). This is
+          disabled by default because there is no authentication for the
+          root shell.
+        </para>
+      </listitem>
+    </varlistentry>
+    <varlistentry>
+      <term>
+        <literal>boot.debug1</literal>
+      </term>
+      <listitem>
+        <para>
+          Start an interactive shell in stage 1 before anything useful
+          has been done. That is, no modules have been loaded and no
+          file systems have been mounted, except for
+          <literal>/proc</literal> and <literal>/sys</literal>.
+        </para>
+      </listitem>
+    </varlistentry>
+    <varlistentry>
+      <term>
+        <literal>boot.debug1devices</literal>
+      </term>
+      <listitem>
+        <para>
+          Like <literal>boot.debug1</literal>, but runs stage1 until
+          kernel modules are loaded and device nodes are created. This
+          may help with e.g. making the keyboard work.
+        </para>
+      </listitem>
+    </varlistentry>
+    <varlistentry>
+      <term>
+        <literal>boot.debug1mounts</literal>
+      </term>
+      <listitem>
+        <para>
+          Like <literal>boot.debug1</literal> or
+          <literal>boot.debug1devices</literal>, but runs stage1 until
+          all filesystems that are mounted during initrd are mounted
+          (see
+          <link linkend="opt-fileSystems._name_.neededForBoot">neededForBoot</link>).
+          As a motivating example, this could be useful if you’ve
+          forgotten to set
+          <link xlink:href="options.html#opt-fileSystems._name_.neededForBoot">neededForBoot</link>
+          on a file system.
+        </para>
+      </listitem>
+    </varlistentry>
+    <varlistentry>
+      <term>
+        <literal>boot.trace</literal>
+      </term>
+      <listitem>
+        <para>
+          Print every shell command executed by the stage 1 and 2 boot
+          scripts.
+        </para>
+      </listitem>
+    </varlistentry>
+    <varlistentry>
+      <term>
+        <literal>single</literal>
+      </term>
+      <listitem>
+        <para>
+          Boot into rescue mode (a.k.a. single user mode). This will
+          cause systemd to start nothing but the unit
+          <literal>rescue.target</literal>, which runs
+          <literal>sulogin</literal> to prompt for the root password and
+          start a root login shell. Exiting the shell causes the system
+          to continue with the normal boot process.
+        </para>
+      </listitem>
+    </varlistentry>
+    <varlistentry>
+      <term>
+        <literal>systemd.log_level=debug</literal>
+        <literal>systemd.log_target=console</literal>
+      </term>
+      <listitem>
+        <para>
+          Make systemd very verbose and send log messages to the console
+          instead of the journal. For more parameters recognised by
+          systemd, see systemd(1).
+        </para>
+      </listitem>
+    </varlistentry>
+  </variablelist>
+  <para>
+    Notice that for <literal>boot.shell_on_fail</literal>,
+    <literal>boot.debug1</literal>,
+    <literal>boot.debug1devices</literal>, and
+    <literal>boot.debug1mounts</literal>, if you did
+    <emphasis role="strong">not</emphasis> select <quote>start the new
+    shell as pid 1</quote>, and you <literal>exit</literal> from the new
+    shell, boot will proceed normally from the point where it failed, as
+    if you’d chosen <quote>ignore the error and continue</quote>.
+  </para>
+  <para>
+    If no login prompts or X11 login screens appear (e.g. due to hanging
+    dependencies), you can press Alt+ArrowUp. If you’re lucky, this will
+    start rescue mode (described above). (Also note that since most
+    units have a 90-second timeout before systemd gives up on them, the
+    <literal>agetty</literal> login prompts should appear eventually
+    unless something is very wrong.)
+  </para>
+</section>
diff --git a/nixpkgs/nixos/doc/manual/from_md/development/assertions.section.xml b/nixpkgs/nixos/doc/manual/from_md/development/assertions.section.xml
new file mode 100644
index 000000000000..0844d484d60f
--- /dev/null
+++ b/nixpkgs/nixos/doc/manual/from_md/development/assertions.section.xml
@@ -0,0 +1,58 @@
+<section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-assertions">
+  <title>Warnings and Assertions</title>
+  <para>
+    When configuration problems are detectable in a module, it is a good
+    idea to write an assertion or warning. Doing so provides clear
+    feedback to the user and prevents errors after the build.
+  </para>
+  <para>
+    Although Nix has the <literal>abort</literal> and
+    <literal>builtins.trace</literal>
+    <link xlink:href="https://nixos.org/nix/manual/#ssec-builtins">functions</link>
+    to perform such tasks, they are not ideally suited for NixOS
+    modules. Instead of these functions, you can declare your warnings
+    and assertions using the NixOS module system.
+  </para>
+  <section xml:id="sec-assertions-warnings">
+    <title>Warnings</title>
+    <para>
+      This is an example of using <literal>warnings</literal>.
+    </para>
+    <programlisting language="bash">
+{ config, lib, ... }:
+{
+  config = lib.mkIf config.services.foo.enable {
+    warnings =
+      if config.services.foo.bar
+      then [ ''You have enabled the bar feature of the foo service.
+               This is known to cause some specific problems in certain situations.
+               '' ]
+      else [];
+  }
+}
+</programlisting>
+  </section>
+  <section xml:id="sec-assertions-assetions">
+    <title>Assertions</title>
+    <para>
+      This example, extracted from the
+      <link xlink:href="https://github.com/NixOS/nixpkgs/blob/release-17.09/nixos/modules/services/logging/syslogd.nix"><literal>syslogd</literal>
+      module</link> shows how to use <literal>assertions</literal>.
+      Since there can only be one active syslog daemon at a time, an
+      assertion is useful to prevent such a broken system from being
+      built.
+    </para>
+    <programlisting language="bash">
+{ config, lib, ... }:
+{
+  config = lib.mkIf config.services.syslogd.enable {
+    assertions =
+      [ { assertion = !config.services.rsyslogd.enable;
+          message = &quot;rsyslogd conflicts with syslogd&quot;;
+        }
+      ];
+  }
+}
+</programlisting>
+  </section>
+</section>
diff --git a/nixpkgs/nixos/doc/manual/from_md/release-notes/rl-2111.section.xml b/nixpkgs/nixos/doc/manual/from_md/release-notes/rl-2111.section.xml
index 070e7b142937..2c7935078e34 100644
--- a/nixpkgs/nixos/doc/manual/from_md/release-notes/rl-2111.section.xml
+++ b/nixpkgs/nixos/doc/manual/from_md/release-notes/rl-2111.section.xml
@@ -1,5 +1,5 @@
-<section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="release-21.11">
-  <title>Release 21.11 (<quote>?</quote>, 2021.11/??)</title>
+<section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-release-21.11">
+  <title>Release 21.11 (“?”, 2021.11/??)</title>
   <para>
     In addition to numerous new and upgraded packages, this release has
     the following highlights:
@@ -12,7 +12,7 @@
       </para>
     </listitem>
   </itemizedlist>
-  <section xml:id="highlights">
+  <section xml:id="sec-release-21.11-highlights">
     <title>Highlights</title>
     <itemizedlist spacing="compact">
       <listitem>
@@ -22,7 +22,7 @@
       </listitem>
     </itemizedlist>
   </section>
-  <section xml:id="new-services">
+  <section xml:id="sec-release-21.11-new-services">
     <title>New Services</title>
     <itemizedlist>
       <listitem>
@@ -40,9 +40,17 @@
           <link xlink:href="options.html#opt-services.sourcehut.enable">services.sourcehut</link>.
         </para>
       </listitem>
+      <listitem>
+        <para>
+          <link xlink:href="https://download.pureftpd.org/pub/ucarp/README">ucarp</link>,
+          an userspace implementation of the Common Address Redundancy
+          Protocol (CARP). Available as
+          <link xlink:href="options.html#opt-networking.ucarp.enable">networking.ucarp</link>.
+        </para>
+      </listitem>
     </itemizedlist>
   </section>
-  <section xml:id="backward-incompatibilities">
+  <section xml:id="sec-release-21.11-incompatibilities">
     <title>Backward Incompatibilities</title>
     <itemizedlist>
       <listitem>
@@ -226,9 +234,90 @@
           </listitem>
         </itemizedlist>
       </listitem>
+      <listitem>
+        <para>
+          <literal>programs.x2goserver</literal> is now
+          <literal>services.x2goserver</literal>
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          The following dotnet-related packages have been removed for
+          being unmaintaned. Please use <literal>fetchNuGet</literal>
+          for specific packages.
+        </para>
+        <itemizedlist spacing="compact">
+          <listitem>
+            <para>
+              Autofac
+            </para>
+          </listitem>
+          <listitem>
+            <para>
+              SystemValueTuple
+            </para>
+          </listitem>
+          <listitem>
+            <para>
+              MicrosoftDiaSymReader
+            </para>
+          </listitem>
+          <listitem>
+            <para>
+              MicrosoftDiaSymReaderPortablePdb
+            </para>
+          </listitem>
+          <listitem>
+            <para>
+              SystemCollectionsImmutable
+            </para>
+          </listitem>
+          <listitem>
+            <para>
+              SystemCollectionsImmutable131
+            </para>
+          </listitem>
+          <listitem>
+            <para>
+              SystemReflectionMetadata
+            </para>
+          </listitem>
+          <listitem>
+            <para>
+              NUnit350
+            </para>
+          </listitem>
+          <listitem>
+            <para>
+              Deedle
+            </para>
+          </listitem>
+          <listitem>
+            <para>
+              ExcelDna
+            </para>
+          </listitem>
+          <listitem>
+            <para>
+              GitVersionTree
+            </para>
+          </listitem>
+          <listitem>
+            <para>
+              NDeskOptions
+            </para>
+          </listitem>
+        </itemizedlist>
+      </listitem>
+      <listitem>
+        <para>
+          The <literal>antlr</literal> package now defaults to the 4.x
+          release instead of the old 2.7.7 version.
+        </para>
+      </listitem>
     </itemizedlist>
   </section>
-  <section xml:id="other-notable-changes">
+  <section xml:id="sec-release-21.11-notable-changes">
     <title>Other Notable Changes</title>
     <para>
     </para>
diff --git a/nixpkgs/nixos/doc/manual/md-to-db.sh b/nixpkgs/nixos/doc/manual/md-to-db.sh
index fc4be7da22ba..7949b42e8d81 100755
--- a/nixpkgs/nixos/doc/manual/md-to-db.sh
+++ b/nixpkgs/nixos/doc/manual/md-to-db.sh
@@ -8,25 +8,31 @@
 DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
 pushd $DIR
 
+# NOTE: Keep in sync with Nixpkgs manual (/doc/Makefile).
+# TODO: Remove raw-attribute when we can get rid of DocBook altogether.
+pandoc_commonmark_enabled_extensions=+attributes+fenced_divs+footnotes+bracketed_spans+definition_lists+pipe_tables+raw_attribute
+pandoc_flags=(
+  # media extraction and diagram-generator.lua not needed
+  "--lua-filter=$DIR/../../../doc/labelless-link-is-xref.lua"
+  -f "commonmark${pandoc_commonmark_enabled_extensions}+smart"
+  -t docbook
+)
+
 OUT="$DIR/from_md"
 mapfile -t MD_FILES < <(find . -type f -regex '.*\.md$')
 
 for mf in ${MD_FILES[*]}; do
   if [ "${mf: -11}" == ".section.md" ]; then
     mkdir -p $(dirname "$OUT/$mf")
-    pandoc "$mf" -t docbook \
-      --extract-media=media \
-      -f markdown+smart \
-    | cat  > "$OUT/${mf%".section.md"}.section.xml"
+    pandoc "$mf" "${pandoc_flags[@]}" \
+      -o "$OUT/${mf%".section.md"}.section.xml"
   fi
 
   if [ "${mf: -11}" == ".chapter.md" ]; then
     mkdir -p $(dirname "$OUT/$mf")
-    pandoc "$mf" -t docbook \
+    pandoc "$mf" "${pandoc_flags[@]}" \
       --top-level-division=chapter \
-      --extract-media=media \
-      -f markdown+smart \
-    | cat  > "$OUT/${mf%".chapter.md"}.chapter.xml"
+      -o "$OUT/${mf%".chapter.md"}.chapter.xml"
   fi
 done
 
diff --git a/nixpkgs/nixos/doc/manual/release-notes/rl-2105.xml b/nixpkgs/nixos/doc/manual/release-notes/rl-2105.xml
index 54abbb6e38e4..4ecdd23d2dea 100644
--- a/nixpkgs/nixos/doc/manual/release-notes/rl-2105.xml
+++ b/nixpkgs/nixos/doc/manual/release-notes/rl-2105.xml
@@ -113,11 +113,11 @@
   <itemizedlist>
    <listitem>
     <para>
-     <link xlink:href="https://www.gnuradio.org/">GNURadio</link> 3.8 was
+     <link xlink:href="https://www.gnuradio.org/">GNURadio</link> 3.8 and 3.9 were
      <link xlink:href="https://github.com/NixOS/nixpkgs/issues/82263">finally</link>
      packaged, along with a rewrite to the Nix expressions, allowing users to
      override the features upstream supports selecting to compile or not to.
-     Additionally, the attribute <code>gnuradio</code> and <code>gnuradio3_7</code>
+     Additionally, the attribute <code>gnuradio</code> (3.9), <code>gnuradio3_8</code> and <code>gnuradio3_7</code>
      now point to an externally wrapped by default derivations, that allow you to
      also add `extraPythonPackages` to the Python interpreter used by GNURadio.
      Missing environmental variables needed for operational GUI were also added
@@ -853,7 +853,7 @@ environment.systemPackages = [
    <listitem>
     <para>
      <link xlink:href="https://kodi.tv/">Kodi</link> has been updated to version 19.1 "Matrix". See
-     the <link xlink:href="https://kodi.tv/article/kodi-190-matrix-release">announcement</link> for
+     the <link xlink:href="https://kodi.tv/article/kodi-19-0-matrix-release">announcement</link> for
      further details.
     </para>
    </listitem>
diff --git a/nixpkgs/nixos/doc/manual/release-notes/rl-2111.section.md b/nixpkgs/nixos/doc/manual/release-notes/rl-2111.section.md
index c1fde5a032b4..e97aed4ccf2a 100644
--- a/nixpkgs/nixos/doc/manual/release-notes/rl-2111.section.md
+++ b/nixpkgs/nixos/doc/manual/release-notes/rl-2111.section.md
@@ -1,14 +1,14 @@
-# Release 21.11 (“?”, 2021.11/??) {#release-21.11}
+# Release 21.11 (“?”, 2021.11/??) {#sec-release-21.11}
 
 In addition to numerous new and upgraded packages, this release has the following highlights:
 
 * Support is planned until the end of April 2022, handing over to 22.05.
 
-## Highlights
+## Highlights {#sec-release-21.11-highlights}
 
 * PHP now defaults to PHP 8.0, updated from 7.4.
 
-## New Services
+## New Services {#sec-release-21.11-new-services}
 
 * [geoipupdate](https://github.com/maxmind/geoipupdate), a GeoIP
   database updater from MaxMind. Available as
@@ -18,7 +18,11 @@ In addition to numerous new and upgraded packages, this release has the followin
   development. Available as
   [services.sourcehut](options.html#opt-services.sourcehut.enable).
 
-## Backward Incompatibilities
+* [ucarp](https://download.pureftpd.org/pub/ucarp/README), an userspace
+  implementation of the Common Address Redundancy Protocol (CARP). Available as
+  [networking.ucarp](options.html#opt-networking.ucarp.enable).
+
+## Backward Incompatibilities {#sec-release-21.11-incompatibilities}
 
 * The `staticjinja` package has been upgraded from 1.0.4 to 2.0.0
 
@@ -64,4 +68,24 @@ In addition to numerous new and upgraded packages, this release has the followin
   - ExcelDnaRegistration
   - MathNetNumerics
 
-## Other Notable Changes
+* `programs.x2goserver` is now `services.x2goserver`
+
+* The following dotnet-related packages have been removed for being unmaintaned.
+  Please use `fetchNuGet` for specific packages.
+  - Autofac
+  - SystemValueTuple
+  - MicrosoftDiaSymReader
+  - MicrosoftDiaSymReaderPortablePdb
+  - SystemCollectionsImmutable
+  - SystemCollectionsImmutable131
+  - SystemReflectionMetadata
+  - NUnit350
+  - Deedle
+  - ExcelDna
+  - GitVersionTree
+  - NDeskOptions
+
+* The `antlr` package now defaults to the 4.x release instead of the
+  old 2.7.7 version.
+
+## Other Notable Changes {#sec-release-21.11-notable-changes}