diff --git a/doc/README.md b/doc/README.md index a060876969c9..6f452f1ba744 100644 --- a/doc/README.md +++ b/doc/README.md @@ -293,7 +293,7 @@ Though this is not shown in the rendered documentation on nixos.org. #### Figures -To define a referencable figure use the following fencing: +To define a referenceable figure use the following fencing: ```markdown ::: {.figure #nixos-logo} diff --git a/doc/build-helpers/trivial-build-helpers.chapter.md b/doc/build-helpers/trivial-build-helpers.chapter.md index a56f6d097989..5d4ede836a1b 100644 --- a/doc/build-helpers/trivial-build-helpers.chapter.md +++ b/doc/build-helpers/trivial-build-helpers.chapter.md @@ -241,7 +241,7 @@ Write a text file to the Nix store. `allowSubstitutes` (Bool, _optional_) : Whether to allow substituting from a binary cache. - Passed through to [`allowSubsitutes`](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-allowSubstitutes) of the underlying call to `builtins.derivation`. + Passed through to [`allowSubstitutes`](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-allowSubstitutes) of the underlying call to `builtins.derivation`. It defaults to `false`, as running the derivation's simple `builder` executable locally is assumed to be faster than network operations. Set it to true if the `checkPhase` step is expensive. @@ -453,7 +453,7 @@ writeTextFile { ### `writeScriptBin` {#trivial-builder-writeScriptBin} -Write a script within a `bin` subirectory of a directory in the Nix store. +Write a script within a `bin` subdirectory of a directory in the Nix store. This is for consistency with the convention of software packages placing executables under `bin`. `writeScriptBin` takes the following arguments: diff --git a/doc/languages-frameworks/javascript.section.md b/doc/languages-frameworks/javascript.section.md index 7975d7c9e43f..dbb0a78b2874 100644 --- a/doc/languages-frameworks/javascript.section.md +++ b/doc/languages-frameworks/javascript.section.md @@ -233,7 +233,7 @@ If these are not defined, `npm pack` may miss some files, and no binaries will b * `npmPruneFlags`: Flags to pass to `npm prune`. Defaults to the value of `npmInstallFlags`. * `makeWrapperArgs`: Flags to pass to `makeWrapper`, added to executable calling the generated `.js` with `node` as an interpreter. These scripts are defined in `package.json`. * `nodejs`: The `nodejs` package to build against, using the corresponding `npm` shipped with that version of `node`. Defaults to `pkgs.nodejs`. -* `npmDeps`: The dependencies used to build the npm package. Especially useful to not have to recompute workspace depedencies. +* `npmDeps`: The dependencies used to build the npm package. Especially useful to not have to recompute workspace dependencies. #### prefetch-npm-deps {#javascript-buildNpmPackage-prefetch-npm-deps} diff --git a/doc/languages-frameworks/nim.section.md b/doc/languages-frameworks/nim.section.md index 71e3ae25a86d..fd97746c6938 100644 --- a/doc/languages-frameworks/nim.section.md +++ b/doc/languages-frameworks/nim.section.md @@ -88,7 +88,7 @@ For example, to propagate a dependency on SDL2 for lockfiles that select the Nim } ``` -The annotations in the `nim-overrides.nix` set are functions that take two arguments and return a new attrset to be overlayed on the package being built. +The annotations in the `nim-overrides.nix` set are functions that take two arguments and return a new attrset to be overlaid on the package being built. - lockAttrs: the attrset for this library from within a lockfile. This can be used to implement library version constraints, such as marking libraries as broken or insecure. - prevAttrs: the attrset produced by initial arguments to `buildNimPackage` and any preceding lockfile overlays. diff --git a/lib/fileset/README.md b/lib/fileset/README.md index 93e0199c32a4..646de07e669a 100644 --- a/lib/fileset/README.md +++ b/lib/fileset/README.md @@ -236,7 +236,7 @@ File sets cannot add single files to the store, they can only import files under Arguments: - (+) There's no point in using this library for a single file, since you can't do anything other than add it to the store or not. And it would be unclear how the library should behave if the one file wouldn't be added to the store: - `toSource { root = ./file.nix; fileset = ; }` has no reasonable result because returing an empty store path wouldn't match the file type, and there's no way to have an empty file store path, whatever that would mean. + `toSource { root = ./file.nix; fileset = ; }` has no reasonable result because returning an empty store path wouldn't match the file type, and there's no way to have an empty file store path, whatever that would mean. ### `fileFilter` takes a path diff --git a/nixos/doc/manual/configuration/luks-file-systems.section.md b/nixos/doc/manual/configuration/luks-file-systems.section.md index 4d2f625073d4..b20957b40b89 100644 --- a/nixos/doc/manual/configuration/luks-file-systems.section.md +++ b/nixos/doc/manual/configuration/luks-file-systems.section.md @@ -90,7 +90,7 @@ as [Trezor](https://trezor.io/). ### systemd Stage 1 {#sec-luks-file-systems-fido2-systemd} -If systemd stage 1 is enabled, it handles unlocking of LUKS-enrypted volumes +If systemd stage 1 is enabled, it handles unlocking of LUKS-encrypted volumes during boot. The following example enables systemd stage1 and adds support for unlocking the existing LUKS2 volume `root` using any enrolled FIDO2 compatible tokens. diff --git a/nixos/doc/manual/development/unit-handling.section.md b/nixos/doc/manual/development/unit-handling.section.md index 1f6a30d6ef34..deb120b9fadd 100644 --- a/nixos/doc/manual/development/unit-handling.section.md +++ b/nixos/doc/manual/development/unit-handling.section.md @@ -75,7 +75,7 @@ units". "Normal" systemd units, by default, are ordered AFTER `sysinit.target`. In other words, these "normal" units expect all services ordered before -`sysinit.target` to have finished without explicity declaring this dependency +`sysinit.target` to have finished without explicitly declaring this dependency relationship for each dependency. See the [systemd bootup](https://www.freedesktop.org/software/systemd/man/latest/bootup.html) for more details on the bootup process. diff --git a/nixos/doc/manual/release-notes/rl-2205.section.md b/nixos/doc/manual/release-notes/rl-2205.section.md index dad45f12373e..e729fdcbb139 100644 --- a/nixos/doc/manual/release-notes/rl-2205.section.md +++ b/nixos/doc/manual/release-notes/rl-2205.section.md @@ -824,7 +824,7 @@ In addition to numerous new and upgraded packages, this release has the followin Configurations using this default will print a warning when rebuilt. - `security.acme` certificates will now correctly check for CA - revokation before reaching their minimum age. + revocation before reaching their minimum age. - Removing domains from `security.acme.certs._name_.extraDomainNames` will now correctly remove those domains during rebuild/renew. diff --git a/nixos/doc/manual/release-notes/rl-2405.section.md b/nixos/doc/manual/release-notes/rl-2405.section.md index 5b097ad4c2a2..3bb993ec33c6 100644 --- a/nixos/doc/manual/release-notes/rl-2405.section.md +++ b/nixos/doc/manual/release-notes/rl-2405.section.md @@ -365,7 +365,7 @@ The pre-existing [services.ankisyncd](#opt-services.ankisyncd.enable) has been m This means that configuration now has to be done using [environment variables](https://hexdocs.pm/livebook/readme.html#environment-variables) instead of command line arguments. This has the further consequence that the `livebook` service configuration has changed. -- `lua` interpreters default LUA_PATH and LUA_CPATH are not overriden by nixpkgs +- `lua` interpreters default LUA_PATH and LUA_CPATH are not overridden by nixpkgs anymore, we patch LUA_ROOT instead which is more respectful to upstream. - `luarocks-packages-updater`'s .csv format, used to define lua packages to be updated, has changed: `src` (URL of a git repository) has now become `rockspec` (URL of a rockspec) to remove ambiguity regarding which rockspec to use and simplify implementation. @@ -730,7 +730,7 @@ Use `services.pipewire.extraConfig` or `services.pipewire.configPackages` for Pi - `services.postgresql.extraPlugins`' type has expanded. Previously it was a list of packages, now it can also be a function that returns such a list. For example a config line like ``services.postgresql.extraPlugins = with pkgs.postgresql_11.pkgs; [ postgis ];`` is recommended to be changed to ``services.postgresql.extraPlugins = ps: with ps; [ postgis ];``; -- `services.slskd` has been refactored to include more configuation options in +- `services.slskd` has been refactored to include more configuration options in the free-form `services.slskd.settings` option, and some defaults (including listen ports) have been changed to match the upstream defaults. Additionally, disk logging is now disabled by default, and the log rotation timer has been removed. @@ -758,7 +758,7 @@ Use `services.pipewire.extraConfig` or `services.pipewire.configPackages` for Pi - `systemd` units can now specify the `Upholds=` and `UpheldBy=` unit dependencies via the aptly named `upholds` and `upheldBy` options. These options get systemd to enforce that the - dependencies remain continuosly running for as long as the dependent unit is in a running state. + dependencies remain continuously running for as long as the dependent unit is in a running state. - A stdenv's default set of hardening flags can now be set via its `bintools-wrapper`'s `defaultHardeningFlags` argument. A convenient stdenv adapter, `withDefaultHardeningFlags`, can be used to override an existing stdenv's `defaultHardeningFlags`. diff --git a/pkgs/applications/networking/cluster/k3s/docs/ONBOARDING_MAINTAINER.md b/pkgs/applications/networking/cluster/k3s/docs/ONBOARDING_MAINTAINER.md index 3ee0897b5768..9c2365d6f2dd 100644 --- a/pkgs/applications/networking/cluster/k3s/docs/ONBOARDING_MAINTAINER.md +++ b/pkgs/applications/networking/cluster/k3s/docs/ONBOARDING_MAINTAINER.md @@ -24,13 +24,13 @@ Only consensus is required to move forward any proposal. Consensus meaning the a If you cause a regression (we've all been there), you are responsible for fixing it, but in case you can't fix it (it happens), feel free to ask for help. That's fine, just let us know. -To merge code, you need to be a commiter, or use the merge-bot, but currently the merge-bot only works for packages located at `pkgs/by-name/`, which means, K3s still need to be migrated there before you can use merge-bot for merging. As a non-commiter, once you have approved a PR you need to forward the request to a commiter. For deciding which commiter, give preference initially to K3s commiters, but any commiter can commit. A commiter usually has a green approval in PRs. +To merge code, you need to be a committer, or use the merge-bot, but currently the merge-bot only works for packages located at `pkgs/by-name/`, which means, K3s still need to be migrated there before you can use merge-bot for merging. As a non-committer, once you have approved a PR you need to forward the request to a committer. For deciding which committer, give preference initially to K3s committers, but any committer can commit. A committer usually has a green approval in PRs. -K3s's commiters currently are: superherointj, marcusramberg, Mic92. +K3s's committers currently are: superherointj, marcusramberg, Mic92. @euank is often silent but still active and has always handled anything dreadful, internal parts of K3s/Kubernetes or architecture things, he initially packaged K3s for nixpkgs, think of him as a last resort, when we fail to accomplish a fix, he comes to rescue us from ourselves. -@mic92 stepped up when @superherointj stepped down a time ago, as Mic92 has a broad responsibility in nixpkgs (he is responsible for far too many things already, nixpkgs-reviews, sops-nix, release manager, bot-whatever), we avoid giving him chore work for `nixos-unstable`, only pick him as commiter last. As Mic92 runs K3s in a `nixos-stable` setting, he might help in testing stable backports. +@mic92 stepped up when @superherointj stepped down a time ago, as Mic92 has a broad responsibility in nixpkgs (he is responsible for far too many things already, nixpkgs-reviews, sops-nix, release manager, bot-whatever), we avoid giving him chore work for `nixos-unstable`, only pick him as committer last. As Mic92 runs K3s in a `nixos-stable` setting, he might help in testing stable backports. On how to handle requests, it's the usual basics, such as, when reviewing PRs, issues, be welcoming, helpful, provide hints whenever possible, try to move things forward, assume good will, ignore [as don't react to] any negativity [since it spirals badly], delay and sort any (severe) disagreement in private. Even on disagrements, be thankful to people for their dedicated time, no matter what happens. In essence, on any unfortunate event, **always put people over code**. diff --git a/pkgs/applications/networking/cluster/k3s/docs/VERSIONING.md b/pkgs/applications/networking/cluster/k3s/docs/VERSIONING.md index c1347b1f861e..191af0058453 100644 --- a/pkgs/applications/networking/cluster/k3s/docs/VERSIONING.md +++ b/pkgs/applications/networking/cluster/k3s/docs/VERSIONING.md @@ -11,7 +11,7 @@ afoul of the upstream version skew policy. ## Patch Release Support Lifecycle -K3s is built on top of K8s and typically provides a similar release cadence and support window (simply by cherry-picking over k8s patches). As such, we assume k3s's support lifecycle is identical to upstream K8s. The upstream K8s release and support lifecycle, including maintenance and end-of-life dates for current releases, is documented [on their suppport site](https://kubernetes.io/releases/patch-releases/#support-period). A more tabular view of the current support timeline can also be found on [endoflife.date](https://endoflife.date/kubernetes). +K3s is built on top of K8s and typically provides a similar release cadence and support window (simply by cherry-picking over k8s patches). As such, we assume k3s's support lifecycle is identical to upstream K8s. The upstream K8s release and support lifecycle, including maintenance and end-of-life dates for current releases, is documented [on their support site](https://kubernetes.io/releases/patch-releases/#support-period). A more tabular view of the current support timeline can also be found on [endoflife.date](https://endoflife.date/kubernetes). In short, a new Kubernetes version is released roughly every 4 months and each release is supported for a little over 1 year. diff --git a/pkgs/development/cuda-modules/README.md b/pkgs/development/cuda-modules/README.md index 76732c5ddfb3..fadf5664de0d 100644 --- a/pkgs/development/cuda-modules/README.md +++ b/pkgs/development/cuda-modules/README.md @@ -23,7 +23,7 @@ scope. These are typically required for the creation of the finalized ## Top-level directories - `cuda`: CUDA redistributables! Provides extension to `cudaPackages` scope. -- `cudatoolkit`: monolothic CUDA Toolkit run-file installer. Provides extension +- `cudatoolkit`: monolithic CUDA Toolkit run-file installer. Provides extension to `cudaPackages` scope. - `cudnn`: NVIDIA cuDNN library. - `cutensor`: NVIDIA cuTENSOR library. diff --git a/pkgs/development/tools/build-managers/gradle/README.md b/pkgs/development/tools/build-managers/gradle/README.md index f52779132c81..bdfca72f61f3 100644 --- a/pkgs/development/tools/build-managers/gradle/README.md +++ b/pkgs/development/tools/build-managers/gradle/README.md @@ -23,7 +23,7 @@ Obviously, this is horrible for reproducibility. Additionally, Gradle doesn't offer a way to export the list of dependency URLs and hashes (it does in a way, but it's far from being complete, and as such is useless for nixpkgs). Even if did, it would be annoying to use considering -fetching non-Gradle dependendencies in Gradle scripts is commonplace. +fetching non-Gradle dependencies in Gradle scripts is commonplace. That's why the setup hook uses mitm-cache, a program designed for intercepting all HTTP requests, recording all the files that were