Merge pull request NixOS#4 from NixOS/master

[pull] master from NixOS:master

ci/OWNERS

@@ -351,6 +351,7 @@ pkgs/by-name/fo/forgejo/                @adamcstephens @bendlas @emilylange
 /pkgs/build-support/node/build-npm-package      @winterqt
 /pkgs/build-support/node/fetch-npm-deps         @winterqt
 /doc/languages-frameworks/javascript.section.md @winterqt
+/pkgs/development/tools/pnpm                    @Scrumplex @gepbird
 
 # OCaml
 /pkgs/build-support/ocaml           @ulrikstrid

doc/README.md

@@ -176,126 +176,138 @@ When needed, each convention explain why it exists, so you can make a decision w
 Note that these conventions are about the **structure** of the manual (and its source files), not about the content that goes in it.
 You, as the writer of documentation, are still in charge of its content.
 
-- Put each sentence in its own line.
-  This makes reviews and suggestions much easier, since GitHub's review system is based on lines.
-  It also helps identifying long sentences at a glance.
+### One sentence per line
 
-- Use the [admonition syntax](#admonitions) for callouts and examples.
+Put each sentence in its own line.
+This makes reviews and suggestions much easier, since GitHub's review system is based on lines.
+It also helps identifying long sentences at a glance.
 
-- Provide at least one example per function, and make examples self-contained.
-  This is easier to understand for beginners.
-  It also helps with testing that it actually works – especially once we introduce automation.
+### Callouts and examples
 
-  Example code should be such that it can be passed to `pkgs.callPackage`.
-  Instead of something like:
+Use the [admonition syntax](#admonitions) for callouts and examples.
 
-  ```nix
-  pkgs.dockerTools.buildLayeredImage {
-    name = "hello";
-    contents = [ pkgs.hello ];
-  }
-  ```
+### Provide self-contained examples
 
-  Write something like:
+Provide at least one example per function, and make examples self-contained.
+This is easier to understand for beginners.
+It also helps with testing that it actually works – especially once we introduce automation.
 
-  ```nix
-  { dockerTools, hello }:
-  dockerTools.buildLayeredImage {
-    name = "hello";
-    contents = [ hello ];
-  }
-  ```
+Example code should be such that it can be passed to `pkgs.callPackage`.
+Instead of something like:
 
-- When showing inputs/outputs of any [REPL](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop), such as a shell or the Nix REPL, use a format as you'd see in the REPL, while trying to visually separate inputs from outputs.
-  This means that for a shell, you should use a format like the following:
-  ```shell
-  $ nix-build -A hello '<nixpkgs>' \
-    --option require-sigs false \
-    --option trusted-substituters file:///tmp/hello-cache \
-    --option substituters file:///tmp/hello-cache
-  /nix/store/zhl06z4lrfrkw5rp0hnjjfrgsclzvxpm-hello-2.12.1
-  ```
-  Note how the input is preceded by `$` on the first line and indented on subsequent lines, and how the output is provided as you'd see on the shell.
+```nix
+pkgs.dockerTools.buildLayeredImage {
+  name = "hello";
+  contents = [ pkgs.hello ];
+}
+```
 
-  For the Nix REPL, you should use a format like the following:
-  ```shell
-  nix-repl> builtins.attrNames { a = 1; b = 2; }
-  [ "a" "b" ]
-  ```
-  Note how the input is preceded by `nix-repl>` and the output is provided as you'd see on the Nix REPL.
+Write something like:
 
-- When documenting functions or anything that has inputs/outputs and example usage, use nested headings to clearly separate inputs, outputs, and examples.
-  Keep examples as the last nested heading, and link to the examples wherever applicable in the documentation.
+```nix
+{ dockerTools, hello }:
+dockerTools.buildLayeredImage {
+  name = "hello";
+  contents = [ hello ];
+}
+```
 
-  The purpose of this convention is to provide a familiar structure for navigating the manual, so any reader can expect to find content related to inputs in an "inputs" heading, examples in an "examples" heading, and so on.
-  An example:
-  ```
-  ## buildImage
+### REPLs
 
-  Some explanation about the function here.
-  Describe a particular scenario, and point to [](#ex-dockerTools-buildImage), which is an example demonstrating it.
+When showing inputs/outputs of any [REPL](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop), such as a shell or the Nix REPL, use a format as you'd see in the REPL, while trying to visually separate inputs from outputs.
+This means that for a shell, you should use a format like the following:
+```shell
+$ nix-build -A hello '<nixpkgs>' \
+  --option require-sigs false \
+  --option trusted-substituters file:///tmp/hello-cache \
+  --option substituters file:///tmp/hello-cache
+/nix/store/zhl06z4lrfrkw5rp0hnjjfrgsclzvxpm-hello-2.12.1
+```
+Note how the input is preceded by `$` on the first line and indented on subsequent lines, and how the output is provided as you'd see on the shell.
 
-  ### Inputs
+For the Nix REPL, you should use a format like the following:
+```shell
+nix-repl> builtins.attrNames { a = 1; b = 2; }
+[ "a" "b" ]
+```
+Note how the input is preceded by `nix-repl>` and the output is provided as you'd see on the Nix REPL.
 
-  Documentation for the inputs of `buildImage`.
-  Perhaps even point to [](#ex-dockerTools-buildImage) again when talking about something specifically linked to it.
+### Headings for inputs, outputs and examples
 
-  ### Passthru outputs
+When documenting functions or anything that has inputs/outputs and example usage, use nested headings to clearly separate inputs, outputs, and examples.
+Keep examples as the last nested heading, and link to the examples wherever applicable in the documentation.
 
-  Documentation for any passthru outputs of `buildImage`.
+The purpose of this convention is to provide a familiar structure for navigating the manual, so any reader can expect to find content related to inputs in an "inputs" heading, examples in an "examples" heading, and so on.
+An example:
+```
+## buildImage
 
-  ### Examples
+Some explanation about the function here.
+Describe a particular scenario, and point to [](#ex-dockerTools-buildImage), which is an example demonstrating it.
 
-  Note that this is the last nested heading in the `buildImage` section.
+### Inputs
 
-  :::{.example #ex-dockerTools-buildImage}
+Documentation for the inputs of `buildImage`.
+Perhaps even point to [](#ex-dockerTools-buildImage) again when talking about something specifically linked to it.
 
-  # Using `buildImage`
+### Passthru outputs
 
-  Example of how to use `buildImage` goes here.
+Documentation for any passthru outputs of `buildImage`.
 
-  :::
-  ```
+### Examples
 
-- Use [definition lists](#definition-lists) to document function arguments, and the attributes of such arguments as well as their [types](https://nixos.org/manual/nix/stable/language/values).
-  For example:
+Note that this is the last nested heading in the `buildImage` section.
 
-  ```markdown
-  # pkgs.coolFunction {#pkgs.coolFunction}
+:::{.example #ex-dockerTools-buildImage}
 
-  `pkgs.coolFunction` *`name`* *`config`*
+# Using `buildImage`
 
-  Description of what `callPackage` does.
+Example of how to use `buildImage` goes here.
 
+:::
+```
+
+### Function arguments
 
-  ## Inputs {#pkgs-coolFunction-inputs}
+Use [definition lists](#definition-lists) to document function arguments, and the attributes of such arguments as well as their [types](https://nixos.org/manual/nix/stable/language/values).
+For example:
 
-  If something's special about `coolFunction`'s general argument handling, you can say so here.
-  Otherwise, just describe the single argument or start the arguments' definition list without introduction.
+```markdown
+# pkgs.coolFunction {#pkgs.coolFunction}
 
-  *`name`* (String)
+`pkgs.coolFunction` *`name`* *`config`*
 
-  : The name of the resulting image.
+Description of what `callPackage` does.
 
-  *`config`* (Attribute set)
 
-  : Introduce the parameter. Maybe you have a test to make sure `{ }` is a sensible default; then you can say: these attributes are optional; `{ }` is a valid argument.
+## Inputs {#pkgs-coolFunction-inputs}
 
-    `outputHash` (String; _optional_)
+If something's special about `coolFunction`'s general argument handling, you can say so here.
+Otherwise, just describe the single argument or start the arguments' definition list without introduction.
 
-    : A brief explanation including when and when not to pass this attribute.
+*`name`* (String)
 
-    : _Default:_ the output path's hash.
-  ```
+: The name of the resulting image.
+
+*`config`* (Attribute set)
+
+: Introduce the parameter. Maybe you have a test to make sure `{ }` is a sensible default; then you can say: these attributes are optional; `{ }` is a valid argument.
+
+  `outputHash` (String; _optional_)
+
+  : A brief explanation including when and when not to pass this attribute.
+
+  : _Default:_ the output path's hash.
+```
 
-  Checklist:
-  - Start with a synopsis, to show the order of positional arguments.
-  - Metavariables are in emphasized code spans: ``` *`arg1`* ```. Metavariables are placeholders where users may write arbitrary expressions. This includes positional arguments.
-  - Attribute names are regular code spans: ``` `attr1` ```. These identifiers can _not_ be picked freely by users, so they are _not_ metavariables.
-  - _optional_ attributes have a _`Default:`_ if it's easily described as a value.
-  - _optional_ attributes have a _`Default behavior:`_ if it's not easily described using a value.
-  - Nix types aren't in code spans, because they are not code
-  - Nix types are capitalized, to distinguish them from the camelCase Module System types, which _are_ code and behave like functions.
+Checklist:
+- Start with a synopsis, to show the order of positional arguments.
+- Metavariables are in emphasized code spans: ``` *`arg1`* ```. Metavariables are placeholders where users may write arbitrary expressions. This includes positional arguments.
+- Attribute names are regular code spans: ``` `attr1` ```. These identifiers can _not_ be picked freely by users, so they are _not_ metavariables.
+- _optional_ attributes have a _`Default:`_ if it's easily described as a value.
+- _optional_ attributes have a _`Default behavior:`_ if it's not easily described using a value.
+- Nix types aren't in code spans, because they are not code
+- Nix types are capitalized, to distinguish them from the camelCase Module System types, which _are_ code and behave like functions.
 
 #### Examples
 

doc/languages-frameworks/gnome.section.md

@@ -155,9 +155,11 @@ There are no schemas available in `XDG_DATA_DIRS`. Temporarily add a random pack
 
 Package is missing some GSettings schemas. You can find out the package containing the schema with `nix-locate org.gnome.foo.gschema.xml` and let the hooks handle the wrapping as [above](#ssec-gnome-common-issues-no-schemas).
 
-### When using `wrapGApps*` hook with special derivers you can end up with double wrapped binaries. {#ssec-gnome-common-issues-double-wrapped}
+### When using `wrapGApps*` hook with special derivers or hooks you can end up with double wrapped binaries. {#ssec-gnome-common-issues-double-wrapped}
 
-This is because derivers like `python.pkgs.buildPythonApplication` or `qt5.mkDerivation` have setup-hooks automatically added that produce wrappers with makeWrapper. The simplest way to workaround that is to disable the `wrapGApps*` hook automatic wrapping with `dontWrapGApps = true;` and pass the arguments it intended to pass to makeWrapper to another.
+This is because some setup hooks like `qt6.wrapQtAppsHook` also wrap programs using `makeWrapper`.  Likewise, some derivers (e.g. `python.pkgs.buildPythonApplication`) automatically pull in their own setup hooks that produce wrappers.
+
+The simplest workaround is to disable the `wrapGApps*` hook's automatic wrapping using `dontWrapGApps = true;` while passing its `makeWrapper` arguments to another wrapper.
 
 In the case of a Python application it could look like:
 
@@ -184,19 +186,19 @@ python3.pkgs.buildPythonApplication {
 And for a QT app like:
 
 ```nix
-mkDerivation {
+stdenv.mkDerivation {
   pname = "calibre";
   version = "3.47.0";
 
   nativeBuildInputs = [
     wrapGAppsHook3
+    qt6.wrapQtAppsHook
     qmake
     # ...
   ];
 
   dontWrapGApps = true;
 
-  # Arguments to be passed to `makeWrapper`, only used by qt5’s mkDerivation
   preFixup = ''
     qtWrapperArgs+=("''${gappsWrapperArgs[@]}")
   '';

doc/packages/darwin-builder.section.md

@@ -100,7 +100,7 @@ $ sudo launchctl kickstart -k system/org.nixos.nix-daemon
     darwin-builder = nixpkgs.lib.nixosSystem {
       system = linuxSystem;
       modules = [
-        "${nixpkgs}/nixos/modules/profiles/macos-builder.nix"
+        "${nixpkgs}/nixos/modules/profiles/nix-builder-vm.nix"
         { virtualisation = {
             host.pkgs = pkgs;
             darwin-builder.workingDirectory = "/var/lib/darwin-builder";
@@ -158,7 +158,7 @@ in the example below and rebuild.
     darwin-builder = nixpkgs.lib.nixosSystem {
       system = linuxSystem;
       modules = [
-        "${nixpkgs}/nixos/modules/profiles/macos-builder.nix"
+        "${nixpkgs}/nixos/modules/profiles/nix-builder-vm.nix"
         {
           virtualisation.host.pkgs = pkgs;
           virtualisation.darwin-builder.diskSize = 5120;
@@ -185,6 +185,6 @@ nix-repl> darwin.linux-builder.nixosConfig.nix.package
 «derivation /nix/store/...-nix-2.17.0.drv»
 
 nix-repl> :p darwin.linux-builder.nixosOptions.virtualisation.memorySize.definitionsWithLocations
-[ { file = "/home/user/src/nixpkgs/nixos/modules/profiles/macos-builder.nix"; value = 3072; } ]
+[ { file = "/home/user/src/nixpkgs/nixos/modules/profiles/nix-builder-vm.nix"; value = 3072; } ]
 
 ```

doc/stdenv/cross-compilation.chapter.md

@@ -181,6 +181,31 @@ Example of an error which this fixes.
 
 `[Errno 8] Exec format error: './gdk3-scan'`
 
+#### Using `-static` outside a `isStatic` platform. {#cross-static-on-non-static-platform}
+
+Add `stdenv.cc.libc.static` (static output of glibc) to `buildInputs` conditionally on if `hostPlatform` uses `glibc`.
+
+
+e.g.
+
+```nix
+{
+  buildInputs = lib.optionals (stdenv.hostPlatform.libc == "glibc") [ stdenv.cc.libc.static ];
+}
+```
+
+Examples of errors which this fixes.
+
+`cannot find -lm: No such file or directory`
+
+`cannot find -lc: No such file or directory`
+
+::: {.note}
+At the time of writing it is assumed the issue only happens on `glibc` because it splits the static libraries in to a different output.
+
+::: {.note}
+You may want to look in to using `stdenvAdapters.makeStatic` or `pkgsStatic` or a `isStatic = true` platform.
+
 ## Cross-building packages {#sec-cross-usage}
 
 Nixpkgs can be instantiated with `localSystem` alone, in which case there is no cross-compiling and everything is built by and for that system, or also with `crossSystem`, in which case packages run on the latter, but all building happens on the former. Both parameters take the same schema as the 3 (build, host, and target) platforms defined in the previous section. As mentioned above, `lib.systems.examples` has some platforms which are used as arguments for these parameters in practice. You can use them programmatically, or on the command line:

doc/stdenv/multiple-output.chapter.md

@@ -21,7 +21,7 @@ In the Nix language the individual outputs can be reached explicitly as attribut
 
 When a multiple-output derivation gets into a build input of another derivation, the `dev` output is added if it exists, otherwise the first output is added. In addition to that, `propagatedBuildOutputs` of that package which by default contain `$outputBin` and `$outputLib` are also added. (See [](#multiple-output-file-type-groups).)
 
-In some cases it may be desirable to combine different outputs under a single store path. A function `symlinkJoin` can be used to do this. (Note that it may negate some closure size benefits of using a multiple-output package.)
+In some cases it may be desirable to combine different outputs under a single store path. The `symlinkJoin` builder can be used to do this. (See [](#trivial-builder-symlinkJoin)). Note that this may negate some closure size benefits of using a multiple-output package.
 
 ## Writing a split derivation {#sec-multiple-outputs-}