diff options
| author | Frederik Rietdijk <fridh@fridh.nl> | 2019-09-19 16:59:42 +0200 |
|---|---|---|
| committer | Frederik Rietdijk <fridh@fridh.nl> | 2019-09-19 16:59:42 +0200 |
| commit | 0b12d44c06dccbfedaae89cb00f782d7c89fc814 (patch) | |
| tree | 914258a15b689afcd266bd9fdb7225911daa3f0c /doc | |
| parent | 105abdd52cfb3795a867ab5d80f314950b86eadd (diff) | |
| parent | 6ff8b675e0c2730e54f95d232a93e5b01813f389 (diff) | |
Merge master into staging-next
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/cross-compilation.xml | 4 | ||||
| -rw-r--r-- | doc/submitting-changes.xml | 4 |
2 files changed, 4 insertions, 4 deletions
diff --git a/doc/cross-compilation.xml b/doc/cross-compilation.xml index f496fa3f896..93fe9095ce2 100644 --- a/doc/cross-compilation.xml +++ b/doc/cross-compilation.xml @@ -271,14 +271,14 @@ <para> Nixpkgs can be instantiated with <varname>localSystem</varname> alone, in which case there is no cross-compiling and everything is built by and for that system, or also with <varname>crossSystem</varname>, in which case packages run on the latter, but all building happens on the former. Both parameters take the same schema as the 3 (build, host, and target) platforms defined in the previous section. As mentioned above, <literal>lib.systems.examples</literal> has some platforms which are used as arguments for these parameters in practice. You can use them programmatically, or on the command line: <programlisting> -nix-build <nixpkgs> --arg crossSystem '(import <nixpkgs/lib>).systems.examples.fooBarBaz' -A whatever</programlisting> +nix-build '<nixpkgs>' --arg crossSystem '(import <nixpkgs/lib>).systems.examples.fooBarBaz' -A whatever</programlisting> </para> <note> <para> Eventually we would like to make these platform examples an unnecessary convenience so that <programlisting> -nix-build <nixpkgs> --arg crossSystem '{ config = "<arch>-<os>-<vendor>-<abi>"; }' -A whatever</programlisting> +nix-build '<nixpkgs>' --arg crossSystem '{ config = "<arch>-<os>-<vendor>-<abi>"; }' -A whatever</programlisting> works in the vast majority of cases. The problem today is dependencies on other sorts of configuration which aren't given proper defaults. We rely on the examples to crudely to set those configuration parameters in some vaguely sane manner on the users behalf. Issue <link xlink:href="https://github.com/NixOS/nixpkgs/issues/34274">#34274</link> tracks this inconvenience along with its root cause in crufty configuration options. </para> </note> diff --git a/doc/submitting-changes.xml b/doc/submitting-changes.xml index 9c98abbe87a..2c7defb8174 100644 --- a/doc/submitting-changes.xml +++ b/doc/submitting-changes.xml @@ -244,7 +244,7 @@ Additional information. <para> When sandbox builds are enabled, Nix will setup an isolated environment for each build process. It is used to remove further hidden dependencies set by the build environment to improve reproducibility. This includes access to the network during the build outside of <function>fetch*</function> functions and files outside the Nix store. Depending on the operating system access to other resources are blocked as well (ex. inter process communication is isolated on Linux); see <link - xlink:href="https://nixos.org/nix/manual/#description-45">build-use-sandbox</link> in Nix manual for details. + xlink:href="https://nixos.org/nix/manual/#conf-sandbox">sandbox</link> in Nix manual for details. </para> <para> @@ -265,7 +265,7 @@ Additional information. <listitem> <para> <emphasis role="bold">Globally enable sandboxing on non-NixOS platforms</emphasis>: add the following to: <filename>/etc/nix/nix.conf</filename> -<screen>build-use-sandbox = true</screen> +<screen>sandbox = true</screen> </para> </listitem> </itemizedlist> |