Browse Source

Merge commit '12363fb6d89859a37cd7e27f85288599f13e49d9'

Update 2022-08-04
main
Katharina Fey 1 week ago
parent
commit
61c16f5ec8
Signed by: kookie
GPG Key ID: 90734A9E619C8A6C
  1. 5
      infra/libkookie/nixpkgs/unstable/.github/CODEOWNERS
  2. 6
      infra/libkookie/nixpkgs/unstable/.github/workflows/backport.yml
  3. 3
      infra/libkookie/nixpkgs/unstable/.github/workflows/basic-eval.yml
  4. 5
      infra/libkookie/nixpkgs/unstable/.github/workflows/direct-push.yml
  5. 10
      infra/libkookie/nixpkgs/unstable/.github/workflows/nixos-manual.yml
  6. 5
      infra/libkookie/nixpkgs/unstable/.github/workflows/no-channel.yml
  7. 5
      infra/libkookie/nixpkgs/unstable/.github/workflows/pending-clear.yml
  8. 5
      infra/libkookie/nixpkgs/unstable/.github/workflows/pending-set.yml
  9. 10
      infra/libkookie/nixpkgs/unstable/.github/workflows/periodic-merge-24h.yml
  10. 6
      infra/libkookie/nixpkgs/unstable/.github/workflows/periodic-merge-6h.yml
  11. 11
      infra/libkookie/nixpkgs/unstable/.github/workflows/update-terraform-providers.yml
  12. 15
      infra/libkookie/nixpkgs/unstable/doc/builders/images/dockertools.section.md
  13. 13
      infra/libkookie/nixpkgs/unstable/doc/builders/packages/unfree.xml
  14. 20
      infra/libkookie/nixpkgs/unstable/doc/contributing/submitting-changes.chapter.md
  15. 1
      infra/libkookie/nixpkgs/unstable/doc/doc-support/parameters.xml
  16. 4
      infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/coq.section.md
  17. 1
      infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/dotnet.section.md
  18. 6
      infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/go.section.md
  19. 37
      infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/javascript.section.md
  20. 6
      infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/maven.section.md
  21. 26
      infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/perl.section.md
  22. 43
      infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/python.section.md
  23. 2
      infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/ruby.section.md
  24. 114
      infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/vim.section.md
  25. 4
      infra/libkookie/nixpkgs/unstable/doc/stdenv/cross-compilation.chapter.md
  26. 5
      infra/libkookie/nixpkgs/unstable/doc/stdenv/platform-notes.chapter.md
  27. 79
      infra/libkookie/nixpkgs/unstable/doc/stdenv/stdenv.chapter.md
  28. 5
      infra/libkookie/nixpkgs/unstable/doc/using/configuration.chapter.md
  29. 21
      infra/libkookie/nixpkgs/unstable/flake.nix
  30. 13
      infra/libkookie/nixpkgs/unstable/lib/licenses.nix
  31. 1
      infra/libkookie/nixpkgs/unstable/lib/systems/default.nix
  32. 36
      infra/libkookie/nixpkgs/unstable/lib/systems/examples.nix
  33. 1
      infra/libkookie/nixpkgs/unstable/lib/systems/inspect.nix
  34. 4
      infra/libkookie/nixpkgs/unstable/lib/systems/platforms.nix
  35. 2
      infra/libkookie/nixpkgs/unstable/lib/trivial.nix
  36. 6
      infra/libkookie/nixpkgs/unstable/lib/types.nix
  37. 887
      infra/libkookie/nixpkgs/unstable/maintainers/maintainer-list.nix
  38. 160
      infra/libkookie/nixpkgs/unstable/maintainers/scripts/fetch-kde-qt.sh
  39. 52
      infra/libkookie/nixpkgs/unstable/maintainers/scripts/fix-maintainers.pl
  40. 4
      infra/libkookie/nixpkgs/unstable/maintainers/scripts/haskell/hydra-report.hs
  41. 1
      infra/libkookie/nixpkgs/unstable/maintainers/scripts/luarocks-packages.csv
  42. 83
      infra/libkookie/nixpkgs/unstable/maintainers/scripts/mdize-module.sh
  43. 2
      infra/libkookie/nixpkgs/unstable/maintainers/team-list.nix
  44. 35
      infra/libkookie/nixpkgs/unstable/nixos/doc/manual/configuration/adding-custom-packages.section.md
  45. 4
      infra/libkookie/nixpkgs/unstable/nixos/doc/manual/development/writing-nixos-tests.section.md
  46. 116
      infra/libkookie/nixpkgs/unstable/nixos/doc/manual/from_md/configuration/adding-custom-packages.section.xml
  47. 3
      infra/libkookie/nixpkgs/unstable/nixos/doc/manual/from_md/development/writing-nixos-tests.section.xml
  48. 5
      infra/libkookie/nixpkgs/unstable/nixos/doc/manual/from_md/installation/building-nixos.chapter.xml
  49. 21
      infra/libkookie/nixpkgs/unstable/nixos/doc/manual/from_md/installation/installing.chapter.xml
  50. 83
      infra/libkookie/nixpkgs/unstable/nixos/doc/manual/from_md/release-notes/rl-2211.section.xml
  51. 3
      infra/libkookie/nixpkgs/unstable/nixos/doc/manual/installation/building-nixos.chapter.md
  52. 12
      infra/libkookie/nixpkgs/unstable/nixos/doc/manual/installation/installing.chapter.md
  53. 28
      infra/libkookie/nixpkgs/unstable/nixos/doc/manual/release-notes/rl-2211.section.md
  54. 6
      infra/libkookie/nixpkgs/unstable/nixos/lib/eval-config.nix
  55. 2
      infra/libkookie/nixpkgs/unstable/nixos/lib/make-multi-disk-zfs-image.nix
  56. 31
      infra/libkookie/nixpkgs/unstable/nixos/lib/make-options-doc/default.nix
  57. 14
      infra/libkookie/nixpkgs/unstable/nixos/lib/make-options-doc/mergeJSON.py
  58. 2
      infra/libkookie/nixpkgs/unstable/nixos/lib/make-single-disk-zfs-image.nix
  59. 2
      infra/libkookie/nixpkgs/unstable/nixos/lib/qemu-common.nix
  60. 8
      infra/libkookie/nixpkgs/unstable/nixos/lib/test-driver/test_driver/vlan.py
  61. 4
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/appstream.nix
  62. 16
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/console.nix
  63. 56
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/fonts/fontconfig.nix
  64. 8
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/fonts/fontdir.nix
  65. 4
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/fonts/fonts.nix
  66. 2
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/fonts/ghostscript.nix
  67. 2
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/gnu.nix
  68. 2
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/gtk/gtk-icon-cache.nix
  69. 31
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/i18n.nix
  70. 2
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/iproute2.nix
  71. 50
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/krb5/default.nix
  72. 40
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/ldap.nix
  73. 19
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/locale.nix
  74. 28
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/networking.nix
  75. 2
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/no-x-libs.nix
  76. 24
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/nsswitch.nix
  77. 8
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/power-management.nix
  78. 26
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/pulseaudio.nix
  79. 72
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/qt5.nix
  80. 35
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/resolvconf.nix
  81. 24
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/shells-environment.nix
  82. 30
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/swap.nix
  83. 10
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/system-path.nix
  84. 2
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/terminfo.nix
  85. 6
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/unix-odbc-drivers.nix
  86. 102
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/users-groups.nix
  87. 4
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/vte.nix
  88. 4
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/xdg/autostart.nix
  89. 4
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/xdg/icons.nix
  90. 4
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/xdg/menus.nix
  91. 24
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/xdg/mime.nix
  92. 27
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/xdg/portal.nix
  93. 49
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/xdg/portals/lxqt.nix
  94. 4
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/xdg/sounds.nix
  95. 24
      infra/libkookie/nixpkgs/unstable/nixos/modules/config/zram.nix
  96. 2
      infra/libkookie/nixpkgs/unstable/nixos/modules/hardware/acpilight.nix
  97. 8
      infra/libkookie/nixpkgs/unstable/nixos/modules/hardware/all-firmware.nix
  98. 2
      infra/libkookie/nixpkgs/unstable/nixos/modules/hardware/bladeRF.nix
  99. 6
      infra/libkookie/nixpkgs/unstable/nixos/modules/hardware/ckb-next.nix
  100. 2
      infra/libkookie/nixpkgs/unstable/nixos/modules/hardware/cpu/amd-microcode.nix
  101. Some files were not shown because too many files have changed in this diff Show More

