Compare commits

..

3 Commits

Author SHA1 Message Date
Robert Hensing
4fd048a763 doc/as-a-function: Command line us of system and crossSystem are ok 2024-09-30 12:13:35 +02:00
Robert Hensing
eaa3ff4461 doc/as-a-function: Edit 2024-09-30 12:13:35 +02:00
Robert Hensing
274eb695e4 nixpkgs: Allow passing {host,build}Platform directly instead of *[sS]ystem
This new interface has already been applied successfully in NixOS.
`nixos-generate-hardware` has been generating the "default" hostPlatform
in `hardware-configuration.nix` for over a year now [without much trouble],
and with the benefit of not having to specify `system` (or similar) in
`nixosSystem` anymore.
Furthermore, the `hostPlatform` option is always defined and reliably
produces the host platform for users who don't use the legacy options.
This is in contrast to `nixpkgs.crossSystem`, which is usually not
even defined, and `nixpkgs.localSystem` which is usually the wrong
platform to refer to in a config file.

Ideally we'd clean up the `nixpkgs.{system,localSystem,crossSystem}`
options to reduce complexity and confusion. But the interface in
Nixpkgs is still based on the old terminology and behavior.
By introducing these parameters also in Nixpkgs, the users' experience
with NixOS carries over to Nixpkgs as well.

Further simplifications in the code base are now possible, specifically

- stage.nix and related files still work with {local,cross}System,
  and have logic like

      ${if stdenv.hostPlatform == stdenv.buildPlatform
        then "localSystem" else "crossSystem"} = <...>

  ... which is really just

      hostPlatform = <...>

  This can now be simplified by refactoring this code to work with
  {host,build}Platform variables instead.

- NixOS can forward its platform options directly to its Nixpkgs call.
  This pays off when the `*[sS]ystem` options are removed.

[without much trouble]: https://github.com/NixOS/nixpkgs/pull/237218
2024-09-30 12:13:35 +02:00
21781 changed files with 480663 additions and 629622 deletions

View File

@@ -40,9 +40,6 @@ d1c1a0c656ccd8bd3b25d3c4287f2d075faf3cf3
# fix indentation in meteor default.nix
a37a6de881ec4c6708e6b88fd16256bbc7f26bbd
# pkgs/stdenv/make-derivation: Reindent
b4cc2a2479a7ab0f6440b2e1319221920ef72699
# treewide: automatically md-convert option descriptions
2e751c0772b9d48ff6923569adfa661b030ab6a2
@@ -163,21 +160,9 @@ ad815aebfbfe1415ff6436521d545029c803c3fb
# nixos/nvidia: apply nixfmt-rfc-style (#313440)
fbdcdde04a7caa007e825a8b822c75fab9adb2d6
# treewide: reformat files which need reformatting after (#341407)
e0464e47880a69896f0fb1810f00e0de469f770a
# step-cli: format package.nix with nixfmt (#331629)
fc7a83f8b62e90de5679e993d4d49ca014ea013d
# ndn-cxx: format with nixfmt-rfc-style
160b2b769c3b8a6d1ae9947afa77520fa2887db7
# ndn-tools: format with nixfmt-rfc-style
4882ef721ce3d7bb3b5e48ff80125255db515013
# nfd: format with nixfmt-rfc-style
548c2377fa81e2abfc192fbf4f521e601251c468
# darwin.stdenv: format with nixfmt-rfc-style (#333962)
93c10ac9e561c6594d3baaeaff2341907390d9b8
@@ -189,20 +174,3 @@ cffc27daf06c77c0d76bc35d24b929cb9d68c3c9
# fetchurl: nixfmt-rfc-style
ce21e97a1f20dee15da85c084f9d1148d84f853b
# percona: apply nixfmt
8d14fa2886fec877690c6d28cfcdba4503dbbcea
# nixos/virtualisation: format image-related files
# Original formatting commit that was reverted
04fadac429ca7d6b92025188652376c230205730
# Revert commit
4cec81a9959ce612b653860dcca53101a36f328a
# Final commit that does the formatting
88b285c01d84de82c0b2b052fd28eaf6709c2d26
# sqlc: format with nixfmt
2bdec131b2bb2c8563f4556d741d34ccb77409e2
# treewide: migrate packages to pkgs/by-name, take 1
571c71e6f73af34a229414f51585738894211408

2
.gitattributes vendored
View File

@@ -16,5 +16,3 @@ nixos/doc/default.nix linguist-documentation=false
nixos/modules/module-list.nix merge=union
# pkgs/top-level/all-packages.nix merge=union
ci/OWNERS linguist-language=CODEOWNERS

392
.github/CODEOWNERS vendored Normal file
View File

