NixOS · Dec 16, 2018 · Dec 17, 2018 · Feb 15, 2019 · Feb 19, 2019 · Mar 9, 2019
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
@@ -11,11 +11,10 @@
    - [ ] macOS
    - [ ] other Linux distributions
 - [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
-- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nox --run "nox-review wip"`
+- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nix-review --run "nix-review wip"`
 - [ ] Tested execution of all binary files (usually in `./result/bin/`)
 - [ ] Determined the impact on package closure size (by running `nix path-info -S` before and after)
 - [ ] Assured whether relevant documentation is up to date
 - [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md).
 
 ---
-
diff --git a/doc/languages-frameworks/python.section.md b/doc/languages-frameworks/python.section.md
@@ -188,25 +188,24 @@ building Python libraries is `buildPythonPackage`. Let's see how we can build th
 ```nix
 { lib, buildPythonPackage, fetchPypi }:
 
-  toolz = buildPythonPackage rec {
-    pname = "toolz";
-    version = "0.7.4";
+buildPythonPackage rec {
+  pname = "toolz";
+  version = "0.7.4";
 
-    src = fetchPypi {
-      inherit pname version;
-      sha256 = "43c2c9e5e7a16b6c88ba3088a9bfc82f7db8e13378be7c78d6c14a5f8ed05afd";
-    };
+  src = fetchPypi {
+    inherit pname version;
+    sha256 = "43c2c9e5e7a16b6c88ba3088a9bfc82f7db8e13378be7c78d6c14a5f8ed05afd";
+  };
 
-    doCheck = false;
+  doCheck = false;
 
-    meta = with lib; {
-      homepage = https://github.com/pytoolz/toolz;
-      description = "List processing tools and functional utilities";
-      license = licenses.bsd3;
-      maintainers = with maintainers; [ fridh ];
-    };
+  meta = with lib; {
+    homepage = https://github.com/pytoolz/toolz;
+    description = "List processing tools and functional utilities";
+    license = licenses.bsd3;
+    maintainers = with maintainers; [ fridh ];
   };
-}
+};
 ```
 
 What happens here? The function `buildPythonPackage` is called and as argument

diff --git a/doc/reviewing-contributions.xml b/doc/reviewing-contributions.xml
@@ -189,14 +189,14 @@ $ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD <co
      </listitem>
      <listitem>
       <para>
-       The <link xlink:href="https://github.com/madjar/nox">nox</link> tool can
-       be used to review a pull request content in a single command. It doesn't
-       rebase on a channel branch so it might trigger multiple source builds.
+       The <link xlink:href="https://github.com/Mic92/nix-review">nix-review</link>
+       tool can be used to review a pull request content in a single command.
        <varname>PRNUMBER</varname> should be replaced by the number at the end
-       of the pull request title.
+       of the pull request title. You can also provide the full github pull
+       request url.
       </para>
 <screen>
-$ nix-shell -p nox --run "nox-review -k pr PRNUMBER"
+$ nix-shell -p nix-review --run "nix-review pr PRNUMBER"
 </screen>
      </listitem>
     </itemizedlist>

diff --git a/doc/submitting-changes.xml b/doc/submitting-changes.xml
@@ -351,26 +351,26 @@ Additional information.
   </section>
 
   <section xml:id="submitting-changes-tested-compilation">
-   <title>Tested compilation of all pkgs that depend on this change using <command>nox-review</command></title>
+   <title>Tested compilation of all pkgs that depend on this change using <command>nix-review</command></title>
 
    <para>
-    If you are updating a package's version, you can use nox to make sure all
-    packages that depend on the updated package still compile correctly. This
-    can be done using the nox utility. The <command>nox-review</command>
-    utility can look for and build all dependencies either based on uncommited
-    changes with the <literal>wip</literal> option or specifying a github pull
-    request number.
+    If you are updating a package's version, you can use nix-review to make sure all
+    packages that depend on the updated package still compile correctly.
+    The <command>nix-review</command> utility can look for and build all dependencies
+    either based on uncommited changes with the <literal>wip</literal> option or
+    specifying a github pull request number.
    </para>
 
    <para>
-    review uncommitted changes:
-<screen>nix-shell -p nox --run "nox-review wip"</screen>
+     review changes from pull request number 12345:
+     <screen>nix-shell -p nix-review --run "nix-review pr 12345"</screen>
    </para>
 
    <para>
-    review changes from pull request number 12345:
-<screen>nix-shell -p nox --run "nox-review pr 12345"</screen>
+     review uncommitted changes:
+     <screen>nix-shell -p nix-review --run "nix-review wip"</screen>
    </para>
+
   </section>
 
   <section xml:id="submitting-changes-tested-execution">

diff --git a/maintainers/maintainer-list.nix b/maintainers/maintainer-list.nix
@@ -1588,6 +1588,11 @@
     github = "fdns";
     name = "Felipe Espinoza";
   };