5
infra/libkookie/nixpkgs/unstable/.github/CODEOWNERS

@ -48,6 +48,7 @@
/pkgs/build-support/writers @lassulus @Profpatsch
# Nixpkgs documentation
/doc @fricklerhandwerk
/maintainers/scripts/db-to-md.sh @jtojnar @ryantm
/maintainers/scripts/doc @jtojnar @ryantm
/doc/build-aux/pandoc-filters @jtojnar
@ -256,8 +257,8 @@
/pkgs/development/go-packages @kalbasit @Mic92 @zowoq
# GNOME
/pkgs/desktops/gnome @jtojnar @hedning
/pkgs/desktops/gnome/extensions @piegamesde @jtojnar @hedning
/pkgs/desktops/gnome @jtojnar
/pkgs/desktops/gnome/extensions @piegamesde @jtojnar
# Cinnamon
/pkgs/desktops/cinnamon @mkg20001

6
infra/libkookie/nixpkgs/unstable/.github/workflows/backport.yml

@ -8,8 +8,14 @@ on:
# the GitHub repository. This means that it should not evaluate user input in a
# way that allows code injection.
permissions:
contents: read
jobs:
backport:
permissions:
contents: write # for zeebe-io/backport-action to create branch
pull-requests: write # for zeebe-io/backport-action to create PR to backport
name: Backport Pull Request
if: github.repository_owner == 'NixOS' && github.event.pull_request.merged == true && (github.event_name != 'labeled' || startsWith('backport', github.event.label.name))
runs-on: ubuntu-latest

3
infra/libkookie/nixpkgs/unstable/.github/workflows/basic-eval.yml

@ -10,6 +10,9 @@ on:
# branches:
# - master
# - release-**
permissions:
contents: read
jobs:
tests:
runs-on: ubuntu-latest

5
infra/libkookie/nixpkgs/unstable/.github/workflows/direct-push.yml

@ -4,8 +4,13 @@ on:
branches:
- master
- release-**
permissions:
contents: read
jobs:
build:
permissions:
contents: write # for peter-evans/commit-comment to comment on commit
runs-on: ubuntu-latest
if: github.repository_owner == 'NixOS'
env:

10
infra/libkookie/nixpkgs/unstable/.github/workflows/nixos-manual.yml

@ -23,4 +23,12 @@ jobs:
- name: Check DocBook files generated from Markdown are consistent
run: |
nixos/doc/manual/md-to-db.sh
git diff --exit-code
git diff --exit-code || {
echo
echo 'Generated manual files are out of date.'
echo 'Please run'
echo
echo ' nixos/doc/manual/md-to-db.sh'
echo
exit 1
}

5
infra/libkookie/nixpkgs/unstable/.github/workflows/no-channel.yml

@ -6,8 +6,13 @@ on:
- 'nixos-**'
- 'nixpkgs-**'
permissions:
contents: read
jobs:
fail:
permissions:
contents: none
name: "This PR is is targeting a channel branch"
runs-on: ubuntu-latest
steps:

5
infra/libkookie/nixpkgs/unstable/.github/workflows/pending-clear.yml

@ -4,8 +4,13 @@ on:
check_suite:
types: [ completed ]
permissions:
contents: read
jobs:
action:
permissions:
statuses: write
runs-on: ubuntu-latest
steps:
- name: clear pending status

5
infra/libkookie/nixpkgs/unstable/.github/workflows/pending-set.yml

@ -8,8 +8,13 @@ on:
# the GitHub repository. This means that it should not evaluate user input in a
# way that allows code injection.
permissions:
contents: read
jobs:
action:
permissions:
statuses: write
runs-on: ubuntu-latest
steps:
- name: set pending status

10
infra/libkookie/nixpkgs/unstable/.github/workflows/periodic-merge-24h.yml

@ -14,8 +14,14 @@ on:
# Merge every 24 hours
- cron: '0 0 * * *'
permissions:
contents: read
jobs:
periodic-merge:
permissions:
contents: write # for devmasx/merge-branch to merge branches
issues: write # for peter-evans/create-or-update-comment to create or update comment
if: github.repository_owner == 'NixOS'
runs-on: ubuntu-latest
strategy:
@ -28,10 +34,6 @@ jobs:
pairs:
- from: master
into: haskell-updates
- from: release-21.11
into: staging-next-21.11
- from: staging-next-21.11
into: staging-21.11
- from: release-22.05
into: staging-next-22.05
- from: staging-next-22.05

6
infra/libkookie/nixpkgs/unstable/.github/workflows/periodic-merge-6h.yml

@ -14,8 +14,14 @@ on:
# Merge every 6 hours
- cron: '0 */6 * * *'
permissions:
contents: read
jobs:
periodic-merge:
permissions:
contents: write # for devmasx/merge-branch to merge branches
issues: write # for peter-evans/create-or-update-comment to create or update comment
if: github.repository_owner == 'NixOS'
runs-on: ubuntu-latest
strategy:

11
infra/libkookie/nixpkgs/unstable/.github/workflows/update-terraform-providers.yml

@ -2,11 +2,18 @@ name: "Update terraform-providers"
on:
schedule:
- cron: "14 3 * * 1"
- cron: "14 3 * * 0"
workflow_dispatch:
permissions:
contents: read
jobs:
tf-providers:
permissions:
contents: write # for peter-evans/create-pull-request to create branch
issues: write # for peter-evans/create-or-update-comment to create or update comment
pull-requests: write # for peter-evans/create-pull-request to create a PR
if: github.repository_owner == 'NixOS' && github.ref == 'refs/heads/master' # ensure workflow_dispatch only runs on master
runs-on: ubuntu-latest
steps:
@ -32,7 +39,7 @@ jobs:
Check that all providers build with:
```
@ofborg build terraform-full
@ofborg build terraform.full
```
branch: terraform-providers-update
delete-branch: false

15
infra/libkookie/nixpkgs/unstable/doc/builders/images/dockertools.section.md