@@ -0,0 +1,392 @@
# CODEOWNERS file
#
# This file is used to describe who owns what in this repository. This file does not
# replace `meta.maintainers` but is instead used for other things than derivations
# and modules, like documentation, package sets, and other assets.
#
# For documentation on this file, see https://help.github.com/articles/about-codeowners/
# Mentioned users will get code review requests.
#
# IMPORTANT NOTE: in order to actually get pinged, commit access is required.
# This also holds true for GitHub teams. Since almost none of our teams have write
# permissions, you need to list all members of the team with commit access individually.
# CI
/.github/workflows @NixOS/Security @Mic92 @zowoq
/.github/workflows/check-nix-format.yml @infinisil
/.github/workflows/nixpkgs-vet.yml @infinisil @philiptaron
/ci @infinisil @philiptaron @NixOS/Security
# Development support
/.editorconfig @Mic92 @zowoq
/shell.nix @infinisil @NixOS/Security
# Libraries
/lib @infinisil
/lib/systems @alyssais @ericson2314
/lib/generators.nix @infinisil @Profpatsch
/lib/cli.nix @infinisil @Profpatsch
/lib/debug.nix @infinisil @Profpatsch
/lib/asserts.nix @infinisil @Profpatsch
/lib/path.* @infinisil
/lib/fileset @infinisil
## Libraries / Module system
/lib/modules.nix @infinisil @roberth
/lib/types.nix @infinisil @roberth
/lib/options.nix @infinisil @roberth
/lib/tests/modules.sh @infinisil @roberth
/lib/tests/modules @infinisil @roberth
# Nixpkgs Internals
/default.nix @Ericson2314
/pkgs/top-level/default.nix @Ericson2314
/pkgs/top-level/impure.nix @Ericson2314
/pkgs/top-level/stage.nix @Ericson2314
/pkgs/top-level/splice.nix @Ericson2314
/pkgs/top-level/release-cross.nix @Ericson2314
/pkgs/top-level/by-name-overlay.nix @infinisil @philiptaron
/pkgs/stdenv @philiptaron
/pkgs/stdenv/generic @Ericson2314
/pkgs/stdenv/generic/check-meta.nix @Ericson2314
/pkgs/stdenv/cross @Ericson2314
/pkgs/build-support @philiptaron
/pkgs/build-support/cc-wrapper @Ericson2314
/pkgs/build-support/bintools-wrapper @Ericson2314
/pkgs/build-support/setup-hooks @Ericson2314
/pkgs/build-support/setup-hooks/auto-patchelf.sh @layus
/pkgs/build-support/setup-hooks/auto-patchelf.py @layus
/pkgs/pkgs-lib @infinisil
## Format generators/serializers
/pkgs/pkgs-lib/formats/libconfig @h7x4
/pkgs/pkgs-lib/formats/hocon @h7x4
# Nixpkgs build-support
/pkgs/build-support/writers @lassulus @Profpatsch
# Nixpkgs make-disk-image
/doc/build-helpers/images/makediskimage.section.md @raitobezarius
/nixos/lib/make-disk-image.nix @raitobezarius
# Nix, the package manager
# @raitobezarius is not "code owner", but is listed here to be notified of changes
# pertaining to the Nix package manager.
# i.e. no authority over those files.
pkgs/tools/package-management/nix/ @NixOS/nix-team @raitobezarius
nixos/modules/installer/tools/nix-fallback-paths.nix @NixOS/nix-team @raitobezarius
# Nixpkgs documentation
/maintainers/scripts/db-to-md.sh @jtojnar @ryantm
/maintainers/scripts/doc @jtojnar @ryantm
# Contributor documentation
/CONTRIBUTING.md @infinisil
/.github/PULL_REQUEST_TEMPLATE.md @infinisil
/doc/contributing/ @infinisil
/doc/contributing/contributing-to-documentation.chapter.md @jtojnar @infinisil
/lib/README.md @infinisil
/doc/README.md @infinisil
/nixos/README.md @infinisil
/pkgs/README.md @infinisil
/pkgs/by-name/README.md @infinisil
/maintainers/README.md @infinisil
# User-facing development documentation
/doc/development.md @infinisil
/doc/development @infinisil
# NixOS Internals
/nixos/default.nix @infinisil
/nixos/lib/from-env.nix @infinisil
/nixos/lib/eval-config.nix @infinisil
/nixos/modules/system/activation/bootspec.nix @grahamc @cole-h @raitobezarius
/nixos/modules/system/activation/bootspec.cue @grahamc @cole-h @raitobezarius
# NixOS integration test driver
/nixos/lib/test-driver @tfc
# NixOS QEMU virtualisation
/nixos/virtualisation/qemu-vm.nix @raitobezarius
# ACME
/nixos/modules/security/acme @arianvp @flokli @aanderse @emilazy # no merge permission: @m1cr0man
# Systemd
/nixos/modules/system/boot/systemd.nix @NixOS/systemd
/nixos/modules/system/boot/systemd @NixOS/systemd
/nixos/lib/systemd-*.nix @NixOS/systemd
/pkgs/os-specific/linux/systemd @NixOS/systemd
# Systemd-boot
/nixos/modules/system/boot/loader/systemd-boot @JulienMalka
# Images and installer media
/nixos/modules/profiles/installation-device.nix @ElvishJerricco
/nixos/modules/installer/cd-dvd/ @ElvishJerricco
/nixos/modules/installer/sd-card/
# Updaters
## update.nix
/maintainers/scripts/update.nix @jtojnar
/maintainers/scripts/update.py @jtojnar
## common-updater-scripts
/pkgs/common-updater/scripts/update-source-version @jtojnar
# Python-related code and docs
/doc/languages-frameworks/python.section.md @mweinelt @natsukium
/maintainers/scripts/update-python-libraries @natsukium
/pkgs/development/interpreters/python @natsukium
/pkgs/top-level/python-packages.nix @natsukium
/pkgs/top-level/release-python.nix @natsukium
# Haskell
/doc/languages-frameworks/haskell.section.md @sternenseemann @maralorn
/maintainers/scripts/haskell @sternenseemann @maralorn
/pkgs/development/compilers/ghc @sternenseemann @maralorn
/pkgs/development/haskell-modules @sternenseemann @maralorn
/pkgs/test/haskell @sternenseemann @maralorn
/pkgs/top-level/release-haskell.nix @sternenseemann @maralorn
/pkgs/top-level/haskell-packages.nix @sternenseemann @maralorn
# Perl
/pkgs/development/interpreters/perl @stigtsp @zakame @marcusramberg
/pkgs/top-level/perl-packages.nix @stigtsp @zakame @marcusramberg
/pkgs/development/perl-modules @stigtsp @zakame @marcusramberg
# R
/pkgs/applications/science/math/R @jbedo
/pkgs/development/r-modules @jbedo
# Rust
/pkgs/development/compilers/rust @Mic92 @zowoq @winterqt @figsoda
/pkgs/build-support/rust @zowoq @winterqt @figsoda
/doc/languages-frameworks/rust.section.md @zowoq @winterqt @figsoda
# C compilers
/pkgs/development/compilers/gcc
/pkgs/development/compilers/llvm @alyssais @RossComputerGuy
/pkgs/development/compilers/emscripten @raitobezarius
/doc/languages-frameworks/emscripten.section.md @raitobezarius
# Audio
/nixos/modules/services/audio/botamusique.nix @mweinelt
/nixos/modules/services/audio/snapserver.nix @mweinelt
/nixos/tests/modules/services/audio/botamusique.nix @mweinelt
/nixos/tests/snapcast.nix @mweinelt
# Browsers
/pkgs/applications/networking/browsers/firefox @mweinelt
/pkgs/applications/networking/browsers/chromium @emilylange
/nixos/tests/chromium.nix @emilylange
# Certificate Authorities
pkgs/data/misc/cacert/ @ajs124 @lukegb @mweinelt
pkgs/development/libraries/nss/ @ajs124 @lukegb @mweinelt
pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
# Jetbrains
/pkgs/applications/editors/jetbrains @edwtjo
# Licenses
/lib/licenses.nix @alyssais
# Qt
/pkgs/development/libraries/qt-5 @K900 @NickCao @SuperSandro2000 @ttuegel
/pkgs/development/libraries/qt-6 @K900 @NickCao @SuperSandro2000 @ttuegel
# KDE / Plasma 5
/pkgs/applications/kde @K900 @NickCao @SuperSandro2000 @ttuegel
/pkgs/desktops/plasma-5 @K900 @NickCao @SuperSandro2000 @ttuegel
/pkgs/development/libraries/kde-frameworks @K900 @NickCao @SuperSandro2000 @ttuegel
# KDE / Plasma 6
/pkgs/kde @K900 @NickCao @SuperSandro2000 @ttuegel
/maintainers/scripts/kde @K900 @NickCao @SuperSandro2000 @ttuegel
# PostgreSQL and related stuff
/pkgs/servers/sql/postgresql @thoughtpolice
/nixos/modules/services/databases/postgresql.xml @thoughtpolice
/nixos/modules/services/databases/postgresql.nix @thoughtpolice
/nixos/tests/postgresql.nix @thoughtpolice
# Hardened profile & related modules
/nixos/modules/profiles/hardened.nix @joachifm
/nixos/modules/security/hidepid.nix @joachifm
/nixos/modules/security/lock-kernel-modules.nix @joachifm
/nixos/modules/security/misc.nix @joachifm
/nixos/tests/hardened.nix @joachifm
/pkgs/os-specific/linux/kernel/hardened-config.nix @joachifm
# Home Automation
/nixos/modules/services/misc/home-assistant.nix @mweinelt
/nixos/modules/services/misc/zigbee2mqtt.nix @mweinelt
/nixos/tests/home-assistant.nix @mweinelt
/nixos/tests/zigbee2mqtt.nix @mweinelt
/pkgs/servers/home-assistant @mweinelt
/pkgs/tools/misc/esphome @mweinelt
# Network Time Daemons
/pkgs/tools/networking/chrony @thoughtpolice
/pkgs/tools/networking/ntp @thoughtpolice
/pkgs/tools/networking/openntpd @thoughtpolice
/nixos/modules/services/networking/ntp @thoughtpolice
# Network
/pkgs/tools/networking/kea/default.nix @mweinelt
/pkgs/tools/networking/babeld/default.nix @mweinelt
/nixos/modules/services/networking/babeld.nix @mweinelt
/nixos/modules/services/networking/kea.nix @mweinelt
/nixos/modules/services/networking/knot.nix @mweinelt
/nixos/modules/services/monitoring/prometheus/exporters/kea.nix @mweinelt
/nixos/tests/babeld.nix @mweinelt
/nixos/tests/kea.nix @mweinelt
/nixos/tests/knot.nix @mweinelt
# Web servers
/doc/packages/nginx.section.md @raitobezarius
/pkgs/servers/http/nginx/ @raitobezarius
/nixos/modules/services/web-servers/nginx/ @raitobezarius
# Dhall
/pkgs/development/dhall-modules @Gabriella439 @Profpatsch @ehmry
/pkgs/development/interpreters/dhall @Gabriella439 @Profpatsch @ehmry
# Idris
/pkgs/development/idris-modules @Infinisil
/pkgs/development/compilers/idris2 @mattpolzin
# Bazel
/pkgs/development/tools/build-managers/bazel @Profpatsch
# NixOS modules for e-mail and dns services
/nixos/modules/services/mail/mailman.nix @peti
/nixos/modules/services/mail/postfix.nix @peti
/nixos/modules/services/networking/bind.nix @peti
/nixos/modules/services/mail/rspamd.nix @peti
# Emacs
/pkgs/applications/editors/emacs/elisp-packages @adisbladis
/pkgs/applications/editors/emacs @adisbladis
/pkgs/top-level/emacs-packages.nix @adisbladis
# Kakoune
/pkgs/applications/editors/kakoune @philiptaron
# Neovim
/pkgs/applications/editors/neovim @figsoda @teto
# VimPlugins
/pkgs/applications/editors/vim/plugins @figsoda
# VsCode Extensions
/pkgs/applications/editors/vscode/extensions
# PHP interpreter, packages, extensions, tests and documentation
/doc/languages-frameworks/php.section.md @aanderse @drupol @globin @ma27 @talyz
/nixos/tests/php @aanderse @drupol @globin @ma27 @talyz
/pkgs/build-support/php/build-pecl.nix @aanderse @drupol @globin @ma27 @talyz
/pkgs/build-support/php @drupol
/pkgs/development/interpreters/php @jtojnar @aanderse @drupol @globin @ma27 @talyz
/pkgs/development/php-packages @aanderse @drupol @globin @ma27 @talyz
/pkgs/top-level/php-packages.nix @jtojnar @aanderse @drupol @globin @ma27 @talyz
# Docker tools
/pkgs/build-support/docker @roberth
/nixos/tests/docker-tools* @roberth
/doc/build-helpers/images/dockertools.section.md @roberth
# Blockchains
/pkgs/applications/blockchains @mmahut @RaghavSood
# Go
/doc/languages-frameworks/go.section.md @kalbasit @katexochen @Mic92 @zowoq
/pkgs/build-support/go @kalbasit @katexochen @Mic92 @zowoq
/pkgs/development/compilers/go @kalbasit @katexochen @Mic92 @zowoq
# GNOME
/pkgs/desktops/gnome @jtojnar
/pkgs/desktops/gnome/extensions @jtojnar
/pkgs/build-support/make-hardcode-gsettings-patch @jtojnar
# Cinnamon
/pkgs/by-name/ci/cinnamon-* @mkg20001
/pkgs/by-name/cj/cjs @mkg20001
/pkgs/by-name/mu/muffin @mkg20001
/pkgs/by-name/ne/nemo @mkg20001
/pkgs/by-name/ne/nemo-* @mkg20001
# nim
/pkgs/development/compilers/nim @ehmry
/pkgs/development/nim-packages @ehmry
/pkgs/top-level/nim-packages.nix @ehmry
# terraform providers
/pkgs/applications/networking/cluster/terraform-providers @zowoq
# Forgejo
nixos/modules/services/misc/forgejo.nix @adamcstephens @bendlas @emilylange
pkgs/by-name/fo/forgejo/ @adamcstephens @bendlas @emilylange
# Dotnet
/pkgs/build-support/dotnet @corngood
/pkgs/development/compilers/dotnet @corngood
/pkgs/test/dotnet @corngood
/doc/languages-frameworks/dotnet.section.md @corngood
# Node.js
/pkgs/build-support/node/build-npm-package @winterqt
/pkgs/build-support/node/fetch-npm-deps @winterqt
/doc/languages-frameworks/javascript.section.md @winterqt
# OCaml
/pkgs/build-support/ocaml @ulrikstrid
/pkgs/development/compilers/ocaml @ulrikstrid
/pkgs/development/ocaml-modules @ulrikstrid
# ZFS
pkgs/os-specific/linux/zfs/2_1.nix @raitobezarius
pkgs/os-specific/linux/zfs/generic.nix @raitobezarius
nixos/modules/tasks/filesystems/zfs.nix @raitobezarius
nixos/tests/zfs.nix @raitobezarius
# Zig
/pkgs/development/compilers/zig @figsoda
/doc/hooks/zig.section.md @figsoda
# Buildbot
nixos/modules/services/continuous-integration/buildbot @Mic92 @zowoq
nixos/tests/buildbot.nix @Mic92 @zowoq
pkgs/development/tools/continuous-integration/buildbot @Mic92 @zowoq
# Pretix
pkgs/by-name/pr/pretix/ @mweinelt
pkgs/by-name/pr/pretalx/ @mweinelt
nixos/modules/services/web-apps/pretix.nix @mweinelt
nixos/modules/services/web-apps/pretalx.nix @mweinelt
nixos/tests/web-apps/pretix.nix @mweinelt
nixos/tests/web-apps/pretalx.nix @mweinelt
# incus/lxc
nixos/maintainers/scripts/incus/ @adamcstephens
nixos/modules/virtualisation/incus.nix @adamcstephens
nixos/modules/virtualisation/lxc* @adamcstephens
nixos/tests/incus/ @adamcstephens
pkgs/by-name/in/incus/ @adamcstephens
pkgs/by-name/lx/lxc* @adamcstephens
# ExpidusOS, Flutter
/pkgs/development/compilers/flutter @RossComputerGuy
/pkgs/desktops/expidus @RossComputerGuy
# GNU Tar & Zip
/pkgs/tools/archivers/gnutar @RossComputerGuy
/pkgs/tools/archivers/zip @RossComputerGuy
# SELinux
/pkgs/os-specific/linux/checkpolicy @RossComputerGuy
/pkgs/os-specific/linux/libselinux @RossComputerGuy
/pkgs/os-specific/linux/libsepol @RossComputerGuy
# installShellFiles
/pkgs/by-name/in/installShellFiles/* @Ericson2314
/pkgs/test/install-shell-files/* @Ericson2314
/doc/hooks/installShellFiles.section.md @Ericson2314

View File

@@ -8,4 +8,4 @@
## Technical details
<!-- Please insert the output of running `nix-shell -p nix-info --run "nix-info -m"` below this line -->
Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.

View File

@@ -7,44 +7,38 @@ assignees: ''
---
## Describe the bug
<!-- A clear and concise description of what the bug is. -->
## Steps To Reproduce
### Describe the bug
A clear and concise description of what the bug is.
### Steps To Reproduce
Steps to reproduce the behavior:
1. ...
2. ...
3. ...
## Expected behavior
### Expected behavior
A clear and concise description of what you expected to happen.
<!-- A clear and concise description of what you expected to happen. -->
### Screenshots
If applicable, add screenshots to help explain your problem.
## Screenshots
### Additional context
Add any other context about the problem here.
<!-- If applicable, add screenshots to help explain your problem: -->
## Additional context
<!-- Add any other context about the problem here. -->
## Metadata
<!-- Please insert the output of running `nix-shell -p nix-info --run "nix-info -m"` below this line -->
## Notify maintainers
### Notify maintainers
<!--
Please @ people who are in the `meta.maintainers` list of the offending package or module.
If in doubt, check `git blame` for whoever last touched something.
-->
---
### Metadata
Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.
Note for maintainers: Please tag this issue in your PR.
```console
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here
```
---

View File

@@ -7,43 +7,36 @@ assignees: ''
---
## Steps To Reproduce
### Steps To Reproduce
Steps to reproduce the behavior:
1. build *X*
## Build log
<!-- insert build log in code block in collapsable section -->
<details>
<summary>Build Log</summary>
### Build log
```
log here if short otherwise a link to a gist
```
</details>
### Additional context
## Additional context
Add any other context about the problem here.
<!-- Add any other context about the problem here. -->
## Metadata
<!-- Please insert the output of running `nix-shell -p nix-info --run "nix-info -m"` below this line -->
## Notify maintainers
### Notify maintainers
<!--
Please @ people who are in the `meta.maintainers` list of the offending package or module.
If in doubt, check `git blame` for whoever last touched something.
-->
---
### Metadata
Note for maintainers: Please tag this issue in your PR.
Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.
```console
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here
```
---

View File

@@ -23,9 +23,12 @@ assignees: ''
- [ ] checked [open documentation issues] for possible duplicates
- [ ] checked [open documentation pull requests] for possible solutions
---
Note for maintainers: Please tag this issue in your PR.
[latest Nixpkgs manual]: https://nixos.org/manual/nixpkgs/unstable/
[latest NixOS manual]: https://nixos.org/manual/nixos/unstable/
[nixpkgs-source]: https://github.com/NixOS/nixpkgs/tree/master/doc
[nixos-source]: https://github.com/NixOS/nixpkgs/tree/master/nixos/doc/manual
[open documentation issues]: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+label%3A%229.needs%3A+documentation%22
[open documentation pull requests]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+is%3Apr+label%3A%228.has%3A+documentation%22%2C%226.topic%3A+documentation%22
---
@@ -33,9 +36,3 @@ Add a :+1: [reaction] to [issues you find important].
[reaction]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
[issues you find important]: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc
[latest Nixpkgs manual]: https://nixos.org/manual/nixpkgs/unstable/
[latest NixOS manual]: https://nixos.org/manual/nixos/unstable/
[nixpkgs-source]: https://github.com/NixOS/nixpkgs/tree/master/doc
[nixos-source]: https://github.com/NixOS/nixpkgs/tree/master/nixos/doc/manual
[open documentation issues]: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+label%3A%229.needs%3A+documentation%22
[open documentation pull requests]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+is%3Apr+label%3A%228.has%3A+documentation%22%2C%226.topic%3A+documentation%22

View File

@@ -1,27 +0,0 @@
---
name: Module requests
about: For NixOS modules that you would like to see
title: 'Module request: MODULENAME'
labels: '9.needs: module (new)'
assignees: ''
---
## Description
<!-- Describe what the module should accomplish: -->
## Notify maintainers
<!-- If applicable, tag the maintainers of the package that corresponds to the module. If the search.nixos.org result shows no maintainers, tag the person that last updated the package. -->
-----
Note for maintainers: Please tag this issue in your PR.
---
Add a :+1: [reaction] to [issues you find important].
[reaction]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
[issues you find important]: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

View File

@@ -7,30 +7,23 @@ assignees: ''
---
## Package Information
<!-- Search for the package here: https://search.nixos.org/packages?channel=unstable -->
- Package name:
- Latest released version:
<!-- Search your package here: https://search.nixos.org/packages?channel=unstable -->
- Current version on the unstable channel:
- Current version on the stable/release channel:
## Checklist
<!--
Type the name of your package and try to find an open pull request for the package
If you find an open pull request, you can review it!
There's a high chance that you'll have the new version right away while helping the community!
-->
- [ ] Checked the [nixpkgs pull requests](https://github.com/NixOS/nixpkgs/pulls)
## Notify maintainers
**Notify maintainers**
<!-- If the search.nixos.org result shows no maintainers, tag the person that last updated the package. -->
---
-----
Note for maintainers: Please tag this issue in your PR.

View File

@@ -7,11 +7,11 @@ assignees: ''
---
## Project description
**Project description**
<!-- Describe the project a little: -->
## Metadata
**Metadata**
* homepage URL:
* source URL:
@@ -20,10 +20,6 @@ assignees: ''
---
Note for maintainers: Please tag this issue in your PR.
---
Add a :+1: [reaction] to [issues you find important].
[reaction]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/

View File

@@ -31,12 +31,12 @@ Fixing bit-by-bit reproducibility also has additional advantages, such as
avoiding hard-to-reproduce bugs, making content-addressed storage more effective
and reducing rebuilds in such systems.
## Steps To Reproduce
### Steps To Reproduce
In the following steps, replace `<package>` with the canonical name of the
package.
### 1. Build the package
#### 1. Build the package
This step will build the package. Specific arguments are passed to the command
to keep the build artifacts so we can compare them in case of differences.
@@ -53,7 +53,7 @@ Or using the new command line style:
nix build nixpkgs#<package> && nix build nixpkgs#<package> --rebuild --keep-failed
```
### 2. Compare the build artifacts
#### 2. Compare the build artifacts
If the previous command completes successfully, no differences were found and
there's nothing to do, builds are reproducible.
@@ -67,7 +67,7 @@ metadata (*e.g. timestamp*) differences.
nix run nixpkgs#diffoscopeMinimal -- --exclude-directory-metadata recursive <Y> <Z>
```
### 3. Examine the build log
#### 3. Examine the build log
To examine the build log, use:
@@ -81,20 +81,10 @@ Or with the new command line style:
nix log $(nix path-info --derivation nixpkgs#<package>)
```
## Additional context
### Additional context
(please share the relevant fragment of the diffoscope output here, and any additional analysis you may have done)
## Notify maintainers
<!--
Please @ people who are in the `meta.maintainers` list of the offending package or module.
If in doubt, check `git blame` for whoever last touched something.
-->
---
Note for maintainers: Please tag this issue in your PR.
(please share the relevant fragment of the diffoscope output here, and any
additional analysis you may have done)
---

View File

@@ -1,7 +1,6 @@
## Description of changes
<!--
^ Please summarise the changes you have done and explain why they are necessary here ^
For package updates please link to a changelog or describe changes, this helps your fellow maintainers discover breaking updates.
For new packages please briefly describe the package or provide a link to its homepage.
-->

146
.github/labeler.yml vendored
View File

@@ -1,4 +1,3 @@
# NOTE: bsd, darwin and cross-compilation labels are handled by ofborg
"6.topic: agda":
- any:
- changed-files:
@@ -22,47 +21,6 @@
- pkgs/by-name/ne/nemo/**/*
- pkgs/by-name/ne/nemo-*/**/*
"6.topic: continuous integration":
- any:
- changed-files:
- any-glob-to-any-file:
- .github/**/*
- ci/**/*
"6.topic: coq":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/applications/science/logic/coq/**/*
- pkgs/development/coq-modules/**/*
- pkgs/top-level/coq-packages.nix
"6.topic: crystal":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/development/compilers/crystal/**/*
"6.topic: cuda":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/development/cuda-modules/**/*
- pkgs/top-level/cuda-packages.nix
"6.topic: deepin":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/services/desktops/deepin/**/*
- pkgs/desktops/deepin/**/*
"6.topic: docker tools":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/applications/virtualization/docker/**/*
"6.topic: dotnet":
- any:
- changed-files:
@@ -128,12 +86,6 @@
- pkgs/build-support/flutter/*.nix
- pkgs/development/compilers/flutter/**/*.nix
"6.topic: games":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/games/**/*
"6.topic: GNOME":
- any:
- changed-files:
@@ -153,12 +105,6 @@
- pkgs/build-support/go/**/*
- pkgs/development/compilers/go/**/*
"6.topic: hardware":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/hardware/**/*
"6.topic: haskell":
- any:
- changed-files:
@@ -172,28 +118,6 @@
- pkgs/top-level/haskell-packages.nix
- pkgs/top-level/release-haskell.nix
"6.topic: java":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/programs/java.nix
- pkgs/development/compilers/graalvm/**/*
- pkgs/development/compilers/openjdk/**/*
- pkgs/development/compilers/temurin-bin/**/*
- pkgs/development/compilers/zulu/**/*
- pkgs/development/java-modules/**/*
- pkgs/top-level/java-packages.nix
"6.topic: jitsi":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/services/networking/jitsi-videobridge.nix
- nixos/modules/services/web-apps/jitsi-meet.nix
- pkgs/servers/web-apps/jitsi-meet/**/*
- pkgs/servers/jitsi-videobridge/**/*
- pkgs/applications/networking/instant-messengers/jitsi/**/*
"6.topic: julia":
- any:
- changed-files:
@@ -281,35 +205,21 @@
- lib/tests/modules.sh
- lib/tests/modules/**
"6.topic: musl":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/os-specific/linux/musl/**/*
"6.topic: nixos":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/**/*
- pkgs/by-name/sw/switch-to-configuration-ng/**/*
- pkgs/os-specific/linux/nixos-rebuild/**/*
"6.topic: nixos-container":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/virtualisation/nixos-containers.nix
- pkgs/tools/virtualization/nixos-container/**/*
"6.topic: nim":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/nim.section.md
- pkgs/build-support/build-nim-package.nix
- pkgs/by-name/ni/nim*
- pkgs/top-level/nim-overrides.nix
- pkgs/development/compilers/nim/*
- pkgs/development/nim-packages/**/*
- pkgs/top-level/nim-packages.nix
"6.topic: nodejs":
- any:
@@ -323,15 +233,6 @@
- pkgs/development/tools/pnpm/**/*
- pkgs/development/web/nodejs/*
"6.topic: nvidia":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/hardware/video/nvidia.nix
- nixos/modules/services/hardware/nvidia-container-toolkit/**/*
- nixos/modules/services/hardware/nvidia-optimus.nix
- pkgs/os-specific/linux/nvidia-x11/**/*
"6.topic: ocaml":
- any:
- changed-files:
@@ -358,9 +259,8 @@
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/php.section.md
- nixos/tests/php/**/*
- pkgs/build-support/php/**/*
- pkgs/development/interpreters/php/**/*
- pkgs/development/interpreters/php/*
- pkgs/development/php-packages/**/*
- pkgs/test/php/default.nix
- pkgs/top-level/php-packages.nix
@@ -405,19 +305,6 @@
- pkgs/development/libraries/kde-frameworks/**/*
- pkgs/development/libraries/qt-5/**/*
"6.topic: R":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/applications/science/math/R/**/*
- pkgs/development/r-modules/**/*
"6.topic: rocm":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/development/rocm-modules/**/*
"6.topic: ruby":
- any:
- changed-files:
@@ -453,15 +340,6 @@
- pkgs/os-specific/linux/systemd/**/*
- nixos/modules/system/boot/systemd*/**/*
"6.topic: tcl":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/tcl.section.md
- pkgs/development/interpreters/tcl/*
- pkgs/development/tcl-modules/**/*
- pkgs/top-level/tcl-packages.nix
"6.topic: TeX":
- any:
- changed-files:
@@ -486,12 +364,6 @@
- nixos/tests/make-test-python.nix # legacy
# lib/debug.nix has a test framework (runTests) but it's not the main focus
"6.topic: updaters":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/common-updater/**/*
"6.topic: vim":
- any:
- changed-files:
@@ -508,22 +380,14 @@
- any-glob-to-any-file:
- pkgs/applications/editors/vscode/**/*
"6.topic: windows":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/os-specific/windows/**/*
"6.topic: xen-project":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/virtualisation/xen*
- pkgs/by-name/xe/xen/*
- pkgs/by-name/qe/qemu_xen/*
- pkgs/applications/virtualization/xen/**
- pkgs/by-name/xe/xen-guest-agent/*
- pkgs/by-name/xt/xtf/*
- pkgs/build-support/xen/*
- pkgs/development/ocaml-modules/xen*/*
- pkgs/development/ocaml-modules/vchan/*

View File

@@ -20,7 +20,7 @@ jobs:
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
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
with:
ref: ${{ github.event.pull_request.head.sha }}
- name: Create backport PRs

View File

@@ -19,13 +19,12 @@ jobs:
runs-on: ubuntu-latest
# we don't limit this action to only NixOS repo since the checks are cheap and useful developer feedback
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
- uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
- uses: cachix/cachix-action@ad2ddac53f961de1989924296a1f236fcfbaa4fc # v15
with:
# This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
name: nixpkgs-ci
signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
- run: nix --experimental-features 'nix-command flakes' flake check --all-systems --no-build
# explicit list of supportedSystems is needed until aarch64-darwin becomes part of the trunk jobset
- run: nix-build pkgs/top-level/release.nix -A release-checks --arg supportedSystems '[ "aarch64-darwin" "aarch64-linux" "x86_64-linux" "x86_64-darwin" ]'

View File

@@ -14,7 +14,7 @@ jobs:
runs-on: ubuntu-latest
if: github.repository_owner == 'NixOS'
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
with:
fetch-depth: 0
filter: blob:none

View File

@@ -13,7 +13,7 @@ jobs:
runs-on: ubuntu-latest
if: github.repository_owner == 'NixOS'
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
@@ -21,7 +21,7 @@ jobs:
sparse-checkout: |
lib
maintainers
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
- uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true

View File

@@ -18,7 +18,7 @@ jobs:
runs-on: ubuntu-latest
if: "!contains(github.event.pull_request.title, '[skip treewide]')"
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
@@ -38,7 +38,7 @@ jobs:
# This should not be a URL, because it would allow PRs to run arbitrary code in CI!
rev=$(jq -r .rev ci/pinned-nixpkgs.json)
echo "url=https://github.com/NixOS/nixpkgs/archive/$rev.tar.gz" >> "$GITHUB_ENV"
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
- uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true

View File

@@ -12,7 +12,7 @@ jobs:
runs-on: ubuntu-latest
if: "!contains(github.event.pull_request.title, '[skip treewide]')"
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
@@ -32,7 +32,7 @@ jobs:
# This should not be a URL, because it would allow PRs to run arbitrary code in CI!
rev=$(jq -r .rev ci/pinned-nixpkgs.json)
echo "url=https://github.com/NixOS/nixpkgs/archive/$rev.tar.gz" >> "$GITHUB_ENV"
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
- uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true

View File

@@ -10,11 +10,11 @@ jobs:
name: shell-check-x86_64-linux
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
- uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
- name: Build shell
run: nix-build shell.nix
@@ -22,10 +22,10 @@ jobs:
name: shell-check-aarch64-darwin
runs-on: macos-latest
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
- uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
- name: Build shell
run: nix-build shell.nix

View File

@@ -1,104 +0,0 @@
name: Codeowners v2
# This workflow depends on two GitHub Apps with the following permissions:
# - For checking code owners:
# - Permissions:
# - Repository > Administration: read-only
# - Organization > Members: read-only
# - Install App on this repository, setting these variables:
# - OWNER_RO_APP_ID (variable)
# - OWNER_RO_APP_PRIVATE_KEY (secret)
# - For requesting code owners:
# - Permissions:
# - Repository > Administration: read-only
# - Organization > Members: read-only
# - Repository > Pull Requests: read-write
# - Install App on this repository, setting these variables:
# - OWNER_APP_ID (variable)
# - OWNER_APP_PRIVATE_KEY (secret)
#
# This split is done because checking code owners requires handling untrusted PR input,
# while requesting code owners requires PR write access, and those shouldn't be mixed.
on:
pull_request_target:
types: [opened, ready_for_review, synchronize, reopened, edited]
# We don't need any default GitHub token
permissions: {}
env:
OWNERS_FILE: ci/OWNERS
# Don't do anything on draft PRs
DRY_MODE: ${{ github.event.pull_request.draft && '1' || '' }}
jobs:
# Check that code owners is valid
check:
name: Check
runs-on: ubuntu-latest
steps:
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
- uses: cachix/cachix-action@ad2ddac53f961de1989924296a1f236fcfbaa4fc # v15
if: github.repository_owner == 'NixOS'
with:
# This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
name: nixpkgs-ci
authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
# Important: Because we use pull_request_target, this checks out the base branch of the PR, not the PR itself.
# We later build and run code from the base branch with access to secrets,
# so it's important this is not the PRs code.
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
path: base
- name: Build codeowners validator
run: nix-build base/ci -A codeownersValidator
- uses: actions/create-github-app-token@5d869da34e18e7287c1daad50e0b8ea0f506ce69 # v1.11.0
id: app-token
with:
app-id: ${{ vars.OWNER_RO_APP_ID }}
private-key: ${{ secrets.OWNER_RO_APP_PRIVATE_KEY }}
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: refs/pull/${{ github.event.number }}/merge
path: pr
- name: Validate codeowners
run: result/bin/codeowners-validator
env:
OWNERS_FILE: pr/${{ env.OWNERS_FILE }}
GITHUB_ACCESS_TOKEN: ${{ steps.app-token.outputs.token }}
REPOSITORY_PATH: pr
OWNER_CHECKER_REPOSITORY: ${{ github.repository }}
# Set this to "notowned,avoid-shadowing" to check that all files are owned by somebody
EXPERIMENTAL_CHECKS: "avoid-shadowing"
# Request reviews from code owners
request:
name: Request
runs-on: ubuntu-latest
steps:
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
# Important: Because we use pull_request_target, this checks out the base branch of the PR, not the PR head.
# This is intentional, because we need to request the review of owners as declared in the base branch.
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/create-github-app-token@5d869da34e18e7287c1daad50e0b8ea0f506ce69 # v1.11.0
id: app-token
with:
app-id: ${{ vars.OWNER_APP_ID }}
private-key: ${{ secrets.OWNER_APP_PRIVATE_KEY }}
- name: Build review request package
run: nix-build ci -A requestReviews
- name: Request reviews
run: result/bin/request-reviews.sh ${{ github.repository }} ${{ github.event.number }} "$OWNERS_FILE"
env:
GH_TOKEN: ${{ steps.app-token.outputs.token }}

View File

@@ -1,44 +0,0 @@
name: "Checking EditorConfig v2"
permissions:
pull-requests: read
contents: read
on:
# avoids approving first time contributors
pull_request_target:
branches-ignore:
- 'release-**'
jobs:
tests:
name: editorconfig-check
runs-on: ubuntu-latest
if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
steps:
- name: Get list of changed files from PR
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh api \
repos/NixOS/nixpkgs/pulls/${{github.event.number}}/files --paginate \
| jq '.[] | select(.status != "removed") | .filename' \
> "$HOME/changed_files"
- name: print list of changed files
run: |
cat "$HOME/changed_files"
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
with:
# nixpkgs commit is pinned so that it doesn't break
# editorconfig-checker 2.4.0
nix_path: nixpkgs=https://github.com/NixOS/nixpkgs/archive/c473cc8714710179df205b153f4e9fa007107ff9.tar.gz
- name: Checking EditorConfig
run: |
cat "$HOME/changed_files" | nix-shell -p editorconfig-checker --run 'xargs -r editorconfig-checker -disable-indent-size'
- if: ${{ failure() }}
run: |
echo "::error :: Hey! It looks like your changes don't follow our editorconfig settings. Read https://editorconfig.org/#download to configure your editor so you never see this error again."

42
.github/workflows/editorconfig.yml vendored Normal file
View File

@@ -0,0 +1,42 @@
name: "Checking EditorConfig"
permissions: read-all
on:
# avoids approving first time contributors
pull_request_target:
branches-ignore:
- 'release-**'
jobs:
tests:
name: editorconfig-check
runs-on: ubuntu-latest
if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
steps:
- name: Get list of changed files from PR
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh api \
repos/NixOS/nixpkgs/pulls/${{github.event.number}}/files --paginate \
| jq '.[] | select(.status != "removed") | .filename' \
> "$HOME/changed_files"
- name: print list of changed files
run: |
cat "$HOME/changed_files"
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
with:
# nixpkgs commit is pinned so that it doesn't break
# editorconfig-checker 2.4.0
nix_path: nixpkgs=https://github.com/NixOS/nixpkgs/archive/c473cc8714710179df205b153f4e9fa007107ff9.tar.gz
- name: Checking EditorConfig
run: |
cat "$HOME/changed_files" | nix-shell -p editorconfig-checker --run 'xargs -r editorconfig-checker -disable-indent-size'
- if: ${{ failure() }}
run: |
echo "::error :: Hey! It looks like your changes don't follow our editorconfig settings. Read https://editorconfig.org/#download to configure your editor so you never see this error again."

View File

@@ -1,33 +0,0 @@
name: "Build NixOS manual v2"
permissions:
contents: read
on:
pull_request_target:
branches:
- master
paths:
- 'nixos/**'
jobs:
nixos:
name: nixos-manual-build
runs-on: ubuntu-latest
if: github.repository_owner == 'NixOS'
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true
- uses: cachix/cachix-action@ad2ddac53f961de1989924296a1f236fcfbaa4fc # v15
with:
# This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
name: nixpkgs-ci
authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
- name: Building NixOS manual
run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true nixos/release.nix -A manual.x86_64-linux

32
.github/workflows/manual-nixos.yml vendored Normal file
View File

@@ -0,0 +1,32 @@
name: "Build NixOS manual"
permissions: read-all
on:
pull_request_target:
branches:
- master
paths:
- 'nixos/**'
jobs:
nixos:
name: nixos-manual-build
runs-on: ubuntu-latest
if: github.repository_owner == 'NixOS'
steps:
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true
- uses: cachix/cachix-action@ad2ddac53f961de1989924296a1f236fcfbaa4fc # v15
with:
# This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
name: nixpkgs-ci
authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
- name: Building NixOS manual
run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true nixos/release.nix -A manual.x86_64-linux

View File

@@ -1,35 +0,0 @@
name: "Build Nixpkgs manual v2"
permissions:
contents: read
on:
pull_request_target:
branches:
- master
paths:
- 'doc/**'
- 'lib/**'
- 'pkgs/tools/nix/nixdoc/**'
jobs:
nixpkgs:
name: nixpkgs-manual-build
runs-on: ubuntu-latest
if: github.repository_owner == 'NixOS'
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true
- uses: cachix/cachix-action@ad2ddac53f961de1989924296a1f236fcfbaa4fc # v15
with:
# This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
name: nixpkgs-ci
authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
- name: Building Nixpkgs manual
run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true pkgs/top-level/release.nix -A manual -A manual.tests

34
.github/workflows/manual-nixpkgs.yml vendored Normal file
View File

@@ -0,0 +1,34 @@
name: "Build Nixpkgs manual"
permissions: read-all
on:
pull_request_target:
branches:
- master
paths:
- 'doc/**'
- 'lib/**'
- 'pkgs/tools/nix/nixdoc/**'
jobs:
nixpkgs:
name: nixpkgs-manual-build
runs-on: ubuntu-latest
if: github.repository_owner == 'NixOS'
steps:
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true
- uses: cachix/cachix-action@ad2ddac53f961de1989924296a1f236fcfbaa4fc # v15
with:
# This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
name: nixpkgs-ci
authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
- name: Building Nixpkgs manual
run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true pkgs/top-level/release.nix -A manual -A manual.tests

View File

@@ -1,45 +0,0 @@
name: "Check whether nix files are parseable v2"
permissions:
pull-requests: read
contents: read
on:
# avoids approving first time contributors
pull_request_target:
branches-ignore:
- 'release-**'
jobs:
tests:
name: nix-files-parseable-check
runs-on: ubuntu-latest
if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
steps:
- name: Get list of changed files from PR
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh api \
repos/NixOS/nixpkgs/pulls/${{github.event.number}}/files --paginate \
| jq --raw-output '.[] | select(.status != "removed" and (.filename | endswith(".nix"))) | .filename' \
> "$HOME/changed_files"
if [[ -s "$HOME/changed_files" ]]; then
echo "CHANGED_FILES=$HOME/changed_files" > "$GITHUB_ENV"
fi
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
if: ${{ env.CHANGED_FILES && env.CHANGED_FILES != '' }}
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
with:
nix_path: nixpkgs=channel:nixpkgs-unstable
- name: Parse all changed or added nix files
run: |
ret=0
while IFS= read -r file; do
out="$(nix-instantiate --parse "$file")" || { echo "$out" && ret=1; }
done < "$HOME/changed_files"
exit "$ret"
if: ${{ env.CHANGED_FILES && env.CHANGED_FILES != '' }}

43
.github/workflows/nix-parse.yml vendored Normal file
View File

@@ -0,0 +1,43 @@
name: "Check whether nix files are parseable"
permissions: read-all
on:
# avoids approving first time contributors
pull_request_target:
branches-ignore:
- 'release-**'
jobs:
tests:
name: nix-files-parseable-check
runs-on: ubuntu-latest
if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
steps:
- name: Get list of changed files from PR
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh api \
repos/NixOS/nixpkgs/pulls/${{github.event.number}}/files --paginate \
| jq --raw-output '.[] | select(.status != "removed" and (.filename | endswith(".nix"))) | .filename' \
> "$HOME/changed_files"
if [[ -s "$HOME/changed_files" ]]; then
echo "CHANGED_FILES=$HOME/changed_files" > "$GITHUB_ENV"
fi
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
if: ${{ env.CHANGED_FILES && env.CHANGED_FILES != '' }}
- uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
with:
nix_path: nixpkgs=channel:nixpkgs-unstable
- name: Parse all changed or added nix files
run: |
ret=0
while IFS= read -r file; do
out="$(nix-instantiate --parse "$file")" || { echo "$out" && ret=1; }
done < "$HOME/changed_files"
exit "$ret"
if: ${{ env.CHANGED_FILES && env.CHANGED_FILES != '' }}

View File

@@ -26,23 +26,53 @@ jobs:
# This should take 1 minute at most, but let's be generous. The default of 6 hours is definitely too long.
timeout-minutes: 10
steps:
# This checks out the base branch because of pull_request_target
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
path: base
sparse-checkout: ci
# This step has to be in this file, because it's needed to determine which revision of the repository to fetch, and we can only use other files from the repository once it's fetched.
- name: Resolving the merge commit
env:
GH_TOKEN: ${{ github.token }}
run: |
if mergedSha=$(base/ci/get-merge-commit.sh ${{ github.repository }} ${{ github.event.number }}); then
echo "Checking the merge commit $mergedSha"
# This checks for mergeability of a pull request as recommended in
# https://docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-your-git-database?apiVersion=2022-11-28#checking-mergeability-of-pull-requests
# Retry the API query this many times
retryCount=5
# Start with 5 seconds, but double every retry
retryInterval=5
while true; do
echo "Checking whether the pull request can be merged"
prInfo=$(gh api \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
/repos/"$GITHUB_REPOSITORY"/pulls/${{ github.event.pull_request.number }})
mergeable=$(jq -r .mergeable <<< "$prInfo")
mergedSha=$(jq -r .merge_commit_sha <<< "$prInfo")
if [[ "$mergeable" == "null" ]]; then
if (( retryCount == 0 )); then
echo "Not retrying anymore. It's likely that GitHub is having internal issues: check https://www.githubstatus.com/"
exit 1
else
(( retryCount -= 1 )) || true
# null indicates that GitHub is still computing whether it's mergeable
# Wait a couple seconds before trying again
echo "GitHub is still computing whether this PR can be merged, waiting $retryInterval seconds before trying again ($retryCount retries left)"
sleep "$retryInterval"
(( retryInterval *= 2 )) || true
fi
else
break
fi
done
if [[ "$mergeable" == "true" ]]; then
echo "The PR can be merged, checking the merge commit $mergedSha"
echo "mergedSha=$mergedSha" >> "$GITHUB_ENV"
else
echo "Skipping the rest..."
echo "The PR cannot be merged, it has a merge conflict, skipping the rest.."
fi
rm -rf base
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
if: env.mergedSha
with:
# pull_request_target checks out the base branch by default
@@ -55,7 +85,7 @@ jobs:
base=$(mktemp -d)
git worktree add "$base" "$(git rev-parse HEAD^1)"
echo "base=$base" >> "$GITHUB_ENV"
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
- uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
if: env.mergedSha
- name: Fetching the pinned tool
if: env.mergedSha

View File

@@ -41,7 +41,7 @@ jobs:
into: staging-24.05
name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
- name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
uses: devmasx/merge-branch@854d3ac71ed1e9deb668e0074781b81fdd6e771f # 1.4.0

View File

@@ -39,7 +39,7 @@ jobs:
into: staging
name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
- name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
uses: devmasx/merge-branch@854d3ac71ed1e9deb668e0074781b81fdd6e771f # 1.4.0

View File

@@ -0,0 +1,69 @@
name: "Update terraform-providers"
on:
#schedule:
# - cron: "0 3 * * *"
workflow_dispatch:
permissions:
contents: read
jobs:
tf-providers:
permissions:
contents: write # for peter-evans/create-pull-request to create branch
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:
- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
- uses: cachix/install-nix-action@ba0dd844c9180cbf77aa72a116d6fbc515d0e87b # v27
with:
nix_path: nixpkgs=channel:nixpkgs-unstable
- name: setup
id: setup
run: |
echo "title=terraform-providers: update $(date -u +"%Y-%m-%d")" >> $GITHUB_OUTPUT
- name: update terraform-providers
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
git config user.name "github-actions[bot]"
echo | nix-shell \
maintainers/scripts/update.nix \
--argstr commit true \
--argstr keep-going true \
--argstr max-workers 2 \
--argstr path terraform-providers
- name: get failed updates
run: |
echo 'FAILED<<EOF' >> $GITHUB_ENV
git ls-files --others >> $GITHUB_ENV
echo 'EOF' >> $GITHUB_ENV
# cleanup logs of failed updates so they aren't included in the PR
- name: clean repo
run: |
git clean -f
- name: create PR
uses: peter-evans/create-pull-request@6cd32fd93684475c31847837f87bb135d40a2b79 # v7.0.3
with:
body: |
Automatic update by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action.
https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}
These providers failed to update:
```
${{ env.FAILED }}
```
Check that all providers build with:
```
@ofborg build opentofu.full
```
If there is more than ten commits in the PR `ofborg` won't build it automatically and you will need to use the above command.
branch: terraform-providers-update
delete-branch: false
title: ${{ steps.setup.outputs.title }}
token: ${{ secrets.GITHUB_TOKEN }}

View File

@@ -6,8 +6,6 @@ Christina Sørensen <christina@cafkafk.com> <christinaafk@gmail.com>
Christina Sørensen <christina@cafkafk.com> <89321978+cafkafk@users.noreply.github.com>
Daniel Løvbrøtte Olsen <me@dandellion.xyz> <daniel.olsen99@gmail.com>
Fabian Affolter <mail@fabian-affolter.ch> <fabian@affolter-engineering.ch>
Fiona Behrens <me@kloenk.dev>
Fiona Behrens <me@kloenk.dev> <me@kloenk.de>
goatastronaut0212 <goatastronaut0212@outlook.com> <goatastronaut0212@proton.me>
Janne Heß <janne@hess.ooo> <dasJ@users.noreply.github.com>
Jörg Thalheim <joerg@thalheim.io> <Mic92@users.noreply.github.com>

View File

@@ -93,8 +93,6 @@ This section describes in some detail how changes can be made and proposed with
7. Respond to review comments, potential CI failures and potential merge conflicts by updating the pull request.
Always keep the pull request in a mergeable state.
This process is covered in more detail from the non-technical side in [I opened a PR, how do I get it merged?](#i-opened-a-pr-how-do-i-get-it-merged).
The custom [OfBorg](https://github.com/NixOS/ofborg) CI system will perform various checks to help ensure code quality, whose results you can see at the bottom of the pull request.
See [the OfBorg Readme](https://github.com/NixOS/ofborg#readme) for more details.
@@ -195,12 +193,19 @@ The last checkbox is about whether it fits the guidelines in this `CONTRIBUTING.
[rebase]: #rebasing-between-branches-ie-from-master-to-staging
From time to time, changes between branches must be rebased, for example, if the
number of new rebuilds they would cause is too large for the target branch.
number of new rebuilds they would cause is too large for the target branch. When
rebasing, care must be taken to include only the intended changes, otherwise
many CODEOWNERS will be inadvertently requested for review. To achieve this,
rebasing should not be performed directly on the target branch, but on the merge
base between the current and target branch. As an additional precautionary measure,
you should temporarily mark the PR as draft for the duration of the operation.
This reduces the probability of mass-pinging people. (OfBorg might still
request a couple of persons for reviews though.)
In the following example, we assume that the current branch, called `feature`,
is based on `master`, and we rebase it onto the merge base between
`master` and `staging` so that the PR can be retargeted to
`staging`. The example uses `upstream` as the remote for `NixOS/nixpkgs.git`
`master` and `staging` so that the PR can eventually be retargeted to
`staging` without causing a mess. The example uses `upstream` as the remote for `NixOS/nixpkgs.git`
while `origin` is the remote you are pushing to.
@@ -229,6 +234,36 @@ git status
git push origin feature --force-with-lease
```
#### Something went wrong and a lot of people were pinged
It happens. Remember to be kind, especially to new contributors.
There is no way back, so the pull request should be closed and locked
(if possible). The changes should be re-submitted in a new PR, in which the people
originally involved in the conversation need to manually be pinged again.
No further discussion should happen on the original PR, as a lot of people
are now subscribed to it.
The following message (or a version thereof) might be left when closing to
describe the situation, since closing and locking without any explanation
is kind of rude:
```markdown
It looks like you accidentally mass-pinged a bunch of people, which are now subscribed
and getting notifications for everything in this pull request. Unfortunately, they
cannot be automatically unsubscribed from the issue (removing review request does not
unsubscribe), therefore development cannot continue in this pull request anymore.
Please open a new pull request with your changes, link back to this one and ping the
people actually involved in here over there.
In order to avoid this in the future, there are instructions for how to properly
rebase between branches in our [contribution guidelines](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#rebasing-between-branches-ie-from-master-to-staging).
Setting your pull request to draft prior to rebasing is strongly recommended.
In draft status, you can preview the list of people that are about to be requested
for review, which allows you to sidestep this issue.
This is not a bulletproof method though, as OfBorg still does review requests even on draft PRs.
```
## How to backport pull requests
[pr-backport]: #how-to-backport-pull-requests
@@ -308,18 +343,20 @@ If you consider having enough knowledge and experience in a topic and would like
Container system, boot system and library changes are some examples of the pull requests fitting this category.
## How to merge pull requests yourself
## How to merge pull requests
[pr-merge]: #how-to-merge-pull-requests
To streamline automated updates, leverage the nixpkgs-merge-bot by simply commenting `@NixOS/nixpkgs-merge-bot merge`. The bot will verify if the following conditions are met, refusing to merge otherwise:
- the PR author should be @r-ryantm;
- the commenter that issued the command should be among the package maintainers;
- the package should reside in `pkgs/by-name`.
Further, nixpkgs-merge-bot will ensure all ofBorg checks (except the Darwin-related ones) are successfully completed before merging the pull request. Should the checks still be underway, the bot patiently waits for ofBorg to finish before attempting the merge again.
For other pull requests, please see [I opened a PR, how do I get it merged?](#i-opened-a-pr-how-do-i-get-it-merged).
For other pull requests, the *Nixpkgs committers* are people who have been given
permission to merge.
It is possible for community members that have enough knowledge and experience on a special topic to contribute by merging pull requests.
In case the PR is stuck waiting for the original author to apply a trivial
change (a typo, capitalisation change, etc.) and the author allowed the members
@@ -393,10 +430,14 @@ Here is a Git history diagram showing the flow of commits between the three bran
} }%%
gitGraph
commit id:" "
branch staging
commit id:" "
branch staging-next
branch staging
checkout master
checkout staging
checkout master
commit id:" "
checkout staging-next
merge master id:"automatic"
checkout staging
merge staging-next id:"automatic "
@@ -512,7 +553,6 @@ To get a sense for what changes are considered mass rebuilds, see [previously me
- [Commit conventions](./doc/README.md#commit-conventions) for changes to `doc`, the Nixpkgs manual.
### Writing good commit messages
[writing-good-commit-messages]: #writing-good-commit-messages
In addition to writing properly formatted commit messages, it's important to include relevant information so other developers can later understand *why* a change was made. While this information usually can be found by digging code, mailing list/Discourse archives, pull request discussions or upstream changes, it may require a lot of work.
@@ -597,7 +637,7 @@ Names of files and directories should be in lowercase, with dashes between words
```nix
{
buildInputs = lib.optional stdenv.hostPlatform.isDarwin iconv;
buildInputs = lib.optional stdenv.isDarwin iconv;
}
```
@@ -605,198 +645,9 @@ Names of files and directories should be in lowercase, with dashes between words
```nix
{
buildInputs = if stdenv.hostPlatform.isDarwin then [ iconv ] else null;
buildInputs = if stdenv.isDarwin then [ iconv ] else null;
}
```
As an exception, an explicit conditional expression with null can be used when fixing a important bug without triggering a mass rebuild.
If this is done a follow up pull request _should_ be created to change the code to `lib.optional(s)`.
# Practical contributing advice
To contribute effectively and efficiently, you need to be aware of how the contributing process generally works.
This section aims to document the process as we live it in Nixpkgs to set expectations right and give practical tips on how to work with it.
## I opened a PR, how do I get it merged?
[i-opened-a-pr-how-do-i-get-it-merged]:#i-opened-a-pr-how-do-i-get-it-merged
In order for your PR to be merged, someone with merge permissions on the repository ("committer") needs to review and merge it.
Because the group of people with merge permissions is mostly a collection of independent unpaid volunteers who do this in their own free time, this can take some time to happen.
It is entirely normal for your PR to sit around without any feedback for days, weeks or sometimes even months.
We strive to avoid the latter cases of course but the reality of it is that this does happen quite frequently.
Even when you get feedback, follow-up feedback may take similarly long.
Don't be intimidated by this and kindly ask for feedback again every so often.
If your change is good it will eventually be merged at some point.
There are some things you can do to help speed up the process of your PR being merged though.
In order to speed the process up, you need to know what needs to happen before a committer will actually hit the merge button.
This section intends to give a little overview and insight of what happens after you create your PR.
### The committer's perspective
PRs have varying quality and even the best people make mistakes.
It is the role of the committer team to assess whether any PR's changes are good changes or not.
In order for any PR to be merged, at least one committer needs to be convinced of its quality enough to merge it.
Committers typically assess three aspects of your PR:
1. Whether the change's intention is necessary and desirable
2. Whether the code quality of your changes is good
3. Whether the artefacts produced by the code are good
If you want your PR to get merged quickly and smoothly, it is in your best interest to help convince committers in these three aspects.
### How to help committers assess your PR
For the committer to judge your intention, it's best to explain why you've made your change.
This does not apply to trivial changes like version updates because the intention is obvious (though linking the changelog is appreciated).
For any more nuanced changed or even major version upgrades, it helps if you explain the background behind your change a bit.
E.g. if you're adding a package, explain what it is and why it should be in Nixpkgs.
This goes hand in hand with [Writing good commit messages](#writing-good-commit-messages).
For the code quality assessment, you cannot do anything yourself as only the committer can do this and they already have your code to look at.
In order to minimise the need for back and forth though, do take a look over your code changes yourself and try to put yourself into the shoes of someone who didn't just write that code.
Would you immediately know what the code does or why it is needed by glancing at it?
If not, reviewers will notice this and will ask you to clarify the code by refactoring it and/or adding a few explanations in code comments.
Doing this preemptively can save you and the committer a lot of time.
To better convey the "story" of your change, consider dividing your change into multiple atomic commits.
There is a balance to strike however: over-fragmentation causes friction.
The code artefacts are the hardest for committers to assess because PRs touch all sorts of components: applications, libraries, NixOS modules, editor plugins and many many other things.
Any individual committer can only really assess components that they themselves know how to use however and yet they must still be convinced somehow.
There isn't a good generic solution to this but there are some ways easing the committer's job here:
- Provide smoke tests that the committer can run without much research or setup.
Committers usually don't have the time or interest to learn how your component works and how they could test its functionality.
If you can provide a quick guide on how to use the component in a meaningful way or a ready-made command that demonstrates that the component works as expected, the committer can easily convince themselves that your change is good.
If it can be automated, you could even turn this smoke test into an automated NixOS test which reviewers could simply run via Nix.
- Invite other users of the component to try it out and report their findings.
If a committer sees the testimonials of other users trying your change and it works as expected for them, that too can convince the committer of your PR's quality.
- Describe what you have done to test your PR.
If you can convince the committer that you have done sufficient quality assurance on your changes and they trust your report, this too can convince them of your PR's quality, albeit not as strongly as the methods above.
- Become a maintainer of the component.
This isn't something you can do on your first few PRs touching a component but listed maintainers generally receive more trust when it comes to changes to their maintained components and committers may opt to merge changes without deeper review when they see they're done by their respective maintainer.
Even if you adhere to all of these recommendations, it is still quite possible for your PR to be forgotten or abandoned by any given committer.
Please remain mindful of the fact that they are doing this on their own volition and unpaid in their free time and therefore [owe you nothing](https://mikemcquaid.com/open-source-maintainers-owe-you-nothing/).
Causing a stink in such a situation is a surefire way to get any other potential committer to not want to look at your PR either.
Ask them nicely whether they still intend to review your PR and find yourself another committer to look at your PR if not.
### How can I get a committer to look at my PR?
- Improve skimmability: use a simple descriptive PR title (details go in commit titles) outlining _what_ is done and _why_.
- Improve discoverability: apply all relevant labels, tick all relevant PR body checkboxes.
- Wait. Reviewers frequently browse open PRs and may happen to run across yours and take a look.
- Get non-committers to review/approve. Many committers filter open PRs for low-hanging fruit that are already been reviewed.
- [@-mention](https://github.blog/news-insights/mention-somebody-they-re-notified/) someone and ask them nicely
- Post in one of the channels made for this purpose if there has been no activity for at least one week
- The current "PRs ready for review" or "PRs already reviewed" threads in the [NixOS Discourse](https://discourse.nixos.org/c/dev/14) (of course choose the one that applies to your situation)
- The [Nixpkgs Review Requests Matrix room](https://matrix.to/#/#review-requests:nixos.org).
### CI failed or got stuck on my PR, what do I do?
First ensure that the failure is actually related to your change.
Sometimes, the CI system simply has a hiccup or the check was broken by someone else before you made your changes.
Read through the error message; it's usually quite easy to tell whether it is caused by anything you did by checking whether it mentions the component you touched anywhere.
If it is indeed caused by your change, obviously try to fix it.
Don't be afraid of asking for advice if you're uncertain how to do that, others have likely fixed such issues dozens of times and can help you out.
Your PR is unlikely to be merged if it has a known issue and it is the purpose of CI to alert you aswell as reviewers to these issues.
ofBorg builds can often get stuck, particularly in PRs targeting `staging` and in builders for the Darwin platform. Reviewers will know how to handle them or when to ignore them.
Don't worry about it.
If there is a build failure however and it happened due to a package related to your change, you need to investigate it of course.
If ofBorg reveals the build to be broken on some platform and you don't have access to that platform, you should set your package's `meta.broken` accordingly.
When in any doubt, please ask via a comment in your PR or through one of the help channels.
## I received a review on my PR, how do I get it over the finish line?
In the review process, the committer will have left some sort of feedback on your PR.
They may have immediately approved of your PR or even merged it but the more likely case is that they want you to change a few things or that they require further input.
A reviewer may have taken a look at the code and it looked good to them ("Diff LGTM") but they still need to be convinced of the artefact's quality.
They might also be waiting on input from other users of the component or its listed maintainer on whether the intention of your PR makes sense for the component.
If you know of people who could help clarify any of this, please bring the PR to their attention.
The current state of the PR is frequently not clearly communicated, so please don't hesitate to ask about it if it's unclear to you.
It's also possible for the reviewer to not be convinced that your PR is necessary or that the method you've chose to achieve your intention is the right one.
Please explain your intentions and reasoning to the committer in such a case.
There may be constraints you had to work with which they're not aware of or qualities of your approach that they didn't immediately notice.
(If these weren't clear to the reviewer, that's a good sign you should explain them in your commit message or code comments!)
There are some further pitfalls and realities which this section intends to make you aware of.
### Aim to reduce cycles
Please be prepared for it to take a while before the reviewer gets back to you after you respond.
This is simply the reality of community projects at the scale of Nixpkgs.
As such, make sure to respond to _all_ feedback, either by applying suggested changes or argue in favor of something else or no change.
It wastes everyone time waiting for a couple of days just for the reviewer to remind you to address something they asked for.
### A reviewer requested a bunch of insubstantial changes on my PR
The people involved in Nixpkgs care about code quality because, once in Nixpkgs, it needs to be maintained for many years to come.
It is therefore likely that other people will ask you to do some things in another way or adhere to some standard.
Sometimes however, they also care a bit too much and may ask you to adhere to a personal preference of theirs.
It's not always easy to tell which is which and whether the requests are critically important to merging the PR.
Sometimes another reviewer may also come along with totally different opinions on some points too.
It is convention to mark review comments that are not critical to the PR as nitpicks but this is not always followed.
As the PR author, you should still take a look at these as they will often reveal best practices and unwritten rules that usually have good reasons behind them and you may want to incorporate them into your modus operandi.
Please keep in mind that reviewers almost always mean well here.
Their intent is not to denounce your code, they want your code to be as good as it can be.
Through their experience, they may also take notice of a seemingly insignificant issues that have caused significant burden before.
Sometimes however, they can also get a bit carried away and become too perfectionistic.
If you feel some of the requests are unreasonable, out of scope, or merely a matter of personal preference, try to nicely remind the reviewers that you may not intend this code to be 100% perfect or that you have different taste in some regards and press them on whether they think that these requests are *critical* to the PR's success.
While we do have a set of [official standards for the Nix community](https://github.com/NixOS/rfcs/), we don't have standards for everything and there are often multiple valid ways to achieve the same goal.
Unless there are standards forbidding the patterns used in your code or there are serious technical, maintainability or readability issues with your code, you can insist to keep the code the way you made it and disregard the requests.
Please communicate this clearly though; a simple "I prefer it this way and see no major issue with it" can save you a lot of arguing.
If you are unsure about some change requests, please ask reviewers *why* they requested them.
This will usually reveal how important they deem it to be and will help educate you about standards, best practices, unwritten rules aswell as preferences people have and why.
Some committers may have stronger opinions on some things and therefore (understandably) may not want to merge your PR if you don't follow their requests.
It is totally fine to get yourself a second or third opinion in such a case.
### Committers work on a push-basis
It's possible for you to get a review but nothing happens afterwards, even if you reply to review comments.
A committer not following up on your PR does not necessarily mean they're disinterested or unresponsive, they may have simply forgotten to follow up on it or had some other circumstances preventing them from doing so.
Committers typically handle many other PRs besides yours and it is not realistic for them to keep up with all of them to a degree where they could reasonably remember to follow up on all PRs that they had intended following up upon.
If someone left an approving review on your PR and didn't merge a few days later, the most likely case is that they simply forgot.
Please see it as your responsibility to actively remind reviewers of your open PRs.
The easiest way to do so is to cause them a Github notification.
Github notifies people involved in the PR whenever you add a comment to your PR, push your PR or re-request their review.
Doing any of that will get you people's attention again.
Everyone deserves proper attention, and yes that includes you!
However please be mindful that committers can sadly not always give everyone the attention they deserve.
It may very well be the case that you have to do this every time you need the committer to follow up upon your PR.
Again, this is a community project so please be mindful of people's circumstances here; be nice when requesting reviews again.
It may also be the case that the committer has lost interest or isn't familiar enough with the component you're touching to be comfortable merging your PR.
They will likely not immediately state that fact however, so please ask for clarification and don't hesitate to find yourself another committer to take a look at your PR.
### Nothing helped
If you followed these guidelines but still got no results or if you feel that you have been wronged in some way, please explicitly reach out to the greater community via its communication channels.
The [NixOS Discourse](https://discourse.nixos.org/) is a great place to do this as it has historically been the asynchronous medium with the greatest concentration of committers and other people who are significantly involved in Nixpkgs.
There is a dedicated discourse thread [PRs in distress](https://discourse.nixos.org/t/prs-in-distress/3604) where you can link your PR if everything else fails.
The [Nixpkgs / NixOS contributions Matrix channel](https://matrix.to/#/#dev:nixos.org) is the best synchronous channel with the same qualities.
Please reserve these for cases where you've made a serious effort in trying to get the attention of multiple active committers and provided realistic means for them to assess your PR's quality though.
As mentioned previously, it is unfortunately perfectly normal for a PR to sit around for weeks on end due to the realities of this being a community project.
Please don't blow up situations where progress is happening but is merely not going fast enough for your tastes.
Honking in a traffic jam will not make you go any faster.

View File

@@ -9,7 +9,7 @@
</p>
<p align="center">
<a href="CONTRIBUTING.md"><img src="https://img.shields.io/github/contributors-anon/NixOS/nixpkgs" alt="Contributors badge" /></a>
<a href="https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md"><img src="https://img.shields.io/github/contributors-anon/NixOS/nixpkgs" alt="Contributors badge" /></a>
<a href="https://opencollective.com/nixos"><img src="https://opencollective.com/nixos/tiers/supporter/badge.svg?label=supporters&color=brightgreen" alt="Open Collective supporters" /></a>
</p>
@@ -74,7 +74,7 @@ Community contributions are always welcome through GitHub Issues and
Pull Requests.
For more information about contributing to the project, please visit
the [contributing page](CONTRIBUTING.md).
the [contributing page](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
# Donations

431
ci/OWNERS
View File

@@ -1,431 +0,0 @@
# This file is used to describe who owns what in this repository.
# Users/teams will get review requests for PRs that change their files.
#
# This file does not replace `meta.maintainers`
# but is instead used for other things than derivations and modules,
# like documentation, package sets, and other assets.
#
# This file uses the same syntax as the natively supported CODEOWNERS file,
# see https://help.github.com/articles/about-codeowners/ for documentation.
# However it comes with some notable differences:
# - There is no need for user/team listed here to have write access.
# - No reviews will be requested for PRs that target the wrong base branch.
#
# Processing of this file is implemented in workflows/codeowners-v2.yml
# CI
/.github/workflows @NixOS/Security @Mic92 @zowoq
/.github/workflows/check-nix-format.yml @infinisil
/.github/workflows/nixpkgs-vet.yml @infinisil @philiptaron
/.github/workflows/codeowners-v2.yml @infinisil
/ci @infinisil @philiptaron @NixOS/Security
/ci/OWNERS @infinisil @philiptaron
# Development support
/.editorconfig @Mic92 @zowoq
/shell.nix @infinisil @NixOS/Security
# Libraries
/lib @infinisil
/lib/systems @alyssais @ericson2314 @NixOS/stdenv
/lib/generators.nix @infinisil @Profpatsch
/lib/cli.nix @infinisil @Profpatsch
/lib/debug.nix @infinisil @Profpatsch
/lib/asserts.nix @infinisil @Profpatsch
/lib/path/* @infinisil
/lib/fileset @infinisil
## Libraries / Module system
/lib/modules.nix @infinisil @roberth
/lib/types.nix @infinisil @roberth
/lib/options.nix @infinisil @roberth
/lib/tests/modules.sh @infinisil @roberth
/lib/tests/modules @infinisil @roberth
# Nixpkgs Internals
/default.nix @Ericson2314
/pkgs/top-level/default.nix @Ericson2314
/pkgs/top-level/impure.nix @Ericson2314
/pkgs/top-level/stage.nix @Ericson2314
/pkgs/top-level/splice.nix @Ericson2314
/pkgs/top-level/release-cross.nix @Ericson2314
/pkgs/top-level/by-name-overlay.nix @infinisil @philiptaron
/pkgs/stdenv @philiptaron @NixOS/stdenv
/pkgs/stdenv/generic @Ericson2314 @NixOS/stdenv
/pkgs/stdenv/generic/check-meta.nix @Ericson2314 @NixOS/stdenv
/pkgs/stdenv/cross @Ericson2314 @NixOS/stdenv
/pkgs/build-support @philiptaron
/pkgs/build-support/cc-wrapper @Ericson2314
/pkgs/build-support/bintools-wrapper @Ericson2314
/pkgs/build-support/setup-hooks @Ericson2314
/pkgs/build-support/setup-hooks/auto-patchelf.sh @layus
/pkgs/by-name/au/auto-patchelf @layus
/pkgs/pkgs-lib @infinisil
## Format generators/serializers
/pkgs/pkgs-lib/formats/libconfig @h7x4
/pkgs/pkgs-lib/formats/hocon @h7x4
# Nixpkgs build-support
/pkgs/build-support/writers @lassulus @Profpatsch
# Nixpkgs make-disk-image
/doc/build-helpers/images/makediskimage.section.md @raitobezarius
/nixos/lib/make-disk-image.nix @raitobezarius
# Nix, the package manager
# @raitobezarius is not "code owner", but is listed here to be notified of changes
# pertaining to the Nix package manager.
# i.e. no authority over those files.
pkgs/tools/package-management/nix/ @NixOS/nix-team @raitobezarius
nixos/modules/installer/tools/nix-fallback-paths.nix @NixOS/nix-team @raitobezarius
# Nixpkgs documentation
/maintainers/scripts/db-to-md.sh @jtojnar @ryantm
/maintainers/scripts/doc @jtojnar @ryantm
# Contributor documentation
/CONTRIBUTING.md @infinisil
/.github/PULL_REQUEST_TEMPLATE.md @infinisil
/doc/contributing/ @infinisil
/doc/contributing/contributing-to-documentation.chapter.md @jtojnar @infinisil
/lib/README.md @infinisil
/doc/README.md @infinisil
/nixos/README.md @infinisil
/pkgs/README.md @infinisil
/pkgs/by-name/README.md @infinisil
/maintainers/README.md @infinisil
# User-facing development documentation
/doc/development.md @infinisil
/doc/development @infinisil
# NixOS Internals
/nixos/default.nix @infinisil
/nixos/lib/from-env.nix @infinisil
/nixos/lib/eval-config.nix @infinisil
/nixos/modules/system/activation/bootspec.nix @grahamc @cole-h @raitobezarius
/nixos/modules/system/activation/bootspec.cue @grahamc @cole-h @raitobezarius
# NixOS integration test driver
/nixos/lib/test-driver @tfc
# NixOS QEMU virtualisation
/nixos/modules/virtualisation/qemu-vm.nix @raitobezarius
# ACME
/nixos/modules/security/acme @NixOS/acme
# Systemd
/nixos/modules/system/boot/systemd.nix @NixOS/systemd
/nixos/modules/system/boot/systemd @NixOS/systemd
/nixos/lib/systemd-*.nix @NixOS/systemd
/pkgs/os-specific/linux/systemd @NixOS/systemd
# Systemd-boot
/nixos/modules/system/boot/loader/systemd-boot @JulienMalka
# Images and installer media
/nixos/modules/profiles/installation-device.nix @ElvishJerricco
/nixos/modules/installer/cd-dvd/ @ElvishJerricco
/nixos/modules/installer/sd-card/
# Amazon
/nixos/modules/virtualisation/amazon-init.nix @arianvp
/nixos/modules/virtualisation/ec2-data.nix @arianvp
/nixos/modules/virtualisation/amazon-options.nix @arianvp
/nixos/modules/virtualisation/amazon-image.nix @arianvp
/nixos/maintainers/scripts/ec2/ @arianvp
/nixos/modules/services/misc/amazon-ssm-agent.nix @arianvp
/nixos/tests/amazon-ssm-agent.nix @arianvp
/nixos/modules/system/boot/grow-partition.nix @arianvp
# Updaters
## update.nix
/maintainers/scripts/update.nix @jtojnar
/maintainers/scripts/update.py @jtojnar
## common-updater-scripts
/pkgs/common-updater/scripts/update-source-version @jtojnar
# Python-related code and docs
/doc/languages-frameworks/python.section.md @mweinelt @natsukium
/maintainers/scripts/update-python-libraries @mweinelt @natsukium
/pkgs/development/interpreters/python @mweinelt @natsukium
/pkgs/top-level/python-packages.nix @natsukium
/pkgs/top-level/release-python.nix @natsukium
# Haskell
/doc/languages-frameworks/haskell.section.md @sternenseemann @maralorn
/maintainers/scripts/haskell @sternenseemann @maralorn
/pkgs/development/compilers/ghc @sternenseemann @maralorn
/pkgs/development/haskell-modules @sternenseemann @maralorn
/pkgs/test/haskell @sternenseemann @maralorn
/pkgs/top-level/release-haskell.nix @sternenseemann @maralorn
/pkgs/top-level/haskell-packages.nix @sternenseemann @maralorn
# Perl
/pkgs/development/interpreters/perl @stigtsp @zakame @marcusramberg
/pkgs/top-level/perl-packages.nix @stigtsp @zakame @marcusramberg
/pkgs/development/perl-modules @stigtsp @zakame @marcusramberg
# R
/pkgs/applications/science/math/R @jbedo
/pkgs/development/r-modules @jbedo
# Rust
/pkgs/development/compilers/rust @alyssais @Mic92 @zowoq @winterqt @figsoda
/pkgs/build-support/rust @zowoq @winterqt @figsoda
/doc/languages-frameworks/rust.section.md @zowoq @winterqt @figsoda
# Tcl
/pkgs/development/interpreters/tcl @fgaz
/pkgs/development/libraries/tk @fgaz
/pkgs/top-level/tcl-packages.nix @fgaz
/pkgs/development/tcl-modules @fgaz
/doc/languages-frameworks/tcl.section.md @fgaz
# C compilers
/pkgs/development/compilers/gcc
/pkgs/development/compilers/llvm @alyssais @RossComputerGuy @NixOS/llvm
/pkgs/development/compilers/emscripten @raitobezarius
/doc/languages-frameworks/emscripten.section.md @raitobezarius
# Audio
/nixos/modules/services/audio/botamusique.nix @mweinelt
/nixos/modules/services/audio/snapserver.nix @mweinelt
/nixos/tests/botamusique.nix @mweinelt
/nixos/tests/snapcast.nix @mweinelt
# Browsers
/pkgs/applications/networking/browsers/firefox @mweinelt
/pkgs/applications/networking/browsers/chromium @emilylange
/nixos/tests/chromium.nix @emilylange
# Certificate Authorities
pkgs/data/misc/cacert/ @ajs124 @lukegb @mweinelt
pkgs/development/libraries/nss/ @ajs124 @lukegb @mweinelt
pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
# Java
/doc/languages-frameworks/java.section.md @NixOS/java
/doc/languages-frameworks/gradle.section.md @NixOS/java
/doc/languages-frameworks/maven.section.md @NixOS/java
/pkgs/top-level/java-packages.nix @NixOS/java
# Jetbrains
/pkgs/applications/editors/jetbrains @edwtjo
# Licenses
/lib/licenses.nix @alyssais
# Qt
/pkgs/development/libraries/qt-5 @K900 @NickCao @SuperSandro2000 @ttuegel
/pkgs/development/libraries/qt-6 @K900 @NickCao @SuperSandro2000 @ttuegel
# KDE / Plasma 5
/pkgs/applications/kde @K900 @NickCao @SuperSandro2000 @ttuegel
/pkgs/desktops/plasma-5 @K900 @NickCao @SuperSandro2000 @ttuegel
/pkgs/development/libraries/kde-frameworks @K900 @NickCao @SuperSandro2000 @ttuegel
# KDE / Plasma 6
/pkgs/kde @K900 @NickCao @SuperSandro2000 @ttuegel
/maintainers/scripts/kde @K900 @NickCao @SuperSandro2000 @ttuegel
# PostgreSQL and related stuff
/pkgs/servers/sql/postgresql @NixOS/postgres
/nixos/modules/services/databases/postgresql.md @NixOS/postgres
/nixos/modules/services/databases/postgresql.nix @NixOS/postgres
/nixos/tests/postgresql @NixOS/postgres
# Hardened profile & related modules
/nixos/modules/profiles/hardened.nix @joachifm
/nixos/modules/security/lock-kernel-modules.nix @joachifm
/nixos/modules/security/misc.nix @joachifm
/nixos/tests/hardened.nix @joachifm
/pkgs/os-specific/linux/kernel/hardened/ @fabianhjr @joachifm
# Home Automation
/nixos/modules/services/home-automation/home-assistant.nix @mweinelt
/nixos/modules/services/home-automation/zigbee2mqtt.nix @mweinelt
/nixos/tests/home-assistant.nix @mweinelt
/nixos/tests/zigbee2mqtt.nix @mweinelt
/pkgs/servers/home-assistant @mweinelt
/pkgs/tools/misc/esphome @mweinelt
# Network Time Daemons
/pkgs/by-name/ch/chrony @thoughtpolice
/pkgs/by-name/nt/ntp @thoughtpolice
/pkgs/by-name/op/openntpd @thoughtpolice
/nixos/modules/services/networking/ntp @thoughtpolice
# Network
/pkgs/by-name/ke/kea @mweinelt
/pkgs/by-name/ba/babeld @mweinelt
/nixos/modules/services/networking/babeld.nix @mweinelt
/nixos/modules/services/networking/kea.nix @mweinelt
/nixos/modules/services/networking/knot.nix @mweinelt
/nixos/modules/services/monitoring/prometheus/exporters/kea.nix @mweinelt
/nixos/tests/babeld.nix @mweinelt
/nixos/tests/kea.nix @mweinelt
/nixos/tests/knot.nix @mweinelt
# Web servers
/doc/packages/nginx.section.md @raitobezarius
/pkgs/servers/http/nginx/ @raitobezarius
/nixos/modules/services/web-servers/nginx/ @raitobezarius
# Dhall
/pkgs/development/dhall-modules @Gabriella439 @Profpatsch @ehmry
/pkgs/development/interpreters/dhall @Gabriella439 @Profpatsch @ehmry
# Idris
/pkgs/development/idris-modules @Infinisil
/pkgs/development/compilers/idris2 @mattpolzin
# Bazel
/pkgs/development/tools/build-managers/bazel @Profpatsch
# NixOS modules for e-mail and dns services
/nixos/modules/services/mail/mailman.nix @peti
/nixos/modules/services/mail/postfix.nix @peti
/nixos/modules/services/networking/bind.nix @peti
/nixos/modules/services/mail/rspamd.nix @peti
# Emacs
/pkgs/applications/editors/emacs/elisp-packages @NixOS/emacs
/pkgs/applications/editors/emacs @NixOS/emacs
/pkgs/top-level/emacs-packages.nix @NixOS/emacs
/doc/packages/emacs.section.md @NixOS/emacs
/nixos/modules/services/editors/emacs.md @NixOS/emacs
# Kakoune
/pkgs/applications/editors/kakoune @philiptaron
# Neovim
/pkgs/applications/editors/neovim @NixOS/neovim
# VimPlugins
/pkgs/applications/editors/vim/plugins @NixOS/neovim
# VsCode Extensions
/pkgs/applications/editors/vscode/extensions
# PHP interpreter, packages, extensions, tests and documentation
/doc/languages-frameworks/php.section.md @aanderse @drupol @globin @ma27 @talyz
/nixos/tests/php @aanderse @drupol @globin @ma27 @talyz
/pkgs/build-support/php/build-pecl.nix @aanderse @drupol @globin @ma27 @talyz
/pkgs/build-support/php @drupol
/pkgs/development/interpreters/php @jtojnar @aanderse @drupol @globin @ma27 @talyz
/pkgs/development/php-packages @aanderse @drupol @globin @ma27 @talyz
/pkgs/top-level/php-packages.nix @jtojnar @aanderse @drupol @globin @ma27 @talyz
# Docker tools
/pkgs/build-support/docker @roberth
/nixos/tests/docker-tools* @roberth
/doc/build-helpers/images/dockertools.section.md @roberth
# Blockchains
/pkgs/applications/blockchains @mmahut @RaghavSood
# Go
/doc/languages-frameworks/go.section.md @kalbasit @katexochen @Mic92 @zowoq
/pkgs/build-support/go @kalbasit @katexochen @Mic92 @zowoq
/pkgs/development/compilers/go @kalbasit @katexochen @Mic92 @zowoq
# GNOME
/pkgs/desktops/gnome @jtojnar
/pkgs/desktops/gnome/extensions @jtojnar
/pkgs/build-support/make-hardcode-gsettings-patch @jtojnar
# Cinnamon
/pkgs/by-name/ci/cinnamon-* @mkg20001
/pkgs/by-name/cj/cjs @mkg20001
/pkgs/by-name/mu/muffin @mkg20001
/pkgs/by-name/ne/nemo @mkg20001
/pkgs/by-name/ne/nemo-* @mkg20001
# Xfce
/doc/hooks/xfce4-dev-tools.section.md @NixOS/xfce
# nim
/doc/languages-frameworks/nim.section.md @ehmry
/pkgs/build-support/build-nim-package.nix @ehmry
/pkgs/top-level/nim-overrides.nix @ehmry
# terraform providers
/pkgs/applications/networking/cluster/terraform-providers @zowoq
# Forgejo
nixos/modules/services/misc/forgejo.nix @adamcstephens @bendlas @emilylange
pkgs/by-name/fo/forgejo/ @adamcstephens @bendlas @emilylange
# Dotnet
/pkgs/build-support/dotnet @corngood
/pkgs/development/compilers/dotnet @corngood
/pkgs/test/dotnet @corngood
/doc/languages-frameworks/dotnet.section.md @corngood
# Node.js
/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
/pkgs/development/compilers/ocaml @ulrikstrid
/pkgs/development/ocaml-modules @ulrikstrid
# ZFS
pkgs/os-specific/linux/zfs/2_1.nix @raitobezarius
pkgs/os-specific/linux/zfs/generic.nix @raitobezarius
nixos/modules/tasks/filesystems/zfs.nix @raitobezarius
nixos/tests/zfs.nix @raitobezarius
# Zig
/pkgs/development/compilers/zig @figsoda
/doc/hooks/zig.section.md @figsoda
# Buildbot
nixos/modules/services/continuous-integration/buildbot @Mic92 @zowoq
nixos/tests/buildbot.nix @Mic92 @zowoq
pkgs/development/tools/continuous-integration/buildbot @Mic92 @zowoq
# Pretix
pkgs/by-name/pr/pretix/ @mweinelt
pkgs/by-name/pr/pretalx/ @mweinelt
nixos/modules/services/web-apps/pretix.nix @mweinelt
nixos/modules/services/web-apps/pretalx.nix @mweinelt
nixos/tests/web-apps/pretix.nix @mweinelt
nixos/tests/web-apps/pretalx.nix @mweinelt
# incus/lxc
nixos/maintainers/scripts/incus/ @adamcstephens
nixos/modules/virtualisation/incus.nix @adamcstephens
nixos/modules/virtualisation/lxc* @adamcstephens
nixos/tests/incus/ @adamcstephens
pkgs/by-name/in/incus/ @adamcstephens
pkgs/by-name/lx/lxc* @adamcstephens
# ExpidusOS, Flutter
/pkgs/development/compilers/flutter @RossComputerGuy
/pkgs/desktops/expidus @RossComputerGuy
# GNU Tar & Zip
/pkgs/tools/archivers/gnutar @RossComputerGuy
/pkgs/by-name/zi/zip @RossComputerGuy
# SELinux
/pkgs/by-name/ch/checkpolicy @RossComputerGuy
/pkgs/by-name/li/libselinux @RossComputerGuy
/pkgs/by-name/li/libsepol @RossComputerGuy
# installShellFiles
/pkgs/by-name/in/installShellFiles/* @Ericson2314
/pkgs/test/install-shell-files/* @Ericson2314
/doc/hooks/installShellFiles.section.md @Ericson2314
# Darwin
/pkgs/by-name/ap/apple-sdk @NixOS/darwin-core
/pkgs/os-specific/darwin/apple-source-releases @NixOS/darwin-core
/pkgs/stdenv/darwin @NixOS/darwin-core

View File

@@ -41,58 +41,3 @@ Why not just build the tooling right from the PRs Nixpkgs version?
- Because it improves security, since we don't have to build potentially untrusted code from PRs.
The tool only needs a very minimal Nix evaluation at runtime, which can work with [readonly-mode](https://nixos.org/manual/nix/stable/command-ref/opt-common.html#opt-readonly-mode) and [restrict-eval](https://nixos.org/manual/nix/stable/command-ref/conf-file.html#conf-restrict-eval).
## `get-merge-commit.sh GITHUB_REPO PR_NUMBER`
Check whether a PR is mergeable and return the test merge commit as
[computed by GitHub](https://docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-your-git-database?apiVersion=2022-11-28#checking-mergeability-of-pull-requests).
Arguments:
- `GITHUB_REPO`: The repository of the PR, e.g. `NixOS/nixpkgs`
- `PR_NUMBER`: The PR number, e.g. `1234`
Exit codes:
- 0: The PR can be merged, the test merge commit hash is returned on stdout
- 1: The PR cannot be merged because it's not open anymore
- 2: The PR cannot be merged because it has a merge conflict
- 3: The merge commit isn't being computed, GitHub is likely having internal issues, unknown if the PR is mergeable
### Usage
This script can be used in GitHub Actions workflows as follows:
```yaml
on: pull_request_target
# We need a token to query the API, but it doesn't need any special permissions
permissions: {}
jobs:
build:
name: Build
runs-on: ubuntu-latest
steps:
# Important: Because of `pull_request_target`, this doesn't check out the PR,
# but rather the base branch of the PR, which is needed so we don't run untrusted code
- uses: actions/checkout@<VERSION>
with:
path: base
sparse-checkout: ci
- name: Resolving the merge commit
env:
GH_TOKEN: ${{ github.token }}
run: |
if mergedSha=$(base/ci/get-merge-commit.sh ${{ github.repository }} ${{ github.event.number }}); then
echo "Checking the merge commit $mergedSha"
echo "mergedSha=$mergedSha" >> "$GITHUB_ENV"
else
# Skipping so that no notifications are sent
echo "Skipping the rest..."
fi
rm -rf base
- uses: actions/checkout@<VERSION>
# Add this to _all_ subsequent steps to skip them
if: env.mergedSha
with:
ref: ${{ env.mergedSha }}
- ...
```

View File

@@ -1,31 +0,0 @@
{
buildGoModule,
fetchFromGitHub,
fetchpatch,
}:
buildGoModule {
name = "codeowners-validator";
src = fetchFromGitHub {
owner = "mszostok";
repo = "codeowners-validator";
rev = "f3651e3810802a37bd965e6a9a7210728179d076";
hash = "sha256-5aSmmRTsOuPcVLWfDF6EBz+6+/Qpbj66udAmi1CLmWQ=";
};
patches = [
# https://github.com/mszostok/codeowners-validator/pull/222
(fetchpatch {
name = "user-write-access-check";
url = "https://github.com/mszostok/codeowners-validator/compare/f3651e3810802a37bd965e6a9a7210728179d076...840eeb88b4da92bda3e13c838f67f6540b9e8529.patch";
hash = "sha256-t3Dtt8SP9nbO3gBrM0nRE7+G6N/ZIaczDyVHYAG/6mU=";
})
# Undoes part of the above PR: We don't want to require write access
# to the repository, that's only needed for GitHub's native CODEOWNERS.
# Furthermore, it removes an unneccessary check from the code
# that breaks tokens generated for GitHub Apps.
./permissions.patch
# Allows setting a custom CODEOWNERS path using the OWNERS_FILE env var
./owners-file-name.patch
];
postPatch = "rm -r docs/investigation";
vendorHash = "sha256-R+pW3xcfpkTRqfS2ETVOwG8PZr0iH5ewroiF7u8hcYI=";
}

View File

@@ -1,15 +0,0 @@
diff --git a/pkg/codeowners/owners.go b/pkg/codeowners/owners.go
index 6910bd2..e0c95e9 100644
--- a/pkg/codeowners/owners.go
+++ b/pkg/codeowners/owners.go
@@ -39,6 +39,10 @@ func NewFromPath(repoPath string) ([]Entry, error) {
// openCodeownersFile finds a CODEOWNERS file and returns content.
// see: https://help.github.com/articles/about-code-owners/#codeowners-file-location
func openCodeownersFile(dir string) (io.Reader, error) {
+ if file, ok := os.LookupEnv("OWNERS_FILE"); ok {
+ return fs.Open(file)
+ }
+
var detectedFiles []string
for _, p := range []string{".", "docs", ".github"} {
pth := path.Join(dir, p)

View File

@@ -1,36 +0,0 @@
diff --git a/internal/check/valid_owner.go b/internal/check/valid_owner.go
index a264bcc..610eda8 100644
--- a/internal/check/valid_owner.go
+++ b/internal/check/valid_owner.go
@@ -16,7 +16,6 @@ import (
const scopeHeader = "X-OAuth-Scopes"
var reqScopes = map[github.Scope]struct{}{
- github.ScopeReadOrg: {},
}
type ValidOwnerConfig struct {
@@ -223,10 +222,7 @@ func (v *ValidOwner) validateTeam(ctx context.Context, name string) *validateErr
for _, t := range v.repoTeams {
// GitHub normalizes name before comparison
if strings.EqualFold(t.GetSlug(), team) {
- if t.Permissions["push"] {
- return nil
- }
- return newValidateError("Team %q cannot review PRs on %q as neither it nor any parent team has write permissions.", team, v.orgRepoName)
+ return nil
}
}
@@ -245,10 +241,7 @@ func (v *ValidOwner) validateGitHubUser(ctx context.Context, name string) *valid
for _, u := range v.repoUsers {
// GitHub normalizes name before comparison
if strings.EqualFold(u.GetLogin(), userName) {
- if u.Permissions["push"] {
- return nil
- }
- return newValidateError("User %q cannot review PRs on %q as they don't have write permissions.", userName, v.orgRepoName)
+ return nil
}
}

View File

@@ -1,29 +0,0 @@
let
pinnedNixpkgs = builtins.fromJSON (builtins.readFile ./pinned-nixpkgs.json);
in
{
system ? builtins.currentSystem,
nixpkgs ? null,
}:
let
nixpkgs' =
if nixpkgs == null then
fetchTarball {
url = "https://github.com/NixOS/nixpkgs/archive/${pinnedNixpkgs.rev}.tar.gz";
sha256 = pinnedNixpkgs.sha256;
}
else
nixpkgs;
pkgs = import nixpkgs' {
inherit system;
config = { };
overlays = [ ];
};
in
{
inherit pkgs;
requestReviews = pkgs.callPackage ./request-reviews { };
codeownersValidator = pkgs.callPackage ./codeowners-validator { };
}

View File

@@ -1,62 +0,0 @@
#!/usr/bin/env bash
# See ./README.md for docs
set -euo pipefail
log() {
echo "$@" >&2
}
if (( $# < 2 )); then
log "Usage: $0 GITHUB_REPO PR_NUMBER"
exit 99
fi
repo=$1
prNumber=$2
# Retry the API query this many times
retryCount=5
# Start with 5 seconds, but double every retry
retryInterval=5
while true; do
log "Checking whether the pull request can be merged"
prInfo=$(gh api \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
"/repos/$repo/pulls/$prNumber")
# Non-open PRs won't have their mergeability computed no matter what
state=$(jq -r .state <<< "$prInfo")
if [[ "$state" != open ]]; then
log "PR is not open anymore"
exit 1
fi
mergeable=$(jq -r .mergeable <<< "$prInfo")
if [[ "$mergeable" == "null" ]]; then
if (( retryCount == 0 )); then
log "Not retrying anymore. It's likely that GitHub is having internal issues: check https://www.githubstatus.com/"
exit 3
else
(( retryCount -= 1 )) || true
# null indicates that GitHub is still computing whether it's mergeable
# Wait a couple seconds before trying again
log "GitHub is still computing whether this PR can be merged, waiting $retryInterval seconds before trying again ($retryCount retries left)"
sleep "$retryInterval"
(( retryInterval *= 2 )) || true
fi
else
break
fi
done
if [[ "$mergeable" == "true" ]]; then
log "The PR can be merged"
jq -r .merge_commit_sha <<< "$prInfo"
else
log "The PR has a merge conflict"
exit 2
fi

View File

@@ -1,43 +0,0 @@
{
lib,
stdenvNoCC,
makeWrapper,
coreutils,
codeowners,
jq,
curl,
github-cli,
gitMinimal,
}:
stdenvNoCC.mkDerivation {
name = "request-reviews";
src = lib.fileset.toSource {
root = ./.;
fileset = lib.fileset.unions [
./get-reviewers.sh
./request-reviews.sh
./verify-base-branch.sh
./dev-branches.txt
];
};
nativeBuildInputs = [ makeWrapper ];
dontBuild = true;
installPhase = ''
mkdir -p $out/bin
mv dev-branches.txt $out/bin
for bin in *.sh; do
mv "$bin" "$out/bin"
wrapProgram "$out/bin/$bin" \
--set PATH ${
lib.makeBinPath [
coreutils
codeowners
jq
curl
github-cli
gitMinimal
]
}
done
'';
}

View File

@@ -1,7 +0,0 @@
# Trusted development branches:
# These generally require PRs to update and are built by Hydra.
master
staging
release-*
staging-*
haskell-updates

View File

@@ -1,126 +0,0 @@
#!/usr/bin/env bash
# Get the code owners of the files changed by a PR,
# suitable to be consumed by the API endpoint to request reviews:
# https://docs.github.com/en/rest/pulls/review-requests?apiVersion=2022-11-28#request-reviewers-for-a-pull-request
set -euo pipefail
log() {
echo "$@" >&2
}
if (( "$#" < 7 )); then
log "Usage: $0 GIT_REPO OWNERS_FILE BASE_REPO BASE_REF HEAD_REF PR_NUMBER PR_AUTHOR"
exit 1
fi
gitRepo=$1
ownersFile=$2
baseRepo=$3
baseRef=$4
headRef=$5
prNumber=$6
prAuthor=$7
tmp=$(mktemp -d)
trap 'rm -rf "$tmp"' exit
git -C "$gitRepo" diff --name-only --merge-base "$baseRef" "$headRef" > "$tmp/touched-files"
readarray -t touchedFiles < "$tmp/touched-files"
log "This PR touches ${#touchedFiles[@]} files"
# Get the owners file from the base, because we don't want to allow PRs to
# remove code owners to avoid pinging them
git -C "$gitRepo" show "$baseRef":"$ownersFile" > "$tmp"/codeowners
# Associative array with the user as the key for easy de-duplication
# Make sure to always lowercase keys to avoid duplicates with different casings
declare -A users=()
for file in "${touchedFiles[@]}"; do
result=$(codeowners --file "$tmp"/codeowners "$file")
read -r file owners <<< "$result"
if [[ "$owners" == "(unowned)" ]]; then
log "File $file is unowned"
continue
fi
log "File $file is owned by $owners"
# Split up multiple owners, separated by arbitrary amounts of spaces
IFS=" " read -r -a entries <<< "$owners"
for entry in "${entries[@]}"; do
# GitHub technically also supports Emails as code owners,
# but we can't easily support that, so let's not
if [[ ! "$entry" =~ @(.*) ]]; then
warn -e "\e[33mCodeowner \"$entry\" for file $file is not valid: Must start with \"@\"\e[0m" >&2
# Don't fail, because the PR for which this script runs can't fix it,
# it has to be fixed in the base branch
continue
fi
# The first regex match is everything after the @
entry=${BASH_REMATCH[1]}
if [[ "$entry" =~ (.*)/(.*) ]]; then
# Teams look like $org/$team
org=${BASH_REMATCH[1]}
team=${BASH_REMATCH[2]}
# Instead of requesting a review from the team itself,
# we request reviews from the individual users.
# This is because once somebody from a team reviewed the PR,
# the API doesn't expose that the team was already requested for a review,
# so we wouldn't be able to avoid rerequesting reviews
# without saving some some extra state somewhere
# We could also consider implementing a more advanced heuristic
# in the future that e.g. only pings one team member,
# but escalates to somebody else if that member doesn't respond in time.
gh api \
--cache=1h \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
"/orgs/$org/teams/$team/members" \
--jq '.[].login' > "$tmp/team-members"
readarray -t members < "$tmp/team-members"
log "Team $entry has these members: ${members[*]}"
for user in "${members[@]}"; do
users[${user,,}]=
done
else
# Everything else is a user
users[${entry,,}]=
fi
done
done
# Cannot request a review from the author
if [[ -v users[${prAuthor,,}] ]]; then
log "One or more files are owned by the PR author, ignoring"
unset 'users[${prAuthor,,}]'
fi
gh api \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
"/repos/$baseRepo/pulls/$prNumber/reviews" \
--jq '.[].user.login' > "$tmp/already-reviewed-by"
# And we don't want to rerequest reviews from people who already reviewed
while read -r user; do
if [[ -v users[${user,,}] ]]; then
log "User $user is a code owner but has already left a review, ignoring"
unset 'users[${user,,}]'
fi
done < "$tmp/already-reviewed-by"
# Turn it into a JSON for the GitHub API call to request PR reviewers
jq -n \
--arg users "${!users[*]}" \
'{
reviewers: $users | split(" "),
}'

View File

@@ -1,95 +0,0 @@
#!/usr/bin/env bash
# Requests reviews for a PR after verifying that the base branch is correct
set -euo pipefail
tmp=$(mktemp -d)
trap 'rm -rf "$tmp"' exit
SCRIPT_DIR=$(dirname "$0")
log() {
echo "$@" >&2
}
effect() {
if [[ -n "${DRY_MODE:-}" ]]; then
log "Skipping in dry mode:" "${@@Q}"
else
"$@"
fi
}
if (( $# < 3 )); then
log "Usage: $0 GITHUB_REPO PR_NUMBER OWNERS_FILE"
exit 1
fi
baseRepo=$1
prNumber=$2
ownersFile=$3
log "Fetching PR info"
prInfo=$(gh api \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
"/repos/$baseRepo/pulls/$prNumber")
baseBranch=$(jq -r .base.ref <<< "$prInfo")
log "Base branch: $baseBranch"
prRepo=$(jq -r .head.repo.full_name <<< "$prInfo")
log "PR repo: $prRepo"
prBranch=$(jq -r .head.ref <<< "$prInfo")
log "PR branch: $prBranch"
prAuthor=$(jq -r .user.login <<< "$prInfo")
log "PR author: $prAuthor"
extraArgs=()
if pwdRepo=$(git rev-parse --show-toplevel 2>/dev/null); then
# Speedup for local runs
extraArgs+=(--reference-if-able "$pwdRepo")
fi
log "Fetching Nixpkgs commit history"
# We only need the commit history, not the contents, so we can do a tree-less clone using tree:0
# https://github.blog/open-source/git/get-up-to-speed-with-partial-clone-and-shallow-clone/#user-content-quick-summary
git clone --bare --filter=tree:0 --no-tags --origin upstream "${extraArgs[@]}" https://github.com/"$baseRepo".git "$tmp"/nixpkgs.git
log "Fetching the PR commit history"
# Fetch the PR
git -C "$tmp/nixpkgs.git" remote add fork https://github.com/"$prRepo".git
# This remote config is the same as --filter=tree:0 when cloning
git -C "$tmp/nixpkgs.git" config remote.fork.partialclonefilter tree:0
git -C "$tmp/nixpkgs.git" config remote.fork.promisor true
git -C "$tmp/nixpkgs.git" fetch --no-tags fork "$prBranch"
headRef=$(git -C "$tmp/nixpkgs.git" rev-parse refs/remotes/fork/"$prBranch")
log "Checking correctness of the base branch"
if ! "$SCRIPT_DIR"/verify-base-branch.sh "$tmp/nixpkgs.git" "$headRef" "$baseRepo" "$baseBranch" "$prRepo" "$prBranch" | tee "$tmp/invalid-base-error" >&2; then
log "Posting error as comment"
if ! response=$(effect gh api \
--method POST \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
"/repos/$baseRepo/issues/$prNumber/comments" \
-F "body=@$tmp/invalid-base-error"); then
log "Failed to post the comment: $response"
fi
exit 1
fi
log "Getting code owners to request reviews from"
"$SCRIPT_DIR"/get-reviewers.sh "$tmp/nixpkgs.git" "$ownersFile" "$baseRepo" "$baseBranch" "$headRef" "$prNumber" "$prAuthor" > "$tmp/reviewers.json"
log "Requesting reviews from: $(<"$tmp/reviewers.json")"
if ! response=$(effect gh api \
--method POST \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
"/repos/$baseRepo/pulls/$prNumber/requested_reviewers" \
--input "$tmp/reviewers.json"); then
log "Failed to request reviews: $response"
exit 1
fi
log "Successfully requested reviews"

View File

@@ -1,104 +0,0 @@
#!/usr/bin/env bash
# Check that a PR doesn't include commits from other development branches.
# Fails with next steps if it does
set -euo pipefail
tmp=$(mktemp -d)
trap 'rm -rf "$tmp"' exit
SCRIPT_DIR=$(dirname "$0")
log() {
echo "$@" >&2
}
# Small helper to check whether an element is in a list
# Usage: `elementIn foo "${list[@]}"`
elementIn() {
local e match=$1
shift
for e; do
if [[ "$e" == "$match" ]]; then
return 0
fi
done
return 1
}
if (( $# < 6 )); then
log "Usage: $0 LOCAL_REPO HEAD_REF BASE_REPO BASE_BRANCH PR_REPO PR_BRANCH"
exit 1
fi
localRepo=$1
headRef=$2
baseRepo=$3
baseBranch=$4
prRepo=$5
prBranch=$6
# All development branches
devBranchPatterns=()
while read -r pattern; do
if [[ "$pattern" != '#'* ]]; then
devBranchPatterns+=("$pattern")
fi
done < "$SCRIPT_DIR/dev-branches.txt"
git -C "$localRepo" branch --list --format "%(refname:short)" "${devBranchPatterns[@]}" > "$tmp/dev-branches"
readarray -t devBranches < "$tmp/dev-branches"
if [[ "$baseRepo" == "$prRepo" ]] && elementIn "$prBranch" "${devBranches[@]}"; then
log "This PR merges $prBranch into $baseBranch, no commit check necessary"
exit 0
fi
# The current merge base of the PR
prMergeBase=$(git -C "$localRepo" merge-base "$baseBranch" "$headRef")
log "The PR's merge base with the base branch $baseBranch is $prMergeBase"
# This is purely for debugging
git -C "$localRepo" rev-list --reverse "$baseBranch".."$headRef" > "$tmp/pr-commits"
log "The PR includes these $(wc -l < "$tmp/pr-commits") commits:"
cat <"$tmp/pr-commits" >&2
for testBranch in "${devBranches[@]}"; do
if [[ -z "$(git -C "$localRepo" rev-list -1 --since="1 month ago" "$testBranch")" ]]; then
log "Not checking $testBranch, was inactive for the last month"
continue
fi
log "Checking if commits from $testBranch are included in the PR"
# We need to check for any commits that are in the PR which are also in the test branch.
# We could check each commit from the PR individually, but that's unnecessarily slow.
#
# This does _almost_ what we want: `git rev-list --count headRef testBranch ^baseBranch`,
# except that it includes commits that are reachable from _either_ headRef or testBranch,
# instead of restricting it to ones reachable by both
# Easily fixable though, because we can use `git merge-base testBranch headRef`
# to get the least common ancestor (aka merge base) commit reachable by both.
# If the branch being tested is indeed the right base branch,
# this is then also the commit from that branch that the PR is based on top of.
testMergeBase=$(git -C "$localRepo" merge-base "$testBranch" "$headRef")
# And then use the `git rev-list --count`, but replacing the non-working
# `headRef testBranch` with the merge base of the two.
extraCommits=$(git -C "$localRepo" rev-list --count "$testMergeBase" ^"$baseBranch")
if (( extraCommits != 0 )); then
log -e "\e[33m"
echo "The PR's base branch is set to $baseBranch, but $extraCommits commits from the $testBranch branch are included. Make sure you know the [right base branch for your changes](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#branch-conventions), then:"
echo "- If the changes should go to the $testBranch branch, [change the base branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request) to $testBranch"
echo "- If the changes should go to the $baseBranch branch, rebase your PR onto the merge base with the $baseBranch branch:"
echo " \`\`\`bash"
echo " # git rebase --onto \$(git merge-base upstream/$baseBranch HEAD) \$(git merge-base upstream/$testBranch HEAD)"
echo " git rebase --onto $prMergeBase $testMergeBase"
echo " git push --force-with-lease"
echo " \`\`\`"
log -e "\e[m"
exit 1
fi
done
log "Base branch is correct, no commits from development branches are included"

View File

@@ -176,138 +176,126 @@ 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.
### One sentence per line
- 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.
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.
- Use the [admonition syntax](#admonitions) for callouts and examples.
### Callouts and examples
- 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.
Use the [admonition syntax](#admonitions) for callouts and examples.
Example code should be such that it can be passed to `pkgs.callPackage`.
Instead of something like:
### Provide self-contained examples
```nix
pkgs.dockerTools.buildLayeredImage {
name = "hello";
contents = [ pkgs.hello ];
}
```
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.
Write something like:
Example code should be such that it can be passed to `pkgs.callPackage`.
Instead of something like:
```nix
{ dockerTools, hello }:
dockerTools.buildLayeredImage {
name = "hello";
contents = [ hello ];
}
```
```nix
pkgs.dockerTools.buildLayeredImage {
name = "hello";
contents = [ pkgs.hello ];
}
```
- 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.
Write something like:
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.
```nix
{ dockerTools, hello }:
dockerTools.buildLayeredImage {
name = "hello";
contents = [ hello ];
}
```
- 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.
### REPLs
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
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.
Some explanation about the function here.
Describe a particular scenario, and point to [](#ex-dockerTools-buildImage), which is an example demonstrating it.
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.
### Inputs
### Headings for inputs, outputs and examples
Documentation for the inputs of `buildImage`.
Perhaps even point to [](#ex-dockerTools-buildImage) again when talking about something specifically linked to it.
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.
### Passthru outputs
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
Documentation for any passthru outputs of `buildImage`.
Some explanation about the function here.
Describe a particular scenario, and point to [](#ex-dockerTools-buildImage), which is an example demonstrating it.
### Examples
### Inputs
Note that this is the last nested heading in the `buildImage` section.
Documentation for the inputs of `buildImage`.
Perhaps even point to [](#ex-dockerTools-buildImage) again when talking about something specifically linked to it.
:::{.example #ex-dockerTools-buildImage}
### Passthru outputs
# Using `buildImage`
Documentation for any passthru outputs of `buildImage`.
Example of how to use `buildImage` goes here.
### Examples
:::
```
Note that this is the last nested heading in the `buildImage` section.
- 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:
:::{.example #ex-dockerTools-buildImage}
```markdown
# pkgs.coolFunction {#pkgs.coolFunction}
# Using `buildImage`
`pkgs.coolFunction` *`name`* *`config`*
Example of how to use `buildImage` goes here.
:::
```
### Function arguments
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:
```markdown
# pkgs.coolFunction {#pkgs.coolFunction}
`pkgs.coolFunction` *`name`* *`config`*
Description of what `callPackage` does.
Description of what `callPackage` does.
## Inputs {#pkgs-coolFunction-inputs}
## Inputs {#pkgs-coolFunction-inputs}
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.
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.
*`name`* (String)
*`name`* (String)
: The name of the resulting image.
: The name of the resulting image.
*`config`* (Attribute set)
*`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.
: 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_)
`outputHash` (String; _optional_)
: A brief explanation including when and when not to pass this attribute.
: A brief explanation including when and when not to pass this attribute.
: _Default:_ the output path's hash.
```
: _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

View File

@@ -117,7 +117,7 @@ in appimageTools.wrapType2 {
install -m 444 -D ${appimageContents}/usr/share/icons/hicolor/512x512/apps/irccloud.png \
$out/share/icons/hicolor/512x512/apps/irccloud.png
substituteInPlace $out/share/applications/irccloud.desktop \
--replace-fail 'Exec=AppRun' 'Exec=${pname}'
--replace 'Exec=AppRun' 'Exec=${pname}'
'';
}
```
@@ -147,7 +147,7 @@ let
appimageContents = appimageTools.extract {
inherit pname version src;
postExtract = ''
substituteInPlace $out/irccloud.desktop --replace-fail 'Exec=AppRun' 'Exec=${pname}'
substituteInPlace $out/irccloud.desktop --replace 'Exec=AppRun' 'Exec=${pname}'
'';
};
in appimageTools.wrapType2 {

View File

@@ -125,8 +125,6 @@ A set of functions that build a predefined set of minimal Linux distributions im
* `debian10x86_64`
* `debian11i386`
* `debian11x86_64`
* `debian12i386`
* `debian12x86_64`
### Attributes {#vm-tools-diskImageFuns-attributes}

View File

@@ -732,7 +732,7 @@ writeShellApplication {
## `symlinkJoin` {#trivial-builder-symlinkJoin}
This can be used to put many derivations into the same directory structure. It works by creating a new derivation and adding symlinks to each of the paths listed. It expects two arguments, `name`, and `paths`. `name` (or alternatively `pname` and `version`) is the name used in the Nix store path for the created derivation. `paths` is a list of paths that will be symlinked. These paths can be to Nix store derivations or any other subdirectory contained within.
This can be used to put many derivations into the same directory structure. It works by creating a new derivation and adding symlinks to each of the paths listed. It expects two arguments, `name`, and `paths`. `name` is the name used in the Nix store path for the created derivation. `paths` is a list of paths that will be symlinked. These paths can be to Nix store derivations or any other subdirectory contained within.
Here is an example:
```nix
# adds symlinks of hello and stack to current build and prints "links added"

View File

@@ -74,7 +74,7 @@
}
{
name = "customisation";
description = "Functions to customise (derivation-related) functions, derivations, or attribute sets";
description = "Functions to customise (derivation-related) functions, derivatons, or attribute sets";
}
{
name = "meta";

View File

@@ -5,8 +5,6 @@
lib,
stdenvNoCC,
callPackage,
devmode,
mkShellNoCC,
documentation-highlighter,
nixos-render-docs,
nixpkgs ? { },
@@ -97,14 +95,10 @@ stdenvNoCC.mkDerivation (
pythonInterpreterTable = callPackage ./python-interpreter-table.nix { };
shell =
let
devmode' = devmode.override {
buildArgs = "./.";
open = "/share/doc/nixpkgs/manual.html";
};
in
mkShellNoCC { packages = [ devmode' ]; };
shell = callPackage ../../pkgs/tools/nix/web-devmode.nix {
buildArgs = "./.";
open = "/share/doc/nixpkgs/manual.html";
};
tests.manpage-urls = callPackage ../tests/manpage-urls.nix { };
};

View File

@@ -1,4 +0,0 @@
# `aws-c-common` {#aws-c-common}
This hook exposes its own [CMake](#cmake) modules by setting [`CMAKE_MODULE_PATH`](https://cmake.org/cmake/help/latest/variable/CMAKE_MODULE_PATH.html) through [the `cmakeFlags` variable](#cmake-flags)
to the nonstandard `$out/lib/cmake` directory, as a workaround for [an upstream bug](https://github.com/awslabs/aws-c-common/issues/844).

View File

@@ -1,35 +1,3 @@
# cmake {#cmake}
Overrides the default configure phase to run the CMake command.
By default, we use the Make generator of CMake.
But when Ninja is also available as a `nativeBuildInput`, this setup hook will detect that and use the ninja generator.
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.
By default, parallel building is enabled as CMake supports parallel building almost everywhere.
You can disable this hooks behavior by setting `configurePhase` to a custom value, or by setting `dontUseCmakeConfigure`.
## Variables controlling CMake {#cmake-variables-controlling}
### CMake Exclusive Variables {#cmake-exclusive-variables}
#### `cmakeFlags` {#cmake-flags}
Controls the flags passed to `cmake setup` during configure phase.
#### `cmakeBuildDir` {#cmake-build-dir}
Directory where CMake will put intermediate files.
Setting this can be useful for debugging multiple CMake builds while in the same source directory, for example, when building for different platforms.
Different values for each build will prevent build artefacts from interefering with each other.
This setting has no tangible effect when running the build in a sandboxed derivation.
The default value is `build`.
#### `dontUseCmakeConfigure` {#dont-use-cmake-configure}
When set to true, don't use the predefined `cmakeConfigurePhase`.
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 hooks 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.

View File

@@ -1,5 +0,0 @@
# desktop-file-utils {#desktop-file-utils}
This setup hook removes the MIME cache (located at `$out/share/applications/mimeinfo.cache`) in the `preFixupPhase`.
This hook is necessary because `mimeinfo.cache` can be created when a package uses `desktop-file-utils`, resulting in collisions if multiple packages are installed that contain this file (as in [#48295](https://github.com/NixOS/nixpkgs/issues/48295)).

View File

@@ -8,12 +8,10 @@ The stdenv built-in hooks are documented in [](#ssec-setup-hooks).
autoconf.section.md
automake.section.md
autopatchelf.section.md
aws-c-common.section.md
bmake.section.md
breakpoint.section.md
cernlib.section.md
cmake.section.md
desktop-file-utils.section.md
gdk-pixbuf.section.md
ghc.section.md
gnome.section.md
@@ -32,7 +30,6 @@ postgresql-test-hook.section.md
premake.section.md
python.section.md
scons.section.md
tauri.section.md
tetex-tex-live.section.md
unzip.section.md
validatePkgConfig.section.md
@@ -40,5 +37,4 @@ versionCheckHook.section.md
waf.section.md
zig.section.md
xcbuild.section.md
xfce4-dev-tools.section.md
```

View File

@@ -6,7 +6,7 @@ This setup hook attempts to use [the `just` command runner](https://just.systems
## `buildPhase` {#just-hook-buildPhase}
This phase attempts to invoke `just` with [the default recipe](https://just.systems/man/en/the-default-recipe.html).
This phase attempts to invoke `just` with [the default recipe](https://just.systems/man/en/chapter_23.html).
[]{#just-hook-dontUseJustBuild} This behavior can be disabled by setting `dontUseJustBuild` to `true`.

View File

@@ -18,16 +18,6 @@ setup hook registering ninja-based build and install phases.
Controls the flags passed to `meson setup` during configure phase.
#### `mesonBuildDir` {#meson-build-dir}
Directory where Meson will put intermediate files.
Setting this can be useful for debugging multiple Meson builds while in the same source directory, for example, when building for different platforms.
Different values for each build will prevent build artefacts from interefering with each other.
This setting has no tangible effect when running the build in a sandboxed derivation.
The default value is `build`.
#### `mesonWrapMode` {#meson-wrap-mode}
Which value is passed as

View File

@@ -1,108 +0,0 @@
# cargo-tauri.hook {#tauri-hook}
[Tauri](https://tauri.app/) is a framework for building smaller, faster, and
more secure desktop applications with a web frontend.
In Nixpkgs, `cargo-tauri.hook` overrides the default build and install phases.
## Example code snippet {#tauri-hook-example-code-snippet}
```nix
{
lib,
stdenv,
rustPlatform,
fetchNpmDeps,
cargo-tauri,
darwin,
glib-networking,
libsoup,
nodejs,
npmHooks,
openssl,
pkg-config,
webkitgtk_4_0,
wrapGAppsHook3,
}:
rustPlatform.buildRustPackage rec {
# . . .
cargoHash = "...";
# Assuming our app's frontend uses `npm` as a package manager
npmDeps = fetchNpmDeps {
name = "${pname}-npm-deps-${version}";
inherit src;
hash = "...";
};
nativeBuildInputs = [
# Pull in our main hook
cargo-tauri.hook
# Setup npm
nodejs
npmHooks.npmConfigHook
# Make sure we can find our libraries
pkg-config
wrapGAppsHook3
];
buildInputs =
[ openssl ]
++ lib.optionals stdenv.hostPlatform.isLinux [
glib-networking # Most Tauri apps need networking
libsoup
webkitgtk_4_0
]
++ lib.optionals stdenv.hostPlatform.isDarwin (
with darwin.apple_sdk.frameworks;
[
AppKit
CoreServices
Security
WebKit
]
);
# Set our Tauri source directory
cargoRoot = "src-tauri";
# And make sure we build there too
buildAndTestSubdir = cargoRoot;
# . . .
}
```
## Variables controlling cargo-tauri {#tauri-hook-variables-controlling}
### Tauri Exclusive Variables {#tauri-hook-exclusive-variables}
#### `tauriBuildFlags` {#tauri-build-flags}
Controls the flags passed to `cargo tauri build`.
#### `tauriBundleType` {#tauri-bundle-type}
The [bundle type](https://tauri.app/v1/guides/building/) to build.
#### `dontTauriBuild` {#dont-tauri-build}
Disables using `tauriBuildHook`.
#### `dontTauriInstall` {#dont-tauri-install}
Disables using `tauriInstallPostBuildHook` and `tauriInstallHook`.
### Honored Variables {#tauri-hook-honored-variables}
Along with those found in [](#compiling-rust-applications-with-cargo), the
following variables used by `cargoBuildHook` and `cargoInstallHook` are honored
by the cargo-tauri setup hook.
- `buildAndTestSubdir`
- `cargoBuildType`
- `cargoBuildNoDefaultFeatures`
- `cargoBuildFeatures`

View File

@@ -28,7 +28,7 @@ It does so in a clean environment (using `env --ignore-environment`), and it che
The variables that this phase control are:
- `dontVersionCheck`: Disable adding this hook to the [`preInstallCheckHooks`](#ssec-installCheck-phase). Useful if you do want to load the bash functions of the hook, but run them differently.
- `dontVersionCheck`: Disable adding this hook to the [`preDistPhases`](#var-stdenv-preDist). Useful if you do want to load the bash functions of the hook, but run them differently.
- `versionCheckProgram`: The full path to the program that should print the `${version}` string. Defaults roughly to `${placeholder "out"}/bin/${pname}`. Using `$out` in the value of this variable won't work, as environment variables from this variable are not expanded by the hook. Hence using `placeholder` is unavoidable.
- `versionCheckProgramArg`: The argument that needs to be passed to `versionCheckProgram`. If undefined the hook tries first `--help` and then `--version`. Examples: `version`, `-V`, `-v`.
- `preVersionCheck`: A hook to run before the check is done.

View File

@@ -1,5 +0,0 @@
# `xfce.xfce4-dev-tools` {#xfce4-dev-tools}
This setup hook attempts to run `xdt-autogen` in `xdtAutogenPhase`, which is part of `preConfigurePhases`.
[]{#dontUseXdtAutogenPhase} This behavior can be disabled by setting `dontUseXdtAutogenPhase` to `true`.

View File

@@ -349,8 +349,8 @@ let
nodePackages.prettier
];
inputs = basePackages ++ lib.optionals stdenv.hostPlatform.isLinux [ inotify-tools ]
++ lib.optionals stdenv.hostPlatform.isDarwin
inputs = basePackages ++ lib.optionals stdenv.isLinux [ inotify-tools ]
++ lib.optionals stdenv.isDarwin
(with darwin.apple_sdk.frameworks; [ CoreFoundation CoreServices ]);
# define shell startup command

View File

@@ -4,7 +4,7 @@
The end result of running Bower is a `bower_components` directory which can be included in the web app's build process.
Bower can be run interactively, by installing `nodePackages.bower`. More interestingly, the Bower components can be declared in a Nix derivation, with the help of `bower2nix`.
Bower can be run interactively, by installing `nodePackages.bower`. More interestingly, the Bower components can be declared in a Nix derivation, with the help of `nodePackages.bower2nix`.
## bower2nix usage {#ssec-bower2nix-usage}

View File

@@ -149,104 +149,3 @@ All new projects should use the CUDA redistributables available in [`cudaPackage
| Find libraries | `buildPhase` or `patchelf` | Missing dependency on a `lib` or `static` output | Add the missing dependency | The `lib` or `static` output typically contain the libraries |
In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary.
## Running Docker or Podman containers with CUDA support {#cuda-docker-podman}
It is possible to run Docker or Podman containers with CUDA support. The recommended mechanism to perform this task is to use the [NVIDIA Container Toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/index.html).
The NVIDIA Container Toolkit can be enabled in NixOS like follows:
```nix
{
hardware.nvidia-container-toolkit.enable = true;
}
```
This will automatically enable a service that generates a CDI specification (located at `/var/run/cdi/nvidia-container-toolkit.json`) based on the auto-detected hardware of your machine. You can check this service by running:
```ShellSession
$ systemctl status nvidia-container-toolkit-cdi-generator.service
```
::: {.note}
Depending on what settings you had already enabled in your system, you might need to restart your machine in order for the NVIDIA Container Toolkit to generate a valid CDI specification for your machine.
:::
Once that a valid CDI specification has been generated for your machine on boot time, both Podman and Docker (> 25) will use this spec if you provide them with the `--device` flag:
```ShellSession
$ podman run --rm -it --device=nvidia.com/gpu=all ubuntu:latest nvidia-smi -L
GPU 0: NVIDIA GeForce RTX 4090 (UUID: <REDACTED>)
GPU 1: NVIDIA GeForce RTX 2080 SUPER (UUID: <REDACTED>)
```
```ShellSession
$ docker run --rm -it --device=nvidia.com/gpu=all ubuntu:latest nvidia-smi -L
GPU 0: NVIDIA GeForce RTX 4090 (UUID: <REDACTED>)
GPU 1: NVIDIA GeForce RTX 2080 SUPER (UUID: <REDACTED>)
```
You can check all the identifiers that have been generated for your auto-detected hardware by checking the contents of the `/var/run/cdi/nvidia-container-toolkit.json` file:
```ShellSession
$ nix run nixpkgs#jq -- -r '.devices[].name' < /var/run/cdi/nvidia-container-toolkit.json
0
1
all
```
### Specifying what devices to expose to the container {#specifying-what-devices-to-expose-to-the-container}
You can choose what devices are exposed to your containers by using the identifier on the generated CDI specification. Like follows:
```ShellSession
$ podman run --rm -it --device=nvidia.com/gpu=0 ubuntu:latest nvidia-smi -L
GPU 0: NVIDIA GeForce RTX 4090 (UUID: <REDACTED>)
```
You can repeat the `--device` argument as many times as necessary if you have multiple GPU's and you want to pick up which ones to expose to the container:
```ShellSession
$ podman run --rm -it --device=nvidia.com/gpu=0 --device=nvidia.com/gpu=1 ubuntu:latest nvidia-smi -L
GPU 0: NVIDIA GeForce RTX 4090 (UUID: <REDACTED>)
GPU 1: NVIDIA GeForce RTX 2080 SUPER (UUID: <REDACTED>)
```
::: {.note}
By default, the NVIDIA Container Toolkit will use the GPU index to identify specific devices. You can change the way to identify what devices to expose by using the `hardware.nvidia-container-toolkit.device-name-strategy` NixOS attribute.
:::
### Using docker-compose {#using-docker-compose}
It's possible to expose GPU's to a `docker-compose` environment as well. With a `docker-compose.yaml` file like follows:
```yaml
services:
some-service:
image: ubuntu:latest
command: sleep infinity
deploy:
resources:
reservations:
devices:
- driver: cdi
device_ids:
- nvidia.com/gpu=all
```
In the same manner, you can pick specific devices that will be exposed to the container:
```yaml
services:
some-service:
image: ubuntu:latest
command: sleep infinity
deploy:
resources:
reservations:
devices:
- driver: cdi
device_ids:
- nvidia.com/gpu=0
- nvidia.com/gpu=1
```

View File

@@ -84,7 +84,7 @@ One advantage is that when `pkgs.zlib` is updated, it will automatically update
echo "================= /testing zlib using node ================="
'';
postPatch = pkgs.lib.optionalString pkgs.stdenv.hostPlatform.isDarwin ''
postPatch = pkgs.lib.optionalString pkgs.stdenv.isDarwin ''
substituteInPlace configure \
--replace-fail '/usr/bin/libtool' 'ar' \
--replace-fail 'AR="libtool"' 'AR="ar"' \

View File

@@ -64,7 +64,7 @@ To avoid costly file system access when locating icons, GTK, [as well as Qt](htt
### Packaging icon themes {#ssec-icon-theme-packaging}
Icon themes may inherit from other icon themes. The inheritance is specified using the `Inherits` key in the `index.theme` file distributed with the icon theme. According to the [icon theme specification](https://specifications.freedesktop.org/icon-theme-spec/latest), icons not provided by the theme are looked for in its parent icon themes. Therefore the parent themes should be installed as dependencies for a more complete experience regarding the icon sets used.
Icon themes may inherit from other icon themes. The inheritance is specified using the `Inherits` key in the `index.theme` file distributed with the icon theme. According to the [icon theme specification](https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html), icons not provided by the theme are looked for in its parent icon themes. Therefore the parent themes should be installed as dependencies for a more complete experience regarding the icon sets used.
The package `hicolor-icon-theme` provides a setup hook which makes symbolic links for the parent themes into the directory `share/icons` of the current theme directory in the nix store, making sure they can be found at runtime. For that to work the packages providing parent icon themes should be listed as propagated build dependencies, together with `hicolor-icon-theme`.
@@ -155,11 +155,9 @@ 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 or hooks you can end up with double wrapped binaries. {#ssec-gnome-common-issues-double-wrapped}
### When using `wrapGApps*` hook with special derivers you can end up with double wrapped binaries. {#ssec-gnome-common-issues-double-wrapped}
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.
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.
In the case of a Python application it could look like:
@@ -186,19 +184,19 @@ python3.pkgs.buildPythonApplication {
And for a QT app like:
```nix
stdenv.mkDerivation {
mkDerivation {
pname = "calibre";
version = "3.47.0";
nativeBuildInputs = [
wrapGAppsHook3
qt6.wrapQtAppsHook
qmake
# ...
];
dontWrapGApps = true;
# Arguments to be passed to `makeWrapper`, only used by qt5s mkDerivation
preFixup = ''
qtWrapperArgs+=("''${gappsWrapperArgs[@]}")
'';

View File

@@ -57,8 +57,8 @@ Available compilers are collected under `haskell.compiler`.
Each of those compiler versions has a corresponding attribute set `packages` built with
it. However, the non-standard package sets are not tested regularly and, as a
result, contain fewer working packages. The corresponding package set for GHC
9.4.5 is `haskell.packages.ghc945`. In fact `haskellPackages` (at the time of writing) is just an alias
for `haskell.packages.ghc966`:
9.4.5 is `haskell.packages.ghc945`. In fact `haskellPackages` is just an alias
for `haskell.packages.ghc964`:
Every package set also re-exposes the GHC used to build its packages as `haskell.packages.*.ghc`.
@@ -191,10 +191,6 @@ and `version` from Hackage.
`sha256`
: Hash to use for the default case of `src`.
`sourceRoot`, `setSourceRoot`
: Passed to `stdenv.mkDerivation`; see [“Variables controlling the unpack
phase”](#variables-controlling-the-unpack-phase).
`revision`
: Revision number of the updated cabal file to fetch from Hackage.
If `null` (which is the default value), the one included in `src` is used.
@@ -764,7 +760,7 @@ that depend on that library, you may want to use:
```nix
haskellPackages.haskell-ci.overrideScope (self: super: {
Cabal = self.Cabal_3_14_0_0;
Cabal = self.Cabal_3_6_2_0;
})
```
@@ -1080,9 +1076,6 @@ benchmark component.
`disableLibraryProfiling drv`
: Sets the `enableLibraryProfiling` argument to `false` for `drv`.
`disableParallelBuilding drv`
: Sets the `enableParallelBuilding` argument to `false` for `drv`.
#### Library functions in the Haskell package sets {#haskell-package-set-lib-functions}
Some library functions depend on packages from the Haskell package sets. Thus they are

View File

@@ -93,7 +93,6 @@ ruby.section.md
rust.section.md
scheme.section.md
swift.section.md
tcl.section.md
texlive.section.md
titanium.section.md
vim.section.md

View File

@@ -33,7 +33,8 @@ stdenv.mkDerivation {
```
Note that `jdk` is an alias for the OpenJDK (self-built where available,
or pre-built via Zulu).
or pre-built via Zulu). Platforms with OpenJDK not (yet) in Nixpkgs
(`Aarch32`, `Aarch64`) point to the (unfree) `oraclejdk`.
Also note that not using `stripJavaArchivesHook` will likely cause the
generated `.jar` files to be non-deterministic, which is not optimal.

View File

@@ -428,26 +428,7 @@ NOTE: It is highly recommended to use a pinned version of pnpm (i.e. `pnpm_8` or
In case you are patching `package.json` or `pnpm-lock.yaml`, make sure to pass `finalAttrs.patches` to the function as well (i.e. `inherit (finalAttrs) patches`.
`pnpm.configHook` supports adding additional `pnpm install` flags via `pnpmInstallFlags` which can be set to a Nix string array:
```nix
{
pnpm,
}:
stdenv.mkDerivation (finalAttrs: {
pname = "foo";
version = "0-unstable-1980-01-01";
src = ...;
pnpmInstallFlags = [ "--shamefully-hoist" ];
pnpmDeps = pnpm.fetchDeps {
inherit (finalAttrs) pnpmInstallFlags;
};
})
```
`pnpm.configHook` supports adding additional `pnpm install` flags via `pnpmInstallFlags` which can be set to a Nix string array.
#### Dealing with `sourceRoot` {#javascript-pnpm-sourceRoot}
@@ -478,16 +459,16 @@ Assuming the following directory structure, we can define `sourceRoot` and `pnpm
#### PNPM Workspaces {#javascript-pnpm-workspaces}
If you need to use a PNPM workspace for your project, then set `pnpmWorkspaces = [ "<workspace project name 1>" "<workspace project name 2>" ]`, etc, in your `pnpm.fetchDeps` call,
which will make PNPM only install dependencies for those workspace packages.
If you need to use a PNPM workspace for your project, then set `pnpmWorkspace = "<workspace project name>"` in your `pnpm.fetchDeps` call,
which will make PNPM only install dependencies for that workspace package.
For example:
```nix
...
pnpmWorkspaces = [ "@astrojs/language-server" ];
pnpmWorkspace = "@astrojs/language-server";
pnpmDeps = pnpm.fetchDeps {
inherit (finalAttrs) pnpmWorkspaces;
inherit (finalAttrs) pnpmWorkspace;
...
}
```
@@ -495,7 +476,7 @@ pnpmDeps = pnpm.fetchDeps {
The above would make `pnpm.fetchDeps` call only install dependencies for the `@astrojs/language-server` workspace package.
Note that you do not need to set `sourceRoot` to make this work.
Usually in such cases, you'd want to use `pnpm --filter=<pnpm workspace name> build` to build your project, as `npmHooks.npmBuildHook` probably won't work. A `buildPhase` based on the following example will probably fit most workspace projects:
Usually in such cases, you'd want to use `pnpm --filter=$pnpmWorkspace build` to build your project, as `npmHooks.npmBuildHook` probably won't work. A `buildPhase` based on the following example will probably fit most workspace projects:
```nix
buildPhase = ''

View File

@@ -125,8 +125,8 @@ On Darwin, if a script has too many `-Idir` flags in its first line (its “sheb
hash = "sha256-vOhB/FwQMC8PPvdnjDvxRpU6jAZcC6GMQfc0AH4uwKg=";
};
nativeBuildInputs = lib.optional stdenv.hostPlatform.isDarwin shortenPerlShebang;
postInstall = lib.optionalString stdenv.hostPlatform.isDarwin ''
nativeBuildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
postInstall = lib.optionalString stdenv.isDarwin ''
shortenPerlShebang $out/bin/exiftool
'';
};

View File

@@ -55,7 +55,6 @@ sets are
* `pkgs.python311Packages`
* `pkgs.python312Packages`
* `pkgs.python313Packages`
* `pkgs.python314Packages`
* `pkgs.pypy27Packages`
* `pkgs.pypy39Packages`
* `pkgs.pypy310Packages`
@@ -412,7 +411,7 @@ let
};
};
pythonEnv = myPython.withPackages (ps: [ ps.my-editable ]);
pythonEnv = testPython.withPackages (ps: [ ps.my-editable ]);
in pkgs.mkShell {
packages = [ pythonEnv ];
@@ -1307,7 +1306,7 @@ for example:
] ++ lib.optionals (pythonAtLeast "3.8") [
# broken due to python3.8 async changes
"async"
] ++ lib.optionals stdenv.buildPlatform.isDarwin [
] ++ lib.optionals stdenv.isDarwin [
# can fail when building with other packages
"socket"
];

View File

@@ -25,14 +25,12 @@ stdenv.mkDerivation {
The same goes for Qt 5 where libraries and tools are under `libsForQt5`.
Any Qt package should include `wrapQtAppsHook` or `wrapQtAppsNoGuiHook` in `nativeBuildInputs`, or explicitly set `dontWrapQtApps` to bypass generating the wrappers.
Any Qt package should include `wrapQtAppsHook` in `nativeBuildInputs`, or explicitly set `dontWrapQtApps` to bypass generating the wrappers.
::: {.note}
Qt 6 graphical applications should also include `qtwayland` in `buildInputs` on Linux (but not on platforms e.g. Darwin, where `qtwayland` is not available), to ensure the Wayland platform plugin is available.
`wrapQtAppsHook` propagates plugins and QML components from `qtwayland` on platforms that support it, to allow applications to act as native Wayland clients. It should be used for all graphical applications.
`wrapQtAppsNoGuiHook` does not propagate `qtwayland` to reduce closure size for purely command-line applications.
This may become default in the future, see [NixOS/nixpkgs#269674](https://github.com/NixOS/nixpkgs/pull/269674).
:::
## Packages supporting multiple Qt versions {#qt-versions}

View File

@@ -162,10 +162,9 @@ rustPlatform.buildRustPackage {
}
```
If the upstream source repository lacks a `Cargo.lock` file, you must add one
to `src`, as it is essential for building a Rust package. Setting
`cargoLock.lockFile` or `cargoLock.lockFileContents` will not automatically add
a `Cargo.lock` file to `src`. A straightforward solution is to use:
Note that setting `cargoLock.lockFile` or `cargoLock.lockFileContents`
doesn't add a `Cargo.lock` to your `src`, and a `Cargo.lock` is still
required to build a rust package. A simple fix is to use:
```nix
{
@@ -679,7 +678,7 @@ Some projects, especially GNOME applications, are built with the Meson Build Sys
, blueprint-compiler
, libadwaita
, libsecret
, tinysparql
, tracker
}:
stdenv.mkDerivation rec {
@@ -713,7 +712,7 @@ stdenv.mkDerivation rec {
buildInputs = [
libadwaita
libsecret
tinysparql
tracker
];
# ...

View File

@@ -1,54 +0,0 @@
# Tcl {#sec-language-tcl}
## User guide {#sec-language-tcl-user-guide}
Tcl interpreters are available under the `tcl` and `tcl-X_Y` attributes, where `X_Y` is the Tcl version.
Tcl libraries are available in the `tclPackages` attribute set.
They are only guaranteed to work with the default Tcl version, but will probably also work with others thanks to the [stubs mechanism](https://wiki.tcl-lang.org/page/Stubs).
## Packaging guide {#sec-language-tcl-packaging}
Tcl packages are typically built with `tclPackages.mkTclDerivation`.
Tcl dependencies go in `buildInputs`/`nativeBuildInputs`/... like other packages.
For more complex package definitions, such as packages with mixed languages, use `tcl.tclPackageHook`.
Where possible, make sure to enable stubs for maximum compatibility, usually with the `--enable-stubs` configure flag.
Here is a simple package example to be called with `tclPackages.callPackage`.
```
{ lib, fetchzip, mkTclDerivation, openssl }:
mkTclDerivation rec {
pname = "tcltls";
version = "1.7.22";
src = fetchzip {
url = "https://core.tcl-lang.org/tcltls/uv/tcltls-${version}.tar.gz";
hash = "sha256-TOouWcQc3MNyJtaAGUGbaQoaCWVe6g3BPERct/V65vk=";
};
buildInputs = [ openssl ];
configureFlags = [
"--with-ssl-dir=${openssl.dev}"
"--enable-stubs"
];
meta = {
homepage = "https://core.tcl-lang.org/tcltls/index";
description = "OpenSSL / RSA-bsafe Tcl extension";
maintainers = [ lib.maintainers.agbrooks ];
license = lib.licenses.tcltk;
platforms = lib.platforms.unix;
};
}
```
All Tcl libraries are declared in `pkgs/top-level/tcl-packages.nix` and are defined in `pkgs/development/tcl-modules/`.
If possible, prefer the by-name hierarchy in `pkgs/development/tcl-modules/by-name/`.
Its use is documented in `pkgs/development/tcl-modules/by-name/README.md`.
All Tcl applications reside elsewhere.
In case a package is used as both a library and an application (for example `expect`), it should be defined in `tcl-packages.nix`, with an alias elsewhere.

View File

@@ -232,19 +232,6 @@ To add a new plugin, run `nix-shell -p vimPluginsUpdater --run 'vim-plugins-upda
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 `vimPluginsUpdater` 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.
### Testing Neovim plugins {#testing-neovim-plugins}
`nvimRequireCheck=MODULE` is a simple test which checks if Neovim can requires the lua module `MODULE` without errors. This is often enough to catch missing dependencies.
This can be manually added through plugin definition overrides in the [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix).
```nix
gitsigns-nvim = super.gitsigns-nvim.overrideAttrs {
dependencies = [ self.plenary-nvim ];
nvimRequireCheck = "gitsigns";
};
```
### Plugin optional configuration {#vim-plugin-required-snippet}
Some plugins require specific configuration to work. We choose not to

View File

@@ -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/nix-builder-vm.nix"
"${nixpkgs}/nixos/modules/profiles/macos-builder.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/nix-builder-vm.nix"
"${nixpkgs}/nixos/modules/profiles/macos-builder.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/nix-builder-vm.nix"; value = 3072; } ]
[ { file = "/home/user/src/nixpkgs/nixos/modules/profiles/macos-builder.nix"; value = 3072; } ]
```

View File

@@ -181,31 +181,6 @@ 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:

View File

@@ -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. 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.
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.)
## Writing a split derivation {#sec-multiple-outputs-}

View File

@@ -79,7 +79,7 @@ Besides tests provided by upstream, that you run in the [`checkPhase`](#ssec-che
- They access the package as consumers would, independently from the environment in which it was built
- They can be run and debugged without rebuilding the package, which is useful if that takes a long time
- They don't add overhead to each build, as opposed checks added to the [`installCheckPhase`](#ssec-installCheck-phase), such as [`versionCheckHook`](#versioncheckhook).
- They don't add overhead to each build, as opposed checks added to the [`distPhase`](#ssec-distribution-phase), such as [`versionCheckHook`](#versioncheckhook).
It is also possible to use `passthru.tests` to test the version with [`testVersion`](#tester-testVersion), but since that is pretty trivial and recommended thing to do, we recommend using [`versionCheckHook`](#versioncheckhook) for that, which has the following advantages over `passthru.tests`:

View File

@@ -2,301 +2,66 @@
## Darwin (macOS) {#sec-darwin}
The Darwin `stdenv` differs from most other ones in Nixpkgs in a few key ways.
These differences reflect the default assumptions for building software on that platform.
In many cases, you can ignore these differences because the software you are packaging is already written with them in mind.
When you do that, write your derivation as normal. You dont have to include any Darwin-specific special cases.
The easiest way to know whether your derivation requires special handling for Darwin is to write it as if it doesnt and see if it works.
If it does, youre done; skip the rest of this.
Some common issues when packaging software for Darwin:
- Darwin uses Clang by default instead of GCC. Packages that refer to `$CC` or `cc` should just work in most cases.
Some packages may hardcode `gcc` or `g++`. You can usually fix that by setting `makeFlags = [ "CC=cc" "CXX=C++" ]`.
If that does not work, you will have to patch the build scripts yourself to use the correct compiler for Darwin.
- Darwin needs an SDK to build software.
The SDK provides a default set of frameworks and libraries to build software, most of which are specific to Darwin.
There are multiple versions of the SDK packages in Nixpkgs, but one is included by default in the `stdenv`.
Usually, you dont have to change or pick a different SDK. When in doubt, use the default.
- The SDK used by your build can be found using the `DEVELOPER_DIR` environment variable.
There are also versions of this variable available when cross-compiling depending on the SDKs role.
The `SDKROOT` variable is also set with the path to the SDKs libraries and frameworks.
`SDKROOT` is always a sub-folder of `DEVELOPER_DIR`.
- Darwin includes a platform-specific tool called `xcrun` to help builds locate binaries they need.
A version of `xcrun` is part of the `stdenv` on Darwin.
If your package invokes `xcrun` via an absolute path (such as `/usr/bin/xcrun`), you will need to patch the build scripts to use `xcrun` instead.
- The Darwin `stdenv` uses clang instead of gcc. When referring to the compiler `$CC` or `cc` will work in both cases. Some builds hardcode gcc/g++ in their build scripts, that can usually be fixed with using something like `makeFlags = [ "CC=cc" ];` or by patching the build scripts.
To reiterate: you usually dont have to worry about this stuff.
Start with writing your derivation as if everything is already set up for you (because in most cases it already is).
If you run into issues or failures, continue reading below for how to deal with the most common issues you may encounter.
### Darwin Issue Troubleshooting {#sec-darwin-troubleshooting}
#### Package requires a non-default SDK or fails to build due to missing frameworks or symbols {#sec-darwin-troubleshooting-using-sdks}
In some cases, you may have to use a non-default SDK.
This can happen when a package requires APIs that are not present in the default SDK.
For example, Metal Performance Shaders were added in macOS 12.
If the default SDK is 11.3, then a package that requires Metal Performance Shaders will fail to build due to missing frameworks and symbols.
To use a non-default SDK, add it to your derivations `buildInputs`.
It is not necessary to override the SDK in the `stdenv` nor is it necessary to override the SDK used by your dependencies.
If your derivation needs a non-default SDK at build time (e.g., for a `depsBuildBuild` compiler), see the cross-compilation documentation for which input you should use.
When determining whether to use a non-default SDK, consider the following:
- Try building your derivation with the default SDK. If it works, youre done.
- If the package specifies a specific version, use that. See below for how to map Xcode version to SDK version.
- If the packages documentation indicates it supports optional features on newer SDKs, consider using the SDK that enables those features.
If youre not sure, use the default SDK.
Note: It is possible to have multiple, different SDK versions in your inputs.
When that happens, the one with the highest version is always used.
```nix
stdenv.mkDerivation {
name = "libfoo-1.2.3";
# ...
buildInputs = [ apple-sdk_14 ];
}
```
#### What is a “deployment target” (or minimum version)? {#sec-darwin-troubleshooting-using-deployment-targets}
The “deployment target” refers to the minimum version of macOS that is expected to run an application.
In most cases, the default is fine, and you dont have to do anything else.
If youre not sure, dont do anything, and that will probably be fine.
Some packages require setting a non-default deployment target (or minimum version) to gain access to certain APIs.
You do that using the `darwinMinVersionHook`, which takes the deployment target version as a parameter.
There are primarily two ways to determine the deployment target.
- The upstream documentation will specify a deployment target or minimum version. Use that.
- The build will fail because an API requires a certain version. Use that.
- In all other cases, you probably dont need to specify a minimum version. The default is usually good enough.
```nix
stdenv.mkDerivation {
name = "libfoo-1.2.3"; # Upstream specifies the minimum supported version as 12.5.
buildInputs = [ (darwinMinVersionHook "12.5") ];
}
```
Note: It is possible to have multiple, different instances of `darwinMinVerisonHook` in your inputs.
When that happens, the one with the highest version is always used.
#### Picking an SDK version {#sec-darwin-troubleshooting-picking-sdk-version}
The following is a list of Xcode versions, the SDK version in Nixpkgs, and the attribute to use to add it.
Check your packages documentation (platform support or installation instructions) to find which Xcode or SDK version to use.
Generally, only the last SDK release for a major version is packaged (each _x_ in 10._x_ until 10.15 is considered a major version).
| Xcode version | SDK version | Nixpkgs attribute |
|--------------------|---------------------------------------------------|-------------------|
| Varies by platform | 10.12.2 (x86_64-darwin)<br/>11.3 (aarch64-darwin) | `apple-sdk` |
| 8.08.3.3 | 10.12.2 | `apple-sdk_10_12` |
| 9.09.4.1 | 10.13.2 | `apple-sdk_10_13` |
| 10.010.3 | 10.14.6 | `apple-sdk_10_14` |
| 11.011.7 | 10.15.6 | `apple-sdk_10_15` |
| 12.012.5.1 | 11.3 | `apple-sdk_11` |
| 13.013.4.1 | 12.3 | `apple-sdk_12` |
| 14.014.3.1 | 13.3 | `apple-sdk_13` |
| 15.015.4 | 14.4 | `apple-sdk_14` |
| 16.0 | 15.0 | `apple-sdk_15` |
#### Darwin Default SDK versions {#sec-darwin-troubleshooting-darwin-defaults}
The current default versions of the deployment target (minimum version) and SDK are indicated by Darwin-specific attributes on the platform. Because of the ways that minimum version and SDK can be changed that are not visible to Nix, they should be treated as lower bounds.
If you need to parameterize over a specific version, create a function that takes the version as a parameter instead of relying on these attributes.
- `darwinMinVersion` defaults to 10.12 on x86_64-darwin and 11.0 on aarch64-darwin.
It sets the default deployment target.
- `darwinSdkVersion` defaults to 10.12 on x86-64-darwin and 11.0 on aarch64-darwin.
Only the major version determines the SDK version, resulting in the 10.12.2 and 11.3 SDKs being used on these platforms respectively.
#### `xcrun` cannot find a binary {#sec-darwin-troubleshooting-xcrun}
`xcrun` searches `PATH` and the SDKs toolchain for binaries to run.
If it cannot find a required binary, it will fail. When that happens, add the package for that binary to your derivations `nativeBuildInputs` (or `nativeCheckInputs` if the failure is happening when running tests).
```nix
stdenv.mkDerivation {
name = "libfoo-1.2.3";
# ...
nativeBuildInputs = [ bison ];
buildCommand = ''
xcrun bison foo.y # produces foo.tab.c
```nix
stdenv.mkDerivation {
name = "libfoo-1.2.3";
# ...
'';
}
```
buildPhase = ''
$CC -o hello hello.c
'';
}
```
#### Package requires `xcodebuild` {#sec-darwin-troubleshooting-xcodebuild}
- On Darwin, libraries are linked using absolute paths, libraries are resolved by their `install_name` at link time. Sometimes packages wont set this correctly causing the library lookups to fail at runtime. This can be fixed by adding extra linker flags or by running `install_name_tool -id` during the `fixupPhase`.
The xcbuild package provides an `xcodebuild` command for packages that really depend on Xcode.
This replacement is not 100% compatible and may run into some issues, but it is able to build many packages.
To use `xcodebuild`, add `xcbuildHook` to your packages `nativeBuildInputs`.
It will provide a `buildPhase` for your derivation.
You can use `xcbuildFlags` to specify flags to `xcodebuild` such as the required schema.
If a schema has spaces in its name, you must set `__structuredAttrs` to `true`.
See MoltenVK for an example of setting up xcbuild.
```nix
stdenv.mkDerivation {
name = "libfoo-1.2.3";
# ...
makeFlags = lib.optional stdenv.isDarwin "LDFLAGS=-Wl,-install_name,$(out)/lib/libfoo.dylib";
}
```
```nix
stdenv.mkDerivation {
name = "libfoo-1.2.3";
xcbuildFlags = [
"-configuration"
"Release"
"-project"
"libfoo-project.xcodeproj"
"-scheme"
"libfoo Package (macOS only)"
];
__structuredAttrs = true;
}
```
- Even if the libraries are linked using absolute paths and resolved via their `install_name` correctly, tests can sometimes fail to run binaries. This happens because the `checkPhase` runs before the libraries are installed.
##### Fixing absolute paths to `xcodebuild`, `xcrun`, and `PlistBuddy` {#sec-darwin-troubleshooting-xcodebuild-absolute-paths}
This can usually be solved by running the tests after the `installPhase` or alternatively by using `DYLD_LIBRARY_PATH`. More information about this variable can be found in the *dyld(1)* manpage.
Many build systems hardcode the absolute paths to `xcodebuild`, `xcrun`, and `PlistBuddy` as `/usr/bin/xcodebuild`, `/usr/bin/xcrun`, and `/usr/libexec/PlistBuddy` respectively.
These paths will need to be replaced with relative paths and the xcbuild package if `xcodebuild` or `PListBuddy` are used.
```
dyld: Library not loaded: /nix/store/7hnmbscpayxzxrixrgxvvlifzlxdsdir-jq-1.5-lib/lib/libjq.1.dylib
Referenced from: /private/tmp/nix-build-jq-1.5.drv-0/jq-1.5/tests/../jq
Reason: image not found
./tests/jqtest: line 5: 75779 Abort trap: 6
```
```nix
stdenv.mkDerivation {
name = "libfoo-1.2.3";
postPatch = ''
subsituteInPlace Makefile \
--replace-fail '/usr/bin/xcodebuild' 'xcodebuild' \
--replace-fail '/usr/bin/xcrun' 'xcrun' \
--replace-fail '/usr/bin/PListBuddy' 'PListBuddy'
'';
}
```
```nix
stdenv.mkDerivation {
name = "libfoo-1.2.3";
# ...
doInstallCheck = true;
installCheckTarget = "check";
}
```
#### How to use libiconv on Darwin {#sec-darwin-troubleshooting-libiconv}
- Some packages assume xcode is available and use `xcrun` to resolve build tools like `clang`, etc. This causes errors like `xcode-select: error: no developer tools were found at '/Applications/Xcode.app'` while the build doesnt actually depend on xcode.
The libiconv package is included in the SDK by default along with libresolv and libsbuf.
You do not need to do anything to use these packages. They are available automatically.
If your derivation needs the `iconv` binary, add the `libiconv` package to your `nativeBuildInputs` (or `nativeCheckInputs` for tests).
```nix
stdenv.mkDerivation {
name = "libfoo-1.2.3";
# ...
prePatch = ''
substituteInPlace Makefile \
--replace-fail '/usr/bin/xcrun clang' clang
'';
}
```
#### Library install name issues {#sec-darwin-troubleshooting-install-name}
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.
Libraries on Darwin are usually linked with absolute paths.
This is determined by something called an “install name”, which is resolved at link time.
Sometimes packages will not set this correctly, causing binaries linking to it not to find their libraries at runtime.
This can be fixed by adding extra linker flags or by using `install_name_tool` to set it in `fixupPhase`.
##### Setting the install name via linker flags {#sec-darwin-troubleshooting-install-name-linker-flags}
```nix
stdenv.mkDerivation {
name = "libfoo-1.2.3";
# ...
makeFlags = lib.optional stdenv.hostPlatform.isDarwin "LDFLAGS=-Wl,-install_name,$(out)/lib/libfoo.dylib";
}
```
##### Setting the install name using `install_name_tool` {#sec-darwin-troubleshooting-install-name-install_name_tool}
```nix
stdenv.mkDerivation {
name = "libfoo-1.2.3";
# ...
postFixup = ''
# `-id <install_name>` takes the install name. The last parameter is the path to the library.
${stdenv.cc.targetPrefix}install_name_tool -id "$out/lib/libfoo.dylib" "$out/lib/libfoo.dylib"
'';
}
```
Even if libraries are linked using absolute paths and resolved via their install name correctly, tests in `checkPhase` can sometimes fail to run binaries because they are linked against libraries that have not yet been installed.
This can usually be solved by running the tests after the `installPhase` or by using `DYLD_LIBRARY_PATH` (see {manpage}`dyld(1)` for more on setting `DYLD_LIBRARY_PATH`).
##### Setting the install name using `fixDarwinDylibNames` hook {#sec-darwin-troubleshooting-install-name-fixDarwinDylibNames}
If your package has numerous dylibs needing fixed, while it is preferable to fix the issue in the packages build, you can update them all by adding the `fixDarwinDylibNames` hook to your `nativeBuildInputs`.
This hook will scan your packages outputs for dylibs and correct their install names.
Note that if any binaries in your outputs linked those dylibs, you may need to use `install_name_tool` to replace references to them with the correct paths.
#### Propagating an SDK (advanced, compilers-only) {#sec-darwin-troubleshooting-propagating-sdks}
The SDK is a package, and it can be propagated.
`darwinMinVersionHook` with a version specified can also be propagated.
However, most packages should *not* do this.
The exception is compilers.
When you propagate an SDK, it becomes part of your derivations public API, and changing the SDK or removing it can be a breaking change.
That is why propagating it is only recommended for compilers.
When authoring a compiler derivation, propagate the SDK only for the ways you expect users to use your compiler.
Depending on your expected use cases, you may have to do one or all of these.
- Put it in `depsTargetTargetPropagated` when your compiler is expected to be added to `nativeBuildInputs`.
That will ensure the SDK is effectively part of the target derivations `buildInputs`.
- If your compiler uses a hook, put it in the hooks `depsTargetTargetPropagated` instead.
The effect should be the same as the above.
- If your package uses the builder pattern, update your builder to add the SDK to the derivations `buildInputs`.
If youre not sure whether to propagate an SDK, dont.
If your package is a compiler or language, and youre not sure, ask @NixOS/darwin-maintainers for help deciding.
### Dealing with `darwin.apple_sdk.frameworks` {#sec-darwin-legacy-frameworks}
You may see references to `darwin.apple_sdk.frameworks`.
This is the legacy SDK pattern, and it is being phased out.
All packages in `darwin.apple_sdk`, `darwin.apple_sdk_11_0`, and `darwin.apple_sdk_12_3` are stubs that do nothing.
If your derivation references them, you can delete them. The default SDK should be enough to build your package.
Note: the new SDK pattern uses the name `apple-sdk` to better align with Nixpkgs naming conventions.
The legacy SDK pattern uses `apple_sdk`.
You always know you are using the old SDK pattern if the name is `apple_sdk`.
Some derivations may depend on the location of frameworks in those old packages.
To update your derivation to find them in the new SDK, use `$SDKROOT` instead in `preConfigure`.
For example, if you substitute `${darwin.apple_sdk.frameworks.OpenGL}/Library/Frameworks/OpenGL.framework` in `postPatch`, replace it with `$SDKROOT/System/Library/Frameworks/OpenGL.framework` in `preConfigure`.
Note that if your derivation is changing a system path (such as `/System/Library/Frameworks/OpenGL.framework`), you may be able to remove the path.
Compilers and binutils targeting Darwin look for system paths in the SDK sysroot.
Some of them (such as Zig or `bindgen` for Rust) depend on it.
#### Updating legacy SDK overrides {#sec-darwin-legacy-frameworks-overrides}
The legacy SDK provided two ways of overriding the default SDK.
These are both being phased out along with the legacy SDKs.
They have been updated to set up the new SDK for you, but you should replace them with doing that directly.
- `pkgs.darwin.apple_sdk_11_0.callPackage` - this pattern was used to provide frameworks from the 11.0 SDK.
It now adds the `apple-sdk_11` package to your derivations build inputs.
- `overrideSDK` - this stdenv adapter would try to replace the frameworks used by your derivation and its transitive dependencies.
It now adds the `apple-sdk_11` package for `11.0` or the `apple-sdk_12` package for `12.3`.
If `darwinMinVersion` is specified, it will add `darwinMinVersionHook` with the specified minimum version.
No other SDK versions are supported.
### Darwin Cross-Compilation {#sec-darwin-legacy-cross-compilation}
Darwin supports cross-compilation between Darwin platforms.
Cross-compilation from Linux is not currently supported but may be supported in the future.
To cross-compile to Darwin, you can set `crossSystem` or use one of the Darwin systems in `pkgsCross`.
The `darwinMinVersionHook` and the SDKs support cross-compilation.
If you need to specify a different SDK version for a `depsBuildBuild` compiler, add it to your `nativeBuildInputs`.
```nix
stdenv.mkDerivation {
name = "libfoo-1.2.3";
# ...
depsBuildBuild = [ buildPackages.stdenv.cc ];
nativeBuildInputs = [ apple-sdk_12 ];
buildInputs = [ apple-sdk_13 ];
depsTargetTargetPropagated = [ apple-sdk_14 ];
}
# The build-build `clang` will use the 12.3 SDK while the package build itself will use the 13.3 SDK.
# Derivations that add this package as an input will have the 14.4 SDK propagated to them.
```
The different target SDK and hooks are mangled based on role:
- `DEVELOPER_DIR_FOR_BUILD` and `MACOSX_DEPLOYMENT_TARGET_FOR_BUILD` for the build platform;
- `DEVELOPER_DIR` and `MACOSX_DEPLOYMENT_TARGET` for the host platform; and
- `DEVELOPER_DIR_FOR_TARGET` and `MACOSX_DEPLOYMENT_TARGET_FOR_TARGET` for the build platform.
In static compilation situations, it is possible for the build and host platform to be the same platform but have different SDKs with the same version (one dynamic and one static).
cc-wrapper and bintools-wrapper take care of handling this distinction.
- 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.

View File

@@ -518,10 +518,8 @@ There are a number of variables that control what phases are executed and in wha
Specifies the phases. You can change the order in which phases are executed, or add new phases, by setting this variable. If its not set, the default value is used, which is `$prePhases unpackPhase patchPhase $preConfigurePhases configurePhase $preBuildPhases buildPhase checkPhase $preInstallPhases installPhase fixupPhase installCheckPhase $preDistPhases distPhase $postPhases`.
The elements of `phases` must not contain spaces. If `phases` is specified as a Nix Language attribute, it should be specified as lists instead of strings. The same rules apply to the `*Phases` variables.
It is discouraged to set this variable, as it is easy to miss some important functionality hidden in some of the less obviously needed phases (like `fixupPhase` which patches the shebang of scripts).
Usually, if you just want to add a few phases, its more convenient to set one of the `*Phases` variables below.
Usually, if you just want to add a few phases, its more convenient to set one of the variables below (such as `preInstallPhases`).
##### `prePhases` {#var-stdenv-prePhases}

View File

@@ -2,6 +2,7 @@
```{=include=} chapters
using/platform-support.chapter.md
using/as-a-function.chapter.md
using/configuration.chapter.md
using/overlays.chapter.md
using/overrides.chapter.md

View File

@@ -0,0 +1,156 @@
# Nixpkgs as a Function {#sec-nixpkgs-function}
Depending on how you use Nixpkgs, you may interact with it as a [Nix function].
The Nixpkgs function returns an attribute set containing mostly packages, but also other things, such as more package sets, and functions.
This return value is often referred to with the identifier `pkgs`, and it has a marker attribute, `_type = "pkgs";`.
The Nixpkgs function can be retrieved in multiple ways.
In a setup with [Nix channels], you may look up the Nixpkgs files with [`<nixpkgs>`][Nix lookup path]; for example
```console
$ nix repl -f '<nixpkgs>'
Added 21938 variables.
nix-repl>
```
<!-- -f: abbreviated form because it is very frequently used -->
[`nix repl`] [`-f`][`nix repl -f`] automatically imports the Nixpkgs function and invokes it for you.
Most Nix commands accept [`--arg`] and [`--argstr`] options to pass arguments to the Nixpkgs function.
In an expression, you can use the `import <nixpkgs> { }` syntax to import the Nixpkgs function, and immmediately [apply] it.
```nix
let
pkgs = import <nixpkgs> {
config = { allowUnfree = true; };
};
in
```
Note that these examples so far have relied on the implicit, [impure] [`builtins.currentSystem`] variable to configure the package set to be able to run on your system.
If you wish not to accidentally rely on the implicit [`builtins.currentSystem`] variable, and you'd like to avoid configuration in `~/.config/nixpkgs`, you may invoke `<nixpkgs/pkgs/top-level>` instead.
To make sure you can reproduce your evaluations, you may use [pinning] or locking, such as provided by [`npins`] or [Flakes].
## Arguments {#sec-nixpkgs-arguments}
For historical reasons, the platform and cross compilation parameters can be specified in multiple ways.
If you run Nix in pure mode, or if you work with expressions for multiple host platforms, you are recommended to use `hostPlatform` for native compilation (locally or on a remote machine), and both `hostPlatform` and `buildPlatform` for cross compilation.
### `hostPlatform` and `buildPlatform` {#sec-nixpkgs-arguments-platforms}
- `hostPlatform` is the platform for which the package set is built. This means that the binaries in the outputs are compatible with `hostPlatform`.
You may specify this as a cpu-os string, such as `"x86_64-linux"`, or `aarch64-darwin`, or you can pass a more details platform object produced with `lib.systems`.
- `buildPlatform` (default: `hostPlatform`) is the platform on which the derivations will run. The derivations produced by Nixpkgs will have a [`system` attribute] that matches `buildPlatform`, so that builds are sent to a machine that is capable of running the `builder` command, which is also configured to be compatible with `buildPlatform`.
Values are specified in the same formats as `hostPlatform`.
::: {.example #ex-nixpkgs-pure-native}
# Natively compiled packages
This shows how to explicitly request packages that are built for a specific platform, not relying on [`builtins.currentSystem`].
The packages will be built natively.
If you request to build this on a host that is not compatible, you need a remote builder.
```nix
let
pkgs = imports <nixpkgs> {
hostPlatform = "x86_64-linux";
};
in pkgs.hello
```
:::
::: {.example #ex-nixpkgs-pure-cross}
# Cross compiled packages
This expression will produce packages that are built on `x86_64-linux` machines, but whose outputs can run on `riscv64-linux`.
The expression is pure, so it will produce the same outcome even if run on e.g. an `aarch64-darwin` machine. For that to work, the macOS machine needs the packages to be available in a cache or it needs a remote builder that can build `x86_64-linux` derivations.
If you were to use [`builtins.currentSystem`] for `buildPlatform`, you would be able to build the packages directly on any machine, but the resulting store paths will be different, depending on the current system.
Especially if you are in a team that doesn't run a single CPU architecture and operating system or you use Nix on machines of more than one platform, you might notice that equivalent deployments would have different store paths, resulting in unnecessary rebuilds, more store path copying, and unnecessary updates to equivalent configurations with different `buildPlatform`s.
For these reason, it is recommended to use pure configurations where the platform parameters are set to fixed values for each deployment target.
```nix
let
pkgs = imports <nixpkgs> {
hostPlatform = "riscv64-linux";
buildPlatform = "x86_64-linux";
};
in pkgs.hello
```
:::
### Legacy arguments `system`, `localSystem` and `crossSystem` {#sec-nixpkgs-arguments-systems-legacy}
`crossSystem` and `system` (or `localSystem`) are ok to use on the command line, but are not recommended for pure Nix code (such as Nix flakes), or Nix code that manages the invocation of the Nixpkgs function.
These parameters existed before [`hostPlatform` and `buildPlatform`](#sec-nixpkgs-arguments-platforms) were introduced.
They are still supported, but are not recommended for new code.
The main difference is that these parameters default to [`builtins.currentSystem`], which does not work for pure code.
Furthermore, their design is optimized for impure command line use.
The term "local" is misleading, because it need not match the platform where the Nix command is run.
The term "cross" is also misleading because its value may equal `localSystem`.
Finally `crossSystem` may have to be unset as an input, complicating some code that calls the Nixpkgs function.
<!-- This example transgresses the guidelines a bit, but we have an audience here that needs answers, because who likes change. Without explanation, this comes across as a superficial, unnecessary and annoying change. Remove this example in 2026 when it is irrelevant. -->
For example, [`nixos-generate-config`] wasn't initially able to set the platform in `hardware-configuration.nix` without making assumptions about cross versus native compilation, resulting in a need for you to manually specify `system` when Flakes were introduced.
### `config` {#sec-nixpkgs-arguments-config}
Example:
```nix
import <nixpkgs> { config = { allowUnfree = true; }; }
```
See [Configuration](#sec-config-options-reference) for details.
### `overlays` {#sec-nixpkgs-arguments-overlays}
Overlays are expressions that modify the package set.
See [Overlays](#chap-overlays) for more information.
### `crossOverlays` {#sec-nixpkgs-arguments-crossOverlays}
<!-- Source: https://matthewbauer.us/slides/always-be-cross-compiling.pdf -->
Cross overlays apply only to the final package set in cross compilation.
This means that [`buildPackages`] and [`nativeBuildInputs`] are unaffected by these overlays and this increases the number of build dependencies that can be retrieved from the cache, or can be reused from a previous build.
[Nix function]: https://nix.dev/manual/nix/latest/language/constructs.html#functions
[Nix channels]: https://nix.dev/manual/nix/latest/command-ref/nix-channel.html
[Nix lookup path]: https://nix.dev/manual/nix/latest/language/constructs/lookup-path.html
[`builtins.currentSystem`]: https://nix.dev/manual/nix/latest/language/builtin-constants.html#builtins-currentSystem
[`system` attribute]: https://nix.dev/manual/nix/latest/language/derivations#attr-system
[`--arg`]: https://nix.dev/manual/nix/latest/command-ref/opt-common.html?highlight=--arg#opt-arg
[`--argstr`]: https://nix.dev/manual/nix/latest/command-ref/opt-common.html?highlight=--argstr#opt-argstr
[apply]: https://nix.dev/manual/nix/latest/language/operators
[impure]: https://nix.dev/manual/nix/latest/command-ref/conf-file.html?highlight=pure-eval#conf-pure-eval
[`npins`]: https://nix.dev/guides/recipes/dependency-management.html
[Flakes]: https://nix.dev/concepts/flakes.html#flakes
[pinning]: https://nix.dev/reference/pinning-nixpkgs.html
<!-- TODO: publish NixOS man pages -->
[`nixos-generate-config`]: https://nixos.org/manual/nixos/stable/#sec-installation
<!-- TODO: make more specific -->
[`buildPackages`]: #ssec-cross-dependency-implementation
<!-- TODO: make more specific -->
[`nativeBuildInputs`]: #ssec-stdenv-dependencies-propagated
[`nix repl`]: https://nix.dev/manual/nix/latest/command-ref/new-cli/nix3-repl.html
[`nix repl -f`]: https://nix.dev/manual/nix/latest/command-ref/new-cli/nix3-repl?highlight=--file#opt-file

View File

@@ -80,17 +80,8 @@
checks = forAllSystems (system: {
tarball = jobs.${system}.tarball;
} // lib.optionalAttrs
(
self.legacyPackages.${system}.stdenv.hostPlatform.isLinux
# Exclude power64 due to "libressl is not available on the requested hostPlatform" with hostPlatform being power64
&& !self.legacyPackages.${system}.targetPlatform.isPower64
# Exclude armv6l-linux due to "cannot bootstrap GHC on this platform ('armv6l-linux' with libc 'defaultLibc')"
&& system != "armv6l-linux"
# Exclude riscv64-linux due to "cannot bootstrap GHC on this platform ('riscv64-linux' with libc 'defaultLibc')"
&& system != "riscv64-linux"
)
{
# Exclude power64 due to "libressl is not available on the requested hostPlatform" with hostPlatform being power64
} // lib.optionalAttrs (self.legacyPackages.${system}.stdenv.hostPlatform.isLinux && !self.legacyPackages.${system}.targetPlatform.isPower64) {
# Test that ensures that the nixosSystem function can accept a lib argument
# Note: prefer not to extend or modify `lib`, especially if you want to share reusable modules
# alternatives include: `import` a file, or put a custom library in an option or in `_module.args.<libname>`
@@ -120,20 +111,10 @@
}).nixos.manual;
};
devShells = forAllSystems (system:
{ } // lib.optionalAttrs
(
# Exclude armv6l-linux because "Package ghc-9.6.6 in .../pkgs/development/compilers/ghc/common-hadrian.nix:579 is not available on the requested hostPlatform"
system != "armv6l-linux"
# Exclude riscv64-linux because "Package ghc-9.6.6 in .../pkgs/development/compilers/ghc/common-hadrian.nix:579 is not available on the requested hostPlatform"
&& system != "riscv64-linux"
# Exclude FreeBSD because "Package ghc-9.6.6 in .../pkgs/development/compilers/ghc/common-hadrian.nix:579 is not available on the requested hostPlatform"
&& !self.legacyPackages.${system}.stdenv.hostPlatform.isFreeBSD
)
{
/** A shell to get tooling for Nixpkgs development. See nixpkgs/shell.nix. */
default = import ./shell.nix { inherit system; };
});
devShells = forAllSystems (system: {
/** A shell to get tooling for Nixpkgs development. See nixpkgs/shell.nix. */
default = import ./shell.nix { inherit system; };
});
/**
A nested structure of [packages](https://nix.dev/manual/nix/latest/glossary#package-attribute-set) and other values.

View File

@@ -5,9 +5,9 @@
let
inherit (builtins) head length;
inherit (lib.trivial) oldestSupportedReleaseIsAtLeast mergeAttrs warn warnIf;
inherit (lib.trivial) isInOldestRelease mergeAttrs warn warnIf;
inherit (lib.strings) concatStringsSep concatMapStringsSep escapeNixIdentifier sanitizeDerivationName;
inherit (lib.lists) filter foldr foldl' concatMap elemAt all partition groupBy take foldl;
inherit (lib.lists) foldr foldl' concatMap elemAt all partition groupBy take foldl;
in
rec {
@@ -644,7 +644,8 @@ rec {
filterAttrs =
pred:
set:
removeAttrs set (filter (name: ! pred name set.${name}) (attrNames set));
listToAttrs (concatMap (name: let v = set.${name}; in if pred name v then [(nameValuePair name v)] else []) (attrNames set));
/**
Filter an attribute set recursively by removing all attributes for
@@ -2136,6 +2137,6 @@ rec {
"lib.zip is a deprecated alias of lib.zipAttrsWith." zipAttrsWith;
# DEPRECATED
cartesianProductOfSets = warnIf (oldestSupportedReleaseIsAtLeast 2405)
cartesianProductOfSets = warnIf (isInOldestRelease 2405)
"lib.cartesianProductOfSets is a deprecated alias of lib.cartesianProduct." cartesianProduct;
}

View File

@@ -73,7 +73,7 @@ let
inherit (self.trivial) id const pipe concat or and xor bitAnd bitOr bitXor
bitNot boolToString mergeAttrs flip mapNullable inNixShell isFloat min max
importJSON importTOML warn warnIf warnIfNot throwIf throwIfNot checkListOfEnum
info showWarnings nixpkgsVersion version isInOldestRelease oldestSupportedReleaseIsAtLeast
info showWarnings nixpkgsVersion version isInOldestRelease
mod compare splitByAndCompare seq deepSeq lessThan add sub
functionArgs setFunctionArgs isFunction toFunction mirrorFunctionArgs
fromHexString toHexString toBaseDigits inPureEvalMode isBool isInt pathExists

View File

@@ -160,9 +160,7 @@ rec {
A fixed-point function returning an attribute set has the form
```nix
final: {
# attributes
}
final: { # attributes }
```
where `final` refers to the lazily evaluated attribute set returned by the fixed-point function.
@@ -170,9 +168,7 @@ rec {
An overlay to such a fixed-point function has the form
```nix
final: prev: {
# attributes
}
final: prev: { # attributes }
```
where `prev` refers to the result of the original function to `final`, and `final` is the result of the composition of the overlay and the original function.
@@ -181,12 +177,8 @@ rec {
```nix
let
f = final: {
# attributes
};
overlay = final: prev: {
# attributes
};
f = final: { # attributes };
overlay = final: prev: { # attributes };
in extends overlay f;
```
@@ -194,12 +186,8 @@ rec {
```nix
let
f = final: {
# attributes
};
overlay = final: prev: {
# attributes
};
f = final: { # attributes };
overlay = final: prev: { # attributes };
g = extends overlay f;
in fix g
```

View File

@@ -213,11 +213,6 @@ lib.mapAttrs mkLicense ({
fullName = "BSD 3-Clause Clear License";
};
bsd3Lbnl = {
spdxId = "BSD-3-Clause-LBNL";
fullName = "Lawrence Berkeley National Labs BSD variant license";
};
bsdOriginal = {
spdxId = "BSD-4-Clause";
fullName = ''BSD 4-clause "Original" or "Old" License'';
@@ -675,7 +670,7 @@ lib.mapAttrs mkLicense ({
# Intel's license, seems free
iasl = {
spdxId = "Intel-ACPI";
fullName = "Intel ACPI Software License Agreement";
fullName = "iASL";
url = "https://old.calculate-linux.org/packages/licenses/iASL";
};
@@ -894,12 +889,7 @@ lib.mapAttrs mkLicense ({
spdxId = "MIT";
fullName = "MIT License";
};
mit-cmu = {
spdxId = "MIT-CMU";
fullName = "CMU License";
};
# https://spdx.org/licenses/MIT-feh.html
mit-feh = {
spdxId = "MIT-feh";
fullName = "feh License";
@@ -952,11 +942,6 @@ lib.mapAttrs mkLicense ({
url = "https://license.coscl.org.cn/MulanPSL2";
};
naist-2003 = {
spdxId = "NAIST-2003";
fullName = "Nara Institute of Science and Technology License (2003)";
};
nasa13 = {
spdxId = "NASA-1.3";
fullName = "NASA Open Source Agreement 1.3";
@@ -1112,7 +1097,7 @@ lib.mapAttrs mkLicense ({
};
purdueBsd = {
fullName = "Purdue BSD-Style License"; # also known as lsof license
fullName = " Purdue BSD-Style License"; # also know as lsof license
url = "https://enterprise.dejacode.com/licenses/public/purdue-bsd";
};
@@ -1222,11 +1207,6 @@ lib.mapAttrs mkLicense ({
fullName = "TCL/TK License";
};
tost = {
fullName = "Tomorrow Open Source Technology License 1.0";
url = "https://github.com/PixarAnimationStudios/OpenUSD/blob/release/LICENSE.txt";
};
ucd = {
fullName = "Unicode Character Database License";
url = "https://fedoraproject.org/wiki/Licensing:UCD";
@@ -1305,15 +1285,6 @@ lib.mapAttrs mkLicense ({
watcom = {
spdxId = "Watcom-1.0";
fullName = "Sybase Open Watcom Public License 1.0";
# Despite being OSIapproved, this licence is not considered FOSS
# by Debian, Fedora, or the FSF, due to an onerous restriction that
# requires publication of even privatelydeployed modifications.
# This violates the FSFs freedom 3 and Debians “desert island
# test” and “dissident test”.
#
# See: <https://en.wikipedia.org/wiki/Sybase_Open_Watcom_Public_License>
free = false;
redistributable = true;
};
w3c = {

View File

@@ -1,2 +1,2 @@
# Expose the minimum required version for evaluating Nixpkgs
"2.3.17"
"2.3"

View File

@@ -23,7 +23,7 @@ let
isAttrs
isBool
isFunction
oldestSupportedReleaseIsAtLeast
isInOldestRelease
isList
isString
length
@@ -354,7 +354,12 @@ let
else if m._type == "if" || m._type == "override" then
loadModule args fallbackFile fallbackKey { config = m; }
else
throw (messages.not_a_module { inherit fallbackFile; value = m; _type = m._type; expectedClass = class; })
throw (
"Could not load a value as a module, because it is of type ${lib.strings.escapeNixString m._type}"
+ optionalString (fallbackFile != unknownModule) ", in file ${toString fallbackFile}."
+ optionalString (m._type == "configuration") " If you do intend to import this configuration, please only import the modules that make up the configuration. You may have to create a `let` binding, file or attribute to give yourself access to the relevant modules.\nWhile loading a configuration into the module system is a very sensible idea, it can not be done cleanly in practice."
# Extended explanation: That's because a finalized configuration is more than just a set of modules. For instance, it has its own `specialArgs` that, by the nature of `specialArgs` can't be loaded through `imports` or the the `modules` argument. So instead, we have to ask you to extract the relevant modules and use those instead. This way, we keep the module system comparatively simple, and hopefully avoid a bad surprise down the line.
)
else if isList m then
let defs = [{ file = fallbackFile; value = m; }]; in
throw "Module imports can't be nested lists. Perhaps you meant to remove one level of lists? Definitions: ${showDefs defs}"
@@ -1030,7 +1035,7 @@ let
mkForce = mkOverride 50;
mkVMOverride = mkOverride 10; # used by nixos-rebuild build-vm
defaultPriority = warnIf (oldestSupportedReleaseIsAtLeast 2305) "lib.modules.defaultPriority is deprecated, please use lib.modules.defaultOverridePriority instead." defaultOverridePriority;
defaultPriority = warnIf (isInOldestRelease 2305) "lib.modules.defaultPriority is deprecated, please use lib.modules.defaultOverridePriority instead." defaultOverridePriority;
mkFixStrictness = warn "lib.mkFixStrictness has no effect and will be removed. It returns its argument unmodified, so you can just remove any calls." id;
@@ -1146,8 +1151,8 @@ let
}: doRename {
inherit from to;
visible = false;
warn = oldestSupportedReleaseIsAtLeast sinceRelease;
use = warnIf (oldestSupportedReleaseIsAtLeast sinceRelease)
warn = isInOldestRelease sinceRelease;
use = warnIf (isInOldestRelease sinceRelease)
"Obsolete option `${showOption from}' is used. It was renamed to `${showOption to}'.";
};
@@ -1445,110 +1450,6 @@ let
collectModules = collectModules null;
};
/**
Error messages produced by the module system.
We factor these out to improve the flow when reading the code.
Functions in `messages` that produce error messages are spelled in
lower_snake_case. This goes against the convention in order to make the
error message implementation more readable, and to visually distinguish
them from other functions in the module system.
*/
messages = let
inherit (lib.strings) concatMapStringsSep escapeNixString trim;
/** "" or ", in file FOO" */
into_fallback_file_maybe = file:
optionalString
(file != null && file != unknownModule)
", while trying to load a module into ${toString file}";
/** Format text with one line break between each list item. */
lines = concatMapStringsSep "\n" trim;
/** Format text with two line break between each list item. */
paragraphs = concatMapStringsSep "\n\n" trim;
/**
```
optionalMatch
{ foo = "Foo result";
bar = "Bar result";
} "foo"
== [ "Foo result" ]
optionalMatch { foo = "Foo"; } "baz" == [ ]
optionalMatch { foo = "Foo"; } true == [ ]
```
*/
optionalMatch = cases: value:
if isString value && cases?${value}
then [ cases.${value} ]
else [];
# esc = builtins.fromJSON "\"\\u001b\"";
esc = builtins.fromJSON "\"\\u001b\"";
# Bold purple for warnings
warn = s: "${esc}[1;35m${s}${esc}[0m";
# Bold green for suggestions
good = s: "${esc}[1;32m${s}${esc}[0m";
# Bold, default color for code
code = s: "${esc}[1m${s}${esc}[0m";
in {
/** When load a value with a (wrong) _type as a module */
not_a_module = { fallbackFile, value, _type, expectedClass ? null }:
paragraphs (
[ ''
Expected a module, but found a value of type ${warn (escapeNixString _type)}${into_fallback_file_maybe fallbackFile}.
A module is typically loaded by adding it the ${code "imports = [ ... ];"} attribute of an existing module, or in the ${code "modules = [ ... ];"} argument of various functions.
Please make sure that each of the list items is a module, and not a different kind of value.
''
]
++ (optionalMatch
{
"configuration" = trim ''
If you really mean to import this configuration, instead please only import the modules that make up the configuration.
You may have to create a `let` binding, file or attribute to give yourself access to the relevant modules.
While loading a configuration into the module system is a very sensible idea, it can not be done cleanly in practice.
'';
# ^^ Extended explanation: That's because a finalized configuration is more than just a set of modules. For instance, it has its own `specialArgs` that, by the nature of `specialArgs` can't be loaded through `imports` or the the `modules` argument. So instead, we have to ask you to extract the relevant modules and use those instead. This way, we keep the module system comparatively simple, and hopefully avoid a bad surprise down the line.
"flake" = lines
([(trim ''
Perhaps you forgot to select an attribute name?
Instead of, for example,
${warn "inputs.someflake"}
you need to write something like
${warn "inputs.someflake"}${
if expectedClass == null
then good ".modules.someApp.default"
else good ".modules.${expectedClass}.default"
}
'')]
++ optionalMatch
{ # We'll no more than 5 custom suggestions here.
# Please switch to `.modules.${class}` in your Module System application.
"nixos" = trim ''
or
${warn "inputs.someflake"}${good ".nixosModules.default"}
'';
"darwin" = trim ''
or
${warn "inputs.someflake"}${good ".darwinModules.default"}
'';
}
expectedClass
);
}
_type
)
);
};
in
private //
{

View File

@@ -256,15 +256,15 @@ let
in {
pathType = lib.warnIf (lib.oldestSupportedReleaseIsAtLeast 2305)
pathType = lib.warnIf (lib.isInOldestRelease 2305)
"lib.sources.pathType has been moved to lib.filesystem.pathType."
lib.filesystem.pathType;
pathIsDirectory = lib.warnIf (lib.oldestSupportedReleaseIsAtLeast 2305)
pathIsDirectory = lib.warnIf (lib.isInOldestRelease 2305)
"lib.sources.pathIsDirectory has been moved to lib.filesystem.pathIsDirectory."
lib.filesystem.pathIsDirectory;
pathIsRegularFile = lib.warnIf (lib.oldestSupportedReleaseIsAtLeast 2305)
pathIsRegularFile = lib.warnIf (lib.isInOldestRelease 2305)
"lib.sources.pathIsRegularFile has been moved to lib.filesystem.pathIsRegularFile."
lib.filesystem.pathIsRegularFile;

View File

@@ -2272,7 +2272,7 @@ rec {
isCoercibleToString :: a -> bool
```
*/
isCoercibleToString = lib.warnIf (lib.oldestSupportedReleaseIsAtLeast 2305)
isCoercibleToString = lib.warnIf (lib.isInOldestRelease 2305)
"lib.strings.isCoercibleToString is deprecated in favor of either isStringLike or isConvertibleWithToString. Only use the latter if it needs to return true for null, numbers, booleans and list of similarly coercibles."
isConvertibleWithToString;

View File

@@ -26,8 +26,6 @@ rec {
cooperlake = [ "sse3" "ssse3" "sse4_1" "sse4_2" "aes" "avx" "avx2" "avx512" "fma" ];
tigerlake = [ "sse3" "ssse3" "sse4_1" "sse4_2" "aes" "avx" "avx2" "avx512" "fma" ];
alderlake = [ "sse3" "ssse3" "sse4_1" "sse4_2" "aes" "avx" "avx2" "fma" ];
sapphirerapids = [ "sse3" "ssse3" "sse4_1" "sse4_2" "aes" "avx" "avx2" "avx512" "fma" ];
emeraldrapids = [ "sse3" "ssse3" "sse4_1" "sse4_2" "aes" "avx" "avx2" "avx512" "fma" ];
# x86_64 AMD
btver1 = [ "sse3" "ssse3" "sse4_1" "sse4_2" ];
btver2 = [ "sse3" "ssse3" "sse4_1" "sse4_2" "aes" "avx" ];
@@ -75,8 +73,6 @@ rec {
cascadelake = [ "cannonlake" ] ++ inferiors.cannonlake;
cooperlake = [ "cascadelake" ] ++ inferiors.cascadelake;
tigerlake = [ "icelake-server" ] ++ inferiors.icelake-server;
sapphirerapids = [ "tigerlake" ] ++ inferiors.tigerlake;
emeraldrapids = [ "sapphirerapids" ] ++ inferiors.sapphirerapids;
# CX16 does not exist on alderlake, while it does on nearly all other intel CPUs
alderlake = [ ];

View File

@@ -277,6 +277,25 @@ let
let
selectEmulator = pkgs:
let
qemu-user = pkgs.qemu.override {
smartcardSupport = false;
spiceSupport = false;
openGLSupport = false;
virglSupport = false;
vncSupport = false;
gtkSupport = false;
sdlSupport = false;
alsaSupport = false;
pulseSupport = false;
pipewireSupport = false;
jackSupport = false;
smbdSupport = false;
seccompSupport = false;
tpmSupport = false;
capstoneSupport = false;
enableDocs = false;
hostCpuTargets = [ "${final.qemuArch}-linux-user" ];
};
wine = (pkgs.winePackagesFor "wine${toString final.parsed.cpu.bits}").minimal;
in
# Note: we guarantee that the return value is either `null` or a path
@@ -287,7 +306,7 @@ let
else if final.isWindows
then "${wine}/bin/wine${optionalString (final.parsed.cpu.bits == 64) "64"}"
else if final.isLinux && pkgs.stdenv.hostPlatform.isLinux && final.qemuArch != null
then "${pkgs.qemu-user}/bin/qemu-${final.qemuArch}"
then "${qemu-user}/bin/qemu-${final.qemuArch}"
else if final.isWasi
then "${pkgs.wasmtime}/bin/wasmtime"
else if final.isMmix
@@ -296,10 +315,6 @@ let
in {
emulatorAvailable = pkgs: (selectEmulator pkgs) != null;
# whether final.emulator pkgs.pkgsStatic works
staticEmulatorAvailable = pkgs: final.emulatorAvailable pkgs
&& (final.isLinux || final.isWasi || final.isMmix);
emulator = pkgs:
if (final.emulatorAvailable pkgs)
then selectEmulator pkgs
@@ -369,17 +384,8 @@ let
}.${cpu.name} or cpu.name;
vendor_ = final.rust.platform.vendor;
# TODO: deprecate args.rustc in favour of args.rust after 23.05 is EOL.
in
args.rust.rustcTarget or
args.rustc.config or (
# Rust uses `wasm32-wasip?` rather than `wasm32-unknown-wasi`.
# We cannot know which subversion does the user want, and
# currently use WASI 0.1 as default for compatibility. Custom
# users can set `rust.rustcTarget` to override it.
if final.isWasi
then "${cpu_}-wasip1"
else "${cpu_}-${vendor_}-${kernel.name}${optionalString (abi.name != "unknown") "-${abi.name}"}"
);
in args.rust.rustcTarget or args.rustc.config
or "${cpu_}-${vendor_}-${kernel.name}${optionalString (abi.name != "unknown") "-${abi.name}"}";
# The name of the rust target if it is standard, or the json file
# containing the custom target spec.

View File

@@ -55,7 +55,7 @@ let
"wasm64-wasi" "wasm32-wasi"
# Windows
"aarch64-windows" "x86_64-windows" "i686-windows"
"x86_64-windows" "i686-windows"
];
allParsed = map parse.mkSystemFromString all;

View File

@@ -256,7 +256,7 @@ rec {
iphone64 = {
config = "aarch64-apple-ios";
# config = "aarch64-apple-darwin14";
darwinSdkVersion = "14.3";
sdkVer = "14.3";
xcodeVer = "12.3";
xcodePlatform = "iPhoneOS";
useiOSPrebuilt = true;
@@ -265,7 +265,7 @@ rec {
iphone32 = {
config = "armv7a-apple-ios";
# config = "arm-apple-darwin10";
darwinSdkVersion = "14.3";
sdkVer = "14.3";
xcodeVer = "12.3";
xcodePlatform = "iPhoneOS";
useiOSPrebuilt = true;
@@ -274,7 +274,7 @@ rec {
iphone64-simulator = {
config = "x86_64-apple-ios";
# config = "x86_64-apple-darwin14";
darwinSdkVersion = "14.3";
sdkVer = "14.3";
xcodeVer = "12.3";
xcodePlatform = "iPhoneSimulator";
darwinPlatform = "ios-simulator";
@@ -284,7 +284,7 @@ rec {
iphone32-simulator = {
config = "i686-apple-ios";
# config = "i386-apple-darwin11";
darwinSdkVersion = "14.3";
sdkVer = "14.3";
xcodeVer = "12.3";
xcodePlatform = "iPhoneSimulator";
darwinPlatform = "ios-simulator";
@@ -325,13 +325,6 @@ rec {
libc = "ucrt"; # This distinguishes the mingw (non posix) toolchain
};
# LLVM-based mingw-w64 for ARM
ucrtAarch64 = {
config = "aarch64-w64-mingw32";
libc = "ucrt";
useLLVM = true;
};
# BSDs
x86_64-freebsd = {

View File

@@ -47,7 +47,6 @@ let
evalModules
extends
filter
filterAttrs
fix
fold
foldAttrs
@@ -1103,25 +1102,6 @@ runTests {
};
};
testFilterAttrs = {
expr = filterAttrs (n: v: n != "a" && (v.hello or false) == true) {
a.hello = true;
b.hello = true;
c = {
hello = true;
world = false;
};
d.hello = false;
};
expected = {
b.hello = true;
c = {
hello = true;
world = false;
};
};
};
# code from example
testFoldlAttrs = {
expr = {

Some files were not shown because too many files have changed in this diff Show More