Merge master into staging-next

3 files changed, 36 insertions, 10 deletions

diff --git a/doc/languages-frameworks/coq.xml b/doc/languages-frameworks/coq.xml
index 640b04c7da9..4314df5c9df 100644
--- a/doc/languages-frameworks/coq.xml
+++ b/doc/languages-frameworks/coq.xml
@@ -12,8 +12,8 @@
 
  <para>
   Some extensions (plugins) might require OCaml and sometimes other OCaml
-  packages. The <literal>coq.ocamlPackages</literal> attribute can be used
-  to depend on the same package set Coq was built against.
+  packages. The <literal>coq.ocamlPackages</literal> attribute can be used to
+  depend on the same package set Coq was built against.
  </para>
 
  <para>
diff --git a/doc/languages-frameworks/vim.section.md b/doc/languages-frameworks/vim.section.md
index 1b235dbb52f..2cec1543a24 100644
--- a/doc/languages-frameworks/vim.section.md
+++ b/doc/languages-frameworks/vim.section.md
@@ -23,6 +23,7 @@ Adding custom .vimrc lines can be done using the following code:
 
 ```
 vim_configurable.customize {
+  # `name` specifies the name of the executable and package
   name = "vim-with-plugins";
 
   vimrcConfig.customRC = ''
@@ -31,6 +32,8 @@ vim_configurable.customize {
 }
 ```
 
+This configuration is used when vim is invoked with the command specified as name, in this case `vim-with-plugins`.
+
 For Neovim the `configure` argument can be overridden to achieve the same:
 
 ```
@@ -83,6 +86,7 @@ The resulting package can be added to `packageOverrides` in `~/.nixpkgs/config.n
 {
   packageOverrides = pkgs: with pkgs; {
     myVim = vim_configurable.customize {
+      # `name` specifies the name of the executable and package
       name = "vim-with-plugins";
       # add here code from the example section
     };
diff --git a/doc/stdenv.xml b/doc/stdenv.xml
index cc0c13c5447..b2f30bf08db 100644
--- a/doc/stdenv.xml
+++ b/doc/stdenv.xml
@@ -372,7 +372,7 @@ let f(h, h + 1, i) = i + h
       They are programs/libraries used at build time that furthermore produce
       programs/libraries also used at build time. If the dependency doesn't
       care about the target platform (i.e. isn't a compiler or similar tool),
-      put it in <varname>nativeBuildInputs</varname>instead. The most common
+      put it in <varname>nativeBuildInputs</varname> instead. The most common
       use for this <literal>buildPackages.stdenv.cc</literal>, the default C
       compiler for this role. That example crops up more than one might think
       in old commonly used C libraries.
@@ -2099,13 +2099,13 @@ someVar=$(stripHash $name)
   </para>
 
   <para>
-   In order to alleviate this burden, the <firstterm>setup
-   hook></firstterm>mechanism was written, where any package can include a
-   shell script that [by convention rather than enforcement by Nix], any
-   downstream reverse-dependency will source as part of its build process. That
-   allows the downstream dependency to merely specify its dependencies, and
-   lets those dependencies effectively initialize themselves. No boilerplate
-   mirroring the list of dependencies is needed.
+   In order to alleviate this burden, the <firstterm>setup hook</firstterm>
+   mechanism was written, where any package can include a shell script that [by
+   convention rather than enforcement by Nix], any downstream
+   reverse-dependency will source as part of its build process. That allows the
+   downstream dependency to merely specify its dependencies, and lets those
+   dependencies effectively initialize themselves. No boilerplate mirroring the
+   list of dependencies is needed.
   </para>
 
   <para>
@@ -2445,6 +2445,28 @@ addEnvHooks "$hostOffset" myBashFunction
       </para>
      </listitem>
     </varlistentry>
+    <varlistentry>
+     <term>
+      breakpointHook
+     </term>
+     <listitem>
+      <para>
+       This hook will make a build pause instead of stopping when a failure
+       happen. It prevents nix to cleanup the build environment immediatly and
+       allows the user to attach to a build environment using the
+       <command>cntr</command> command. On build error it will print the
+       instruction that are neccessary for <command>cntr</command>. Installing
+       cntr and running the command will provide shell access to the build
+       sandbox of failed build. At <filename>/var/lib/cntr</filename> the
+       sandbox filesystem is mounted. All commands and files of the system are
+       still accessible within the shell. To execute commands from the sandbox
+       use the cntr exec subcommand. Note that <command>cntr</command> also
+       needs to be executed on the machine that is doing the build, which might
+       be not the case when remote builders are enabled.
+       <command>cntr</command> is only supported on linux based platforms.
+      </para>
+     </listitem>
+    </varlistentry>
    </variablelist>
   </para>
  </section>