Project import generated by Copybara.
GitOrigin-RevId: e182da8622a354d44c39b3d7a542dc12cd7baa5f
This commit is contained in:
parent
376e20fe04
commit
a3d4720129
2136 changed files with 52135 additions and 30991 deletions
5
third_party/nixpkgs/.github/CODEOWNERS
vendored
5
third_party/nixpkgs/.github/CODEOWNERS
vendored
|
@ -48,6 +48,10 @@
|
|||
# Nixpkgs build-support
|
||||
/pkgs/build-support/writers @lassulus @Profpatsch
|
||||
|
||||
# Nixpkgs make-disk-image
|
||||
/doc/builders/images/makediskimage.section.md @raitobezarius
|
||||
/nixos/lib/make-disk-image.nix @raitobezarius
|
||||
|
||||
# Nixpkgs documentation
|
||||
/maintainers/scripts/db-to-md.sh @jtojnar @ryantm
|
||||
/maintainers/scripts/doc @jtojnar @ryantm
|
||||
|
@ -270,6 +274,7 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
|
|||
# GNOME
|
||||
/pkgs/desktops/gnome @jtojnar
|
||||
/pkgs/desktops/gnome/extensions @piegamesde @jtojnar
|
||||
/pkgs/build-support/make-hardcode-gsettings-patch @jtojnar
|
||||
|
||||
# Cinnamon
|
||||
/pkgs/desktops/cinnamon @mkg20001
|
||||
|
|
4
third_party/nixpkgs/CONTRIBUTING.md
vendored
4
third_party/nixpkgs/CONTRIBUTING.md
vendored
|
@ -55,7 +55,7 @@ Package version upgrades usually allow for simpler commit messages, including at
|
|||
|
||||
Pull requests should not be squash merged in order to keep complete commit messages and GPG signatures intact and must not be when the change doesn't make sense as a single commit.
|
||||
This means that, when addressing review comments in order to keep the pull request in an always mergeable status, you will sometimes need to rewrite your branch's history and then force-push it with `git push --force-with-lease`.
|
||||
Useful git commands that can help a lot with this are `git commit --patch --amend` and `git rebase --interactive @~3`. For more details consult the git man pages.
|
||||
Useful git commands that can help a lot with this are `git commit --patch --amend` and `git rebase --interactive`. For more details consult the git man pages or online resources like [git-rebase.io](https://git-rebase.io/) or [The Pro Git Book](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History).
|
||||
|
||||
## Rebasing between branches (i.e. from master to staging)
|
||||
|
||||
|
@ -112,7 +112,7 @@ You can also create the backport manually:
|
|||
2. Check out the target _release branch_, e.g. `release-22.11`. Do not use a _channel branch_ like `nixos-22.11` or `nixpkgs-22.11-darwin`.
|
||||
3. Create a branch for your change, e.g. `git checkout -b backport`.
|
||||
4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request.
|
||||
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-22.11`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[22.11]`.
|
||||
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-22.11`) as the target branch of the pull request, and link to the pull request in which the original change was committed to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[22.11]`.
|
||||
6. When the backport pull request is merged and you have the necessary privileges you can also replace the label `9.needs: port to stable` with `8.has: port to stable` on the original pull request. This way maintainers can keep track of missing backports easier.
|
||||
|
||||
## Criteria for Backporting changes
|
||||
|
|
|
@ -3,10 +3,31 @@ Turns a manpage reference into a link, when a mapping is defined below.
|
|||
]]
|
||||
|
||||
local man_urls = {
|
||||
["tmpfiles.d(5)"] = "https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html",
|
||||
["nix.conf(5)"] = "https://nixos.org/manual/nix/stable/#sec-conf-file",
|
||||
["systemd.time(7)"] = "https://www.freedesktop.org/software/systemd/man/systemd.time.html",
|
||||
|
||||
["journald.conf(5)"] = "https://www.freedesktop.org/software/systemd/man/journald.conf.html",
|
||||
["logind.conf(5)"] = "https://www.freedesktop.org/software/systemd/man/logind.conf.html",
|
||||
["networkd.conf(5)"] = "https://www.freedesktop.org/software/systemd/man/networkd.conf.html",
|
||||
["systemd.automount(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.automount.html",
|
||||
["systemd.exec(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.exec.html",
|
||||
["systemd.link(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.link.html",
|
||||
["systemd.mount(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.mount.html",
|
||||
["systemd.netdev(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.netdev.html",
|
||||
["systemd.network(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.network.html",
|
||||
["systemd.nspawn(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.nspawn.html",
|
||||
["systemd.path(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.path.html",
|
||||
["systemd.resource-control(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html",
|
||||
["systemd.scope(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.scope.html",
|
||||
["systemd.service(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.service.html",
|
||||
["systemd.slice(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.slice.html",
|
||||
["systemd.socket(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.socket.html",
|
||||
["systemd.timer(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.timer.html",
|
||||
["systemd.unit(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.unit.html",
|
||||
["timesyncd.conf(5)"] = "https://www.freedesktop.org/software/systemd/man/timesyncd.conf.html",
|
||||
["tmpfiles.d(5)"] = "https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html",
|
||||
["systemd.time(7)"] = "https://www.freedesktop.org/software/systemd/man/systemd.time.html",
|
||||
["systemd-fstab-generator(8)"] = "https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html",
|
||||
["systemd-networkd-wait-online.service(8)"] = "https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html",
|
||||
}
|
||||
|
||||
function Code(elem)
|
||||
|
|
1
third_party/nixpkgs/doc/builders/images.xml
vendored
1
third_party/nixpkgs/doc/builders/images.xml
vendored
|
@ -10,4 +10,5 @@
|
|||
<xi:include href="images/ocitools.section.xml" />
|
||||
<xi:include href="images/snaptools.section.xml" />
|
||||
<xi:include href="images/portableservice.section.xml" />
|
||||
<xi:include href="images/makediskimage.section.xml" />
|
||||
</chapter>
|
||||
|
|
107
third_party/nixpkgs/doc/builders/images/makediskimage.section.md
vendored
Normal file
107
third_party/nixpkgs/doc/builders/images/makediskimage.section.md
vendored
Normal file
|
@ -0,0 +1,107 @@
|
|||
# `<nixpkgs/nixos/lib/make-disk-image.nix>` {#sec-make-disk-image}
|
||||
|
||||
`<nixpkgs/nixos/lib/make-disk-image.nix>` is a function to create _disk images_ in multiple formats: raw, QCOW2 (QEMU), QCOW2-Compressed (compressed version), VDI (VirtualBox), VPC (VirtualPC).
|
||||
|
||||
This function can create images in two ways:
|
||||
|
||||
- using `cptofs` without any virtual machine to create a Nix store disk image,
|
||||
- using a virtual machine to create a full NixOS installation.
|
||||
|
||||
When testing early-boot or lifecycle parts of NixOS such as a bootloader or multiple generations, it is necessary to opt for a full NixOS system installation.
|
||||
Whereas for many web servers, applications, it is possible to work with a Nix store only disk image and is faster to build.
|
||||
|
||||
NixOS tests also use this function when preparing the VM. The `cptofs` method is used when `virtualisation.useBootLoader` is false (the default). Otherwise the second method is used.
|
||||
|
||||
## Features
|
||||
|
||||
For reference, read the function signature source code for documentation on arguments: <https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-disk-image.nix>.
|
||||
Features are separated in various sections depending on if you opt for a Nix-store only image or a full NixOS image.
|
||||
|
||||
### Common
|
||||
|
||||
- arbitrary NixOS configuration
|
||||
- automatic or bound disk size: `diskSize` parameter, `additionalSpace` can be set when `diskSize` is `auto` to add a constant of disk space
|
||||
- multiple partition table layouts: EFI, legacy, legacy + GPT, hybrid, none through `partitionTableType` parameter
|
||||
- OVMF or EFI firmwares and variables templates can be customized
|
||||
- root filesystem `fsType` can be customized to whatever `mkfs.${fsType}` exist during operations
|
||||
- root filesystem label can be customized, defaults to `nix-store` if it's a Nix store image, otherwise `nixpkgs/nixos`
|
||||
- arbitrary code can be executed after disk image was produced with `postVM`
|
||||
- the current nixpkgs can be realized as a channel in the disk image, which will change the hash of the image when the sources are updated
|
||||
- additional store paths can be provided through `additionalPaths`
|
||||
|
||||
### Full NixOS image
|
||||
|
||||
- arbitrary contents with permissions can be placed in the target filesystem using `contents`
|
||||
- a `/etc/nixpkgs/nixos/configuration.nix` can be provided through `configFile`
|
||||
- bootloaders are supported
|
||||
- EFI variables can be mutated during image production and the result is exposed in `$out`
|
||||
- boot partition size when partition table is `efi` or `hybrid`
|
||||
|
||||
### On bit-to-bit reproducibility
|
||||
|
||||
Images are **NOT** deterministic, please do not hesitate to try to fix this, source of determinisms are (not exhaustive) :
|
||||
|
||||
- bootloader installation have timestamps
|
||||
- SQLite Nix store database contain registration times
|
||||
- `/etc/shadow` is in a non-deterministic order
|
||||
|
||||
A `deterministic` flag is available for best efforts determinism.
|
||||
|
||||
## Usage
|
||||
|
||||
To produce a Nix-store only image:
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> {};
|
||||
lib = pkgs.lib;
|
||||
make-disk-image = import <nixpkgs/nixos/lib/make-disk-image.nix>;
|
||||
in
|
||||
make-disk-image {
|
||||
inherit pkgs lib;
|
||||
config = {};
|
||||
additionalPaths = [ ];
|
||||
format = "qcow2";
|
||||
onlyNixStore = true;
|
||||
partitionTableType = "none";
|
||||
installBootLoader = false;
|
||||
touchEFIVars = false;
|
||||
diskSize = "auto";
|
||||
additionalSpace = "0M"; # Defaults to 512M.
|
||||
copyChannel = false;
|
||||
}
|
||||
```
|
||||
|
||||
Some arguments can be left out, they are shown explicitly for the sake of the example.
|
||||
|
||||
Building this derivation will provide a QCOW2 disk image containing only the Nix store and its registration information.
|
||||
|
||||
To produce a NixOS installation image disk with UEFI and bootloader installed:
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> {};
|
||||
lib = pkgs.lib;
|
||||
make-disk-image = import <nixpkgs/nixos/lib/make-disk-image.nix>;
|
||||
evalConfig = import <nixpkgs/nixos/lib/eval-config.nix>;
|
||||
in
|
||||
make-disk-image {
|
||||
inherit pkgs lib;
|
||||
config = evalConfig {
|
||||
modules = [
|
||||
{
|
||||
fileSystems."/" = { device = "/dev/vda"; fsType = "ext4"; autoFormat = true; };
|
||||
boot.grub.device = "/dev/vda";
|
||||
}
|
||||
];
|
||||
};
|
||||
format = "qcow2";
|
||||
onlyNixStore = false;
|
||||
partitionTableType = "legacy+gpt";
|
||||
installBootLoader = true;
|
||||
touchEFIVars = true;
|
||||
diskSize = "auto";
|
||||
additionalSpace = "0M"; # Defaults to 512M.
|
||||
copyChannel = false;
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -34,4 +34,4 @@ buildContainer {
|
|||
|
||||
- `mounts` specifies additional mount points chosen by the user. By default only a minimal set of necessary filesystems are mounted into the container (e.g procfs, cgroupfs)
|
||||
|
||||
- `readonly` makes the container\'s rootfs read-only if it is set to true. The default value is false `false`.
|
||||
- `readonly` makes the container's rootfs read-only if it is set to true. The default value is false `false`.
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
## Compiling without AVX support {#compiling-without-avx-support}
|
||||
|
||||
Especially older CPUs don\'t support [AVX](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions) (Advanced Vector Extensions) instructions that are used by DLib to optimize their algorithms.
|
||||
Especially older CPUs don't support [AVX](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions) (Advanced Vector Extensions) instructions that are used by DLib to optimize their algorithms.
|
||||
|
||||
On the affected hardware errors like `Illegal instruction` will occur. In those cases AVX support needs to be disabled:
|
||||
|
||||
|
|
1
third_party/nixpkgs/doc/builders/special.xml
vendored
1
third_party/nixpkgs/doc/builders/special.xml
vendored
|
@ -7,4 +7,5 @@
|
|||
</para>
|
||||
<xi:include href="special/fhs-environments.section.xml" />
|
||||
<xi:include href="special/mkshell.section.xml" />
|
||||
<xi:include href="special/darwin-builder.section.xml" />
|
||||
</chapter>
|
||||
|
|
60
third_party/nixpkgs/doc/builders/special/darwin-builder.section.md
vendored
Normal file
60
third_party/nixpkgs/doc/builders/special/darwin-builder.section.md
vendored
Normal file
|
@ -0,0 +1,60 @@
|
|||
# darwin.builder {#sec-darwin-builder}
|
||||
|
||||
`darwin.builder` provides a way to bootstrap a Linux builder on a macOS machine.
|
||||
|
||||
This requires macOS version 12.4 or later.
|
||||
|
||||
This also requires that port 22 on your machine is free (since Nix does not
|
||||
permit specifying a non-default SSH port for builders).
|
||||
|
||||
You will also need to be a trusted user for your Nix installation. In other
|
||||
words, your `/etc/nix/nix.conf` should have something like:
|
||||
|
||||
```
|
||||
extra-trusted-users = <your username goes here>
|
||||
```
|
||||
|
||||
To launch the builder, run the following flake:
|
||||
|
||||
```ShellSession
|
||||
$ nix run nixpkgs#darwin.builder
|
||||
```
|
||||
|
||||
That will prompt you to enter your `sudo` password:
|
||||
|
||||
```
|
||||
+ sudo --reset-timestamp /nix/store/…-install-credentials.sh ./keys
|
||||
Password:
|
||||
```
|
||||
|
||||
… so that it can install a private key used to `ssh` into the build server.
|
||||
After that the script will launch the virtual machine:
|
||||
|
||||
```
|
||||
<<< Welcome to NixOS 22.11.20220901.1bd8d11 (aarch64) - ttyAMA0 >>>
|
||||
|
||||
Run 'nixos-help' for the NixOS manual.
|
||||
|
||||
nixos login:
|
||||
```
|
||||
|
||||
> Note: When you need to stop the VM, type `Ctrl`-`a` + `c` to open the `qemu`
|
||||
> prompt and then type `quit` followed by `Enter`
|
||||
|
||||
To delegate builds to the remote builder, add the following options to your
|
||||
`nix.conf` file:
|
||||
|
||||
```
|
||||
# - Replace ${ARCH} with either aarch64 or x86_64 to match your host machine
|
||||
# - Replace ${MAX_JOBS} with the maximum number of builds (pick 4 if you're not sure)
|
||||
builders = ssh-ng://builder@localhost ${ARCH}-linux /etc/nix/builder_ed25519 ${MAX_JOBS} - - - c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUpCV2N4Yi9CbGFxdDFhdU90RStGOFFVV3JVb3RpQzVxQkorVXVFV2RWQ2Igcm9vdEBuaXhvcwo='
|
||||
|
||||
# Not strictly necessary, but this will reduce your disk utilization
|
||||
builders-use-substitutes = true
|
||||
```
|
||||
|
||||
… and then restart your Nix daemon to apply the change:
|
||||
|
||||
```ShellSession
|
||||
$ sudo launchctl kickstart -k system/org.nixos.nix-daemon
|
||||
```
|
|
@ -260,6 +260,10 @@ When in doubt, consider refactoring the `pkgs/` tree, e.g. creating new categori
|
|||
|
||||
- `development/tools/build-managers` (e.g. `gnumake`)
|
||||
|
||||
- **If it’s a _language server_:**
|
||||
|
||||
- `development/tools/language-servers` (e.g. `ccls` or `rnix-lsp`)
|
||||
|
||||
- **Else:**
|
||||
|
||||
- `development/tools/misc` (e.g. `binutils`)
|
||||
|
|
|
@ -185,7 +185,7 @@ Sample template for a new module review is provided below.
|
|||
##### Comments
|
||||
```
|
||||
|
||||
## Individual maintainer list {#reviewing-contributions-indvidual-maintainer-list}
|
||||
## Individual maintainer list {#reviewing-contributions-individual-maintainer-list}
|
||||
|
||||
When adding users to `maintainers/maintainer-list.nix`, the following
|
||||
checks should be performed:
|
||||
|
|
|
@ -199,7 +199,7 @@ It’s important to test any executables generated by a build when you change or
|
|||
|
||||
### Meets Nixpkgs contribution standards {#submitting-changes-contribution-standards}
|
||||
|
||||
The last checkbox is fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md). The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc\... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
|
||||
The last checkbox is fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md). The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
|
||||
|
||||
## Hotfixing pull requests {#submitting-changes-hotfixing-pull-requests}
|
||||
|
||||
|
|
18
third_party/nixpkgs/doc/doc-support/default.nix
vendored
18
third_party/nixpkgs/doc/doc-support/default.nix
vendored
|
@ -3,8 +3,22 @@ let
|
|||
inherit (pkgs) lib;
|
||||
inherit (lib) hasPrefix removePrefix;
|
||||
|
||||
locationsXml = import ./lib-function-locations.nix { inherit pkgs nixpkgs; };
|
||||
functionDocs = import ./lib-function-docs.nix { inherit locationsXml pkgs; };
|
||||
libsets = [
|
||||
{ name = "asserts"; description = "assertion functions"; }
|
||||
{ name = "attrsets"; description = "attribute set functions"; }
|
||||
{ name = "strings"; description = "string manipulation functions"; }
|
||||
{ name = "versions"; description = "version string functions"; }
|
||||
{ name = "trivial"; description = "miscellaneous functions"; }
|
||||
{ name = "lists"; description = "list manipulation functions"; }
|
||||
{ name = "debug"; description = "debugging functions"; }
|
||||
{ name = "options"; description = "NixOS / nixpkgs option handling"; }
|
||||
{ name = "filesystem"; description = "filesystem functions"; }
|
||||
{ name = "sources"; description = "source filtering functions"; }
|
||||
{ name = "cli"; description = "command-line serialization functions"; }
|
||||
];
|
||||
|
||||
locationsXml = import ./lib-function-locations.nix { inherit pkgs nixpkgs libsets; };
|
||||
functionDocs = import ./lib-function-docs.nix { inherit locationsXml pkgs libsets; };
|
||||
version = pkgs.lib.version;
|
||||
|
||||
epub-xsl = pkgs.writeText "epub.xsl" ''
|
||||
|
|
|
@ -1,30 +1,32 @@
|
|||
# Generates the documentation for library functons via nixdoc. To add
|
||||
# another library function file to this list, the include list in the
|
||||
# file `doc/functions/library.xml` must also be updated.
|
||||
# Generates the documentation for library functions via nixdoc.
|
||||
|
||||
{ pkgs ? import ./.. {}, locationsXml }:
|
||||
{ pkgs, locationsXml, libsets }:
|
||||
|
||||
with pkgs; stdenv.mkDerivation {
|
||||
name = "nixpkgs-lib-docs";
|
||||
src = ./../../lib;
|
||||
src = ../../lib;
|
||||
|
||||
buildInputs = [ nixdoc ];
|
||||
installPhase = ''
|
||||
function docgen {
|
||||
nixdoc -c "$1" -d "$2" -f "../lib/$1.nix" > "$out/$1.xml"
|
||||
# TODO: wrap lib.$1 in <literal>, make nixdoc not escape it
|
||||
nixdoc -c "$1" -d "lib.$1: $2" -f "$1.nix" > "$out/$1.xml"
|
||||
echo "<xi:include href='$1.xml' />" >> "$out/index.xml"
|
||||
}
|
||||
|
||||
mkdir -p $out
|
||||
ln -s ${locationsXml} $out/locations.xml
|
||||
mkdir -p "$out"
|
||||
|
||||
docgen asserts 'Assert functions'
|
||||
docgen attrsets 'Attribute-set functions'
|
||||
docgen strings 'String manipulation functions'
|
||||
docgen trivial 'Miscellaneous functions'
|
||||
docgen lists 'List manipulation functions'
|
||||
docgen debug 'Debugging functions'
|
||||
docgen options 'NixOS / nixpkgs option handling'
|
||||
docgen filesystem 'Filesystem functions'
|
||||
docgen sources 'Source filtering functions'
|
||||
cat > "$out/index.xml" << 'EOF'
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<root xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||
EOF
|
||||
|
||||
${lib.concatMapStrings ({ name, description }: ''
|
||||
docgen ${name} ${lib.escapeShellArg description}
|
||||
'') libsets}
|
||||
|
||||
echo "</root>" >> "$out/index.xml"
|
||||
|
||||
ln -s ${locationsXml} $out/locations.xml
|
||||
'';
|
||||
}
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
{ pkgs ? (import ./.. { }), nixpkgs ? { }}:
|
||||
{ pkgs, nixpkgs ? { }, libsets }:
|
||||
let
|
||||
revision = pkgs.lib.trivial.revisionWithDefault (nixpkgs.revision or "master");
|
||||
|
||||
|
@ -16,9 +16,7 @@ let
|
|||
subsetname = subsetname;
|
||||
functions = libDefPos toplib.${subsetname};
|
||||
})
|
||||
(builtins.filter
|
||||
(name: builtins.isAttrs toplib.${name})
|
||||
(builtins.attrNames toplib));
|
||||
(builtins.map (x: x.name) libsets);
|
||||
|
||||
nixpkgsLib = pkgs.lib;
|
||||
|
||||
|
|
|
@ -11,6 +11,7 @@
|
|||
<xsl:param name="html.script" select="'./highlightjs/highlight.pack.js ./highlightjs/loader.js'" />
|
||||
<xsl:param name="xref.with.number.and.title" select="0" />
|
||||
<xsl:param name="use.id.as.filename" select="1" />
|
||||
<xsl:param name="generate.section.toc.level" select="1" />
|
||||
<xsl:param name="toc.section.depth" select="0" />
|
||||
<xsl:param name="admon.style" select="''" />
|
||||
<xsl:param name="callout.graphics.extension" select="'.svg'" />
|
||||
|
|
24
third_party/nixpkgs/doc/functions/library.xml
vendored
24
third_party/nixpkgs/doc/functions/library.xml
vendored
|
@ -8,25 +8,7 @@
|
|||
Nixpkgs provides a standard library at <varname>pkgs.lib</varname>, or through <code>import <nixpkgs/lib></code>.
|
||||
</para>
|
||||
|
||||
<!-- These docs are generated via nixdoc. To add another generated
|
||||
library function file to this list, the file
|
||||
`lib-function-docs.nix` must also be updated. -->
|
||||
|
||||
<xi:include href="./library/generated/asserts.xml" />
|
||||
|
||||
<xi:include href="./library/generated/attrsets.xml" />
|
||||
|
||||
<xi:include href="./library/generated/strings.xml" />
|
||||
|
||||
<xi:include href="./library/generated/trivial.xml" />
|
||||
|
||||
<xi:include href="./library/generated/lists.xml" />
|
||||
|
||||
<xi:include href="./library/generated/debug.xml" />
|
||||
|
||||
<xi:include href="./library/generated/options.xml" />
|
||||
|
||||
<xi:include href="./library/generated/filesystem.xml" />
|
||||
|
||||
<xi:include href="./library/generated/sources.xml" />
|
||||
<!-- The index must have a root element to declare namespaces, but we
|
||||
don't want to include it, so we select all of its children. -->
|
||||
<xi:include href="./library/generated/index.xml" xpointer="xpointer(/root/*)" />
|
||||
</section>
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
## Usage {#sec-pkgs-nix-gitignore-usage}
|
||||
|
||||
`pkgs.nix-gitignore` exports a number of functions, but you\'ll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
|
||||
`pkgs.nix-gitignore` exports a number of functions, but you'll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
|
||||
|
||||
```nix
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
|
@ -30,7 +30,7 @@ gitignoreSourcePure = gitignoreFilterSourcePure (_: _: true);
|
|||
gitignoreSource = gitignoreFilterSource (_: _: true);
|
||||
```
|
||||
|
||||
Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it\'s blacklisted by either your filter or the gitignoreFilter.
|
||||
Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it's blacklisted by either your filter or the gitignoreFilter.
|
||||
|
||||
If you want to make your own filter from scratch, you may use
|
||||
|
||||
|
|
|
@ -232,7 +232,6 @@ androidenv.emulateApp {
|
|||
platformVersion = "24";
|
||||
abiVersion = "armeabi-v7a"; # mips, x86, x86_64
|
||||
systemImageType = "default";
|
||||
useGoogleAPIs = false;
|
||||
app = ./MyApp.apk;
|
||||
package = "MyApp";
|
||||
activity = "MainActivity";
|
||||
|
|
|
@ -93,7 +93,7 @@ Practical steps:
|
|||
- run `mix2nix > mix_deps.nix` in the upstream repo.
|
||||
- pass `mixNixDeps = with pkgs; import ./mix_deps.nix { inherit lib beamPackages; };` as an argument to mixRelease.
|
||||
|
||||
If there are git depencencies.
|
||||
If there are git dependencies.
|
||||
|
||||
- You'll need to fix the version artificially in mix.exs and regenerate the mix.lock with fixed version (on upstream). This will enable you to run `mix2nix > mix_deps.nix`.
|
||||
- From the mix_deps.nix file, remove the dependencies that had git versions and pass them as an override to the import function.
|
||||
|
|
|
@ -8,7 +8,7 @@ The Coq derivation is overridable through the `coq.override overrides`, where ov
|
|||
* `customOCamlPackages` (optional, defaults to `null`, which lets Coq choose a version automatically), which can be set to any of the ocaml packages attribute of `ocaml-ng` (such as `ocaml-ng.ocamlPackages_4_10` which is the default for Coq 8.11 for example).
|
||||
* `coq-version` (optional, defaults to the short version e.g. "8.10"), is a version number of the form "x.y" that indicates which Coq's version build behavior to mimic when using a source which is not a release. E.g. `coq.override { version = "d370a9d1328a4e1cdb9d02ee032f605a9d94ec7a"; coq-version = "8.10"; }`.
|
||||
|
||||
The associated package set can be optained using `mkCoqPackages coq`, where `coq` is the derivation to use.
|
||||
The associated package set can be obtained using `mkCoqPackages coq`, where `coq` is the derivation to use.
|
||||
|
||||
## Coq packages attribute sets: `coqPackages` {#coq-packages-attribute-sets-coqpackages}
|
||||
|
||||
|
|
|
@ -38,7 +38,7 @@ want to target for in terms of SASS (real hardware) or PTX (JIT kernels).
|
|||
|
||||
Nixpkgs tries to target support real architecture defaults based on the
|
||||
CUDA toolkit version with PTX support for future hardware. Experienced
|
||||
users may optmize this configuration for a variety of reasons such as
|
||||
users may optimize this configuration for a variety of reasons such as
|
||||
reducing binary size and compile time, supporting legacy hardware, or
|
||||
optimizing for specific hardware.
|
||||
|
||||
|
|
|
@ -37,9 +37,9 @@ pkgs.writeCueValidator
|
|||
```
|
||||
|
||||
- The first parameter is the Cue schema file.
|
||||
- The second paramter is an options parameter, currently, only: `document` can be passed.
|
||||
- The second parameter is an options parameter, currently, only: `document` can be passed.
|
||||
|
||||
`document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but differents documents based on the data you are validating.
|
||||
`document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but different documents based on the data you are validating.
|
||||
|
||||
Another example, given the following `validator.nix` :
|
||||
```
|
||||
|
|
|
@ -121,7 +121,6 @@ in buildDotnetModule rec {
|
|||
|
||||
dotnet-sdk = dotnetCorePackages.sdk_3_1;
|
||||
dotnet-runtime = dotnetCorePackages.net_5_0;
|
||||
dotnetFlags = [ "--runtime linux-x64" ];
|
||||
|
||||
executables = [ "foo" ]; # This wraps "$out/lib/$pname/foo" to `$out/bin/foo`.
|
||||
executables = []; # Don't install any executables.
|
||||
|
|
|
@ -4,10 +4,10 @@
|
|||
|
||||
### Installation without packages {#installation-without-packages}
|
||||
|
||||
You can install `hy` via nix-env or by adding it to `configuration.nix` by reffering to it as a `hy` attribute. This kind of installation adds `hy` to your environment and it succesfully works with `python3`.
|
||||
You can install `hy` via nix-env or by adding it to `configuration.nix` by referring to it as a `hy` attribute. This kind of installation adds `hy` to your environment and it successfully works with `python3`.
|
||||
|
||||
::: {.caution}
|
||||
Packages that are installed with your python derivation, are not accesible by `hy` this way.
|
||||
Packages that are installed with your python derivation, are not accessible by `hy` this way.
|
||||
:::
|
||||
|
||||
### Installation with packages {#installation-with-packages}
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
xml:id="chap-language-support">
|
||||
<title>Languages and frameworks</title>
|
||||
<para>
|
||||
The <link linkend="chap-stdenv">standard build environment</link> makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accomodated by overriding the appropriate phases of <literal>stdenv</literal>. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
|
||||
The <link linkend="chap-stdenv">standard build environment</link> makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accommodated by overriding the appropriate phases of <literal>stdenv</literal>. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
|
||||
</para>
|
||||
<xi:include href="agda.section.xml" />
|
||||
<xi:include href="android.section.xml" />
|
||||
|
|
|
@ -605,7 +605,7 @@ been removed, in this case, it's recommended to use `pytestCheckHook`.
|
|||
`test` command for a `checkPhase` which runs `pytest`. This is also beneficial
|
||||
when a package may need many items disabled to run the test suite.
|
||||
|
||||
Using the example above, the analagous `pytestCheckHook` usage would be:
|
||||
Using the example above, the analogous `pytestCheckHook` usage would be:
|
||||
|
||||
```
|
||||
checkInputs = [ pytestCheckHook ];
|
||||
|
@ -624,7 +624,7 @@ Using the example above, the analagous `pytestCheckHook` usage would be:
|
|||
];
|
||||
```
|
||||
|
||||
This is expecially useful when tests need to be conditionally disabled,
|
||||
This is especially useful when tests need to be conditionally disabled,
|
||||
for example:
|
||||
|
||||
```
|
||||
|
|
|
@ -186,6 +186,23 @@ added. To find the correct hash, you can first use `lib.fakeSha256` or
|
|||
`lib.fakeHash` as a stub hash. Building the package (and thus the
|
||||
vendored dependencies) will then inform you of the correct hash.
|
||||
|
||||
For usage outside nixpkgs, `allowBuiltinFetchGit` could be used to
|
||||
avoid having to specify `outputHashes`. For example:
|
||||
|
||||
```nix
|
||||
rustPlatform.buildRustPackage rec {
|
||||
pname = "myproject";
|
||||
version = "1.0.0";
|
||||
|
||||
cargoLock = {
|
||||
lockFile = ./Cargo.lock;
|
||||
allowBuiltinFetchGit = true;
|
||||
};
|
||||
|
||||
# ...
|
||||
}
|
||||
```
|
||||
|
||||
### Cargo features {#cargo-features}
|
||||
|
||||
You can disable default features using `buildNoDefaultFeatures`, and
|
||||
|
@ -319,7 +336,7 @@ The above are just guidelines, and exceptions may be granted on a case-by-case b
|
|||
However, please check if it's possible to disable a problematic subset of the
|
||||
test suite and leave a comment explaining your reasoning.
|
||||
|
||||
This can be achived with `--skip` in `checkFlags`:
|
||||
This can be achieved with `--skip` in `checkFlags`:
|
||||
|
||||
```nix
|
||||
rustPlatform.buildRustPackage {
|
||||
|
|
2
third_party/nixpkgs/doc/old/cross.txt
vendored
2
third_party/nixpkgs/doc/old/cross.txt
vendored
|
@ -303,7 +303,7 @@ One of the compiler flags that GCC uses for this compiler is called X_CFLAGS.
|
|||
This is used by the Nix build process to set the dynamic linker, glibc
|
||||
in the case of i686-linux using the default Nix packages collection.
|
||||
|
||||
Obiously, since we need to compile libstc++ for arm-linux with uClibc linking
|
||||
Obviously, since we need to compile libstc++ for arm-linux with uClibc linking
|
||||
will not be done correctly: you can't link object files built for arm-linux
|
||||
with a glibc built for i686-linux.
|
||||
|
||||
|
|
|
@ -29,7 +29,7 @@ NixOS provides two ways to select the outputs to install for packages listed in
|
|||
`nix-env` lacks an easy way to select the outputs to install. When installing a package, `nix-env` always installs the outputs listed in `meta.outputsToInstall`, even when the user explicitly selects an output.
|
||||
|
||||
::: {.warning}
|
||||
`nix-env` silenty disregards the outputs selected by the user, and instead installs the outputs from `meta.outputsToInstall`. For example,
|
||||
`nix-env` silently disregards the outputs selected by the user, and instead installs the outputs from `meta.outputsToInstall`. For example,
|
||||
|
||||
```ShellSession
|
||||
$ nix-env -iA nixpkgs.coreutils.info
|
||||
|
|
|
@ -719,11 +719,11 @@ If set, libraries and executables are not stripped. By default, they are.
|
|||
|
||||
##### `dontStripHost` {#var-stdenv-dontStripHost}
|
||||
|
||||
Like `dontStrip`, but only affects the `strip` command targetting the package’s host platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
|
||||
Like `dontStrip`, but only affects the `strip` command targeting the package’s host platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
|
||||
|
||||
##### `dontStripTarget` {#var-stdenv-dontStripTarget}
|
||||
|
||||
Like `dontStrip`, but only affects the `strip` command targetting the packages’ target platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
|
||||
Like `dontStrip`, but only affects the `strip` command targeting the packages’ target platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
|
||||
|
||||
##### `dontMoveSbin` {#var-stdenv-dontMoveSbin}
|
||||
|
||||
|
|
|
@ -73,7 +73,7 @@ There are also two ways to try compiling a package which has been marked as unsu
|
|||
}
|
||||
```
|
||||
|
||||
The difference between a package being unsupported on some system and being broken is admittedly a bit fuzzy. If a program *ought* to work on a certain platform, but doesn't, the platform should be included in `meta.platforms`, but marked as broken with e.g. `meta.broken = !hostPlatform.isWindows`. Of course, this begs the question of what \"ought\" means exactly. That is left to the package maintainer.
|
||||
The difference between a package being unsupported on some system and being broken is admittedly a bit fuzzy. If a program *ought* to work on a certain platform, but doesn't, the platform should be included in `meta.platforms`, but marked as broken with e.g. `meta.broken = !hostPlatform.isWindows`. Of course, this begs the question of what "ought" means exactly. That is left to the package maintainer.
|
||||
|
||||
## Installing unfree packages {#sec-allow-unfree}
|
||||
|
||||
|
|
63
third_party/nixpkgs/lib/attrsets.nix
vendored
63
third_party/nixpkgs/lib/attrsets.nix
vendored
|
@ -16,6 +16,8 @@ rec {
|
|||
|
||||
Example:
|
||||
x = { a = { b = 3; }; }
|
||||
# ["a" "b"] is equivalent to x.a.b
|
||||
# 6 is a default value to return if the path does not exist in attrset
|
||||
attrByPath ["a" "b"] 6 x
|
||||
=> 3
|
||||
attrByPath ["z" "z"] 6 x
|
||||
|
@ -23,6 +25,7 @@ rec {
|
|||
|
||||
Type:
|
||||
attrByPath :: [String] -> Any -> AttrSet -> Any
|
||||
|
||||
*/
|
||||
attrByPath =
|
||||
# A list of strings representing the attribute path to return from `set`
|
||||
|
@ -96,7 +99,7 @@ rec {
|
|||
=> error: cannot find attribute `z.z'
|
||||
|
||||
Type:
|
||||
getAttrFromPath :: [String] -> AttrSet -> Value
|
||||
getAttrFromPath :: [String] -> AttrSet -> Any
|
||||
*/
|
||||
getAttrFromPath =
|
||||
# A list of strings representing the attribute path to get from `set`
|
||||
|
@ -109,10 +112,7 @@ rec {
|
|||
/* Map each attribute in the given set and merge them into a new attribute set.
|
||||
|
||||
Type:
|
||||
concatMapAttrs ::
|
||||
(String -> a -> AttrSet)
|
||||
-> AttrSet
|
||||
-> AttrSet
|
||||
concatMapAttrs :: (String -> a -> AttrSet) -> AttrSet -> AttrSet
|
||||
|
||||
Example:
|
||||
concatMapAttrs
|
||||
|
@ -168,8 +168,7 @@ rec {
|
|||
] { a.b.c = 0; }
|
||||
=> { a = { b = { d = 1; }; }; x = { y = "xy"; }; }
|
||||
|
||||
Type:
|
||||
updateManyAttrsByPath :: [AttrSet] -> AttrSet -> AttrSet
|
||||
Type: updateManyAttrsByPath :: [{ path :: [String], update :: (Any -> Any) }] -> AttrSet -> AttrSet
|
||||
*/
|
||||
updateManyAttrsByPath = let
|
||||
# When recursing into attributes, instead of updating the `path` of each
|
||||
|
@ -252,6 +251,7 @@ rec {
|
|||
Example:
|
||||
attrValues {c = 3; a = 1; b = 2;}
|
||||
=> [1 2 3]
|
||||
|
||||
Type:
|
||||
attrValues :: AttrSet -> [Any]
|
||||
*/
|
||||
|
@ -341,6 +341,7 @@ rec {
|
|||
|
||||
Type:
|
||||
foldAttrs :: (Any -> Any -> Any) -> Any -> [AttrSets] -> Any
|
||||
|
||||
*/
|
||||
foldAttrs =
|
||||
# A function, given a value and a collector combines the two.
|
||||
|
@ -394,7 +395,7 @@ rec {
|
|||
{ a = 2; b = 20; }
|
||||
]
|
||||
Type:
|
||||
cartesianProductOfSets :: AttrSet -> [AttrSet]
|
||||
cartesianProductOfSets :: AttrSet -> [AttrSet]
|
||||
*/
|
||||
cartesianProductOfSets =
|
||||
# Attribute set with attributes that are lists of values
|
||||
|
@ -413,7 +414,7 @@ rec {
|
|||
=> { name = "some"; value = 6; }
|
||||
|
||||
Type:
|
||||
nameValuePair :: String -> Any -> AttrSet
|
||||
nameValuePair :: String -> Any -> { name :: String, value :: Any }
|
||||
*/
|
||||
nameValuePair =
|
||||
# Attribute name
|
||||
|
@ -600,7 +601,7 @@ rec {
|
|||
=> { }
|
||||
|
||||
Type:
|
||||
optionalAttrs :: Bool -> AttrSet
|
||||
optionalAttrs :: Bool -> AttrSet -> AttrSet
|
||||
*/
|
||||
optionalAttrs =
|
||||
# Condition under which the `as` attribute set is returned.
|
||||
|
@ -646,7 +647,7 @@ rec {
|
|||
=> { a = ["x" "y"]; b = ["z"] }
|
||||
|
||||
Type:
|
||||
zipAttrsWith :: (String -> [ Any ] -> Any) -> [ AttrSet ] -> AttrSet
|
||||
zipAttrsWith :: (String -> [ Any ] -> Any) -> [ AttrSet ] -> AttrSet
|
||||
*/
|
||||
zipAttrsWith =
|
||||
builtins.zipAttrsWith or (f: sets: zipAttrsWithNames (concatMap attrNames sets) f sets);
|
||||
|
@ -737,7 +738,7 @@ rec {
|
|||
}
|
||||
|
||||
Type:
|
||||
recursiveUpdate :: AttrSet -> AttrSet -> AttrSet
|
||||
recursiveUpdate :: AttrSet -> AttrSet -> AttrSet
|
||||
*/
|
||||
recursiveUpdate =
|
||||
# Left attribute set of the merge.
|
||||
|
@ -757,7 +758,7 @@ rec {
|
|||
matchAttrs :: AttrSet -> AttrSet -> Bool
|
||||
*/
|
||||
matchAttrs =
|
||||
# Attribute set strucutre to match
|
||||
# Attribute set structure to match
|
||||
pattern:
|
||||
# Attribute set to find patterns in
|
||||
attrs:
|
||||
|
@ -795,6 +796,7 @@ rec {
|
|||
/* Turns a list of strings into a human-readable description of those
|
||||
strings represented as an attribute path. The result of this function is
|
||||
not intended to be machine-readable.
|
||||
Create a new attribute set with `value` set at the nested attribute location specified in `attrPath`.
|
||||
|
||||
Example:
|
||||
showAttrPath [ "foo" "10" "bar" ]
|
||||
|
@ -831,11 +833,11 @@ rec {
|
|||
If the output does not exist, fallback to `.out` and then to the default.
|
||||
|
||||
Example:
|
||||
getOutput pkgs.openssl
|
||||
getBin pkgs.openssl
|
||||
=> "/nix/store/9rz8gxhzf8sw4kf2j2f1grr49w8zx5vj-openssl-1.0.1r"
|
||||
|
||||
Type:
|
||||
getOutput :: Derivation -> String
|
||||
getBin :: Derivation -> String
|
||||
*/
|
||||
getBin = getOutput "bin";
|
||||
|
||||
|
@ -844,11 +846,11 @@ rec {
|
|||
If the output does not exist, fallback to `.out` and then to the default.
|
||||
|
||||
Example:
|
||||
getOutput pkgs.openssl
|
||||
getLib pkgs.openssl
|
||||
=> "/nix/store/9rz8gxhzf8sw4kf2j2f1grr49w8zx5vj-openssl-1.0.1r-lib"
|
||||
|
||||
Type:
|
||||
getOutput :: Derivation -> String
|
||||
getLib :: Derivation -> String
|
||||
*/
|
||||
getLib = getOutput "lib";
|
||||
|
||||
|
@ -857,11 +859,11 @@ rec {
|
|||
If the output does not exist, fallback to `.out` and then to the default.
|
||||
|
||||
Example:
|
||||
getOutput pkgs.openssl
|
||||
getDev pkgs.openssl
|
||||
=> "/nix/store/9rz8gxhzf8sw4kf2j2f1grr49w8zx5vj-openssl-1.0.1r-dev"
|
||||
|
||||
Type:
|
||||
getOutput :: Derivation -> String
|
||||
getDev :: Derivation -> String
|
||||
*/
|
||||
getDev = getOutput "dev";
|
||||
|
||||
|
@ -870,15 +872,19 @@ rec {
|
|||
If the output does not exist, fallback to `.out` and then to the default.
|
||||
|
||||
Example:
|
||||
getOutput pkgs.openssl
|
||||
getMan pkgs.openssl
|
||||
=> "/nix/store/9rz8gxhzf8sw4kf2j2f1grr49w8zx5vj-openssl-1.0.1r-man"
|
||||
|
||||
Type:
|
||||
getOutput :: Derivation -> String
|
||||
getMan :: Derivation -> String
|
||||
*/
|
||||
getMan = getOutput "man";
|
||||
|
||||
/* Pick the outputs of packages to place in `buildInputs` */
|
||||
/* Pick the outputs of packages to place in `buildInputs`
|
||||
|
||||
Type: chooseDevOutputs :: [Derivation] -> [String]
|
||||
|
||||
*/
|
||||
chooseDevOutputs =
|
||||
# List of packages to pick `dev` outputs from
|
||||
drvs:
|
||||
|
@ -900,6 +906,7 @@ rec {
|
|||
|
||||
Type:
|
||||
recurseIntoAttrs :: AttrSet -> AttrSet
|
||||
|
||||
*/
|
||||
recurseIntoAttrs =
|
||||
# An attribute set to scan for derivations.
|
||||
|
@ -909,7 +916,7 @@ rec {
|
|||
/* Undo the effect of recurseIntoAttrs.
|
||||
|
||||
Type:
|
||||
recurseIntoAttrs :: AttrSet -> AttrSet
|
||||
dontRecurseIntoAttrs :: AttrSet -> AttrSet
|
||||
*/
|
||||
dontRecurseIntoAttrs =
|
||||
# An attribute set to not scan for derivations.
|
||||
|
@ -919,7 +926,10 @@ rec {
|
|||
/* `unionOfDisjoint x y` is equal to `x // y // z` where the
|
||||
attrnames in `z` are the intersection of the attrnames in `x` and
|
||||
`y`, and all values `assert` with an error message. This
|
||||
operator is commutative, unlike (//). */
|
||||
operator is commutative, unlike (//).
|
||||
|
||||
Type: unionOfDisjoint :: AttrSet -> AttrSet -> AttrSet
|
||||
*/
|
||||
unionOfDisjoint = x: y:
|
||||
let
|
||||
intersection = builtins.intersectAttrs x y;
|
||||
|
@ -930,9 +940,10 @@ rec {
|
|||
in
|
||||
(x // y) // mask;
|
||||
|
||||
# deprecated
|
||||
# DEPRECATED
|
||||
zipWithNames = zipAttrsWithNames;
|
||||
# deprecated
|
||||
|
||||
# DEPRECATED
|
||||
zip = builtins.trace
|
||||
"lib.zip is deprecated, use lib.zipAttrsWith instead" zipAttrsWith;
|
||||
}
|
||||
|
|
2
third_party/nixpkgs/lib/derivations.nix
vendored
2
third_party/nixpkgs/lib/derivations.nix
vendored
|
@ -17,7 +17,7 @@ in
|
|||
situations below.
|
||||
|
||||
For illustration and/or testing, we define derivation such that its
|
||||
evaluation is very noticable.
|
||||
evaluation is very noticeable.
|
||||
|
||||
let derivation = throw "This won't be evaluated.";
|
||||
|
||||
|
|
5
third_party/nixpkgs/lib/generators.nix
vendored
5
third_party/nixpkgs/lib/generators.nix
vendored
|
@ -342,7 +342,10 @@ rec {
|
|||
else "{" + introSpace
|
||||
+ libStr.concatStringsSep introSpace (libAttr.mapAttrsToList
|
||||
(name: value:
|
||||
"${libStr.escapeNixIdentifier name} = ${go (indent + " ") value};") v)
|
||||
"${libStr.escapeNixIdentifier name} = ${
|
||||
builtins.addErrorContext "while evaluating an attribute `${name}`"
|
||||
(go (indent + " ") value)
|
||||
};") v)
|
||||
+ outroSpace + "}"
|
||||
else abort "generators.toPretty: should never happen (v = ${v})";
|
||||
in go "";
|
||||
|
|
5
third_party/nixpkgs/lib/licenses.nix
vendored
5
third_party/nixpkgs/lib/licenses.nix
vendored
|
@ -969,6 +969,11 @@ in mkLicense lset) ({
|
|||
fullName = "wxWindows Library Licence, Version 3.1";
|
||||
};
|
||||
|
||||
x11 = {
|
||||
spdxId = "X11";
|
||||
fullName = "X11 License";
|
||||
};
|
||||
|
||||
xfig = {
|
||||
fullName = "xfig";
|
||||
url = "http://mcj.sourceforge.net/authors.html#xfig"; # https is broken
|
||||
|
|
2
third_party/nixpkgs/lib/modules.nix
vendored
2
third_party/nixpkgs/lib/modules.nix
vendored
|
@ -479,7 +479,7 @@ rec {
|
|||
) (lib.functionArgs f);
|
||||
|
||||
# Note: we append in the opposite order such that we can add an error
|
||||
# context on the explicited arguments of "args" too. This update
|
||||
# context on the explicit arguments of "args" too. This update
|
||||
# operator is used to make the "args@{ ... }: with args.lib;" notation
|
||||
# works.
|
||||
in f (args // extraArgs)
|
||||
|
|
21
third_party/nixpkgs/lib/options.nix
vendored
21
third_party/nixpkgs/lib/options.nix
vendored
|
@ -104,8 +104,6 @@ rec {
|
|||
/* Creates an Option attribute set for an option that specifies the
|
||||
package a module should use for some purpose.
|
||||
|
||||
Type: mkPackageOption :: pkgs -> string -> { default :: [string], example :: null | string | [string] } -> option
|
||||
|
||||
The package is specified as a list of strings representing its attribute path in nixpkgs.
|
||||
|
||||
Because of this, you need to pass nixpkgs itself as the first argument.
|
||||
|
@ -116,6 +114,8 @@ rec {
|
|||
|
||||
You can omit the default path if the name of the option is also attribute path in nixpkgs.
|
||||
|
||||
Type: mkPackageOption :: pkgs -> string -> { default :: [string], example :: null | string | [string] } -> option
|
||||
|
||||
Example:
|
||||
mkPackageOption pkgs "hello" { }
|
||||
=> { _type = "option"; default = «derivation /nix/store/3r2vg51hlxj3cx5vscp0vkv60bqxkaq0-hello-2.10.drv»; defaultText = { ... }; description = "The hello package to use."; type = { ... }; }
|
||||
|
@ -221,9 +221,10 @@ rec {
|
|||
optionAttrSetToDocList' = _: options:
|
||||
concatMap (opt:
|
||||
let
|
||||
name = showOption opt.loc;
|
||||
docOption = rec {
|
||||
loc = opt.loc;
|
||||
name = showOption opt.loc;
|
||||
inherit name;
|
||||
description = opt.description or null;
|
||||
declarations = filter (x: x != unknownModule) opt.declarations;
|
||||
internal = opt.internal or false;
|
||||
|
@ -234,8 +235,18 @@ rec {
|
|||
readOnly = opt.readOnly or false;
|
||||
type = opt.type.description or "unspecified";
|
||||
}
|
||||
// optionalAttrs (opt ? example) { example = renderOptionValue opt.example; }
|
||||
// optionalAttrs (opt ? default) { default = renderOptionValue (opt.defaultText or opt.default); }
|
||||
// optionalAttrs (opt ? example) {
|
||||
example =
|
||||
builtins.addErrorContext "while evaluating the example of option `${name}`" (
|
||||
renderOptionValue opt.example
|
||||
);
|
||||
}
|
||||
// optionalAttrs (opt ? default) {
|
||||
default =
|
||||
builtins.addErrorContext "while evaluating the default value of option `${name}`" (
|
||||
renderOptionValue (opt.defaultText or opt.default)
|
||||
);
|
||||
}
|
||||
// optionalAttrs (opt ? relatedPackages && opt.relatedPackages != null) { inherit (opt) relatedPackages; };
|
||||
|
||||
subOptions =
|
||||
|
|
6
third_party/nixpkgs/lib/strings.nix
vendored
6
third_party/nixpkgs/lib/strings.nix
vendored
|
@ -185,7 +185,7 @@ rec {
|
|||
*/
|
||||
makeBinPath = makeSearchPathOutput "bin" "bin";
|
||||
|
||||
/* Normalize path, removing extranous /s
|
||||
/* Normalize path, removing extraneous /s
|
||||
|
||||
Type: normalizePath :: string -> string
|
||||
|
||||
|
@ -281,7 +281,7 @@ rec {
|
|||
=> [ ]
|
||||
stringToCharacters "abc"
|
||||
=> [ "a" "b" "c" ]
|
||||
stringToCharacters "💩"
|
||||
stringToCharacters "🦄"
|
||||
=> [ "<EFBFBD>" "<EFBFBD>" "<EFBFBD>" "<EFBFBD>" ]
|
||||
*/
|
||||
stringToCharacters = s:
|
||||
|
@ -330,7 +330,7 @@ rec {
|
|||
*/
|
||||
escape = list: replaceStrings list (map (c: "\\${c}") list);
|
||||
|
||||
/* Escape occurence of the element of `list` in `string` by
|
||||
/* Escape occurrence of the element of `list` in `string` by
|
||||
converting to its ASCII value and prefixing it with \\x.
|
||||
Only works for printable ascii characters.
|
||||
|
||||
|
|
|
@ -67,7 +67,7 @@ rec {
|
|||
#
|
||||
# Note:
|
||||
#
|
||||
# - The succesors of `skylake` (`cannonlake`, `icelake`, etc) use `avx512`
|
||||
# - The successors of `skylake` (`cannonlake`, `icelake`, etc) use `avx512`
|
||||
# which no current AMD Zen michroarch support.
|
||||
# - `znver1` uses `ABM`, `CLZERO`, `CX16`, `MWAITX`, and `SSE4A` which no
|
||||
# current Intel microarch support.
|
||||
|
|
4
third_party/nixpkgs/lib/systems/default.nix
vendored
4
third_party/nixpkgs/lib/systems/default.nix
vendored
|
@ -20,7 +20,7 @@ rec {
|
|||
# necessary.
|
||||
#
|
||||
# `parsed` is inferred from args, both because there are two options with one
|
||||
# clearly prefered, and to prevent cycles. A simpler fixed point where the RHS
|
||||
# clearly preferred, and to prevent cycles. A simpler fixed point where the RHS
|
||||
# always just used `final.*` would fail on both counts.
|
||||
elaborate = args': let
|
||||
args = if lib.isString args' then { system = args'; }
|
||||
|
@ -62,7 +62,7 @@ rec {
|
|||
linker =
|
||||
/**/ if final.useLLVM or false then "lld"
|
||||
else if final.isDarwin then "cctools"
|
||||
# "bfd" and "gold" both come from GNU binutils. The existance of Gold
|
||||
# "bfd" and "gold" both come from GNU binutils. The existence of Gold
|
||||
# is why we use the more obscure "bfd" and not "binutils" for this
|
||||
# choice.
|
||||
else "bfd";
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# See [RFC 46] for mandated platform support and ../../pkgs/stdenv for
|
||||
# implemented platform support. This list is mainly descriptive, i.e. all
|
||||
# system doubles for platforms where nixpkgs can do native compiliation
|
||||
# system doubles for platforms where nixpkgs can do native compilation
|
||||
# reasonably well are included.
|
||||
#
|
||||
# [RFC 46]: https://github.com/NixOS/rfcs/blob/master/rfcs/0046-platform-support-tiers.md
|
||||
|
|
15
third_party/nixpkgs/lib/tests/misc.nix
vendored
15
third_party/nixpkgs/lib/tests/misc.nix
vendored
|
@ -212,6 +212,21 @@ runTests {
|
|||
expected = [ "1" "2" "3" ];
|
||||
};
|
||||
|
||||
testPadVersionLess = {
|
||||
expr = versions.pad 3 "1.2";
|
||||
expected = "1.2.0";
|
||||
};
|
||||
|
||||
testPadVersionLessExtra = {
|
||||
expr = versions.pad 3 "1.3-rc1";
|
||||
expected = "1.3.0-rc1";
|
||||
};
|
||||
|
||||
testPadVersionMore = {
|
||||
expr = versions.pad 3 "1.2.3.4";
|
||||
expected = "1.2.3";
|
||||
};
|
||||
|
||||
testIsStorePath = {
|
||||
expr =
|
||||
let goodPath =
|
||||
|
|
2
third_party/nixpkgs/lib/tests/modules.sh
vendored
2
third_party/nixpkgs/lib/tests/modules.sh
vendored
|
@ -246,7 +246,7 @@ checkConfigError 'A definition for option .* is not of type .*' \
|
|||
## Freeform modules
|
||||
# Assigning without a declared option should work
|
||||
checkConfigOutput '^"24"$' config.value ./freeform-attrsOf.nix ./define-value-string.nix
|
||||
# No freeform assigments shouldn't make it error
|
||||
# No freeform assignments shouldn't make it error
|
||||
checkConfigOutput '^{ }$' config ./freeform-attrsOf.nix
|
||||
# but only if the type matches
|
||||
checkConfigError 'A definition for option .* is not of type .*' config.value ./freeform-attrsOf.nix ./define-value-list.nix
|
||||
|
|
9
third_party/nixpkgs/lib/types.nix
vendored
9
third_party/nixpkgs/lib/types.nix
vendored
|
@ -558,15 +558,6 @@ rec {
|
|||
nestedTypes.elemType = elemType;
|
||||
};
|
||||
|
||||
# TODO: drop this in the future:
|
||||
loaOf = elemType: types.attrsOf elemType // {
|
||||
name = "loaOf";
|
||||
deprecationMessage = "Mixing lists with attribute values is no longer"
|
||||
+ " possible; please use `types.attrsOf` instead. See"
|
||||
+ " https://github.com/NixOS/nixpkgs/issues/1800 for the motivation.";
|
||||
nestedTypes.elemType = elemType;
|
||||
};
|
||||
|
||||
# Value of given type but with no merging (i.e. `uniq list`s are not concatenated).
|
||||
uniq = elemType: mkOptionType rec {
|
||||
name = "uniq";
|
||||
|
|
15
third_party/nixpkgs/lib/versions.nix
vendored
15
third_party/nixpkgs/lib/versions.nix
vendored
|
@ -46,4 +46,19 @@ rec {
|
|||
builtins.concatStringsSep "."
|
||||
(lib.take 2 (splitVersion v));
|
||||
|
||||
/* Pad a version string with zeros to match the given number of components.
|
||||
|
||||
Example:
|
||||
pad 3 "1.2"
|
||||
=> "1.2.0"
|
||||
pad 3 "1.3-rc1"
|
||||
=> "1.3.0-rc1"
|
||||
pad 3 "1.2.3.4"
|
||||
=> "1.2.3"
|
||||
*/
|
||||
pad = n: version: let
|
||||
numericVersion = lib.head (lib.splitString "-" version);
|
||||
versionSuffix = lib.removePrefix numericVersion version;
|
||||
in lib.concatStringsSep "." (lib.take n (lib.splitVersion numericVersion ++ lib.genList (_: "0") n)) + versionSuffix;
|
||||
|
||||
}
|
||||
|
|
|
@ -186,6 +186,12 @@
|
|||
githubId = 7755101;
|
||||
name = "Aaron Andersen";
|
||||
};
|
||||
aaqaishtyaq = {
|
||||
email = "aaqaishtyaq@gmail.com";
|
||||
github = "aaqaishtyaq";
|
||||
githubId = 22131756;
|
||||
name = "Aaqa Ishtyaq";
|
||||
};
|
||||
aaronjanse = {
|
||||
email = "aaron@ajanse.me";
|
||||
matrix = "@aaronjanse:matrix.org";
|
||||
|
@ -552,6 +558,12 @@
|
|||
githubId = 43479487;
|
||||
name = "Titouan Biteau";
|
||||
};
|
||||
alekseysidorov = {
|
||||
email = "sauron1987@gmail.com";
|
||||
github = "alekseysidorov";
|
||||
githubId = 83360;
|
||||
name = "Aleksey Sidorov";
|
||||
};
|
||||
alerque = {
|
||||
email = "caleb@alerque.com";
|
||||
github = "alerque";
|
||||
|
@ -1474,12 +1486,12 @@
|
|||
}];
|
||||
};
|
||||
babariviere = {
|
||||
email = "babathriviere@gmail.com";
|
||||
email = "me@babariviere.com";
|
||||
github = "babariviere";
|
||||
githubId = 12128029;
|
||||
name = "Bastien Rivière";
|
||||
keys = [{
|
||||
fingerprint = "2F85 B362 B274 0012 37E2 81EE F202 AD3B 6EDF 4BD1";
|
||||
fingerprint = "74AA 9AB4 E6FF 872B 3C5A CB3E 3903 5CC0 B75D 1142";
|
||||
}];
|
||||
};
|
||||
babbaj = {
|
||||
|
@ -1695,6 +1707,15 @@
|
|||
fingerprint = "D35E C9CE E631 638F F1D8 B401 6F0E 410D C3EE D02";
|
||||
}];
|
||||
};
|
||||
benjaminedwardwebb = {
|
||||
name = "Ben Webb";
|
||||
email = "benjaminedwardwebb@gmail.com";
|
||||
github = "benjaminedwardwebb";
|
||||
githubId = 7118777;
|
||||
keys = [{
|
||||
fingerprint = "E9A3 7864 2165 28CE 507C CA82 72EA BF75 C331 CD25";
|
||||
}];
|
||||
};
|
||||
benley = {
|
||||
email = "benley@gmail.com";
|
||||
github = "benley";
|
||||
|
@ -1728,12 +1749,6 @@
|
|||
githubId = 442623;
|
||||
name = "Ben Pye";
|
||||
};
|
||||
benwbooth = {
|
||||
email = "benwbooth@gmail.com";
|
||||
github = "benwbooth";
|
||||
githubId = 75972;
|
||||
name = "Ben Booth";
|
||||
};
|
||||
berberman = {
|
||||
email = "berberman@yandex.com";
|
||||
matrix = "@berberman:mozilla.org";
|
||||
|
@ -3932,6 +3947,16 @@
|
|||
github = "edlimerkaj";
|
||||
githubId = 71988351;
|
||||
};
|
||||
edrex = {
|
||||
email = "ericdrex@gmail.com";
|
||||
github = "edrex";
|
||||
githubId = 14615;
|
||||
keys = [{
|
||||
fingerprint = "AC47 2CCC 9867 4644 A9CF EB28 1C5C 1ED0 9F66 6824";
|
||||
}];
|
||||
matrix = "@edrex:matrix.org";
|
||||
name = "Eric Drechsel";
|
||||
};
|
||||
ehllie = {
|
||||
email = "me@ehllie.xyz";
|
||||
github = "ehllie";
|
||||
|
@ -4132,6 +4157,12 @@
|
|||
githubId = 1365692;
|
||||
name = "Will Fancher";
|
||||
};
|
||||
emattiza = {
|
||||
email = "nix@mattiza.dev";
|
||||
github = "emattiza";
|
||||
githubId = 11719476;
|
||||
name = "Evan Mattiza";
|
||||
};
|
||||
emmabastas = {
|
||||
email = "emma.bastas@protonmail.com";
|
||||
matrix = "@emmabastas:matrix.org";
|
||||
|
@ -5167,6 +5198,15 @@
|
|||
githubId = 643494;
|
||||
name = "Cillian de Róiste";
|
||||
};
|
||||
GoldsteinE = {
|
||||
email = "root@goldstein.rs";
|
||||
github = "GoldsteinE";
|
||||
githubId = 12019211;
|
||||
name = "Maximilian Siling";
|
||||
keys = [{
|
||||
fingerprint = "0BAF 2D87 CB43 746F 6237 2D78 DE60 31AB A0BB 269A";
|
||||
}];
|
||||
};
|
||||
Gonzih = {
|
||||
email = "gonzih@gmail.com";
|
||||
github = "Gonzih";
|
||||
|
@ -5553,6 +5593,12 @@
|
|||
matrix = "@chris:netsoj.nl";
|
||||
name = "Chris Josten";
|
||||
};
|
||||
henkery = {
|
||||
email = "jim@reupload.nl";
|
||||
github = "henkery";
|
||||
githubId = 1923309;
|
||||
name = "Jim van Abkoude";
|
||||
};
|
||||
henrikolsson = {
|
||||
email = "henrik@fixme.se";
|
||||
github = "henrikolsson";
|
||||
|
@ -6053,6 +6099,12 @@
|
|||
githubId = 37965;
|
||||
name = "Léo Stefanesco";
|
||||
};
|
||||
indeednotjames = {
|
||||
email = "nix@indeednotjames.com";
|
||||
github = "IndeedNotJames";
|
||||
githubId = 55066419;
|
||||
name = "Emily Lange";
|
||||
};
|
||||
infinidoge = {
|
||||
name = "Infinidoge";
|
||||
email = "infinidoge@inx.moe";
|
||||
|
@ -8687,6 +8739,12 @@
|
|||
githubId = 322214;
|
||||
name = "Mathnerd314";
|
||||
};
|
||||
math-42 = {
|
||||
email = "matheus.4200@gmail.com";
|
||||
github = "Math-42";
|
||||
githubId = 43853194;
|
||||
name = "Matheus Vieira";
|
||||
};
|
||||
matklad = {
|
||||
email = "aleksey.kladov@gmail.com";
|
||||
github = "matklad";
|
||||
|
@ -11524,6 +11582,15 @@
|
|||
githubId = 131856;
|
||||
name = "Arnout Engelen";
|
||||
};
|
||||
rafael = {
|
||||
name = "Rafael";
|
||||
email = "pr9@tuta.io";
|
||||
github = "rafa-dot-el";
|
||||
githubId = 104688305;
|
||||
keys = [{
|
||||
fingerprint = "5F0B 3EAC F1F9 8155 0946 CDF5 469E 3255 A40D 2AD6";
|
||||
}];
|
||||
};
|
||||
RaghavSood = {
|
||||
email = "r@raghavsood.com";
|
||||
github = "RaghavSood";
|
||||
|
@ -12020,7 +12087,7 @@
|
|||
name = "Russell O'Connor";
|
||||
};
|
||||
rodrgz = {
|
||||
email = "rodrgz@proton.me";
|
||||
email = "erik@rodgz.com";
|
||||
github = "rodrgz";
|
||||
githubId = 53882428;
|
||||
name = "Erik Rodriguez";
|
||||
|
@ -15923,6 +15990,12 @@
|
|||
github = "kuwii";
|
||||
githubId = 10705175;
|
||||
};
|
||||
kkharji = {
|
||||
name = "kkharji";
|
||||
email = "kkharji@protonmail.com";
|
||||
github = "kkharji";
|
||||
githubId = 65782666;
|
||||
};
|
||||
melias122 = {
|
||||
name = "Martin Elias";
|
||||
email = "martin+nixpkgs@elias.sx";
|
||||
|
|
|
@ -415,7 +415,7 @@ printBuildSummary
|
|||
<> ["","*:arrow_heading_up:: The number of packages that depend (directly or indirectly) on this package (if any). If two numbers are shown the first (lower) number considers only packages which currently have enabled hydra jobs, i.e. are not marked broken. The second (higher) number considers all packages.*",""]
|
||||
<> footer
|
||||
where
|
||||
footer = ["*Report generated with [maintainers/scripts/haskell/hydra-report.hs](https://github.com/NixOS/nixpkgs/blob/haskell-updates/maintainers/scripts/haskell/hydra-report.sh)*"]
|
||||
footer = ["*Report generated with [maintainers/scripts/haskell/hydra-report.hs](https://github.com/NixOS/nixpkgs/blob/haskell-updates/maintainers/scripts/haskell/hydra-report.hs)*"]
|
||||
totals =
|
||||
[ "#### Build summary"
|
||||
, ""
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
#! /usr/bin/env nix-shell
|
||||
#! nix-shell -i bash -p coreutils nix gnused -I nixpkgs=.
|
||||
#! nix-shell -i bash -p coreutils jq nix -I nixpkgs=.
|
||||
|
||||
config_file=pkgs/development/haskell-modules/configuration-hackage2nix/transitive-broken.yaml
|
||||
|
||||
|
@ -12,4 +12,4 @@ dont-distribute-packages:
|
|||
EOF
|
||||
|
||||
echo "Regenerating list of transitive broken packages ..."
|
||||
echo -e $(nix-instantiate --eval --strict maintainers/scripts/haskell/transitive-broken-packages.nix) | sed 's/\"//' | LC_ALL=C.UTF-8 sort -i >> $config_file
|
||||
nix-instantiate --eval --option restrict-eval true -I . --strict --json maintainers/scripts/haskell/transitive-broken-packages.nix | jq -r . | LC_ALL=C.UTF-8 sort -i >> $config_file
|
||||
|
|
|
@ -12,5 +12,5 @@ let
|
|||
(getEvaluating (nixpkgs { config.allowBroken = true; }).haskellPackages);
|
||||
in
|
||||
''
|
||||
${lib.concatMapStringsSep "\n" (x: " - ${x}") brokenDeps}
|
||||
${lib.concatMapStringsSep "\n" (x: " - ${x}") brokenDeps}
|
||||
''
|
||||
|
|
|
@ -11,6 +11,7 @@ compat53,,,,0.7-1,,vcunat
|
|||
cosmo,,,,,,marsam
|
||||
coxpcall,,,,1.17.0-1,,
|
||||
cqueues,,,,,,vcunat
|
||||
cyan,,,,,,
|
||||
cyrussasl,https://github.com/JorjBauer/lua-cyrussasl.git,,,,,
|
||||
digestif,https://github.com/astoff/digestif.git,,,0.2-1,5.3,
|
||||
dkjson,,,,,,
|
||||
|
@ -99,6 +100,7 @@ sqlite,,,,,,
|
|||
std._debug,https://github.com/lua-stdlib/_debug.git,,,,,
|
||||
std.normalize,https://github.com/lua-stdlib/normalize.git,,,,,
|
||||
stdlib,,,,41.2.2,,vyp
|
||||
teal-language-server,,,http://luarocks.org/dev,,,
|
||||
tl,,,,,,mephistophiles
|
||||
vstruct,https://github.com/ToxicFrog/vstruct.git,,,,,
|
||||
vusted,,,,,,figsoda
|
||||
|
|
|
|
@ -755,6 +755,7 @@ with lib.maintainers; {
|
|||
xfce = {
|
||||
members = [
|
||||
romildo
|
||||
muscaln
|
||||
];
|
||||
scope = "Maintain Xfce desktop environment and related packages.";
|
||||
shortName = "Xfce";
|
||||
|
|
|
@ -75,7 +75,7 @@ necessary).
|
|||
|
||||
Packages in Nixpkgs sometimes provide systemd units with them, usually
|
||||
in e.g `#pkg-out#/lib/systemd/`. Putting such a package in
|
||||
`environment.systemPackages` doesn\'t make the service available to
|
||||
`environment.systemPackages` doesn't make the service available to
|
||||
users or the system.
|
||||
|
||||
In order to enable a systemd *system* service with provided upstream
|
||||
|
@ -87,9 +87,9 @@ systemd.packages = [ pkgs.packagekit ];
|
|||
|
||||
Usually NixOS modules written by the community do the above, plus take
|
||||
care of other details. If a module was written for a service you are
|
||||
interested in, you\'d probably need only to use
|
||||
interested in, you'd probably need only to use
|
||||
`services.#name#.enable = true;`. These services are defined in
|
||||
Nixpkgs\' [ `nixos/modules/` directory
|
||||
Nixpkgs' [ `nixos/modules/` directory
|
||||
](https://github.com/NixOS/nixpkgs/tree/master/nixos/modules). In case
|
||||
the service is simple enough, the above method should work, and start
|
||||
the service on boot.
|
||||
|
@ -98,8 +98,8 @@ the service on boot.
|
|||
differently. Given a package that has a systemd unit file at
|
||||
`#pkg-out#/lib/systemd/user/`, using [](#opt-systemd.packages) will
|
||||
make you able to start the service via `systemctl --user start`, but it
|
||||
won\'t start automatically on login. However, You can imperatively
|
||||
enable it by adding the package\'s attribute to
|
||||
won't start automatically on login. However, You can imperatively
|
||||
enable it by adding the package's attribute to
|
||||
[](#opt-systemd.packages) and then do this (e.g):
|
||||
|
||||
```ShellSession
|
||||
|
@ -113,7 +113,7 @@ If you are interested in a timer file, use `timers.target.wants` instead
|
|||
of `default.target.wants` in the 1st and 2nd command.
|
||||
|
||||
Using `systemctl --user enable syncthing.service` instead of the above,
|
||||
will work, but it\'ll use the absolute path of `syncthing.service` for
|
||||
will work, but it'll use the absolute path of `syncthing.service` for
|
||||
the symlink, and this path is in `/nix/store/.../lib/systemd/user/`.
|
||||
Hence [garbage collection](#sec-nix-gc) will remove that file and you
|
||||
will wind up with a broken symlink in your systemd configuration, which
|
||||
|
|
|
@ -17,7 +17,7 @@ services.kubernetes = {
|
|||
};
|
||||
```
|
||||
|
||||
Another way is to assign cluster roles (\"master\" and/or \"node\") to
|
||||
Another way is to assign cluster roles ("master" and/or "node") to
|
||||
the host. This enables apiserver, controllerManager, scheduler,
|
||||
addonManager, kube-proxy and etcd:
|
||||
|
||||
|
|
|
@ -82,61 +82,68 @@ boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 120;
|
|||
sets the kernel's TCP keepalive time to 120 seconds. To see the
|
||||
available parameters, run `sysctl -a`.
|
||||
|
||||
## Customize your kernel {#sec-linux-config-customizing}
|
||||
## Building a custom kernel {#sec-linux-config-customizing}
|
||||
|
||||
The first step before compiling the kernel is to generate an appropriate
|
||||
`.config` configuration. Either you pass your own config via the
|
||||
`configfile` setting of `linuxKernel.manualConfig`:
|
||||
You can customize the default kernel configuration by overriding the arguments for your kernel package:
|
||||
|
||||
```nix
|
||||
custom-kernel = let base_kernel = linuxKernel.kernels.linux_4_9;
|
||||
in super.linuxKernel.manualConfig {
|
||||
inherit (super) stdenv hostPlatform;
|
||||
inherit (base_kernel) src;
|
||||
version = "${base_kernel.version}-custom";
|
||||
|
||||
configfile = /home/me/my_kernel_config;
|
||||
allowImportFromDerivation = true;
|
||||
};
|
||||
```
|
||||
|
||||
You can edit the config with this snippet (by default `make
|
||||
menuconfig` won\'t work out of the box on nixos):
|
||||
|
||||
```ShellSession
|
||||
nix-shell -E 'with import <nixpkgs> {}; kernelToOverride.overrideAttrs (o: {nativeBuildInputs=o.nativeBuildInputs ++ [ pkg-config ncurses ];})'
|
||||
```
|
||||
|
||||
or you can let nixpkgs generate the configuration. Nixpkgs generates it
|
||||
via answering the interactive kernel utility `make config`. The answers
|
||||
depend on parameters passed to
|
||||
`pkgs/os-specific/linux/kernel/generic.nix` (which you can influence by
|
||||
overriding `extraConfig, autoModules,
|
||||
modDirVersion, preferBuiltin, extraConfig`).
|
||||
|
||||
```nix
|
||||
mptcp93.override ({
|
||||
name="mptcp-local";
|
||||
|
||||
pkgs.linux_latest.override {
|
||||
ignoreConfigErrors = true;
|
||||
autoModules = false;
|
||||
kernelPreferBuiltin = true;
|
||||
extraStructuredConfig = with lib.kernel; {
|
||||
DEBUG_KERNEL = yes;
|
||||
FRAME_POINTER = yes;
|
||||
KGDB = yes;
|
||||
KGDB_SERIAL_CONSOLE = yes;
|
||||
DEBUG_INFO = yes;
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
enableParallelBuilding = true;
|
||||
See `pkgs/os-specific/linux/kernel/generic.nix` for details on how these arguments
|
||||
affect the generated configuration. You can also build a custom version of Linux by calling
|
||||
`pkgs.buildLinux` directly, which requires the `src` and `version` arguments to be specified.
|
||||
|
||||
extraConfig = ''
|
||||
DEBUG_KERNEL y
|
||||
FRAME_POINTER y
|
||||
KGDB y
|
||||
KGDB_SERIAL_CONSOLE y
|
||||
DEBUG_INFO y
|
||||
'';
|
||||
});
|
||||
To use your custom kernel package in your NixOS configuration, set
|
||||
|
||||
```nix
|
||||
boot.kernelPackages = pkgs.linuxPackagesFor yourCustomKernel;
|
||||
```
|
||||
|
||||
Note that this method will use the common configuration defined in `pkgs/os-specific/linux/kernel/common-config.nix`,
|
||||
which is suitable for a NixOS system.
|
||||
|
||||
If you already have a generated configuration file, you can build a kernel that uses it with `pkgs.linuxManualConfig`:
|
||||
|
||||
```nix
|
||||
let
|
||||
baseKernel = pkgs.linux_latest;
|
||||
in pkgs.linuxManualConfig {
|
||||
inherit (baseKernel) src modDirVersion;
|
||||
version = "${baseKernel.version}-custom";
|
||||
configfile = ./my_kernel_config;
|
||||
allowImportFromDerivation = true;
|
||||
}
|
||||
```
|
||||
|
||||
::: {.note}
|
||||
The build will fail if `modDirVersion` does not match the source's `kernel.release` file,
|
||||
so `modDirVersion` should remain tied to `src`.
|
||||
:::
|
||||
|
||||
To edit the `.config` file for Linux X.Y, proceed as follows:
|
||||
|
||||
```ShellSession
|
||||
$ nix-shell '<nixpkgs>' -A linuxKernel.kernels.linux_X_Y.configEnv
|
||||
$ unpackPhase
|
||||
$ cd linux-*
|
||||
$ make nconfig
|
||||
```
|
||||
|
||||
## Developing kernel modules {#sec-linux-config-developing-modules}
|
||||
|
||||
When developing kernel modules it\'s often convenient to run
|
||||
When developing kernel modules it's often convenient to run
|
||||
edit-compile-run loop as quickly as possible. See below snippet as an
|
||||
example of developing `mellanox` drivers.
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
In some cases, it may be desirable to take advantage of commonly-used,
|
||||
predefined configurations provided by nixpkgs, but different from those
|
||||
that come as default. This is a role fulfilled by NixOS\'s Profiles,
|
||||
that come as default. This is a role fulfilled by NixOS's Profiles,
|
||||
which come as files living in `<nixpkgs/nixos/modules/profiles>`. That
|
||||
is to say, expected usage is to add them to the imports list of your
|
||||
`/etc/configuration.nix` as such:
|
||||
|
|
|
@ -7,7 +7,7 @@ This includes a hardened kernel, and limiting the system information
|
|||
available to processes through the `/sys` and
|
||||
`/proc` filesystems. It also disables the User Namespaces
|
||||
feature of the kernel, which stops Nix from being able to build anything
|
||||
(this particular setting can be overriden via
|
||||
(this particular setting can be overridden via
|
||||
[](#opt-security.allowUserNamespaces)). See the
|
||||
[profile source](https://github.com/nixos/nixpkgs/tree/master/nixos/modules/profiles/hardened.nix)
|
||||
for further detail on which settings are altered.
|
||||
|
|
|
@ -30,7 +30,7 @@ to your NixOS configuration. For instance, if you remove a user from
|
|||
[](#opt-users.users) and run nixos-rebuild, the user
|
||||
account will cease to exist. Also, imperative commands for managing users and
|
||||
groups, such as useradd, are no longer available. Passwords may still be
|
||||
assigned by setting the user\'s
|
||||
assigned by setting the user's
|
||||
[hashedPassword](#opt-users.users._name_.hashedPassword) option. A
|
||||
hashed password can be generated using `mkpasswd`.
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@ While X11 (see [](#sec-x11)) is still the primary display technology
|
|||
on NixOS, Wayland support is steadily improving. Where X11 separates the
|
||||
X Server and the window manager, on Wayland those are combined: a
|
||||
Wayland Compositor is like an X11 window manager, but also embeds the
|
||||
Wayland \'Server\' functionality. This means it is sufficient to install
|
||||
Wayland 'Server' functionality. This means it is sufficient to install
|
||||
a Wayland Compositor such as sway without separately enabling a Wayland
|
||||
server:
|
||||
|
||||
|
|
|
@ -81,7 +81,7 @@ second password to login can be redundant.
|
|||
|
||||
To enable auto-login, you need to define your default window manager and
|
||||
desktop environment. If you wanted no desktop environment and i3 as your
|
||||
your window manager, you\'d define:
|
||||
your window manager, you'd define:
|
||||
|
||||
```nix
|
||||
services.xserver.displayManager.defaultSession = "none+i3";
|
||||
|
@ -110,7 +110,7 @@ maintained but may perform worse in some cases (like in old chipsets).
|
|||
|
||||
The second driver, `intel`, is specific to Intel GPUs, but not
|
||||
recommended by most distributions: it lacks several modern features (for
|
||||
example, it doesn\'t support Glamor) and the package hasn\'t been
|
||||
example, it doesn't support Glamor) and the package hasn't been
|
||||
officially updated since 2015.
|
||||
|
||||
The results vary depending on the hardware, so you may have to try both
|
||||
|
@ -162,7 +162,7 @@ with other kernel modules.
|
|||
|
||||
AMD provides a proprietary driver for its graphics cards that is not
|
||||
enabled by default because it's not Free Software, is often broken in
|
||||
nixpkgs and as of this writing doesn\'t offer more features or
|
||||
nixpkgs and as of this writing doesn't offer more features or
|
||||
performance. If you still want to use it anyway, you need to explicitly
|
||||
set:
|
||||
|
||||
|
@ -215,7 +215,7 @@ US layout, with an additional layer to type some greek symbols by
|
|||
pressing the right-alt key.
|
||||
|
||||
Create a file called `us-greek` with the following content (under a
|
||||
directory called `symbols`; it\'s an XKB peculiarity that will help with
|
||||
directory called `symbols`; it's an XKB peculiarity that will help with
|
||||
testing):
|
||||
|
||||
```nix
|
||||
|
@ -249,7 +249,7 @@ The name (after `extraLayouts.`) should match the one given to the
|
|||
|
||||
Applying this customization requires rebuilding several packages, and a
|
||||
broken XKB file can lead to the X session crashing at login. Therefore,
|
||||
you\'re strongly advised to **test your layout before applying it**:
|
||||
you're strongly advised to **test your layout before applying it**:
|
||||
|
||||
```ShellSession
|
||||
$ nix-shell -p xorg.xkbcomp
|
||||
|
@ -313,8 +313,8 @@ prefer to keep the layout definitions inside the NixOS configuration.
|
|||
|
||||
Unfortunately, the Xorg server does not (currently) support setting a
|
||||
keymap directly but relies instead on XKB rules to select the matching
|
||||
components (keycodes, types, \...) of a layout. This means that
|
||||
components other than symbols won\'t be loaded by default. As a
|
||||
components (keycodes, types, ...) of a layout. This means that
|
||||
components other than symbols won't be loaded by default. As a
|
||||
workaround, you can set the keymap using `setxkbmap` at the start of the
|
||||
session with:
|
||||
|
||||
|
@ -323,7 +323,7 @@ services.xserver.displayManager.sessionCommands = "setxkbmap -keycodes media";
|
|||
```
|
||||
|
||||
If you are manually starting the X server, you should set the argument
|
||||
`-xkbdir /etc/X11/xkb`, otherwise X won\'t find your layout files. For
|
||||
`-xkbdir /etc/X11/xkb`, otherwise X won't find your layout files. For
|
||||
example with `xinit` run
|
||||
|
||||
```ShellSession
|
||||
|
|
|
@ -31,8 +31,8 @@ enabled. To enable Thunar without enabling Xfce, use the configuration
|
|||
option [](#opt-programs.thunar.enable) instead of simply adding
|
||||
`pkgs.xfce.thunar` to [](#opt-environment.systemPackages).
|
||||
|
||||
If you\'d like to add extra plugins to Thunar, add them to
|
||||
[](#opt-programs.thunar.plugins). You shouldn\'t just add them to
|
||||
If you'd like to add extra plugins to Thunar, add them to
|
||||
[](#opt-programs.thunar.plugins). You shouldn't just add them to
|
||||
[](#opt-environment.systemPackages).
|
||||
|
||||
## Troubleshooting {#sec-xfce-troubleshooting .unnumbered}
|
||||
|
@ -46,7 +46,7 @@ Thunar:2410): GVFS-RemoteVolumeMonitor-WARNING **: remote volume monitor with db
|
|||
```
|
||||
|
||||
This is caused by some needed GNOME services not running. This is all
|
||||
fixed by enabling \"Launch GNOME services on startup\" in the Advanced
|
||||
fixed by enabling "Launch GNOME services on startup" in the Advanced
|
||||
tab of the Session and Startup settings panel. Alternatively, you can
|
||||
run this command to do the same thing.
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Contributing to this manual {#chap-contributing}
|
||||
|
||||
The DocBook and CommonMark sources of NixOS' manual are in the [nixos/doc/manual](https://github.com/NixOS/nixpkgs/tree/master/nixos/doc/manual) subdirectory of the [Nixpkgs](https://github.com/NixOS/nixpkgs) repository.
|
||||
The [DocBook] and CommonMark sources of the NixOS manual are in the [nixos/doc/manual](https://github.com/NixOS/nixpkgs/tree/master/nixos/doc/manual) subdirectory of the [Nixpkgs](https://github.com/NixOS/nixpkgs) repository.
|
||||
|
||||
You can quickly check your edits with the following:
|
||||
|
||||
|
@ -11,3 +11,25 @@ $ nix-build nixos/release.nix -A manual.x86_64-linux
|
|||
```
|
||||
|
||||
If the build succeeds, the manual will be in `./result/share/doc/nixos/index.html`.
|
||||
|
||||
**Contributing to the man pages**
|
||||
|
||||
The man pages are written in [DocBook] which is XML.
|
||||
|
||||
To see what your edits look like:
|
||||
|
||||
```ShellSession
|
||||
$ cd /path/to/nixpkgs
|
||||
$ nix-build nixos/release.nix -A manpages.x86_64-linux
|
||||
```
|
||||
|
||||
You can then read the man page you edited by running
|
||||
|
||||
```ShellSession
|
||||
$ man --manpath=result/share/man nixos-rebuild # Replace nixos-rebuild with the command whose manual you edited
|
||||
```
|
||||
|
||||
If you're on a different architecture that's supported by NixOS (check nixos/release.nix) then replace `x86_64-linux` with the architecture.
|
||||
`nix-build` will complain otherwise, but should also tell you which architecture you have + the supported ones.
|
||||
|
||||
[DocBook]: https://en.wikipedia.org/wiki/DocBook
|
||||
|
|
|
@ -34,7 +34,7 @@ read which is set to `dry-activate` when a dry activation is done.
|
|||
|
||||
An activation script can write to special files instructing
|
||||
`switch-to-configuration` to restart/reload units. The script will take these
|
||||
requests into account and will incorperate the unit configuration as described
|
||||
requests into account and will incorporate the unit configuration as described
|
||||
above. This means that the activation script will "fake" a modified unit file
|
||||
and `switch-to-configuration` will act accordingly. By doing so, configuration
|
||||
like [systemd.services.\<name\>.restartIfChanged](#opt-systemd.services) is
|
||||
|
@ -49,7 +49,7 @@ dry activation being `/run/nixos/dry-activation-restart-list` and
|
|||
`/run/nixos/dry-activation-reload-list`. Those files can contain
|
||||
newline-separated lists of unit names where duplicates are being ignored. These
|
||||
files are not create automatically and activation scripts must take the
|
||||
possiblility into account that they have to create them first.
|
||||
possibility into account that they have to create them first.
|
||||
|
||||
## NixOS snippets {#sec-activation-script-nixos-snippets}
|
||||
|
||||
|
|
|
@ -149,7 +149,7 @@ multiple modules, or as an alternative to related `enable` options.
|
|||
|
||||
As an example, we will take the case of display managers. There is a
|
||||
central display manager module for generic display manager options and a
|
||||
module file per display manager backend (sddm, gdm \...).
|
||||
module file per display manager backend (sddm, gdm ...).
|
||||
|
||||
There are two approaches we could take with this module structure:
|
||||
|
||||
|
|
|
@ -92,11 +92,11 @@ merging is handled.
|
|||
: A free-form attribute set.
|
||||
|
||||
::: {.warning}
|
||||
This type will be deprecated in the future because it doesn\'t
|
||||
This type will be deprecated in the future because it doesn't
|
||||
recurse into attribute sets, silently drops earlier attribute
|
||||
definitions, and doesn\'t discharge `lib.mkDefault`, `lib.mkIf`
|
||||
definitions, and doesn't discharge `lib.mkDefault`, `lib.mkIf`
|
||||
and co. For allowing arbitrary attribute sets, prefer
|
||||
`types.attrsOf types.anything` instead which doesn\'t have these
|
||||
`types.attrsOf types.anything` instead which doesn't have these
|
||||
problems.
|
||||
:::
|
||||
|
||||
|
@ -222,7 +222,7 @@ Submodules are detailed in [Submodule](#section-option-types-submodule).
|
|||
- *`specialArgs`* An attribute set of extra arguments to be passed
|
||||
to the module functions. The option `_module.args` should be
|
||||
used instead for most arguments since it allows overriding.
|
||||
*`specialArgs`* should only be used for arguments that can\'t go
|
||||
*`specialArgs`* should only be used for arguments that can't go
|
||||
through the module fixed-point, because of infinite recursion or
|
||||
other problems. An example is overriding the `lib` argument,
|
||||
because `lib` itself is used to define `_module.args`, which
|
||||
|
@ -236,7 +236,7 @@ Submodules are detailed in [Submodule](#section-option-types-submodule).
|
|||
In such a case it would allow the option to be set with
|
||||
`the-submodule.config = "value"` instead of requiring
|
||||
`the-submodule.config.config = "value"`. This is because
|
||||
only when modules *don\'t* set the `config` or `options`
|
||||
only when modules *don't* set the `config` or `options`
|
||||
keys, all keys are interpreted as option definitions in the
|
||||
`config` section. Enabling this option implicitly puts all
|
||||
attributes in the `config` section.
|
||||
|
@ -324,7 +324,7 @@ Composed types are types that take a type as parameter. `listOf
|
|||
: Type *`t1`* or type *`t2`*, e.g. `with types; either int str`.
|
||||
Multiple definitions cannot be merged.
|
||||
|
||||
`types.oneOf` \[ *`t1 t2`* \... \]
|
||||
`types.oneOf` \[ *`t1 t2`* ... \]
|
||||
|
||||
: Type *`t1`* or type *`t2`* and so forth, e.g.
|
||||
`with types; oneOf [ int str bool ]`. Multiple definitions cannot be
|
||||
|
@ -345,7 +345,7 @@ that are handled like a separate module.
|
|||
It takes a parameter *`o`*, that should be a set, or a function returning
|
||||
a set with an `options` key defining the sub-options. Submodule option
|
||||
definitions are type-checked accordingly to the `options` declarations.
|
||||
Of course, you can nest submodule option definitons for even higher
|
||||
Of course, you can nest submodule option definitions for even higher
|
||||
modularity.
|
||||
|
||||
The option set can be defined directly
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
Modules that are imported can also be disabled. The option declarations,
|
||||
config implementation and the imports of a disabled module will be
|
||||
ignored, allowing another to take it\'s place. This can be used to
|
||||
ignored, allowing another to take its place. This can be used to
|
||||
import a set of modules from another channel while keeping the rest of
|
||||
the system on a stable release.
|
||||
|
||||
|
@ -14,7 +14,7 @@ relative to the modules path (eg. \<nixpkgs/nixos/modules> for nixos).
|
|||
This example will replace the existing postgresql module with the
|
||||
version defined in the nixos-unstable channel while keeping the rest of
|
||||
the modules and packages from the original nixos channel. This only
|
||||
overrides the module definition, this won\'t use postgresql from
|
||||
overrides the module definition, this won't use postgresql from
|
||||
nixos-unstable unless explicitly configured to do so.
|
||||
|
||||
```nix
|
||||
|
@ -35,7 +35,7 @@ nixos-unstable unless explicitly configured to do so.
|
|||
|
||||
This example shows how to define a custom module as a replacement for an
|
||||
existing module. Importing this module will disable the original module
|
||||
without having to know it\'s implementation details.
|
||||
without having to know its implementation details.
|
||||
|
||||
```nix
|
||||
{ config, lib, pkgs, ... }:
|
||||
|
|
|
@ -9,10 +9,10 @@ can be declared. File formats can be separated into two categories:
|
|||
`{ foo = { bar = 10; }; }`. Other examples are INI, YAML and TOML.
|
||||
The following section explains the convention for these settings.
|
||||
|
||||
- Non-nix-representable ones: These can\'t be trivially mapped to a
|
||||
- Non-nix-representable ones: These can't be trivially mapped to a
|
||||
subset of Nix syntax. Most generic programming languages are in this
|
||||
group, e.g. bash, since the statement `if true; then echo hi; fi`
|
||||
doesn\'t have a trivial representation in Nix.
|
||||
doesn't have a trivial representation in Nix.
|
||||
|
||||
Currently there are no fixed conventions for these, but it is common
|
||||
to have a `configFile` option for setting the configuration file
|
||||
|
@ -24,7 +24,7 @@ can be declared. File formats can be separated into two categories:
|
|||
an `extraConfig` option of type `lines` to allow arbitrary text
|
||||
after the autogenerated part of the file.
|
||||
|
||||
## Nix-representable Formats (JSON, YAML, TOML, INI, \...) {#sec-settings-nix-representable}
|
||||
## Nix-representable Formats (JSON, YAML, TOML, INI, ...) {#sec-settings-nix-representable}
|
||||
|
||||
By convention, formats like this are handled with a generic `settings`
|
||||
option, representing the full program configuration as a Nix value. The
|
||||
|
|
|
@ -19,7 +19,7 @@ $ nix-shell
|
|||
nix-shell$ make
|
||||
```
|
||||
|
||||
Once you are done making modifications to the manual, it\'s important to
|
||||
Once you are done making modifications to the manual, it's important to
|
||||
build it before committing. You can do that as follows:
|
||||
|
||||
```ShellSession
|
||||
|
|
|
@ -71,7 +71,7 @@ The meaning of each part is as follows.
|
|||
- This `imports` list enumerates the paths to other NixOS modules that
|
||||
should be included in the evaluation of the system configuration. A
|
||||
default set of modules is defined in the file `modules/module-list.nix`.
|
||||
These don\'t need to be added in the import list.
|
||||
These don't need to be added in the import list.
|
||||
|
||||
- The attribute `options` is a nested set of *option declarations*
|
||||
(described below).
|
||||
|
|
|
@ -165,7 +165,7 @@ The following methods are available on machine objects:
|
|||
`get_screen_text_variants`
|
||||
|
||||
: Return a list of different interpretations of what is currently
|
||||
visible on the machine\'s screen using optical character
|
||||
visible on the machine's screen using optical character
|
||||
recognition. The number and order of the interpretations is not
|
||||
specified and is subject to change, but if no exception is raised at
|
||||
least one will be returned.
|
||||
|
@ -177,7 +177,7 @@ The following methods are available on machine objects:
|
|||
`get_screen_text`
|
||||
|
||||
: Return a textual representation of what is currently visible on the
|
||||
machine\'s screen using optical character recognition.
|
||||
machine's screen using optical character recognition.
|
||||
|
||||
::: {.note}
|
||||
This requires [`enableOCR`](#test-opt-enableOCR) to be set to `true`.
|
||||
|
@ -298,7 +298,7 @@ The following methods are available on machine objects:
|
|||
|
||||
: Wait until the supplied regular expressions match a line of the
|
||||
serial console output. This method is useful when OCR is not
|
||||
possibile or accurate enough.
|
||||
possible or accurate enough.
|
||||
|
||||
`wait_for_window`
|
||||
|
||||
|
@ -350,8 +350,8 @@ machine.wait_for_unit("xautolock.service", "x-session-user")
|
|||
This applies to `systemctl`, `get_unit_info`, `wait_for_unit`,
|
||||
`start_job` and `stop_job`.
|
||||
|
||||
For faster dev cycles it\'s also possible to disable the code-linters
|
||||
(this shouldn\'t be commited though):
|
||||
For faster dev cycles it's also possible to disable the code-linters
|
||||
(this shouldn't be committed though):
|
||||
|
||||
```nix
|
||||
{
|
||||
|
@ -370,7 +370,7 @@ For faster dev cycles it\'s also possible to disable the code-linters
|
|||
|
||||
This will produce a Nix warning at evaluation time. To fully disable the
|
||||
linter, wrap the test script in comment directives to disable the Black
|
||||
linter directly (again, don\'t commit this within the Nixpkgs
|
||||
linter directly (again, don't commit this within the Nixpkgs
|
||||
repository):
|
||||
|
||||
```nix
|
||||
|
|
|
@ -23,7 +23,7 @@ $ nix-collect-garbage
|
|||
this unit automatically at certain points in time, for instance,
|
||||
every night at 03:15:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
nix.gc.automatic = true;
|
||||
nix.gc.dates = "03:15";
|
||||
</programlisting>
|
||||
|
|
|
@ -31,7 +31,7 @@ $ ping -c1 10.233.4.2
|
|||
address. This can be accomplished using the following configuration
|
||||
on the host:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.nat.enable = true;
|
||||
networking.nat.internalInterfaces = ["ve-+"];
|
||||
networking.nat.externalInterface = "eth0";
|
||||
|
@ -45,7 +45,7 @@ networking.nat.externalInterface = "eth0";
|
|||
If you are using Network Manager, you need to explicitly prevent it
|
||||
from managing container interfaces:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.networkmanager.unmanaged = [ "interface-name:ve-*" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
|
|
@ -42,7 +42,7 @@ $ systemd-cgls
|
|||
process would get 1/1001 of the cgroup’s CPU time.) You can limit a
|
||||
service’s CPU share in <literal>configuration.nix</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
systemd.services.httpd.serviceConfig.CPUShares = 512;
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -57,7 +57,7 @@ systemd.services.httpd.serviceConfig.CPUShares = 512;
|
|||
<literal>configuration.nix</literal>; for instance, to limit
|
||||
<literal>httpd.service</literal> to 512 MiB of RAM (excluding swap):
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
systemd.services.httpd.serviceConfig.MemoryLimit = "512M";
|
||||
</programlisting>
|
||||
<para>
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
following specifies that there shall be a container named
|
||||
<literal>database</literal> running PostgreSQL:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
containers.database =
|
||||
{ config =
|
||||
{ config, pkgs, ... }:
|
||||
|
@ -29,7 +29,7 @@ containers.database =
|
|||
However, they cannot change the network configuration. You can give
|
||||
a container its own network as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
containers.database = {
|
||||
privateNetwork = true;
|
||||
hostAddress = "192.168.100.10";
|
||||
|
|
|
@ -85,21 +85,21 @@ Jan 07 15:55:57 hagbard systemd[1]: Started PostgreSQL Server.
|
|||
Packages in Nixpkgs sometimes provide systemd units with them,
|
||||
usually in e.g <literal>#pkg-out#/lib/systemd/</literal>. Putting
|
||||
such a package in <literal>environment.systemPackages</literal>
|
||||
doesn't make the service available to users or the system.
|
||||
doesn’t make the service available to users or the system.
|
||||
</para>
|
||||
<para>
|
||||
In order to enable a systemd <emphasis>system</emphasis> service
|
||||
with provided upstream package, use (e.g):
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
systemd.packages = [ pkgs.packagekit ];
|
||||
</programlisting>
|
||||
<para>
|
||||
Usually NixOS modules written by the community do the above, plus
|
||||
take care of other details. If a module was written for a service
|
||||
you are interested in, you'd probably need only to use
|
||||
you are interested in, you’d probably need only to use
|
||||
<literal>services.#name#.enable = true;</literal>. These services
|
||||
are defined in Nixpkgs'
|
||||
are defined in Nixpkgs’
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/tree/master/nixos/modules">
|
||||
<literal>nixos/modules/</literal> directory </link>. In case the
|
||||
service is simple enough, the above method should work, and start
|
||||
|
@ -111,8 +111,8 @@ systemd.packages = [ pkgs.packagekit ];
|
|||
unit file at <literal>#pkg-out#/lib/systemd/user/</literal>, using
|
||||
<xref linkend="opt-systemd.packages" /> will make you able to
|
||||
start the service via <literal>systemctl --user start</literal>,
|
||||
but it won't start automatically on login. However, You can
|
||||
imperatively enable it by adding the package's attribute to
|
||||
but it won’t start automatically on login. However, You can
|
||||
imperatively enable it by adding the package’s attribute to
|
||||
<xref linkend="opt-systemd.packages" /> and then do this (e.g):
|
||||
</para>
|
||||
<programlisting>
|
||||
|
@ -129,7 +129,7 @@ $ systemctl --user enable syncthing.service
|
|||
</para>
|
||||
<para>
|
||||
Using <literal>systemctl --user enable syncthing.service</literal>
|
||||
instead of the above, will work, but it'll use the absolute path
|
||||
instead of the above, will work, but it’ll use the absolute path
|
||||
of <literal>syncthing.service</literal> for the symlink, and this
|
||||
path is in <literal>/nix/store/.../lib/systemd/user/</literal>.
|
||||
Hence <link linkend="sec-nix-gc">garbage collection</link> will
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
If you find yourself repeating yourself over and over, it’s time to
|
||||
abstract. Take, for instance, this Apache HTTP Server configuration:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.httpd.virtualHosts =
|
||||
{ "blog.example.org" = {
|
||||
|
@ -29,7 +29,7 @@
|
|||
the only difference is the document root directories. To prevent
|
||||
this duplication, we can use a <literal>let</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
let
|
||||
commonConfig =
|
||||
{ adminAddr = "alice@example.org";
|
||||
|
@ -55,7 +55,7 @@ in
|
|||
You can write a <literal>let</literal> wherever an expression is
|
||||
allowed. Thus, you also could have written:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.httpd.virtualHosts =
|
||||
let commonConfig = ...; in
|
||||
|
@ -74,7 +74,7 @@ in
|
|||
of different virtual hosts, all with identical configuration except
|
||||
for the document root. This can be done as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
services.httpd.virtualHosts =
|
||||
let
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
network configuration not covered by the existing NixOS modules. For
|
||||
instance, to statically configure an IPv6 address:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.localCommands =
|
||||
''
|
||||
ip -6 addr add 2001:610:685:1::1/64 dev eth0
|
||||
|
|
|
@ -28,7 +28,7 @@ $ cd nixpkgs
|
|||
manual. Finally, you add it to
|
||||
<xref linkend="opt-environment.systemPackages" />, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages = [ pkgs.my-package ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -45,7 +45,7 @@ environment.systemPackages = [ pkgs.my-package ];
|
|||
Hello</link> package directly in
|
||||
<literal>configuration.nix</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages =
|
||||
let
|
||||
my-hello = with pkgs; stdenv.mkDerivation rec {
|
||||
|
@ -62,13 +62,13 @@ environment.systemPackages =
|
|||
Of course, you can also move the definition of
|
||||
<literal>my-hello</literal> into a separate Nix expression, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages = [ (import ./my-hello.nix) ];
|
||||
</programlisting>
|
||||
<para>
|
||||
where <literal>my-hello.nix</literal> contains:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
with import <nixpkgs> {}; # bring all of Nixpkgs into scope
|
||||
|
||||
stdenv.mkDerivation rec {
|
||||
|
@ -98,7 +98,7 @@ Hello, world!
|
|||
need to install <literal>appimage-run</literal>: add to
|
||||
<literal>/etc/nixos/configuration.nix</literal>
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages = [ pkgs.appimage-run ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
<para>
|
||||
The NixOS configuration file generally looks like this:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{ option definitions
|
||||
|
@ -21,7 +21,7 @@
|
|||
the name of an option and <literal>value</literal> is its value. For
|
||||
example,
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{ services.httpd.enable = true;
|
||||
|
@ -44,7 +44,7 @@
|
|||
<literal>true</literal>. This means that the example above can also
|
||||
be written as:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{ services = {
|
||||
|
@ -96,7 +96,7 @@ The option value `services.httpd.enable' in `/etc/nixos/configuration.nix' is no
|
|||
<para>
|
||||
Strings are enclosed in double quotes, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.hostName = "dexter";
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -107,7 +107,7 @@ networking.hostName = "dexter";
|
|||
Multi-line strings can be enclosed in <emphasis>double single
|
||||
quotes</emphasis>, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.extraHosts =
|
||||
''
|
||||
127.0.0.2 other-localhost
|
||||
|
@ -135,7 +135,7 @@ networking.extraHosts =
|
|||
These can be <literal>true</literal> or
|
||||
<literal>false</literal>, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.firewall.enable = true;
|
||||
networking.firewall.allowPing = false;
|
||||
</programlisting>
|
||||
|
@ -149,7 +149,7 @@ networking.firewall.allowPing = false;
|
|||
<para>
|
||||
For example,
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 60;
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -171,7 +171,7 @@ boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 60;
|
|||
Sets were introduced above. They are name/value pairs enclosed
|
||||
in braces, as in the option definition
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
fileSystems."/boot" =
|
||||
{ device = "/dev/sda1";
|
||||
fsType = "ext4";
|
||||
|
@ -189,13 +189,13 @@ fileSystems."/boot" =
|
|||
The important thing to note about lists is that list elements
|
||||
are separated by whitespace, like this:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernelModules = [ "fuse" "kvm-intel" "coretemp" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
List elements can be any other type, e.g. sets:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
|
||||
</programlisting>
|
||||
</listitem>
|
||||
|
@ -211,7 +211,7 @@ swapDevices = [ { device = "/dev/disk/by-label/swap"; } ];
|
|||
through the function argument <literal>pkgs</literal>. Typical
|
||||
uses:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages =
|
||||
[ pkgs.thunderbird
|
||||
pkgs.emacs
|
||||
|
|
|
@ -22,7 +22,7 @@
|
|||
a dependency on GTK 2. If you want to build it against GTK 3, you
|
||||
can specify that as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages = [ (pkgs.emacs.override { gtk = pkgs.gtk3; }) ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -46,7 +46,7 @@ environment.systemPackages = [ (pkgs.emacs.override { gtk = pkgs.gtk3; }) ];
|
|||
the package, such as the source code. For instance, if you want to
|
||||
override the source code of Emacs, you can say:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages = [
|
||||
(pkgs.emacs.overrideAttrs (oldAttrs: {
|
||||
name = "emacs-25.0-pre";
|
||||
|
@ -72,7 +72,7 @@ environment.systemPackages = [
|
|||
everything depend on your customised instance, you can apply a
|
||||
<emphasis>global</emphasis> override as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
nixpkgs.config.packageOverrides = pkgs:
|
||||
{ emacs = pkgs.emacs.override { gtk = pkgs.gtk3; };
|
||||
};
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
adding the following line to <literal>configuration.nix</literal>
|
||||
enables the Mozilla Thunderbird email application:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
environment.systemPackages = [ pkgs.thunderbird ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
<literal>/dev/disk/by-label/data</literal> onto the mount point
|
||||
<literal>/data</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
fileSystems."/data" =
|
||||
{ device = "/dev/disk/by-label/data";
|
||||
fsType = "ext4";
|
||||
|
|
|
@ -6,14 +6,14 @@
|
|||
both IPv4 and IPv6 traffic. It is enabled by default. It can be
|
||||
disabled as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.firewall.enable = false;
|
||||
</programlisting>
|
||||
<para>
|
||||
If the firewall is enabled, you can open specific TCP ports to the
|
||||
outside world:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.firewall.allowedTCPPorts = [ 80 443 ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -26,7 +26,7 @@ networking.firewall.allowedTCPPorts = [ 80 443 ];
|
|||
<para>
|
||||
To open ranges of TCP ports:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.firewall.allowedTCPPortRanges = [
|
||||
{ from = 4000; to = 4007; }
|
||||
{ from = 8000; to = 8010; }
|
||||
|
|
|
@ -62,7 +62,7 @@ Platform Vendor Advanced Micro Devices, Inc.
|
|||
<xref linkend="opt-hardware.opengl.extraPackages" /> enables
|
||||
OpenCL support:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hardware.opengl.extraPackages = [
|
||||
rocm-opencl-icd
|
||||
];
|
||||
|
@ -85,7 +85,7 @@ hardware.opengl.extraPackages = [
|
|||
enable OpenCL support. For example, for Gen8 and later GPUs, the
|
||||
following configuration can be used:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hardware.opengl.extraPackages = [
|
||||
intel-compute-runtime
|
||||
];
|
||||
|
@ -162,7 +162,7 @@ GPU1:
|
|||
makes amdvlk the default driver and hides radv and lavapipe from
|
||||
the device list. A specific driver can be forced as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hardware.opengl.extraPackages = [
|
||||
pkgs.amdvlk
|
||||
];
|
||||
|
@ -206,7 +206,7 @@ $ nix-shell -p libva-utils --run vainfo
|
|||
Modern Intel GPUs use the iHD driver, which can be installed
|
||||
with:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hardware.opengl.extraPackages = [
|
||||
intel-media-driver
|
||||
];
|
||||
|
@ -215,7 +215,7 @@ hardware.opengl.extraPackages = [
|
|||
Older Intel GPUs use the i965 driver, which can be installed
|
||||
with:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
hardware.opengl.extraPackages = [
|
||||
vaapiIntel
|
||||
];
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
interfaces. However, you can configure an interface manually as
|
||||
follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.interfaces.eth0.ipv4.addresses = [ {
|
||||
address = "192.168.1.2";
|
||||
prefixLength = 24;
|
||||
|
@ -16,7 +16,7 @@ networking.interfaces.eth0.ipv4.addresses = [ {
|
|||
Typically you’ll also want to set a default gateway and set of name
|
||||
servers:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.defaultGateway = "192.168.1.1";
|
||||
networking.nameservers = [ "8.8.8.8" ];
|
||||
</programlisting>
|
||||
|
@ -32,7 +32,7 @@ networking.nameservers = [ "8.8.8.8" ];
|
|||
The host name is set using
|
||||
<xref linkend="opt-networking.hostName" />:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.hostName = "cartman";
|
||||
</programlisting>
|
||||
<para>
|
||||
|
|
|
@ -10,21 +10,21 @@
|
|||
<xref linkend="opt-networking.interfaces._name_.tempAddress" />. You
|
||||
can disable IPv6 support globally by setting:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.enableIPv6 = false;
|
||||
</programlisting>
|
||||
<para>
|
||||
You can disable IPv6 on a single interface using a normal sysctl (in
|
||||
this example, we use interface <literal>eth0</literal>):
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernel.sysctl."net.ipv6.conf.eth0.disable_ipv6" = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
As with IPv4 networking interfaces are automatically configured via
|
||||
DHCPv6. You can configure an interface manually:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.interfaces.eth0.ipv6.addresses = [ {
|
||||
address = "fe00:aa:bb:cc::2";
|
||||
prefixLength = 64;
|
||||
|
@ -34,7 +34,7 @@ networking.interfaces.eth0.ipv6.addresses = [ {
|
|||
For configuring a gateway, optionally with explicitly specified
|
||||
interface:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.defaultGateway6 = {
|
||||
address = "fe00::1";
|
||||
interface = "enp0s3";
|
||||
|
|
|
@ -10,7 +10,7 @@
|
|||
way is to enable and configure cluster components appropriately by
|
||||
hand:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.kubernetes = {
|
||||
apiserver.enable = true;
|
||||
controllerManager.enable = true;
|
||||
|
@ -21,24 +21,24 @@ services.kubernetes = {
|
|||
};
|
||||
</programlisting>
|
||||
<para>
|
||||
Another way is to assign cluster roles ("master" and/or
|
||||
"node") to the host. This enables apiserver,
|
||||
Another way is to assign cluster roles (<quote>master</quote> and/or
|
||||
<quote>node</quote>) to the host. This enables apiserver,
|
||||
controllerManager, scheduler, addonManager, kube-proxy and etcd:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.kubernetes.roles = [ "master" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
While this will enable the kubelet and kube-proxy only:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.kubernetes.roles = [ "node" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
Assigning both the master and node roles is usable if you want a
|
||||
single node Kubernetes cluster for dev or testing purposes:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.kubernetes.roles = [ "master" "node" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
|
|
@ -5,7 +5,7 @@
|
|||
option <literal>boot.kernelPackages</literal>. For instance, this
|
||||
selects the Linux 3.10 kernel:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernelPackages = pkgs.linuxKernel.packages.linux_3_10;
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -48,7 +48,7 @@ zcat /proc/config.gz
|
|||
<xref linkend="sec-customising-packages" />). For instance, to
|
||||
enable support for the kernel debugger KGDB:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
nixpkgs.config.packageOverrides = pkgs: pkgs.lib.recursiveUpdate pkgs {
|
||||
linuxKernel.kernels.linux_5_10 = pkgs.linuxKernel.kernels.linux_5_10.override {
|
||||
extraConfig = ''
|
||||
|
@ -69,7 +69,7 @@ nixpkgs.config.packageOverrides = pkgs: pkgs.lib.recursiveUpdate pkgs {
|
|||
automatically by <literal>udev</literal>. You can force a module to
|
||||
be loaded via <xref linkend="opt-boot.kernelModules" />, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernelModules = [ "fuse" "kvm-intel" "coretemp" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -77,7 +77,7 @@ boot.kernelModules = [ "fuse" "kvm-intel" "coretemp&quo
|
|||
root file system), you can use
|
||||
<xref linkend="opt-boot.initrd.kernelModules" />:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.initrd.kernelModules = [ "cifs" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -88,7 +88,7 @@ boot.initrd.kernelModules = [ "cifs" ];
|
|||
Kernel runtime parameters can be set through
|
||||
<xref linkend="opt-boot.kernel.sysctl" />, e.g.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 120;
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -96,65 +96,82 @@ boot.kernel.sysctl."net.ipv4.tcp_keepalive_time" = 120;
|
|||
available parameters, run <literal>sysctl -a</literal>.
|
||||
</para>
|
||||
<section xml:id="sec-linux-config-customizing">
|
||||
<title>Customize your kernel</title>
|
||||
<title>Building a custom kernel</title>
|
||||
<para>
|
||||
The first step before compiling the kernel is to generate an
|
||||
appropriate <literal>.config</literal> configuration. Either you
|
||||
pass your own config via the <literal>configfile</literal> setting
|
||||
of <literal>linuxKernel.manualConfig</literal>:
|
||||
You can customize the default kernel configuration by overriding
|
||||
the arguments for your kernel package:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
custom-kernel = let base_kernel = linuxKernel.kernels.linux_4_9;
|
||||
in super.linuxKernel.manualConfig {
|
||||
inherit (super) stdenv hostPlatform;
|
||||
inherit (base_kernel) src;
|
||||
version = "${base_kernel.version}-custom";
|
||||
|
||||
configfile = /home/me/my_kernel_config;
|
||||
allowImportFromDerivation = true;
|
||||
};
|
||||
</programlisting>
|
||||
<para>
|
||||
You can edit the config with this snippet (by default
|
||||
<literal>make menuconfig</literal> won't work out of the box on
|
||||
nixos):
|
||||
</para>
|
||||
<programlisting>
|
||||
nix-shell -E 'with import <nixpkgs> {}; kernelToOverride.overrideAttrs (o: {nativeBuildInputs=o.nativeBuildInputs ++ [ pkg-config ncurses ];})'
|
||||
</programlisting>
|
||||
<para>
|
||||
or you can let nixpkgs generate the configuration. Nixpkgs
|
||||
generates it via answering the interactive kernel utility
|
||||
<literal>make config</literal>. The answers depend on parameters
|
||||
passed to
|
||||
<literal>pkgs/os-specific/linux/kernel/generic.nix</literal>
|
||||
(which you can influence by overriding
|
||||
<literal>extraConfig, autoModules, modDirVersion, preferBuiltin, extraConfig</literal>).
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
mptcp93.override ({
|
||||
name="mptcp-local";
|
||||
|
||||
<programlisting language="nix">
|
||||
pkgs.linux_latest.override {
|
||||
ignoreConfigErrors = true;
|
||||
autoModules = false;
|
||||
kernelPreferBuiltin = true;
|
||||
|
||||
enableParallelBuilding = true;
|
||||
|
||||
extraConfig = ''
|
||||
DEBUG_KERNEL y
|
||||
FRAME_POINTER y
|
||||
KGDB y
|
||||
KGDB_SERIAL_CONSOLE y
|
||||
DEBUG_INFO y
|
||||
'';
|
||||
});
|
||||
extraStructuredConfig = with lib.kernel; {
|
||||
DEBUG_KERNEL = yes;
|
||||
FRAME_POINTER = yes;
|
||||
KGDB = yes;
|
||||
KGDB_SERIAL_CONSOLE = yes;
|
||||
DEBUG_INFO = yes;
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
<para>
|
||||
See <literal>pkgs/os-specific/linux/kernel/generic.nix</literal>
|
||||
for details on how these arguments affect the generated
|
||||
configuration. You can also build a custom version of Linux by
|
||||
calling <literal>pkgs.buildLinux</literal> directly, which
|
||||
requires the <literal>src</literal> and <literal>version</literal>
|
||||
arguments to be specified.
|
||||
</para>
|
||||
<para>
|
||||
To use your custom kernel package in your NixOS configuration, set
|
||||
</para>
|
||||
<programlisting language="nix">
|
||||
boot.kernelPackages = pkgs.linuxPackagesFor yourCustomKernel;
|
||||
</programlisting>
|
||||
<para>
|
||||
Note that this method will use the common configuration defined in
|
||||
<literal>pkgs/os-specific/linux/kernel/common-config.nix</literal>,
|
||||
which is suitable for a NixOS system.
|
||||
</para>
|
||||
<para>
|
||||
If you already have a generated configuration file, you can build
|
||||
a kernel that uses it with
|
||||
<literal>pkgs.linuxManualConfig</literal>:
|
||||
</para>
|
||||
<programlisting language="nix">
|
||||
let
|
||||
baseKernel = pkgs.linux_latest;
|
||||
in pkgs.linuxManualConfig {
|
||||
inherit (baseKernel) src modDirVersion;
|
||||
version = "${baseKernel.version}-custom";
|
||||
configfile = ./my_kernel_config;
|
||||
allowImportFromDerivation = true;
|
||||
}
|
||||
</programlisting>
|
||||
<note>
|
||||
<para>
|
||||
The build will fail if <literal>modDirVersion</literal> does not
|
||||
match the source’s <literal>kernel.release</literal> file, so
|
||||
<literal>modDirVersion</literal> should remain tied to
|
||||
<literal>src</literal>.
|
||||
</para>
|
||||
</note>
|
||||
<para>
|
||||
To edit the <literal>.config</literal> file for Linux X.Y, proceed
|
||||
as follows:
|
||||
</para>
|
||||
<programlisting>
|
||||
$ nix-shell '<nixpkgs>' -A linuxKernel.kernels.linux_X_Y.configEnv
|
||||
$ unpackPhase
|
||||
$ cd linux-*
|
||||
$ make nconfig
|
||||
</programlisting>
|
||||
</section>
|
||||
<section xml:id="sec-linux-config-developing-modules">
|
||||
<title>Developing kernel modules</title>
|
||||
<para>
|
||||
When developing kernel modules it's often convenient to run
|
||||
When developing kernel modules it’s often convenient to run
|
||||
edit-compile-run loop as quickly as possible. See below snippet as
|
||||
an example of developing <literal>mellanox</literal> drivers.
|
||||
</para>
|
||||
|
@ -181,7 +198,7 @@ $ make -C $dev/lib/modules/*/build M=$(pwd)/drivers/net/ethernet/mellanox module
|
|||
available kernel version <emphasis>that is supported by
|
||||
ZFS</emphasis> like this:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
boot.kernelPackages = pkgs.zfs.latestCompatibleLinuxPackages;
|
||||
}
|
||||
|
|
|
@ -30,7 +30,7 @@ Enter passphrase for /dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d: ***
|
|||
at boot time as <literal>/</literal>, add the following to
|
||||
<literal>configuration.nix</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.initrd.luks.devices.crypted.device = "/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d";
|
||||
fileSystems."/".device = "/dev/mapper/crypted";
|
||||
</programlisting>
|
||||
|
@ -39,7 +39,7 @@ fileSystems."/".device = "/dev/mapper/crypted";
|
|||
located on an encrypted partition, it is necessary to add the
|
||||
following grub option:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.loader.grub.enableCryptodisk = true;
|
||||
</programlisting>
|
||||
<section xml:id="sec-luks-file-systems-fido2">
|
||||
|
@ -67,7 +67,7 @@ Added to key to device /dev/sda2, slot: 2
|
|||
compatible key, add the following to
|
||||
<literal>configuration.nix</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.initrd.luks.fido2Support = true;
|
||||
boot.initrd.luks.devices."/dev/sda2".fido2.credential = "f1d00200108b9d6e849a8b388da457688e3dd653b4e53770012d8f28e5d3b269865038c346802f36f3da7278b13ad6a3bb6a1452e24ebeeaa24ba40eef559b1b287d2a2f80b7";
|
||||
</programlisting>
|
||||
|
@ -77,7 +77,7 @@ boot.initrd.luks.devices."/dev/sda2".fido2.credential = "f1d00200
|
|||
protected, such as
|
||||
<link xlink:href="https://trezor.io/">Trezor</link>.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.initrd.luks.devices."/dev/sda2".fido2.passwordLess = true;
|
||||
</programlisting>
|
||||
</section>
|
||||
|
|
|
@ -14,7 +14,7 @@
|
|||
other modules by including them from
|
||||
<literal>configuration.nix</literal>, e.g.:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{ imports = [ ./vpn.nix ./kde.nix ];
|
||||
|
@ -28,7 +28,7 @@
|
|||
<literal>vpn.nix</literal> and <literal>kde.nix</literal>. The
|
||||
latter might look like this:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{ services.xserver.enable = true;
|
||||
|
@ -50,7 +50,7 @@
|
|||
you want it to appear first, you can use
|
||||
<literal>mkBefore</literal>:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
boot.kernelModules = mkBefore [ "kvm-intel" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -70,7 +70,7 @@ The unique option `services.httpd.adminAddr' is defined multiple times, in `/etc
|
|||
When that happens, it’s possible to force one definition take
|
||||
precedence over the others:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.httpd.adminAddr = pkgs.lib.mkForce "bob@example.org";
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -93,7 +93,7 @@ services.httpd.adminAddr = pkgs.lib.mkForce "bob@example.org";
|
|||
<xref linkend="opt-services.xserver.enable" /> is set to
|
||||
<literal>true</literal> somewhere else:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
{ environment.systemPackages =
|
||||
|
@ -137,7 +137,7 @@ nix-repl> map (x: x.hostName) config.services.httpd.virtualHosts
|
|||
below would have the same effect as importing a file which sets
|
||||
those options.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
let netConfig = hostName: {
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
To facilitate network configuration, some desktop environments use
|
||||
NetworkManager. You can enable NetworkManager by setting:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.networkmanager.enable = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -15,7 +15,7 @@ networking.networkmanager.enable = true;
|
|||
All users that should have permission to change network settings
|
||||
must belong to the <literal>networkmanager</literal> group:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
users.users.alice.extraGroups = [ "networkmanager" ];
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -36,7 +36,7 @@ users.users.alice.extraGroups = [ "networkmanager" ];
|
|||
used together if desired. To do this you need to instruct
|
||||
NetworkManager to ignore those interfaces like:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.networkmanager.unmanaged = [
|
||||
"*" "except:type:wwan" "except:type:gsm"
|
||||
];
|
||||
|
|
|
@ -4,12 +4,12 @@
|
|||
In some cases, it may be desirable to take advantage of
|
||||
commonly-used, predefined configurations provided by nixpkgs, but
|
||||
different from those that come as default. This is a role fulfilled
|
||||
by NixOS's Profiles, which come as files living in
|
||||
by NixOS’s Profiles, which come as files living in
|
||||
<literal><nixpkgs/nixos/modules/profiles></literal>. That is
|
||||
to say, expected usage is to add them to the imports list of your
|
||||
<literal>/etc/configuration.nix</literal> as such:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
imports = [
|
||||
<nixpkgs/nixos/modules/profiles/profile-name.nix>
|
||||
];
|
||||
|
|
|
@ -9,7 +9,7 @@
|
|||
available to processes through the <literal>/sys</literal> and
|
||||
<literal>/proc</literal> filesystems. It also disables the User
|
||||
Namespaces feature of the kernel, which stops Nix from being able to
|
||||
build anything (this particular setting can be overriden via
|
||||
build anything (this particular setting can be overridden via
|
||||
<xref linkend="opt-security.allowUserNamespaces" />). See the
|
||||
<link xlink:href="https://github.com/nixos/nixpkgs/tree/master/nixos/modules/profiles/hardened.nix">profile
|
||||
source</link> for further detail on which settings are altered.
|
||||
|
|
|
@ -30,7 +30,7 @@
|
|||
the interface with MAC address
|
||||
<literal>52:54:00:12:01:01</literal> using a netword link unit:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
systemd.network.links."10-wan" = {
|
||||
matchConfig.PermanentMACAddress = "52:54:00:12:01:01";
|
||||
linkConfig.Name = "wan";
|
||||
|
@ -43,7 +43,7 @@ systemd.network.links."10-wan" = {
|
|||
<para>
|
||||
Alternatively, we can use a plain old udev rule:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.udev.initrdRules = ''
|
||||
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
|
||||
ATTR{address}=="52:54:00:12:01:01", KERNEL=="eth*", NAME="wan"
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
<para>
|
||||
Secure shell (SSH) access to your machine can be enabled by setting:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.openssh.enable = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -16,7 +16,7 @@ services.openssh.enable = true;
|
|||
You can declaratively specify authorised RSA/DSA public keys for a
|
||||
user as follows:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
users.users.alice.openssh.authorizedKeys.keys =
|
||||
[ "ssh-dss AAAAB3NzaC1kc3MAAACBAPIkGWVEt4..." ];
|
||||
</programlisting>
|
||||
|
|
|
@ -54,7 +54,7 @@ SHA256:yjxl3UbTn31fLWeyLYTAKYJPRmzknjQZoyG8gSNEoIE my-user@workstation
|
|||
<link linkend="opt-fileSystems">fileSystems</link> option. Here’s
|
||||
a typical setup:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
system.fsPackages = [ pkgs.sshfs ];
|
||||
|
||||
|
@ -80,7 +80,7 @@ SHA256:yjxl3UbTn31fLWeyLYTAKYJPRmzknjQZoyG8gSNEoIE my-user@workstation
|
|||
well, for example you can change the default SSH port or specify a
|
||||
jump proxy:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
options =
|
||||
[ "ProxyJump=bastion@example.com"
|
||||
|
@ -92,7 +92,7 @@ SHA256:yjxl3UbTn31fLWeyLYTAKYJPRmzknjQZoyG8gSNEoIE my-user@workstation
|
|||
It’s also possible to change the <literal>ssh</literal> command
|
||||
used by SSHFS to connect to the server. For example:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
{
|
||||
options =
|
||||
[ (builtins.replaceStrings [" "] ["\\040"]
|
||||
|
|
|
@ -25,7 +25,7 @@
|
|||
Apache HTTP, setting
|
||||
<xref linkend="opt-services.httpd.adminAddr" /> appropriately:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.httpd.enable = true;
|
||||
services.httpd.adminAddr = ...;
|
||||
networking.firewall.allowedTCPPorts = [ 80 443 ];
|
||||
|
@ -40,7 +40,7 @@ networking.firewall.allowedTCPPorts = [ 80 443 ];
|
|||
<literal>.authz</literal> file describing access permission, and
|
||||
<literal>AuthUserFile</literal> to the password file.
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
services.httpd.extraModules = [
|
||||
# note that order is *super* important here
|
||||
{ name = "dav_svn"; path = "${pkgs.apacheHttpdPackages.subversion}/modules/mod_dav_svn.so"; }
|
||||
|
@ -106,7 +106,7 @@ $ htpasswd -s PASSWORD_FILE USER_NAME
|
|||
<literal>ACCESS_FILE</literal> will look something like the
|
||||
following:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
[/]
|
||||
* = r
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
states that a user account named <literal>alice</literal> shall
|
||||
exist:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
users.users.alice = {
|
||||
isNormalUser = true;
|
||||
home = "/home/alice";
|
||||
|
@ -36,7 +36,7 @@ users.users.alice = {
|
|||
<xref linkend="opt-users.users" /> and run nixos-rebuild, the user
|
||||
account will cease to exist. Also, imperative commands for managing
|
||||
users and groups, such as useradd, are no longer available.
|
||||
Passwords may still be assigned by setting the user's
|
||||
Passwords may still be assigned by setting the user’s
|
||||
<link linkend="opt-users.users._name_.hashedPassword">hashedPassword</link>
|
||||
option. A hashed password can be generated using
|
||||
<literal>mkpasswd</literal>.
|
||||
|
@ -45,7 +45,7 @@ users.users.alice = {
|
|||
A user ID (uid) is assigned automatically. You can also specify a
|
||||
uid manually by adding
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
uid = 1000;
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -55,7 +55,7 @@ uid = 1000;
|
|||
Groups can be specified similarly. The following states that a group
|
||||
named <literal>students</literal> shall exist:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
users.groups.students.gid = 1000;
|
||||
</programlisting>
|
||||
<para>
|
||||
|
|
|
@ -5,11 +5,12 @@
|
|||
display technology on NixOS, Wayland support is steadily improving.
|
||||
Where X11 separates the X Server and the window manager, on Wayland
|
||||
those are combined: a Wayland Compositor is like an X11 window
|
||||
manager, but also embeds the Wayland 'Server' functionality. This
|
||||
means it is sufficient to install a Wayland Compositor such as sway
|
||||
without separately enabling a Wayland server:
|
||||
manager, but also embeds the Wayland <quote>Server</quote>
|
||||
functionality. This means it is sufficient to install a Wayland
|
||||
Compositor such as sway without separately enabling a Wayland
|
||||
server:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
programs.sway.enable = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
|
@ -21,7 +22,7 @@ programs.sway.enable = true;
|
|||
be able to share your screen, you might want to activate this
|
||||
option:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
xdg.portal.wlr.enable = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
|
|
|
@ -9,13 +9,13 @@
|
|||
<para>
|
||||
NixOS will start wpa_supplicant for you if you enable this setting:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.wireless.enable = true;
|
||||
</programlisting>
|
||||
<para>
|
||||
NixOS lets you specify networks for wpa_supplicant declaratively:
|
||||
</para>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.wireless.networks = {
|
||||
echelon = { # SSID with no spaces or special characters
|
||||
psk = "abcdefgh";
|
||||
|
@ -49,7 +49,7 @@ network={
|
|||
psk=dca6d6ed41f4ab5a984c9f55f6f66d4efdc720ebf66959810f4329bb391c5435
|
||||
}
|
||||
</programlisting>
|
||||
<programlisting language="bash">
|
||||
<programlisting language="nix">
|
||||
networking.wireless.networks = {
|
||||
echelon = {
|
||||
pskRaw = "dca6d6ed41f4ab5a984c9f55f6f66d4efdc720ebf66959810f4329bb391c5435";
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue