mirror of
https://github.com/NixOS/nixpkgs.git
synced 2024-11-27 17:33:09 +00:00
Merge remote-tracking branch 'upstream/master' into darwin-to-linux-cross
This commit is contained in:
commit
bbd12f5583
@ -1,8 +0,0 @@
|
||||
;;; Directory Local Variables
|
||||
;;; For more information see (info "(emacs) Directory Variables")
|
||||
|
||||
((nil
|
||||
(bug-reference-bug-regexp . "\\(\\(?:[Ii]ssue \\|[Ff]ixe[ds] \\|[Rr]esolve[ds]? \\|[Cc]lose[ds]? \\|[Pp]\\(?:ull [Rr]equest\\|[Rr]\\) \\|(\\)#\\([0-9]+\\))?\\)")
|
||||
(bug-reference-url-format . "https://github.com/NixOS/nixpkgs/issues/%s"))
|
||||
(nix-mode
|
||||
(tab-width . 2)))
|
2
.github/CONTRIBUTING.md
vendored
2
.github/CONTRIBUTING.md
vendored
@ -20,6 +20,8 @@ under the terms of [COPYING](../COPYING), which is an MIT-like license.
|
||||
(Motivation for change. Additional information.)
|
||||
```
|
||||
|
||||
For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message).
|
||||
|
||||
Examples:
|
||||
|
||||
* nginx: init at 2.0.1
|
||||
|
9
COPYING
9
COPYING
@ -18,12 +18,3 @@ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
|
||||
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
|
||||
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
||||
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
|
||||
======================================================================
|
||||
|
||||
Note: the license above does not apply to the packages built by the
|
||||
Nix Packages collection, merely to the package descriptions (i.e., Nix
|
||||
expressions, build scripts, etc.). It also might not apply to patches
|
||||
included in Nixpkgs, which may be derivative works of the packages to
|
||||
which they apply. The aforementioned artifacts are all covered by the
|
||||
licenses of the respective packages.
|
||||
|
14
README.md
14
README.md
@ -12,12 +12,12 @@ build daemon as so-called channels. To get channel information via git, add
|
||||
```
|
||||
|
||||
For stability and maximum binary package support, it is recommended to maintain
|
||||
custom changes on top of one of the channels, e.g. `nixos-18.03` for the latest
|
||||
custom changes on top of one of the channels, e.g. `nixos-18.09` for the latest
|
||||
release and `nixos-unstable` for the latest successful build of master:
|
||||
|
||||
```
|
||||
% git remote update channels
|
||||
% git rebase channels/nixos-18.03
|
||||
% git rebase channels/nixos-18.09
|
||||
```
|
||||
|
||||
For pull-requests, please rebase onto nixpkgs `master`.
|
||||
@ -31,11 +31,17 @@ For pull-requests, please rebase onto nixpkgs `master`.
|
||||
* [Manual (NixOS)](https://nixos.org/nixos/manual/)
|
||||
* [Community maintained wiki](https://nixos.wiki/)
|
||||
* [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
|
||||
* [Continuous package builds for 18.03 release](https://hydra.nixos.org/jobset/nixos/release-18.03)
|
||||
* [Continuous package builds for 18.09 release](https://hydra.nixos.org/jobset/nixos/release-18.09)
|
||||
* [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
|
||||
* [Tests for 18.03 release](https://hydra.nixos.org/job/nixos/release-18.03/tested#tabs-constituents)
|
||||
* [Tests for 18.09 release](https://hydra.nixos.org/job/nixos/release-18.09/tested#tabs-constituents)
|
||||
|
||||
Communication:
|
||||
|
||||
* [Discourse Forum](https://discourse.nixos.org/)
|
||||
* [IRC - #nixos on freenode.net](irc://irc.freenode.net/#nixos)
|
||||
|
||||
Note: MIT license does not apply to the packages built by Nixpkgs, merely to
|
||||
the package descriptions (Nix expressions, build scripts, and so on). It also
|
||||
might not apply to patches included in Nixpkgs, which may be derivative works
|
||||
of the packages to which they apply. The aforementioned artifacts are all
|
||||
covered by the licenses of the respective packages.
|
||||
|
@ -18,7 +18,7 @@ if ! builtins ? nixVersion || builtins.compareVersions requiredVersion builtins.
|
||||
|
||||
For more information, please see the NixOS release notes at
|
||||
https://nixos.org/nixos/manual or locally at
|
||||
${toString ./doc/manual/release-notes}.
|
||||
${toString ./nixos/doc/manual/release-notes}.
|
||||
|
||||
If you need further help, see https://nixos.org/nixos/support.html
|
||||
''
|
||||
|
1
doc/.gitignore
vendored
1
doc/.gitignore
vendored
@ -4,3 +4,4 @@
|
||||
out
|
||||
manual-full.xml
|
||||
highlightjs
|
||||
functions/library/locations.xml
|
||||
|
@ -19,7 +19,7 @@ fix-misc-xml:
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f ${MD_TARGETS} .version manual-full.xml
|
||||
rm -f ${MD_TARGETS} .version manual-full.xml functions/library/locations.xml
|
||||
rm -rf ./out/ ./highlightjs
|
||||
|
||||
.PHONY: validate
|
||||
@ -69,13 +69,17 @@ highlightjs:
|
||||
cp -r "$$HIGHLIGHTJS/loader.js" highlightjs/
|
||||
|
||||
|
||||
manual-full.xml: ${MD_TARGETS} .version *.xml
|
||||
manual-full.xml: ${MD_TARGETS} .version functions/library/locations.xml *.xml **/*.xml **/**/*.xml
|
||||
xmllint --nonet --xinclude --noxincludenode manual.xml --output manual-full.xml
|
||||
|
||||
.version:
|
||||
nix-instantiate --eval \
|
||||
-E '(import ../lib).version' > .version
|
||||
|
||||
functions/library/locations.xml:
|
||||
nix-build ./lib-function-locations.nix \
|
||||
--out-link ./functions/library/locations.xml
|
||||
|
||||
%.section.xml: %.section.md
|
||||
pandoc $^ -w docbook+smart \
|
||||
-f markdown+smart \
|
||||
|
@ -325,7 +325,7 @@
|
||||
};
|
||||
};
|
||||
}
|
||||
</screen>
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
To install it into our environment, you can just run <literal>nix-env -iA
|
||||
@ -347,7 +347,7 @@
|
||||
};
|
||||
};
|
||||
}
|
||||
</screen>
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
<literal>pathsToLink</literal> tells Nixpkgs to only link the paths listed
|
||||
@ -383,7 +383,7 @@
|
||||
};
|
||||
};
|
||||
}
|
||||
</screen>
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
This provides us with some useful documentation for using our packages.
|
||||
@ -395,15 +395,15 @@
|
||||
{
|
||||
packageOverrides = pkgs: with pkgs; rec {
|
||||
myProfile = writeText "my-profile" ''
|
||||
export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin
|
||||
export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man
|
||||
export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin
|
||||
export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man
|
||||
'';
|
||||
myPackages = pkgs.buildEnv {
|
||||
name = "my-packages";
|
||||
paths = [
|
||||
(runCommand "profile" {} ''
|
||||
mkdir -p $out/etc/profile.d
|
||||
cp ${myProfile} $out/etc/profile.d/my-profile.sh
|
||||
mkdir -p $out/etc/profile.d
|
||||
cp ${myProfile} $out/etc/profile.d/my-profile.sh
|
||||
'')
|
||||
aspell
|
||||
bc
|
||||
@ -421,7 +421,7 @@ cp ${myProfile} $out/etc/profile.d/my-profile.sh
|
||||
};
|
||||
};
|
||||
}
|
||||
</screen>
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
For this to work fully, you must also have this script sourced when you are
|
||||
@ -438,7 +438,7 @@ if [ -d $HOME/.nix-profile/etc/profile.d ]; then
|
||||
fi
|
||||
done
|
||||
fi
|
||||
</screen>
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
Now just run <literal>source $HOME/.profile</literal> and you can starting
|
||||
@ -459,16 +459,16 @@ fi
|
||||
{
|
||||
packageOverrides = pkgs: with pkgs; rec {
|
||||
myProfile = writeText "my-profile" ''
|
||||
export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin
|
||||
export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man
|
||||
export INFOPATH=$HOME/.nix-profile/share/info:/nix/var/nix/profiles/default/share/info:/usr/share/info
|
||||
export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin
|
||||
export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man
|
||||
export INFOPATH=$HOME/.nix-profile/share/info:/nix/var/nix/profiles/default/share/info:/usr/share/info
|
||||
'';
|
||||
myPackages = pkgs.buildEnv {
|
||||
name = "my-packages";
|
||||
paths = [
|
||||
(runCommand "profile" {} ''
|
||||
mkdir -p $out/etc/profile.d
|
||||
cp ${myProfile} $out/etc/profile.d/my-profile.sh
|
||||
mkdir -p $out/etc/profile.d
|
||||
cp ${myProfile} $out/etc/profile.d/my-profile.sh
|
||||
'')
|
||||
aspell
|
||||
bc
|
||||
@ -485,17 +485,17 @@ cp ${myProfile} $out/etc/profile.d/my-profile.sh
|
||||
pathsToLink = [ "/share/man" "/share/doc" "/share/info" "/bin" "/etc" ];
|
||||
extraOutputsToInstall = [ "man" "doc" "info" ];
|
||||
postBuild = ''
|
||||
if [ -x $out/bin/install-info -a -w $out/share/info ]; then
|
||||
shopt -s nullglob
|
||||
for i in $out/share/info/*.info $out/share/info/*.info.gz; do
|
||||
$out/bin/install-info $i $out/share/info/dir
|
||||
done
|
||||
fi
|
||||
if [ -x $out/bin/install-info -a -w $out/share/info ]; then
|
||||
shopt -s nullglob
|
||||
for i in $out/share/info/*.info $out/share/info/*.info.gz; do
|
||||
$out/bin/install-info $i $out/share/info/dir
|
||||
done
|
||||
fi
|
||||
'';
|
||||
};
|
||||
};
|
||||
}
|
||||
</screen>
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
<literal>postBuild</literal> tells Nixpkgs to run a command after building
|
||||
|
@ -47,9 +47,10 @@
|
||||
|
||||
<para>
|
||||
In Nixpkgs, these three platforms are defined as attribute sets under the
|
||||
names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>, and
|
||||
<literal>targetPlatform</literal>. They are always defined as attributes in
|
||||
the standard environment. That means one can access them like:
|
||||
names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>,
|
||||
and <literal>targetPlatform</literal>. They are always defined as
|
||||
attributes in the standard environment. That means one can access them
|
||||
like:
|
||||
<programlisting>{ stdenv, fooDep, barDep, .. }: ...stdenv.buildPlatform...</programlisting>
|
||||
.
|
||||
</para>
|
||||
|
@ -1,6 +1,7 @@
|
||||
{ pkgs ? (import ./.. { }), nixpkgs ? { }}:
|
||||
let
|
||||
pkgs = import ./.. { };
|
||||
lib = pkgs.lib;
|
||||
locationsXml = import ./lib-function-locations.nix { inherit pkgs nixpkgs; };
|
||||
in
|
||||
pkgs.stdenv.mkDerivation {
|
||||
name = "nixpkgs-manual";
|
||||
@ -29,6 +30,8 @@ pkgs.stdenv.mkDerivation {
|
||||
];
|
||||
|
||||
postPatch = ''
|
||||
rm -rf ./functions/library/locations.xml
|
||||
ln -s ${locationsXml} ./functions/library/locations.xml
|
||||
echo ${lib.version} > .version
|
||||
'';
|
||||
|
||||
|
@ -1,799 +1,17 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="chap-functions">
|
||||
xml:id="chap-functions">
|
||||
<title>Functions reference</title>
|
||||
<para>
|
||||
The nixpkgs repository has several utility functions to manipulate Nix
|
||||
expressions.
|
||||
</para>
|
||||
<section xml:id="sec-overrides">
|
||||
<title>Overriding</title>
|
||||
|
||||
<para>
|
||||
Sometimes one wants to override parts of <literal>nixpkgs</literal>, e.g.
|
||||
derivation attributes, the results of derivations or even the whole package
|
||||
set.
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-pkg-override">
|
||||
<title><pkg>.override</title>
|
||||
|
||||
<para>
|
||||
The function <varname>override</varname> is usually available for all the
|
||||
derivations in the nixpkgs expression (<varname>pkgs</varname>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is used to override the arguments passed to a function.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example usages:
|
||||
<programlisting>pkgs.foo.override { arg1 = val1; arg2 = val2; ... }</programlisting>
|
||||
<programlisting>import pkgs.path { overlays = [ (self: super: {
|
||||
foo = super.foo.override { barSupport = true ; };
|
||||
})]};</programlisting>
|
||||
<programlisting>mypkg = pkgs.callPackage ./mypkg.nix {
|
||||
mydep = pkgs.mydep.override { ... };
|
||||
}</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the first example, <varname>pkgs.foo</varname> is the result of a
|
||||
function call with some default arguments, usually a derivation. Using
|
||||
<varname>pkgs.foo.override</varname> will call the same function with the
|
||||
given new arguments.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-pkg-overrideAttrs">
|
||||
<title><pkg>.overrideAttrs</title>
|
||||
|
||||
<para>
|
||||
The function <varname>overrideAttrs</varname> allows overriding the
|
||||
attribute set passed to a <varname>stdenv.mkDerivation</varname> call,
|
||||
producing a new derivation based on the original one. This function is
|
||||
available on all derivations produced by the
|
||||
<varname>stdenv.mkDerivation</varname> function, which is most packages in
|
||||
the nixpkgs expression <varname>pkgs</varname>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example usage:
|
||||
<programlisting>helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
|
||||
separateDebugInfo = true;
|
||||
});</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the above example, the <varname>separateDebugInfo</varname> attribute is
|
||||
overridden to be true, thus building debug info for
|
||||
<varname>helloWithDebug</varname>, while all other attributes will be
|
||||
retained from the original <varname>hello</varname> package.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The argument <varname>oldAttrs</varname> is conventionally used to refer to
|
||||
the attr set originally passed to <varname>stdenv.mkDerivation</varname>.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Note that <varname>separateDebugInfo</varname> is processed only by the
|
||||
<varname>stdenv.mkDerivation</varname> function, not the generated, raw
|
||||
Nix derivation. Thus, using <varname>overrideDerivation</varname> will not
|
||||
work in this case, as it overrides only the attributes of the final
|
||||
derivation. It is for this reason that <varname>overrideAttrs</varname>
|
||||
should be preferred in (almost) all cases to
|
||||
<varname>overrideDerivation</varname>, i.e. to allow using
|
||||
<varname>sdenv.mkDerivation</varname> to process input arguments, as well
|
||||
as the fact that it is easier to use (you can use the same attribute names
|
||||
you see in your Nix code, instead of the ones generated (e.g.
|
||||
<varname>buildInputs</varname> vs <varname>nativeBuildInputs</varname>,
|
||||
and involves less typing.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-pkg-overrideDerivation">
|
||||
<title><pkg>.overrideDerivation</title>
|
||||
|
||||
<warning>
|
||||
<para>
|
||||
You should prefer <varname>overrideAttrs</varname> in almost all cases,
|
||||
see its documentation for the reasons why.
|
||||
<varname>overrideDerivation</varname> is not deprecated and will continue
|
||||
to work, but is less nice to use and does not have as many abilities as
|
||||
<varname>overrideAttrs</varname>.
|
||||
</para>
|
||||
</warning>
|
||||
|
||||
<warning>
|
||||
<para>
|
||||
Do not use this function in Nixpkgs as it evaluates a Derivation before
|
||||
modifying it, which breaks package abstraction and removes error-checking
|
||||
of function arguments. In addition, this evaluation-per-function
|
||||
application incurs a performance penalty, which can become a problem if
|
||||
many overrides are used. It is only intended for ad-hoc customisation,
|
||||
such as in <filename>~/.config/nixpkgs/config.nix</filename>.
|
||||
</para>
|
||||
</warning>
|
||||
|
||||
<para>
|
||||
The function <varname>overrideDerivation</varname> creates a new derivation
|
||||
based on an existing one by overriding the original's attributes with the
|
||||
attribute set produced by the specified function. This function is
|
||||
available on all derivations defined using the
|
||||
<varname>makeOverridable</varname> function. Most standard
|
||||
derivation-producing functions, such as
|
||||
<varname>stdenv.mkDerivation</varname>, are defined using this function,
|
||||
which means most packages in the nixpkgs expression,
|
||||
<varname>pkgs</varname>, have this function.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example usage:
|
||||
<programlisting>mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
|
||||
name = "sed-4.2.2-pre";
|
||||
src = fetchurl {
|
||||
url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2;
|
||||
sha256 = "11nq06d131y4wmf3drm0yk502d2xc6n5qy82cg88rb9nqd2lj41k";
|
||||
};
|
||||
patches = [];
|
||||
});</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the above example, the <varname>name</varname>, <varname>src</varname>,
|
||||
and <varname>patches</varname> of the derivation will be overridden, while
|
||||
all other attributes will be retained from the original derivation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The argument <varname>oldAttrs</varname> is used to refer to the attribute
|
||||
set of the original derivation.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
A package's attributes are evaluated *before* being modified by the
|
||||
<varname>overrideDerivation</varname> function. For example, the
|
||||
<varname>name</varname> attribute reference in <varname>url =
|
||||
"mirror://gnu/hello/${name}.tar.gz";</varname> is filled-in *before* the
|
||||
<varname>overrideDerivation</varname> function modifies the attribute set.
|
||||
This means that overriding the <varname>name</varname> attribute, in this
|
||||
example, *will not* change the value of the <varname>url</varname>
|
||||
attribute. Instead, we need to override both the <varname>name</varname>
|
||||
*and* <varname>url</varname> attributes.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-lib-makeOverridable">
|
||||
<title>lib.makeOverridable</title>
|
||||
|
||||
<para>
|
||||
The function <varname>lib.makeOverridable</varname> is used to make the
|
||||
result of a function easily customizable. This utility only makes sense for
|
||||
functions that accept an argument set and return an attribute set.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example usage:
|
||||
<programlisting>f = { a, b }: { result = a+b; }
|
||||
c = lib.makeOverridable f { a = 1; b = 2; }</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The variable <varname>c</varname> is the value of the <varname>f</varname>
|
||||
function applied with some default arguments. Hence the value of
|
||||
<varname>c.result</varname> is <literal>3</literal>, in this example.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The variable <varname>c</varname> however also has some additional
|
||||
functions, like <link linkend="sec-pkg-override">c.override</link> which
|
||||
can be used to override the default arguments. In this example the value of
|
||||
<varname>(c.override { a = 4; }).result</varname> is 6.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="sec-generators">
|
||||
<title>Generators</title>
|
||||
|
||||
<para>
|
||||
Generators are functions that create file formats from nix data structures,
|
||||
e. g. for configuration files. There are generators available for:
|
||||
<literal>INI</literal>, <literal>JSON</literal> and <literal>YAML</literal>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
All generators follow a similar call interface: <code>generatorName
|
||||
configFunctions data</code>, where <literal>configFunctions</literal> is an
|
||||
attrset of user-defined functions that format nested parts of the content.
|
||||
They each have common defaults, so often they do not need to be set
|
||||
manually. An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]"
|
||||
] name)</code> from the <literal>INI</literal> generator. It receives the
|
||||
name of a section and sanitizes it. The default
|
||||
<literal>mkSectionName</literal> escapes <literal>[</literal> and
|
||||
<literal>]</literal> with a backslash.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Generators can be fine-tuned to produce exactly the file format required by
|
||||
your application/service. One example is an INI-file format which uses
|
||||
<literal>: </literal> as separator, the strings
|
||||
<literal>"yes"</literal>/<literal>"no"</literal> as boolean values and
|
||||
requires all string values to be quoted:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
with lib;
|
||||
let
|
||||
customToINI = generators.toINI {
|
||||
# specifies how to format a key/value pair
|
||||
mkKeyValue = generators.mkKeyValueDefault {
|
||||
# specifies the generated string for a subset of nix values
|
||||
mkValueString = v:
|
||||
if v == true then ''"yes"''
|
||||
else if v == false then ''"no"''
|
||||
else if isString v then ''"${v}"''
|
||||
# and delegats all other values to the default generator
|
||||
else generators.mkValueStringDefault {} v;
|
||||
} ":";
|
||||
};
|
||||
|
||||
# the INI file can now be given as plain old nix values
|
||||
in customToINI {
|
||||
main = {
|
||||
pushinfo = true;
|
||||
autopush = false;
|
||||
host = "localhost";
|
||||
port = 42;
|
||||
};
|
||||
mergetool = {
|
||||
merge = "diff3";
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
This will produce the following INI file as nix string:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
[main]
|
||||
autopush:"no"
|
||||
host:"localhost"
|
||||
port:42
|
||||
pushinfo:"yes"
|
||||
str\:ange:"very::strange"
|
||||
|
||||
[mergetool]
|
||||
merge:"diff3"
|
||||
</programlisting>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Nix store paths can be converted to strings by enclosing a derivation
|
||||
attribute like so: <code>"${drv}"</code>.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
Detailed documentation for each generator can be found in
|
||||
<literal>lib/generators.nix</literal>.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="sec-debug">
|
||||
<title>Debugging Nix Expressions</title>
|
||||
|
||||
<para>
|
||||
Nix is a unityped, dynamic language, this means every value can potentially
|
||||
appear anywhere. Since it is also non-strict, evaluation order and what
|
||||
ultimately is evaluated might surprise you. Therefore it is important to be
|
||||
able to debug nix expressions.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the <literal>lib/debug.nix</literal> file you will find a number of
|
||||
functions that help (pretty-)printing values while evaluation is runnnig.
|
||||
You can even specify how deep these values should be printed recursively,
|
||||
and transform them on the fly. Please consult the docstrings in
|
||||
<literal>lib/debug.nix</literal> for usage information.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="sec-fhs-environments">
|
||||
<title>buildFHSUserEnv</title>
|
||||
|
||||
<para>
|
||||
<function>buildFHSUserEnv</function> provides a way to build and run
|
||||
FHS-compatible lightweight sandboxes. It creates an isolated root with bound
|
||||
<filename>/nix/store</filename>, so its footprint in terms of disk space
|
||||
needed is quite small. This allows one to run software which is hard or
|
||||
unfeasible to patch for NixOS -- 3rd-party source trees with FHS
|
||||
assumptions, games distributed as tarballs, software with integrity checking
|
||||
and/or external self-updated binaries. It uses Linux namespaces feature to
|
||||
create temporary lightweight environments which are destroyed after all
|
||||
child processes exit, without root user rights requirement. Accepted
|
||||
arguments are:
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>name</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Environment name.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>targetPkgs</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Packages to be installed for the main host's architecture (i.e. x86_64 on
|
||||
x86_64 installations). Along with libraries binaries are also installed.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>multiPkgs</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Packages to be installed for all architectures supported by a host (i.e.
|
||||
i686 and x86_64 on x86_64 installations). Only libraries are installed by
|
||||
default.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>extraBuildCommands</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Additional commands to be executed for finalizing the directory
|
||||
structure.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>extraBuildCommandsMulti</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Like <literal>extraBuildCommands</literal>, but executed only on multilib
|
||||
architectures.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>extraOutputsToInstall</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Additional derivation outputs to be linked for both target and
|
||||
multi-architecture packages.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>extraInstallCommands</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Additional commands to be executed for finalizing the derivation with
|
||||
runner script.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>runScript</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
A command that would be executed inside the sandbox and passed all the
|
||||
command line arguments. It defaults to <literal>bash</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>
|
||||
One can create a simple environment using a <literal>shell.nix</literal>
|
||||
like that:
|
||||
</para>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
|
||||
(pkgs.buildFHSUserEnv {
|
||||
name = "simple-x11-env";
|
||||
targetPkgs = pkgs: (with pkgs;
|
||||
[ udev
|
||||
alsaLib
|
||||
]) ++ (with pkgs.xorg;
|
||||
[ libX11
|
||||
libXcursor
|
||||
libXrandr
|
||||
]);
|
||||
multiPkgs = pkgs: (with pkgs;
|
||||
[ udev
|
||||
alsaLib
|
||||
]);
|
||||
runScript = "bash";
|
||||
}).env
|
||||
]]></programlisting>
|
||||
|
||||
<para>
|
||||
Running <literal>nix-shell</literal> would then drop you into a shell with
|
||||
these libraries and binaries available. You can use this to run
|
||||
closed-source applications which expect FHS structure without hassles:
|
||||
simply change <literal>runScript</literal> to the application path, e.g.
|
||||
<filename>./bin/start.sh</filename> -- relative paths are supported.
|
||||
</para>
|
||||
</section>
|
||||
<xi:include href="shell.section.xml" />
|
||||
<section xml:id="sec-pkgs-dockerTools">
|
||||
<title>pkgs.dockerTools</title>
|
||||
|
||||
<para>
|
||||
<varname>pkgs.dockerTools</varname> is a set of functions for creating and
|
||||
manipulating Docker images according to the
|
||||
<link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#docker-image-specification-v120">
|
||||
Docker Image Specification v1.2.0 </link>. Docker itself is not used to
|
||||
perform any of the operations done by these functions.
|
||||
</para>
|
||||
|
||||
<warning>
|
||||
<para>
|
||||
The <varname>dockerTools</varname> API is unstable and may be subject to
|
||||
backwards-incompatible changes in the future.
|
||||
</para>
|
||||
</warning>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-buildImage">
|
||||
<title>buildImage</title>
|
||||
|
||||
<para>
|
||||
This function is analogous to the <command>docker build</command> command,
|
||||
in that can used to build a Docker-compatible repository tarball containing
|
||||
a single image with one or multiple layers. As such, the result is suitable
|
||||
for being loaded in Docker with <command>docker load</command>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The parameters of <varname>buildImage</varname> with relative example
|
||||
values are described below:
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-dockerTools-buildImage'>
|
||||
<title>Docker build</title>
|
||||
<programlisting>
|
||||
buildImage {
|
||||
name = "redis"; <co xml:id='ex-dockerTools-buildImage-1' />
|
||||
tag = "latest"; <co xml:id='ex-dockerTools-buildImage-2' />
|
||||
|
||||
fromImage = someBaseImage; <co xml:id='ex-dockerTools-buildImage-3' />
|
||||
fromImageName = null; <co xml:id='ex-dockerTools-buildImage-4' />
|
||||
fromImageTag = "latest"; <co xml:id='ex-dockerTools-buildImage-5' />
|
||||
|
||||
contents = pkgs.redis; <co xml:id='ex-dockerTools-buildImage-6' />
|
||||
runAsRoot = '' <co xml:id='ex-dockerTools-buildImage-runAsRoot' />
|
||||
#!${stdenv.shell}
|
||||
mkdir -p /data
|
||||
'';
|
||||
|
||||
config = { <co xml:id='ex-dockerTools-buildImage-8' />
|
||||
Cmd = [ "/bin/redis-server" ];
|
||||
WorkingDir = "/data";
|
||||
Volumes = {
|
||||
"/data" = {};
|
||||
};
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>
|
||||
The above example will build a Docker image <literal>redis/latest</literal>
|
||||
from the given base image. Loading and running this image in Docker results
|
||||
in <literal>redis-server</literal> being started automatically.
|
||||
</para>
|
||||
|
||||
<calloutlist>
|
||||
<callout arearefs='ex-dockerTools-buildImage-1'>
|
||||
<para>
|
||||
<varname>name</varname> specifies the name of the resulting image. This
|
||||
is the only required argument for <varname>buildImage</varname>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-2'>
|
||||
<para>
|
||||
<varname>tag</varname> specifies the tag of the resulting image. By
|
||||
default it's <literal>null</literal>, which indicates that the nix output
|
||||
hash will be used as tag.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-3'>
|
||||
<para>
|
||||
<varname>fromImage</varname> is the repository tarball containing the
|
||||
base image. It must be a valid Docker image, such as exported by
|
||||
<command>docker save</command>. By default it's <literal>null</literal>,
|
||||
which can be seen as equivalent to <literal>FROM scratch</literal> of a
|
||||
<filename>Dockerfile</filename>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-4'>
|
||||
<para>
|
||||
<varname>fromImageName</varname> can be used to further specify the base
|
||||
image within the repository, in case it contains multiple images. By
|
||||
default it's <literal>null</literal>, in which case
|
||||
<varname>buildImage</varname> will peek the first image available in the
|
||||
repository.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-5'>
|
||||
<para>
|
||||
<varname>fromImageTag</varname> can be used to further specify the tag of
|
||||
the base image within the repository, in case an image contains multiple
|
||||
tags. By default it's <literal>null</literal>, in which case
|
||||
<varname>buildImage</varname> will peek the first tag available for the
|
||||
base image.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-6'>
|
||||
<para>
|
||||
<varname>contents</varname> is a derivation that will be copied in the
|
||||
new layer of the resulting image. This can be similarly seen as
|
||||
<command>ADD contents/ /</command> in a <filename>Dockerfile</filename>.
|
||||
By default it's <literal>null</literal>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-runAsRoot'>
|
||||
<para>
|
||||
<varname>runAsRoot</varname> is a bash script that will run as root in an
|
||||
environment that overlays the existing layers of the base image with the
|
||||
new resulting layer, including the previously copied
|
||||
<varname>contents</varname> derivation. This can be similarly seen as
|
||||
<command>RUN ...</command> in a <filename>Dockerfile</filename>.
|
||||
<note>
|
||||
<para>
|
||||
Using this parameter requires the <literal>kvm</literal> device to be
|
||||
available.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-8'>
|
||||
<para>
|
||||
<varname>config</varname> is used to specify the configuration of the
|
||||
containers that will be started off the built image in Docker. The
|
||||
available options are listed in the
|
||||
<link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions">
|
||||
Docker Image Specification v1.2.0 </link>.
|
||||
</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
|
||||
<para>
|
||||
After the new layer has been created, its closure (to which
|
||||
<varname>contents</varname>, <varname>config</varname> and
|
||||
<varname>runAsRoot</varname> contribute) will be copied in the layer
|
||||
itself. Only new dependencies that are not already in the existing layers
|
||||
will be copied.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
At the end of the process, only one new single layer will be produced and
|
||||
added to the resulting image.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The resulting repository will only list the single image
|
||||
<varname>image/tag</varname>. In the case of
|
||||
<xref linkend='ex-dockerTools-buildImage'/> it would be
|
||||
<varname>redis/latest</varname>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is possible to inspect the arguments with which an image was built using
|
||||
its <varname>buildArgs</varname> attribute.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
If you see errors similar to <literal>getProtocolByName: does not exist
|
||||
(no such protocol name: tcp)</literal> you may need to add
|
||||
<literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
If you see errors similar to <literal>Error_Protocol ("certificate has
|
||||
unknown CA",True,UnknownCa)</literal> you may need to add
|
||||
<literal>pkgs.cacert</literal> to <varname>contents</varname>.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-fetchFromRegistry">
|
||||
<title>pullImage</title>
|
||||
|
||||
<para>
|
||||
This function is analogous to the <command>docker pull</command> command,
|
||||
in that can be used to pull a Docker image from a Docker registry. By
|
||||
default <link xlink:href="https://hub.docker.com/">Docker Hub</link> is
|
||||
used to pull images.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Its parameters are described in the example below:
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-dockerTools-pullImage'>
|
||||
<title>Docker pull</title>
|
||||
<programlisting>
|
||||
pullImage {
|
||||
imageName = "nixos/nix"; <co xml:id='ex-dockerTools-pullImage-1' />
|
||||
imageDigest = "sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b"; <co xml:id='ex-dockerTools-pullImage-2' />
|
||||
finalImageTag = "1.11"; <co xml:id='ex-dockerTools-pullImage-3' />
|
||||
sha256 = "0mqjy3zq2v6rrhizgb9nvhczl87lcfphq9601wcprdika2jz7qh8"; <co xml:id='ex-dockerTools-pullImage-4' />
|
||||
os = "linux"; <co xml:id='ex-dockerTools-pullImage-5' />
|
||||
arch = "x86_64"; <co xml:id='ex-dockerTools-pullImage-6' />
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<calloutlist>
|
||||
<callout arearefs='ex-dockerTools-pullImage-1'>
|
||||
<para>
|
||||
<varname>imageName</varname> specifies the name of the image to be
|
||||
downloaded, which can also include the registry namespace (e.g.
|
||||
<literal>nixos</literal>). This argument is required.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-2'>
|
||||
<para>
|
||||
<varname>imageDigest</varname> specifies the digest of the image to be
|
||||
downloaded. Skopeo can be used to get the digest of an image, with its
|
||||
<varname>inspect</varname> subcommand. Since a given
|
||||
<varname>imageName</varname> may transparently refer to a manifest list
|
||||
of images which support multiple architectures and/or operating systems,
|
||||
supply the `--override-os` and `--override-arch` arguments to specify
|
||||
exactly which image you want. By default it will match the OS and
|
||||
architecture of the host the command is run on.
|
||||
<programlisting>
|
||||
$ nix-shell --packages skopeo jq --command "skopeo --override-os linux --override-arch x86_64 inspect docker://docker.io/nixos/nix:1.11 | jq -r '.Digest'"
|
||||
sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
|
||||
</programlisting>
|
||||
This argument is required.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-3'>
|
||||
<para>
|
||||
<varname>finalImageTag</varname>, if specified, this is the tag of the
|
||||
image to be created. Note it is never used to fetch the image since we
|
||||
prefer to rely on the immutable digest ID. By default it's
|
||||
<literal>latest</literal>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-4'>
|
||||
<para>
|
||||
<varname>sha256</varname> is the checksum of the whole fetched image.
|
||||
This argument is required.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-5'>
|
||||
<para>
|
||||
<varname>os</varname>, if specified, is the operating system of the
|
||||
fetched image. By default it's <literal>linux</literal>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-6'>
|
||||
<para>
|
||||
<varname>arch</varname>, if specified, is the cpu architecture of the
|
||||
fetched image. By default it's <literal>x86_64</literal>.
|
||||
</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-exportImage">
|
||||
<title>exportImage</title>
|
||||
|
||||
<para>
|
||||
This function is analogous to the <command>docker export</command> command,
|
||||
in that can used to flatten a Docker image that contains multiple layers.
|
||||
It is in fact the result of the merge of all the layers of the image. As
|
||||
such, the result is suitable for being imported in Docker with
|
||||
<command>docker import</command>.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Using this function requires the <literal>kvm</literal> device to be
|
||||
available.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
The parameters of <varname>exportImage</varname> are the following:
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-dockerTools-exportImage'>
|
||||
<title>Docker export</title>
|
||||
<programlisting>
|
||||
exportImage {
|
||||
fromImage = someLayeredImage;
|
||||
fromImageName = null;
|
||||
fromImageTag = null;
|
||||
|
||||
name = someLayeredImage.name;
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>
|
||||
The parameters relative to the base image have the same synopsis as
|
||||
described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except
|
||||
that <varname>fromImage</varname> is the only required argument in this
|
||||
case.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <varname>name</varname> argument is the name of the derivation output,
|
||||
which defaults to <varname>fromImage.name</varname>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-shadowSetup">
|
||||
<title>shadowSetup</title>
|
||||
|
||||
<para>
|
||||
This constant string is a helper for setting up the base files for managing
|
||||
users and groups, only if such files don't exist already. It is suitable
|
||||
for being used in a <varname>runAsRoot</varname>
|
||||
<xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like
|
||||
in the example below:
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-dockerTools-shadowSetup'>
|
||||
<title>Shadow base files</title>
|
||||
<programlisting>
|
||||
buildImage {
|
||||
name = "shadow-basic";
|
||||
|
||||
runAsRoot = ''
|
||||
#!${stdenv.shell}
|
||||
${shadowSetup}
|
||||
groupadd -r redis
|
||||
useradd -r -g redis redis
|
||||
mkdir /data
|
||||
chown redis:redis /data
|
||||
'';
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>
|
||||
Creating base files like <literal>/etc/passwd</literal> or
|
||||
<literal>/etc/login.defs</literal> are necessary for shadow-utils to
|
||||
manipulate users and groups.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
<xi:include href="functions/library.xml" />
|
||||
<xi:include href="functions/overrides.xml" />
|
||||
<xi:include href="functions/generators.xml" />
|
||||
<xi:include href="functions/debug.xml" />
|
||||
<xi:include href="functions/fhs-environments.xml" />
|
||||
<xi:include href="functions/shell.xml" />
|
||||
<xi:include href="functions/dockertools.xml" />
|
||||
</chapter>
|
||||
|
21
doc/functions/debug.xml
Normal file
21
doc/functions/debug.xml
Normal file
@ -0,0 +1,21 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-debug">
|
||||
<title>Debugging Nix Expressions</title>
|
||||
|
||||
<para>
|
||||
Nix is a unityped, dynamic language, this means every value can potentially
|
||||
appear anywhere. Since it is also non-strict, evaluation order and what
|
||||
ultimately is evaluated might surprise you. Therefore it is important to be
|
||||
able to debug nix expressions.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the <literal>lib/debug.nix</literal> file you will find a number of
|
||||
functions that help (pretty-)printing values while evaluation is runnnig. You
|
||||
can even specify how deep these values should be printed recursively, and
|
||||
transform them on the fly. Please consult the docstrings in
|
||||
<literal>lib/debug.nix</literal> for usage information.
|
||||
</para>
|
||||
</section>
|
564
doc/functions/dockertools.xml
Normal file
564
doc/functions/dockertools.xml
Normal file
@ -0,0 +1,564 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-pkgs-dockerTools">
|
||||
<title>pkgs.dockerTools</title>
|
||||
|
||||
<para>
|
||||
<varname>pkgs.dockerTools</varname> is a set of functions for creating and
|
||||
manipulating Docker images according to the
|
||||
<link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#docker-image-specification-v120">
|
||||
Docker Image Specification v1.2.0 </link>. Docker itself is not used to
|
||||
perform any of the operations done by these functions.
|
||||
</para>
|
||||
|
||||
<warning>
|
||||
<para>
|
||||
The <varname>dockerTools</varname> API is unstable and may be subject to
|
||||
backwards-incompatible changes in the future.
|
||||
</para>
|
||||
</warning>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-buildImage">
|
||||
<title>buildImage</title>
|
||||
|
||||
<para>
|
||||
This function is analogous to the <command>docker build</command> command,
|
||||
in that can used to build a Docker-compatible repository tarball containing
|
||||
a single image with one or multiple layers. As such, the result is suitable
|
||||
for being loaded in Docker with <command>docker load</command>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The parameters of <varname>buildImage</varname> with relative example values
|
||||
are described below:
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-dockerTools-buildImage'>
|
||||
<title>Docker build</title>
|
||||
<programlisting>
|
||||
buildImage {
|
||||
name = "redis"; <co xml:id='ex-dockerTools-buildImage-1' />
|
||||
tag = "latest"; <co xml:id='ex-dockerTools-buildImage-2' />
|
||||
|
||||
fromImage = someBaseImage; <co xml:id='ex-dockerTools-buildImage-3' />
|
||||
fromImageName = null; <co xml:id='ex-dockerTools-buildImage-4' />
|
||||
fromImageTag = "latest"; <co xml:id='ex-dockerTools-buildImage-5' />
|
||||
|
||||
contents = pkgs.redis; <co xml:id='ex-dockerTools-buildImage-6' />
|
||||
runAsRoot = '' <co xml:id='ex-dockerTools-buildImage-runAsRoot' />
|
||||
#!${stdenv.shell}
|
||||
mkdir -p /data
|
||||
'';
|
||||
|
||||
config = { <co xml:id='ex-dockerTools-buildImage-8' />
|
||||
Cmd = [ "/bin/redis-server" ];
|
||||
WorkingDir = "/data";
|
||||
Volumes = {
|
||||
"/data" = {};
|
||||
};
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>
|
||||
The above example will build a Docker image <literal>redis/latest</literal>
|
||||
from the given base image. Loading and running this image in Docker results
|
||||
in <literal>redis-server</literal> being started automatically.
|
||||
</para>
|
||||
|
||||
<calloutlist>
|
||||
<callout arearefs='ex-dockerTools-buildImage-1'>
|
||||
<para>
|
||||
<varname>name</varname> specifies the name of the resulting image. This is
|
||||
the only required argument for <varname>buildImage</varname>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-2'>
|
||||
<para>
|
||||
<varname>tag</varname> specifies the tag of the resulting image. By
|
||||
default it's <literal>null</literal>, which indicates that the nix output
|
||||
hash will be used as tag.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-3'>
|
||||
<para>
|
||||
<varname>fromImage</varname> is the repository tarball containing the base
|
||||
image. It must be a valid Docker image, such as exported by
|
||||
<command>docker save</command>. By default it's <literal>null</literal>,
|
||||
which can be seen as equivalent to <literal>FROM scratch</literal> of a
|
||||
<filename>Dockerfile</filename>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-4'>
|
||||
<para>
|
||||
<varname>fromImageName</varname> can be used to further specify the base
|
||||
image within the repository, in case it contains multiple images. By
|
||||
default it's <literal>null</literal>, in which case
|
||||
<varname>buildImage</varname> will peek the first image available in the
|
||||
repository.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-5'>
|
||||
<para>
|
||||
<varname>fromImageTag</varname> can be used to further specify the tag of
|
||||
the base image within the repository, in case an image contains multiple
|
||||
tags. By default it's <literal>null</literal>, in which case
|
||||
<varname>buildImage</varname> will peek the first tag available for the
|
||||
base image.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-6'>
|
||||
<para>
|
||||
<varname>contents</varname> is a derivation that will be copied in the new
|
||||
layer of the resulting image. This can be similarly seen as <command>ADD
|
||||
contents/ /</command> in a <filename>Dockerfile</filename>. By default
|
||||
it's <literal>null</literal>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-runAsRoot'>
|
||||
<para>
|
||||
<varname>runAsRoot</varname> is a bash script that will run as root in an
|
||||
environment that overlays the existing layers of the base image with the
|
||||
new resulting layer, including the previously copied
|
||||
<varname>contents</varname> derivation. This can be similarly seen as
|
||||
<command>RUN ...</command> in a <filename>Dockerfile</filename>.
|
||||
<note>
|
||||
<para>
|
||||
Using this parameter requires the <literal>kvm</literal> device to be
|
||||
available.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-8'>
|
||||
<para>
|
||||
<varname>config</varname> is used to specify the configuration of the
|
||||
containers that will be started off the built image in Docker. The
|
||||
available options are listed in the
|
||||
<link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions">
|
||||
Docker Image Specification v1.2.0 </link>.
|
||||
</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
|
||||
<para>
|
||||
After the new layer has been created, its closure (to which
|
||||
<varname>contents</varname>, <varname>config</varname> and
|
||||
<varname>runAsRoot</varname> contribute) will be copied in the layer itself.
|
||||
Only new dependencies that are not already in the existing layers will be
|
||||
copied.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
At the end of the process, only one new single layer will be produced and
|
||||
added to the resulting image.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The resulting repository will only list the single image
|
||||
<varname>image/tag</varname>. In the case of
|
||||
<xref linkend='ex-dockerTools-buildImage'/> it would be
|
||||
<varname>redis/latest</varname>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is possible to inspect the arguments with which an image was built using
|
||||
its <varname>buildArgs</varname> attribute.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
If you see errors similar to <literal>getProtocolByName: does not exist (no
|
||||
such protocol name: tcp)</literal> you may need to add
|
||||
<literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
If you see errors similar to <literal>Error_Protocol ("certificate has
|
||||
unknown CA",True,UnknownCa)</literal> you may need to add
|
||||
<literal>pkgs.cacert</literal> to <varname>contents</varname>.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<example xml:id="example-pkgs-dockerTools-buildImage-creation-date">
|
||||
<title>Impurely Defining a Docker Layer's Creation Date</title>
|
||||
<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 list images</command>, the newly created images will be
|
||||
listed like this:
|
||||
</para>
|
||||
<screen><![CDATA[
|
||||
$ docker image list
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
hello latest 08c791c7846e 48 years ago 25.2MB
|
||||
]]></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>
|
||||
<programlisting><![CDATA[
|
||||
pkgs.dockerTools.buildImage {
|
||||
name = "hello";
|
||||
tag = "latest";
|
||||
created = "now";
|
||||
contents = pkgs.hello;
|
||||
|
||||
config.Cmd = [ "/bin/hello" ];
|
||||
}
|
||||
]]></programlisting>
|
||||
<para>
|
||||
and now the Docker CLI will display a reasonable date and sort the images
|
||||
as expected:
|
||||
<screen><![CDATA[
|
||||
$ docker image list
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
hello latest de2bf4786de6 About a minute ago 25.2MB
|
||||
]]></screen>
|
||||
however, the produced images will not be binary reproducible.
|
||||
</para>
|
||||
</example>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-buildLayeredImage">
|
||||
<title>buildLayeredImage</title>
|
||||
|
||||
<para>
|
||||
Create a Docker image with many of the store paths being on their own layer
|
||||
to improve sharing between images.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>name</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name of the resulting image.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>tag</varname> <emphasis>optional</emphasis>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Tag of the generated image.
|
||||
</para>
|
||||
<para>
|
||||
<emphasis>Default:</emphasis> the output path's hash
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>contents</varname> <emphasis>optional</emphasis>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Top level paths in the container. Either a single derivation, or a list
|
||||
of derivations.
|
||||
</para>
|
||||
<para>
|
||||
<emphasis>Default:</emphasis> <literal>[]</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>config</varname> <emphasis>optional</emphasis>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Run-time configuration of the container. A full list of the options are
|
||||
available at in the
|
||||
<link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions">
|
||||
Docker Image Specification v1.2.0 </link>.
|
||||
</para>
|
||||
<para>
|
||||
<emphasis>Default:</emphasis> <literal>{}</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>created</varname> <emphasis>optional</emphasis>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Date and time the layers were created. Follows the same
|
||||
<literal>now</literal> exception supported by
|
||||
<literal>buildImage</literal>.
|
||||
</para>
|
||||
<para>
|
||||
<emphasis>Default:</emphasis> <literal>1970-01-01T00:00:01Z</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>maxLayers</varname> <emphasis>optional</emphasis>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Maximum number of layers to create.
|
||||
</para>
|
||||
<para>
|
||||
<emphasis>Default:</emphasis> <literal>24</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<section xml:id="dockerTools-buildLayeredImage-arg-contents">
|
||||
<title>Behavior of <varname>contents</varname> in the final image</title>
|
||||
|
||||
<para>
|
||||
Each path directly listed in <varname>contents</varname> will have a
|
||||
symlink in the root of the image.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For example:
|
||||
<programlisting><![CDATA[
|
||||
pkgs.dockerTools.buildLayeredImage {
|
||||
name = "hello";
|
||||
contents = [ pkgs.hello ];
|
||||
}
|
||||
]]></programlisting>
|
||||
will create symlinks for all the paths in the <literal>hello</literal>
|
||||
package:
|
||||
<screen><![CDATA[
|
||||
/bin/hello -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/bin/hello
|
||||
/share/info/hello.info -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/share/info/hello.info
|
||||
/share/locale/bg/LC_MESSAGES/hello.mo -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/share/locale/bg/LC_MESSAGES/hello.mo
|
||||
]]></screen>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="dockerTools-buildLayeredImage-arg-config">
|
||||
<title>Automatic inclusion of <varname>config</varname> references</title>
|
||||
|
||||
<para>
|
||||
The closure of <varname>config</varname> is automatically included in the
|
||||
closure of the final image.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This allows you to make very simple Docker images with very little code.
|
||||
This container will start up and run <command>hello</command>:
|
||||
<programlisting><![CDATA[
|
||||
pkgs.dockerTools.buildLayeredImage {
|
||||
name = "hello";
|
||||
config.Cmd = [ "${pkgs.hello}/bin/hello" ];
|
||||
}
|
||||
]]></programlisting>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="dockerTools-buildLayeredImage-arg-maxLayers">
|
||||
<title>Adjusting <varname>maxLayers</varname></title>
|
||||
|
||||
<para>
|
||||
Increasing the <varname>maxLayers</varname> increases the number of layers
|
||||
which have a chance to be shared between different images.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Modern Docker installations support up to 128 layers, however older
|
||||
versions support as few as 42.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the produced image will not be extended by other Docker builds, it is
|
||||
safe to set <varname>maxLayers</varname> to <literal>128</literal>. However
|
||||
it will be impossible to extend the image further.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The first (<literal>maxLayers-2</literal>) most "popular" paths will have
|
||||
their own individual layers, then layer #<literal>maxLayers-1</literal>
|
||||
will contain all the remaining "unpopular" paths, and finally layer
|
||||
#<literal>maxLayers</literal> will contain the Image configuration.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Docker's Layers are not inherently ordered, they are content-addressable
|
||||
and are not explicitly layered until they are composed in to an Image.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-fetchFromRegistry">
|
||||
<title>pullImage</title>
|
||||
|
||||
<para>
|
||||
This function is analogous to the <command>docker pull</command> command, in
|
||||
that can be used to pull a Docker image from a Docker registry. By default
|
||||
<link xlink:href="https://hub.docker.com/">Docker Hub</link> is used to pull
|
||||
images.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Its parameters are described in the example below:
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-dockerTools-pullImage'>
|
||||
<title>Docker pull</title>
|
||||
<programlisting>
|
||||
pullImage {
|
||||
imageName = "nixos/nix"; <co xml:id='ex-dockerTools-pullImage-1' />
|
||||
imageDigest = "sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b"; <co xml:id='ex-dockerTools-pullImage-2' />
|
||||
finalImageTag = "1.11"; <co xml:id='ex-dockerTools-pullImage-3' />
|
||||
sha256 = "0mqjy3zq2v6rrhizgb9nvhczl87lcfphq9601wcprdika2jz7qh8"; <co xml:id='ex-dockerTools-pullImage-4' />
|
||||
os = "linux"; <co xml:id='ex-dockerTools-pullImage-5' />
|
||||
arch = "x86_64"; <co xml:id='ex-dockerTools-pullImage-6' />
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<calloutlist>
|
||||
<callout arearefs='ex-dockerTools-pullImage-1'>
|
||||
<para>
|
||||
<varname>imageName</varname> specifies the name of the image to be
|
||||
downloaded, which can also include the registry namespace (e.g.
|
||||
<literal>nixos</literal>). This argument is required.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-2'>
|
||||
<para>
|
||||
<varname>imageDigest</varname> specifies the digest of the image to be
|
||||
downloaded. Skopeo can be used to get the digest of an image, with its
|
||||
<varname>inspect</varname> subcommand. Since a given
|
||||
<varname>imageName</varname> may transparently refer to a manifest list of
|
||||
images which support multiple architectures and/or operating systems,
|
||||
supply the `--override-os` and `--override-arch` arguments to specify
|
||||
exactly which image you want. By default it will match the OS and
|
||||
architecture of the host the command is run on.
|
||||
<programlisting>
|
||||
$ nix-shell --packages skopeo jq --command "skopeo --override-os linux --override-arch x86_64 inspect docker://docker.io/nixos/nix:1.11 | jq -r '.Digest'"
|
||||
sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
|
||||
</programlisting>
|
||||
This argument is required.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-3'>
|
||||
<para>
|
||||
<varname>finalImageTag</varname>, if specified, this is the tag of the
|
||||
image to be created. Note it is never used to fetch the image since we
|
||||
prefer to rely on the immutable digest ID. By default it's
|
||||
<literal>latest</literal>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-4'>
|
||||
<para>
|
||||
<varname>sha256</varname> is the checksum of the whole fetched image. This
|
||||
argument is required.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-5'>
|
||||
<para>
|
||||
<varname>os</varname>, if specified, is the operating system of the
|
||||
fetched image. By default it's <literal>linux</literal>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-6'>
|
||||
<para>
|
||||
<varname>arch</varname>, if specified, is the cpu architecture of the
|
||||
fetched image. By default it's <literal>x86_64</literal>.
|
||||
</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-exportImage">
|
||||
<title>exportImage</title>
|
||||
|
||||
<para>
|
||||
This function is analogous to the <command>docker export</command> command,
|
||||
in that can used to flatten a Docker image that contains multiple layers. It
|
||||
is in fact the result of the merge of all the layers of the image. As such,
|
||||
the result is suitable for being imported in Docker with <command>docker
|
||||
import</command>.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Using this function requires the <literal>kvm</literal> device to be
|
||||
available.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
The parameters of <varname>exportImage</varname> are the following:
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-dockerTools-exportImage'>
|
||||
<title>Docker export</title>
|
||||
<programlisting>
|
||||
exportImage {
|
||||
fromImage = someLayeredImage;
|
||||
fromImageName = null;
|
||||
fromImageTag = null;
|
||||
|
||||
name = someLayeredImage.name;
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>
|
||||
The parameters relative to the base image have the same synopsis as
|
||||
described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except that
|
||||
<varname>fromImage</varname> is the only required argument in this case.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <varname>name</varname> argument is the name of the derivation output,
|
||||
which defaults to <varname>fromImage.name</varname>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-shadowSetup">
|
||||
<title>shadowSetup</title>
|
||||
|
||||
<para>
|
||||
This constant string is a helper for setting up the base files for managing
|
||||
users and groups, only if such files don't exist already. It is suitable for
|
||||
being used in a <varname>runAsRoot</varname>
|
||||
<xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like
|
||||
in the example below:
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-dockerTools-shadowSetup'>
|
||||
<title>Shadow base files</title>
|
||||
<programlisting>
|
||||
buildImage {
|
||||
name = "shadow-basic";
|
||||
|
||||
runAsRoot = ''
|
||||
#!${stdenv.shell}
|
||||
${shadowSetup}
|
||||
groupadd -r redis
|
||||
useradd -r -g redis redis
|
||||
mkdir /data
|
||||
chown redis:redis /data
|
||||
'';
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>
|
||||
Creating base files like <literal>/etc/passwd</literal> or
|
||||
<literal>/etc/login.defs</literal> are necessary for shadow-utils to
|
||||
manipulate users and groups.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
142
doc/functions/fhs-environments.xml
Normal file
142
doc/functions/fhs-environments.xml
Normal file
@ -0,0 +1,142 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-fhs-environments">
|
||||
<title>buildFHSUserEnv</title>
|
||||
|
||||
<para>
|
||||
<function>buildFHSUserEnv</function> provides a way to build and run
|
||||
FHS-compatible lightweight sandboxes. It creates an isolated root with bound
|
||||
<filename>/nix/store</filename>, so its footprint in terms of disk space
|
||||
needed is quite small. This allows one to run software which is hard or
|
||||
unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions,
|
||||
games distributed as tarballs, software with integrity checking and/or
|
||||
external self-updated binaries. It uses Linux namespaces feature to create
|
||||
temporary lightweight environments which are destroyed after all child
|
||||
processes exit, without root user rights requirement. Accepted arguments are:
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>name</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Environment name.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>targetPkgs</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Packages to be installed for the main host's architecture (i.e. x86_64 on
|
||||
x86_64 installations). Along with libraries binaries are also installed.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>multiPkgs</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Packages to be installed for all architectures supported by a host (i.e.
|
||||
i686 and x86_64 on x86_64 installations). Only libraries are installed by
|
||||
default.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>extraBuildCommands</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Additional commands to be executed for finalizing the directory structure.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>extraBuildCommandsMulti</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Like <literal>extraBuildCommands</literal>, but executed only on multilib
|
||||
architectures.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>extraOutputsToInstall</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Additional derivation outputs to be linked for both target and
|
||||
multi-architecture packages.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>extraInstallCommands</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Additional commands to be executed for finalizing the derivation with
|
||||
runner script.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>runScript</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
A command that would be executed inside the sandbox and passed all the
|
||||
command line arguments. It defaults to <literal>bash</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>
|
||||
One can create a simple environment using a <literal>shell.nix</literal> like
|
||||
that:
|
||||
</para>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
|
||||
(pkgs.buildFHSUserEnv {
|
||||
name = "simple-x11-env";
|
||||
targetPkgs = pkgs: (with pkgs;
|
||||
[ udev
|
||||
alsaLib
|
||||
]) ++ (with pkgs.xorg;
|
||||
[ libX11
|
||||
libXcursor
|
||||
libXrandr
|
||||
]);
|
||||
multiPkgs = pkgs: (with pkgs;
|
||||
[ udev
|
||||
alsaLib
|
||||
]);
|
||||
runScript = "bash";
|
||||
}).env
|
||||
]]></programlisting>
|
||||
|
||||
<para>
|
||||
Running <literal>nix-shell</literal> would then drop you into a shell with
|
||||
these libraries and binaries available. You can use this to run closed-source
|
||||
applications which expect FHS structure without hassles: simply change
|
||||
<literal>runScript</literal> to the application path, e.g.
|
||||
<filename>./bin/start.sh</filename> -- relative paths are supported.
|
||||
</para>
|
||||
</section>
|
89
doc/functions/generators.xml
Normal file
89
doc/functions/generators.xml
Normal file
@ -0,0 +1,89 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-generators">
|
||||
<title>Generators</title>
|
||||
|
||||
<para>
|
||||
Generators are functions that create file formats from nix data structures,
|
||||
e. g. for configuration files. There are generators available for:
|
||||
<literal>INI</literal>, <literal>JSON</literal> and <literal>YAML</literal>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
All generators follow a similar call interface: <code>generatorName
|
||||
configFunctions data</code>, where <literal>configFunctions</literal> is an
|
||||
attrset of user-defined functions that format nested parts of the content.
|
||||
They each have common defaults, so often they do not need to be set manually.
|
||||
An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]" ]
|
||||
name)</code> from the <literal>INI</literal> generator. It receives the name
|
||||
of a section and sanitizes it. The default <literal>mkSectionName</literal>
|
||||
escapes <literal>[</literal> and <literal>]</literal> with a backslash.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Generators can be fine-tuned to produce exactly the file format required by
|
||||
your application/service. One example is an INI-file format which uses
|
||||
<literal>: </literal> as separator, the strings
|
||||
<literal>"yes"</literal>/<literal>"no"</literal> as boolean values and
|
||||
requires all string values to be quoted:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
with lib;
|
||||
let
|
||||
customToINI = generators.toINI {
|
||||
# specifies how to format a key/value pair
|
||||
mkKeyValue = generators.mkKeyValueDefault {
|
||||
# specifies the generated string for a subset of nix values
|
||||
mkValueString = v:
|
||||
if v == true then ''"yes"''
|
||||
else if v == false then ''"no"''
|
||||
else if isString v then ''"${v}"''
|
||||
# and delegats all other values to the default generator
|
||||
else generators.mkValueStringDefault {} v;
|
||||
} ":";
|
||||
};
|
||||
|
||||
# the INI file can now be given as plain old nix values
|
||||
in customToINI {
|
||||
main = {
|
||||
pushinfo = true;
|
||||
autopush = false;
|
||||
host = "localhost";
|
||||
port = 42;
|
||||
};
|
||||
mergetool = {
|
||||
merge = "diff3";
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
This will produce the following INI file as nix string:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
[main]
|
||||
autopush:"no"
|
||||
host:"localhost"
|
||||
port:42
|
||||
pushinfo:"yes"
|
||||
str\:ange:"very::strange"
|
||||
|
||||
[mergetool]
|
||||
merge:"diff3"
|
||||
</programlisting>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Nix store paths can be converted to strings by enclosing a derivation
|
||||
attribute like so: <code>"${drv}"</code>.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
Detailed documentation for each generator can be found in
|
||||
<literal>lib/generators.nix</literal>.
|
||||
</para>
|
||||
</section>
|
15
doc/functions/library.xml
Normal file
15
doc/functions/library.xml
Normal file
@ -0,0 +1,15 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-functions-library">
|
||||
<title>Nixpkgs Library Functions</title>
|
||||
|
||||
<para>
|
||||
Nixpkgs provides a standard library at <varname>pkgs.lib</varname>, or
|
||||
through <code>import <nixpkgs/lib></code>.
|
||||
</para>
|
||||
|
||||
<xi:include href="./library/asserts.xml" />
|
||||
|
||||
<xi:include href="./library/attrsets.xml" />
|
||||
</section>
|
117
doc/functions/library/asserts.xml
Normal file
117
doc/functions/library/asserts.xml
Normal file
@ -0,0 +1,117 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-functions-library-asserts">
|
||||
<title>Assert functions</title>
|
||||
|
||||
<section xml:id="function-library-lib.asserts.assertMsg">
|
||||
<title><function>lib.asserts.assertMsg</function></title>
|
||||
|
||||
<subtitle><literal>assertMsg :: Bool -> String -> Bool</literal>
|
||||
</subtitle>
|
||||
|
||||
<xi:include href="./locations.xml" xpointer="lib.asserts.assertMsg" />
|
||||
|
||||
<para>
|
||||
Print a trace message if <literal>pred</literal> is false.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Intended to be used to augment asserts with helpful error messages.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>pred</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Condition under which the <varname>msg</varname> should
|
||||
<emphasis>not</emphasis> be printed.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>msg</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Message to print.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<example xml:id="function-library-lib.asserts.assertMsg-example-false">
|
||||
<title>Printing when the predicate is false</title>
|
||||
<programlisting><![CDATA[
|
||||
assert lib.asserts.assertMsg ("foo" == "bar") "foo is not bar, silly"
|
||||
stderr> trace: foo is not bar, silly
|
||||
stderr> assert failed
|
||||
]]></programlisting>
|
||||
</example>
|
||||
</section>
|
||||
|
||||
<section xml:id="function-library-lib.asserts.assertOneOf">
|
||||
<title><function>lib.asserts.assertOneOf</function></title>
|
||||
|
||||
<subtitle><literal>assertOneOf :: String -> String ->
|
||||
StringList -> Bool</literal>
|
||||
</subtitle>
|
||||
|
||||
<xi:include href="./locations.xml" xpointer="lib.asserts.assertOneOf" />
|
||||
|
||||
<para>
|
||||
Specialized <function>asserts.assertMsg</function> for checking if
|
||||
<varname>val</varname> is one of the elements of <varname>xs</varname>.
|
||||
Useful for checking enums.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>name</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name of the variable the user entered <varname>val</varname> into,
|
||||
for inclusion in the error message.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>val</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The value of what the user provided, to be compared against the values in
|
||||
<varname>xs</varname>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>xs</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The list of valid values.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<example xml:id="function-library-lib.asserts.assertOneOf-example">
|
||||
<title>Ensuring a user provided a possible value</title>
|
||||
<programlisting><![CDATA[
|
||||
let sslLibrary = "bearssl";
|
||||
in lib.asserts.assertOneOf "sslLibrary" sslLibrary [ "openssl" "bearssl" ];
|
||||
=> false
|
||||
stderr> trace: sslLibrary must be one of "openssl", "libressl", but is: "bearssl"
|
||||
]]></programlisting>
|
||||
</example>
|
||||
</section>
|
||||
</section>
|
1731
doc/functions/library/attrsets.xml
Normal file
1731
doc/functions/library/attrsets.xml
Normal file
File diff suppressed because it is too large
Load Diff
212
doc/functions/overrides.xml
Normal file
212
doc/functions/overrides.xml
Normal file
@ -0,0 +1,212 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-overrides">
|
||||
<title>Overriding</title>
|
||||
|
||||
<para>
|
||||
Sometimes one wants to override parts of <literal>nixpkgs</literal>, e.g.
|
||||
derivation attributes, the results of derivations.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
These functions are used to make changes to packages, returning only single
|
||||
packages. <link xlink:href="#chap-overlays">Overlays</link>, on the other
|
||||
hand, can be used to combine the overridden packages across the entire
|
||||
package set of Nixpkgs.
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-pkg-override">
|
||||
<title><pkg>.override</title>
|
||||
|
||||
<para>
|
||||
The function <varname>override</varname> is usually available for all the
|
||||
derivations in the nixpkgs expression (<varname>pkgs</varname>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is used to override the arguments passed to a function.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example usages:
|
||||
<programlisting>pkgs.foo.override { arg1 = val1; arg2 = val2; ... }</programlisting>
|
||||
<!-- TODO: move below programlisting to a new section about extending and overlays
|
||||
and reference it
|
||||
-->
|
||||
<programlisting>
|
||||
import pkgs.path { overlays = [ (self: super: {
|
||||
foo = super.foo.override { barSupport = true ; };
|
||||
})]};
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
mypkg = pkgs.callPackage ./mypkg.nix {
|
||||
mydep = pkgs.mydep.override { ... };
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the first example, <varname>pkgs.foo</varname> is the result of a
|
||||
function call with some default arguments, usually a derivation. Using
|
||||
<varname>pkgs.foo.override</varname> will call the same function with the
|
||||
given new arguments.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-pkg-overrideAttrs">
|
||||
<title><pkg>.overrideAttrs</title>
|
||||
|
||||
<para>
|
||||
The function <varname>overrideAttrs</varname> allows overriding the
|
||||
attribute set passed to a <varname>stdenv.mkDerivation</varname> call,
|
||||
producing a new derivation based on the original one. This function is
|
||||
available on all derivations produced by the
|
||||
<varname>stdenv.mkDerivation</varname> function, which is most packages in
|
||||
the nixpkgs expression <varname>pkgs</varname>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example usage:
|
||||
<programlisting>
|
||||
helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
|
||||
separateDebugInfo = true;
|
||||
});
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the above example, the <varname>separateDebugInfo</varname> attribute is
|
||||
overridden to be true, thus building debug info for
|
||||
<varname>helloWithDebug</varname>, while all other attributes will be
|
||||
retained from the original <varname>hello</varname> package.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The argument <varname>oldAttrs</varname> is conventionally used to refer to
|
||||
the attr set originally passed to <varname>stdenv.mkDerivation</varname>.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Note that <varname>separateDebugInfo</varname> is processed only by the
|
||||
<varname>stdenv.mkDerivation</varname> function, not the generated, raw Nix
|
||||
derivation. Thus, using <varname>overrideDerivation</varname> will not work
|
||||
in this case, as it overrides only the attributes of the final derivation.
|
||||
It is for this reason that <varname>overrideAttrs</varname> should be
|
||||
preferred in (almost) all cases to <varname>overrideDerivation</varname>,
|
||||
i.e. to allow using <varname>stdenv.mkDerivation</varname> to process input
|
||||
arguments, as well as the fact that it is easier to use (you can use the
|
||||
same attribute names you see in your Nix code, instead of the ones
|
||||
generated (e.g. <varname>buildInputs</varname> vs
|
||||
<varname>nativeBuildInputs</varname>), and it involves less typing).
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-pkg-overrideDerivation">
|
||||
<title><pkg>.overrideDerivation</title>
|
||||
|
||||
<warning>
|
||||
<para>
|
||||
You should prefer <varname>overrideAttrs</varname> in almost all cases, see
|
||||
its documentation for the reasons why.
|
||||
<varname>overrideDerivation</varname> is not deprecated and will continue
|
||||
to work, but is less nice to use and does not have as many abilities as
|
||||
<varname>overrideAttrs</varname>.
|
||||
</para>
|
||||
</warning>
|
||||
|
||||
<warning>
|
||||
<para>
|
||||
Do not use this function in Nixpkgs as it evaluates a Derivation before
|
||||
modifying it, which breaks package abstraction and removes error-checking
|
||||
of function arguments. In addition, this evaluation-per-function
|
||||
application incurs a performance penalty, which can become a problem if
|
||||
many overrides are used. It is only intended for ad-hoc customisation, such
|
||||
as in <filename>~/.config/nixpkgs/config.nix</filename>.
|
||||
</para>
|
||||
</warning>
|
||||
|
||||
<para>
|
||||
The function <varname>overrideDerivation</varname> creates a new derivation
|
||||
based on an existing one by overriding the original's attributes with the
|
||||
attribute set produced by the specified function. This function is available
|
||||
on all derivations defined using the <varname>makeOverridable</varname>
|
||||
function. Most standard derivation-producing functions, such as
|
||||
<varname>stdenv.mkDerivation</varname>, are defined using this function,
|
||||
which means most packages in the nixpkgs expression,
|
||||
<varname>pkgs</varname>, have this function.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example usage:
|
||||
<programlisting>
|
||||
mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
|
||||
name = "sed-4.2.2-pre";
|
||||
src = fetchurl {
|
||||
url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2;
|
||||
sha256 = "11nq06d131y4wmf3drm0yk502d2xc6n5qy82cg88rb9nqd2lj41k";
|
||||
};
|
||||
patches = [];
|
||||
});
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the above example, the <varname>name</varname>, <varname>src</varname>,
|
||||
and <varname>patches</varname> of the derivation will be overridden, while
|
||||
all other attributes will be retained from the original derivation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The argument <varname>oldAttrs</varname> is used to refer to the attribute
|
||||
set of the original derivation.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
A package's attributes are evaluated *before* being modified by the
|
||||
<varname>overrideDerivation</varname> function. For example, the
|
||||
<varname>name</varname> attribute reference in <varname>url =
|
||||
"mirror://gnu/hello/${name}.tar.gz";</varname> is filled-in *before* the
|
||||
<varname>overrideDerivation</varname> function modifies the attribute set.
|
||||
This means that overriding the <varname>name</varname> attribute, in this
|
||||
example, *will not* change the value of the <varname>url</varname>
|
||||
attribute. Instead, we need to override both the <varname>name</varname>
|
||||
*and* <varname>url</varname> attributes.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-lib-makeOverridable">
|
||||
<title>lib.makeOverridable</title>
|
||||
|
||||
<para>
|
||||
The function <varname>lib.makeOverridable</varname> is used to make the
|
||||
result of a function easily customizable. This utility only makes sense for
|
||||
functions that accept an argument set and return an attribute set.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example usage:
|
||||
<programlisting>
|
||||
f = { a, b }: { result = a+b; };
|
||||
c = lib.makeOverridable f { a = 1; b = 2; };
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The variable <varname>c</varname> is the value of the <varname>f</varname>
|
||||
function applied with some default arguments. Hence the value of
|
||||
<varname>c.result</varname> is <literal>3</literal>, in this example.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The variable <varname>c</varname> however also has some additional
|
||||
functions, like <link linkend="sec-pkg-override">c.override</link> which can
|
||||
be used to override the default arguments. In this example the value of
|
||||
<varname>(c.override { a = 4; }).result</varname> is 6.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
26
doc/functions/shell.xml
Normal file
26
doc/functions/shell.xml
Normal file
@ -0,0 +1,26 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-pkgs-mkShell">
|
||||
<title>pkgs.mkShell</title>
|
||||
|
||||
<para>
|
||||
<function>pkgs.mkShell</function> is a special kind of derivation that is
|
||||
only useful when using it combined with <command>nix-shell</command>. It will
|
||||
in fact fail to instantiate when invoked with <command>nix-build</command>.
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-pkgs-mkShell-usage">
|
||||
<title>Usage</title>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
pkgs.mkShell {
|
||||
# this will make all the build inputs from hello and gnutar
|
||||
# available to the shell environment
|
||||
inputsFrom = with pkgs; [ hello gnutar ];
|
||||
buildInputs = [ pkgs.gnumake ];
|
||||
}
|
||||
]]></programlisting>
|
||||
</section>
|
||||
</section>
|
@ -11,10 +11,9 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Some libraries require OCaml and sometimes also Camlp5 or findlib. The exact
|
||||
versions that were used to build Coq are saved in the
|
||||
<literal>coq.ocaml</literal> and <literal>coq.camlp5</literal> and
|
||||
<literal>coq.findlib</literal> attributes.
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -186,7 +186,7 @@ building Python libraries is `buildPythonPackage`. Let's see how we can build th
|
||||
`toolz` package.
|
||||
|
||||
```nix
|
||||
{ # ...
|
||||
{ lib, buildPythonPackage, fetchPypi }:
|
||||
|
||||
toolz = buildPythonPackage rec {
|
||||
pname = "toolz";
|
||||
@ -199,8 +199,8 @@ building Python libraries is `buildPythonPackage`. Let's see how we can build th
|
||||
|
||||
doCheck = false;
|
||||
|
||||
meta = {
|
||||
homepage = "https://github.com/pytoolz/toolz/";
|
||||
meta = with lib; {
|
||||
homepage = https://github.com/pytoolz/toolz;
|
||||
description = "List processing tools and functional utilities";
|
||||
license = licenses.bsd3;
|
||||
maintainers = with maintainers; [ fridh ];
|
||||
@ -267,12 +267,13 @@ that we introduced with the `let` expression.
|
||||
|
||||
#### Handling dependencies
|
||||
|
||||
Our example, `toolz`, does not have any dependencies on other Python
|
||||
packages or system libraries. According to the manual, `buildPythonPackage`
|
||||
uses the arguments `buildInputs` and `propagatedBuildInputs` to specify dependencies. If something is
|
||||
exclusively a build-time dependency, then the dependency should be included as a
|
||||
`buildInput`, but if it is (also) a runtime dependency, then it should be added
|
||||
to `propagatedBuildInputs`. Test dependencies are considered build-time dependencies.
|
||||
Our example, `toolz`, does not have any dependencies on other Python packages or
|
||||
system libraries. According to the manual, `buildPythonPackage` uses the
|
||||
arguments `buildInputs` and `propagatedBuildInputs` to specify dependencies. If
|
||||
something is exclusively a build-time dependency, then the dependency should be
|
||||
included as a `buildInput`, but if it is (also) a runtime dependency, then it
|
||||
should be added to `propagatedBuildInputs`. Test dependencies are considered
|
||||
build-time dependencies and passed to `checkInputs`.
|
||||
|
||||
The following example shows which arguments are given to `buildPythonPackage` in
|
||||
order to build [`datashape`](https://github.com/blaze/datashape).
|
||||
@ -292,7 +293,7 @@ order to build [`datashape`](https://github.com/blaze/datashape).
|
||||
checkInputs = with self; [ pytest ];
|
||||
propagatedBuildInputs = with self; [ numpy multipledispatch dateutil ];
|
||||
|
||||
meta = {
|
||||
meta = with lib; {
|
||||
homepage = https://github.com/ContinuumIO/datashape;
|
||||
description = "A data description language";
|
||||
license = licenses.bsd2;
|
||||
@ -326,7 +327,7 @@ when building the bindings and are therefore added as `buildInputs`.
|
||||
|
||||
buildInputs = with self; [ pkgs.libxml2 pkgs.libxslt ];
|
||||
|
||||
meta = {
|
||||
meta = with lib; {
|
||||
description = "Pythonic binding for the libxml2 and libxslt libraries";
|
||||
homepage = https://lxml.de;
|
||||
license = licenses.bsd3;
|
||||
@ -370,9 +371,9 @@ and `CFLAGS`.
|
||||
export CFLAGS="-I${pkgs.fftw.dev}/include -I${pkgs.fftwFloat.dev}/include -I${pkgs.fftwLongDouble.dev}/include"
|
||||
'';
|
||||
|
||||
meta = {
|
||||
meta = with lib; {
|
||||
description = "A pythonic wrapper around FFTW, the FFT library, presenting a unified interface for all the supported transforms";
|
||||
homepage = http://hgomersall.github.com/pyFFTW/;
|
||||
homepage = http://hgomersall.github.com/pyFFTW;
|
||||
license = with licenses; [ bsd2 bsd3 ];
|
||||
maintainers = with maintainers; [ fridh ];
|
||||
};
|
||||
@ -478,8 +479,6 @@ don't explicitly define which `python` derivation should be used. In the above
|
||||
example we use `buildPythonPackage` that is part of the set `python35Packages`,
|
||||
and in this case the `python35` interpreter is automatically used.
|
||||
|
||||
|
||||
|
||||
## Reference
|
||||
|
||||
### Interpreters
|
||||
@ -549,31 +548,31 @@ The `buildPythonPackage` function is implemented in
|
||||
|
||||
The following is an example:
|
||||
```nix
|
||||
{ lib, buildPythonPackage, fetchPypi, hypothesis, setuptools_scm, attrs, py, setuptools, six, pluggy }:
|
||||
|
||||
buildPythonPackage rec {
|
||||
version = "3.3.1";
|
||||
pname = "pytest";
|
||||
|
||||
preCheck = ''
|
||||
# don't test bash builtins
|
||||
rm testing/test_argcomplete.py
|
||||
'';
|
||||
version = "3.3.1";
|
||||
|
||||
src = fetchPypi {
|
||||
inherit pname version;
|
||||
sha256 = "cf8436dc59d8695346fcd3ab296de46425ecab00d64096cebe79fb51ecb2eb93";
|
||||
};
|
||||
|
||||
postPatch = ''
|
||||
# don't test bash builtins
|
||||
rm testing/test_argcomplete.py
|
||||
'';
|
||||
|
||||
checkInputs = [ hypothesis ];
|
||||
buildInputs = [ setuptools_scm ];
|
||||
propagatedBuildInputs = [ attrs py setuptools six pluggy ];
|
||||
|
||||
meta = with stdenv.lib; {
|
||||
meta = with lib; {
|
||||
maintainers = with maintainers; [ domenkozar lovek323 madjar lsix ];
|
||||
description = "Framework for writing tests";
|
||||
};
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
The `buildPythonPackage` mainly does four things:
|
||||
@ -655,6 +654,39 @@ Another difference is that `buildPythonPackage` by default prefixes the names of
|
||||
the packages with the version of the interpreter. Because this is irrelevant for
|
||||
applications, the prefix is omitted.
|
||||
|
||||
When packaging a python application with `buildPythonApplication`, it should be
|
||||
called with `callPackage` and passed `python` or `pythonPackages` (possibly
|
||||
specifying an interpreter version), like this:
|
||||
|
||||
```nix
|
||||
{ lib, python3Packages }:
|
||||
|
||||
python3Packages.buildPythonApplication rec {
|
||||
pname = "luigi";
|
||||
version = "2.7.9";
|
||||
|
||||
src = python3Packages.fetchPypi {
|
||||
inherit pname version;
|
||||
sha256 = "035w8gqql36zlan0xjrzz9j4lh9hs0qrsgnbyw07qs7lnkvbdv9x";
|
||||
};
|
||||
|
||||
propagatedBuildInputs = with python3Packages; [ tornado_4 pythondaemon ];
|
||||
|
||||
meta = with lib; {
|
||||
...
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
This is then added to `all-packages.nix` just as any other application would be.
|
||||
|
||||
```nix
|
||||
luigi = callPackage ../applications/networking/cluster/luigi { };
|
||||
```
|
||||
|
||||
Since the package is an application, a consumer doesn't need to care about
|
||||
python versions or modules, which is why they don't go in `pythonPackages`.
|
||||
|
||||
#### `toPythonApplication` function
|
||||
|
||||
A distinction is made between applications and libraries, however, sometimes a
|
||||
|
@ -64,9 +64,6 @@ When the `Cargo.lock`, provided by upstream, is not in sync with the
|
||||
added in `cargoPatches` will also be prepended to the patches in `patches` at
|
||||
build-time.
|
||||
|
||||
To install crates with nix there is also an experimental project called
|
||||
[nixcrates](https://github.com/fractalide/nixcrates).
|
||||
|
||||
## Compiling Rust crates using Nix instead of Cargo
|
||||
|
||||
### Simple operation
|
||||
|
@ -5,11 +5,17 @@ date: 2016-06-25
|
||||
---
|
||||
# User's Guide to Vim Plugins/Addons/Bundles/Scripts in Nixpkgs
|
||||
|
||||
You'll get a vim(-your-suffix) in PATH also loading the plugins you want.
|
||||
Both Neovim and Vim can be configured to include your favorite plugins
|
||||
and additional libraries.
|
||||
|
||||
Loading can be deferred; see examples.
|
||||
|
||||
Vim packages, VAM (=vim-addon-manager) and Pathogen are supported to load
|
||||
packages.
|
||||
At the moment we support three different methods for managing plugins:
|
||||
|
||||
- Vim packages (*recommend*)
|
||||
- VAM (=vim-addon-manager)
|
||||
- Pathogen
|
||||
- vim-plug
|
||||
|
||||
## Custom configuration
|
||||
|
||||
@ -25,7 +31,19 @@ vim_configurable.customize {
|
||||
}
|
||||
```
|
||||
|
||||
## Vim packages
|
||||
For Neovim the `configure` argument can be overridden to achieve the same:
|
||||
|
||||
```
|
||||
neovim.override {
|
||||
configure = {
|
||||
customRC = ''
|
||||
# here your custom configuration goes!
|
||||
'';
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
## Managing plugins with Vim packages
|
||||
|
||||
To store you plugins in Vim packages the following example can be used:
|
||||
|
||||
@ -38,13 +56,79 @@ vim_configurable.customize {
|
||||
opt = [ phpCompletion elm-vim ];
|
||||
# To automatically load a plugin when opening a filetype, add vimrc lines like:
|
||||
# autocmd FileType php :packadd phpCompletion
|
||||
}
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
## VAM
|
||||
For Neovim the syntax is:
|
||||
|
||||
### dependencies by Vim plugins
|
||||
```
|
||||
neovim.override {
|
||||
configure = {
|
||||
customRC = ''
|
||||
# here your custom configuration goes!
|
||||
'';
|
||||
packages.myVimPackage = with pkgs.vimPlugins; {
|
||||
# see examples below how to use custom packages
|
||||
start = [ ];
|
||||
opt = [ ];
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
The resulting package can be added to `packageOverrides` in `~/.nixpkgs/config.nix` to make it installable:
|
||||
|
||||
```
|
||||
{
|
||||
packageOverrides = pkgs: with pkgs; {
|
||||
myVim = vim_configurable.customize {
|
||||
name = "vim-with-plugins";
|
||||
# add here code from the example section
|
||||
};
|
||||
myNeovim = neovim.override {
|
||||
configure = {
|
||||
# add here code from the example section
|
||||
};
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
After that you can install your special grafted `myVim` or `myNeovim` packages.
|
||||
|
||||
## Managing plugins with vim-plug
|
||||
|
||||
To use [vim-plug](https://github.com/junegunn/vim-plug) to manage your Vim
|
||||
plugins the following example can be used:
|
||||
|
||||
```
|
||||
vim_configurable.customize {
|
||||
vimrcConfig.packages.myVimPackage = with pkgs.vimPlugins; {
|
||||
# loaded on launch
|
||||
plug.plugins = [ youcompleteme fugitive phpCompletion elm-vim ];
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
For Neovim the syntax is:
|
||||
|
||||
```
|
||||
neovim.override {
|
||||
configure = {
|
||||
customRC = ''
|
||||
# here your custom configuration goes!
|
||||
'';
|
||||
plug.plugins = with pkgs.vimPlugins; [
|
||||
vim-go
|
||||
];
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
## Managing plugins with VAM
|
||||
|
||||
### Handling dependencies of Vim plugins
|
||||
|
||||
VAM introduced .json files supporting dependencies without versioning
|
||||
assuming that "using latest version" is ok most of the time.
|
||||
@ -125,6 +209,18 @@ Sample output2:
|
||||
]
|
||||
|
||||
|
||||
## Adding new plugins to nixpkgs
|
||||
|
||||
In `pkgs/misc/vim-plugins/vim-plugin-names` we store the plugin names
|
||||
for all vim plugins we automatically generate plugins for.
|
||||
The format of this file `github username/github repository`:
|
||||
For example https://github.com/scrooloose/nerdtree becomes `scrooloose/nerdtree`.
|
||||
After adding your plugin to this file run the `./update.py` in the same folder.
|
||||
This will updated a file called `generated.nix` and make your plugin accessible in the
|
||||
`vimPlugins` attribute set (`vimPlugins.nerdtree` in our example).
|
||||
If additional steps to the build process of the plugin are required, add an
|
||||
override to the `pkgs/misc/vim-plugins/default.nix` in the same directory.
|
||||
|
||||
## Important repositories
|
||||
|
||||
- [vim-pi](https://bitbucket.org/vimcommunity/vim-pi) is a plugin repository
|
||||
|
85
doc/lib-function-locations.nix
Normal file
85
doc/lib-function-locations.nix
Normal file
@ -0,0 +1,85 @@
|
||||
{ pkgs ? (import ./.. { }), nixpkgs ? { }}:
|
||||
let
|
||||
revision = pkgs.lib.trivial.revisionWithDefault (nixpkgs.revision or "master");
|
||||
|
||||
libDefPos = set:
|
||||
builtins.map
|
||||
(name: {
|
||||
name = name;
|
||||
location = builtins.unsafeGetAttrPos name set;
|
||||
})
|
||||
(builtins.attrNames set);
|
||||
|
||||
libset = toplib:
|
||||
builtins.map
|
||||
(subsetname: {
|
||||
subsetname = subsetname;
|
||||
functions = libDefPos toplib."${subsetname}";
|
||||
})
|
||||
(builtins.filter
|
||||
(name: builtins.isAttrs toplib."${name}")
|
||||
(builtins.attrNames toplib));
|
||||
|
||||
nixpkgsLib = pkgs.lib;
|
||||
|
||||
flattenedLibSubset = { subsetname, functions }:
|
||||
builtins.map
|
||||
(fn: {
|
||||
name = "lib.${subsetname}.${fn.name}";
|
||||
value = fn.location;
|
||||
})
|
||||
functions;
|
||||
|
||||
locatedlibsets = libs: builtins.map flattenedLibSubset (libset libs);
|
||||
removeFilenamePrefix = prefix: filename:
|
||||
let
|
||||
prefixLen = (builtins.stringLength prefix) + 1; # +1 to remove the leading /
|
||||
filenameLen = builtins.stringLength filename;
|
||||
substr = builtins.substring prefixLen filenameLen filename;
|
||||
in substr;
|
||||
|
||||
removeNixpkgs = removeFilenamePrefix (builtins.toString pkgs.path);
|
||||
|
||||
liblocations =
|
||||
builtins.filter
|
||||
(elem: elem.value != null)
|
||||
(nixpkgsLib.lists.flatten
|
||||
(locatedlibsets nixpkgsLib));
|
||||
|
||||
fnLocationRelative = { name, value }:
|
||||
{
|
||||
inherit name;
|
||||
value = value // { file = removeNixpkgs value.file; };
|
||||
};
|
||||
|
||||
relativeLocs = (builtins.map fnLocationRelative liblocations);
|
||||
sanitizeId = builtins.replaceStrings
|
||||
[ "'" ]
|
||||
[ "-prime" ];
|
||||
|
||||
urlPrefix = "https://github.com/NixOS/nixpkgs/blob/${revision}";
|
||||
xmlstrings = (nixpkgsLib.strings.concatMapStrings
|
||||
({ name, value }:
|
||||
''
|
||||
<section><title>${name}</title>
|
||||
<para xml:id="${sanitizeId name}">
|
||||
Located at
|
||||
<link
|
||||
xlink:href="${urlPrefix}/${value.file}#L${builtins.toString value.line}">${value.file}:${builtins.toString value.line}</link>
|
||||
in <literal><nixpkgs></literal>.
|
||||
</para>
|
||||
</section>
|
||||
'')
|
||||
relativeLocs);
|
||||
|
||||
in pkgs.writeText
|
||||
"locations.xml"
|
||||
''
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
version="5">
|
||||
<title>All the locations for every lib function</title>
|
||||
<para>This file is only for inclusion by other files.</para>
|
||||
${xmlstrings}
|
||||
</section>
|
||||
''
|
191
doc/overlays.xml
191
doc/overlays.xml
@ -17,91 +17,122 @@
|
||||
<title>Installing overlays</title>
|
||||
|
||||
<para>
|
||||
The list of overlays is determined as follows.
|
||||
The list of overlays can be set either explicitly in a Nix expression, or
|
||||
through <literal><nixpkgs-overlays></literal> or user configuration
|
||||
files.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the <varname>overlays</varname> argument is not provided explicitly, we
|
||||
look for overlays in a path. The path is determined as follows:
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
First, if an <varname>overlays</varname> argument to the nixpkgs function
|
||||
itself is given, then that is used.
|
||||
</para>
|
||||
<para>
|
||||
This can be passed explicitly when importing nipxkgs, for example
|
||||
<literal>import <nixpkgs> { overlays = [ overlay1 overlay2 ];
|
||||
}</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Otherwise, if the Nix path entry <literal><nixpkgs-overlays></literal>
|
||||
exists, we look for overlays at that path, as described below.
|
||||
</para>
|
||||
<para>
|
||||
See the section on <literal>NIX_PATH</literal> in the Nix manual for more
|
||||
details on how to set a value for
|
||||
<literal><nixpkgs-overlays>.</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If one of <filename>~/.config/nixpkgs/overlays.nix</filename> and
|
||||
<filename>~/.config/nixpkgs/overlays/</filename> exists, then we look for
|
||||
overlays at that path, as described below. It is an error if both exist.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
<section xml:id="sec-overlays-argument">
|
||||
<title>Set overlays in NixOS or Nix expressions</title>
|
||||
|
||||
<para>
|
||||
If we are looking for overlays at a path, then there are two cases:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
If the path is a file, then the file is imported as a Nix expression and
|
||||
used as the list of overlays.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If the path is a directory, then we take the content of the directory,
|
||||
order it lexicographically, and attempt to interpret each as an overlay
|
||||
by:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Importing the file, if it is a <literal>.nix</literal> file.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Importing a top-level <filename>default.nix</filename> file, if it is
|
||||
a directory.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
On a NixOS system the value of the <literal>nixpkgs.overlays</literal>
|
||||
option, if present, is passed to the system Nixpkgs directly as an
|
||||
argument. Note that this does not affect the overlays for non-NixOS
|
||||
operations (e.g. <literal>nix-env</literal>), which are
|
||||
<link xlink:href="#sec-overlays-lookup">looked</link> up independently.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On a NixOS system the value of the <literal>nixpkgs.overlays</literal>
|
||||
option, if present, is passed to the system Nixpkgs directly as an argument.
|
||||
Note that this does not affect the overlays for non-NixOS operations (e.g.
|
||||
<literal>nix-env</literal>), which are looked up independently.
|
||||
</para>
|
||||
<para>
|
||||
The list of overlays can be passed explicitly when importing nixpkgs, for
|
||||
example <literal>import <nixpkgs> { overlays = [ overlay1 overlay2 ];
|
||||
}</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>overlays.nix</filename> option therefore provides a convenient
|
||||
way to use the same overlays for a NixOS system configuration and user
|
||||
configuration: the same file can be used as
|
||||
<filename>overlays.nix</filename> and imported as the value of
|
||||
<literal>nixpkgs.overlays</literal>.
|
||||
</para>
|
||||
<para>
|
||||
Further overlays can be added by calling the <literal>pkgs.extend</literal>
|
||||
or <literal>pkgs.appendOverlays</literal>, although it is often preferable
|
||||
to avoid these functions, because they recompute the Nixpkgs fixpoint,
|
||||
which is somewhat expensive to do.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-overlays-lookup">
|
||||
<title>Install overlays via configuration lookup</title>
|
||||
|
||||
<para>
|
||||
The list of overlays is determined as follows.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
First, if an
|
||||
<link xlink:href="#sec-overlays-argument"><varname>overlays</varname>
|
||||
argument</link> to the nixpkgs function itself is given, then that is
|
||||
used and no path lookup will be performed.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Otherwise, if the Nix path entry
|
||||
<literal><nixpkgs-overlays></literal> exists, we look for overlays at
|
||||
that path, as described below.
|
||||
</para>
|
||||
<para>
|
||||
See the section on <literal>NIX_PATH</literal> in the Nix manual for
|
||||
more details on how to set a value for
|
||||
<literal><nixpkgs-overlays>.</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If one of <filename>~/.config/nixpkgs/overlays.nix</filename> and
|
||||
<filename>~/.config/nixpkgs/overlays/</filename> exists, then we look
|
||||
for overlays at that path, as described below. It is an error if both
|
||||
exist.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If we are looking for overlays at a path, then there are two cases:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
If the path is a file, then the file is imported as a Nix expression and
|
||||
used as the list of overlays.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If the path is a directory, then we take the content of the directory,
|
||||
order it lexicographically, and attempt to interpret each as an overlay
|
||||
by:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Importing the file, if it is a <literal>.nix</literal> file.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Importing a top-level <filename>default.nix</filename> file, if it is
|
||||
a directory.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Because overlays that are set in NixOS configuration do not affect
|
||||
non-NixOS operations such as <literal>nix-env</literal>, the
|
||||
<filename>overlays.nix</filename> option provides a convenient way to use
|
||||
the same overlays for a NixOS system configuration and user configuration:
|
||||
the same file can be used as <filename>overlays.nix</filename> and imported
|
||||
as the value of <literal>nixpkgs.overlays</literal>.
|
||||
</para>
|
||||
|
||||
<!-- TODO: Example of sharing overlays between NixOS configuration
|
||||
and configuration lookup. Also reference the example
|
||||
from the sec-overlays-argument paragraph about NixOS.
|
||||
-->
|
||||
</section>
|
||||
</section>
|
||||
<!--============================================================-->
|
||||
<section xml:id="sec-overlays-definition">
|
||||
|
@ -413,11 +413,9 @@ packageOverrides = pkgs: {
|
||||
in your <filename>/etc/nixos/configuration.nix</filename>. You'll also need
|
||||
<programlisting>hardware.pulseaudio.support32Bit = true;</programlisting>
|
||||
if you are using PulseAudio - this will enable 32bit ALSA apps integration.
|
||||
To use the Steam controller, you need to add
|
||||
<programlisting>services.udev.extraRules = ''
|
||||
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"
|
||||
KERNEL=="uinput", MODE="0660", GROUP="users", OPTIONS+="static_node=uinput"
|
||||
'';</programlisting>
|
||||
To use the Steam controller or other Steam supported controllers such as
|
||||
the DualShock 4 or Nintendo Switch Pro, you need to add
|
||||
<programlisting>hardware.steam-hardware.enable = true;</programlisting>
|
||||
to your configuration.
|
||||
</para>
|
||||
</section>
|
||||
@ -671,6 +669,9 @@ overrides = self: super: rec {
|
||||
plugins = with availablePlugins; [ python perl ];
|
||||
}
|
||||
}</programlisting>
|
||||
If the <literal>configure</literal> function returns an attrset without the
|
||||
<literal>plugins</literal> attribute, <literal>availablePlugins</literal>
|
||||
will be used automatically.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -680,10 +681,10 @@ overrides = self: super: rec {
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The python plugin allows the addition of extra libraries. For instance, the
|
||||
<literal>inotify.py</literal> script in weechat-scripts requires D-Bus or
|
||||
libnotify, and the <literal>fish.py</literal> script requires pycrypto. To
|
||||
use these scripts, use the <literal>python</literal> plugin's
|
||||
The python and perl plugins allows the addition of extra libraries. For
|
||||
instance, the <literal>inotify.py</literal> script in weechat-scripts
|
||||
requires D-Bus or libnotify, and the <literal>fish.py</literal> script
|
||||
requires pycrypto. To use these scripts, use the plugin's
|
||||
<literal>withPackages</literal> attribute:
|
||||
<programlisting>weechat.override { configure = {availablePlugins, ...}: {
|
||||
plugins = with availablePlugins; [
|
||||
@ -704,6 +705,61 @@ overrides = self: super: rec {
|
||||
}; }
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
WeeChat allows to set defaults on startup using the
|
||||
<literal>--run-command</literal>. The <literal>configure</literal> method
|
||||
can be used to pass commands to the program:
|
||||
<programlisting>weechat.override {
|
||||
configure = { availablePlugins, ... }: {
|
||||
init = ''
|
||||
/set foo bar
|
||||
/server add freenode chat.freenode.org
|
||||
'';
|
||||
};
|
||||
}</programlisting>
|
||||
Further values can be added to the list of commands when running
|
||||
<literal>weechat --run-command "your-commands"</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Additionally it's possible to specify scripts to be loaded when starting
|
||||
<literal>weechat</literal>. These will be loaded before the commands from
|
||||
<literal>init</literal>:
|
||||
<programlisting>weechat.override {
|
||||
configure = { availablePlugins, ... }: {
|
||||
scripts = with pkgs.weechatScripts; [
|
||||
weechat-xmpp weechat-matrix-bridge wee-slack
|
||||
];
|
||||
init = ''
|
||||
/set plugins.var.python.jabber.key "val"
|
||||
'':
|
||||
};
|
||||
}</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In <literal>nixpkgs</literal> there's a subpackage which contains
|
||||
derivations for WeeChat scripts. Such derivations expect a
|
||||
<literal>passthru.scripts</literal> attribute which contains a list of all
|
||||
scripts inside the store path. Furthermore all scripts have to live in
|
||||
<literal>$out/share</literal>. An exemplary derivation looks like this:
|
||||
<programlisting>{ stdenv, fetchurl }:
|
||||
|
||||
stdenv.mkDerivation {
|
||||
name = "exemplary-weechat-script";
|
||||
src = fetchurl {
|
||||
url = "https://scripts.tld/your-scripts.tar.gz";
|
||||
sha256 = "...";
|
||||
};
|
||||
passthru.scripts = [ "foo.py" "bar.lua" ];
|
||||
installPhase = ''
|
||||
mkdir $out/share
|
||||
cp foo.py $out/share
|
||||
cp bar.lua $out/share
|
||||
'';
|
||||
}</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="sec-citrix">
|
||||
<title>Citrix Receiver</title>
|
||||
@ -763,4 +819,75 @@ citrix_receiver.override {
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="sec-ibus-typing-booster">
|
||||
<title>ibus-engines.typing-booster</title>
|
||||
|
||||
<para>
|
||||
This package is an ibus-based completion method to speed up typing.
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-ibus-typing-booster-activate">
|
||||
<title>Activating the engine</title>
|
||||
|
||||
<para>
|
||||
IBus needs to be configured accordingly to activate
|
||||
<literal>typing-booster</literal>. The configuration depends on the desktop
|
||||
manager in use. For detailed instructions, please refer to the
|
||||
<link xlink:href="https://mike-fabian.github.io/ibus-typing-booster/documentation.html">upstream
|
||||
docs</link>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On NixOS you need to explicitly enable <literal>ibus</literal> with given
|
||||
engines before customizing your desktop to use
|
||||
<literal>typing-booster</literal>. This can be achieved using the
|
||||
<literal>ibus</literal> module:
|
||||
<programlisting>{ pkgs, ... }: {
|
||||
i18n.inputMethod = {
|
||||
enabled = "ibus";
|
||||
ibus.engines = with pkgs.ibus-engines; [ typing-booster ];
|
||||
};
|
||||
}</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-ibus-typing-booster-customize-hunspell">
|
||||
<title>Using custom hunspell dictionaries</title>
|
||||
|
||||
<para>
|
||||
The IBus engine is based on <literal>hunspell</literal> to support
|
||||
completion in many languages. By default the dictionaries
|
||||
<literal>de-de</literal>, <literal>en-us</literal>,
|
||||
<literal>es-es</literal>, <literal>it-it</literal>,
|
||||
<literal>sv-se</literal> and <literal>sv-fi</literal> are in use. To add
|
||||
another dictionary, the package can be overridden like this:
|
||||
<programlisting>ibus-engines.typing-booster.override {
|
||||
langs = [ "de-at" "en-gb" ];
|
||||
}</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<emphasis>Note: each language passed to <literal>langs</literal> must be an
|
||||
attribute name in <literal>pkgs.hunspellDicts</literal>.</emphasis>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-ibus-typing-booster-emoji-picker">
|
||||
<title>Built-in emoji picker</title>
|
||||
|
||||
<para>
|
||||
The <literal>ibus-engines.typing-booster</literal> package contains a
|
||||
program named <literal>emoji-picker</literal>. To display all emojis
|
||||
correctly, a special font such as <literal>noto-fonts-emoji</literal> is
|
||||
needed:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On NixOS it can be installed using the following expression:
|
||||
<programlisting>{ pkgs, ... }: {
|
||||
fonts.fonts = with pkgs; [ noto-fonts-emoji ];
|
||||
}</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
|
@ -1,5 +1,5 @@
|
||||
{ pkgs ? import ../. {} }:
|
||||
(import ./default.nix).overrideAttrs (x: {
|
||||
(import ./default.nix {}).overrideAttrs (x: {
|
||||
buildInputs = x.buildInputs ++ [ pkgs.xmloscopy pkgs.ruby ];
|
||||
|
||||
})
|
||||
|
@ -1,22 +0,0 @@
|
||||
---
|
||||
title: pkgs.mkShell
|
||||
author: zimbatm
|
||||
date: 2017-10-30
|
||||
---
|
||||
|
||||
# mkShell
|
||||
|
||||
pkgs.mkShell is a special kind of derivation that is only useful when using
|
||||
it combined with nix-shell. It will in fact fail to instantiate when invoked
|
||||
with nix-build.
|
||||
|
||||
## Usage
|
||||
|
||||
```nix
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
pkgs.mkShell {
|
||||
# this will make all the build inputs from hello and gnutar available to the shell environment
|
||||
inputsFrom = with pkgs; [ hello gnutar ];
|
||||
buildInputs = [ pkgs.gnumake ];
|
||||
}
|
||||
```
|
@ -2129,7 +2129,7 @@ someVar=$(stripHash $name)
|
||||
The most typical use of the setup hook is actually to add other hooks which
|
||||
are then run (i.e. after all the setup hooks) on each dependency. For
|
||||
example, the C compiler wrapper's setup hook feeds itself flags for each
|
||||
dependency that contains relevant libaries and headers. This is done by
|
||||
dependency that contains relevant libraries and headers. This is done by
|
||||
defining a bash function, and appending its name to one of
|
||||
<envar>envBuildBuildHooks</envar>`, <envar>envBuildHostHooks</envar>`,
|
||||
<envar>envBuildTargetHooks</envar>`, <envar>envHostHostHooks</envar>`,
|
||||
|
44
lib/asserts.nix
Normal file
44
lib/asserts.nix
Normal file
@ -0,0 +1,44 @@
|
||||
{ lib }:
|
||||
|
||||
rec {
|
||||
|
||||
/* Print a trace message if pred is false.
|
||||
Intended to be used to augment asserts with helpful error messages.
|
||||
|
||||
Example:
|
||||
assertMsg false "nope"
|
||||
=> false
|
||||
stderr> trace: nope
|
||||
|
||||
assert (assertMsg ("foo" == "bar") "foo is not bar, silly"); ""
|
||||
stderr> trace: foo is not bar, silly
|
||||
stderr> assert failed at …
|
||||
|
||||
Type:
|
||||
assertMsg :: Bool -> String -> Bool
|
||||
*/
|
||||
# TODO(Profpatsch): add tests that check stderr
|
||||
assertMsg = pred: msg:
|
||||
if pred
|
||||
then true
|
||||
else builtins.trace msg false;
|
||||
|
||||
/* Specialized `assertMsg` for checking if val is one of the elements
|
||||
of a list. Useful for checking enums.
|
||||
|
||||
Example:
|
||||
let sslLibrary = "libressl"
|
||||
in assertOneOf "sslLibrary" sslLibrary [ "openssl" "bearssl" ]
|
||||
=> false
|
||||
stderr> trace: sslLibrary must be one of "openssl", "bearssl", but is: "libressl"
|
||||
|
||||
Type:
|
||||
assertOneOf :: String -> ComparableVal -> List ComparableVal -> Bool
|
||||
*/
|
||||
assertOneOf = name: val: xs: assertMsg
|
||||
(lib.elem val xs)
|
||||
"${name} must be one of ${
|
||||
lib.generators.toPretty {} xs}, but is: ${
|
||||
lib.generators.toPretty {} val}";
|
||||
|
||||
}
|
@ -435,12 +435,15 @@ rec {
|
||||
useful for deep-overriding.
|
||||
|
||||
Example:
|
||||
x = { a = { b = 4; c = 3; }; }
|
||||
overrideExisting x { a = { b = 6; d = 2; }; }
|
||||
=> { a = { b = 6; d = 2; }; }
|
||||
overrideExisting {} { a = 1; }
|
||||
=> {}
|
||||
overrideExisting { b = 2; } { a = 1; }
|
||||
=> { b = 2; }
|
||||
overrideExisting { a = 3; b = 2; } { a = 1; }
|
||||
=> { a = 1; b = 2; }
|
||||
*/
|
||||
overrideExisting = old: new:
|
||||
old // listToAttrs (map (attr: nameValuePair attr (attrByPath [attr] old.${attr} new)) (attrNames old));
|
||||
mapAttrs (name: value: new.${name} or value) old;
|
||||
|
||||
/* Get a package output.
|
||||
If no output is found, fallback to `.out` and then to the default.
|
||||
|
@ -196,7 +196,7 @@ rec {
|
||||
newScope = scope: newScope (self // scope);
|
||||
callPackage = self.newScope {};
|
||||
overrideScope = g: lib.warn
|
||||
"`overrideScope` (from `lib.makeScope`) is deprecated. Do `overrideScope' (self: self: { … })` instead of `overrideScope (super: self: { … })`. All other overrides have the parameters in that order, including other definitions of `overrideScope`. This was the only definition violating the pattern."
|
||||
"`overrideScope` (from `lib.makeScope`) is deprecated. Do `overrideScope' (self: super: { … })` instead of `overrideScope (super: self: { … })`. All other overrides have the parameters in that order, including other definitions of `overrideScope`. This was the only definition violating the pattern."
|
||||
(makeScope newScope (lib.fixedPoints.extends (lib.flip g) f));
|
||||
overrideScope' = g: makeScope newScope (lib.fixedPoints.extends g f);
|
||||
packages = f;
|
||||
|
@ -38,10 +38,11 @@ let
|
||||
systems = callLibs ./systems;
|
||||
|
||||
# misc
|
||||
asserts = callLibs ./asserts.nix;
|
||||
debug = callLibs ./debug.nix;
|
||||
|
||||
generators = callLibs ./generators.nix;
|
||||
misc = callLibs ./deprecated.nix;
|
||||
|
||||
# domain-specific
|
||||
fetchers = callLibs ./fetchers.nix;
|
||||
|
||||
@ -60,7 +61,6 @@ let
|
||||
boolToString mergeAttrs flip mapNullable inNixShell min max
|
||||
importJSON warn info nixpkgsVersion version mod compare
|
||||
splitByAndCompare functionArgs setFunctionArgs isFunction;
|
||||
|
||||
inherit (fixedPoints) fix fix' extends composeExtensions
|
||||
makeExtensible makeExtensibleWithCustomName;
|
||||
inherit (attrsets) attrByPath hasAttrByPath setAttrByPath
|
||||
@ -117,6 +117,8 @@ let
|
||||
unknownModule mkOption;
|
||||
inherit (types) isType setType defaultTypeMerge defaultFunctor
|
||||
isOptionType mkOptionType;
|
||||
inherit (asserts)
|
||||
assertMsg assertOneOf;
|
||||
inherit (debug) addErrorContextToAttrs traceIf traceVal traceValFn
|
||||
traceXMLVal traceXMLValMarked traceSeq traceSeqN traceValSeq
|
||||
traceValSeqFn traceValSeqN traceValSeqNFn traceShowVal
|
||||
|
@ -143,6 +143,7 @@ rec {
|
||||
}@args: v: with builtins;
|
||||
let isPath = v: typeOf v == "path";
|
||||
in if isInt v then toString v
|
||||
else if isFloat v then "~${toString v}"
|
||||
else if isString v then ''"${libStr.escape [''"''] v}"''
|
||||
else if true == v then "true"
|
||||
else if false == v then "false"
|
||||
|
@ -355,6 +355,11 @@ lib.mapAttrs (n: v: v // { shortName = n; }) rec {
|
||||
fullName = "Independent JPEG Group License";
|
||||
};
|
||||
|
||||
imagemagick = spdx {
|
||||
fullName = "ImageMagick License";
|
||||
spdxId = "imagemagick";
|
||||
};
|
||||
|
||||
inria-compcert = {
|
||||
fullName = "INRIA Non-Commercial License Agreement for the CompCert verified compiler";
|
||||
url = "http://compcert.inria.fr/doc/LICENSE";
|
||||
@ -382,6 +387,14 @@ lib.mapAttrs (n: v: v // { shortName = n; }) rec {
|
||||
fullName = "ISC License";
|
||||
};
|
||||
|
||||
# Proprietary binaries; free to redistribute without modification.
|
||||
issl = {
|
||||
fullName = "Intel Simplified Software License";
|
||||
url = https://software.intel.com/en-us/license/intel-simplified-software-license;
|
||||
free = false;
|
||||
};
|
||||
|
||||
|
||||
lgpl2 = spdx {
|
||||
spdxId = "LGPL-2.0";
|
||||
fullName = "GNU Library General Public License v2 only";
|
||||
@ -495,6 +508,12 @@ lib.mapAttrs (n: v: v // { shortName = n; }) rec {
|
||||
fullName = "Non-Profit Open Software License 3.0";
|
||||
};
|
||||
|
||||
ocamlpro_nc = {
|
||||
fullName = "OCamlPro Non Commercial license version 1";
|
||||
url = "https://alt-ergo.ocamlpro.com/http/alt-ergo-2.2.0/OCamlPro-Non-Commercial-License.pdf";
|
||||
free = false;
|
||||
};
|
||||
|
||||
ofl = spdx {
|
||||
spdxId = "OFL-1.1";
|
||||
fullName = "SIL Open Font License 1.1";
|
||||
@ -546,6 +565,11 @@ lib.mapAttrs (n: v: v // { shortName = n; }) rec {
|
||||
fullName = "Public Domain";
|
||||
};
|
||||
|
||||
purdueBsd = {
|
||||
fullName = " Purdue BSD-Style License"; # also know as lsof license
|
||||
url = https://enterprise.dejacode.com/licenses/public/purdue-bsd;
|
||||
};
|
||||
|
||||
qpl = spdx {
|
||||
spdxId = "QPL-1.0";
|
||||
fullName = "Q Public License 1.0";
|
||||
@ -561,6 +585,11 @@ lib.mapAttrs (n: v: v // { shortName = n; }) rec {
|
||||
fullName = "Ruby License";
|
||||
};
|
||||
|
||||
sendmail = spdx {
|
||||
spdxId = "Sendmail";
|
||||
fullName = "Sendmail License";
|
||||
};
|
||||
|
||||
sgi-b-20 = spdx {
|
||||
spdxId = "SGI-B-2.0";
|
||||
fullName = "SGI Free Software License B v2.0";
|
||||
|
@ -509,7 +509,8 @@ rec {
|
||||
=> 3
|
||||
*/
|
||||
last = list:
|
||||
assert list != []; elemAt list (length list - 1);
|
||||
assert lib.assertMsg (list != []) "lists.last: list must not be empty!";
|
||||
elemAt list (length list - 1);
|
||||
|
||||
/* Return all elements but the last
|
||||
|
||||
@ -517,7 +518,9 @@ rec {
|
||||
init [ 1 2 3 ]
|
||||
=> [ 1 2 ]
|
||||
*/
|
||||
init = list: assert list != []; take (length list - 1) list;
|
||||
init = list:
|
||||
assert lib.assertMsg (list != []) "lists.init: list must not be empty!";
|
||||
take (length list - 1) list;
|
||||
|
||||
|
||||
/* return the image of the cross product of some lists by a function
|
||||
|
@ -8,7 +8,31 @@ with lib.strings;
|
||||
|
||||
rec {
|
||||
|
||||
# Returns true when the given argument is an option
|
||||
#
|
||||
# Examples:
|
||||
# isOption 1 // => false
|
||||
# isOption (mkOption {}) // => true
|
||||
isOption = lib.isType "option";
|
||||
|
||||
# Creates an Option attribute set. mkOption accepts an attribute set with the following keys:
|
||||
#
|
||||
# default: Default value used when no definition is given in the configuration.
|
||||
# defaultText: Textual representation of the default, for in the manual.
|
||||
# example: Example value used in the manual.
|
||||
# description: String describing the option.
|
||||
# type: Option type, providing type-checking and value merging.
|
||||
# apply: Function that converts the option value to something else.
|
||||
# internal: Whether the option is for NixOS developers only.
|
||||
# visible: Whether the option shows up in the manual.
|
||||
# readOnly: Whether the option can be set only once
|
||||
# options: Obsolete, used by types.optionSet.
|
||||
#
|
||||
# All keys default to `null` when not given.
|
||||
#
|
||||
# Examples:
|
||||
# mkOption { } // => { _type = "option"; }
|
||||
# mkOption { defaultText = "foo"; } // => { _type = "option"; defaultText = "foo"; }
|
||||
mkOption =
|
||||
{ default ? null # Default value used when no definition is given in the configuration.
|
||||
, defaultText ? null # Textual representation of the default, for in the manual.
|
||||
@ -24,6 +48,10 @@ rec {
|
||||
} @ attrs:
|
||||
attrs // { _type = "option"; };
|
||||
|
||||
# Creates a Option attribute set for a boolean value option i.e an option to be toggled on or off:
|
||||
#
|
||||
# Examples:
|
||||
# mkEnableOption "foo" // => { _type = "option"; default = false; description = "Whether to enable foo."; example = true; type = { ... }; }
|
||||
mkEnableOption = name: mkOption {
|
||||
default = false;
|
||||
example = true;
|
||||
@ -74,7 +102,18 @@ rec {
|
||||
else
|
||||
val) (head defs).value defs;
|
||||
|
||||
# Extracts values of all "value" keys of the given list
|
||||
#
|
||||
# Examples:
|
||||
# getValues [ { value = 1; } { value = 2; } ] // => [ 1 2 ]
|
||||
# getValues [ ] // => [ ]
|
||||
getValues = map (x: x.value);
|
||||
|
||||
# Extracts values of all "file" keys of the given list
|
||||
#
|
||||
# Examples:
|
||||
# getFiles [ { file = "file1"; } { file = "file2"; } ] // => [ "file1" "file2" ]
|
||||
# getFiles [ ] // => [ ]
|
||||
getFiles = map (x: x.file);
|
||||
|
||||
# Generate documentation template from the list of option declaration like
|
||||
|
@ -26,6 +26,10 @@ rec {
|
||||
(type == "symlink" && lib.hasPrefix "result" baseName)
|
||||
);
|
||||
|
||||
# Filters a source tree removing version control files and directories using cleanSourceWith
|
||||
#
|
||||
# Example:
|
||||
# cleanSource ./.
|
||||
cleanSource = src: cleanSourceWith { filter = cleanSourceFilter; inherit src; };
|
||||
|
||||
# Like `builtins.filterSource`, except it will compose with itself,
|
||||
|
@ -410,7 +410,7 @@ rec {
|
||||
components = splitString "/" url;
|
||||
filename = lib.last components;
|
||||
name = builtins.head (splitString sep filename);
|
||||
in assert name != filename; name;
|
||||
in assert name != filename; name;
|
||||
|
||||
/* Create an --{enable,disable}-<feat> string that can be passed to
|
||||
standard GNU Autoconf scripts.
|
||||
@ -468,7 +468,10 @@ rec {
|
||||
strw = lib.stringLength str;
|
||||
reqWidth = width - (lib.stringLength filler);
|
||||
in
|
||||
assert strw <= width;
|
||||
assert lib.assertMsg (strw <= width)
|
||||
"fixedWidthString: requested string length (${
|
||||
toString width}) must not be shorter than actual length (${
|
||||
toString strw})";
|
||||
if strw == width then str else filler + fixedWidthString reqWidth filler str;
|
||||
|
||||
/* Format a number adding leading zeroes up to fixed width.
|
||||
@ -501,7 +504,7 @@ rec {
|
||||
isStorePath = x:
|
||||
isCoercibleToString x
|
||||
&& builtins.substring 0 1 (toString x) == "/"
|
||||
&& dirOf (builtins.toPath x) == builtins.storeDir;
|
||||
&& dirOf x == builtins.storeDir;
|
||||
|
||||
/* Convert string to int
|
||||
Obviously, it is a bit hacky to use fromJSON that way.
|
||||
@ -537,11 +540,10 @@ rec {
|
||||
*/
|
||||
readPathsFromFile = rootPath: file:
|
||||
let
|
||||
root = toString rootPath;
|
||||
lines = lib.splitString "\n" (builtins.readFile file);
|
||||
removeComments = lib.filter (line: line != "" && !(lib.hasPrefix "#" line));
|
||||
relativePaths = removeComments lines;
|
||||
absolutePaths = builtins.map (path: builtins.toPath (root + "/" + path)) relativePaths;
|
||||
absolutePaths = builtins.map (path: rootPath + "/${path}") relativePaths;
|
||||
in
|
||||
absolutePaths;
|
||||
|
||||
|
@ -46,6 +46,25 @@ rec {
|
||||
# Misc boolean options
|
||||
useAndroidPrebuilt = false;
|
||||
useiOSPrebuilt = false;
|
||||
|
||||
# Output from uname
|
||||
uname = {
|
||||
# uname -s
|
||||
system = {
|
||||
"linux" = "Linux";
|
||||
"windows" = "Windows";
|
||||
"darwin" = "Darwin";
|
||||
"netbsd" = "NetBSD";
|
||||
"freebsd" = "FreeBSD";
|
||||
"openbsd" = "OpenBSD";
|
||||
}.${final.parsed.kernel.name} or null;
|
||||
|
||||
# uname -p
|
||||
processor = final.parsed.cpu.name;
|
||||
|
||||
# uname -r
|
||||
release = null;
|
||||
};
|
||||
} // mapAttrs (n: v: v final.parsed) inspect.predicates
|
||||
// args;
|
||||
in assert final.useAndroidPrebuilt -> final.isAndroid;
|
||||
|
@ -15,6 +15,8 @@ let
|
||||
|
||||
"x86_64-cygwin" "x86_64-darwin" "x86_64-freebsd" "x86_64-linux"
|
||||
"x86_64-netbsd" "x86_64-openbsd" "x86_64-solaris"
|
||||
|
||||
"x86_64-windows" "i686-windows"
|
||||
];
|
||||
|
||||
allParsed = map parse.mkSystemFromString all;
|
||||
@ -37,12 +39,13 @@ in rec {
|
||||
darwin = filterDoubles predicates.isDarwin;
|
||||
freebsd = filterDoubles predicates.isFreeBSD;
|
||||
# Should be better, but MinGW is unclear.
|
||||
gnu = filterDoubles (matchAttrs { kernel = parse.kernels.linux; abi = parse.abis.gnu; });
|
||||
gnu = filterDoubles (matchAttrs { kernel = parse.kernels.linux; abi = parse.abis.gnu; }) ++ filterDoubles (matchAttrs { kernel = parse.kernels.linux; abi = parse.abis.gnueabi; }) ++ filterDoubles (matchAttrs { kernel = parse.kernels.linux; abi = parse.abis.gnueabihf; });
|
||||
illumos = filterDoubles predicates.isSunOS;
|
||||
linux = filterDoubles predicates.isLinux;
|
||||
netbsd = filterDoubles predicates.isNetBSD;
|
||||
openbsd = filterDoubles predicates.isOpenBSD;
|
||||
unix = filterDoubles predicates.isUnix;
|
||||
windows = filterDoubles predicates.isWindows;
|
||||
|
||||
mesaPlatforms = ["i686-linux" "x86_64-linux" "x86_64-darwin" "armv5tel-linux" "armv6l-linux" "armv7l-linux" "aarch64-linux" "powerpc64le-linux"];
|
||||
}
|
||||
|
@ -28,7 +28,7 @@ rec {
|
||||
};
|
||||
|
||||
armv7l-hf-multiplatform = rec {
|
||||
config = "armv7a-unknown-linux-gnueabihf";
|
||||
config = "armv7l-unknown-linux-gnueabihf";
|
||||
platform = platforms.armv7l-hf-multiplatform;
|
||||
};
|
||||
|
||||
|
7
lib/tests/check-eval.nix
Normal file
7
lib/tests/check-eval.nix
Normal file
@ -0,0 +1,7 @@
|
||||
# Throws an error if any of our lib tests fail.
|
||||
|
||||
let tests = [ "misc" "systems" ];
|
||||
all = builtins.concatLists (map (f: import (./. + "/${f}.nix")) tests);
|
||||
in if all == []
|
||||
then null
|
||||
else throw (builtins.toJSON all)
|
@ -112,7 +112,7 @@ runTests {
|
||||
storePathAppendix = isStorePath
|
||||
"${goodPath}/bin/python";
|
||||
nonAbsolute = isStorePath (concatStrings (tail (stringToCharacters goodPath)));
|
||||
asPath = isStorePath (builtins.toPath goodPath);
|
||||
asPath = isStorePath goodPath;
|
||||
otherPath = isStorePath "/something/else";
|
||||
otherVals = {
|
||||
attrset = isStorePath {};
|
||||
@ -236,6 +236,20 @@ runTests {
|
||||
};
|
||||
};
|
||||
|
||||
testOverrideExistingEmpty = {
|
||||
expr = overrideExisting {} { a = 1; };
|
||||
expected = {};
|
||||
};
|
||||
|
||||
testOverrideExistingDisjoint = {
|
||||
expr = overrideExisting { b = 2; } { a = 1; };
|
||||
expected = { b = 2; };
|
||||
};
|
||||
|
||||
testOverrideExistingOverride = {
|
||||
expr = overrideExisting { a = 3; b = 2; } { a = 1; };
|
||||
expected = { a = 1; b = 2; };
|
||||
};
|
||||
|
||||
# GENERATORS
|
||||
# these tests assume attributes are converted to lists
|
||||
@ -355,9 +369,10 @@ runTests {
|
||||
testToPretty = {
|
||||
expr = mapAttrs (const (generators.toPretty {})) rec {
|
||||
int = 42;
|
||||
float = 0.1337;
|
||||
bool = true;
|
||||
string = ''fno"rd'';
|
||||
path = /. + "/foo"; # toPath returns a string
|
||||
path = /. + "/foo";
|
||||
null_ = null;
|
||||
function = x: x;
|
||||
functionArgs = { arg ? 4, foo }: arg;
|
||||
@ -367,6 +382,7 @@ runTests {
|
||||
};
|
||||
expected = rec {
|
||||
int = "42";
|
||||
float = "~0.133700";
|
||||
bool = "true";
|
||||
string = ''"fno\"rd"'';
|
||||
path = "/foo";
|
||||
|
@ -12,20 +12,21 @@ let
|
||||
expected = lib.sort lib.lessThan y;
|
||||
};
|
||||
in with lib.systems.doubles; lib.runTests {
|
||||
all = assertTrue (mseteq all (linux ++ darwin ++ cygwin ++ freebsd ++ openbsd ++ netbsd ++ illumos));
|
||||
testall = mseteq all (linux ++ darwin ++ freebsd ++ openbsd ++ netbsd ++ illumos ++ windows);
|
||||
|
||||
arm = assertTrue (mseteq arm [ "armv5tel-linux" "armv6l-linux" "armv7l-linux" ]);
|
||||
i686 = assertTrue (mseteq i686 [ "i686-linux" "i686-freebsd" "i686-netbsd" "i686-openbsd" "i686-cygwin" ]);
|
||||
mips = assertTrue (mseteq mips [ "mipsel-linux" ]);
|
||||
x86_64 = assertTrue (mseteq x86_64 [ "x86_64-linux" "x86_64-darwin" "x86_64-freebsd" "x86_64-openbsd" "x86_64-netbsd" "x86_64-cygwin" "x86_64-solaris" ]);
|
||||
testarm = mseteq arm [ "armv5tel-linux" "armv6l-linux" "armv7l-linux" ];
|
||||
testi686 = mseteq i686 [ "i686-linux" "i686-freebsd" "i686-netbsd" "i686-openbsd" "i686-cygwin" "i686-windows" ];
|
||||
testmips = mseteq mips [ "mipsel-linux" ];
|
||||
testx86_64 = mseteq x86_64 [ "x86_64-linux" "x86_64-darwin" "x86_64-freebsd" "x86_64-openbsd" "x86_64-netbsd" "x86_64-cygwin" "x86_64-solaris" "x86_64-windows" ];
|
||||
|
||||
cygwin = assertTrue (mseteq cygwin [ "i686-cygwin" "x86_64-cygwin" ]);
|
||||
darwin = assertTrue (mseteq darwin [ "x86_64-darwin" ]);
|
||||
freebsd = assertTrue (mseteq freebsd [ "i686-freebsd" "x86_64-freebsd" ]);
|
||||
gnu = assertTrue (mseteq gnu (linux /* ++ kfreebsd ++ ... */));
|
||||
illumos = assertTrue (mseteq illumos [ "x86_64-solaris" ]);
|
||||
linux = assertTrue (mseteq linux [ "i686-linux" "x86_64-linux" "armv5tel-linux" "armv6l-linux" "armv7l-linux" "aarch64-linux" "mipsel-linux" ]);
|
||||
netbsd = assertTrue (mseteq netbsd [ "i686-netbsd" "x86_64-netbsd" ]);
|
||||
openbsd = assertTrue (mseteq openbsd [ "i686-openbsd" "x86_64-openbsd" ]);
|
||||
unix = assertTrue (mseteq unix (linux ++ darwin ++ freebsd ++ openbsd ++ netbsd ++ illumos));
|
||||
testcygwin = mseteq cygwin [ "i686-cygwin" "x86_64-cygwin" ];
|
||||
testdarwin = mseteq darwin [ "x86_64-darwin" ];
|
||||
testfreebsd = mseteq freebsd [ "i686-freebsd" "x86_64-freebsd" ];
|
||||
testgnu = mseteq gnu (linux /* ++ kfreebsd ++ ... */);
|
||||
testillumos = mseteq illumos [ "x86_64-solaris" ];
|
||||
testlinux = mseteq linux [ "i686-linux" "x86_64-linux" "armv5tel-linux" "armv6l-linux" "armv7l-linux" "aarch64-linux" "mipsel-linux" ];
|
||||
testnetbsd = mseteq netbsd [ "i686-netbsd" "x86_64-netbsd" ];
|
||||
testopenbsd = mseteq openbsd [ "i686-openbsd" "x86_64-openbsd" ];
|
||||
testwindows = mseteq windows [ "i686-cygwin" "x86_64-cygwin" "i686-windows" "x86_64-windows" ];
|
||||
testunix = mseteq unix (linux ++ darwin ++ freebsd ++ openbsd ++ netbsd ++ illumos ++ cygwin);
|
||||
}
|
||||
|
@ -36,18 +36,18 @@ rec {
|
||||
|
||||
/* bitwise “and” */
|
||||
bitAnd = builtins.bitAnd
|
||||
or import ./zip-int-bits.nix
|
||||
(a: b: if a==1 && b==1 then 1 else 0);
|
||||
or (import ./zip-int-bits.nix
|
||||
(a: b: if a==1 && b==1 then 1 else 0));
|
||||
|
||||
/* bitwise “or” */
|
||||
bitOr = builtins.bitOr
|
||||
or import ./zip-int-bits.nix
|
||||
(a: b: if a==1 || b==1 then 1 else 0);
|
||||
or (import ./zip-int-bits.nix
|
||||
(a: b: if a==1 || b==1 then 1 else 0));
|
||||
|
||||
/* bitwise “xor” */
|
||||
bitXor = builtins.bitXor
|
||||
or import ./zip-int-bits.nix
|
||||
(a: b: if a!=b then 1 else 0);
|
||||
or (import ./zip-int-bits.nix
|
||||
(a: b: if a!=b then 1 else 0));
|
||||
|
||||
/* bitwise “not” */
|
||||
bitNot = builtins.sub (-1);
|
||||
@ -105,6 +105,16 @@ rec {
|
||||
then lib.strings.fileContents suffixFile
|
||||
else "pre-git";
|
||||
|
||||
# Attempt to get the revision nixpkgs is from
|
||||
revisionWithDefault = default:
|
||||
let
|
||||
revisionFile = "${toString ./..}/.git-revision";
|
||||
gitRepo = "${toString ./..}/.git";
|
||||
in if lib.pathIsDirectory gitRepo
|
||||
then lib.commitIdFromGitRepo gitRepo
|
||||
else if lib.pathExists revisionFile then lib.fileContents revisionFile
|
||||
else default;
|
||||
|
||||
nixpkgsVersion = builtins.trace "`lib.nixpkgsVersion` is deprecated, use `lib.version` instead!" version;
|
||||
|
||||
# Whether we're being called by nix-shell.
|
||||
@ -171,7 +181,7 @@ rec {
|
||||
builtins.fromJSON (builtins.readFile path);
|
||||
|
||||
|
||||
## Warnings and asserts
|
||||
## Warnings
|
||||
|
||||
/* See https://github.com/NixOS/nix/issues/749. Eventually we'd like these
|
||||
to expand to Nix builtins that carry metadata so that Nix can filter out
|
||||
|
@ -119,7 +119,9 @@ rec {
|
||||
let
|
||||
betweenDesc = lowest: highest:
|
||||
"${toString lowest} and ${toString highest} (both inclusive)";
|
||||
between = lowest: highest: assert lowest <= highest;
|
||||
between = lowest: highest:
|
||||
assert lib.assertMsg (lowest <= highest)
|
||||
"ints.between: lowest must be smaller than highest";
|
||||
addCheck int (x: x >= lowest && x <= highest) // {
|
||||
name = "intBetween";
|
||||
description = "integer between ${betweenDesc lowest highest}";
|
||||
@ -192,7 +194,10 @@ rec {
|
||||
# separator between the values).
|
||||
separatedString = sep: mkOptionType rec {
|
||||
name = "separatedString";
|
||||
description = "string";
|
||||
description = if sep == ""
|
||||
then "Concatenated string" # for types.string.
|
||||
else "strings concatenated with ${builtins.toJSON sep}"
|
||||
;
|
||||
check = isString;
|
||||
merge = loc: defs: concatStringsSep sep (getValues defs);
|
||||
functor = (defaultFunctor name) // {
|
||||
@ -439,7 +444,9 @@ rec {
|
||||
# Either value of type `finalType` or `coercedType`, the latter is
|
||||
# converted to `finalType` using `coerceFunc`.
|
||||
coercedTo = coercedType: coerceFunc: finalType:
|
||||
assert coercedType.getSubModules == null;
|
||||
assert lib.assertMsg (coercedType.getSubModules == null)
|
||||
"coercedTo: coercedType must not have submodules (it’s a ${
|
||||
coercedType.description})";
|
||||
mkOptionType rec {
|
||||
name = "coercedTo";
|
||||
description = "${finalType.description} or ${coercedType.description} convertible to it";
|
||||
|
@ -18,6 +18,11 @@
|
||||
for an example on how to work with this data.
|
||||
*/
|
||||
{
|
||||
"1000101" = {
|
||||
email = "jan.hrnko@satoshilabs.com";
|
||||
github = "1000101";
|
||||
name = "Jan Hrnko";
|
||||
};
|
||||
a1russell = {
|
||||
email = "adamlr6+pub@gmail.com";
|
||||
github = "a1russell";
|
||||
@ -153,6 +158,11 @@
|
||||
github = "alexanderkjeldaas";
|
||||
name = "Alexander Kjeldaas";
|
||||
};
|
||||
akavel = {
|
||||
email = "czapkofan@gmail.com";
|
||||
github = "akavel";
|
||||
name = "Mateusz Czapliński";
|
||||
};
|
||||
akaWolf = {
|
||||
email = "akawolf0@gmail.com";
|
||||
github = "akaWolf";
|
||||
@ -216,6 +226,11 @@
|
||||
github = "amiloradovsky";
|
||||
name = "Andrew Miloradovsky";
|
||||
};
|
||||
aminb = {
|
||||
email = "amin@aminb.org";
|
||||
github = "aminb";
|
||||
name = "Amin Bandali";
|
||||
};
|
||||
aminechikhaoui = {
|
||||
email = "amine.chikhaoui91@gmail.com";
|
||||
github = "AmineChikhaoui";
|
||||
@ -227,7 +242,7 @@
|
||||
name = "Andrew Morsillo";
|
||||
};
|
||||
AndersonTorres = {
|
||||
email = "torres.anderson.85@gmail.com";
|
||||
email = "torres.anderson.85@protonmail.com";
|
||||
github = "AndersonTorres";
|
||||
name = "Anderson Torres";
|
||||
};
|
||||
@ -376,6 +391,16 @@
|
||||
github = "auntie";
|
||||
name = "Jonathan Glines";
|
||||
};
|
||||
avaq = {
|
||||
email = "avaq+nixos@xs4all.nl";
|
||||
github = "avaq";
|
||||
name = "Aldwin Vlasblom";
|
||||
};
|
||||
avery = {
|
||||
email = "averyl+nixos@protonmail.com";
|
||||
github = "AveryLychee";
|
||||
name = "Avery Lychee";
|
||||
};
|
||||
avnik = {
|
||||
email = "avn@avnik.info";
|
||||
github = "avnik";
|
||||
@ -500,6 +525,11 @@
|
||||
github = "bgamari";
|
||||
name = "Ben Gamari";
|
||||
};
|
||||
bhall = {
|
||||
email = "brendan.j.hall@bath.edu";
|
||||
github = "brendan-hall";
|
||||
name = "Brendan Hall";
|
||||
};
|
||||
bhipple = {
|
||||
email = "bhipple@protonmail.com";
|
||||
github = "bhipple";
|
||||
@ -678,6 +708,11 @@
|
||||
github = "Chaddai";
|
||||
name = "Chaddaï Fouché";
|
||||
};
|
||||
chaduffy = {
|
||||
email = "charles@dyfis.net";
|
||||
github = "charles-dyfis-net";
|
||||
name = "Charles Duffy";
|
||||
};
|
||||
changlinli = {
|
||||
email = "mail@changlinli.com";
|
||||
github = "changlinli";
|
||||
@ -956,6 +991,11 @@
|
||||
github = "deepfire";
|
||||
name = "Kosyrev Serge";
|
||||
};
|
||||
delroth = {
|
||||
email = "delroth@gmail.com";
|
||||
github = "delroth";
|
||||
name = "Pierre Bourdon";
|
||||
};
|
||||
deltaevo = {
|
||||
email = "deltaduartedavid@gmail.com";
|
||||
github = "DeltaEvo";
|
||||
@ -1110,6 +1150,11 @@
|
||||
github = "dtzWill";
|
||||
name = "Will Dietz";
|
||||
};
|
||||
dysinger = {
|
||||
email = "tim@dysinger.net";
|
||||
github = "dysinger";
|
||||
name = "Tim Dysinger";
|
||||
};
|
||||
dywedir = {
|
||||
email = "dywedir@protonmail.ch";
|
||||
github = "dywedir";
|
||||
@ -1165,6 +1210,11 @@
|
||||
github = "eduarrrd";
|
||||
name = "Eduard Bachmakov";
|
||||
};
|
||||
edude03 = {
|
||||
email = "michael@melenion.com";
|
||||
github = "edude03";
|
||||
name = "Michael Francis";
|
||||
};
|
||||
edwtjo = {
|
||||
email = "ed@cflags.cc";
|
||||
github = "edwtjo";
|
||||
@ -1307,6 +1357,11 @@
|
||||
github = "etu";
|
||||
name = "Elis Hirwing";
|
||||
};
|
||||
evck = {
|
||||
email = "eric@evenchick.com";
|
||||
github = "ericevenchick";
|
||||
name = "Eric Evenchick";
|
||||
};
|
||||
exfalso = {
|
||||
email = "0slemi0@gmail.com";
|
||||
github = "exfalso";
|
||||
@ -1327,6 +1382,11 @@
|
||||
github = "expipiplus1";
|
||||
name = "Joe Hermaszewski";
|
||||
};
|
||||
f--t = {
|
||||
email = "git@f-t.me";
|
||||
github = "f--t";
|
||||
name = "f--t";
|
||||
};
|
||||
f-breidenstein = {
|
||||
email = "mail@felixbreidenstein.de";
|
||||
github = "f-breidenstein";
|
||||
@ -1610,6 +1670,11 @@
|
||||
github = "hamhut1066";
|
||||
name = "Hamish Hutchings";
|
||||
};
|
||||
haslersn = {
|
||||
email = "haslersn@fius.informatik.uni-stuttgart.de";
|
||||
github = "haslersn";
|
||||
name = "Sebastian Hasler";
|
||||
};
|
||||
havvy = {
|
||||
email = "ryan.havvy@gmail.com";
|
||||
github = "havvy";
|
||||
@ -1832,6 +1897,11 @@
|
||||
github = "jdagilliland";
|
||||
name = "Jason Gilliland";
|
||||
};
|
||||
jdehaas = {
|
||||
email = "qqlq@nullptr.club";
|
||||
github = "jeroendehaas";
|
||||
name = "Jeroen de Haas";
|
||||
};
|
||||
jefdaj = {
|
||||
email = "jefdaj@gmail.com";
|
||||
github = "jefdaj";
|
||||
@ -1847,6 +1917,16 @@
|
||||
github = "jerith666";
|
||||
name = "Matt McHenry";
|
||||
};
|
||||
jeschli = {
|
||||
email = "jeschli@gmail.com";
|
||||
github = "jeschli";
|
||||
name = "Markus Hihn";
|
||||
};
|
||||
jethro = {
|
||||
email = "jethrokuan95@gmail.com";
|
||||
github = "jethrokuan";
|
||||
name = "Jethro Kuan";
|
||||
};
|
||||
jfb = {
|
||||
email = "james@yamtime.com";
|
||||
github = "tftio";
|
||||
@ -2098,6 +2178,11 @@
|
||||
github = "kiloreux";
|
||||
name = "Kiloreux Emperex";
|
||||
};
|
||||
kimburgess = {
|
||||
email = "kim@acaprojects.com";
|
||||
github = "kimburgess";
|
||||
name = "Kim Burgess";
|
||||
};
|
||||
kini = {
|
||||
email = "keshav.kini@gmail.com";
|
||||
github = "kini";
|
||||
@ -2154,6 +2239,11 @@
|
||||
github = "krav";
|
||||
name = "Kristoffer Thømt Ravneberg";
|
||||
};
|
||||
kroell = {
|
||||
email = "nixosmainter@makroell.de";
|
||||
github = "rokk4";
|
||||
name = "Matthias Axel Kröll";
|
||||
};
|
||||
kristoff3r = {
|
||||
email = "k.soeholm@gmail.com";
|
||||
github = "kristoff3r";
|
||||
@ -2397,6 +2487,11 @@
|
||||
github = "ma27";
|
||||
name = "Maximilian Bosch";
|
||||
};
|
||||
ma9e = {
|
||||
email = "sean@lfo.team";
|
||||
github = "ma9e";
|
||||
name = "Sean Haugh";
|
||||
};
|
||||
madjar = {
|
||||
email = "georges.dubus@compiletoi.net";
|
||||
github = "madjar";
|
||||
@ -2531,6 +2626,11 @@
|
||||
github = "mdaiter";
|
||||
name = "Matthew S. Daiter";
|
||||
};
|
||||
mdevlamynck = {
|
||||
email = "matthias.devlamynck@mailoo.org";
|
||||
github = "mdevlamynck";
|
||||
name = "Matthias Devlamynck";
|
||||
};
|
||||
meditans = {
|
||||
email = "meditans@gmail.com";
|
||||
github = "meditans";
|
||||
@ -2808,6 +2908,11 @@
|
||||
github = "muflax";
|
||||
name = "Stefan Dorn";
|
||||
};
|
||||
mvnetbiz = {
|
||||
email = "mvnetbiz@gmail.com";
|
||||
github = "mvnetbiz";
|
||||
name = "Matt Votava";
|
||||
};
|
||||
myrl = {
|
||||
email = "myrl.0xf@gmail.com";
|
||||
github = "myrl";
|
||||
@ -2987,7 +3092,7 @@
|
||||
name = "Oliver Dunkl";
|
||||
};
|
||||
offline = {
|
||||
email = "jakahudoklin@gmail.com";
|
||||
email = "jaka@x-truder.net";
|
||||
github = "offlinehacker";
|
||||
name = "Jaka Hudoklin";
|
||||
};
|
||||
@ -3015,6 +3120,11 @@
|
||||
github = "olynch";
|
||||
name = "Owen Lynch";
|
||||
};
|
||||
OPNA2608 = {
|
||||
email = "christoph.neidahl@gmail.com";
|
||||
github = "OPNA2608";
|
||||
name = "Christoph Neidahl";
|
||||
};
|
||||
orbekk = {
|
||||
email = "kjetil.orbekk@gmail.com";
|
||||
github = "orbekk";
|
||||
@ -3050,6 +3160,16 @@
|
||||
github = "oyren";
|
||||
name = "Moritz Scheuren";
|
||||
};
|
||||
pacien = {
|
||||
email = "b4gx3q.nixpkgs@pacien.net";
|
||||
github = "pacien";
|
||||
name = "Pacien Tran-Girard";
|
||||
};
|
||||
paddygord = {
|
||||
email = "pgpatrickgordon@gmail.com";
|
||||
github = "paddygord";
|
||||
name = "Patrick Gordon";
|
||||
};
|
||||
paholg = {
|
||||
email = "paho@paholg.com";
|
||||
github = "paholg";
|
||||
@ -3224,6 +3344,11 @@
|
||||
github = "pmyjavec";
|
||||
name = "Pauly Myjavec";
|
||||
};
|
||||
pnelson = {
|
||||
email = "me@pnelson.ca";
|
||||
github = "pnelson";
|
||||
name = "Philip Nelson";
|
||||
};
|
||||
pneumaticat = {
|
||||
email = "kevin@potatofrom.space";
|
||||
github = "pneumaticat";
|
||||
@ -3259,6 +3384,11 @@
|
||||
github = "proglodyte";
|
||||
name = "Proglodyte";
|
||||
};
|
||||
prusnak = {
|
||||
email = "stick@gk2.sk";
|
||||
github = "prusnak";
|
||||
name = "Pavol Rusnak";
|
||||
};
|
||||
pshendry = {
|
||||
email = "paul@pshendry.com";
|
||||
github = "pshendry";
|
||||
@ -3396,6 +3526,11 @@
|
||||
github = "relrod";
|
||||
name = "Ricky Elrod";
|
||||
};
|
||||
renatoGarcia = {
|
||||
email = "fgarcia.renato@gmail.com";
|
||||
github = "renatoGarcia";
|
||||
name = "Renato Garcia";
|
||||
};
|
||||
renzo = {
|
||||
email = "renzocarbonara@gmail.com";
|
||||
github = "k0001";
|
||||
@ -3888,6 +4023,11 @@
|
||||
github = "StillerHarpo";
|
||||
name = "Florian Engel";
|
||||
};
|
||||
stites = {
|
||||
email = "sam@stites.io";
|
||||
github = "stites";
|
||||
name = "Sam Stites";
|
||||
};
|
||||
stumoss = {
|
||||
email = "samoss@gmail.com";
|
||||
github = "stumoss";
|
||||
@ -3953,6 +4093,11 @@
|
||||
github = "sztupi";
|
||||
name = "Attila Sztupak";
|
||||
};
|
||||
t184256 = {
|
||||
email = "monk@unboiled.info";
|
||||
github = "t184256";
|
||||
name = "Alexander Sosedkin";
|
||||
};
|
||||
tadfisher = {
|
||||
email = "tadfisher@gmail.com";
|
||||
github = "tadfisher";
|
||||
@ -4008,11 +4153,6 @@
|
||||
github = "tazjin";
|
||||
name = "Vincent Ambo";
|
||||
};
|
||||
TealG = {
|
||||
email = "~@Teal.Gr";
|
||||
github = "TealG";
|
||||
name = "Teal Gaure";
|
||||
};
|
||||
teh = {
|
||||
email = "tehunger@gmail.com";
|
||||
github = "teh";
|
||||
@ -4153,6 +4293,11 @@
|
||||
github = "tomsmeets";
|
||||
name = "Tom Smeets";
|
||||
};
|
||||
toonn = {
|
||||
email = "nnoot@toonn.io";
|
||||
github = "toonn";
|
||||
name = "Toon Nolten";
|
||||
};
|
||||
travisbhartwell = {
|
||||
email = "nafai@travishartwell.net";
|
||||
github = "travisbhartwell";
|
||||
@ -4237,6 +4382,11 @@
|
||||
github = "uri-canva";
|
||||
name = "Uri Baghin";
|
||||
};
|
||||
uskudnik = {
|
||||
email = "urban.skudnik@gmail.com";
|
||||
github = "uskudnik";
|
||||
name = "Urban Skudnik";
|
||||
};
|
||||
utdemir = {
|
||||
email = "me@utdemir.com";
|
||||
github = "utdemir";
|
||||
@ -4381,6 +4531,11 @@
|
||||
github = "vrthra";
|
||||
name = "Rahul Gopinath";
|
||||
};
|
||||
vskilet = {
|
||||
email = "victor@sene.ovh";
|
||||
github = "vskilet";
|
||||
name = "Victor SENE";
|
||||
};
|
||||
vyp = {
|
||||
email = "elisp.vim@gmail.com";
|
||||
github = "vyp";
|
||||
@ -4508,13 +4663,18 @@
|
||||
github = "y0no";
|
||||
name = "Yoann Ono";
|
||||
};
|
||||
yarny = {
|
||||
email = "41838844+Yarny0@users.noreply.github.com";
|
||||
github = "Yarny0";
|
||||
name = "Yarny";
|
||||
};
|
||||
yarr = {
|
||||
email = "savraz@gmail.com";
|
||||
github = "Eternity-Yarr";
|
||||
name = "Dmitry V.";
|
||||
};
|
||||
yegortimoshenko = {
|
||||
email = "yegortimoshenko@gmail.com";
|
||||
email = "yegortimoshenko@riseup.net";
|
||||
github = "yegortimoshenko";
|
||||
name = "Yegor Timoshenko";
|
||||
};
|
||||
@ -4563,6 +4723,11 @@
|
||||
github = "maggesi";
|
||||
name = "Marco Maggesi";
|
||||
};
|
||||
zachcoyle = {
|
||||
email = "zach.coyle@gmail.com";
|
||||
github = "zachcoyle";
|
||||
name = "Zach Coyle";
|
||||
};
|
||||
zagy = {
|
||||
email = "cz@flyingcircus.io";
|
||||
github = "zagy";
|
||||
|
@ -4,7 +4,7 @@ all: manual-combined.xml format
|
||||
.PHONY: debug
|
||||
debug: generated manual-combined.xml
|
||||
|
||||
manual-combined.xml: generated *.xml
|
||||
manual-combined.xml: generated *.xml **/*.xml
|
||||
rm -f ./manual-combined.xml
|
||||
nix-shell --packages xmloscopy \
|
||||
--run "xmloscopy --docbook5 ./manual.xml ./manual-combined.xml"
|
||||
|
@ -52,4 +52,8 @@ $ ping -c1 10.233.4.2
|
||||
networking.networkmanager.unmanaged = [ "interface-name:ve-*" ];
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You may need to restart your system for the changes to take effect.
|
||||
</para>
|
||||
</section>
|
||||
|
@ -84,18 +84,17 @@ nixpkgs.config.packageOverrides = pkgs:
|
||||
allowImportFromDerivation = true;
|
||||
};
|
||||
]]></screen>
|
||||
|
||||
You can edit the config with this snippet (by default <command>make menuconfig</command> won't work
|
||||
out of the box on nixos):
|
||||
<screen><![CDATA[
|
||||
You can edit the config with this snippet (by default <command>make
|
||||
menuconfig</command> won't work out of the box on nixos):
|
||||
<screen><![CDATA[
|
||||
nix-shell -E 'with import <nixpkgs> {}; kernelToOverride.overrideAttrs (o: {nativeBuildInputs=o.nativeBuildInputs ++ [ pkgconfig ncurses ];})'
|
||||
]]></screen>
|
||||
|
||||
|
||||
or you can let nixpkgs generate the configuration.
|
||||
Nixpkgs generates it via answering the interactive kernel utility <command>make config</command>.
|
||||
The answers depend on parameters passed to <filename>pkgs/os-specific/linux/kernel/generic.nix</filename>
|
||||
(which you can influence by overriding <literal>extraConfig, autoModules, modDirVersion, preferBuiltin, extraConfig</literal>).
|
||||
or you can let nixpkgs generate the configuration. Nixpkgs generates it via
|
||||
answering the interactive kernel utility <command>make config</command>. The
|
||||
answers depend on parameters passed to
|
||||
<filename>pkgs/os-specific/linux/kernel/generic.nix</filename> (which you
|
||||
can influence by overriding <literal>extraConfig, autoModules,
|
||||
modDirVersion, preferBuiltin, extraConfig</literal>).
|
||||
<screen><![CDATA[
|
||||
|
||||
mptcp93.override ({
|
||||
|
@ -90,7 +90,9 @@ let
|
||||
fi
|
||||
${buildPackages.libxslt.bin}/bin/xsltproc \
|
||||
--stringparam revision '${revision}' \
|
||||
-o $out ${./options-to-docbook.xsl} $optionsXML
|
||||
-o intermediate.xml ${./options-to-docbook.xsl} $optionsXML
|
||||
${buildPackages.libxslt.bin}/bin/xsltproc \
|
||||
-o "$out" ${./postprocess-option-descriptions.xsl} intermediate.xml
|
||||
'';
|
||||
|
||||
sources = lib.sourceFilesBySuffices ./. [".xml"];
|
||||
@ -250,7 +252,7 @@ in rec {
|
||||
''; # */
|
||||
|
||||
# Generate the NixOS manual.
|
||||
manual = runCommand "nixos-manual"
|
||||
manualHTML = runCommand "nixos-manual-html"
|
||||
{ inherit sources;
|
||||
nativeBuildInputs = [ buildPackages.libxml2.bin buildPackages.libxslt.bin ];
|
||||
meta.description = "The NixOS manual in HTML format";
|
||||
@ -279,6 +281,11 @@ in rec {
|
||||
echo "doc manual $dst" >> $out/nix-support/hydra-build-products
|
||||
''; # */
|
||||
|
||||
# Alias for backward compatibility. TODO(@oxij): remove eventually.
|
||||
manual = manualHTML;
|
||||
|
||||
# Index page of the NixOS manual.
|
||||
manualHTMLIndex = "${manualHTML}/share/doc/nixos/index.html";
|
||||
|
||||
manualEpub = runCommand "nixos-manual-epub"
|
||||
{ inherit sources;
|
||||
|
@ -34,7 +34,7 @@ $ nix-build -A system</screen>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>system.build.manual.manual</varname>
|
||||
<varname>system.build.manual.manualHTML</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
|
37
nixos/doc/manual/development/debugging-nixos-tests.xml
Normal file
37
nixos/doc/manual/development/debugging-nixos-tests.xml
Normal file
@ -0,0 +1,37 @@
|
||||
<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-debugging-nixos-tests">
|
||||
<title>Debugging NixOS tests</title>
|
||||
|
||||
<para>
|
||||
Tests may fail and infrastructure offers access to inspect machine state.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To prevent test from stopping and cleaning up, insert a sleep command:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
$machine->succeed("sleep 84000");
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
As soon as machine starts run as root:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
nix-shell -p socat --run "socat STDIO,raw,echo=0,escape=0x11 UNIX:/tmp/nix-build-vm-test-run-*.drv-0/vm-state-machine/backdoor"
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
You may need to find the correct path, replacing <literal>/tmp</literal>,
|
||||
<literal>*</literal> or <literal>machine</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Press "enter" to open up console and login as "root". After you're done,
|
||||
press "ctrl-q" to exit the console.
|
||||
</para>
|
||||
</section>
|
@ -16,4 +16,5 @@ xlink:href="https://github.com/NixOS/nixpkgs/tree/master/nixos/tests">nixos/test
|
||||
<xi:include href="writing-nixos-tests.xml" />
|
||||
<xi:include href="running-nixos-tests.xml" />
|
||||
<xi:include href="running-nixos-tests-interactively.xml" />
|
||||
<xi:include href="debugging-nixos-tests.xml" />
|
||||
</chapter>
|
||||
|
@ -19,6 +19,7 @@ starting VDE switch for network 1
|
||||
> startAll
|
||||
> testScript
|
||||
> $machine->succeed("touch /tmp/foo")
|
||||
> print($machine->succeed("pwd"), "\n") # Show stdout of command
|
||||
</screen>
|
||||
The function <command>testScript</command> executes the entire test script
|
||||
and drops you back into the test driver command line upon its completion.
|
||||
@ -33,8 +34,11 @@ $ nix-build nixos/tests/login.nix -A driver
|
||||
$ ./result/bin/nixos-run-vms
|
||||
</screen>
|
||||
The script <command>nixos-run-vms</command> starts the virtual machines
|
||||
defined by test. The root file system of the VMs is created on the fly and
|
||||
kept across VM restarts in
|
||||
<filename>./</filename><varname>hostname</varname><filename>.qcow2</filename>.
|
||||
defined by test.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The machine state is kept across VM restarts in
|
||||
<filename>/tmp/vm-state-</filename><varname>machinename</varname>.
|
||||
</para>
|
||||
</section>
|
||||
|
@ -108,7 +108,7 @@ xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualis
|
||||
<programlisting>
|
||||
$machine->start;
|
||||
$machine->waitForUnit("default.target");
|
||||
$machine->succeed("uname") =~ /Linux/;
|
||||
die unless $machine->succeed("uname") =~ /Linux/;
|
||||
</programlisting>
|
||||
The first line is actually unnecessary; machines are implicitly started when
|
||||
you first execute an action on them (such as <literal>waitForUnit</literal>
|
||||
|
@ -5,28 +5,29 @@
|
||||
xml:id="sec-installing-behind-proxy">
|
||||
<title>Installing behind a proxy</title>
|
||||
|
||||
<para>
|
||||
<para>
|
||||
To install NixOS behind a proxy, do the following before running
|
||||
<literal>nixos-install</literal>.
|
||||
</para>
|
||||
<orderedlist numeration="arabic">
|
||||
</para>
|
||||
|
||||
<orderedlist numeration="arabic">
|
||||
<listitem>
|
||||
<para>
|
||||
Update proxy configuration in
|
||||
<literal>/mnt/etc/nixos/configuration.nix</literal> to keep the
|
||||
internet accessible after reboot.
|
||||
</para>
|
||||
<programlisting>
|
||||
<para>
|
||||
Update proxy configuration in
|
||||
<literal>/mnt/etc/nixos/configuration.nix</literal> to keep the internet
|
||||
accessible after reboot.
|
||||
</para>
|
||||
<programlisting>
|
||||
networking.proxy.default = "http://user:password@proxy:port/";
|
||||
networking.proxy.noProxy = "127.0.0.1,localhost,internal.domain";
|
||||
</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Setup the proxy environment variables in the shell where you are
|
||||
running <literal>nixos-install</literal>.
|
||||
</para>
|
||||
<programlisting>
|
||||
<para>
|
||||
Setup the proxy environment variables in the shell where you are running
|
||||
<literal>nixos-install</literal>.
|
||||
</para>
|
||||
<programlisting>
|
||||
# proxy_url="http://user:password@proxy:port/"
|
||||
# export http_proxy="$proxy_url"
|
||||
# export HTTP_PROXY="$proxy_url"
|
||||
@ -34,14 +35,14 @@ networking.proxy.noProxy = "127.0.0.1,localhost,internal.domain";
|
||||
# export HTTPS_PROXY="$proxy_url"
|
||||
</programlisting>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</orderedlist>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
If you are switching networks with different proxy configurations, use the
|
||||
<literal>nesting.clone</literal> option in
|
||||
<literal>configuration.nix</literal> to switch proxies at runtime.
|
||||
Refer to <xref linkend="ch-options" /> for more information.
|
||||
</para>
|
||||
</note>
|
||||
<note>
|
||||
<para>
|
||||
If you are switching networks with different proxy configurations, use the
|
||||
<literal>nesting.clone</literal> option in
|
||||
<literal>configuration.nix</literal> to switch proxies at runtime. Refer to
|
||||
<xref linkend="ch-options" /> for more information.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
@ -9,13 +9,12 @@
|
||||
For systems without CD drive, the NixOS live CD can be booted from a USB
|
||||
stick. You can use the <command>dd</command> utility to write the image:
|
||||
<command>dd if=<replaceable>path-to-image</replaceable>
|
||||
of=<replaceable>/dev/sdb</replaceable></command>. Be careful about specifying
|
||||
of=<replaceable>/dev/sdX</replaceable></command>. Be careful about specifying
|
||||
the correct drive; you can use the <command>lsblk</command> command to get a
|
||||
list of block devices.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On macOS:
|
||||
<note>
|
||||
<title>On macOS</title>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ diskutil list
|
||||
[..]
|
||||
@ -26,43 +25,16 @@ $ diskutil unmountDisk diskN
|
||||
Unmount of all volumes on diskN was successful
|
||||
$ sudo dd bs=1m if=nix.iso of=/dev/rdiskN
|
||||
</programlisting>
|
||||
Using the 'raw' <command>rdiskN</command> device instead of
|
||||
<command>diskN</command> completes in minutes instead of hours. After
|
||||
<command>dd</command> completes, a GUI dialog "The disk you inserted was not
|
||||
readable by this computer" will pop up, which can be ignored.
|
||||
Using the 'raw' <command>rdiskN</command> device instead of
|
||||
<command>diskN</command> completes in minutes instead of hours. After
|
||||
<command>dd</command> completes, a GUI dialog "The disk you inserted was
|
||||
not readable by this computer" will pop up, which can be ignored.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <command>dd</command> utility will write the image verbatim to the drive,
|
||||
making it the recommended option for both UEFI and non-UEFI installations.
|
||||
For non-UEFI installations, you can alternatively use
|
||||
<link xlink:href="http://unetbootin.sourceforge.net/">unetbootin</link>. If
|
||||
you cannot use <command>dd</command> for a UEFI installation, you can also
|
||||
mount the ISO, copy its contents verbatim to your drive, then either:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Change the label of the disk partition to the label of the ISO (visible
|
||||
with the blkid command), or
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Edit <filename>loader/entries/nixos-livecd.conf</filename> on the drive
|
||||
and change the <literal>root=</literal> field in the
|
||||
<literal>options</literal> line to point to your drive (see the
|
||||
documentation on <literal>root=</literal> in
|
||||
<link xlink:href="https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt">
|
||||
the kernel documentation</link> for more details).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If you want to load the contents of the ISO to ram after bootin (So you
|
||||
can remove the stick after bootup) you can append the parameter
|
||||
<literal>copytoram</literal> to the <literal>options</literal> field.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
@ -4,60 +4,46 @@
|
||||
version="5.0"
|
||||
xml:id="sec-installation">
|
||||
<title>Installing NixOS</title>
|
||||
<para>
|
||||
NixOS can be installed on BIOS or UEFI systems. The procedure for a UEFI
|
||||
installation is by and large the same as a BIOS installation. The differences
|
||||
are mentioned in the steps that follow.
|
||||
</para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Boot from the CD.
|
||||
</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
UEFI systems
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
You should boot the live CD in UEFI mode (consult your specific
|
||||
hardware's documentation for instructions). You may find the
|
||||
<link xlink:href="http://www.rodsbooks.com/refind">rEFInd boot
|
||||
manager</link> useful.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The CD contains a basic NixOS installation. (It also contains Memtest86+,
|
||||
useful if you want to test new hardware). When it’s finished booting, it
|
||||
should have detected most of your hardware.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The NixOS manual is available on virtual console 8 (press Alt+F8 to access)
|
||||
or by running <command>nixos-help</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
You get logged in as <literal>root</literal> (with empty password).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If you downloaded the graphical ISO image, you can run <command>systemctl
|
||||
start display-manager</command> to start KDE. If you want to continue on
|
||||
the terminal, you can use <command>loadkeys</command> to switch to your
|
||||
preferred keyboard layout. (We even provide neo2 via <command>loadkeys de
|
||||
neo</command>!)
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<section xml:id="sec-installation-booting">
|
||||
<title>Booting the system</title>
|
||||
|
||||
<para>
|
||||
NixOS can be installed on BIOS or UEFI systems. The procedure for a UEFI
|
||||
installation is by and large the same as a BIOS installation. The
|
||||
differences are mentioned in the steps that follow.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The installation media can be burned to a CD, or now more commonly, "burned"
|
||||
to a USB drive (see <xref linkend="sec-booting-from-usb"/>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The installation media contains a basic NixOS installation. When it’s
|
||||
finished booting, it should have detected most of your hardware.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The NixOS manual is available on virtual console 8 (press Alt+F8 to access)
|
||||
or by running <command>nixos-help</command>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You are logged-in automatically as <literal>root</literal>. (The
|
||||
<literal>root</literal> user account has an empty password.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you downloaded the graphical ISO image, you can run <command>systemctl
|
||||
start display-manager</command> to start KDE. If you want to continue on the
|
||||
terminal, you can use <command>loadkeys</command> to switch to your
|
||||
preferred keyboard layout. (We even provide neo2 via <command>loadkeys de
|
||||
neo</command>!)
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-installation-booting-networking">
|
||||
<title>Networking in the installer</title>
|
||||
|
||||
<para>
|
||||
The boot process should have brought up networking (check <command>ip
|
||||
a</command>). Networking is necessary for the installer, since it will
|
||||
@ -65,58 +51,165 @@
|
||||
binaries). It’s best if you have a DHCP server on your network. Otherwise
|
||||
configure networking manually using <command>ifconfig</command>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To manually configure the network on the graphical installer, first disable
|
||||
network-manager with <command>systemctl stop network-manager</command>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To manually configure the wifi on the minimal installer, run
|
||||
<command>wpa_supplicant -B -i interface -c <(wpa_passphrase 'SSID'
|
||||
'key')</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
||||
<para>
|
||||
If you would like to continue the installation from a different machine you
|
||||
need to activate the SSH daemon via <literal>systemctl start
|
||||
sshd</literal>. In order to be able to login you also need to set a
|
||||
password for <literal>root</literal> using <literal>passwd</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="sec-installation-partitioning">
|
||||
<title>Partitioning and formatting</title>
|
||||
|
||||
<para>
|
||||
The NixOS installer doesn’t do any partitioning or formatting, so you need
|
||||
to do that yourself.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The NixOS installer ships with multiple partitioning tools. The examples
|
||||
below use <command>parted</command>, but also provides
|
||||
<command>fdisk</command>, <command>gdisk</command>,
|
||||
<command>cfdisk</command>, and <command>cgdisk</command>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The recommended partition scheme differs depending if the computer uses
|
||||
<emphasis>Legacy Boot</emphasis> or <emphasis>UEFI</emphasis>.
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-installation-partitioning-UEFI">
|
||||
<title>UEFI (GPT)</title>
|
||||
|
||||
<para>
|
||||
The NixOS installer doesn’t do any partitioning or formatting yet, so you
|
||||
need to do that yourself. Use the following commands:
|
||||
<itemizedlist>
|
||||
Here's an example partition scheme for UEFI, using
|
||||
<filename>/dev/sda</filename> as the device.
|
||||
<note>
|
||||
<para>
|
||||
You can safely ignore <command>parted</command>'s informational message
|
||||
about needing to update /etc/fstab.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
For partitioning: <command>fdisk</command>.
|
||||
<screen>
|
||||
# fdisk /dev/sda # <lineannotation>(or whatever device you want to install on)</lineannotation>
|
||||
-- for UEFI systems only
|
||||
> n # <lineannotation>(create a new partition for /boot)</lineannotation>
|
||||
> 3 # <lineannotation>(make it a partition number 3)</lineannotation>
|
||||
> # <lineannotation>(press enter to accept the default)</lineannotation>
|
||||
> +512M # <lineannotation>(the size of the UEFI boot partition)</lineannotation>
|
||||
> t # <lineannotation>(change the partition type ...)</lineannotation>
|
||||
> 3 # <lineannotation>(... of the boot partition ...)</lineannotation>
|
||||
> 1 # <lineannotation>(... to 'UEFI System')</lineannotation>
|
||||
-- for BIOS or UEFI systems
|
||||
> n # <lineannotation>(create a new partition for /swap)</lineannotation>
|
||||
> 2 # <lineannotation>(make it a partition number 2)</lineannotation>
|
||||
> # <lineannotation>(press enter to accept the default)</lineannotation>
|
||||
> +8G # <lineannotation>(the size of the swap partition, set to whatever you like)</lineannotation>
|
||||
> n # <lineannotation>(create a new partition for /)</lineannotation>
|
||||
> 1 # <lineannotation>(make it a partition number 1)</lineannotation>
|
||||
> # <lineannotation>(press enter to accept the default)</lineannotation>
|
||||
> # <lineannotation>(press enter to accept the default and use the rest of the remaining space)</lineannotation>
|
||||
> a # <lineannotation>(make the partition bootable)</lineannotation>
|
||||
> x # <lineannotation>(enter expert mode)</lineannotation>
|
||||
> f # <lineannotation>(fix up the partition ordering)</lineannotation>
|
||||
> r # <lineannotation>(exit expert mode)</lineannotation>
|
||||
> w # <lineannotation>(write the partition table to disk and exit)</lineannotation></screen>
|
||||
Create a <emphasis>GPT</emphasis> partition table.
|
||||
<screen language="commands"># parted /dev/sda -- mklabel gpt</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Add the <emphasis>root</emphasis> partition. This will fill the disk
|
||||
except for the end part, where the swap will live, and the space left in
|
||||
front (512MiB) which will be used by the boot partition.
|
||||
<screen language="commands"># parted /dev/sda -- mkpart primary 512MiB -8GiB</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Next, add a <emphasis>swap</emphasis> partition. The size required will
|
||||
vary according to needs, here a 8GiB one is created.
|
||||
<screen language="commands"># parted /dev/sda -- mkpart primary linux-swap -8GiB 100%</screen>
|
||||
<note>
|
||||
<para>
|
||||
The swap partition size rules are no different than for other Linux
|
||||
distributions.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Finally, the <emphasis>boot</emphasis> partition. NixOS by default uses
|
||||
the ESP (EFI system partition) as its <emphasis>/boot</emphasis>
|
||||
partition. It uses the initially reserved 512MiB at the start of the
|
||||
disk.
|
||||
<screen language="commands"># parted /dev/sda -- mkpart ESP fat32 1MiB 512MiB
|
||||
# parted /dev/sda -- set 3 boot on</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Once complete, you can follow with
|
||||
<xref linkend="sec-installation-partitioning-formatting"/>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-installation-partitioning-MBR">
|
||||
<title>Legacy Boot (MBR)</title>
|
||||
|
||||
<para>
|
||||
Here's an example partition scheme for Legacy Boot, using
|
||||
<filename>/dev/sda</filename> as the device.
|
||||
<note>
|
||||
<para>
|
||||
You can safely ignore <command>parted</command>'s informational message
|
||||
about needing to update /etc/fstab.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Create a <emphasis>MBR</emphasis> partition table.
|
||||
<screen language="commands"># parted /dev/sda -- mklabel msdos</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Add the <emphasis>root</emphasis> partition. This will fill the the disk
|
||||
except for the end part, where the swap will live.
|
||||
<screen language="commands"># parted /dev/sda -- mkpart primary 1MiB -8GiB</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Finally, add a <emphasis>swap</emphasis> partition. The size required
|
||||
will vary according to needs, here a 8GiB one is created.
|
||||
<screen language="commands"># parted /dev/sda -- mkpart primary linux-swap -8GiB 100%</screen>
|
||||
<note>
|
||||
<para>
|
||||
The swap partition size rules are no different than for other Linux
|
||||
distributions.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Once complete, you can follow with
|
||||
<xref linkend="sec-installation-partitioning-formatting"/>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-installation-partitioning-formatting">
|
||||
<title>Formatting</title>
|
||||
|
||||
<para>
|
||||
Use the following commands:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
For initialising Ext4 partitions: <command>mkfs.ext4</command>. It is
|
||||
@ -169,242 +262,249 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Mount the target file system on which NixOS should be installed on
|
||||
<filename>/mnt</filename>, e.g.
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="sec-installation-installing">
|
||||
<title>Installing</title>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Mount the target file system on which NixOS should be installed on
|
||||
<filename>/mnt</filename>, e.g.
|
||||
<screen>
|
||||
# mount /dev/disk/by-label/nixos /mnt
|
||||
</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
UEFI systems
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Mount the boot file system on <filename>/mnt/boot</filename>, e.g.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
UEFI systems
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Mount the boot file system on <filename>/mnt/boot</filename>, e.g.
|
||||
<screen>
|
||||
# mkdir -p /mnt/boot
|
||||
# mount /dev/disk/by-label/boot /mnt/boot
|
||||
</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If your machine has a limited amount of memory, you may want to activate
|
||||
swap devices now (<command>swapon
|
||||
<replaceable>device</replaceable></command>). The installer (or rather, the
|
||||
build actions that it may spawn) may need quite a bit of RAM, depending on
|
||||
your configuration.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If your machine has a limited amount of memory, you may want to activate
|
||||
swap devices now (<command>swapon
|
||||
<replaceable>device</replaceable></command>). The installer (or rather,
|
||||
the build actions that it may spawn) may need quite a bit of RAM,
|
||||
depending on your configuration.
|
||||
<screen>
|
||||
# swapon /dev/sda2</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
You now need to create a file
|
||||
<filename>/mnt/etc/nixos/configuration.nix</filename> that specifies the
|
||||
intended configuration of the system. This is because NixOS has a
|
||||
<emphasis>declarative</emphasis> configuration model: you create or edit a
|
||||
description of the desired configuration of your system, and then NixOS
|
||||
takes care of making it happen. The syntax of the NixOS configuration file
|
||||
is described in <xref linkend="sec-configuration-syntax"/>, while a list of
|
||||
available configuration options appears in
|
||||
<xref
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
You now need to create a file
|
||||
<filename>/mnt/etc/nixos/configuration.nix</filename> that specifies the
|
||||
intended configuration of the system. This is because NixOS has a
|
||||
<emphasis>declarative</emphasis> configuration model: you create or edit a
|
||||
description of the desired configuration of your system, and then NixOS
|
||||
takes care of making it happen. The syntax of the NixOS configuration file
|
||||
is described in <xref linkend="sec-configuration-syntax"/>, while a list
|
||||
of available configuration options appears in
|
||||
<xref
|
||||
linkend="ch-options"/>. A minimal example is shown in
|
||||
<xref
|
||||
<xref
|
||||
linkend="ex-config"/>.
|
||||
</para>
|
||||
<para>
|
||||
The command <command>nixos-generate-config</command> can generate an
|
||||
initial configuration file for you:
|
||||
</para>
|
||||
<para>
|
||||
The command <command>nixos-generate-config</command> can generate an
|
||||
initial configuration file for you:
|
||||
<screen>
|
||||
# nixos-generate-config --root /mnt</screen>
|
||||
You should then edit <filename>/mnt/etc/nixos/configuration.nix</filename>
|
||||
to suit your needs:
|
||||
You should then edit <filename>/mnt/etc/nixos/configuration.nix</filename>
|
||||
to suit your needs:
|
||||
<screen>
|
||||
# nano /mnt/etc/nixos/configuration.nix
|
||||
</screen>
|
||||
If you’re using the graphical ISO image, other editors may be available
|
||||
(such as <command>vim</command>). If you have network access, you can also
|
||||
install other editors — for instance, you can install Emacs by running
|
||||
<literal>nix-env -i emacs</literal>.
|
||||
</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
BIOS systems
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
You <emphasis>must</emphasis> set the option
|
||||
<xref linkend="opt-boot.loader.grub.device"/> to specify on which disk
|
||||
the GRUB boot loader is to be installed. Without it, NixOS cannot boot.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
UEFI systems
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
You <emphasis>must</emphasis> set the option
|
||||
<xref linkend="opt-boot.loader.systemd-boot.enable"/> to
|
||||
<literal>true</literal>. <command>nixos-generate-config</command> should
|
||||
do this automatically for new configurations when booted in UEFI mode.
|
||||
</para>
|
||||
<para>
|
||||
You may want to look at the options starting with
|
||||
<option><link linkend="opt-boot.loader.efi.canTouchEfiVariables">boot.loader.efi</link></option>
|
||||
and
|
||||
<option><link linkend="opt-boot.loader.systemd-boot.enable">boot.loader.systemd</link></option>
|
||||
as well.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<para>
|
||||
If there are other operating systems running on the machine before
|
||||
installing NixOS, the <xref linkend="opt-boot.loader.grub.useOSProber"/>
|
||||
option can be set to <literal>true</literal> to automatically add them to
|
||||
the grub menu.
|
||||
</para>
|
||||
<para>
|
||||
Another critical option is <option>fileSystems</option>, specifying the
|
||||
file systems that need to be mounted by NixOS. However, you typically
|
||||
don’t need to set it yourself, because
|
||||
<command>nixos-generate-config</command> sets it automatically in
|
||||
<filename>/mnt/etc/nixos/hardware-configuration.nix</filename> from your
|
||||
currently mounted file systems. (The configuration file
|
||||
<filename>hardware-configuration.nix</filename> is included from
|
||||
<filename>configuration.nix</filename> and will be overwritten by future
|
||||
invocations of <command>nixos-generate-config</command>; thus, you
|
||||
generally should not modify it.)
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
Depending on your hardware configuration or type of file system, you may
|
||||
need to set the option <option>boot.initrd.kernelModules</option> to
|
||||
include the kernel modules that are necessary for mounting the root file
|
||||
system, otherwise the installed system will not be able to boot. (If this
|
||||
happens, boot from the CD again, mount the target file system on
|
||||
<filename>/mnt</filename>, fix
|
||||
<filename>/mnt/etc/nixos/configuration.nix</filename> and rerun
|
||||
<filename>nixos-install</filename>.) In most cases,
|
||||
<command>nixos-generate-config</command> will figure out the required
|
||||
modules.
|
||||
If you’re using the graphical ISO image, other editors may be available
|
||||
(such as <command>vim</command>). If you have network access, you can also
|
||||
install other editors — for instance, you can install Emacs by running
|
||||
<literal>nix-env -i emacs</literal>.
|
||||
</para>
|
||||
</note>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Do the installation:
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
BIOS systems
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
You <emphasis>must</emphasis> set the option
|
||||
<xref linkend="opt-boot.loader.grub.device"/> to specify on which disk
|
||||
the GRUB boot loader is to be installed. Without it, NixOS cannot boot.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
UEFI systems
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
You <emphasis>must</emphasis> set the option
|
||||
<xref linkend="opt-boot.loader.systemd-boot.enable"/> to
|
||||
<literal>true</literal>. <command>nixos-generate-config</command>
|
||||
should do this automatically for new configurations when booted in UEFI
|
||||
mode.
|
||||
</para>
|
||||
<para>
|
||||
You may want to look at the options starting with
|
||||
<option><link linkend="opt-boot.loader.efi.canTouchEfiVariables">boot.loader.efi</link></option>
|
||||
and
|
||||
<option><link linkend="opt-boot.loader.systemd-boot.enable">boot.loader.systemd</link></option>
|
||||
as well.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<para>
|
||||
If there are other operating systems running on the machine before
|
||||
installing NixOS, the <xref linkend="opt-boot.loader.grub.useOSProber"/>
|
||||
option can be set to <literal>true</literal> to automatically add them to
|
||||
the grub menu.
|
||||
</para>
|
||||
<para>
|
||||
Another critical option is <option>fileSystems</option>, specifying the
|
||||
file systems that need to be mounted by NixOS. However, you typically
|
||||
don’t need to set it yourself, because
|
||||
<command>nixos-generate-config</command> sets it automatically in
|
||||
<filename>/mnt/etc/nixos/hardware-configuration.nix</filename> from your
|
||||
currently mounted file systems. (The configuration file
|
||||
<filename>hardware-configuration.nix</filename> is included from
|
||||
<filename>configuration.nix</filename> and will be overwritten by future
|
||||
invocations of <command>nixos-generate-config</command>; thus, you
|
||||
generally should not modify it.)
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
Depending on your hardware configuration or type of file system, you may
|
||||
need to set the option <option>boot.initrd.kernelModules</option> to
|
||||
include the kernel modules that are necessary for mounting the root file
|
||||
system, otherwise the installed system will not be able to boot. (If this
|
||||
happens, boot from the installation media again, mount the target file
|
||||
system on <filename>/mnt</filename>, fix
|
||||
<filename>/mnt/etc/nixos/configuration.nix</filename> and rerun
|
||||
<filename>nixos-install</filename>.) In most cases,
|
||||
<command>nixos-generate-config</command> will figure out the required
|
||||
modules.
|
||||
</para>
|
||||
</note>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Do the installation:
|
||||
<screen>
|
||||
# nixos-install</screen>
|
||||
Cross fingers. If this fails due to a temporary problem (such as a network
|
||||
issue while downloading binaries from the NixOS binary cache), you can just
|
||||
re-run <command>nixos-install</command>. Otherwise, fix your
|
||||
<filename>configuration.nix</filename> and then re-run
|
||||
<command>nixos-install</command>.
|
||||
</para>
|
||||
<para>
|
||||
As the last step, <command>nixos-install</command> will ask you to set the
|
||||
password for the <literal>root</literal> user, e.g.
|
||||
Cross fingers. If this fails due to a temporary problem (such as a network
|
||||
issue while downloading binaries from the NixOS binary cache), you can
|
||||
just re-run <command>nixos-install</command>. Otherwise, fix your
|
||||
<filename>configuration.nix</filename> and then re-run
|
||||
<command>nixos-install</command>.
|
||||
</para>
|
||||
<para>
|
||||
As the last step, <command>nixos-install</command> will ask you to set the
|
||||
password for the <literal>root</literal> user, e.g.
|
||||
<screen>
|
||||
setting root password...
|
||||
Enter new UNIX password: ***
|
||||
Retype new UNIX password: ***
|
||||
</screen>
|
||||
<note>
|
||||
<para>
|
||||
For unattended installations, it is possible to use
|
||||
<command>nixos-install --no-root-passwd</command>
|
||||
in order to disable the password prompt entirely.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If everything went well:
|
||||
Retype new UNIX password: ***</screen>
|
||||
<note>
|
||||
<para>
|
||||
For unattended installations, it is possible to use
|
||||
<command>nixos-install --no-root-passwd</command> in order to disable
|
||||
the password prompt entirely.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If everything went well:
|
||||
<screen>
|
||||
# reboot</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
You should now be able to boot into the installed NixOS. The GRUB boot menu
|
||||
shows a list of <emphasis>available configurations</emphasis> (initially
|
||||
just one). Every time you change the NixOS configuration (see
|
||||
<link
|
||||
# reboot</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
You should now be able to boot into the installed NixOS. The GRUB boot
|
||||
menu shows a list of <emphasis>available configurations</emphasis>
|
||||
(initially just one). Every time you change the NixOS configuration (see
|
||||
<link
|
||||
linkend="sec-changing-config">Changing Configuration</link>
|
||||
), a new item is added to the menu. This allows you to easily roll back to
|
||||
a previous configuration if something goes wrong.
|
||||
</para>
|
||||
<para>
|
||||
You should log in and change the <literal>root</literal> password with
|
||||
<command>passwd</command>.
|
||||
</para>
|
||||
<para>
|
||||
You’ll probably want to create some user accounts as well, which can be
|
||||
done with <command>useradd</command>:
|
||||
), a new item is added to the menu. This allows you to easily roll back to
|
||||
a previous configuration if something goes wrong.
|
||||
</para>
|
||||
<para>
|
||||
You should log in and change the <literal>root</literal> password with
|
||||
<command>passwd</command>.
|
||||
</para>
|
||||
<para>
|
||||
You’ll probably want to create some user accounts as well, which can be
|
||||
done with <command>useradd</command>:
|
||||
<screen>
|
||||
$ useradd -c 'Eelco Dolstra' -m eelco
|
||||
$ passwd eelco</screen>
|
||||
</para>
|
||||
<para>
|
||||
You may also want to install some software. For instance,
|
||||
</para>
|
||||
<para>
|
||||
You may also want to install some software. For instance,
|
||||
<screen>
|
||||
$ nix-env -qa \*</screen>
|
||||
shows what packages are available, and
|
||||
shows what packages are available, and
|
||||
<screen>
|
||||
$ nix-env -i w3m</screen>
|
||||
install the <literal>w3m</literal> browser.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<para>
|
||||
To summarise, <xref linkend="ex-install-sequence" /> shows a typical sequence
|
||||
of commands for installing NixOS on an empty hard drive (here
|
||||
<filename>/dev/sda</filename>). <xref linkend="ex-config"
|
||||
install the <literal>w3m</literal> browser.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
<section xml:id="sec-installation-summary">
|
||||
<title>Installation summary</title>
|
||||
|
||||
<para>
|
||||
To summarise, <xref linkend="ex-install-sequence" /> shows a typical
|
||||
sequence of commands for installing NixOS on an empty hard drive (here
|
||||
<filename>/dev/sda</filename>). <xref linkend="ex-config"
|
||||
/> shows a
|
||||
corresponding configuration Nix expression.
|
||||
</para>
|
||||
<example xml:id='ex-install-sequence'>
|
||||
<title>Commands for Installing NixOS on <filename>/dev/sda</filename></title>
|
||||
<screen>
|
||||
# fdisk /dev/sda # <lineannotation>(or whatever device you want to install on)</lineannotation>
|
||||
-- for UEFI systems only
|
||||
> n # <lineannotation>(create a new partition for /boot)</lineannotation>
|
||||
> 3 # <lineannotation>(make it a partition number 3)</lineannotation>
|
||||
> # <lineannotation>(press enter to accept the default)</lineannotation>
|
||||
> +512M # <lineannotation>(the size of the UEFI boot partition)</lineannotation>
|
||||
> t # <lineannotation>(change the partition type ...)</lineannotation>
|
||||
> 3 # <lineannotation>(... of the boot partition ...)</lineannotation>
|
||||
> 1 # <lineannotation>(... to 'UEFI System')</lineannotation>
|
||||
-- for BIOS or UEFI systems
|
||||
> n # <lineannotation>(create a new partition for /swap)</lineannotation>
|
||||
> 2 # <lineannotation>(make it a partition number 2)</lineannotation>
|
||||
> # <lineannotation>(press enter to accept the default)</lineannotation>
|
||||
> +8G # <lineannotation>(the size of the swap partition)</lineannotation>
|
||||
> n # <lineannotation>(create a new partition for /)</lineannotation>
|
||||
> 1 # <lineannotation>(make it a partition number 1)</lineannotation>
|
||||
> # <lineannotation>(press enter to accept the default)</lineannotation>
|
||||
> # <lineannotation>(press enter to accept the default and use the rest of the remaining space)</lineannotation>
|
||||
> a # <lineannotation>(make the partition bootable)</lineannotation>
|
||||
> x # <lineannotation>(enter expert mode)</lineannotation>
|
||||
> f # <lineannotation>(fix up the partition ordering)</lineannotation>
|
||||
> r # <lineannotation>(exit expert mode)</lineannotation>
|
||||
> w # <lineannotation>(write the partition table to disk and exit)</lineannotation>
|
||||
corresponding configuration Nix expression.
|
||||
</para>
|
||||
|
||||
<example xml:id="ex-partition-scheme-MBR">
|
||||
<title>Example partition schemes for NixOS on <filename>/dev/sda</filename> (MBR)</title>
|
||||
<screen language="commands">
|
||||
# parted /dev/sda -- mklabel msdos
|
||||
# parted /dev/sda -- mkpart primary 1MiB -8GiB
|
||||
# parted /dev/sda -- mkpart primary linux-swap -8GiB 100%</screen>
|
||||
</example>
|
||||
|
||||
<example xml:id="ex-partition-scheme-UEFI">
|
||||
<title>Example partition schemes for NixOS on <filename>/dev/sda</filename> (UEFI)</title>
|
||||
<screen language="commands">
|
||||
# parted /dev/sda -- mklabel gpt
|
||||
# parted /dev/sda -- mkpart primary 512MiB -8GiB
|
||||
# parted /dev/sda -- mkpart primary linux-swap -8GiB 100%
|
||||
# parted /dev/sda -- mkpart ESP fat32 1MiB 512MiB
|
||||
# parted /dev/sda -- set 3 boot on</screen>
|
||||
</example>
|
||||
|
||||
<example xml:id="ex-install-sequence">
|
||||
<title>Commands for Installing NixOS on <filename>/dev/sda</filename></title>
|
||||
<para>
|
||||
With a partitioned disk.
|
||||
<screen language="commands">
|
||||
# mkfs.ext4 -L nixos /dev/sda1
|
||||
# mkswap -L swap /dev/sda2
|
||||
# swapon /dev/sda2
|
||||
@ -416,9 +516,11 @@ $ nix-env -i w3m</screen>
|
||||
# nano /mnt/etc/nixos/configuration.nix
|
||||
# nixos-install
|
||||
# reboot</screen>
|
||||
</example>
|
||||
<example xml:id='ex-config'>
|
||||
<title>NixOS Configuration</title>
|
||||
</para>
|
||||
</example>
|
||||
|
||||
<example xml:id='ex-config'>
|
||||
<title>NixOS Configuration</title>
|
||||
<screen>
|
||||
{ config, pkgs, ... }: {
|
||||
imports = [
|
||||
@ -438,10 +540,19 @@ $ nix-env -i w3m</screen>
|
||||
services.sshd.enable = true;
|
||||
}
|
||||
</screen>
|
||||
</example>
|
||||
<xi:include href="installing-usb.xml" />
|
||||
<xi:include href="installing-pxe.xml" />
|
||||
<xi:include href="installing-virtualbox-guest.xml" />
|
||||
<xi:include href="installing-from-other-distro.xml" />
|
||||
<xi:include href="installing-behind-a-proxy.xml" />
|
||||
</example>
|
||||
</section>
|
||||
<section xml:id="sec-installation-additional-notes">
|
||||
<title>Additional installation notes</title>
|
||||
|
||||
<xi:include href="installing-usb.xml" />
|
||||
|
||||
<xi:include href="installing-pxe.xml" />
|
||||
|
||||
<xi:include href="installing-virtualbox-guest.xml" />
|
||||
|
||||
<xi:include href="installing-from-other-distro.xml" />
|
||||
|
||||
<xi:include href="installing-behind-a-proxy.xml" />
|
||||
</section>
|
||||
</chapter>
|
||||
|
@ -52,10 +52,13 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
To see what channels are available, go to
|
||||
<link
|
||||
xlink:href="https://nixos.org/channels"/>. (Note that the URIs of the
|
||||
<link xlink:href="https://nixos.org/channels"/>. (Note that the URIs of the
|
||||
various channels redirect to a directory that contains the channel’s latest
|
||||
version and includes ISO images and VirtualBox appliances.)
|
||||
version and includes ISO images and VirtualBox appliances.) Please note that
|
||||
during the release process, channels that are not yet released will be
|
||||
present here as well. See the Getting NixOS page
|
||||
<link xlink:href="https://nixos.org/nixos/download.html"/> to find the newest
|
||||
supported stable release.
|
||||
</para>
|
||||
<para>
|
||||
When you first install NixOS, you’re automatically subscribed to the NixOS
|
||||
|
@ -17,8 +17,8 @@
|
||||
<para>
|
||||
If you encounter problems, please report them on the
|
||||
<literal
|
||||
xlink:href="https://discourse.nixos.org">Discourse</literal>
|
||||
or on the <link
|
||||
xlink:href="https://discourse.nixos.org">Discourse</literal> or
|
||||
on the <link
|
||||
xlink:href="irc://irc.freenode.net/#nixos">
|
||||
<literal>#nixos</literal> channel on Freenode</link>. Bugs should be
|
||||
reported in
|
||||
|
@ -4,6 +4,7 @@
|
||||
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
|
||||
xmlns:str="http://exslt.org/strings"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:nixos="tag:nixos.org"
|
||||
xmlns="http://docbook.org/ns/docbook"
|
||||
extension-element-prefixes="str"
|
||||
>
|
||||
@ -30,10 +31,12 @@
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>
|
||||
<xsl:value-of disable-output-escaping="yes"
|
||||
select="attr[@name = 'description']/string/@value" />
|
||||
</para>
|
||||
<nixos:option-description>
|
||||
<para>
|
||||
<xsl:value-of disable-output-escaping="yes"
|
||||
select="attr[@name = 'description']/string/@value" />
|
||||
</para>
|
||||
</nixos:option-description>
|
||||
|
||||
<xsl:if test="attr[@name = 'type']">
|
||||
<para>
|
||||
|
115
nixos/doc/manual/postprocess-option-descriptions.xsl
Normal file
115
nixos/doc/manual/postprocess-option-descriptions.xsl
Normal file
@ -0,0 +1,115 @@
|
||||
<?xml version="1.0"?>
|
||||
|
||||
<xsl:stylesheet version="1.0"
|
||||
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
|
||||
xmlns:str="http://exslt.org/strings"
|
||||
xmlns:exsl="http://exslt.org/common"
|
||||
xmlns:db="http://docbook.org/ns/docbook"
|
||||
xmlns:nixos="tag:nixos.org"
|
||||
extension-element-prefixes="str exsl">
|
||||
<xsl:output method='xml' encoding="UTF-8" />
|
||||
|
||||
<xsl:template match="@*|node()">
|
||||
<xsl:copy>
|
||||
<xsl:apply-templates select="@*|node()" />
|
||||
</xsl:copy>
|
||||
</xsl:template>
|
||||
|
||||
<xsl:template name="break-up-description">
|
||||
<xsl:param name="input" />
|
||||
<xsl:param name="buffer" />
|
||||
|
||||
<!-- Every time we have two newlines following each other, we want to
|
||||
break it into </para><para>. -->
|
||||
<xsl:variable name="parbreak" select="'

'" />
|
||||
|
||||
<!-- Similar to "(head:tail) = input" in Haskell. -->
|
||||
<xsl:variable name="head" select="$input[1]" />
|
||||
<xsl:variable name="tail" select="$input[position() > 1]" />
|
||||
|
||||
<xsl:choose>
|
||||
<xsl:when test="$head/self::text() and contains($head, $parbreak)">
|
||||
<!-- If the haystack provided to str:split() directly starts or
|
||||
ends with $parbreak, it doesn't generate a <token/> for that,
|
||||
so we are doing this here. -->
|
||||
<xsl:variable name="splitted-raw">
|
||||
<xsl:if test="starts-with($head, $parbreak)"><token /></xsl:if>
|
||||
<xsl:for-each select="str:split($head, $parbreak)">
|
||||
<token><xsl:value-of select="node()" /></token>
|
||||
</xsl:for-each>
|
||||
<!-- Something like ends-with($head, $parbreak), but there is
|
||||
no ends-with() in XSLT, so we need to use substring(). -->
|
||||
<xsl:if test="
|
||||
substring($head, string-length($head) -
|
||||
string-length($parbreak) + 1) = $parbreak
|
||||
"><token /></xsl:if>
|
||||
</xsl:variable>
|
||||
<xsl:variable name="splitted"
|
||||
select="exsl:node-set($splitted-raw)/token" />
|
||||
<!-- The buffer we had so far didn't contain any text nodes that
|
||||
contain a $parbreak, so we can put the buffer along with the
|
||||
first token of $splitted into a para element. -->
|
||||
<para xmlns="http://docbook.org/ns/docbook">
|
||||
<xsl:apply-templates select="exsl:node-set($buffer)" />
|
||||
<xsl:apply-templates select="$splitted[1]/node()" />
|
||||
</para>
|
||||
<!-- We have already emitted the first splitted result, so the
|
||||
last result is going to be set as the new $buffer later
|
||||
because its contents may not be directly followed up by a
|
||||
$parbreak. -->
|
||||
<xsl:for-each select="$splitted[position() > 1
|
||||
and position() < last()]">
|
||||
<para xmlns="http://docbook.org/ns/docbook">
|
||||
<xsl:apply-templates select="node()" />
|
||||
</para>
|
||||
</xsl:for-each>
|
||||
<xsl:call-template name="break-up-description">
|
||||
<xsl:with-param name="input" select="$tail" />
|
||||
<xsl:with-param name="buffer" select="$splitted[last()]/node()" />
|
||||
</xsl:call-template>
|
||||
</xsl:when>
|
||||
<!-- Either non-text node or one without $parbreak, which we just
|
||||
want to buffer and continue recursing. -->
|
||||
<xsl:when test="$input">
|
||||
<xsl:call-template name="break-up-description">
|
||||
<xsl:with-param name="input" select="$tail" />
|
||||
<!-- This essentially appends $head to $buffer. -->
|
||||
<xsl:with-param name="buffer">
|
||||
<xsl:if test="$buffer">
|
||||
<xsl:for-each select="exsl:node-set($buffer)">
|
||||
<xsl:apply-templates select="." />
|
||||
</xsl:for-each>
|
||||
</xsl:if>
|
||||
<xsl:apply-templates select="$head" />
|
||||
</xsl:with-param>
|
||||
</xsl:call-template>
|
||||
</xsl:when>
|
||||
<!-- No more $input, just put the remaining $buffer in a para. -->
|
||||
<xsl:otherwise>
|
||||
<para xmlns="http://docbook.org/ns/docbook">
|
||||
<xsl:apply-templates select="exsl:node-set($buffer)" />
|
||||
</para>
|
||||
</xsl:otherwise>
|
||||
</xsl:choose>
|
||||
</xsl:template>
|
||||
|
||||
<xsl:template match="nixos:option-description">
|
||||
<xsl:choose>
|
||||
<!--
|
||||
Only process nodes that are comprised of a single <para/> element,
|
||||
because if that's not the case the description already contains
|
||||
</para><para> in between and we need no further processing.
|
||||
-->
|
||||
<xsl:when test="count(db:para) > 1">
|
||||
<xsl:apply-templates select="node()" />
|
||||
</xsl:when>
|
||||
<xsl:otherwise>
|
||||
<xsl:call-template name="break-up-description">
|
||||
<xsl:with-param name="input"
|
||||
select="exsl:node-set(db:para/node())" />
|
||||
</xsl:call-template>
|
||||
</xsl:otherwise>
|
||||
</xsl:choose>
|
||||
</xsl:template>
|
||||
|
||||
</xsl:stylesheet>
|
@ -8,6 +8,7 @@
|
||||
This section lists the release notes for each stable version of NixOS and
|
||||
current unstable revision.
|
||||
</para>
|
||||
<xi:include href="rl-1903.xml" />
|
||||
<xi:include href="rl-1809.xml" />
|
||||
<xi:include href="rl-1803.xml" />
|
||||
<xi:include href="rl-1709.xml" />
|
||||
|
@ -435,11 +435,11 @@ system.autoUpgrade.enable = true;
|
||||
<programlisting>
|
||||
system.stateVersion = "14.12";
|
||||
</programlisting>
|
||||
The new option <option>system.stateVersion</option> ensures that
|
||||
certain configuration changes that could break existing systems (such as
|
||||
the <command>sshd</command> host key setting) will maintain compatibility
|
||||
with the specified NixOS release. NixOps sets the state version of
|
||||
existing deployments automatically.
|
||||
The new option <option>system.stateVersion</option> ensures that certain
|
||||
configuration changes that could break existing systems (such as the
|
||||
<command>sshd</command> host key setting) will maintain compatibility with
|
||||
the specified NixOS release. NixOps sets the state version of existing
|
||||
deployments automatically.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -3,7 +3,7 @@
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-release-18.09">
|
||||
<title>Release 18.09 (“Jellyfish”, 2018/09/??)</title>
|
||||
<title>Release 18.09 (“Jellyfish”, 2018/10/05)</title>
|
||||
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
@ -14,18 +14,56 @@
|
||||
|
||||
<para>
|
||||
In addition to numerous new and upgraded packages, this release has the
|
||||
following highlights:
|
||||
following notable updates:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Support for wrapping binaries using <literal>firejail</literal> has been
|
||||
added through <varname>programs.firejail.wrappedBinaries</varname>.
|
||||
</para>
|
||||
<para>
|
||||
For example
|
||||
</para>
|
||||
<para>
|
||||
End of support is planned for end of April 2019, handing over to 19.03.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Platform support: x86_64-linux and x86_64-darwin as always. Support for
|
||||
aarch64-linux is as with the previous releases, not equivalent to the
|
||||
x86-64-linux release, but with efforts to reach parity.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Nix has been updated to 2.1; see its
|
||||
<link xlink:href="https://nixos.org/nix/manual/#ssec-relnotes-2.1">release
|
||||
notes</link>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Core versions: linux: 4.14 LTS (unchanged), glibc: 2.26 → 2.27, gcc: 7
|
||||
(unchanged), systemd: 237 → 239.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Desktop version changes: gnome: 3.26 → 3.28, (KDE) plasma-desktop: 5.12
|
||||
→ 5.13.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Notable changes and additions for 18.09 include:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Support for wrapping binaries using <literal>firejail</literal> has been
|
||||
added through <varname>programs.firejail.wrappedBinaries</varname>.
|
||||
</para>
|
||||
<para>
|
||||
For example
|
||||
</para>
|
||||
<programlisting>
|
||||
programs.firejail = {
|
||||
enable = true;
|
||||
@ -35,9 +73,10 @@ programs.firejail = {
|
||||
};
|
||||
};
|
||||
</programlisting>
|
||||
<para>
|
||||
This will place <literal>firefox</literal> and <literal>mpv</literal> binaries in the global path wrapped by firejail.
|
||||
</para>
|
||||
<para>
|
||||
This will place <literal>firefox</literal> and <literal>mpv</literal>
|
||||
binaries in the global path wrapped by firejail.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
@ -69,52 +108,355 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
||||
<title>New Services</title>
|
||||
|
||||
<para>
|
||||
The following new services were added since the last release:
|
||||
A curated selection of new services that were added since the last release:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The <varname>services.cassandra</varname> module has been reworked and
|
||||
was rewritten from scratch. The service has succeeding tests for
|
||||
the versions 2.1, 2.2, 3.0 and 3.11 of <link
|
||||
xlink:href="https://cassandra.apache.org/">Apache Cassandra</link>.
|
||||
The <varname>services.cassandra</varname> module has been reworked and was
|
||||
rewritten from scratch. The service has succeeding tests for the versions
|
||||
2.1, 2.2, 3.0 and 3.11 of
|
||||
<link
|
||||
xlink:href="https://cassandra.apache.org/">Apache
|
||||
Cassandra</link>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
There is a new <varname>services.foundationdb</varname> module for deploying
|
||||
<link xlink:href="https://www.foundationdb.org">FoundationDB</link> clusters.
|
||||
There is a new <varname>services.foundationdb</varname> module for
|
||||
deploying
|
||||
<link xlink:href="https://www.foundationdb.org">FoundationDB</link>
|
||||
clusters.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
When enabled the <literal>iproute2</literal> will copy the files expected
|
||||
by ip route (e.g., <filename>rt_tables</filename>) in
|
||||
<filename>/run/iproute2</filename>. This allows to write aliases for
|
||||
<filename>/etc/iproute2</filename>. This allows to write aliases for
|
||||
routing tables for instance.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<varname>services.strongswan-swanctl</varname>
|
||||
is a modern replacement for <varname>services.strongswan</varname>.
|
||||
You can use either one of them to setup IPsec VPNs but not both at the same time.
|
||||
<varname>services.strongswan-swanctl</varname> is a modern replacement for
|
||||
<varname>services.strongswan</varname>. You can use either one of them to
|
||||
setup IPsec VPNs but not both at the same time.
|
||||
</para>
|
||||
<para>
|
||||
<varname>services.strongswan-swanctl</varname> uses the
|
||||
<link xlink:href="https://wiki.strongswan.org/projects/strongswan/wiki/swanctl">swanctl</link>
|
||||
command which uses the modern
|
||||
<link xlink:href="https://github.com/strongswan/strongswan/blob/master/src/libcharon/plugins/vici/README.md">vici</link>
|
||||
<emphasis>Versatile IKE Configuration Interface</emphasis>.
|
||||
The deprecated <literal>ipsec</literal> command used in <varname>services.strongswan</varname> is using the legacy
|
||||
<link xlink:href="https://github.com/strongswan/strongswan/blob/master/README_LEGACY.md">stroke configuration interface</link>.
|
||||
<varname>services.strongswan-swanctl</varname> uses the
|
||||
<link xlink:href="https://wiki.strongswan.org/projects/strongswan/wiki/swanctl">swanctl</link>
|
||||
command which uses the modern
|
||||
<link xlink:href="https://github.com/strongswan/strongswan/blob/master/src/libcharon/plugins/vici/README.md">vici</link>
|
||||
<emphasis>Versatile IKE Configuration Interface</emphasis>. The deprecated
|
||||
<literal>ipsec</literal> command used in
|
||||
<varname>services.strongswan</varname> is using the legacy
|
||||
<link xlink:href="https://github.com/strongswan/strongswan/blob/master/README_LEGACY.md">stroke
|
||||
configuration interface</link>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The new <varname>services.elasticsearch-curator</varname> service
|
||||
periodically curates or manages, your Elasticsearch indices and snapshots.
|
||||
The new <varname>services.elasticsearch-curator</varname> service
|
||||
periodically curates or manages, your Elasticsearch indices and snapshots.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Every new services:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./config/xdg/autostart.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./config/xdg/icons.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./config/xdg/menus.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./config/xdg/mime.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./hardware/brightnessctl.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./hardware/onlykey.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./hardware/video/uvcvideo/default.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./misc/documentation.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./programs/firejail.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./programs/iftop.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./programs/sedutil.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./programs/singularity.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./programs/xss-lock.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./programs/zsh/zsh-autosuggestions.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/admin/oxidized.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/backup/duplicati.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/backup/restic.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/backup/restic-rest-server.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/cluster/hadoop/default.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/databases/aerospike.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/databases/monetdb.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/desktops/bamf.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/desktops/flatpak.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/desktops/zeitgeist.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/development/bloop.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/development/jupyter/default.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/hardware/lcd.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/hardware/undervolt.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/misc/clipmenu.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/misc/gitweb.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/misc/serviio.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/misc/safeeyes.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/misc/sysprof.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/misc/weechat.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/monitoring/datadog-agent.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/monitoring/incron.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/networking/dnsdist.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/networking/freeradius.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/networking/hans.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/networking/morty.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/networking/ndppd.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/networking/ocserv.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/networking/owamp.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/networking/quagga.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/networking/shadowsocks.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/networking/stubby.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/networking/zeronet.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/security/certmgr.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/security/cfssl.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/security/oauth2_proxy_nginx.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/web-apps/virtlyst.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/web-apps/youtrack.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/web-servers/hitch/default.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/web-servers/hydron.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/web-servers/meguca.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./services/web-servers/nginx/gitweb.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./virtualisation/kvmgt.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>./virtualisation/qemu-guest-agent.nix</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
@ -135,8 +477,50 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The deprecated <varname>services.cassandra</varname> module has
|
||||
seen a complete rewrite. (See above.)
|
||||
Some licenses that were incorrectly not marked as unfree now are. This is
|
||||
the case for:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
cc-by-nc-sa-20: Creative Commons Attribution Non Commercial Share Alike
|
||||
2.0
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
cc-by-nc-sa-25: Creative Commons Attribution Non Commercial Share Alike
|
||||
2.5
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
cc-by-nc-sa-30: Creative Commons Attribution Non Commercial Share Alike
|
||||
3.0
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
cc-by-nc-sa-40: Creative Commons Attribution Non Commercial Share Alike
|
||||
4.0
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
cc-by-nd-30: Creative Commons Attribution-No Derivative Works v3.00
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
msrla: Microsoft Research License Agreement
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The deprecated <varname>services.cassandra</varname> module has seen a
|
||||
complete rewrite. (See above.)
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -186,41 +570,44 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<varname>services.munge</varname> now runs as user (and group) <literal>munge</literal> instead of root.
|
||||
Make sure the key file is accessible to the daemon.
|
||||
<varname>services.munge</varname> now runs as user (and group)
|
||||
<literal>munge</literal> instead of root. Make sure the key file is
|
||||
accessible to the daemon.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<varname>dockerTools.buildImage</varname> now uses <literal>null</literal> as default value for <varname>tag</varname>,
|
||||
which indicates that the nix output hash will be used as tag.
|
||||
<varname>dockerTools.buildImage</varname> now uses <literal>null</literal>
|
||||
as default value for <varname>tag</varname>, which indicates that the nix
|
||||
output hash will be used as tag.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The ELK stack: <varname>elasticsearch</varname>, <varname>logstash</varname> and <varname>kibana</varname>
|
||||
has been upgraded from 2.* to 6.3.*.
|
||||
The 2.* versions have been <link xlink:href="https://www.elastic.co/support/eol">unsupported since last year</link>
|
||||
so they have been removed. You can still use the 5.* versions under the names
|
||||
<varname>elasticsearch5</varname>, <varname>logstash5</varname> and
|
||||
<varname>kibana5</varname>.
|
||||
The ELK stack: <varname>elasticsearch</varname>,
|
||||
<varname>logstash</varname> and <varname>kibana</varname> has been
|
||||
upgraded from 2.* to 6.3.*. The 2.* versions have been
|
||||
<link xlink:href="https://www.elastic.co/support/eol">unsupported since
|
||||
last year</link> so they have been removed. You can still use the 5.*
|
||||
versions under the names <varname>elasticsearch5</varname>,
|
||||
<varname>logstash5</varname> and <varname>kibana5</varname>.
|
||||
</para>
|
||||
<para>
|
||||
The elastic beats:
|
||||
<varname>filebeat</varname>, <varname>heartbeat</varname>,
|
||||
<varname>metricbeat</varname> and <varname>packetbeat</varname>
|
||||
have had the same treatment: they now target 6.3.* as well.
|
||||
The 5.* versions are available under the names:
|
||||
The elastic beats: <varname>filebeat</varname>,
|
||||
<varname>heartbeat</varname>, <varname>metricbeat</varname> and
|
||||
<varname>packetbeat</varname> have had the same treatment: they now target
|
||||
6.3.* as well. The 5.* versions are available under the names:
|
||||
<varname>filebeat5</varname>, <varname>heartbeat5</varname>,
|
||||
<varname>metricbeat5</varname> and <varname>packetbeat5</varname>
|
||||
</para>
|
||||
<para>
|
||||
The ELK-6.3 stack now comes with
|
||||
<link xlink:href="https://www.elastic.co/products/x-pack/open">X-Pack by default</link>.
|
||||
Since X-Pack is licensed under the
|
||||
<link xlink:href="https://github.com/elastic/elasticsearch/blob/master/licenses/ELASTIC-LICENSE.txt">Elastic License</link>
|
||||
the ELK packages now have an unfree license. To use them you need to specify
|
||||
<literal>allowUnfree = true;</literal> in your nixpkgs configuration.
|
||||
<link xlink:href="https://www.elastic.co/products/x-pack/open">X-Pack by
|
||||
default</link>. Since X-Pack is licensed under the
|
||||
<link xlink:href="https://github.com/elastic/elasticsearch/blob/master/licenses/ELASTIC-LICENSE.txt">Elastic
|
||||
License</link> the ELK packages now have an unfree license. To use them
|
||||
you need to specify <literal>allowUnfree = true;</literal> in your nixpkgs
|
||||
configuration.
|
||||
</para>
|
||||
<para>
|
||||
Fortunately there is also a free variant of the ELK stack without X-Pack.
|
||||
@ -231,20 +618,23 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Options
|
||||
<literal>boot.initrd.luks.devices.<replaceable>name</replaceable>.yubikey.ramfsMountPoint</literal>
|
||||
<literal>boot.initrd.luks.devices.<replaceable>name</replaceable>.yubikey.storage.mountPoint</literal>
|
||||
were removed. <literal>luksroot.nix</literal> module never supported more than one YubiKey at
|
||||
a time anyway, hence those options never had any effect. You should be able to remove them
|
||||
from your config without any issues.
|
||||
Options
|
||||
<literal>boot.initrd.luks.devices.<replaceable>name</replaceable>.yubikey.ramfsMountPoint</literal>
|
||||
<literal>boot.initrd.luks.devices.<replaceable>name</replaceable>.yubikey.storage.mountPoint</literal>
|
||||
were removed. <literal>luksroot.nix</literal> module never supported more
|
||||
than one YubiKey at a time anyway, hence those options never had any
|
||||
effect. You should be able to remove them from your config without any
|
||||
issues.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>stdenv.system</literal> and <literal>system</literal> in nixpkgs now refer to the host platform instead of the build platform.
|
||||
For native builds this is not change, let alone a breaking one.
|
||||
For cross builds, it is a breaking change, and <literal>stdenv.buildPlatform.system</literal> can be used instead for the old behavior.
|
||||
They should be using that anyways for clarity.
|
||||
<literal>stdenv.system</literal> and <literal>system</literal> in nixpkgs
|
||||
now refer to the host platform instead of the build platform. For native
|
||||
builds this is not change, let alone a breaking one. For cross builds, it
|
||||
is a breaking change, and <literal>stdenv.buildPlatform.system</literal>
|
||||
can be used instead for the old behavior. They should be using that
|
||||
anyways for clarity.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
@ -298,26 +688,33 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>pkgs</literal> argument to NixOS modules can now be set directly using <literal>nixpkgs.pkgs</literal>. Previously, only the <literal>system</literal>, <literal>config</literal> and <literal>overlays</literal> arguments could be used to influence <literal>pkgs</literal>.
|
||||
The <literal>pkgs</literal> argument to NixOS modules can now be set
|
||||
directly using <literal>nixpkgs.pkgs</literal>. Previously, only the
|
||||
<literal>system</literal>, <literal>config</literal> and
|
||||
<literal>overlays</literal> arguments could be used to influence
|
||||
<literal>pkgs</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
A NixOS system can now be constructed more easily based on a preexisting invocation of Nixpkgs. For example:
|
||||
<programlisting>
|
||||
A NixOS system can now be constructed more easily based on a preexisting
|
||||
invocation of Nixpkgs. For example:
|
||||
<programlisting>
|
||||
inherit (pkgs.nixos {
|
||||
boot.loader.grub.enable = false;
|
||||
fileSystems."/".device = "/dev/xvda1";
|
||||
}) toplevel kernel initialRamdisk manual;
|
||||
</programlisting>
|
||||
|
||||
This benefits evaluation performance, lets you write Nixpkgs packages that depend on NixOS images and is consistent with a deployment architecture that would be centered around Nixpkgs overlays.
|
||||
This benefits evaluation performance, lets you write Nixpkgs packages that
|
||||
depend on NixOS images and is consistent with a deployment architecture
|
||||
that would be centered around Nixpkgs overlays.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>lib.traceValIfNot</literal> has been deprecated. Use
|
||||
<literal>if/then/else</literal> and <literal>lib.traceValSeq</literal> instead.
|
||||
<literal>lib.traceValIfNot</literal> has been deprecated. Use
|
||||
<literal>if/then/else</literal> and <literal>lib.traceValSeq</literal>
|
||||
instead.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -336,9 +733,9 @@ inherit (pkgs.nixos {
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>lib.recursiveUpdateUntil</literal> was not acting according to its
|
||||
specification. It has been fixed to act according to the docstring, and a
|
||||
test has been added.
|
||||
<literal>lib.recursiveUpdateUntil</literal> was not acting according to
|
||||
its specification. It has been fixed to act according to the docstring,
|
||||
and a test has been added.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -408,11 +805,11 @@ inherit (pkgs.nixos {
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The Kubernetes package has been bumped to major version 1.11.
|
||||
Please consult the
|
||||
<link xlink:href="https://github.com/kubernetes/kubernetes/blob/release-1.11/CHANGELOG-1.11.md">release notes</link>
|
||||
for details on new features and api changes.
|
||||
<para>
|
||||
The Kubernetes package has been bumped to major version 1.11. Please
|
||||
consult the
|
||||
<link xlink:href="https://github.com/kubernetes/kubernetes/blob/release-1.11/CHANGELOG-1.11.md">release
|
||||
notes</link> for details on new features and api changes.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -432,8 +829,8 @@ inherit (pkgs.nixos {
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The option <varname>services.kubernetes.apiserver.address</varname>
|
||||
was renamed to <varname>services.kubernetes.apiserver.bindAddress</varname>.
|
||||
The option <varname>services.kubernetes.apiserver.address</varname> was
|
||||
renamed to <varname>services.kubernetes.apiserver.bindAddress</varname>.
|
||||
Note that the default value has changed from 127.0.0.1 to 0.0.0.0.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -445,76 +842,86 @@ inherit (pkgs.nixos {
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The option <varname>services.kubernetes.addons.dashboard.enableRBAC</varname>
|
||||
was renamed to <varname>services.kubernetes.addons.dashboard.rbac.enable</varname>.
|
||||
The option
|
||||
<varname>services.kubernetes.addons.dashboard.enableRBAC</varname> was
|
||||
renamed to
|
||||
<varname>services.kubernetes.addons.dashboard.rbac.enable</varname>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The Kubernetes Dashboard now has only minimal RBAC permissions by default.
|
||||
If dashboard cluster-admin rights are desired,
|
||||
set <varname>services.kubernetes.addons.dashboard.rbac.clusterAdmin</varname> to true.
|
||||
On existing clusters, in order for the revocation of privileges to take effect,
|
||||
the current ClusterRoleBinding for kubernetes-dashboard must be manually removed:
|
||||
<literal>kubectl delete clusterrolebinding kubernetes-dashboard</literal>
|
||||
If dashboard cluster-admin rights are desired, set
|
||||
<varname>services.kubernetes.addons.dashboard.rbac.clusterAdmin</varname>
|
||||
to true. On existing clusters, in order for the revocation of privileges
|
||||
to take effect, the current ClusterRoleBinding for kubernetes-dashboard
|
||||
must be manually removed: <literal>kubectl delete clusterrolebinding
|
||||
kubernetes-dashboard</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The <varname>programs.screen</varname> module provides allows to configure
|
||||
<literal>/etc/screenrc</literal>, however the module behaved fairly counterintuitive as
|
||||
the config exists, but the package wasn't available. Since 18.09 <literal>pkgs.screen</literal>
|
||||
will be added to <literal>environment.systemPackages</literal>.
|
||||
<literal>/etc/screenrc</literal>, however the module behaved fairly
|
||||
counterintuitive as the config exists, but the package wasn't available.
|
||||
Since 18.09 <literal>pkgs.screen</literal> will be added to
|
||||
<literal>environment.systemPackages</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The module <option>services.networking.hostapd</option> now uses WPA2 by default.
|
||||
The module <option>services.networking.hostapd</option> now uses WPA2 by
|
||||
default.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<varname>s6Dns</varname>, <varname>s6Networking</varname>,
|
||||
<varname>s6LinuxUtils</varname> and <varname>s6PortableUtils</varname>
|
||||
renamed to
|
||||
<varname>s6-dns</varname>, <varname>s6-networking</varname>,
|
||||
<varname>s6-linux-utils</varname> and <varname>s6-portable-utils</varname> respectively.
|
||||
<varname>s6Dns</varname>, <varname>s6Networking</varname>,
|
||||
<varname>s6LinuxUtils</varname> and <varname>s6PortableUtils</varname>
|
||||
renamed to <varname>s6-dns</varname>, <varname>s6-networking</varname>,
|
||||
<varname>s6-linux-utils</varname> and <varname>s6-portable-utils</varname>
|
||||
respectively.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The module option <option>nix.useSandbox</option> is now defaulted to <literal>true</literal>.
|
||||
The module option <option>nix.useSandbox</option> is now defaulted to
|
||||
<literal>true</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The config activation script of <literal>nixos-rebuild</literal> now
|
||||
<link xlink:href="https://www.freedesktop.org/software/systemd/man/systemctl.html#Manager%20Lifecycle%20Commands">reloads</link>
|
||||
all user units for each authenticated user.
|
||||
The config activation script of <literal>nixos-rebuild</literal> now
|
||||
<link xlink:href="https://www.freedesktop.org/software/systemd/man/systemctl.html#Manager%20Lifecycle%20Commands">reloads</link>
|
||||
all user units for each authenticated user.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The default display manager is now LightDM.
|
||||
To use SLiM set <literal>services.xserver.displayManager.slim.enable</literal>
|
||||
to <literal>true</literal>.
|
||||
The default display manager is now LightDM. To use SLiM set
|
||||
<literal>services.xserver.displayManager.slim.enable</literal> to
|
||||
<literal>true</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
NixOS option descriptions are now automatically broken up into individual
|
||||
paragraphs if the text contains two consecutive newlines, so it's no
|
||||
longer necessary to use <code></para><para></code> to start
|
||||
a new paragraph.
|
||||
NixOS option descriptions are now automatically broken up into individual
|
||||
paragraphs if the text contains two consecutive newlines, so it's no
|
||||
longer necessary to use <code></para><para></code> to start a
|
||||
new paragraph.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Top-level <literal>buildPlatform</literal>, <literal>hostPlatform</literal>, and <literal>targetPlatform</literal> in Nixpkgs are deprecated.
|
||||
Please use their equivalents in <literal>stdenv</literal> instead:
|
||||
<literal>stdenv.buildPlatform</literal>, <literal>stdenv.hostPlatform</literal>, and <literal>stdenv.targetPlatform</literal>.
|
||||
Top-level <literal>buildPlatform</literal>,
|
||||
<literal>hostPlatform</literal>, and <literal>targetPlatform</literal> in
|
||||
Nixpkgs are deprecated. Please use their equivalents in
|
||||
<literal>stdenv</literal> instead:
|
||||
<literal>stdenv.buildPlatform</literal>,
|
||||
<literal>stdenv.hostPlatform</literal>, and
|
||||
<literal>stdenv.targetPlatform</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
|
160
nixos/doc/manual/release-notes/rl-1903.xml
Normal file
160
nixos/doc/manual/release-notes/rl-1903.xml
Normal file
@ -0,0 +1,160 @@
|
||||
<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-release-19.03">
|
||||
<title>Release 19.03 (“Koi”, 2019/03/??)</title>
|
||||
|
||||
<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-release-19.03-highlights">
|
||||
<title>Highlights</title>
|
||||
|
||||
<para>
|
||||
In addition to numerous new and upgraded packages, this release has the
|
||||
following highlights:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para />
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<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-release-19.03-new-services">
|
||||
<title>New Services</title>
|
||||
|
||||
<para>
|
||||
The following new services were added since the last release:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para />
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<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-release-19.03-incompatibilities">
|
||||
<title>Backward Incompatibilities</title>
|
||||
|
||||
<para>
|
||||
When upgrading from a previous release, please be aware of the following
|
||||
incompatible changes:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The minimum version of Nix required to evaluate Nixpkgs is now 2.0.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
For users of NixOS 18.03 and 19.03, NixOS defaults to Nix 2.0, but
|
||||
supports using Nix 1.11 by setting <literal>nix.package =
|
||||
pkgs.nix1;</literal>. If this option is set to a Nix 1.11 package, you
|
||||
will need to either unset the option or upgrade it to Nix 2.0.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
For users of NixOS 17.09, you will first need to upgrade Nix by setting
|
||||
<literal>nix.package = pkgs.nixStable2;</literal> and run
|
||||
<command>nixos-rebuild switch</command> as the <literal>root</literal>
|
||||
user.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
For users of a daemon-less Nix installation on Linux or macOS, you can
|
||||
upgrade Nix by running <command>curl https://nixos.org/nix/install |
|
||||
sh</command>, or prior to doing a channel update, running
|
||||
<command>nix-env -iA nix</command>.
|
||||
</para>
|
||||
<para>
|
||||
If you have already run a channel update and Nix is no longer able to
|
||||
evaluate Nixpkgs, the error message printed should provide adequate
|
||||
directions for upgrading Nix.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
For users of the Nix daemon on macOS, you can upgrade Nix by running
|
||||
<command>sudo -i sh -c 'nix-channel --update && nix-env -iA
|
||||
nixpkgs.nix'; sudo launchctl stop org.nixos.nix-daemon; sudo launchctl
|
||||
start org.nixos.nix-daemon</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Package <varname>rabbitmq_server</varname> is renamed to
|
||||
<varname>rabbitmq-server</varname>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>light</literal> module no longer uses setuid binaries, but
|
||||
udev rules. As a consequence users of that module have to belong to the
|
||||
<literal>video</literal> group in order to use the executable (i.e.
|
||||
<literal>users.users.yourusername.extraGroups = ["video"];</literal>).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Buildbot now supports Python 3 and its packages have been moved to
|
||||
<literal>pythonPackages</literal>. The options
|
||||
<option>services.buildbot-master.package</option> and
|
||||
<option>services.buildbot-worker.package</option> can be used to select
|
||||
the Python 2 or 3 version of the package.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Options
|
||||
<literal>services.znc.confOptions.networks.<replaceable>name</replaceable>.userName</literal> and
|
||||
<literal>services.znc.confOptions.networks.<replaceable>name</replaceable>.modulePackages</literal>
|
||||
were removed. They were never used for anything and can therefore safely be removed.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Package <literal>wasm</literal> has been renamed <literal>proglodyte-wasm</literal>. The package
|
||||
<literal>wasm</literal> will be pointed to <literal>ocamlPackages.wasm</literal> in 19.09, so
|
||||
make sure to update your configuration if you want to keep <literal>proglodyte-wasm</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<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-release-19.03-notable-changes">
|
||||
<title>Other Notable Changes</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The <option>services.matomo</option> module gained the option
|
||||
<option>services.matomo.package</option> which determines the used
|
||||
Matomo version.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
@ -28,7 +28,7 @@ rec {
|
||||
modules = configurations ++
|
||||
[ ../modules/virtualisation/qemu-vm.nix
|
||||
../modules/testing/test-instrumentation.nix # !!! should only get added for automated test runs
|
||||
{ key = "no-manual"; services.nixosManual.enable = false; }
|
||||
{ key = "no-manual"; documentation.nixos.enable = false; }
|
||||
{ key = "qemu"; system.build.qemu = qemu; }
|
||||
] ++ optional minimal ../modules/testing/minimal-kernel.nix;
|
||||
extraArgs = { inherit nodes; };
|
||||
|
@ -28,7 +28,7 @@
|
||||
|
||||
let extraArgs_ = extraArgs; pkgs_ = pkgs;
|
||||
extraModules = let e = builtins.getEnv "NIXOS_EXTRA_MODULE_PATH";
|
||||
in if e == "" then [] else [(import (builtins.toPath e))];
|
||||
in if e == "" then [] else [(import e)];
|
||||
in
|
||||
|
||||
let
|
||||
|
@ -155,8 +155,10 @@ sub start {
|
||||
$ENV{USE_TMPDIR} = 1;
|
||||
$ENV{QEMU_OPTS} =
|
||||
($self->{allowReboot} ? "" : "-no-reboot ") .
|
||||
"-monitor unix:./monitor -chardev socket,id=shell,path=./shell " .
|
||||
"-device virtio-serial -device virtconsole,chardev=shell " .
|
||||
"-monitor unix:./monitor " .
|
||||
"-chardev socket,id=shell,path=./shell -device virtio-serial -device virtconsole,chardev=shell " .
|
||||
# socket backdoor, see "Debugging NixOS tests" section in NixOS manual
|
||||
"-chardev socket,id=backdoor,path=./backdoor,server,nowait -device virtio-serial -device virtconsole,chardev=backdoor " .
|
||||
"-device virtio-rng-pci " .
|
||||
($showGraphics ? "-serial stdio" : "-nographic") . " " . ($ENV{QEMU_OPTS} || "");
|
||||
chdir $self->{stateDir} or die;
|
||||
|
@ -4,20 +4,29 @@ with lib;
|
||||
|
||||
let
|
||||
cfg = config.networking.iproute2;
|
||||
confDir = "/run/iproute2";
|
||||
in
|
||||
{
|
||||
options.networking.iproute2.enable = mkEnableOption "copy IP route configuration files";
|
||||
|
||||
config = mkMerge [
|
||||
({ nixpkgs.config.iproute2.confDir = confDir; })
|
||||
|
||||
(mkIf cfg.enable {
|
||||
system.activationScripts.iproute2 = ''
|
||||
cp -R ${pkgs.iproute}/etc/iproute2 ${confDir}
|
||||
chmod -R 664 ${confDir}
|
||||
chmod +x ${confDir}
|
||||
options.networking.iproute2 = {
|
||||
enable = mkEnableOption "copy IP route configuration files";
|
||||
rttablesExtraConfig = mkOption {
|
||||
type = types.lines;
|
||||
default = "";
|
||||
description = ''
|
||||
Verbatim lines to add to /etc/iproute2/rt_tables
|
||||
'';
|
||||
})
|
||||
];
|
||||
};
|
||||
};
|
||||
|
||||
config = mkIf cfg.enable {
|
||||
environment.etc."iproute2/bpf_pinning" = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/bpf_pinning"; };
|
||||
environment.etc."iproute2/ematch_map" = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/ematch_map"; };
|
||||
environment.etc."iproute2/group" = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/group"; };
|
||||
environment.etc."iproute2/nl_protos" = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/nl_protos"; };
|
||||
environment.etc."iproute2/rt_dsfield" = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/rt_dsfield"; };
|
||||
environment.etc."iproute2/rt_protos" = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/rt_protos"; };
|
||||
environment.etc."iproute2/rt_realms" = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/rt_realms"; };
|
||||
environment.etc."iproute2/rt_scopes" = { mode = "0644"; text = fileContents "${pkgs.iproute}/etc/iproute2/rt_scopes"; };
|
||||
environment.etc."iproute2/rt_tables" = { mode = "0644"; text = (fileContents "${pkgs.iproute}/etc/iproute2/rt_tables")
|
||||
+ (optionalString (cfg.rttablesExtraConfig != "") "\n\n${cfg.rttablesExtraConfig}"); };
|
||||
};
|
||||
}
|
||||
|
@ -79,7 +79,7 @@ in {
|
||||
|
||||
options = {
|
||||
krb5 = {
|
||||
enable = mkEnableOption "Whether to enable Kerberos V.";
|
||||
enable = mkEnableOption "building krb5.conf, configuration file for Kerberos V";
|
||||
|
||||
kerberos = mkOption {
|
||||
type = types.package;
|
||||
|
@ -154,6 +154,18 @@ in {
|
||||
'';
|
||||
};
|
||||
|
||||
extraModules = mkOption {
|
||||
type = types.listOf types.package;
|
||||
default = [];
|
||||
example = literalExample "[ pkgs.pulseaudio-modules-bt ]";
|
||||
description = ''
|
||||
Extra pulseaudio modules to use. This is intended for out-of-tree
|
||||
pulseaudio modules like extra bluetooth codecs.
|
||||
|
||||
Extra modules take precedence over built-in pulseaudio modules.
|
||||
'';
|
||||
};
|
||||
|
||||
daemon = {
|
||||
logLevel = mkOption {
|
||||
type = types.str;
|
||||
@ -236,6 +248,18 @@ in {
|
||||
systemd.packages = [ overriddenPackage ];
|
||||
})
|
||||
|
||||
(mkIf (cfg.extraModules != []) {
|
||||
hardware.pulseaudio.daemon.config.dl-search-path = let
|
||||
overriddenModules = builtins.map
|
||||
(drv: drv.override { pulseaudio = overriddenPackage; })
|
||||
cfg.extraModules;
|
||||
modulePaths = builtins.map
|
||||
(drv: "${drv}/lib/pulse-${overriddenPackage.version}/modules")
|
||||
# User-provided extra modules take precedence
|
||||
(overriddenModules ++ [ overriddenPackage ]);
|
||||
in lib.concatStringsSep ":" modulePaths;
|
||||
})
|
||||
|
||||
(mkIf hasZeroconf {
|
||||
services.avahi.enable = true;
|
||||
})
|
||||
|
@ -108,14 +108,14 @@ in
|
||||
};
|
||||
|
||||
environment.shellAliases = mkOption {
|
||||
default = {};
|
||||
example = { ll = "ls -l"; };
|
||||
example = { l = null; ll = "ls -l"; };
|
||||
description = ''
|
||||
An attribute set that maps aliases (the top level attribute names in
|
||||
this option) to command strings or directly to build outputs. The
|
||||
aliases are added to all users' shells.
|
||||
Aliases mapped to <code>null</code> are ignored.
|
||||
'';
|
||||
type = types.attrs; # types.attrsOf types.stringOrPath;
|
||||
type = with types; attrsOf (nullOr (either str path));
|
||||
};
|
||||
|
||||
environment.binsh = mkOption {
|
||||
@ -157,21 +157,36 @@ in
|
||||
# terminal instead of logging out of X11).
|
||||
environment.variables = config.environment.sessionVariables;
|
||||
|
||||
environment.shellAliases = mapAttrs (name: mkDefault) {
|
||||
ls = "ls --color=tty";
|
||||
ll = "ls -l";
|
||||
l = "ls -alh";
|
||||
};
|
||||
|
||||
environment.etc."shells".text =
|
||||
''
|
||||
${concatStringsSep "\n" (map utils.toShellPath cfg.shells)}
|
||||
/bin/sh
|
||||
'';
|
||||
|
||||
# For resetting environment with `. /etc/set-environment` when needed
|
||||
# and discoverability (see motivation of #30418).
|
||||
environment.etc."set-environment".source = config.system.build.setEnvironment;
|
||||
|
||||
system.build.setEnvironment = pkgs.writeText "set-environment"
|
||||
''
|
||||
${exportedEnvVars}
|
||||
''
|
||||
# DO NOT EDIT -- this file has been generated automatically.
|
||||
|
||||
${cfg.extraInit}
|
||||
# Prevent this file from being sourced by child shells.
|
||||
export __NIXOS_SET_ENVIRONMENT_DONE=1
|
||||
|
||||
# ~/bin if it exists overrides other bin directories.
|
||||
export PATH="$HOME/bin:$PATH"
|
||||
'';
|
||||
${exportedEnvVars}
|
||||
|
||||
${cfg.extraInit}
|
||||
|
||||
# ~/bin if it exists overrides other bin directories.
|
||||
export PATH="$HOME/bin:$PATH"
|
||||
'';
|
||||
|
||||
system.activationScripts.binsh = stringAfter [ "stdio" ]
|
||||
''
|
||||
|
@ -13,7 +13,7 @@ let
|
||||
pkgs.attr
|
||||
pkgs.bashInteractive # bash with ncurses support
|
||||
pkgs.bzip2
|
||||
pkgs.coreutils
|
||||
pkgs.coreutils-full
|
||||
pkgs.cpio
|
||||
pkgs.curl
|
||||
pkgs.diffutils
|
||||
@ -140,7 +140,7 @@ in
|
||||
if [ -x $out/bin/glib-compile-schemas -a -w $out/share/glib-2.0/schemas ]; then
|
||||
$out/bin/glib-compile-schemas $out/share/glib-2.0/schemas
|
||||
fi
|
||||
|
||||
|
||||
${config.environment.extraSetup}
|
||||
'';
|
||||
};
|
||||
|
@ -7,7 +7,7 @@ with lib;
|
||||
type = types.bool;
|
||||
default = true;
|
||||
description = ''
|
||||
Whether to install files to support the
|
||||
Whether to install files to support the
|
||||
<link xlink:href="https://specifications.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html">XDG Shared MIME-info specification</link> and the
|
||||
<link xlink:href="https://specifications.freedesktop.org/mime-apps-spec/mime-apps-spec-latest.html">XDG MIME Applications specification</link>.
|
||||
'';
|
||||
@ -17,18 +17,18 @@ with lib;
|
||||
config = mkIf config.xdg.mime.enable {
|
||||
environment.pathsToLink = [ "/share/mime" ];
|
||||
|
||||
environment.systemPackages = [
|
||||
# this package also installs some useful data, as well as its utilities
|
||||
pkgs.shared-mime-info
|
||||
environment.systemPackages = [
|
||||
# this package also installs some useful data, as well as its utilities
|
||||
pkgs.shared-mime-info
|
||||
];
|
||||
|
||||
environment.extraSetup = ''
|
||||
if [ -w $out/share/mime ]; then
|
||||
XDG_DATA_DIRS=$out/share ${pkgs.shared-mime-info}/bin/update-mime-database -V $out/share/mime > /dev/null
|
||||
if [ -w $out/share/mime ] && [ -d $out/share/mime/packages ]; then
|
||||
XDG_DATA_DIRS=$out/share ${pkgs.buildPackages.shared-mime-info}/bin/update-mime-database -V $out/share/mime > /dev/null
|
||||
fi
|
||||
|
||||
if [ -w $out/share/applications ]; then
|
||||
${pkgs.desktop-file-utils}/bin/update-desktop-database $out/share/applications
|
||||
${pkgs.buildPackages.desktop-file-utils}/bin/update-desktop-database $out/share/applications
|
||||
fi
|
||||
'';
|
||||
};
|
||||
|
@ -129,17 +129,17 @@ in
|
||||
message = "Option driSupport32Bit only makes sense on a 64-bit system.";
|
||||
};
|
||||
|
||||
system.activationScripts.setup-opengl =
|
||||
''
|
||||
ln -sfn ${package} /run/opengl-driver
|
||||
${if pkgs.stdenv.isi686 then ''
|
||||
ln -sfn opengl-driver /run/opengl-driver-32
|
||||
'' else if cfg.driSupport32Bit then ''
|
||||
ln -sfn ${package32} /run/opengl-driver-32
|
||||
'' else ''
|
||||
rm -f /run/opengl-driver-32
|
||||
''}
|
||||
'';
|
||||
systemd.tmpfiles.rules = [
|
||||
"L+ /run/opengl-driver - - - - ${package}"
|
||||
(
|
||||
if pkgs.stdenv.isi686 then
|
||||
"L+ /run/opengl-driver-32 - - - - opengl-driver"
|
||||
else if cfg.driSupport32Bit then
|
||||
"L+ /run/opengl-driver-32 - - - - ${package32}"
|
||||
else
|
||||
"r /run/opengl-driver-32"
|
||||
)
|
||||
];
|
||||
|
||||
environment.sessionVariables.LD_LIBRARY_PATH =
|
||||
[ "/run/opengl-driver/lib" ] ++ optional cfg.driSupport32Bit "/run/opengl-driver-32/lib";
|
||||
|
25
nixos/modules/hardware/steam-hardware.nix
Normal file
25
nixos/modules/hardware/steam-hardware.nix
Normal file
@ -0,0 +1,25 @@
|
||||
{ config, lib, pkgs, ... }:
|
||||
|
||||
with lib;
|
||||
|
||||
let
|
||||
|
||||
cfg = config.hardware.steam-hardware;
|
||||
|
||||
in
|
||||
|
||||
{
|
||||
options.hardware.steam-hardware = {
|
||||
enable = mkOption {
|
||||
type = types.bool;
|
||||
default = false;
|
||||
description = "Enable udev rules for Steam hardware such as the Steam Controller, other supported controllers and the HTC Vive";
|
||||
};
|
||||
};
|
||||
|
||||
config = mkIf cfg.enable {
|
||||
services.udev.packages = [
|
||||
pkgs.steamPackages.steam
|
||||
];
|
||||
};
|
||||
}
|
@ -1,6 +1,6 @@
|
||||
# This module provides the proprietary NVIDIA X11 / OpenGL drivers.
|
||||
|
||||
{ config, lib, pkgs, pkgs_i686, ... }:
|
||||
{ stdenv, config, lib, pkgs, pkgs_i686, ... }:
|
||||
|
||||
with lib;
|
||||
|
||||
@ -23,35 +23,149 @@ let
|
||||
else null;
|
||||
|
||||
nvidia_x11 = nvidiaForKernel config.boot.kernelPackages;
|
||||
nvidia_libs32 = (nvidiaForKernel pkgs_i686.linuxPackages).override { libsOnly = true; kernel = null; };
|
||||
nvidia_libs32 =
|
||||
if versionOlder nvidia_x11.version "391" then
|
||||
((nvidiaForKernel pkgs_i686.linuxPackages).override { libsOnly = true; kernel = null; }).out
|
||||
else
|
||||
(nvidiaForKernel config.boot.kernelPackages).lib32;
|
||||
|
||||
enabled = nvidia_x11 != null;
|
||||
|
||||
cfg = config.hardware.nvidia;
|
||||
optimusCfg = cfg.optimus_prime;
|
||||
in
|
||||
|
||||
{
|
||||
options = {
|
||||
hardware.nvidia.modesetting.enable = lib.mkOption {
|
||||
type = lib.types.bool;
|
||||
default = false;
|
||||
description = ''
|
||||
Enable kernel modesetting when using the NVIDIA proprietary driver.
|
||||
|
||||
Enabling this fixes screen tearing when using Optimus via PRIME (see
|
||||
<option>hardware.nvidia.optimus_prime.enable</option>. This is not enabled
|
||||
by default because it is not officially supported by NVIDIA and would not
|
||||
work with SLI.
|
||||
'';
|
||||
};
|
||||
|
||||
hardware.nvidia.optimus_prime.enable = lib.mkOption {
|
||||
type = lib.types.bool;
|
||||
default = false;
|
||||
description = ''
|
||||
Enable NVIDIA Optimus support using the NVIDIA proprietary driver via PRIME.
|
||||
If enabled, the NVIDIA GPU will be always on and used for all rendering,
|
||||
while enabling output to displays attached only to the integrated Intel GPU
|
||||
without a multiplexer.
|
||||
|
||||
Note that this option only has any effect if the "nvidia" driver is specified
|
||||
in <option>services.xserver.videoDrivers</option>, and it should preferably
|
||||
be the only driver there.
|
||||
|
||||
If this is enabled, then the bus IDs of the NVIDIA and Intel GPUs have to be
|
||||
specified (<option>hardware.nvidia.optimus_prime.nvidiaBusId</option> and
|
||||
<option>hardware.nvidia.optimus_prime.intelBusId</option>).
|
||||
|
||||
If you enable this, you may want to also enable kernel modesetting for the
|
||||
NVIDIA driver (<option>hardware.nvidia.modesetting.enable</option>) in order
|
||||
to prevent tearing.
|
||||
|
||||
Note that this configuration will only be successful when a display manager
|
||||
for which the <option>services.xserver.displayManager.setupCommands</option>
|
||||
option is supported is used; notably, SLiM is not supported.
|
||||
'';
|
||||
};
|
||||
|
||||
hardware.nvidia.optimus_prime.nvidiaBusId = lib.mkOption {
|
||||
type = lib.types.string;
|
||||
default = "";
|
||||
example = "PCI:1:0:0";
|
||||
description = ''
|
||||
Bus ID of the NVIDIA GPU. You can find it using lspci; for example if lspci
|
||||
shows the NVIDIA GPU at "01:00.0", set this option to "PCI:1:0:0".
|
||||
'';
|
||||
};
|
||||
|
||||
hardware.nvidia.optimus_prime.intelBusId = lib.mkOption {
|
||||
type = lib.types.string;
|
||||
default = "";
|
||||
example = "PCI:0:2:0";
|
||||
description = ''
|
||||
Bus ID of the Intel GPU. You can find it using lspci; for example if lspci
|
||||
shows the Intel GPU at "00:02.0", set this option to "PCI:0:2:0".
|
||||
'';
|
||||
};
|
||||
};
|
||||
|
||||
config = mkIf enabled {
|
||||
assertions = [
|
||||
{
|
||||
assertion = config.services.xserver.displayManager.gdm.wayland;
|
||||
message = "NVidia drivers don't support wayland";
|
||||
message = "NVIDIA drivers don't support wayland";
|
||||
}
|
||||
{
|
||||
assertion = !optimusCfg.enable ||
|
||||
(optimusCfg.nvidiaBusId != "" && optimusCfg.intelBusId != "");
|
||||
message = ''
|
||||
When NVIDIA Optimus via PRIME is enabled, the GPU bus IDs must configured.
|
||||
'';
|
||||
}
|
||||
];
|
||||
|
||||
services.xserver.drivers = singleton
|
||||
{ name = "nvidia"; modules = [ nvidia_x11.bin ]; libPath = [ nvidia_x11 ]; };
|
||||
# If Optimus/PRIME is enabled, we:
|
||||
# - Specify the configured NVIDIA GPU bus ID in the Device section for the
|
||||
# "nvidia" driver.
|
||||
# - Add the AllowEmptyInitialConfiguration option to the Screen section for the
|
||||
# "nvidia" driver, in order to allow the X server to start without any outputs.
|
||||
# - Add a separate Device section for the Intel GPU, using the "modesetting"
|
||||
# driver and with the configured BusID.
|
||||
# - Reference that Device section from the ServerLayout section as an inactive
|
||||
# device.
|
||||
# - Configure the display manager to run specific `xrandr` commands which will
|
||||
# configure/enable displays connected to the Intel GPU.
|
||||
|
||||
services.xserver.screenSection =
|
||||
services.xserver.drivers = singleton {
|
||||
name = "nvidia";
|
||||
modules = [ nvidia_x11.bin ];
|
||||
libPath = [ nvidia_x11 ];
|
||||
deviceSection = optionalString optimusCfg.enable
|
||||
''
|
||||
BusID "${optimusCfg.nvidiaBusId}"
|
||||
'';
|
||||
screenSection =
|
||||
''
|
||||
Option "RandRRotation" "on"
|
||||
${optionalString optimusCfg.enable "Option \"AllowEmptyInitialConfiguration\""}
|
||||
'';
|
||||
};
|
||||
|
||||
services.xserver.extraConfig = optionalString optimusCfg.enable
|
||||
''
|
||||
Option "RandRRotation" "on"
|
||||
Section "Device"
|
||||
Identifier "nvidia-optimus-intel"
|
||||
Driver "modesetting"
|
||||
BusID "${optimusCfg.intelBusId}"
|
||||
Option "AccelMethod" "none"
|
||||
EndSection
|
||||
'';
|
||||
services.xserver.serverLayoutSection = optionalString optimusCfg.enable
|
||||
''
|
||||
Inactive "nvidia-optimus-intel"
|
||||
'';
|
||||
|
||||
services.xserver.displayManager.setupCommands = optionalString optimusCfg.enable ''
|
||||
# Added by nvidia configuration module for Optimus/PRIME.
|
||||
${pkgs.xorg.xrandr}/bin/xrandr --setprovideroutputsource modesetting NVIDIA-0
|
||||
${pkgs.xorg.xrandr}/bin/xrandr --auto
|
||||
'';
|
||||
|
||||
environment.etc."nvidia/nvidia-application-profiles-rc" = mkIf nvidia_x11.useProfiles {
|
||||
source = "${nvidia_x11.bin}/share/nvidia/nvidia-application-profiles-rc";
|
||||
};
|
||||
|
||||
hardware.opengl.package = nvidia_x11.out;
|
||||
hardware.opengl.package32 = nvidia_libs32.out;
|
||||
hardware.opengl.package32 = nvidia_libs32;
|
||||
|
||||
environment.systemPackages = [ nvidia_x11.bin nvidia_x11.settings ]
|
||||
++ lib.filter (p: p != null) [ nvidia_x11.persistenced ];
|
||||
@ -62,6 +176,8 @@ in
|
||||
boot.kernelModules = [ "nvidia-uvm" ] ++
|
||||
lib.optionals config.services.xserver.enable [ "nvidia" "nvidia_modeset" "nvidia_drm" ];
|
||||
|
||||
# If requested enable modesetting via kernel parameter.
|
||||
boot.kernelParams = optional cfg.modesetting.enable "nvidia-drm.modeset=1";
|
||||
|
||||
# Create /dev/nvidia-uvm when the nvidia-uvm module is loaded.
|
||||
services.udev.extraRules =
|
||||
|
@ -3,32 +3,50 @@
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="module-services-input-methods">
|
||||
<title>Input Methods</title>
|
||||
<para>
|
||||
Input methods are an operating system component that allows any data, such as
|
||||
keyboard strokes or mouse movements, to be received as input. In this way
|
||||
users can enter characters and symbols not found on their input devices.
|
||||
Using an input method is obligatory for any language that has more graphemes
|
||||
than there are keys on the keyboard.
|
||||
</para>
|
||||
<para>
|
||||
The following input methods are available in NixOS:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
IBus: The intelligent input bus.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Fcitx: A customizable lightweight input method.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Nabi: A Korean input method based on XIM.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Uim: The universal input method, is a library with a XIM bridge.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<section xml:id="module-services-input-methods-ibus">
|
||||
<title>IBus</title>
|
||||
|
||||
<title>Input Methods</title>
|
||||
<para>
|
||||
IBus is an Intelligent Input Bus. It provides full featured and user
|
||||
friendly input method user interface.
|
||||
</para>
|
||||
|
||||
<para>Input methods are an operating system component that allows any data, such
|
||||
as keyboard strokes or mouse movements, to be received as input. In this way
|
||||
users can enter characters and symbols not found on their input devices. Using
|
||||
an input method is obligatory for any language that has more graphemes than
|
||||
there are keys on the keyboard.</para>
|
||||
|
||||
<para>The following input methods are available in NixOS:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>IBus: The intelligent input bus.</para></listitem>
|
||||
<listitem><para>Fcitx: A customizable lightweight input
|
||||
method.</para></listitem>
|
||||
<listitem><para>Nabi: A Korean input method based on XIM.</para></listitem>
|
||||
<listitem><para>Uim: The universal input method, is a library with a XIM
|
||||
bridge.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<section xml:id="module-services-input-methods-ibus"><title>IBus</title>
|
||||
|
||||
<para>IBus is an Intelligent Input Bus. It provides full featured and user
|
||||
friendly input method user interface.</para>
|
||||
|
||||
<para>The following snippet can be used to configure IBus:</para>
|
||||
<para>
|
||||
The following snippet can be used to configure IBus:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
i18n.inputMethod = {
|
||||
@ -37,57 +55,89 @@ i18n.inputMethod = {
|
||||
};
|
||||
</programlisting>
|
||||
|
||||
<para><literal>i18n.inputMethod.ibus.engines</literal> is optional and can be
|
||||
used to add extra IBus engines.</para>
|
||||
<para>
|
||||
<literal>i18n.inputMethod.ibus.engines</literal> is optional and can be used
|
||||
to add extra IBus engines.
|
||||
</para>
|
||||
|
||||
<para>Available extra IBus engines are:</para>
|
||||
<para>
|
||||
Available extra IBus engines are:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Anthy (<literal>ibus-engines.anthy</literal>): Anthy is a
|
||||
system for Japanese input method. It converts Hiragana text to Kana Kanji
|
||||
mixed text.</para></listitem>
|
||||
<listitem><para>Hangul (<literal>ibus-engines.hangul</literal>): Korean input
|
||||
method.</para></listitem>
|
||||
<listitem><para>m17n (<literal>ibus-engines.m17n</literal>): m17n is an input
|
||||
method that uses input methods and corresponding icons in the m17n
|
||||
database.</para></listitem>
|
||||
<listitem><para>mozc (<literal>ibus-engines.mozc</literal>): A Japanese input
|
||||
method from Google.</para></listitem>
|
||||
<listitem><para>Table (<literal>ibus-engines.table</literal>): An input method
|
||||
that load tables of input methods.</para></listitem>
|
||||
<listitem><para>table-others (<literal>ibus-engines.table-others</literal>):
|
||||
Various table-based input methods. To use this, and any other table-based
|
||||
input methods, it must appear in the list of engines along with
|
||||
<literal>table</literal>. For example:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Anthy (<literal>ibus-engines.anthy</literal>): Anthy is a system for
|
||||
Japanese input method. It converts Hiragana text to Kana Kanji mixed text.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Hangul (<literal>ibus-engines.hangul</literal>): Korean input method.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
m17n (<literal>ibus-engines.m17n</literal>): m17n is an input method that
|
||||
uses input methods and corresponding icons in the m17n database.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
mozc (<literal>ibus-engines.mozc</literal>): A Japanese input method from
|
||||
Google.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Table (<literal>ibus-engines.table</literal>): An input method that load
|
||||
tables of input methods.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
table-others (<literal>ibus-engines.table-others</literal>): Various
|
||||
table-based input methods. To use this, and any other table-based input
|
||||
methods, it must appear in the list of engines along with
|
||||
<literal>table</literal>. For example:
|
||||
<programlisting>
|
||||
ibus.engines = with pkgs.ibus-engines; [ table table-others ];
|
||||
</programlisting>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>To use any input method, the package must be added in the configuration,
|
||||
as shown above, and also (after running <literal>nixos-rebuild</literal>) the
|
||||
input method must be added from IBus' preference dialog.</para>
|
||||
<para>
|
||||
To use any input method, the package must be added in the configuration, as
|
||||
shown above, and also (after running <literal>nixos-rebuild</literal>) the
|
||||
input method must be added from IBus' preference dialog.
|
||||
</para>
|
||||
|
||||
<simplesect xml:id="module-services-input-methods-troubleshooting">
|
||||
<title>Troubleshooting</title>
|
||||
<para>If IBus works in some applications but not others, a likely cause of
|
||||
this is that IBus is depending on a different version of
|
||||
<literal>glib</literal> to what the applications are depending on. This can
|
||||
be checked by running <literal>nix-store -q --requisites <path> | grep
|
||||
glib</literal>, where <literal><path></literal> is the path of either
|
||||
IBus or an application in the Nix store. The <literal>glib</literal>
|
||||
packages must match exactly. If they do not, uninstalling and reinstalling
|
||||
the application is a likely fix.</para>
|
||||
</simplesect>
|
||||
</section>
|
||||
<simplesect xml:id="module-services-input-methods-troubleshooting">
|
||||
<title>Troubleshooting</title>
|
||||
<para>
|
||||
If IBus works in some applications but not others, a likely cause of this
|
||||
is that IBus is depending on a different version of <literal>glib</literal>
|
||||
to what the applications are depending on. This can be checked by running
|
||||
<literal>nix-store -q --requisites <path> | grep glib</literal>,
|
||||
where <literal><path></literal> is the path of either IBus or an
|
||||
application in the Nix store. The <literal>glib</literal> packages must
|
||||
match exactly. If they do not, uninstalling and reinstalling the
|
||||
application is a likely fix.
|
||||
</para>
|
||||
</simplesect>
|
||||
</section>
|
||||
<section xml:id="module-services-input-methods-fcitx">
|
||||
<title>Fcitx</title>
|
||||
|
||||
<section xml:id="module-services-input-methods-fcitx"><title>Fcitx</title>
|
||||
<para>
|
||||
Fcitx is an input method framework with extension support. It has three
|
||||
built-in Input Method Engine, Pinyin, QuWei and Table-based input methods.
|
||||
</para>
|
||||
|
||||
<para>Fcitx is an input method framework with extension support. It has three
|
||||
built-in Input Method Engine, Pinyin, QuWei and Table-based input
|
||||
methods.</para>
|
||||
<para>The following snippet can be used to configure Fcitx:</para>
|
||||
<para>
|
||||
The following snippet can be used to configure Fcitx:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
i18n.inputMethod = {
|
||||
@ -96,51 +146,89 @@ i18n.inputMethod = {
|
||||
};
|
||||
</programlisting>
|
||||
|
||||
<para><literal>i18n.inputMethod.fcitx.engines</literal> is optional and can be
|
||||
used to add extra Fcitx engines.</para>
|
||||
<para>
|
||||
<literal>i18n.inputMethod.fcitx.engines</literal> is optional and can be
|
||||
used to add extra Fcitx engines.
|
||||
</para>
|
||||
|
||||
<para>Available extra Fcitx engines are:</para>
|
||||
<para>
|
||||
Available extra Fcitx engines are:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Anthy (<literal>fcitx-engines.anthy</literal>): Anthy is a
|
||||
system for Japanese input method. It converts Hiragana text to Kana Kanji
|
||||
mixed text.</para></listitem>
|
||||
<listitem><para>Chewing (<literal>fcitx-engines.chewing</literal>): Chewing is
|
||||
an intelligent Zhuyin input method. It is one of the most popular input
|
||||
methods among Traditional Chinese Unix users.</para></listitem>
|
||||
<listitem><para>Hangul (<literal>fcitx-engines.hangul</literal>): Korean input
|
||||
method.</para></listitem>
|
||||
<listitem><para>Unikey (<literal>fcitx-engines.unikey</literal>): Vietnamese input
|
||||
method.</para></listitem>
|
||||
<listitem><para>m17n (<literal>fcitx-engines.m17n</literal>): m17n is an input
|
||||
method that uses input methods and corresponding icons in the m17n
|
||||
database.</para></listitem>
|
||||
<listitem><para>mozc (<literal>fcitx-engines.mozc</literal>): A Japanese input
|
||||
method from Google.</para></listitem>
|
||||
<listitem><para>table-others (<literal>fcitx-engines.table-others</literal>):
|
||||
Various table-based input methods.</para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Anthy (<literal>fcitx-engines.anthy</literal>): Anthy is a system for
|
||||
Japanese input method. It converts Hiragana text to Kana Kanji mixed text.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Chewing (<literal>fcitx-engines.chewing</literal>): Chewing is an
|
||||
intelligent Zhuyin input method. It is one of the most popular input
|
||||
methods among Traditional Chinese Unix users.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Hangul (<literal>fcitx-engines.hangul</literal>): Korean input method.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Unikey (<literal>fcitx-engines.unikey</literal>): Vietnamese input method.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
m17n (<literal>fcitx-engines.m17n</literal>): m17n is an input method that
|
||||
uses input methods and corresponding icons in the m17n database.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
mozc (<literal>fcitx-engines.mozc</literal>): A Japanese input method from
|
||||
Google.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
table-others (<literal>fcitx-engines.table-others</literal>): Various
|
||||
table-based input methods.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section xml:id="module-services-input-methods-nabi">
|
||||
<title>Nabi</title>
|
||||
|
||||
<section xml:id="module-services-input-methods-nabi"><title>Nabi</title>
|
||||
<para>
|
||||
Nabi is an easy to use Korean X input method. It allows you to enter
|
||||
phonetic Korean characters (hangul) and pictographic Korean characters
|
||||
(hanja).
|
||||
</para>
|
||||
|
||||
<para>Nabi is an easy to use Korean X input method. It allows you to enter
|
||||
phonetic Korean characters (hangul) and pictographic Korean characters
|
||||
(hanja).</para>
|
||||
<para>The following snippet can be used to configure Nabi:</para>
|
||||
<para>
|
||||
The following snippet can be used to configure Nabi:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
i18n.inputMethod = {
|
||||
<link linkend="opt-i18n.inputMethod.enabled">enabled</link> = "nabi";
|
||||
};
|
||||
</programlisting>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="module-services-input-methods-uim">
|
||||
<title>Uim</title>
|
||||
|
||||
<section xml:id="module-services-input-methods-uim"><title>Uim</title>
|
||||
<para>
|
||||
Uim (short for "universal input method") is a multilingual input method
|
||||
framework. Applications can use it through so-called bridges.
|
||||
</para>
|
||||
|
||||
<para>Uim (short for "universal input method") is a multilingual input method
|
||||
framework. Applications can use it through so-called bridges.</para>
|
||||
<para>The following snippet can be used to configure uim:</para>
|
||||
<para>
|
||||
The following snippet can be used to configure uim:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
i18n.inputMethod = {
|
||||
@ -148,8 +236,9 @@ i18n.inputMethod = {
|
||||
};
|
||||
</programlisting>
|
||||
|
||||
<para>Note: The <xref linkend="opt-i18n.inputMethod.uim.toolbar"/> option can be
|
||||
used to choose uim toolbar.</para>
|
||||
|
||||
</section>
|
||||
<para>
|
||||
Note: The <xref linkend="opt-i18n.inputMethod.uim.toolbar"/> option can be
|
||||
used to choose uim toolbar.
|
||||
</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
@ -0,0 +1,49 @@
|
||||
# This module contains the basic configuration for building a graphical NixOS
|
||||
# installation CD.
|
||||
|
||||
{ config, lib, pkgs, ... }:
|
||||
|
||||
with lib;
|
||||
|
||||
{
|
||||
imports = [ ./installation-cd-base.nix ];
|
||||
|
||||
services.xserver = {
|
||||
enable = true;
|
||||
|
||||
# Don't start the X server by default.
|
||||
autorun = mkForce false;
|
||||
|
||||
# Automatically login as root.
|
||||
displayManager.slim = {
|
||||
enable = true;
|
||||
defaultUser = "root";
|
||||
autoLogin = true;
|
||||
};
|
||||
|
||||
};
|
||||
|
||||
# Provide networkmanager for easy wireless configuration.
|
||||
networking.networkmanager.enable = true;
|
||||
networking.wireless.enable = mkForce false;
|
||||
|
||||
# KDE complains if power management is disabled (to be precise, if
|
||||
# there is no power management backend such as upower).
|
||||
powerManagement.enable = true;
|
||||
|
||||
environment.systemPackages = [
|
||||
# Include gparted for partitioning disks.
|
||||
pkgs.gparted
|
||||
|
||||
# Include some editors.
|
||||
pkgs.vim
|
||||
pkgs.bvi # binary editor
|
||||
pkgs.joe
|
||||
|
||||
# Firefox for reading the manual.
|
||||
pkgs.firefox
|
||||
|
||||
pkgs.glxinfo
|
||||
];
|
||||
|
||||
}
|
@ -6,47 +6,11 @@
|
||||
with lib;
|
||||
|
||||
{
|
||||
imports = [ ./installation-cd-base.nix ];
|
||||
imports = [ ./installation-cd-graphical-base.nix ];
|
||||
|
||||
services.xserver = {
|
||||
enable = true;
|
||||
# GDM doesn't start in virtual machines with ISO
|
||||
displayManager.slim = {
|
||||
enable = true;
|
||||
defaultUser = "root";
|
||||
autoLogin = true;
|
||||
};
|
||||
desktopManager.gnome3 = {
|
||||
enable = true;
|
||||
extraGSettingsOverrides = ''
|
||||
[org.gnome.desktop.background]
|
||||
show-desktop-icons=true
|
||||
services.xserver.desktopManager.gnome3.enable = true;
|
||||
|
||||
[org.gnome.nautilus.desktop]
|
||||
trash-icon-visible=false
|
||||
volumes-visible=false
|
||||
home-icon-visible=false
|
||||
network-icon-visible=false
|
||||
'';
|
||||
|
||||
extraGSettingsOverridePackages = [ pkgs.gnome3.nautilus ];
|
||||
};
|
||||
};
|
||||
|
||||
environment.systemPackages =
|
||||
[ # Include gparted for partitioning disks.
|
||||
pkgs.gparted
|
||||
|
||||
# Include some editors.
|
||||
pkgs.vim
|
||||
pkgs.bvi # binary editor
|
||||
pkgs.joe
|
||||
|
||||
pkgs.glxinfo
|
||||
];
|
||||
|
||||
# Don't start the X server by default.
|
||||
services.xserver.autorun = mkForce false;
|
||||
services.xserver.displayManager.slim.enable = mkForce false;
|
||||
|
||||
# Auto-login as root.
|
||||
services.xserver.displayManager.gdm.autoLogin = {
|
||||
@ -54,25 +18,4 @@ with lib;
|
||||
user = "root";
|
||||
};
|
||||
|
||||
system.activationScripts.installerDesktop = let
|
||||
# Must be executable
|
||||
desktopFile = pkgs.writeScript "nixos-manual.desktop" ''
|
||||
[Desktop Entry]
|
||||
Version=1.0
|
||||
Type=Link
|
||||
Name=NixOS Manual
|
||||
URL=${config.system.build.manual.manual}/share/doc/nixos/index.html
|
||||
Icon=system-help
|
||||
'';
|
||||
|
||||
# use cp and chmod +x, we must be sure the apps are in the nix store though
|
||||
in ''
|
||||
mkdir -p /root/Desktop
|
||||
ln -sfT ${desktopFile} /root/Desktop/nixos-manual.desktop
|
||||
cp ${pkgs.gnome3.gnome-terminal}/share/applications/gnome-terminal.desktop /root/Desktop/gnome-terminal.desktop
|
||||
chmod a+rx /root/Desktop/gnome-terminal.desktop
|
||||
cp ${pkgs.gparted}/share/applications/gparted.desktop /root/Desktop/gparted.desktop
|
||||
chmod a+rx /root/Desktop/gparted.desktop
|
||||
'';
|
||||
|
||||
}
|
||||
|
@ -1,23 +1,14 @@
|
||||
# This module defines a NixOS installation CD that contains X11 and
|
||||
# KDE 5.
|
||||
# Plasma5.
|
||||
|
||||
{ config, lib, pkgs, ... }:
|
||||
|
||||
with lib;
|
||||
|
||||
{
|
||||
imports = [ ./installation-cd-base.nix ];
|
||||
imports = [ ./installation-cd-graphical-base.nix ];
|
||||
|
||||
services.xserver = {
|
||||
enable = true;
|
||||
|
||||
# Automatically login as root.
|
||||
displayManager.slim = {
|
||||
enable = true;
|
||||
defaultUser = "root";
|
||||
autoLogin = true;
|
||||
};
|
||||
|
||||
desktopManager.plasma5 = {
|
||||
enable = true;
|
||||
enableQt4Support = false;
|
||||
@ -27,45 +18,25 @@ with lib;
|
||||
synaptics.enable = true;
|
||||
};
|
||||
|
||||
environment.systemPackages =
|
||||
[ pkgs.glxinfo
|
||||
|
||||
# Include gparted for partitioning disks.
|
||||
pkgs.gparted
|
||||
|
||||
# Firefox for reading the manual.
|
||||
pkgs.firefox
|
||||
|
||||
# Include some editors.
|
||||
pkgs.vim
|
||||
pkgs.bvi # binary editor
|
||||
pkgs.joe
|
||||
];
|
||||
|
||||
# Provide networkmanager for easy wireless configuration.
|
||||
networking.networkmanager.enable = true;
|
||||
networking.wireless.enable = mkForce false;
|
||||
|
||||
# KDE complains if power management is disabled (to be precise, if
|
||||
# there is no power management backend such as upower).
|
||||
powerManagement.enable = true;
|
||||
|
||||
# Don't start the X server by default.
|
||||
services.xserver.autorun = mkForce false;
|
||||
environment.systemPackages = with pkgs; [
|
||||
# Graphical text editor
|
||||
kate
|
||||
];
|
||||
|
||||
system.activationScripts.installerDesktop = let
|
||||
desktopFile = pkgs.writeText "nixos-manual.desktop" ''
|
||||
|
||||
manualDesktopFile = pkgs.writeScript "nixos-manual.desktop" ''
|
||||
[Desktop Entry]
|
||||
Version=1.0
|
||||
Type=Application
|
||||
Name=NixOS Manual
|
||||
Exec=firefox ${config.system.build.manual.manual}/share/doc/nixos/index.html
|
||||
Exec=firefox ${config.system.build.manual.manualHTMLIndex}
|
||||
Icon=text-html
|
||||
'';
|
||||
|
||||
in ''
|
||||
mkdir -p /root/Desktop
|
||||
ln -sfT ${desktopFile} /root/Desktop/nixos-manual.desktop
|
||||
ln -sfT ${manualDesktopFile} /root/Desktop/nixos-manual.desktop
|
||||
ln -sfT ${pkgs.konsole}/share/applications/org.kde.konsole.desktop /root/Desktop/org.kde.konsole.desktop
|
||||
ln -sfT ${pkgs.gparted}/share/applications/gparted.desktop /root/Desktop/gparted.desktop
|
||||
'';
|
||||
|
@ -233,7 +233,7 @@ let
|
||||
"
|
||||
# Make our own efi program, we can't rely on "grub-install" since it seems to
|
||||
# probe for devices, even with --skip-fs-probe.
|
||||
${pkgs.grub2_efi}/bin/grub-mkimage -o $out/EFI/boot/${if targetArch == "x64" then "bootx64" else "bootx32"}.efi -p /EFI/boot -O ${if targetArch == "x64" then "x86_64" else "i386"}-efi \
|
||||
${pkgs.grub2_efi}/bin/grub-mkimage -o $out/EFI/boot/${if targetArch == "x64" then "bootx64" else "bootia32"}.efi -p /EFI/boot -O ${if targetArch == "x64" then "x86_64" else "i386"}-efi \
|
||||
$MODULES
|
||||
cp ${pkgs.grub2_efi}/share/grub/unicode.pf2 $out/EFI/boot/
|
||||
|
||||
|
@ -137,7 +137,7 @@ in
|
||||
# Setting vesa, we don't get the nvidia driver, which can't work in arm.
|
||||
services.xserver.videoDrivers = [ "vesa" ];
|
||||
|
||||
services.nixosManual.enable = false;
|
||||
documentation.nixos.enable = false;
|
||||
|
||||
# Include the firmware for various wireless cards.
|
||||
networking.enableRalinkFirmware = true;
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
x86_64-linux = "/nix/store/0d60i73mcv8z1m8d2m74yfn84980gfsa-nix-2.0.4";
|
||||
i686-linux = "/nix/store/6ssafj2s5a2g9x28yld7b70vwd6vw6lb-nix-2.0.4";
|
||||
aarch64-linux = "/nix/store/3wwch7bp7n7xsl8apgy2a4b16yzyij1z-nix-2.0.4";
|
||||
x86_64-darwin = "/nix/store/771l8i0mz4c8kry8cz3sz8rr3alalckg-nix-2.0.4";
|
||||
x86_64-linux = "/nix/store/cdcia67siabmj6li7vyffgv2cry86fq8-nix-2.1.3";
|
||||
i686-linux = "/nix/store/6q3xi6y5qnsv7d62b8n00hqfxi8rs2xs-nix-2.1.3";
|
||||
aarch64-linux = "/nix/store/2v93d0vimlm28jg0ms6v1i6lc0fq13pn-nix-2.1.3";
|
||||
x86_64-darwin = "/nix/store/dkjlfkrknmxbjmpfk3dg4q3nmb7m3zvk-nix-2.1.3";
|
||||
}
|
||||
|
@ -277,8 +277,7 @@ if ($virt eq "qemu" || $virt eq "kvm" || $virt eq "bochs") {
|
||||
|
||||
# Also for Hyper-V.
|
||||
if ($virt eq "microsoft") {
|
||||
push @initrdAvailableKernelModules, "hv_storvsc";
|
||||
$videoDriver = "fbdev";
|
||||
push @attrs, "virtualisation.hypervGuest.enable = true;"
|
||||
}
|
||||
|
||||
|
||||
|
@ -13,6 +13,7 @@ extraBuildFlags=()
|
||||
|
||||
mountPoint=/mnt
|
||||
channelPath=
|
||||
system=
|
||||
|
||||
while [ "$#" -gt 0 ]; do
|
||||
i="$1"; shift 1
|
||||
|
@ -82,7 +82,7 @@ evalNix(){
|
||||
set -e
|
||||
|
||||
if test $exit_code -eq 0; then
|
||||
cat <<EOF
|
||||
sed '/^warning: Nix search path/d' <<EOF
|
||||
$result
|
||||
EOF
|
||||
return 0;
|
||||
@ -90,7 +90,7 @@ EOF
|
||||
sed -n '
|
||||
/^error/ { s/, at (string):[0-9]*:[0-9]*//; p; };
|
||||
/^warning: Nix search path/ { p; };
|
||||
' <<EOF
|
||||
' >&2 <<EOF
|
||||
$result
|
||||
EOF
|
||||
exit_code=1
|
||||
|
@ -1,8 +1,72 @@
|
||||
{ config, lib, pkgs, ... }:
|
||||
{ config, lib, pkgs, baseModules, ... }:
|
||||
|
||||
with lib;
|
||||
|
||||
let cfg = config.documentation; in
|
||||
let
|
||||
|
||||
cfg = config.documentation;
|
||||
|
||||
/* For the purpose of generating docs, evaluate options with each derivation
|
||||
in `pkgs` (recursively) replaced by a fake with path "\${pkgs.attribute.path}".
|
||||
It isn't perfect, but it seems to cover a vast majority of use cases.
|
||||
Caveat: even if the package is reached by a different means,
|
||||
the path above will be shown and not e.g. `${config.services.foo.package}`. */
|
||||
manual = import ../../doc/manual rec {
|
||||
inherit pkgs config;
|
||||
version = config.system.nixos.release;
|
||||
revision = "release-${version}";
|
||||
options =
|
||||
let
|
||||
scrubbedEval = evalModules {
|
||||
modules = [ { nixpkgs.localSystem = config.nixpkgs.localSystem; } ] ++ baseModules;
|
||||
args = (config._module.args) // { modules = [ ]; };
|
||||
specialArgs = { pkgs = scrubDerivations "pkgs" pkgs; };
|
||||
};
|
||||
scrubDerivations = namePrefix: pkgSet: mapAttrs
|
||||
(name: value:
|
||||
let wholeName = "${namePrefix}.${name}"; in
|
||||
if isAttrs value then
|
||||
scrubDerivations wholeName value
|
||||
// (optionalAttrs (isDerivation value) { outPath = "\${${wholeName}}"; })
|
||||
else value
|
||||
)
|
||||
pkgSet;
|
||||
in scrubbedEval.options;
|
||||
};
|
||||
|
||||
helpScript = pkgs.writeScriptBin "nixos-help"
|
||||
''
|
||||
#! ${pkgs.runtimeShell} -e
|
||||
# Finds first executable browser in a colon-separated list.
|
||||
# (see how xdg-open defines BROWSER)
|
||||
browser="$(
|
||||
IFS=: ; for b in $BROWSER; do
|
||||
[ -n "$(type -P "$b" || true)" ] && echo "$b" && break
|
||||
done
|
||||
)"
|
||||
if [ -z "$browser" ]; then
|
||||
browser="$(type -P xdg-open || true)"
|
||||
if [ -z "$browser" ]; then
|
||||
browser="$(type -P w3m || true)"
|
||||
if [ -z "$browser" ]; then
|
||||
echo "$0: unable to start a web browser; please set \$BROWSER"
|
||||
exit 1
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
exec "$browser" ${manual.manualHTMLIndex}
|
||||
'';
|
||||
|
||||
desktopItem = pkgs.makeDesktopItem {
|
||||
name = "nixos-manual";
|
||||
desktopName = "NixOS Manual";
|
||||
genericName = "View NixOS documentation in a web browser";
|
||||
icon = "nix-snowflake";
|
||||
exec = "${helpScript}/bin/nixos-help";
|
||||
categories = "System";
|
||||
};
|
||||
|
||||
in
|
||||
|
||||
{
|
||||
|
||||
@ -66,6 +130,22 @@ let cfg = config.documentation; in
|
||||
'';
|
||||
};
|
||||
|
||||
nixos.enable = mkOption {
|
||||
type = types.bool;
|
||||
default = true;
|
||||
description = ''
|
||||
Whether to install NixOS's own documentation.
|
||||
<itemizedlist>
|
||||
<listitem><para>This includes man pages like
|
||||
<citerefentry><refentrytitle>configuration.nix</refentrytitle>
|
||||
<manvolnum>5</manvolnum></citerefentry> if <option>man.enable</option> is
|
||||
set.</para></listitem>
|
||||
<listitem><para>This includes the HTML manual and the <command>nixos-help</command> command if
|
||||
<option>doc.enable</option> is set.</para></listitem>
|
||||
</itemizedlist>
|
||||
'';
|
||||
};
|
||||
|
||||
};
|
||||
|
||||
};
|
||||
@ -86,7 +166,7 @@ let cfg = config.documentation; in
|
||||
if [ -w $out/share/info ]; then
|
||||
shopt -s nullglob
|
||||
for i in $out/share/info/*.info $out/share/info/*.info.gz; do
|
||||
${pkgs.texinfo}/bin/install-info $i $out/share/info/dir
|
||||
${pkgs.buildPackages.texinfo}/bin/install-info $i $out/share/info/dir
|
||||
done
|
||||
fi
|
||||
'';
|
||||
@ -99,6 +179,21 @@ let cfg = config.documentation; in
|
||||
environment.extraOutputsToInstall = [ "doc" ] ++ optional cfg.dev.enable "devdoc";
|
||||
})
|
||||
|
||||
(mkIf cfg.nixos.enable {
|
||||
system.build.manual = manual;
|
||||
|
||||
environment.systemPackages = []
|
||||
++ optional cfg.man.enable manual.manpages
|
||||
++ optionals cfg.doc.enable ([ manual.manualHTML helpScript ]
|
||||
++ optionals config.services.xserver.enable [ desktopItem pkgs.nixos-icons ]);
|
||||
|
||||
services.mingetty.helpLine = mkIf cfg.doc.enable (
|
||||
"\nRun `nixos-help` "
|
||||
+ optionalString config.services.nixosManual.showManual "or press <Alt-F${toString config.services.nixosManual.ttyNumber}> "
|
||||
+ "for the NixOS manual."
|
||||
);
|
||||
})
|
||||
|
||||
]);
|
||||
|
||||
}
|
||||
|
@ -53,7 +53,7 @@
|
||||
tomcat = 16;
|
||||
#audio = 17; # unused
|
||||
#floppy = 18; # unused
|
||||
#uucp = 19; # unused
|
||||
uucp = 19;
|
||||
#lp = 20; # unused
|
||||
#proc = 21; # unused
|
||||
pulseaudio = 22; # must match `pulseaudio' GID
|
||||
@ -289,7 +289,7 @@
|
||||
stanchion = 262;
|
||||
riak-cs = 263;
|
||||
infinoted = 264;
|
||||
# keystone = 265; # unused, removed 2017-12-13
|
||||
sickbeard = 265;
|
||||
# glance = 266; # unused, removed 2017-12-13
|
||||
couchpotato = 267;
|
||||
gogs = 268;
|
||||
@ -329,6 +329,8 @@
|
||||
# kvm = 302; # unused
|
||||
# render = 303; # unused
|
||||
zeronet = 304;
|
||||
lirc = 305;
|
||||
lidarr = 306;
|
||||
|
||||
# When adding a uid, make sure it doesn't match an existing gid. And don't use uids above 399!
|
||||
|
||||
@ -383,7 +385,7 @@
|
||||
virtuoso = 44;
|
||||
#rtkit = 45; # unused
|
||||
dovecot2 = 46;
|
||||
#dovenull = 47; # unused
|
||||
dovenull2 = 47;
|
||||
prayer = 49;
|
||||
mpd = 50;
|
||||
clamav = 51;
|
||||
@ -579,7 +581,7 @@
|
||||
stanchion = 262;
|
||||
riak-cs = 263;
|
||||
infinoted = 264;
|
||||
# keystone = 265; # unused, removed 2017-12-13
|
||||
sickbeard = 265;
|
||||
# glance = 266; # unused, removed 2017-12-13
|
||||
couchpotato = 267;
|
||||
gogs = 268;
|
||||
@ -618,6 +620,8 @@
|
||||
kvm = 302; # default udev rules from systemd requires these
|
||||
render = 303; # default udev rules from systemd requires these
|
||||
zeronet = 304;
|
||||
lirc = 305;
|
||||
lidarr = 306;
|
||||
|
||||
# When adding a gid, make sure it doesn't match an existing
|
||||
# uid. Users and groups with the same name should have equal
|
||||
|
@ -5,7 +5,6 @@ with lib;
|
||||
let
|
||||
cfg = config.system.nixos;
|
||||
|
||||
revisionFile = "${toString pkgs.path}/.git-revision";
|
||||
gitRepo = "${toString pkgs.path}/.git";
|
||||
gitCommitId = lib.substring 0 7 (commitIdFromGitRepo gitRepo);
|
||||
in
|
||||
@ -37,9 +36,7 @@ in
|
||||
nixos.revision = mkOption {
|
||||
internal = true;
|
||||
type = types.str;
|
||||
default = if pathIsDirectory gitRepo then commitIdFromGitRepo gitRepo
|
||||
else if pathExists revisionFile then fileContents revisionFile
|
||||
else "master";
|
||||
default = lib.trivial.revisionWithDefault "master";
|
||||
description = "The Git revision from which this NixOS configuration was built.";
|
||||
};
|
||||
|
||||
@ -84,7 +81,7 @@ in
|
||||
versionSuffix = mkIf (pathIsDirectory gitRepo) (mkDefault (".git." + gitCommitId));
|
||||
|
||||
# Note: the first letter is bumped on every release. It's an animal.
|
||||
codeName = "Jellyfish";
|
||||
codeName = "Koi";
|
||||
};
|
||||
|
||||
# Generate /etc/os-release. See
|
||||
|
@ -46,6 +46,7 @@
|
||||
./hardware/opengl.nix
|
||||
./hardware/pcmcia.nix
|
||||
./hardware/raid/hpsa.nix
|
||||
./hardware/steam-hardware.nix
|
||||
./hardware/usb-wwan.nix
|
||||
./hardware/onlykey.nix
|
||||
./hardware/video/amdgpu.nix
|
||||
@ -107,7 +108,6 @@
|
||||
./programs/oblogout.nix
|
||||
./programs/plotinus.nix
|
||||
./programs/qt5ct.nix
|
||||
./programs/rootston.nix
|
||||
./programs/screen.nix
|
||||
./programs/sedutil.nix
|
||||
./programs/slock.nix
|
||||
@ -148,6 +148,7 @@
|
||||
./security/duosec.nix
|
||||
./security/hidepid.nix
|
||||
./security/lock-kernel-modules.nix
|
||||
./security/misc.nix
|
||||
./security/oath.nix
|
||||
./security/pam.nix
|
||||
./security/pam_usb.nix
|
||||
@ -245,6 +246,7 @@
|
||||
./services/desktops/gnome3/gnome-user-share.nix
|
||||
./services/desktops/gnome3/gpaste.nix
|
||||
./services/desktops/gnome3/gvfs.nix
|
||||
./services/desktops/gnome3/rygel.nix
|
||||
./services/desktops/gnome3/seahorse.nix
|
||||
./services/desktops/gnome3/sushi.nix
|
||||
./services/desktops/gnome3/tracker.nix
|
||||
@ -271,15 +273,18 @@
|
||||
./services/hardware/interception-tools.nix
|
||||
./services/hardware/irqbalance.nix
|
||||
./services/hardware/lcd.nix
|
||||
./services/hardware/lirc.nix
|
||||
./services/hardware/nvidia-optimus.nix
|
||||
./services/hardware/pcscd.nix
|
||||
./services/hardware/pommed.nix
|
||||
./services/hardware/ratbagd.nix
|
||||
./services/hardware/sane.nix
|
||||
./services/hardware/sane_extra_backends/brscan4.nix
|
||||
./services/hardware/tcsd.nix
|
||||
./services/hardware/tlp.nix
|
||||
./services/hardware/thinkfan.nix
|
||||
./services/hardware/trezord.nix
|
||||
./services/hardware/triggerhappy.nix
|
||||
./services/hardware/u2f.nix
|
||||
./services/hardware/udev.nix
|
||||
./services/hardware/udisks2.nix
|
||||
@ -362,6 +367,7 @@
|
||||
./services/misc/jackett.nix
|
||||
./services/misc/logkeys.nix
|
||||
./services/misc/leaps.nix
|
||||
./services/misc/lidarr.nix
|
||||
./services/misc/mantisbt.nix
|
||||
./services/misc/mathics.nix
|
||||
./services/misc/matrix-synapse.nix
|
||||
@ -392,6 +398,7 @@
|
||||
./services/misc/rogue.nix
|
||||
./services/misc/serviio.nix
|
||||
./services/misc/safeeyes.nix
|
||||
./services/misc/sickbeard.nix
|
||||
./services/misc/siproxd.nix
|
||||
./services/misc/snapper.nix
|
||||
./services/misc/sonarr.nix
|
||||
@ -406,6 +413,7 @@
|
||||
./services/misc/taskserver
|
||||
./services/misc/tzupdate.nix
|
||||
./services/misc/uhub.nix
|
||||
./services/misc/weechat.nix
|
||||
./services/misc/xmr-stak.nix
|
||||
./services/misc/zookeeper.nix
|
||||
./services/monitoring/apcupsd.nix
|
||||
@ -494,6 +502,7 @@
|
||||
./services/networking/dnsdist.nix
|
||||
./services/networking/dnsmasq.nix
|
||||
./services/networking/ejabberd.nix
|
||||
./services/networking/epmd.nix
|
||||
./services/networking/fakeroute.nix
|
||||
./services/networking/ferm.nix
|
||||
./services/networking/firefox/sync-server.nix
|
||||
@ -515,9 +524,11 @@
|
||||
./services/networking/heyefi.nix
|
||||
./services/networking/hostapd.nix
|
||||
./services/networking/htpdate.nix
|
||||
./services/networking/hylafax/default.nix
|
||||
./services/networking/i2pd.nix
|
||||
./services/networking/i2p.nix
|
||||
./services/networking/iodine.nix
|
||||
./services/networking/iperf3.nix
|
||||
./services/networking/ircd-hybrid/default.nix
|
||||
./services/networking/iwd.nix
|
||||
./services/networking/keepalived/default.nix
|
||||
@ -552,6 +563,7 @@
|
||||
./services/networking/nsd.nix
|
||||
./services/networking/ntopng.nix
|
||||
./services/networking/ntpd.nix
|
||||
./services/networking/nullidentdmod.nix
|
||||
./services/networking/nylon.nix
|
||||
./services/networking/ocserv.nix
|
||||
./services/networking/oidentd.nix
|
||||
@ -622,7 +634,7 @@
|
||||
./services/networking/zerobin.nix
|
||||
./services/networking/zeronet.nix
|
||||
./services/networking/zerotierone.nix
|
||||
./services/networking/znc.nix
|
||||
./services/networking/znc/default.nix
|
||||
./services/printing/cupsd.nix
|
||||
./services/scheduling/atd.nix
|
||||
./services/scheduling/chronos.nix
|
||||
@ -676,8 +688,10 @@
|
||||
./services/web-apps/atlassian/confluence.nix
|
||||
./services/web-apps/atlassian/crowd.nix
|
||||
./services/web-apps/atlassian/jira.nix
|
||||
./services/web-apps/codimd.nix
|
||||
./services/web-apps/frab.nix
|
||||
./services/web-apps/mattermost.nix
|
||||
./services/web-apps/nextcloud.nix
|
||||
./services/web-apps/nexus.nix
|
||||
./services/web-apps/pgpkeyserver-lite.nix
|
||||
./services/web-apps/matomo.nix
|
||||
@ -721,12 +735,14 @@
|
||||
./services/x11/display-managers/lightdm.nix
|
||||
./services/x11/display-managers/sddm.nix
|
||||
./services/x11/display-managers/slim.nix
|
||||
./services/x11/display-managers/startx.nix
|
||||
./services/x11/display-managers/xpra.nix
|
||||
./services/x11/fractalart.nix
|
||||
./services/x11/hardware/libinput.nix
|
||||
./services/x11/hardware/multitouch.nix
|
||||
./services/x11/hardware/synaptics.nix
|
||||
./services/x11/hardware/wacom.nix
|
||||
./services/x11/gdk-pixbuf.nix
|
||||
./services/x11/redshift.nix
|
||||
./services/x11/urxvtd.nix
|
||||
./services/x11/window-managers/awesome.nix
|
||||
|
@ -7,9 +7,12 @@
|
||||
services.xserver = {
|
||||
enable = true;
|
||||
displayManager.sddm.enable = true;
|
||||
desktopManager.plasma5.enable = true;
|
||||
desktopManager.plasma5 = {
|
||||
enable = true;
|
||||
enableQt4Support = false;
|
||||
};
|
||||
libinput.enable = true; # for touchpad support on many laptops
|
||||
};
|
||||
|
||||
environment.systemPackages = [ pkgs.glxinfo ];
|
||||
environment.systemPackages = [ pkgs.glxinfo pkgs.firefox ];
|
||||
}
|
||||
|
@ -6,12 +6,18 @@
|
||||
with lib;
|
||||
|
||||
{
|
||||
meta = {
|
||||
maintainers = [ maintainers.joachifm ];
|
||||
};
|
||||
|
||||
boot.kernelPackages = mkDefault pkgs.linuxPackages_hardened;
|
||||
|
||||
security.hideProcessInformation = mkDefault true;
|
||||
|
||||
security.lockKernelModules = mkDefault true;
|
||||
|
||||
security.allowUserNamespaces = mkDefault false;
|
||||
|
||||
security.apparmor.enable = mkDefault true;
|
||||
|
||||
boot.kernelParams = [
|
||||
@ -55,18 +61,6 @@ with lib;
|
||||
# ... or at least apply some hardening to it
|
||||
boot.kernel.sysctl."net.core.bpf_jit_harden" = mkDefault true;
|
||||
|
||||
# A recurring problem with user namespaces is that there are
|
||||
# still code paths where the kernel's permission checking logic
|
||||
# fails to account for namespacing, instead permitting a
|
||||
# namespaced process to act outside the namespace with the
|
||||
# same privileges as it would have inside it. This is particularly
|
||||
# bad in the common case of running as root within the namespace.
|
||||
#
|
||||
# Setting the number of allowed user namespaces to 0 effectively disables
|
||||
# the feature at runtime. Attempting to create a user namespace
|
||||
# with unshare will then fail with "no space left on device".
|
||||
boot.kernel.sysctl."user.max_user_namespaces" = mkDefault 0;
|
||||
|
||||
# Raise ASLR entropy for 64bit & 32bit, respectively.
|
||||
#
|
||||
# Note: mmap_rnd_compat_bits may not exist on 64bit.
|
||||
|
@ -22,9 +22,10 @@ with lib;
|
||||
config = {
|
||||
|
||||
# Enable in installer, even if the minimal profile disables it.
|
||||
services.nixosManual.enable = mkForce true;
|
||||
documentation.enable = mkForce true;
|
||||
|
||||
# Show the manual.
|
||||
documentation.nixos.enable = mkForce true;
|
||||
services.nixosManual.showManual = true;
|
||||
|
||||
# Let the user play Rogue on TTY 8 during the installation.
|
||||
|
@ -12,7 +12,6 @@ with lib;
|
||||
i18n.supportedLocales = [ (config.i18n.defaultLocale + "/UTF-8") ];
|
||||
|
||||
documentation.enable = mkDefault false;
|
||||
services.nixosManual.enable = mkDefault false;
|
||||
|
||||
sound.enable = mkDefault false;
|
||||
}
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user