+  ffinkdevs = {
+    email = "fink@h0st.space";
+    github = "ffinkdevs";
+    name = "Fabian Fink";
+  };
   fgaz = {
     email = "fgaz@fgaz.me";
     github = "fgaz";
@@ -1770,6 +1775,11 @@
     github = "Gerschtli";
     name = "Tobias Happ";
   };
+  ggpeti = {
+    email = "ggpeti@gmail.com";
+    github = "ggpeti";
+    name = "Peter Ferenczy";
+  };
   gilligan = {
     email = "tobias.pflug@gmail.com";
     github = "gilligan";

diff --git a/nixos/doc/manual/Makefile b/nixos/doc/manual/Makefile
@@ -6,13 +6,14 @@ debug: generated manual-combined.xml
 
 manual-combined.xml: generated *.xml **/*.xml
 	rm -f ./manual-combined.xml
-	nix-shell --packages xmloscopy \
+	nix-shell --pure -Q --packages xmloscopy \
 		--run "xmloscopy --docbook5 ./manual.xml ./manual-combined.xml"
 
 .PHONY: format
 format:
-	find ../../ -iname '*.xml' -type f -print0 | xargs -0 -I{} -n1 \
-		xmlformat --config-file "../xmlformat.conf" -i {}
+	nix-shell --pure -Q --packages xmlformat \
+		--run "find ../../ -iname '*.xml' -type f -print0 | xargs -0 -I{} -n1 \
+		xmlformat --config-file '../xmlformat.conf' -i {}"
 
 .PHONY: fix-misc-xml
 fix-misc-xml:

diff --git a/nixos/doc/manual/configuration/config-file.xml b/nixos/doc/manual/configuration/config-file.xml
@@ -200,8 +200,9 @@ swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
 <xref linkend="opt-services.postgresql.package"/> = pkgs.postgresql_10;
 </programlisting>
       The latter option definition changes the default PostgreSQL package used
-      by NixOS’s PostgreSQL service to 10.x. For more information on packages,
-      including how to add new ones, see <xref linkend="sec-custom-packages"/>.
+      by NixOS’s PostgreSQL service to 10.x. For more information on
+      packages, including how to add new ones, see
+      <xref linkend="sec-custom-packages"/>.
      </para>
     </listitem>
    </varlistentry>

diff --git a/nixos/doc/manual/configuration/kubernetes.xml b/nixos/doc/manual/configuration/kubernetes.xml
@@ -4,15 +4,13 @@
          version="5.0"
          xml:id="sec-kubernetes">
  <title>Kubernetes</title>
-
  <para>
-   The NixOS Kubernetes module is a collective term for a handful of
-   individual submodules implementing the Kubernetes cluster components.
+  The NixOS Kubernetes module is a collective term for a handful of individual
+  submodules implementing the Kubernetes cluster components.
  </para>
-
  <para>
-   There are generally two ways of enabling Kubernetes on NixOS.
-   One way is to enable and configure cluster components appropriately by hand:
+  There are generally two ways of enabling Kubernetes on NixOS. One way is to
+  enable and configure cluster components appropriately by hand:
 <programlisting>
 services.kubernetes = {
   apiserver.enable = true;
@@ -33,95 +31,82 @@ services.kubernetes = {
 <programlisting>
 <xref linkend="opt-services.kubernetes.roles"/> = [ "node" ];
 </programlisting>
-  Assigning both the master and node roles is usable if you want a single
-  node Kubernetes cluster for dev or testing purposes:
+  Assigning both the master and node roles is usable if you want a single node
+  Kubernetes cluster for dev or testing purposes:
 <programlisting>
 <xref linkend="opt-services.kubernetes.roles"/> = [ "master" "node" ];
 </programlisting>
   Note: Assigning either role will also default both
   <xref linkend="opt-services.kubernetes.flannel.enable"/> and
-  <xref linkend="opt-services.kubernetes.easyCerts"/> to true.
-  This sets up flannel as CNI and activates automatic PKI bootstrapping.
+  <xref linkend="opt-services.kubernetes.easyCerts"/> to true. This sets up
+  flannel as CNI and activates automatic PKI bootstrapping.
  </para>
-
  <para>
-   As of kubernetes 1.10.X it has been deprecated to open
-   non-tls-enabled ports on kubernetes components. Thus, from NixOS 19.03 all
-   plain HTTP ports have been disabled by default.
-   While opening insecure ports is still possible, it is recommended not to
-   bind these to other interfaces than loopback.
-
-   To re-enable the insecure port on the apiserver, see options:
-   <xref linkend="opt-services.kubernetes.apiserver.insecurePort"/>
-   and
-   <xref linkend="opt-services.kubernetes.apiserver.insecureBindAddress"/>
+  As of kubernetes 1.10.X it has been deprecated to open non-tls-enabled ports
+  on kubernetes components. Thus, from NixOS 19.03 all plain HTTP ports have
+  been disabled by default. While opening insecure ports is still possible, it
+  is recommended not to bind these to other interfaces than loopback. To
+  re-enable the insecure port on the apiserver, see options:
+  <xref linkend="opt-services.kubernetes.apiserver.insecurePort"/> and
+  <xref linkend="opt-services.kubernetes.apiserver.insecureBindAddress"/>
  </para>
-
  <note>
   <para>
    As of NixOS 19.03, it is mandatory to configure:
-   <xref linkend="opt-services.kubernetes.masterAddress"/>.
-   The masterAddress must be resolveable and routeable by all cluster nodes.
-   In single node clusters, this can be set to <literal>localhost</literal>.
+   <xref linkend="opt-services.kubernetes.masterAddress"/>. The masterAddress
+   must be resolveable and routeable by all cluster nodes. In single node
+   clusters, this can be set to <literal>localhost</literal>.
   </para>
  </note>
-
  <para>
-   Role-based access control (RBAC) authorization mode is enabled by default.
-   This means that anonymous requests to the apiserver secure port will
-   expectedly cause a permission denied error. All cluster components must
-   therefore be configured with x509 certificates for two-way tls communication.
-   The x509 certificate subject section determines the roles and permissions
-   granted by the apiserver to perform clusterwide or namespaced operations.
-   See also:
-   <link
+  Role-based access control (RBAC) authorization mode is enabled by default.
+  This means that anonymous requests to the apiserver secure port will
+  expectedly cause a permission denied error. All cluster components must
+  therefore be configured with x509 certificates for two-way tls communication.
+  The x509 certificate subject section determines the roles and permissions
+  granted by the apiserver to perform clusterwide or namespaced operations. See
+  also:
+  <link
      xlink:href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/">
-     Using RBAC Authorization</link>.
+  Using RBAC Authorization</link>.
  </para>
-
-  <para>
-   The NixOS kubernetes module provides an option for automatic certificate
-   bootstrapping and configuration,
-    <xref linkend="opt-services.kubernetes.easyCerts"/>.
-   The PKI bootstrapping process involves setting up a certificate authority
-   (CA) daemon (cfssl) on the kubernetes master node. cfssl generates a CA-cert
-   for the cluster, and uses the CA-cert for signing subordinate certs issued to
-   each of the cluster components. Subsequently, the certmgr daemon monitors
-   active certificates and renews them when needed. For single node Kubernetes
-   clusters, setting <xref linkend="opt-services.kubernetes.easyCerts"/> = true
-   is sufficient and no further action is required. For joining extra node
-   machines to an existing cluster on the other hand, establishing initial trust
-   is mandatory.
+ <para>
+  The NixOS kubernetes module provides an option for automatic certificate
+  bootstrapping and configuration,
+  <xref linkend="opt-services.kubernetes.easyCerts"/>. The PKI bootstrapping
+  process involves setting up a certificate authority (CA) daemon (cfssl) on
+  the kubernetes master node. cfssl generates a CA-cert for the cluster, and
+  uses the CA-cert for signing subordinate certs issued to each of the cluster
+  components. Subsequently, the certmgr daemon monitors active certificates and
+  renews them when needed. For single node Kubernetes clusters, setting
+  <xref linkend="opt-services.kubernetes.easyCerts"/> = true is sufficient and
+  no further action is required. For joining extra node machines to an existing
+  cluster on the other hand, establishing initial trust is mandatory.
  </para>
-
  <para>
-   To add new nodes to the cluster:
-   On any (non-master) cluster node where
-   <xref linkend="opt-services.kubernetes.easyCerts"/> is enabled, the helper
-   script <literal>nixos-kubernetes-node-join</literal> is available on PATH.
-   Given a token on stdin, it will copy the token to the kubernetes
-   secrets directory and restart the certmgr service. As requested
-   certificates are issued, the script will restart kubernetes cluster
-   components as needed for them to pick up new keypairs.
+  To add new nodes to the cluster: On any (non-master) cluster node where
+  <xref linkend="opt-services.kubernetes.easyCerts"/> is enabled, the helper
+  script <literal>nixos-kubernetes-node-join</literal> is available on PATH.
+  Given a token on stdin, it will copy the token to the kubernetes secrets
+  directory and restart the certmgr service. As requested certificates are
+  issued, the script will restart kubernetes cluster components as needed for
+  them to pick up new keypairs.
  </para>
-
  <note>
   <para>
    Multi-master (HA) clusters are not supported by the easyCerts module.
   </para>
  </note>
-
  <para>
-   In order to interact with an RBAC-enabled cluster as an administrator, one
-   needs to have cluster-admin privileges. By default, when easyCerts is
-   enabled, a cluster-admin kubeconfig file is generated and linked into
-   <literal>/etc/kubernetes/cluster-admin.kubeconfig</literal> as determined by
-   <xref linkend="opt-services.kubernetes.pki.etcClusterAdminKubeconfig"/>.
-   <literal>export KUBECONFIG=/etc/kubernetes/cluster-admin.kubeconfig</literal>
-   will make kubectl use this kubeconfig to access and authenticate the cluster.
-   The cluster-admin kubeconfig references an auto-generated keypair owned by
-   root. Thus, only root on the kubernetes master may obtain cluster-admin
-   rights by means of this file.
+  In order to interact with an RBAC-enabled cluster as an administrator, one
+  needs to have cluster-admin privileges. By default, when easyCerts is
+  enabled, a cluster-admin kubeconfig file is generated and linked into
+  <literal>/etc/kubernetes/cluster-admin.kubeconfig</literal> as determined by
+  <xref linkend="opt-services.kubernetes.pki.etcClusterAdminKubeconfig"/>.
+  <literal>export KUBECONFIG=/etc/kubernetes/cluster-admin.kubeconfig</literal>
+  will make kubectl use this kubeconfig to access and authenticate the cluster.
+  The cluster-admin kubeconfig references an auto-generated keypair owned by
+  root. Thus, only root on the kubernetes master may obtain cluster-admin
+  rights by means of this file.
  </para>
-
 </chapter>