pyrox.dev
+58
-46
CONTRIBUTING.md
+58
-46
CONTRIBUTING.md
·········- In attribute sets or lists that span multiple lines, the attribute names or list elements should be aligned:······For functions that are truly generic in the number of arguments (such as wrappers around `mkDerivation`) that have some required arguments, you should write them using an `@`-pattern:······- Building lists conditionally _should_ be done with `lib.optional(s)` instead of using `if cond then [ ... ] else null` or `if cond then [ ... ] else [ ]`.As an exception, an explicit conditional expression with null can be used when fixing a important bug without triggering a mass rebuild.
·········- In attribute sets or lists that span multiple lines, the attribute names or list elements should be aligned:······For functions that are truly generic in the number of arguments (such as wrappers around `mkDerivation`) that have some required arguments, you should write them using an `@`-pattern:······- Building lists conditionally _should_ be done with `lib.optional(s)` instead of using `if cond then [ ... ] else null` or `if cond then [ ... ] else [ ]`.As an exception, an explicit conditional expression with null can be used when fixing a important bug without triggering a mass rebuild.
+5
-5
doc/build-helpers/fetchers.chapter.md
+5
-5
doc/build-helpers/fetchers.chapter.md
···A common mistake is to update a fetcher’s URL, or a version parameter, without updating the hash.············
···A common mistake is to update a fetcher’s URL, or a version parameter, without updating the hash.············
+1
doc/build-helpers/images/dockertools.section.md
+1
doc/build-helpers/images/dockertools.section.md
+8
-4
doc/build-helpers/special/checkpoint-build.section.md
+8
-4
doc/build-helpers/special/checkpoint-build.section.md
···
···
+32
-22
doc/build-helpers/testers.chapter.md
+32
-22
doc/build-helpers/testers.chapter.md
·········This example will run the command `hello --version`, and then check that the version of the `hello` package is in the output of the command.·········
·········This example will run the command `hello --version`, and then check that the version of the `hello` package is in the output of the command.·········
+18
-16
doc/build-helpers/trivial-build-helpers.chapter.md
+18
-16
doc/build-helpers/trivial-build-helpers.chapter.md
·································
·································
+18
-11
doc/functions/nix-gitignore.section.md
+18
-11
doc/functions/nix-gitignore.section.md
···`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.These functions are derived from the `Filter` functions by setting the first filter argument to `(_: _: 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.······If you wish to use a filter that would search for .gitignore files in subdirectories, just like git does by default, use this function:
···`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.These functions are derived from the `Filter` functions by setting the first filter argument to `(_: _: 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.······If you wish to use a filter that would search for .gitignore files in subdirectories, just like git does by default, use this function:
+3
-1
doc/hooks/breakpoint.section.md
+3
-1
doc/hooks/breakpoint.section.md
···This hook will make a build pause instead of stopping when a failure happens. It prevents nix from cleaning up the build environment immediately and allows the user to attach to a build environment using the `cntr` command. Upon build error it will print instructions on how to use `cntr`, which can be used to enter the environment for debugging. Installing cntr and running the command will provide shell access to the build sandbox of failed build. At `/var/lib/cntr` the sandboxed filesystem is mounted. All commands and files of the system are still accessible within the shell. To execute commands from the sandbox use the cntr exec subcommand. `cntr` is only supported on Linux-based platforms. To use it first add `cntr` to your `environment.systemPackages` on NixOS or alternatively to the root user on non-NixOS systems. Then in the package that is supposed to be inspected, add `breakpointHook` to `nativeBuildInputs`.When a build failure happens there will be an instruction printed that shows how to attach with `cntr` to the build sandbox.
···This hook will make a build pause instead of stopping when a failure happens. It prevents nix from cleaning up the build environment immediately and allows the user to attach to a build environment using the `cntr` command. Upon build error it will print instructions on how to use `cntr`, which can be used to enter the environment for debugging. Installing cntr and running the command will provide shell access to the build sandbox of failed build. At `/var/lib/cntr` the sandboxed filesystem is mounted. All commands and files of the system are still accessible within the shell. To execute commands from the sandbox use the cntr exec subcommand. `cntr` is only supported on Linux-based platforms. To use it first add `cntr` to your `environment.systemPackages` on NixOS or alternatively to the root user on non-NixOS systems. Then in the package that is supposed to be inspected, add `breakpointHook` to `nativeBuildInputs`.When a build failure happens there will be an instruction printed that shows how to attach with `cntr` to the build sandbox.
+17
-15
doc/hooks/installShellFiles.section.md
+17
-15
doc/hooks/installShellFiles.section.md
···The `installShellCompletion` function takes one or more paths to shell completion files. By default it will autodetect the shell type from the completion file extension, but you may also specify it by passing one of `--bash`, `--fish`, or `--zsh`. These flags apply to all paths listed after them (up until another shell flag is given). Each path may also have a custom installation name provided by providing a flag `--name NAME` before the path. If this flag is not provided, zsh completions will be renamed automatically such that `foobar.zsh` becomes `_foobar`. A root name may be provided for all paths using the flag `--cmd NAME`; this synthesizes the appropriate name depending on the shell (e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for zsh). The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which case the shell and name must be provided.
···The `installShellCompletion` function takes one or more paths to shell completion files. By default it will autodetect the shell type from the completion file extension, but you may also specify it by passing one of `--bash`, `--fish`, or `--zsh`. These flags apply to all paths listed after them (up until another shell flag is given). Each path may also have a custom installation name provided by providing a flag `--name NAME` before the path. If this flag is not provided, zsh completions will be renamed automatically such that `foobar.zsh` becomes `_foobar`. A root name may be provided for all paths using the flag `--cmd NAME`; this synthesizes the appropriate name depending on the shell (e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for zsh). The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which case the shell and name must be provided.
+7
-6
doc/hooks/mpi-check-hook.section.md
+7
-6
doc/hooks/mpi-check-hook.section.md
+3
-2
doc/languages-frameworks/agda.section.md
+3
-2
doc/languages-frameworks/agda.section.md
······Note that the derivation function is called with `mkDerivation` set to `agdaPackages.mkDerivation`, therefore you···
······Note that the derivation function is called with `mkDerivation` set to `agdaPackages.mkDerivation`, therefore you···
+14
-12
doc/languages-frameworks/android.section.md
+14
-12
doc/languages-frameworks/android.section.md
···
···
+6
-2
doc/languages-frameworks/beam.section.md
+6
-2
doc/languages-frameworks/beam.section.md
···- From the mix_deps.nix file, remove the dependencies that had git versions and pass them as an override to the import function.······The first build will complain about the hash value, you can replace with the suggested value after that.
···- From the mix_deps.nix file, remove the dependencies that had git versions and pass them as an override to the import function.······The first build will complain about the hash value, you can replace with the suggested value after that.
+8
-6
doc/languages-frameworks/bower.section.md
+8
-6
doc/languages-frameworks/bower.section.md
···Using the `bower2nix` command line arguments, the output can be redirected to a file. A name like `bower-packages.nix` would be fine.···In ["buildBowerComponents" example](#ex-buildBowerComponents) the following arguments are of special significance to the function:
···Using the `bower2nix` command line arguments, the output can be redirected to a file. A name like `bower-packages.nix` would be fine.···In ["buildBowerComponents" example](#ex-buildBowerComponents) the following arguments are of special significance to the function:
+4
-2
doc/languages-frameworks/chicken.section.md
+4
-2
doc/languages-frameworks/chicken.section.md
······
······
+5
-1
doc/languages-frameworks/crystal.section.md
+5
-1
doc/languages-frameworks/crystal.section.md
···This won't build anything yet, because we haven't told it what files build. We can specify a mapping from binary names to source files with the `crystalBinaries` attribute. The project's compilation instructions should show this. For Mint, the binary is called "mint", which is compiled from the source file `src/mint.cr`, so we'll specify this as follows:Additionally you can override the default `crystal build` options (which are currently `--release --progress --no-debug --verbose`) withDepending on the project, you might need additional steps to get it to compile successfully. In Mint's case, we need to link against openssl, so in the end the Nix file looks as follows:
···This won't build anything yet, because we haven't told it what files build. We can specify a mapping from binary names to source files with the `crystalBinaries` attribute. The project's compilation instructions should show this. For Mint, the binary is called "mint", which is compiled from the source file `src/mint.cr`, so we'll specify this as follows:Additionally you can override the default `crystal build` options (which are currently `--release --progress --no-debug --verbose`) withDepending on the project, you might need additional steps to get it to compile successfully. In Mint's case, we need to link against openssl, so in the end the Nix file looks as follows:
+11
-7
doc/languages-frameworks/cuda.section.md
+11
-7
doc/languages-frameworks/cuda.section.md
···
···
+9
-1
doc/languages-frameworks/dhall.section.md
+9
-1
doc/languages-frameworks/dhall.section.md
············For example, suppose we wanted to selectively enable `source = true` just for the Prelude. We can do that like this:[semantic-integrity-checks]: https://docs.dhall-lang.org/tutorials/Language-Tour.html#installing-packages
············For example, suppose we wanted to selectively enable `source = true` just for the Prelude. We can do that like this:[semantic-integrity-checks]: https://docs.dhall-lang.org/tutorials/Language-Tour.html#installing-packages
+1
-1
doc/languages-frameworks/dotnet.section.md
+1
-1
doc/languages-frameworks/dotnet.section.md
+27
-21
doc/languages-frameworks/gnome.section.md
+27
-21
doc/languages-frameworks/gnome.section.md
···In the rare case you need to use icons from dependencies (e.g. when an app forces an icon theme), you can use the following to pick them up:···To avoid costly file system access when locating icons, GTK, [as well as Qt](https://woboq.com/blog/qicon-reads-gtk-icon-cache-in-qt57.html), can rely on `icon-theme.cache` files from the themes' top-level directories. These files are generated using `gtk-update-icon-cache`, which is expected to be run whenever an icon is added or removed to an icon theme (typically an application icon into `hicolor` theme) and some programs do indeed run this after icon installation. However, since packages are installed into their own prefix by Nix, this would lead to conflicts. For that reason, `gtk3` provides a [setup hook](#ssec-gnome-hooks-gtk-drop-icon-theme-cache) that will clean the file from installation. Since most applications only ship their own icon that will be loaded on start-up, it should not affect them too much. On the other hand, icon themes are much larger and more widely used so we need to cache them. Because we recommend installing icon themes globally, we will generate the cache files from all packages in a profile using a NixOS module. You can enable the cache generation using `gtk.iconCache.enable` option if your desktop environment does not already do that.···---prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \Fortunately, there is [`wrapGAppsHook`]{#ssec-gnome-hooks-wrapgappshook}. It works in conjunction with other setup hooks that populate environment variables, and it will then wrap all executables in `bin` and `libexec` directories using said variables.···You can also pass additional arguments to `makeWrapper` using `gappsWrapperArgs` in `preFixup` hook:······
···In the rare case you need to use icons from dependencies (e.g. when an app forces an icon theme), you can use the following to pick them up:···To avoid costly file system access when locating icons, GTK, [as well as Qt](https://woboq.com/blog/qicon-reads-gtk-icon-cache-in-qt57.html), can rely on `icon-theme.cache` files from the themes' top-level directories. These files are generated using `gtk-update-icon-cache`, which is expected to be run whenever an icon is added or removed to an icon theme (typically an application icon into `hicolor` theme) and some programs do indeed run this after icon installation. However, since packages are installed into their own prefix by Nix, this would lead to conflicts. For that reason, `gtk3` provides a [setup hook](#ssec-gnome-hooks-gtk-drop-icon-theme-cache) that will clean the file from installation. Since most applications only ship their own icon that will be loaded on start-up, it should not affect them too much. On the other hand, icon themes are much larger and more widely used so we need to cache them. Because we recommend installing icon themes globally, we will generate the cache files from all packages in a profile using a NixOS module. You can enable the cache generation using `gtk.iconCache.enable` option if your desktop environment does not already do that.···+--prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \Fortunately, there is [`wrapGAppsHook`]{#ssec-gnome-hooks-wrapgappshook}. It works in conjunction with other setup hooks that populate environment variables, and it will then wrap all executables in `bin` and `libexec` directories using said variables.···You can also pass additional arguments to `makeWrapper` using `gappsWrapperArgs` in `preFixup` hook:······
+48
-30
doc/languages-frameworks/go.section.md
+48
-30
doc/languages-frameworks/go.section.md
······- `goDeps` is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate `deps.nix` file for readability. The dependency data structure is described below.···The most common use case for this argument is to make the resulting executable aware of its own version by injecting the value of string variable using the `-X` flag. For example:···A string list of [Go build tags (also called build constraints)](https://pkg.go.dev/cmd/go#hdr-Build_constraints) that are passed via the `-tags` argument of `go build`. These constraints control whether Go files from the source should be included in the build. For example:············
······- `goDeps` is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate `deps.nix` file for readability. The dependency data structure is described below.···The most common use case for this argument is to make the resulting executable aware of its own version by injecting the value of string variable using the `-X` flag. For example:···A string list of [Go build tags (also called build constraints)](https://pkg.go.dev/cmd/go#hdr-Build_constraints) that are passed via the `-tags` argument of `go build`. These constraints control whether Go files from the source should be included in the build. For example:············
+2
-2
doc/languages-frameworks/idris.section.md
+2
-2
doc/languages-frameworks/idris.section.md
+22
-14
doc/languages-frameworks/java.section.md
+22
-14
doc/languages-frameworks/java.section.md
···············
···············
+43
-27
doc/languages-frameworks/javascript.section.md
+43
-27
doc/languages-frameworks/javascript.section.md
···when you need to override a package.json. It's nice to use the one from the upstream source and do some explicit override. Here is an example:You will still need to commit the modified version of the lock files, but at least the overrides are explicit for everyone to see.···For example, `dat` requires `node-gyp-build`, so we override its expression in [pkgs/development/node-packages/overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/overrides.nix):### Adding and Updating Javascript packages in nixpkgs {#javascript-adding-or-updating-packages}···If the downloaded files contain the `package.json` and `yarn.lock` files they can be used like this:···It's important to use the `--offline` flag. For example if you script is `"build": "something"` in `package.json` use:The `distPhase` is packing the package's dependencies in a tarball using `yarn pack`. You can disable it using:The configure phase can sometimes fail because it makes many assumptions which may not always apply. One common override is:···
···when you need to override a package.json. It's nice to use the one from the upstream source and do some explicit override. Here is an example:You will still need to commit the modified version of the lock files, but at least the overrides are explicit for everyone to see.···For example, `dat` requires `node-gyp-build`, so we override its expression in [pkgs/development/node-packages/overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/overrides.nix):### Adding and Updating Javascript packages in nixpkgs {#javascript-adding-or-updating-packages}···If the downloaded files contain the `package.json` and `yarn.lock` files they can be used like this:···It's important to use the `--offline` flag. For example if you script is `"build": "something"` in `package.json` use:The `distPhase` is packing the package's dependencies in a tarball using `yarn pack`. You can disable it using:The configure phase can sometimes fail because it makes many assumptions which may not always apply. One common override is:···
+5
-3
doc/languages-frameworks/lisp.section.md
+5
-3
doc/languages-frameworks/lisp.section.md
+21
-16
doc/languages-frameworks/lua.section.md
+21
-16
doc/languages-frameworks/lua.section.md
·········The `buildLuarocksPackage` function is implemented in `pkgs/development/interpreters/lua-5/build-luarocks-package.nix`-url = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
·········The `buildLuarocksPackage` function is implemented in `pkgs/development/interpreters/lua-5/build-luarocks-package.nix`+url = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
+1
-1
doc/languages-frameworks/maven.section.md
+1
-1
doc/languages-frameworks/maven.section.md
···This package calls `maven.buildMavenPackage` to do its work. The primary difference from `stdenv.mkDerivation` is the `mvnHash` variable, which is a hash of all of the Maven dependencies.
···This package calls `maven.buildMavenPackage` to do its work. The primary difference from `stdenv.mkDerivation` is the `mvnHash` variable, which is a hash of all of the Maven dependencies.
+1
doc/languages-frameworks/ocaml.section.md
+1
doc/languages-frameworks/ocaml.section.md
···Here is a second example, this time using a source archive generated with `dune-release`. It is a good idea to use this archive when it is available as it will usually contain substituted variables such as a `%%VERSION%%` field. This library does not depend on any other OCaml library and no tests are run after building it.
···Here is a second example, this time using a source archive generated with `dune-release`. It is a good idea to use this archive when it is available as it will usually contain substituted variables such as a `%%VERSION%%` field. This library does not depend on any other OCaml library and no tests are run after building it.
+41
-33
doc/languages-frameworks/perl.section.md
+41
-33
doc/languages-frameworks/perl.section.md
···Perl packages from CPAN are defined in [pkgs/top-level/perl-packages.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix) rather than `pkgs/all-packages.nix`. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from `perl-packages.nix`. However, more complicated packages should be put in a separate file, typically in `pkgs/development/perl-modules`. Here is an example of the former:Note the use of `mirror://cpan/`, and the `pname` and `version` in the URL definition to ensure that the `pname` attribute is consistent with the source that we’re actually downloading. Perl packages are made available in `all-packages.nix` through the variable `perlPackages`. For instance, if you have a package that needs `ClassC3`, you would typically write···Dependencies on other Perl packages can be specified in the `buildInputs` and `propagatedBuildInputs` attributes. If something is exclusively a build-time dependency, use `buildInputs`; if it’s (also) a runtime dependency, use `propagatedBuildInputs`. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules:On Darwin, if a script has too many `-Idir` flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the `shortenPerlShebang` function from the `postInstall` phase:···This will remove the `-I` flags from the shebang line, rewrite them in the `use lib` form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place.
···Perl packages from CPAN are defined in [pkgs/top-level/perl-packages.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix) rather than `pkgs/all-packages.nix`. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from `perl-packages.nix`. However, more complicated packages should be put in a separate file, typically in `pkgs/development/perl-modules`. Here is an example of the former:Note the use of `mirror://cpan/`, and the `pname` and `version` in the URL definition to ensure that the `pname` attribute is consistent with the source that we’re actually downloading. Perl packages are made available in `all-packages.nix` through the variable `perlPackages`. For instance, if you have a package that needs `ClassC3`, you would typically write···Dependencies on other Perl packages can be specified in the `buildInputs` and `propagatedBuildInputs` attributes. If something is exclusively a build-time dependency, use `buildInputs`; if it’s (also) a runtime dependency, use `propagatedBuildInputs`. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules:On Darwin, if a script has too many `-Idir` flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the `shortenPerlShebang` function from the `postInstall` phase:···This will remove the `-I` flags from the shebang line, rewrite them in the `use lib` form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place.
+3
-3
doc/languages-frameworks/php.section.md
+3
-3
doc/languages-frameworks/php.section.md
·········
·········
+2
-2
doc/languages-frameworks/pkg-config.section.md
+2
-2
doc/languages-frameworks/pkg-config.section.md
···
···
+65
-25
doc/languages-frameworks/python.section.md
+65
-25
doc/languages-frameworks/python.section.md
···This is particularly useful for numpy and scipy users who want to gain speed with other blas implementations.·································However, this is done in its own phase, and not dependent on whether [`doCheck = true;`](#var-stdenv-doCheck).············`unittestCheckHook` is a hook which will substitute the setuptools `test` command for a [`checkPhase`](#ssec-check-phase) which runs `python -m unittest discover`:························### How to override a Python package using overlays? {#how-to-override-a-python-package-using-overlays}······This method is using `passthru`, meaning that changing `optional-dependencies` of a package won't cause it to rebuild.
···This is particularly useful for numpy and scipy users who want to gain speed with other blas implementations.·································However, this is done in its own phase, and not dependent on whether [`doCheck = true;`](#var-stdenv-doCheck).············`unittestCheckHook` is a hook which will substitute the setuptools `test` command for a [`checkPhase`](#ssec-check-phase) which runs `python -m unittest discover`:························### How to override a Python package using overlays? {#how-to-override-a-python-package-using-overlays}······This method is using `passthru`, meaning that changing `optional-dependencies` of a package won't cause it to rebuild.
+2
doc/languages-frameworks/ruby.section.md
+2
doc/languages-frameworks/ruby.section.md
···Sometimes a Gemfile references other files. Such as `.ruby-version` or vendored gems. When copying the Gemfile to the nix store we need to copy those files alongside. This can be done using `extraConfigPaths`. For example:
···Sometimes a Gemfile references other files. Such as `.ruby-version` or vendored gems. When copying the Gemfile to the nix store we need to copy those files alongside. This can be done using `extraConfigPaths`. For example:
+41
-25
doc/languages-frameworks/rust.section.md
+41
-25
doc/languages-frameworks/rust.section.md
·········Per the instructions in the [Cargo Book](https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html)·····················
·········Per the instructions in the [Cargo Book](https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html)·····················
+17
-9
doc/languages-frameworks/swift.section.md
+17
-9
doc/languages-frameworks/swift.section.md
·········
·········
+10
-6
doc/languages-frameworks/vim.section.md
+10
-6
doc/languages-frameworks/vim.section.md
···Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:Sometimes plugins require an override that must be changed when the plugin is updated. This can cause issues when Vim plugins are auto-updated but the associated override isn't updated. For these plugins, the override should be written so that it specifies all information required to install the plugin, and running `./update.py` doesn't change the derivation for the plugin. Manually updating the override is required to update these types of plugins. An example of such a plugin is `LanguageClient-neovim`.···
···Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:Sometimes plugins require an override that must be changed when the plugin is updated. This can cause issues when Vim plugins are auto-updated but the associated override isn't updated. For these plugins, the override should be written so that it specifies all information required to install the plugin, and running `./update.py` doesn't change the derivation for the plugin. Manually updating the override is required to update these types of plugins. An example of such a plugin is `LanguageClient-neovim`.···
+3
doc/packages/darwin-builder.section.md
+3
doc/packages/darwin-builder.section.md
······
······
+35
-31
doc/packages/eclipse.section.md
+35
-31
doc/packages/eclipse.section.md
···If you prefer to install plugins in a more declarative manner, then Nixpkgs also offer a number of Eclipse plugins that can be installed in an _Eclipse environment_. This type of environment is created using the function `eclipseWithPlugins` found inside the `nixpkgs.eclipses` attribute set. This function takes as argument `{ eclipse, plugins ? [], jvmArgs ? [] }` where `eclipse` is a one of the Eclipse packages described above, `plugins` is a list of plugin derivations, and `jvmArgs` is a list of arguments given to the JVM running the Eclipse. For example, say you wish to install the latest Eclipse Platform with the popular Eclipse Color Theme plugin and also allow Eclipse to use more RAM. You could then add:···
···If you prefer to install plugins in a more declarative manner, then Nixpkgs also offer a number of Eclipse plugins that can be installed in an _Eclipse environment_. This type of environment is created using the function `eclipseWithPlugins` found inside the `nixpkgs.eclipses` attribute set. This function takes as argument `{ eclipse, plugins ? [], jvmArgs ? [] }` where `eclipse` is a one of the Eclipse packages described above, `plugins` is a list of plugin derivations, and `jvmArgs` is a list of arguments given to the JVM running the Eclipse. For example, say you wish to install the latest Eclipse Platform with the popular Eclipse Color Theme plugin and also allow Eclipse to use more RAM. You could then add:···
+8
-5
doc/packages/emacs.section.md
+8
-5
doc/packages/emacs.section.md
······Sometimes `emacs.pkgs.withPackages` is not enough, as this package set has some priorities imposed on packages (with the lowest priority assigned to GNU-devel ELPA, and the highest for packages manually defined in `pkgs/applications/editors/emacs/elisp-packages/manual-packages`). But you can't control these priorities when some package is installed as a dependency. You can override it on a per-package-basis, providing all the required dependencies manually, but it's tedious and there is always a possibility that an unwanted dependency will sneak in through some other package. To completely override such a package, you can use `overrideScope`.···
······Sometimes `emacs.pkgs.withPackages` is not enough, as this package set has some priorities imposed on packages (with the lowest priority assigned to GNU-devel ELPA, and the highest for packages manually defined in `pkgs/applications/editors/emacs/elisp-packages/manual-packages`). But you can't control these priorities when some package is installed as a dependency. You can override it on a per-package-basis, providing all the required dependencies manually, but it's tedious and there is always a possibility that an unwanted dependency will sneak in through some other package. To completely override such a package, you can use `overrideScope`.···
+1
-1
doc/packages/steam.section.md
+1
-1
doc/packages/steam.section.md
+3
-1
doc/packages/urxvt.section.md
+3
-1
doc/packages/urxvt.section.md
···If the plugin is itself a Perl package that needs to be imported from other plugins or scripts, add the following passthrough:
+3
-3
doc/packages/weechat.section.md
+3
-3
doc/packages/weechat.section.md
···WeeChat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration, such as:···
···WeeChat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration, such as:···
+19
-9
doc/stdenv/cross-compilation.chapter.md
+19
-9
doc/stdenv/cross-compilation.chapter.md
···In Nixpkgs, these three platforms are defined as attribute sets under the names `buildPlatform`, `hostPlatform`, and `targetPlatform`. They are always defined as attributes in the standard environment. That means one can access them like:···Many packages assume that an unprefixed binutils (`cc`/`ar`/`ld` etc.) is available, but Nix doesn't provide one. It only provides a prefixed one, just as it only does for all the other binutils programs. It may be necessary to patch the package to fix the build system to use a prefix. For instance, instead of `cc`, use `${stdenv.cc.targetPrefix}cc`.#### How do I avoid compiling a GCC cross-compiler from source? {#cross-qa-avoid-compiling-gcc-cross-compiler}······#### Package using Meson needs to run binaries for the host platform during build. {#cross-meson-runs-host-code}···
···In Nixpkgs, these three platforms are defined as attribute sets under the names `buildPlatform`, `hostPlatform`, and `targetPlatform`. They are always defined as attributes in the standard environment. That means one can access them like:···Many packages assume that an unprefixed binutils (`cc`/`ar`/`ld` etc.) is available, but Nix doesn't provide one. It only provides a prefixed one, just as it only does for all the other binutils programs. It may be necessary to patch the package to fix the build system to use a prefix. For instance, instead of `cc`, use `${stdenv.cc.targetPrefix}cc`.#### How do I avoid compiling a GCC cross-compiler from source? {#cross-qa-avoid-compiling-gcc-cross-compiler}······#### Package using Meson needs to run binaries for the host platform during build. {#cross-meson-runs-host-code}···
+31
-19
doc/stdenv/meta.chapter.md
+31
-19
doc/stdenv/meta.chapter.md
···Nix packages can declare *meta-attributes* that contain information about a package such as a description, its homepage, its license, and so on. For instance, the GNU Hello package has a `meta` declaration like this:Meta-attributes are not passed to the builder of the package. Thus, a change to a meta-attribute doesn’t trigger a recompilation of the package.···The list of Nix platform types on which the package is supported. Hydra builds packages according to the platform specified. If no platform is specified, the package does not have prebuilt binaries. An example is:Attribute Set `lib.platforms` defines [various common lists](https://github.com/NixOS/nixpkgs/blob/master/lib/systems/doubles.nix) of platforms types.···For example, a package which requires dynamic linking and cannot be linked statically could use this:The [`lib.meta.availableOn`](https://github.com/NixOS/nixpkgs/blob/b03ac42b0734da3e7be9bf8d94433a5195734b19/lib/meta.nix#L95-L106) function can be used to test whether or not a package is available (i.e. buildable) on a given platform.···The NixOS tests are available as `nixosTests` in parameters of derivations. For instance, the OpenSMTPD derivation includes lines similar to:···The list of Nix platform types for which the [Hydra](https://github.com/nixos/hydra) [instance at `hydra.nixos.org`](https://nixos.org/hydra) will build the package. (Hydra is the Nix-based continuous build system.) It defaults to the value of `meta.platforms`. Thus, the only reason to set `meta.hydraPlatforms` is if you want `hydra.nixos.org` to build the package on a subset of `meta.platforms`, or not at all, e.g.···
···Nix packages can declare *meta-attributes* that contain information about a package such as a description, its homepage, its license, and so on. For instance, the GNU Hello package has a `meta` declaration like this:Meta-attributes are not passed to the builder of the package. Thus, a change to a meta-attribute doesn’t trigger a recompilation of the package.···The list of Nix platform types on which the package is supported. Hydra builds packages according to the platform specified. If no platform is specified, the package does not have prebuilt binaries. An example is:Attribute Set `lib.platforms` defines [various common lists](https://github.com/NixOS/nixpkgs/blob/master/lib/systems/doubles.nix) of platforms types.···For example, a package which requires dynamic linking and cannot be linked statically could use this:The [`lib.meta.availableOn`](https://github.com/NixOS/nixpkgs/blob/b03ac42b0734da3e7be9bf8d94433a5195734b19/lib/meta.nix#L95-L106) function can be used to test whether or not a package is available (i.e. buildable) on a given platform.···The NixOS tests are available as `nixosTests` in parameters of derivations. For instance, the OpenSMTPD derivation includes lines similar to:···The list of Nix platform types for which the [Hydra](https://github.com/nixos/hydra) [instance at `hydra.nixos.org`](https://nixos.org/hydra) will build the package. (Hydra is the Nix-based continuous build system.) It defaults to the value of `meta.platforms`. Thus, the only reason to set `meta.hydraPlatforms` is if you want `hydra.nixos.org` to build the package on a subset of `meta.platforms`, or not at all, e.g.···
+3
-1
doc/stdenv/multiple-output.chapter.md
+3
-1
doc/stdenv/multiple-output.chapter.md
···In nixpkgs there is a framework supporting multiple-output derivations. It tries to cover most cases by default behavior. You can find the source separated in `<nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh>`; it’s relatively well-readable. The whole machinery is triggered by defining the `outputs` attribute to contain the list of desired output names (strings).Often such a single line is enough. For each output an equally named environment variable is passed to the builder and contains the path in nix store for that output. Typically you also want to have the main `out` output, as it catches any files that didn’t get elsewhere.
···In nixpkgs there is a framework supporting multiple-output derivations. It tries to cover most cases by default behavior. You can find the source separated in `<nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh>`; it’s relatively well-readable. The whole machinery is triggered by defining the `outputs` attribute to contain the list of desired output names (strings).Often such a single line is enough. For each output an equally named environment variable is passed to the builder and contains the path in nix store for that output. Typically you also want to have the main `out` output, as it catches any files that didn’t get elsewhere.
+59
-35
doc/stdenv/stdenv.chapter.md
+59
-35
doc/stdenv/stdenv.chapter.md
···············-version="$(curl -sI https://zoom.us/client/latest/zoom_x86_64.tar.xz | grep -Fi 'Location:' | pcre2grep -o1 '/(([0-9]\.?)+)/')"···- [`supportedFeatures`]{#var-passthru-updateScript-set-supportedFeatures} (optional) – a list of the [extra features](#var-passthru-updateScript-supported-features) the script supports.A common pattern is to use the [`nix-update-script`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/common-updater/nix-update.nix) attribute provided in Nixpkgs, which runs [`nix-update`](https://github.com/Mic92/nix-update):For simple packages, this is often enough, and will ensure that the package is updated automatically by [`nixpkgs-update`](https://ryantm.github.io/nixpkgs-update) when a new version is released. The [update bot](https://nix-community.org/update-bot) runs periodically to attempt to automatically update packages, and will run `passthru.updateScript` if set. While not strictly necessary if the project is listed on [Repology](https://repology.org), using `nix-update-script` allows the package to update via many more sources (e.g. GitHub releases).···A list of strings passed as additional flags to `make`. These flags are also used by the default install and check phase. For setting make flags specific to the build phase, use `buildFlags` (see below).···A shell array containing additional arguments passed to `make`. You must use this instead of `makeFlags` if the arguments contain spaces, e.g.Note that shell arrays cannot be passed through environment variables, so you cannot set `makeFlagsArray` in a derivation attribute (because those are passed through environment variables): you have to define them in shell code.···Controls whether the check phase is executed. By default it is skipped, but if `doCheck` is set to true, the check phase is usually executed. Thus you should setin the derivation to enable checks. The exception is cross compilation. Cross compiled builds never run tests, no matter how `doCheck` is set, as the newly-built program won’t run on the platform used to build it.············Controls whether the installCheck phase is executed. By default it is skipped, but if `doInstallCheck` is set to true, the installCheck phase is usually executed. Thus you should setin the derivation to enable install checks. The exception is cross compilation. Cross compiled builds never run tests, no matter how `doInstallCheck` is set, as the newly-built program won’t run on the platform used to build it.···As `remove-references-to` is an actual executable and not a shell function, it can be used with `find`.
···············+version="$(curl -sI https://zoom.us/client/latest/zoom_x86_64.tar.xz | grep -Fi 'Location:' | pcre2grep -o1 '/(([0-9]\.?)+)/')"···- [`supportedFeatures`]{#var-passthru-updateScript-set-supportedFeatures} (optional) – a list of the [extra features](#var-passthru-updateScript-supported-features) the script supports.A common pattern is to use the [`nix-update-script`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/common-updater/nix-update.nix) attribute provided in Nixpkgs, which runs [`nix-update`](https://github.com/Mic92/nix-update):For simple packages, this is often enough, and will ensure that the package is updated automatically by [`nixpkgs-update`](https://ryantm.github.io/nixpkgs-update) when a new version is released. The [update bot](https://nix-community.org/update-bot) runs periodically to attempt to automatically update packages, and will run `passthru.updateScript` if set. While not strictly necessary if the project is listed on [Repology](https://repology.org), using `nix-update-script` allows the package to update via many more sources (e.g. GitHub releases).···A list of strings passed as additional flags to `make`. These flags are also used by the default install and check phase. For setting make flags specific to the build phase, use `buildFlags` (see below).···A shell array containing additional arguments passed to `make`. You must use this instead of `makeFlags` if the arguments contain spaces, e.g.Note that shell arrays cannot be passed through environment variables, so you cannot set `makeFlagsArray` in a derivation attribute (because those are passed through environment variables): you have to define them in shell code.···Controls whether the check phase is executed. By default it is skipped, but if `doCheck` is set to true, the check phase is usually executed. Thus you should setin the derivation to enable checks. The exception is cross compilation. Cross compiled builds never run tests, no matter how `doCheck` is set, as the newly-built program won’t run on the platform used to build it.············Controls whether the installCheck phase is executed. By default it is skipped, but if `doInstallCheck` is set to true, the installCheck phase is usually executed. Thus you should setin the derivation to enable install checks. The exception is cross compilation. Cross compiled builds never run tests, no matter how `doInstallCheck` is set, as the newly-built program won’t run on the platform used to build it.···As `remove-references-to` is an actual executable and not a shell function, it can be used with `find`.
+1
-1
doc/using/configuration.chapter.md
+1
-1
doc/using/configuration.chapter.md
+1
-1
doc/using/overlays.chapter.md
+1
-1
doc/using/overlays.chapter.md
+32
-22
doc/using/overrides.chapter.md
+32
-22
doc/using/overrides.chapter.md
···<!-- TODO: move below programlisting to a new section about extending and overlays and reference it -->···In the first example, `pkgs.foo` is the result of a function call with some default arguments, usually a derivation. Using `pkgs.foo.override` will call the same function with the given new arguments.···In the above example, "-bar" is appended to the pname attribute, while all other attributes will be retained from the original `hello` package.···Function arguments can be omitted entirely if there is no need to access `previousAttrs` or `finalAttrs`.In the above example, the `separateDebugInfo` attribute is overridden to be true, thus building debug info for `helloWithDebug`.···In the above example, the `name`, `src`, and `patches` of the derivation will be overridden, while all other attributes will be retained from the original derivation.···The variable `c` is the value of the `f` function applied with some default arguments. Hence the value of `c.result` is `3`, in this example.
···<!-- TODO: move below programlisting to a new section about extending and overlays and reference it -->···In the first example, `pkgs.foo` is the result of a function call with some default arguments, usually a derivation. Using `pkgs.foo.override` will call the same function with the given new arguments.···In the above example, "-bar" is appended to the pname attribute, while all other attributes will be retained from the original `hello` package.···Function arguments can be omitted entirely if there is no need to access `previousAttrs` or `finalAttrs`.In the above example, the `separateDebugInfo` attribute is overridden to be true, thus building debug info for `helloWithDebug`.···In the above example, the `name`, `src`, and `patches` of the derivation will be overridden, while all other attributes will be retained from the original derivation.···The variable `c` is the value of the `f` function applied with some default arguments. Hence the value of `c.result` is `3`, in this example.
+4
-4
maintainers/README.md
+4
-4
maintainers/README.md
······
······
+4
-2
nixos/doc/manual/administration/cleaning-store.chapter.md
+4
-2
nixos/doc/manual/administration/cleaning-store.chapter.md
+8
-4
nixos/doc/manual/administration/container-networking.section.md
+8
-4
nixos/doc/manual/administration/container-networking.section.md
······
······
+6
-2
nixos/doc/manual/administration/control-groups.chapter.md
+6
-2
nixos/doc/manual/administration/control-groups.chapter.md
······
······
+16
-12
nixos/doc/manual/administration/declarative-containers.section.md
+16
-12
nixos/doc/manual/administration/declarative-containers.section.md
······
······
+3
-1
nixos/doc/manual/administration/service-mgmt.chapter.md
+3
-1
nixos/doc/manual/administration/service-mgmt.chapter.md
+3
-3
nixos/doc/manual/configuration/abstractions.section.md
+3
-3
nixos/doc/manual/configuration/abstractions.section.md
+6
-4
nixos/doc/manual/configuration/ad-hoc-network-config.section.md
+6
-4
nixos/doc/manual/configuration/ad-hoc-network-config.section.md
+21
-13
nixos/doc/manual/configuration/adding-custom-packages.section.md
+21
-13
nixos/doc/manual/configuration/adding-custom-packages.section.md
·········
·········
+38
-22
nixos/doc/manual/configuration/config-file.section.md
+38
-22
nixos/doc/manual/configuration/config-file.section.md
························
························
+30
-22
nixos/doc/manual/configuration/customizing-packages.section.md
+30
-22
nixos/doc/manual/configuration/customizing-packages.section.md
············
············
+3
-1
nixos/doc/manual/configuration/declarative-packages.section.md
+3
-1
nixos/doc/manual/configuration/declarative-packages.section.md
+6
-4
nixos/doc/manual/configuration/file-systems.chapter.md
+6
-4
nixos/doc/manual/configuration/file-systems.chapter.md
+12
-6
nixos/doc/manual/configuration/firewall.section.md
+12
-6
nixos/doc/manual/configuration/firewall.section.md
······
······
+34
-24
nixos/doc/manual/configuration/gpu-accel.chapter.md
+34
-24
nixos/doc/manual/configuration/gpu-accel.chapter.md
············
············
+13
-7
nixos/doc/manual/configuration/ipv4-config.section.md
+13
-7
nixos/doc/manual/configuration/ipv4-config.section.md
······
······
+18
-10
nixos/doc/manual/configuration/ipv6-config.section.md
+18
-10
nixos/doc/manual/configuration/ipv6-config.section.md
···
···
+19
-11
nixos/doc/manual/configuration/kubernetes.chapter.md
+19
-11
nixos/doc/manual/configuration/kubernetes.chapter.md
······
······
+34
-20
nixos/doc/manual/configuration/linux-kernel.chapter.md
+34
-20
nixos/doc/manual/configuration/linux-kernel.chapter.md
··················
··················
+22
-12
nixos/doc/manual/configuration/luks-file-systems.section.md
+22
-12
nixos/doc/manual/configuration/luks-file-systems.section.md
···-boot.initrd.luks.devices.crypted.device = "/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d";···-boot.initrd.luks.devices."/dev/sda2".fido2.credential = "f1d00200108b9d6e849a8b388da457688e3dd653b4e53770012d8f28e5d3b269865038c346802f36f3da7278b13ad6a3bb6a1452e24ebeeaa24ba40eef559b1b287d2a2f80b7";······
···+boot.initrd.luks.devices.crypted.device = "/dev/disk/by-uuid/3f6b0024-3a44-4fde-a43a-767b872abe5d";···+boot.initrd.luks.devices."/dev/sda2".fido2.credential = "f1d00200108b9d6e849a8b388da457688e3dd653b4e53770012d8f28e5d3b269865038c346802f36f3da7278b13ad6a3bb6a1452e24ebeeaa24ba40eef559b1b287d2a2f80b7";······
+7
-3
nixos/doc/manual/configuration/modularity.section.md
+7
-3
nixos/doc/manual/configuration/modularity.section.md
·········
·········
+11
-5
nixos/doc/manual/configuration/network-manager.section.md
+11
-5
nixos/doc/manual/configuration/network-manager.section.md
·········
·········
+15
-13
nixos/doc/manual/configuration/overlayfs.section.md
+15
-13
nixos/doc/manual/configuration/overlayfs.section.md
···
···
+5
-3
nixos/doc/manual/configuration/profiles.chapter.md
+5
-3
nixos/doc/manual/configuration/profiles.chapter.md
+12
-8
nixos/doc/manual/configuration/renaming-interfaces.section.md
+12
-8
nixos/doc/manual/configuration/renaming-interfaces.section.md
······
······
+7
-3
nixos/doc/manual/configuration/ssh.section.md
+7
-3
nixos/doc/manual/configuration/ssh.section.md
······
······
+28
-23
nixos/doc/manual/configuration/subversion.chapter.md
+28
-23
nixos/doc/manual/configuration/subversion.chapter.md
······-{ name = "authz_svn"; path = "${pkgs.apacheHttpdPackages.subversion}/modules/mod_authz_svn.so"; }···
······+{ name = "authz_svn"; path = "${pkgs.apacheHttpdPackages.subversion}/modules/mod_authz_svn.so"; }···
+18
-10
nixos/doc/manual/configuration/user-mgmt.chapter.md
+18
-10
nixos/doc/manual/configuration/user-mgmt.chapter.md
············
············
+5
-1
nixos/doc/manual/configuration/wayland.chapter.md
+5
-1
nixos/doc/manual/configuration/wayland.chapter.md
······
······
+23
-17
nixos/doc/manual/configuration/wireless.section.md
+23
-17
nixos/doc/manual/configuration/wireless.section.md
······
······
+92
-52
nixos/doc/manual/configuration/x-windows.chapter.md
+92
-52
nixos/doc/manual/configuration/x-windows.chapter.md
···················································
···················································
+13
-9
nixos/doc/manual/configuration/xfce.chapter.md
+13
-9
nixos/doc/manual/configuration/xfce.chapter.md
···
···
+9
-7
nixos/doc/manual/development/activation-script.section.md
+9
-7
nixos/doc/manual/development/activation-script.section.md
···
···
+2
-2
nixos/doc/manual/development/assertions.section.md
+2
-2
nixos/doc/manual/development/assertions.section.md
+6
-2
nixos/doc/manual/development/etc-overlay.section.md
+6
-2
nixos/doc/manual/development/etc-overlay.section.md
······
+2
-2
nixos/doc/manual/development/meta-attributes.section.md
+2
-2
nixos/doc/manual/development/meta-attributes.section.md
+1
-1
nixos/doc/manual/development/non-switchable-systems.section.md
+1
-1
nixos/doc/manual/development/non-switchable-systems.section.md
+25
-17
nixos/doc/manual/development/option-declarations.section.md
+25
-17
nixos/doc/manual/development/option-declarations.section.md
······
······
+47
-31
nixos/doc/manual/development/option-def.section.md
+47
-31
nixos/doc/manual/development/option-def.section.md
··················
··················
+69
-53
nixos/doc/manual/development/option-types.section.md
+69
-53
nixos/doc/manual/development/option-types.section.md
··················
··················
+21
-19
nixos/doc/manual/development/settings-options.section.md
+21
-19
nixos/doc/manual/development/settings-options.section.md
···
···
+7
-5
nixos/doc/manual/development/unit-handling.section.md
+7
-5
nixos/doc/manual/development/unit-handling.section.md
···
···
+4
-4
nixos/doc/manual/development/writing-modules.chapter.md
+4
-4
nixos/doc/manual/development/writing-modules.chapter.md
+11
-5
nixos/doc/manual/development/writing-nixos-tests.section.md
+11
-5
nixos/doc/manual/development/writing-nixos-tests.section.md
······Tests that are part of NixOS are added to [`nixos/tests/all-tests.nix`](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/all-tests.nix).·········
······Tests that are part of NixOS are added to [`nixos/tests/all-tests.nix`](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/all-tests.nix).·········
+15
-13
nixos/doc/manual/installation/building-images-via-systemd-repart.chapter.md
+15
-13
nixos/doc/manual/installation/building-images-via-systemd-repart.chapter.md
·········
·········
+3
-1
nixos/doc/manual/installation/changing-config.chapter.md
+3
-1
nixos/doc/manual/installation/changing-config.chapter.md
+4
-2
nixos/doc/manual/installation/installing-behind-a-proxy.section.md
+4
-2
nixos/doc/manual/installation/installing-behind-a-proxy.section.md
+11
-7
nixos/doc/manual/installation/installing-from-other-distro.section.md
+11
-7
nixos/doc/manual/installation/installing-from-other-distro.section.md
······
······
+6
-2
nixos/doc/manual/installation/installing-virtualbox-guest.section.md
+6
-2
nixos/doc/manual/installation/installing-virtualbox-guest.section.md
···
···
+7
-3
nixos/doc/manual/installation/upgrading.chapter.md
+7
-3
nixos/doc/manual/installation/upgrading.chapter.md
······
······
+4
-4
nixos/doc/manual/release-notes/rl-1509.section.md
+4
-4
nixos/doc/manual/release-notes/rl-1509.section.md
+2
-2
nixos/doc/manual/release-notes/rl-1703.section.md
+2
-2
nixos/doc/manual/release-notes/rl-1703.section.md
······- Autoloading connection tracking helpers is now disabled by default. This default was also changed in the Linux kernel and is considered insecure if not configured properly in your firewall. If you need connection tracking helpers (i.e. for active FTP) please enable `networking.firewall.autoLoadConntrackHelpers` and tune `networking.firewall.connectionTrackingModules` to suit your needs.
······- Autoloading connection tracking helpers is now disabled by default. This default was also changed in the Linux kernel and is considered insecure if not configured properly in your firewall. If you need connection tracking helpers (i.e. for active FTP) please enable `networking.firewall.autoLoadConntrackHelpers` and tune `networking.firewall.connectionTrackingModules` to suit your needs.
+16
-18
nixos/doc/manual/release-notes/rl-2009.section.md
+16
-18
nixos/doc/manual/release-notes/rl-2009.section.md
···- The remaining configuration flags can now be set directly on the `php` attribute. For example, instead of··················
···- The remaining configuration flags can now be set directly on the `php` attribute. For example, instead of··················
+4
nixos/doc/manual/release-notes/rl-2205.section.md
+4
nixos/doc/manual/release-notes/rl-2205.section.md
······"subsystem=undertow"."server=default-server"."http-listener=default".proxy-address-forwarding = true;···- The MoinMoin wiki engine (`services.moinmoin`) has been removed, because Python 2 is being retired from nixpkgs.
······"subsystem=undertow"."server=default-server"."http-listener=default".proxy-address-forwarding = true;···- The MoinMoin wiki engine (`services.moinmoin`) has been removed, because Python 2 is being retired from nixpkgs.
+5
-3
nixos/doc/manual/release-notes/rl-2211.section.md
+5
-3
nixos/doc/manual/release-notes/rl-2211.section.md
···- `services.github-runner` and `services.github-runners.<name>` gained the option `serviceOverrides` which allows overriding the systemd `serviceConfig`. If you have been overriding the systemd service configuration (i.e., by defining `systemd.services.github-runner.serviceConfig`), you have to use the `serviceOverrides` option now. Example:<!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
···- `services.github-runner` and `services.github-runners.<name>` gained the option `serviceOverrides` which allows overriding the systemd `serviceConfig`. If you have been overriding the systemd service configuration (i.e., by defining `systemd.services.github-runner.serviceConfig`), you have to use the `serviceOverrides` option now. Example:<!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
+38
-26
nixos/doc/manual/release-notes/rl-2305.section.md
+38
-26
nixos/doc/manual/release-notes/rl-2305.section.md
···- NixOS now defaults to using [nsncd](https://github.com/twosigma/nsncd), a non-caching reimplementation of nscd in Rust, as its NSS lookup dispatcher. This replaces the buggy and deprecated nscd implementation provided through glibc. When you find problems, you can switch back by disabling it:- The internal option `boot.bootspec.enable` is now enabled by default because [RFC 0125](https://github.com/NixOS/rfcs/pull/125) was merged. This means you will have a bootspec document called `boot.json` generated for each system and specialisation in the top-level. This is useful to enable advanced boot use cases in NixOS, such as Secure Boot.···- MAC-then-encrypt algorithms were removed from the default selection of `services.openssh.settings.Macs`. If you still require these [MACs](https://en.wikipedia.org/wiki/Message_authentication_code), for example when you are relying on libssh2 (e.g. VLC) or the SSH library shipped on the iPhone, you can re-add them like this:- `podman` now uses the `netavark` network stack. Users will need to delete all of their local containers, images, volumes, etc, by running `podman system reset --force` once before upgrading their systems.···- The default module options for [services.snapserver.openFirewall](#opt-services.snapserver.openFirewall), [services.tmate-ssh-server.openFirewall](#opt-services.tmate-ssh-server.openFirewall) and [services.unifi-video.openFirewall](#opt-services.unifi-video.openFirewall) have been changed from `true` to `false`. You will need to explicitly set this option to `true`, or configure your firewall.···- NixOS swap partitions with random encryption can now control the sector size, cipher, and key size used to set up the plain encryption device over the underlying block device rather than allowing them to be determined by `cryptsetup(8)`. One can use these features like so:- New option `security.pam.zfs` to enable unlocking and mounting of encrypted ZFS home dataset at login.···- PostgreSQL has added opt-in support for [JIT compilation](https://www.postgresql.org/docs/current/jit-reason.html). It can be enabled like this:- `services.netdata` offers a [`services.netdata.deadlineBeforeStopSec`](#opt-services.netdata.deadlineBeforeStopSec) option which will control the deadline (in seconds) after which systemd will consider your netdata instance as dead if it didn't start in the elapsed time. It is helpful when your netdata instance takes longer to start because of a large amount of state or upgrades.
···- NixOS now defaults to using [nsncd](https://github.com/twosigma/nsncd), a non-caching reimplementation of nscd in Rust, as its NSS lookup dispatcher. This replaces the buggy and deprecated nscd implementation provided through glibc. When you find problems, you can switch back by disabling it:- The internal option `boot.bootspec.enable` is now enabled by default because [RFC 0125](https://github.com/NixOS/rfcs/pull/125) was merged. This means you will have a bootspec document called `boot.json` generated for each system and specialisation in the top-level. This is useful to enable advanced boot use cases in NixOS, such as Secure Boot.···- MAC-then-encrypt algorithms were removed from the default selection of `services.openssh.settings.Macs`. If you still require these [MACs](https://en.wikipedia.org/wiki/Message_authentication_code), for example when you are relying on libssh2 (e.g. VLC) or the SSH library shipped on the iPhone, you can re-add them like this:- `podman` now uses the `netavark` network stack. Users will need to delete all of their local containers, images, volumes, etc, by running `podman system reset --force` once before upgrading their systems.···- The default module options for [services.snapserver.openFirewall](#opt-services.snapserver.openFirewall), [services.tmate-ssh-server.openFirewall](#opt-services.tmate-ssh-server.openFirewall) and [services.unifi-video.openFirewall](#opt-services.unifi-video.openFirewall) have been changed from `true` to `false`. You will need to explicitly set this option to `true`, or configure your firewall.···- NixOS swap partitions with random encryption can now control the sector size, cipher, and key size used to set up the plain encryption device over the underlying block device rather than allowing them to be determined by `cryptsetup(8)`. One can use these features like so:- New option `security.pam.zfs` to enable unlocking and mounting of encrypted ZFS home dataset at login.···- PostgreSQL has added opt-in support for [JIT compilation](https://www.postgresql.org/docs/current/jit-reason.html). It can be enabled like this:- `services.netdata` offers a [`services.netdata.deadlineBeforeStopSec`](#opt-services.netdata.deadlineBeforeStopSec) option which will control the deadline (in seconds) after which systemd will consider your netdata instance as dead if it didn't start in the elapsed time. It is helpful when your netdata instance takes longer to start because of a large amount of state or upgrades.
+23
-17
nixos/doc/manual/release-notes/rl-2311.section.md
+23
-17
nixos/doc/manual/release-notes/rl-2311.section.md
·········
·········
+2
-1
nixos/doc/manual/release-notes/rl-2405.section.md
+2
-1
nixos/doc/manual/release-notes/rl-2405.section.md
···- The package `optparse-bash` is now dropped due to upstream inactivity. Alternatives available in Nixpkgs include [`argc`](https://github.com/sigoden/argc), [`argbash`](https://github.com/matejak/argbash), [`bashly`](https://github.com/DannyBen/bashly) and [`gum`](https://github.com/charmbracelet/gum), to name a few.
···- The package `optparse-bash` is now dropped due to upstream inactivity. Alternatives available in Nixpkgs include [`argc`](https://github.com/sigoden/argc), [`argbash`](https://github.com/matejak/argbash), [`bashly`](https://github.com/DannyBen/bashly) and [`gum`](https://github.com/charmbracelet/gum), to name a few.
+35
-21
nixos/modules/i18n/input-method/default.md
+35
-21
nixos/modules/i18n/input-method/default.md
·····················
·····················
+18
-10
nixos/modules/programs/digitalbitbox/default.md
+18
-10
nixos/modules/programs/digitalbitbox/default.md
·········
·········
+3
-1
nixos/modules/programs/plotinus.md
+3
-1
nixos/modules/programs/plotinus.md
+184
-170
nixos/modules/security/acme/default.md
+184
-170
nixos/modules/security/acme/default.md
······-# /var/lib/acme/.challenges must be writable by the ACME user and readable by the Apache user.······-while read x y; do if [ "$x" = "secret" ]; then secret="''${y:1:''${#y}-3}"; fi; done < /var/lib/secrets/dnskeys.conf······
······+# /var/lib/acme/.challenges must be writable by the ACME user and readable by the Apache user.······+while read x y; do if [ "$x" = "secret" ]; then secret="''${y:1:''${#y}-3}"; fi; done < /var/lib/secrets/dnskeys.conf······
+11
-9
nixos/modules/services/audio/castopod.md
+11
-9
nixos/modules/services/audio/castopod.md
···Use the following configuration to start a public instance of Castopod on `castopod.example.com` domain:Go to `https://castopod.example.com/cp-install` to create superadmin account after applying the above configuration.
···Use the following configuration to start a public instance of Castopod on `castopod.example.com` domain:Go to `https://castopod.example.com/cp-install` to create superadmin account after applying the above configuration.
+12
-13
nixos/modules/services/backup/borgbackup.md
+12
-13
nixos/modules/services/backup/borgbackup.md
······
······
+10
-4
nixos/modules/services/databases/foundationdb.md
+10
-4
nixos/modules/services/databases/foundationdb.md
·········
·········
+22
-8
nixos/modules/services/databases/postgresql.md
+22
-8
nixos/modules/services/databases/postgresql.md
···Note that you are required to specify the desired version of PostgreSQL (e.g. `pkgs.postgresql_15`). Since upgrading your PostgreSQL version requires a database dump and reload (see below), NixOS cannot provide a default value for [](#opt-services.postgresql.package) such as the most recent release of PostgreSQL.···By default, PostgreSQL stores its databases in {file}`/var/lib/postgresql/$psqlSchema`. You can override this using [](#opt-services.postgresql.dataDir), e.g.···##### in intermediate oneshot service {#module-services-postgres-initializing-extra-permissions-superuser-oneshot}······##### in service `preStart` {#module-services-postgres-initializing-extra-permissions-service-user-pre-start}···##### in intermediate oneshot service {#module-services-postgres-initializing-extra-permissions-service-user-oneshot}······You can build custom PostgreSQL-with-plugins (to be used outside of NixOS) using function `.withPackages`. For example, creating a custom PostgreSQL package in an overlay can look like:
···Note that you are required to specify the desired version of PostgreSQL (e.g. `pkgs.postgresql_15`). Since upgrading your PostgreSQL version requires a database dump and reload (see below), NixOS cannot provide a default value for [](#opt-services.postgresql.package) such as the most recent release of PostgreSQL.···By default, PostgreSQL stores its databases in {file}`/var/lib/postgresql/$psqlSchema`. You can override this using [](#opt-services.postgresql.dataDir), e.g.···##### in intermediate oneshot service {#module-services-postgres-initializing-extra-permissions-superuser-oneshot}······##### in service `preStart` {#module-services-postgres-initializing-extra-permissions-service-user-pre-start}···##### in intermediate oneshot service {#module-services-postgres-initializing-extra-permissions-service-user-oneshot}······You can build custom PostgreSQL-with-plugins (to be used outside of NixOS) using function `.withPackages`. For example, creating a custom PostgreSQL package in an overlay can look like:
+4
nixos/modules/services/databases/tigerbeetle.md
+4
nixos/modules/services/databases/tigerbeetle.md
···When first started, the TigerBeetle service will create its data file at {file}`/var/lib/tigerbeetle` unless the file already exists, in which case it will just use the existing file.···Note that the TigerBeetle module won't open any firewall ports automatically, so if you configure it to listen on an external interface, you'll need to ensure that connections can reach it:A complete list of options for TigerBeetle can be found [here](#opt-services.tigerbeetle.enable).
···When first started, the TigerBeetle service will create its data file at {file}`/var/lib/tigerbeetle` unless the file already exists, in which case it will just use the existing file.···Note that the TigerBeetle module won't open any firewall ports automatically, so if you configure it to listen on an external interface, you'll need to ensure that connections can reach it:A complete list of options for TigerBeetle can be found [here](#opt-services.tigerbeetle.enable).
+4
nixos/modules/services/desktops/flatpak.md
+4
nixos/modules/services/desktops/flatpak.md
······
······
+1
-1
nixos/modules/services/development/athens.md
+1
-1
nixos/modules/services/development/athens.md
+3
-1
nixos/modules/services/development/livebook.md
+3
-1
nixos/modules/services/development/livebook.md
+8
-4
nixos/modules/services/editors/emacs.md
+8
-4
nixos/modules/services/editors/emacs.md
·········
·········
+48
-42
nixos/modules/services/matrix/maubot.md
+48
-42
nixos/modules/services/matrix/maubot.md
······
······
+18
-16
nixos/modules/services/misc/forgejo.md
+18
-16
nixos/modules/services/misc/forgejo.md
···
···
+41
-37
nixos/modules/services/misc/gitlab.md
+41
-37
nixos/modules/services/misc/gitlab.md
······
······
+3
-3
nixos/modules/services/misc/sourcehut/default.md
+3
-3
nixos/modules/services/misc/sourcehut/default.md
+26
-22
nixos/modules/services/monitoring/certspotter.md
+26
-22
nixos/modules/services/monitoring/certspotter.md
······
······
+65
-59
nixos/modules/services/monitoring/parsedmarc.md
+65
-59
nixos/modules/services/monitoring/parsedmarc.md
·········
·········
+5
-1
nixos/modules/services/monitoring/prometheus/exporters.md
+5
-1
nixos/modules/services/monitoring/prometheus/exporters.md
············
············
+12
-10
nixos/modules/services/networking/firefox-syncserver.md
+12
-10
nixos/modules/services/networking/firefox-syncserver.md
···
···
+40
-33
nixos/modules/services/networking/mosquitto.md
+40
-33
nixos/modules/services/networking/mosquitto.md
······
······
+17
-9
nixos/modules/services/networking/netbird.md
+17
-9
nixos/modules/services/networking/netbird.md
·········the port 51830. Its configuration file will then be located at `/var/lib/netbird-wt1/config.json`.···
·········the port 51830. Its configuration file will then be located at `/var/lib/netbird-wt1/config.json`.···
+84
-78
nixos/modules/services/networking/pleroma.md
+84
-78
nixos/modules/services/networking/pleroma.md
······This is an example of configuration, where [](#opt-services.pleroma.configs) option contains the content of the file `config.exs`, generated [in the first section](#module-services-pleroma-generate-config), but with the secrets (database password, endpoint secret key, salts, etc.) removed. Removing secrets is important, because otherwise they will be stored publicly in the Nix store.Secrets must be moved into a file pointed by [](#opt-services.pleroma.secretConfigFile), in our case `/var/lib/pleroma/secrets.exs`. This file can be created copying the previously generated `config.exs` file and then removing all the settings, except the secrets. This is an example···In this configuration, Pleroma is listening only on the local port 4000. Nginx can be configured as a Reverse Proxy, for forwarding requests from public ports to the Pleroma service. This is an example of configuration, using-add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, Idempotency-Key' always;-add_header 'Access-Control-Expose-Headers' 'Link, X-RateLimit-Reset, X-RateLimit-Limit, X-RateLimit-Remaining, X-Request-Id' always;
······This is an example of configuration, where [](#opt-services.pleroma.configs) option contains the content of the file `config.exs`, generated [in the first section](#module-services-pleroma-generate-config), but with the secrets (database password, endpoint secret key, salts, etc.) removed. Removing secrets is important, because otherwise they will be stored publicly in the Nix store.Secrets must be moved into a file pointed by [](#opt-services.pleroma.secretConfigFile), in our case `/var/lib/pleroma/secrets.exs`. This file can be created copying the previously generated `config.exs` file and then removing all the settings, except the secrets. This is an example···In this configuration, Pleroma is listening only on the local port 4000. Nginx can be configured as a Reverse Proxy, for forwarding requests from public ports to the Pleroma service. This is an example of configuration, using+add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, Idempotency-Key' always;+add_header 'Access-Control-Expose-Headers' 'Link, X-RateLimit-Reset, X-RateLimit-Limit, X-RateLimit-Remaining, X-Request-Id' always;
+30
-26
nixos/modules/services/networking/prosody.md
+30
-26
nixos/modules/services/networking/prosody.md
······Provided the setup detailed in the previous section, you'll need the following acme configuration to generate
······Provided the setup detailed in the previous section, you'll need the following acme configuration to generate
+3
-1
nixos/modules/services/search/meilisearch.md
+3
-1
nixos/modules/services/search/meilisearch.md
+137
-117
nixos/modules/services/web-apps/akkoma.md
+137
-117
nixos/modules/services/web-apps/akkoma.md
···Please refer to the [configuration cheat sheet](https://docs.akkoma.dev/stable/configuration/cheatsheet/)···Please refer to [](#module-security-acme) for details on how to provision an SSL/TLS certificate.·····················-# Adjust these settings according to the database name and upload directory path used by Pleroma···
···Please refer to the [configuration cheat sheet](https://docs.akkoma.dev/stable/configuration/cheatsheet/)···Please refer to [](#module-security-acme) for details on how to provision an SSL/TLS certificate.·····················+# Adjust these settings according to the database name and upload directory path used by Pleroma···
+114
-104
nixos/modules/services/web-apps/discourse.md
+114
-104
nixos/modules/services/web-apps/discourse.md
···············
···············
+12
-10
nixos/modules/services/web-apps/keycloak.md
+12
-10
nixos/modules/services/web-apps/keycloak.md
···
···
+8
-6
nixos/modules/services/web-apps/lemmy.md
+8
-6
nixos/modules/services/web-apps/lemmy.md
+3
-1
nixos/modules/services/web-apps/pict-rs.md
+3
-1
nixos/modules/services/web-apps/pict-rs.md
+1
-1
nixos/modules/services/web-apps/suwayomi-server.md
+1
-1
nixos/modules/services/web-apps/suwayomi-server.md
+53
-35
nixos/modules/services/x11/desktop-managers/gnome.md
+53
-35
nixos/modules/services/x11/desktop-managers/gnome.md
·········It is also possible to disable many of the [core services](https://github.com/NixOS/nixpkgs/blob/b8ec4fd2a4edc4e30d02ba7b1a2cc1358f3db1d5/nixos/modules/services/x11/desktop-managers/gnome.nix#L329-L348). For example, if you do not need indexing files, you can disable Tracker with:Note, however, that doing so is not supported and might break some applications. Notably, GNOME Music cannot work without Tracker.·········GNOME Flashback provides a desktop environment based on the classic GNOME 2 architecture. You can enable the default GNOME Flashback session, which uses the Metacity window manager, with:It is also possible to create custom sessions that replace Metacity with a different window manager using [](#opt-services.xserver.desktopManager.gnome.flashback.customSessions).·········
·········It is also possible to disable many of the [core services](https://github.com/NixOS/nixpkgs/blob/b8ec4fd2a4edc4e30d02ba7b1a2cc1358f3db1d5/nixos/modules/services/x11/desktop-managers/gnome.nix#L329-L348). For example, if you do not need indexing files, you can disable Tracker with:Note, however, that doing so is not supported and might break some applications. Notably, GNOME Music cannot work without Tracker.·········GNOME Flashback provides a desktop environment based on the classic GNOME 2 architecture. You can enable the default GNOME Flashback session, which uses the Metacity window manager, with:It is also possible to create custom sessions that replace Metacity with a different window manager using [](#opt-services.xserver.desktopManager.gnome.flashback.customSessions).·········
+18
-9
nixos/modules/services/x11/desktop-managers/pantheon.md
+18
-9
nixos/modules/services/x11/desktop-managers/pantheon.md
···All of Pantheon is working in NixOS and the applications should be available, aside from a few [exceptions](https://github.com/NixOS/nixpkgs/issues/58161). To enable Pantheon, setThis automatically enables LightDM and Pantheon's LightDM greeter. If you'd like to disable this, setbut please be aware using Pantheon without LightDM as a display manager will break screenlocking from the UI. The NixOS module for Pantheon installs all of Pantheon's default applications. If you'd like to not install Pantheon's apps, setYou can also use [](#opt-environment.pantheon.excludePackages) to remove any other app (like `elementary-mail`).···please note that, like how the NixOS options describe these as extra plugins, this would only add to the default plugins included with the programs. If for some reason you'd like to configure which plugins to use exactly, both packages have an argument for this:
···All of Pantheon is working in NixOS and the applications should be available, aside from a few [exceptions](https://github.com/NixOS/nixpkgs/issues/58161). To enable Pantheon, setThis automatically enables LightDM and Pantheon's LightDM greeter. If you'd like to disable this, setbut please be aware using Pantheon without LightDM as a display manager will break screenlocking from the UI. The NixOS module for Pantheon installs all of Pantheon's default applications. If you'd like to not install Pantheon's apps, setYou can also use [](#opt-environment.pantheon.excludePackages) to remove any other app (like `elementary-mail`).···please note that, like how the NixOS options describe these as extra plugins, this would only add to the default plugins included with the programs. If for some reason you'd like to configure which plugins to use exactly, both packages have an argument for this:
+6
-2
nixos/modules/system/boot/clevis.md
+6
-2
nixos/modules/system/boot/clevis.md
···Then, specify the device you want to decrypt using a given clevis secret. Clevis will automatically try to decrypt the device at boot and will fallback to interactive unlocking if the decryption policy is not fulfilled.
···Then, specify the device you want to decrypt using a given clevis secret. Clevis will automatically try to decrypt the device at boot and will fallback to interactive unlocking if the decryption policy is not fulfilled.
+40
-28
pkgs/README.md
+40
-28
pkgs/README.md
······Otherwise, you can add a `.patch` file to the `nixpkgs` repository. In the interest of keeping our maintenance burden to a minimum, only patches that are unique to `nixpkgs` should be added in this way.···If a patch is available online but does not cleanly apply, it can be modified in some fixed ways by using additional optional arguments for `fetchpatch`. Check [the `fetchpatch` reference](https://nixos.org/manual/nixpkgs/unstable/#fetchpatch) for details.···The throw message should explain in short why the package was removed for users that still have it installed.·········
······Otherwise, you can add a `.patch` file to the `nixpkgs` repository. In the interest of keeping our maintenance burden to a minimum, only patches that are unique to `nixpkgs` should be added in this way.···If a patch is available online but does not cleanly apply, it can be modified in some fixed ways by using additional optional arguments for `fetchpatch`. Check [the `fetchpatch` reference](https://nixos.org/manual/nixpkgs/unstable/#fetchpatch) for details.···The throw message should explain in short why the package was removed for users that still have it installed.·········
+15
-3
pkgs/by-name/README.md
+15
-3
pkgs/by-name/README.md
······The best way to resolve this is to not use `callPackage` directly, such that check 1 doesn't trigger.······This is not required, but the above solution also allows refactoring the definitions into a separate file:···if `callPackage` isn't used underneath and you want the same `.override` arguments for all attributes:···This is not required, but the above solution also allows exposing the package set as an attribute:
······The best way to resolve this is to not use `callPackage` directly, such that check 1 doesn't trigger.······This is not required, but the above solution also allows refactoring the definitions into a separate file:···if `callPackage` isn't used underneath and you want the same `.override` arguments for all attributes:···This is not required, but the above solution also allows exposing the package set as an attribute:
+61
-55
pkgs/development/misc/resholve/README.md
+61
-55
pkgs/development/misc/resholve/README.md
···- [shell.nix from abathur/tdverpy](https://github.com/abathur/tdverpy/blob/e1f956df3ed1c7097a5164e0c85b178772e277f5/shell.nix#L6-L13)······
···- [shell.nix from abathur/tdverpy](https://github.com/abathur/tdverpy/blob/e1f956df3ed1c7097a5164e0c85b178772e277f5/shell.nix#L6-L13)······
+1
-1
pkgs/servers/home-assistant/custom-components/README.md
+1
-1
pkgs/servers/home-assistant/custom-components/README.md
+3
-1
pkgs/servers/home-assistant/custom-lovelace-modules/README.md
+3
-1
pkgs/servers/home-assistant/custom-lovelace-modules/README.md
+11
-9
pkgs/servers/nextcloud/packages/README.md
+11
-9
pkgs/servers/nextcloud/packages/README.md
···
···
+12
-10
pkgs/servers/web-apps/wordpress/packages/README.md
+12
-10
pkgs/servers/web-apps/wordpress/packages/README.md
···
···