@ -20,7 +20,12 @@ buildImage {
fromImageName = null;
fromImageTag = "latest";
contents = pkgs.redis;
copyToRoot = pkgs.buildEnv {
name = "image-root";
paths = [ pkgs.redis ];
pathsToLink = [ "/bin" ];
};
runAsRoot = ''
#!${pkgs.runtimeShell}
mkdir -p /data
@ -46,7 +51,7 @@ The above example will build a Docker image `redis/latest` from the given base i
- `fromImageTag` can be used to further specify the tag of the base image within the repository, in case an image contains multiple tags. By default it's `null`, in which case `buildImage` will peek the first tag available for the base image.
- `contents` is a derivation that will be copied in the new layer of the resulting image. This can be similarly seen as `ADD contents/ /` in a `Dockerfile`. By default it's `null`.
- `copyToRoot` is a derivation that will be copied in the new layer of the resulting image. This can be similarly seen as `ADD contents/ /` in a `Dockerfile`. By default it's `null`.
- `runAsRoot` is a bash script that will run as root in an environment that overlays the existing layers of the base image with the new resulting layer, including the previously copied `contents` derivation. This can be similarly seen as `RUN ...` in a `Dockerfile`.
@ -81,7 +86,11 @@ pkgs.dockerTools.buildImage {
name = "hello";
tag = "latest";
created = "now";
contents = pkgs.hello;
copyToRoot = pkgs.buildEnv {
name = "image-root";
paths = [ pkgs.hello ];
pathsToLink = [ "/bin" ];
};
config.Cmd = [ "/bin/hello" ];
}

13
infra/libkookie/nixpkgs/unstable/doc/builders/packages/unfree.xml

@ -1,13 +0,0 @@
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:id="unfree-software">
<title>Unfree software</title>
<para>
All users of Nixpkgs are free software users, and many users (and developers) of Nixpkgs want to limit and tightly control their exposure to unfree software. At the same time, many users need (or want) to run some specific pieces of proprietary software. Nixpkgs includes some expressions for unfree software packages. By default unfree software cannot be installed and doesn’t show up in searches. To allow installing unfree software in a single Nix invocation one can export <literal>NIXPKGS_ALLOW_UNFREE=1</literal>. For a persistent solution, users can set <literal>allowUnfree</literal> in the Nixpkgs configuration.
</para>
<para>
Fine-grained control is possible by defining <literal>allowUnfreePredicate</literal> function in config; it takes the <literal>mkDerivation</literal> parameter attrset and returns <literal>true</literal> for unfree packages that should be allowed.
</para>
</section>

20
infra/libkookie/nixpkgs/unstable/doc/contributing/submitting-changes.chapter.md

@ -167,24 +167,30 @@ Packages with automated tests are much more likely to be merged in a timely fash
### Tested compilation of all pkgs that depend on this change using `nixpkgs-review` {#submitting-changes-tested-compilation}
If you are updating a package’s version, you can use nixpkgs-review to make sure all packages that depend on the updated package still compile correctly. The `nixpkgs-review` utility can look for and build all dependencies either based on uncommited changes with the `wip` option or specifying a github pull request number.
If you are updating a package’s version, you can use `nixpkgs-review` to make sure all packages that depend on the updated package still compile correctly. The `nixpkgs-review` utility can look for and build all dependencies either based on uncommitted changes with the `wip` option or specifying a GitHub pull request number.
review changes from pull request number 12345:
Review changes from pull request number 12345:
```ShellSession
nix run nixpkgs.nixpkgs-review -c nixpkgs-review pr 12345
nix-shell -p nixpkgs-review --run "nixpkgs-review pr 12345"
```
review uncommitted changes:
Alternatively, with flakes (and analogously for the other commands below):
```ShellSession
nix run nixpkgs.nixpkgs-review -c nixpkgs-review wip
nix run nixpkgs#nixpkgs-review -- pr 12345
```
review changes from last commit:
Review uncommitted changes:
```ShellSession
nix run nixpkgs.nixpkgs-review -c nixpkgs-review rev HEAD
nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
```
Review changes from last commit:
```ShellSession
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
```
### Tested execution of all binary files (usually in `./result/bin/`) {#submitting-changes-tested-execution}

1
infra/libkookie/nixpkgs/unstable/doc/doc-support/parameters.xml

@ -11,4 +11,5 @@
<xsl:param name="toc.section.depth" select="0" />
<xsl:param name="admon.style" select="''" />
<xsl:param name="callout.graphics.extension" select="'.svg'" />
<xsl:param name="generate.consistent.ids" select="1" />
</xsl:stylesheet>

4
infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/coq.section.md

@ -5,9 +5,11 @@
The Coq derivation is overridable through the `coq.override overrides`, where overrides is an attribute set which contains the arguments to override. We recommend overriding either of the following
* `version` (optional, defaults to the latest version of Coq selected for nixpkgs, see `pkgs/top-level/coq-packages` to witness this choice), which follows the conventions explained in the `coqPackages` section below,
* `customOCamlPackage` (optional, defaults to `null`, which lets Coq choose a version automatically), which can be set to any of the ocaml packages attribute of `ocaml-ng` (such as `ocaml-ng.ocamlPackages_4_10` which is the default for Coq 8.11 for example).
* `customOCamlPackages` (optional, defaults to `null`, which lets Coq choose a version automatically), which can be set to any of the ocaml packages attribute of `ocaml-ng` (such as `ocaml-ng.ocamlPackages_4_10` which is the default for Coq 8.11 for example).
* `coq-version` (optional, defaults to the short version e.g. "8.10"), is a version number of the form "x.y" that indicates which Coq's version build behavior to mimic when using a source which is not a release. E.g. `coq.override { version = "d370a9d1328a4e1cdb9d02ee032f605a9d94ec7a"; coq-version = "8.10"; }`.
The associated package set can be optained using `mkCoqPackages coq`, where `coq` is the derivation to use.
## Coq packages attribute sets: `coqPackages` {#coq-packages-attribute-sets-coqpackages}
The recommended way of defining a derivation for a Coq library, is to use the `coqPackages.mkCoqDerivation` function, which is essentially a specialization of `mkDerivation` taking into account most of the specifics of Coq libraries. The following attributes are supported:

1
infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/dotnet.section.md

@ -87,6 +87,7 @@ To package Dotnet applications, you can use `buildDotnetModule`. This has simila
* `executables` is used to specify which executables get wrapped to `$out/bin`, relative to `$out/lib/$pname`. If this is unset, all executables generated will get installed. If you do not want to install any, set this to `[]`. This gets done in the `preFixup` phase.
* `runtimeDeps` is used to wrap libraries into `LD_LIBRARY_PATH`. This is how dotnet usually handles runtime dependencies.
* `buildType` is used to change the type of build. Possible values are `Release`, `Debug`, etc. By default, this is set to `Release`.
* `selfContainedBuild` allows to enable the [self-contained](https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained) build flag. By default, it is set to false and generated applications have a dependency on the selected dotnet runtime. If enabled, the dotnet runtime is bundled into the executable and the built app has no dependency on Dotnet.
* `dotnet-sdk` is useful in cases where you need to change what dotnet SDK is being used.
* `dotnet-runtime` is useful in cases where you need to change what dotnet runtime is being used. This can be either a regular dotnet runtime, or an aspnetcore.
* `dotnet-test-sdk` is useful in cases where unit tests expect a different dotnet SDK. By default, this is set to the `dotnet-sdk` attribute.

6
infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/go.section.md

@ -11,8 +11,8 @@ The function `buildGoModule` builds Go programs managed with Go modules. It buil
In the following is an example expression using `buildGoModule`, the following arguments are of special significance to the function:
- `vendorSha256`: is the hash of the output of the intermediate fetcher derivation. `vendorSha256` can also take `null` as an input. When `null` is used as a value, rather than fetching the dependencies and vendoring them, we use the vendoring included within the source repo. If you'd like to not have to update this field on dependency changes, run `go mod vendor` in your source repo and set `vendorSha256 = null;`
- `proxyVendor`: Fetches (go mod download) and proxies the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build or if any dependency has case-insensitive conflicts which will produce platform dependant `vendorSha256` checksums.
- `vendorHash`: is the hash of the output of the intermediate fetcher derivation. `vendorHash` can also take `null` as an input. When `null` is used as a value, rather than fetching the dependencies and vendoring them, we use the vendoring included within the source repo. If you'd like to not have to update this field on dependency changes, run `go mod vendor` in your source repo and set `vendorHash = null;`
- `proxyVendor`: Fetches (go mod download) and proxies the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build or if any dependency has case-insensitive conflicts which will produce platform dependant `vendorHash` checksums.
```nix
pet = buildGoModule rec {
@ -26,7 +26,7 @@ pet = buildGoModule rec {
sha256 = "0m2fzpqxk7hrbxsgqplkg7h2p7gv6s1miymv3gvw0cz039skag0s";
};
vendorSha256 = "1879j77k96684wi554rkjxydrj8g3hpp0kvxz03sd8dmwr3lh83j";
vendorHash = "sha256-ciBIR+a1oaYH+H1PcC8cD8ncfJczk1IiJ8iYNM+R6aA=";
meta = with lib; {
description = "Simple command-line snippet manager, written in Go";

37
infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/javascript.section.md

@ -180,18 +180,27 @@ See `node2nix` [docs](https://github.com/svanderburg/node2nix) for more info.
#### Preparation {#javascript-yarn2nix-preparation}
You will need at least a yarn.lock and yarn.nix file.
You will need at least a `yarn.lock` file. If upstream does not have one you need to generate it and reference it in your package definition.
- Generate a yarn.lock in upstream if it is not already there.
- `yarn2nix > yarn.nix` will generate the dependencies in a Nix format.
If the downloaded files contain the `package.json` and `yarn.lock` files they can be used like this:
```nix
offlineCache = fetchYarnDeps {
yarnLock = src + "/yarn.lock";
sha256 = "....";
};
```
#### mkYarnPackage {#javascript-yarn2nix-mkYarnPackage}
This will by default try to generate a binary. For package only generating static assets (Svelte, Vue, React...), you will need to explicitly override the build step with your instructions. It's important to use the `--offline` flag. For example if you script is `"build": "something"` in package.json use:
`mkYarnPackage` will by default try to generate a binary. For package only generating static assets (Svelte, Vue, React, WebPack, ...), you will need to explicitly override the build step with your instructions.
It's important to use the `--offline` flag. For example if you script is `"build": "something"` in `package.json` use:
```nix
buildPhase = ''
yarn build --offline
export HOME=$(mktemp -d)
yarn --offline build
'';
```
@ -201,15 +210,27 @@ The dist phase is also trying to build a binary, the only way to override it is
distPhase = "true";
```
The configure phase can sometimes fail because it tries to be too clever. One common override is:
The configure phase can sometimes fail because it makes many assumptions which may not always apply. One common override is:
```nix
configurePhase = ''
ln -s $node_modules node_modules
'';
```
or if you need a writeable node_modules directory:
```nix
configurePhase = "ln -s $node_modules node_modules";
configurePhase = ''
cp -r $node_modules node_modules
chmod +w node_modules
'';
```
#### mkYarnModules {#javascript-yarn2nix-mkYarnModules}
This will generate a derivation including the node_modules. If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way. [Plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39) offers a good example of how to do this.
This will generate a derivation including the `node_modules` directory.
If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way.
#### Overriding dependency behavior

6
infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/maven.section.md

@ -233,7 +233,8 @@ in stdenv.mkDerivation rec {
src = builtins.fetchTarball
"https://github.com/fzakaria/nixos-maven-example/archive/main.tar.gz";
buildInputs = [ maven makeWrapper ];
nativeBuildInputs = [ makeWrapper ];
buildInputs = [ maven ];
buildPhase = ''
echo "Using repository ${repository}"
@ -310,7 +311,8 @@ in stdenv.mkDerivation rec {
src = builtins.fetchTarball
"https://github.com/fzakaria/nixos-maven-example/archive/main.tar.gz";
buildInputs = [ maven makeWrapper ];
nativeBuildInputs = [ makeWrapper ];
buildInputs = [ maven ];
buildPhase = ''
echo "Using repository ${repository}"

26
infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/perl.section.md

@ -1,6 +1,6 @@
# Perl {#sec-language-perl}
## Running perl programs on the shell {#ssec-perl-running}
## Running Perl programs on the shell {#ssec-perl-running}
When executing a Perl script, it is possible you get an error such as `./myscript.pl: bad interpreter: /usr/bin/perl: no such file or directory`. This happens when the script expects Perl to be installed at `/usr/bin/perl`, which is not the case when using Perl from nixpkgs. You can fix the script by changing the first line to:
@ -35,15 +35,16 @@ Perl packages from CPAN are defined in [pkgs/top-level/perl-packages.nix](https:
```nix
ClassC3 = buildPerlPackage rec {
name = "Class-C3-0.21";
pname = "Class-C3";
version = "0.21";
src = fetchurl {
url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz";
url = "mirror://cpan/authors/id/F/FL/FLORA/${pname}-${version}.tar.gz";
sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
};
};
```
Note the use of `mirror://cpan/`, and the `${name}` in the URL definition to ensure that the name 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
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
```nix
foo = import ../path/to/foo.nix {
@ -72,10 +73,11 @@ So what does `buildPerlPackage` do? It does the following:
{ buildPerlPackage, fetchurl, db }:
buildPerlPackage rec {
name = "BerkeleyDB-0.36";
pname = "BerkeleyDB";
version = "0.36";
src = fetchurl {
url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz";
url = "mirror://cpan/authors/id/P/PM/PMQS/${pname}-${version}.tar.gz";
sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
};
@ -90,9 +92,10 @@ Dependencies on other Perl packages can be specified in the `buildInputs` and `p
```nix
ClassC3Componentised = buildPerlPackage rec {
name = "Class-C3-Componentised-1.0004";
pname = "Class-C3-Componentised";
version = "1.0004";
src = fetchurl {
url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz";
url = "mirror://cpan/authors/id/A/AS/ASH/${pname}-${version}.tar.gz";
sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
};
propagatedBuildInputs = [
@ -111,7 +114,7 @@ ImageExifTool = buildPerlPackage {
version = "11.50";
src = fetchurl {
url = "https://www.sno.phy.queensu.ca/~phil/exiftool/Image-ExifTool-11.50.tar.gz";
url = "https://www.sno.phy.queensu.ca/~phil/exiftool/${pname}-${version}.tar.gz";
sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3";
};
@ -139,9 +142,10 @@ This program takes a Perl module name, looks it up on CPAN, fetches and unpacks
```ShellSession
$ nix-generate-from-cpan XML::Simple
XMLSimple = buildPerlPackage rec {
name = "XML-Simple-2.22";
pname = "XML-Simple";
version = "2.22";
src = fetchurl {
url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz";
url = "mirror://cpan/authors/id/G/GR/GRANTM/XML-Simple-2.22.tar.gz";
sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
};
propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];

43
infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/python.section.md

@ -602,10 +602,10 @@ been removed, in this case, it's recommended to use `pytestCheckHook`.
#### Using pytestCheckHook {#using-pytestcheckhook}
`pytestCheckHook` is a convenient hook which will substitute the setuptools
`test` command for a checkPhase which runs `pytest`. This is also beneficial
`test` command for a `checkPhase` which runs `pytest`. This is also beneficial
when a package may need many items disabled to run the test suite.
Using the example above, the analagous pytestCheckHook usage would be:
Using the example above, the analagous `pytestCheckHook` usage would be:
```
checkInputs = [ pytestCheckHook ];
@ -624,7 +624,7 @@ Using the example above, the analagous pytestCheckHook usage would be:
];
```
This is expecially useful when tests need to be conditionallydisabled,
This is expecially useful when tests need to be conditionally disabled,
for example:
```
@ -640,31 +640,35 @@ for example:
"socket"
];
```
Trying to concatenate the related strings to disable tests in a regular checkPhase
would be much harder to read. This also enables us to comment on why specific tests
are disabled.
Trying to concatenate the related strings to disable tests in a regular
`checkPhase` would be much harder to read. This also enables us to comment on
why specific tests are disabled.
#### Using pythonImportsCheck {#using-pythonimportscheck}
Although unit tests are highly prefered to validate correctness of a package, not
all packages have test suites that can be ran easily, and some have none at all.
Although unit tests are highly preferred to validate correctness of a package, not
all packages have test suites that can be run easily, and some have none at all.
To help ensure the package still works, `pythonImportsCheck` can attempt to import
the listed modules.
```
pythonImportsCheck = [ "requests" "urllib" ];
```
roughly translates to:
```
postCheck = ''
PYTHONPATH=$out/${python.sitePackages}:$PYTHONPATH
python -c "import requests; import urllib"
'';
```
However, this is done in it's own phase, and not dependent on whether `doCheck = true;`
However, this is done in its own phase, and not dependent on whether `doCheck = true;`.
This can also be useful in verifying that the package doesn't assume commonly
present packages (e.g. `setuptools`)
present packages (e.g. `setuptools`).
#### Using pythonRelaxDepsHook {#using-pythonrelaxdepshook}
@ -719,7 +723,7 @@ pkg3
```
In general you should always use `pythonRelaxDeps`, because `pythonRemoveDeps`
will convert build errors in runtime errors. However `pythonRemoveDeps` may
will convert build errors into runtime errors. However `pythonRemoveDeps` may
still be useful in exceptional cases, and also to remove dependencies wrongly
declared by upstream (for example, declaring `black` as a runtime dependency
instead of a dev dependency).
@ -738,14 +742,14 @@ creates a special link to the project code. That way, you can run updated code
without having to reinstall after each and every change you make. Development
mode is also available. Let's see how you can use it.
In the previous Nix expression the source was fetched from an url. We can also
In the previous Nix expression the source was fetched from a url. We can also
refer to a local source instead using `src = ./path/to/source/tree;`
If we create a `shell.nix` file which calls `buildPythonPackage`, and if `src`
is a local source, and if the local source has a `setup.py`, then development
mode is activated.
In the following example we create a simple environment that has a Python 3.9
In the following example, we create a simple environment that has a Python 3.9
version of our package in it, as well as its dependencies and other packages we
like to have in the environment, all specified with `propagatedBuildInputs`.
Indeed, we can just add any package we like to have in our environment to
@ -862,7 +866,7 @@ Each interpreter has the following attributes:
### Optimizations {#optimizations}
The Python interpreters are by default not build with optimizations enabled, because
The Python interpreters are by default not built with optimizations enabled, because
the builds are in that case not reproducible. To enable optimizations, override the
interpreter of interest, e.g using
@ -913,7 +917,7 @@ and the aliases
#### `buildPythonPackage` function {#buildpythonpackage-function}
The `buildPythonPackage` function is implemented in
`pkgs/development/interpreters/python/mk-python-derivation`
`pkgs/development/interpreters/python/mk-python-derivation.nix`
using setup hooks.
The following is an example:
@ -954,7 +958,7 @@ The `buildPythonPackage` mainly does four things:
* In the `postFixup` phase, the `wrapPythonPrograms` bash function is called to
wrap all programs in the `$out/bin/*` directory to include `$PATH`
environment variable and add dependent libraries to script's `sys.path`.
* In the `installCheck` phase, `${python.interpreter} setup.py test` is ran.
* In the `installCheck` phase, `${python.interpreter} setup.py test` is run.
By default tests are run because `doCheck = true`. Test dependencies, like
e.g. the test runner, should be added to `checkInputs`.
@ -969,7 +973,7 @@ following are specific to `buildPythonPackage`:
* `catchConflicts ? true`: If `true`, abort package build if a package name
appears more than once in dependency tree. Default is `true`.
* `disabled` ? false: If `true`, package is not built for the particular Python
* `disabled ? false`: If `true`, package is not built for the particular Python
interpreter version.
* `dontWrapPythonPrograms ? false`: Skip wrapping of Python programs.
* `permitUserSite ? false`: Skip setting the `PYTHONNOUSERSITE` environment
@ -1421,7 +1425,8 @@ in newpkgs.inkscape
### `python setup.py bdist_wheel` cannot create .whl {#python-setup.py-bdist_wheel-cannot-create-.whl}
Executing `python setup.py bdist_wheel` in a `nix-shell `fails with
Executing `python setup.py bdist_wheel` in a `nix-shell`fails with
```
ValueError: ZIP does not support timestamps before 1980
```
@ -1513,7 +1518,7 @@ in pkgs.mkShell rec {
# the environment.
pythonPackages.python
# This execute some shell code to initialize a venv in $venvDir before
# This executes some shell code to initialize a venv in $venvDir before
# dropping into the shell
pythonPackages.venvShellHook

2
infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/ruby.section.md

@ -274,7 +274,7 @@ bundlerApp {
gemdir = ./.;
exes = [ "r10k" ];
buildInputs = [ makeWrapper ];
nativeBuildInputs = [ makeWrapper ];
postBuild = ''
wrapProgram $out/bin/r10k --prefix PATH : ${lib.makeBinPath [ git gnutar gzip ]}

114
infra/libkookie/nixpkgs/unstable/doc/languages-frameworks/vim.section.md

@ -5,11 +5,9 @@ and additional libraries.
Loading can be deferred; see examples.
At the moment we support three different methods for managing plugins:
At the moment we support two different methods for managing plugins:
- Vim packages (*recommend*)
- VAM (=vim-addon-manager)
- Pathogen
- Vim packages (*recommended*)
- vim-plug
## Custom configuration {#custom-configuration}
@ -45,7 +43,7 @@ neovim.override {
```
If you want to use `neovim-qt` as a graphical editor, you can configure it by overriding Neovim in an overlay
or passing it an overridden Neovimn:
or passing it an overridden Neovim:
```nix
neovim-qt.override {
@ -61,7 +59,7 @@ neovim-qt.override {
## Managing plugins with Vim packages {#managing-plugins-with-vim-packages}
To store you plugins in Vim packages (the native Vim plugin manager, see `:help packages`) the following example can be used:
To store your plugins in Vim packages (the native Vim plugin manager, see `:help packages`) the following example can be used:
```nix
vim_configurable.customize {
@ -110,7 +108,7 @@ The resulting package can be added to `packageOverrides` in `~/.nixpkgs/config.n
};
myNeovim = neovim.override {
configure = {
# add here code from the example section
# add code from the example section here
};
};
};
@ -158,10 +156,10 @@ in
```
### Specificities for some plugins
#### Tree sitter
#### Treesitter
By default `nvim-treesitter` encourages you to download, compile and install
the required tree-sitter grammars at run time with `:TSInstall`. This works
the required Treesitter grammars at run time with `:TSInstall`. This works
poorly on NixOS. Instead, to install the `nvim-treesitter` plugins with a set
of precompiled grammars, you can use `nvim-treesitter.withPlugins` function:
@ -204,7 +202,7 @@ For Neovim the syntax is:
neovim.override {
configure = {
customRC = ''
# here your custom configuration goes!
# your custom configuration goes here!
'';
plug.plugins = with pkgs.vimPlugins; [
vim-go
@ -213,100 +211,6 @@ neovim.override {
}
```
## Managing plugins with VAM {#managing-plugins-with-vam}
### Handling dependencies of Vim plugins {#handling-dependencies-of-vim-plugins}
VAM introduced .json files supporting dependencies without versioning
assuming that "using latest version" is ok most of the time.
### Example {#example}
First create a vim-scripts file having one plugin name per line. Example:
```vim
"tlib"
{'name': 'vim-addon-sql'}
{'filetype_regex': '\%(vim)$', 'names': ['reload', 'vim-dev-plugin']}
```
Such vim-scripts file can be read by VAM as well like this:
```vim
call vam#Scripts(expand('~/.vim-scripts'), {})
```
Create a default.nix file:
```nix
{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7102" }:
nixpkgs.vim_configurable.customize { name = "vim"; vimrcConfig.vam.pluginDictionaries = [ "vim-addon-vim2nix" ]; }
```
Create a generate.vim file:
```vim
ActivateAddons vim-addon-vim2nix
let vim_scripts = "vim-scripts"
call nix#ExportPluginsForNix({
\ 'path_to_nixpkgs': eval('{"'.substitute(substitute(substitute($NIX_PATH, ':', ',', 'g'), '=',':', 'g'), '\([:,]\)', '"\1"',"g").'"}')["nixpkgs"],
\ 'cache_file': '/tmp/vim2nix-cache',
\ 'try_catch': 0,
\ 'plugin_dictionaries': ["vim-addon-manager"]+map(readfile(vim_scripts), 'eval(v:val)')
\ })
```
Then run
```bash
nix-shell -p vimUtils.vim_with_vim2nix --command "vim -c 'source generate.vim'"
```
You should get a Vim buffer with the nix derivations (output1) and vam.pluginDictionaries (output2).
You can add your Vim to your system's configuration file like this and start it by "vim-my":
```nix
my-vim =
let plugins = let inherit (vimUtils) buildVimPluginFrom2Nix; in {
copy paste output1 here
}; in vim_configurable.customize {
name = "vim-my";
vimrcConfig.vam.knownPlugins = plugins; # optional
vimrcConfig.vam.pluginDictionaries = [
copy paste output2 here
];
};
```
Sample output1:
```nix
"reload" = buildVimPluginFrom2Nix { # created by nix#NixDerivation
name = "reload";
src = fetchgit {
url = "https://github.com/xolox/vim-reload";
rev = "0a601a668727f5b675cb1ddc19f6861f3f7ab9e1";
sha256 = "0vb832l9yxj919f5hfg6qj6bn9ni57gnjd3bj7zpq7d4iv2s4wdh";
};
dependencies = ["nim-misc"];
};
[...]
```
Sample output2:
```nix
[
''vim-addon-manager''
''tlib''
{ "name" = ''vim-addon-sql''; }
{ "filetype_regex" = ''\%(vim)$$''; "names" = [ ''reload'' ''vim-dev-plugin'' ]; }
]
```
## Adding new plugins to nixpkgs {#adding-new-plugins-to-nixpkgs}
Nix expressions for Vim plugins are stored in [pkgs/applications/editors/vim/plugins](https://github.com/NixOS/nixpkgs/tree/master/pkgs/applications/editors/vim/plugins). For the vast majority of plugins, Nix expressions are automatically generated by running [`./update.py`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/update.py). This creates a [generated.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/generated.nix) file based on the plugins listed in [vim-plugin-names](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/vim-plugin-names). Plugins are listed in alphabetical order in `vim-plugin-names` using the format `[github username]/[repository]@[gitref]`. For example https://github.com/scrooloose/nerdtree becomes `scrooloose/nerdtree`.
@ -323,7 +227,7 @@ Sometimes plugins require an override that must be changed when the plugin is up
To add a new plugin, run `./update.py --add "[owner]/[name]"`. **NOTE**: This script automatically commits to your git repository. Be sure to check out a fresh branch before running.
Finally, there are some plugins that are also packaged in nodePackages because they have Javascript-related build steps, such as running webpack. Those plugins are not listed in `vim-plugin-names` or managed by `update.py` at all, and are included separately in `overrides.nix`. Currently, all these plugins are related to the `coc.nvim` ecosystem of Language Server Protocol integration with vim/neovim.
Finally, there are some plugins that are also packaged in nodePackages because they have Javascript-related build steps, such as running webpack. Those plugins are not listed in `vim-plugin-names` or managed by `update.py` at all, and are included separately in `overrides.nix`. Currently, all these plugins are related to the `coc.nvim` ecosystem of the Language Server Protocol integration with vim/neovim.
## Updating plugins in nixpkgs {#updating-plugins-in-nixpkgs}

4
infra/libkookie/nixpkgs/unstable/doc/stdenv/cross-compilation.chapter.md vendored

@ -155,14 +155,14 @@ doCheck = stdenv.hostPlatform == stdenv.buildPlatform;
#### Package using Meson needs to run binaries for the host platform during build. {#cross-meson-runs-host-code}
Add `mesonEmulatorHook` cross conditionally to `nativeBuildInputs`.
Add `mesonEmulatorHook` to `nativeBuildInputs` conditionally on if the target binaries can be executed.
e.g.
```
nativeBuildInputs = [
meson
] ++ lib.optionals (stdenv.buildPlatform != stdenv.hostPlatform) [
] ++ lib.optionals (!stdenv.buildPlatform.canExecute stdenv.hostPlatform) [
mesonEmulatorHook
];
```

5
infra/libkookie/nixpkgs/unstable/doc/stdenv/platform-notes.chapter.md vendored

@ -60,3 +60,8 @@ Some common issues when packaging software for Darwin:
```
The package `xcbuild` can be used to build projects that really depend on Xcode. However, this replacement is not 100% compatible with Xcode and can occasionally cause issues.
- x86_64-darwin uses the 10.12 SDK by default, but some software is not compatible with that version of the SDK. In that case,
the 11.0 SDK used by aarch64-darwin is available for use on x86_64-darwin. To use it, reference `apple_sdk_11_0` instead of
`apple_sdk` in your derivation and use `pkgs.darwin.apple_sdk_11_0.callPackage` instead of `pkgs.callPackage`. On Linux, this will
have the same effect as `pkgs.callPackage`, so you can use `pkgs.darwin.apple_sdk_11_0.callPackage` regardless of platform.

79
infra/libkookie/nixpkgs/unstable/doc/stdenv/stdenv.chapter.md vendored

@ -77,7 +77,7 @@ where the builder can do anything it wants, but typically starts with
source $stdenv/setup
```
to let `stdenv` set up the environment (e.g., process the `buildInputs`). If you want, you can still use `stdenv`’s generic builder:
to let `stdenv` set up the environment (e.g. by resetting `PATH` and populating it from build inputs). If you want, you can still use `stdenv`’s generic builder:
```bash
source $stdenv/setup
@ -698,12 +698,12 @@ Hook executed at the end of the install phase.
### The fixup phase {#ssec-fixup-phase}
The fixup phase performs some (Nix-specific) post-processing actions on the files installed under `$out` by the install phase. The default `fixupPhase` does the following:
The fixup phase performs (Nix-specific) post-processing actions on the files installed under `$out` by the install phase. The default `fixupPhase` does the following:
- It moves the `man/`, `doc/` and `info/` subdirectories of `$out` to `share/`.
- It strips libraries and executables of debug information.
- On Linux, it applies the `patchelf` command to ELF executables and libraries to remove unused directories from the `RPATH` in order to prevent unnecessary runtime dependencies.
- It rewrites the interpreter paths of shell scripts to paths found in `PATH`. E.g., `/usr/bin/perl` will be rewritten to `/nix/store/some-perl/bin/perl` found in `PATH`.
- It rewrites the interpreter paths of shell scripts to paths found in `PATH`. E.g., `/usr/bin/perl` will be rewritten to `/nix/store/some-perl/bin/perl` found in `PATH`. See [](#patch-shebangs.sh) for details.
#### Variables controlling the fixup phase {#variables-controlling-the-fixup-phase}
@ -749,7 +749,7 @@ If set, the `patchelf` command is not used to remove unnecessary `RPATH` entries
##### `dontPatchShebangs` {#var-stdenv-dontPatchShebangs}
If set, scripts starting with `#!` do not have their interpreter paths rewritten to paths in the Nix store.
If set, scripts starting with `#!` do not have their interpreter paths rewritten to paths in the Nix store. See [](#patch-shebangs.sh) on how patching shebangs works.
##### `dontPruneLibtoolFiles` {#var-stdenv-dontPruneLibtoolFiles}
@ -983,7 +983,7 @@ addEnvHooks "$hostOffset" myBashFunction
The *existence* of setups hooks has long been documented and packages inside Nixpkgs are free to use this mechanism. Other packages, however, should not rely on these mechanisms not changing between Nixpkgs versions. Because of the existing issues with this system, there’s little benefit from mandating it be stable for any period of time.
First, let’s cover some setup hooks that are part of Nixpkgs default stdenv. This means that they are run for every package built using `stdenv.mkDerivation`. Some of these are platform specific, so they may run on Linux but not Darwin or vice-versa.
First, let’s cover some setup hooks that are part of Nixpkgs default `stdenv`. This means that they are run for every package built using `stdenv.mkDerivation` or when using a custom builder that has `source $stdenv/setup`. Some of these are platform specific, so they may run on Linux but not Darwin or vice-versa.
### `move-docs.sh` {#move-docs.sh}
@ -999,7 +999,70 @@ This runs the strip command on installed binaries and libraries. This removes un
### `patch-shebangs.sh` {#patch-shebangs.sh}
This setup hook patches installed scripts to use the full path to the shebang interpreter. A shebang interpreter is the first commented line of a script telling the operating system which program will run the script (e.g `#!/bin/bash`). In Nix, we want an exact path to that interpreter to be used. This often replaces `/bin/sh` with a path in the Nix store.
This setup hook patches installed scripts to add Nix store paths to their shebang interpreter as found in the build environment. The [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) line tells a Unix-like operating system which interpreter to use to execute the script's contents.
::: note
The [generic builder][generic-builder] populates `PATH` from inputs of the derivation.
:::
[generic-builder]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/stdenv/generic/builder.sh
#### Invocation {#patch-shebangs.sh-invocation}
Multiple paths can be specified.
```
patchShebangs [--build | --host] PATH...
```
##### Flags
`--build`
: Look up commands available at build time
`--host`
: Look up commands available at run time
##### Examples
```sh
patchShebangs --host /nix/store/<hash>-hello-1.0/bin
```
```sh
patchShebangs --build configure
```
`#!/bin/sh` will be rewritten to `#!/nix/store/<hash>-some-bash/bin/sh`.
`#!/usr/bin/env` gets special treatment: `#!/usr/bin/env python` is rewritten to `/nix/store/<hash>/bin/python`.
Interpreter paths that point to a valid Nix store location are not changed.
::: note
A script file must be marked as executable, otherwise it will not be
considered.
:::
This mechanism ensures that the interpreter for a given script is always found and is exactly the one specified by the build.
It can be disabled by setting [`dontPatchShebangs`](#var-stdenv-dontPatchShebangs):
```nix
stdenv.mkDerivation {
# ...
dontPatchShebangs = true;
# ...
}
```
The file [`patch-shebangs.sh`][patch-shebangs.sh] defines the [`patchShebangs`][patchShebangs] function. It is used to implement [`patchShebangsAuto`][patchShebangsAuto], the [setup hook](#ssec-setup-hooks) that is registered to run during the [fixup phase](#ssec-fixup-phase) by default.
If you need to run `patchShebangs` at build time, it must be called explicitly within [one of the build phases](#sec-stdenv-phases).
[patch-shebangs.sh]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/build-support/setup-hooks/patch-shebangs.sh
[patchShebangs]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/build-support/setup-hooks/patch-shebangs.sh#L24-L105
[patchShebangsAuto]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/build-support/setup-hooks/patch-shebangs.sh#L107-L119
### `audit-tmpdir.sh` {#audit-tmpdir.sh}
@ -1155,7 +1218,7 @@ The `validatePkgConfig` hook validates all pkg-config (`.pc`) files in a package
### cmake {#cmake}
Overrides the default configure phase to run the CMake command. By default, we use the Make generator of CMake. In addition, dependencies are added automatically to CMAKE_PREFIX_PATH so that packages are correctly detected by CMake. Some additional flags are passed in to give similar behavior to configure-based packages. You can disable this hook’s behavior by setting configurePhase to a custom value, or by setting dontUseCmakeConfigure. cmakeFlags controls flags passed only to CMake. By default, parallel building is enabled as CMake supports parallel building almost everywhere. When Ninja is also in use, CMake will detect that and use the ninja generator.
Overrides the default configure phase to run the CMake command. By default, we use the Make generator of CMake. In addition, dependencies are added automatically to `CMAKE_PREFIX_PATH` so that packages are correctly detected by CMake. Some additional flags are passed in to give similar behavior to configure-based packages. You can disable this hook’s behavior by setting `configurePhase` to a custom value, or by setting `dontUseCmakeConfigure`. `cmakeFlags` controls flags passed only to CMake. By default, parallel building is enabled as CMake supports parallel building almost everywhere. When Ninja is also in use, CMake will detect that and use the ninja generator.
### xcbuildHook {#xcbuildhook}
@ -1316,7 +1379,7 @@ If the libraries lack `-fPIE`, you will get the error `recompile with -fPIE`.
[^footnote-stdenv-ignored-build-platform]: The build platform is ignored because it is a mere implementation detail of the package satisfying the dependency: As a general programming principle, dependencies are always *specified* as interfaces, not concrete implementation.
[^footnote-stdenv-native-dependencies-in-path]: Currently, this means for native builds all dependencies are put on the `PATH`. But in the future that may not be the case for sake of matching cross: the platforms would be assumed to be unique for native and cross builds alike, so only the `depsBuild*` and `nativeBuildInputs` would be added to the `PATH`.
[^footnote-stdenv-propagated-dependencies]: Nix itself already takes a package’s transitive dependencies into account, but this propagation ensures nixpkgs-specific infrastructure like setup hooks (mentioned above) also are run as if the propagated dependency.
[^footnote-stdenv-propagated-dependencies]: Nix itself already takes a package’s transitive dependencies into account, but this propagation ensures nixpkgs-specific infrastructure like [setup hooks](#ssec-setup-hooks) also are run as if it were a propagated dependency.
[^footnote-stdenv-find-inputs-location]: The `findInputs` function, currently residing in `pkgs/stdenv/generic/setup.sh`, implements the propagation logic.
[^footnote-stdenv-sys-lib-search-path]: It clears the `sys_lib_*search_path` variables in the Libtool script to prevent Libtool from using libraries in `/usr/lib` and such.
[^footnote-stdenv-build-time-guessing-impurity]: Eventually these will be passed building natively as well, to improve determinism: build-time guessing, as is done today, is a risk of impurity.

5
infra/libkookie/nixpkgs/unstable/doc/using/configuration.chapter.md

@ -77,6 +77,11 @@ The difference between a package being unsupported on some system and being brok
## Installing unfree packages {#sec-allow-unfree}
All users of Nixpkgs are free software users, and many users (and developers) of Nixpkgs want to limit and tightly control their exposure to unfree software.
At the same time, many users need (or want) to run some specific pieces of proprietary software.
Nixpkgs includes some expressions for unfree software packages.
By default unfree software cannot be installed and doesn’t show up in searches.
There are several ways to tweak how Nix handles a package which has been marked as unfree.
- To temporarily allow all unfree packages, you can use an environment variable for a single invocation of the nix tools:

21
infra/libkookie/nixpkgs/unstable/flake.nix

@ -20,13 +20,20 @@
nixos = import ./nixos/lib { lib = final; };
nixosSystem = args:
import ./nixos/lib/eval-config.nix (args // {
modules = args.modules ++ [ {
system.nixos.versionSuffix =
".${final.substring 0 8 (self.lastModifiedDate or self.lastModified or "19700101")}.${self.shortRev or "dirty"}";
system.nixos.revision = final.mkIf (self ? rev) self.rev;
} ];
});
import ./nixos/lib/eval-config.nix (
args // {
modules = args.modules ++ [{
system.nixos.versionSuffix =
".${final.substring 0 8 (self.lastModifiedDate or self.lastModified or "19700101")}.${self.shortRev or "dirty"}";
system.nixos.revision = final.mkIf (self ? rev) self.rev;
}];
} // lib.optionalAttrs (! args?system) {
# Allow system to be set modularly in nixpkgs.system.
# We set it to null, to remove the "legacy" entrypoint's
# non-hermetic default.
system = null;
}
);
});
checks.x86_64-linux.tarball = jobs.tarball;

13
infra/libkookie/nixpkgs/unstable/lib/licenses.nix

@ -55,6 +55,12 @@ in mkLicense lset) ({
fullName = "GNU Affero General Public License v3.0 or later";
};
aladdin = {
spdxId = "Aladdin";
fullName = "Aladdin Free Public License";
free = false;
};
amazonsl = {
fullName = "Amazon Software License";
url = "https://aws.amazon.com/asl/";
@ -514,6 +520,13 @@ in mkLicense lset) ({
free = false;
};
databricks-dbx = {
fullName = "DataBricks eXtensions aka dbx License";
url = "https://github.com/databrickslabs/dbx/blob/743b579a4ac44531f764c6e522dbe5a81a7dc0e4/LICENSE";
free = false;
redistributable = false;
};
issl = {
fullName = "Intel Simplified Software License";
url = "https://software.intel.com/en-us/license/intel-simplified-software-license";

1
infra/libkookie/nixpkgs/unstable/lib/systems/default.nix

@ -36,6 +36,7 @@ rec {
config = parse.tripleFromSystem final.parsed;
# Determine whether we can execute binaries built for the provided platform.
canExecute = platform:
final.isAndroid == platform.isAndroid &&
parse.isCompatible final.parsed.cpu platform.parsed.cpu
&& final.parsed.kernel == platform.parsed.kernel;
isCompatible = _: throw "2022-05-23: isCompatible has been removed in favor of canExecute, refer to the 22.11 changelog for details";

36
infra/libkookie/nixpkgs/unstable/lib/systems/examples.nix

@ -57,23 +57,23 @@ rec {
armv7a-android-prebuilt = {
config = "armv7a-unknown-linux-androideabi";
rustc.config = "armv7-linux-androideabi";
sdkVer = "29";
ndkVer = "21";
sdkVer = "28";
ndkVer = "24";
useAndroidPrebuilt = true;
} // platforms.armv7a-android;
aarch64-android-prebuilt = {
config = "aarch64-unknown-linux-android";
rustc.config = "aarch64-linux-android";
sdkVer = "29";
ndkVer = "21";
sdkVer = "28";
ndkVer = "24";
useAndroidPrebuilt = true;
};
aarch64-android = {
config = "aarch64-unknown-linux-android";
sdkVer = "30";
ndkVer = "21";
ndkVer = "24";
libc = "bionic";
useAndroidPrebuilt = false;
useLLVM = true;
@ -91,25 +91,23 @@ rec {
config = "mipsel-unknown-linux-gnu";
} // platforms.fuloong2f_n32;
# MIPS ABI table transcribed from here: https://wiki.debian.org/Multiarch/Tuples
# can execute on 32bit chip
mips-linux-gnu = { config = "mips-linux-gnu"; } // platforms.gcc_mips32r2_o32;
mipsel-linux-gnu = { config = "mipsel-linux-gnu"; } // platforms.gcc_mips32r2_o32;
mipsisa32r6-linux-gnu = { config = "mipsisa32r6-linux-gnu"; } // platforms.gcc_mips32r6_o32;
mipsisa32r6el-linux-gnu = { config = "mipsisa32r6el-linux-gnu"; } // platforms.gcc_mips32r6_o32;
mips-linux-gnu = { config = "mips-unknown-linux-gnu"; } // platforms.gcc_mips32r2_o32;
mipsel-linux-gnu = { config = "mipsel-unknown-linux-gnu"; } // platforms.gcc_mips32r2_o32;
mipsisa32r6-linux-gnu = { config = "mipsisa32r6-unknown-linux-gnu"; } // platforms.gcc_mips32r6_o32;
mipsisa32r6el-linux-gnu = { config = "mipsisa32r6el-unknown-linux-gnu"; } // platforms.gcc_mips32r6_o32;
# require 64bit chip (for more registers, 64-bit floating point, 64-bit "long long") but use 32bit pointers
mips64-linux-gnuabin32 = { config = "mips64-linux-gnuabin32"; } // platforms.gcc_mips64r2_n32;
mips64el-linux-gnuabin32 = { config = "mips64el-linux-gnuabin32"; } // platforms.gcc_mips64r2_n32;
mipsisa64r6-linux-gnuabin32 = { config = "mipsisa64r6-linux-gnuabin32"; } // platforms.gcc_mips64r6_n32;
mipsisa64r6el-linux-gnuabin32 = { config = "mipsisa64r6el-linux-gnuabin32"; } // platforms.gcc_mips64r6_n32;
mips64-linux-gnuabin32 = { config = "mips64-unknown-linux-gnuabin32"; } // platforms.gcc_mips64r2_n32;
mips64el-linux-gnuabin32 = { config = "mips64el-unknown-linux-gnuabin32"; } // platforms.gcc_mips64r2_n32;
mipsisa64r6-linux-gnuabin32 = { config = "mipsisa64r6-unknown-linux-gnuabin32"; } // platforms.gcc_mips64r6_n32;
mipsisa64r6el-linux-gnuabin32 = { config = "mipsisa64r6el-unknown-linux-gnuabin32"; } // platforms.gcc_mips64r6_n32;
# 64bit pointers
mips64-linux-gnuabi64 = { config = "mips64-linux-gnuabi64"; } // platforms.gcc_mips64r2_64;
mips64el-linux-gnuabi64 = { config = "mips64el-linux-gnuabi64"; } // platforms.gcc_mips64r2_64;
mipsisa64r6-linux-gnuabi64 = { config = "mipsisa64r6-linux-gnuabi64"; } // platforms.gcc_mips64r6_64;
mipsisa64r6el-linux-gnuabi64 = { config = "mipsisa64r6el-linux-gnuabi64"; } // platforms.gcc_mips64r6_64;
mips64-linux-gnuabi64 = { config = "mips64-unknown-linux-gnuabi64"; } // platforms.gcc_mips64r2_64;
mips64el-linux-gnuabi64 = { config = "mips64el-unknown-linux-gnuabi64"; } // platforms.gcc_mips64r2_64;
mipsisa64r6-linux-gnuabi64 = { config = "mipsisa64r6-unknown-linux-gnuabi64"; } // platforms.gcc_mips64r6_64;
mipsisa64r6el-linux-gnuabi64 = { config = "mipsisa64r6el-unknown-linux-gnuabi64"; } // platforms.gcc_mips64r6_64;
muslpi = raspberryPi // {
config = "armv6l-unknown-linux-musleabihf";

1
infra/libkookie/nixpkgs/unstable/lib/systems/inspect.nix

@ -16,6 +16,7 @@ rec {
isx86 = { cpu = { family = "x86"; }; };
isAarch32 = { cpu = { family = "arm"; bits = 32; }; };
isAarch64 = { cpu = { family = "arm"; bits = 64; }; };
isAarch = { cpu = { family = "arm"; }; };
isMips = { cpu = { family = "mips"; }; };
isMips32 = { cpu = { family = "mips"; bits = 32; }; };
isMips64 = { cpu = { family = "mips"; bits = 64; }; };

4
infra/libkookie/nixpkgs/unstable/lib/systems/platforms.nix