Compare commits

..

2 Commits

Author SHA1 Message Date
bezmuth
0551dd4086 nixos/pixelfed: init module 2022-12-24 19:47:57 +01:00
bezmuth
d5dbf91a60 pixelfed: init at UNSTABLE-01-09-2022 2022-12-24 19:43:43 +01:00
59502 changed files with 2148204 additions and 4301120 deletions

View File

@@ -1,27 +0,0 @@
{
"name": "nixpkgs",
"image": "mcr.microsoft.com/devcontainers/universal:2-linux",
"features": {
"ghcr.io/devcontainers/features/nix:1": {
// fails in the devcontainer sandbox, enable sandbox via config instead
"multiUser": false,
"packages": "nixd,nixfmt-unstable",
"extraNixConfig": "experimental-features = nix-command flakes,sandbox = true"
}
},
"customizations": {
"vscode": {
"extensions": [
"jnoortheen.nix-ide"
],
"settings": {
"nix.formatterPath": "nixfmt-rfc-style",
"nix.enableLanguageServer": true,
"nix.serverPath": "nixd"
}
}
},
"remoteEnv": {
"NIXPKGS": "/workspaces/nixpkgs"
}
}

View File

@@ -17,14 +17,10 @@ end_of_line = unset
insert_final_newline = unset
trim_trailing_whitespace = unset
# We want readFile .version to return the version without a newline.
[.version]
insert_final_newline = false
# see https://nixos.org/nixpkgs/manual/#chap-conventions
# Match json/lockfiles/markdown/nix/perl/python/ruby/shell/docbook files, set indent to spaces
[*.{bash,json,lock,md,nix,pl,pm,py,rb,sh,xml}]
[*.{json,lock,md,nix,pl,pm,py,rb,sh,xml}]
indent_style = space
# Match docbook files, set indent width of one
@@ -36,7 +32,7 @@ indent_size = 1
indent_size = 2
# Match perl/python/shell scripts, set indent width of four
[*.{bash,pl,pm,py,sh}]
[*.{pl,pm,py,sh}]
indent_size = 4
# Match gemfiles, set indent to spaces with width of two
@@ -44,10 +40,6 @@ indent_size = 4
indent_size = 2
indent_style = space
# Match package.json, which are generally pulled from upstream and accept them as they are
[package.json]
indent_style = unset
# Disable file types or individual files
# some of these files may be auto-generated and/or require significant changes
@@ -63,13 +55,10 @@ trim_trailing_whitespace = unset
[*.lock]
indent_size = unset
# Although Markdown/CommonMark allows using two trailing spaces to denote
# a hard line break, we do not use that feature in nixpkgs since
# it forces the surrounding paragraph to become a <literallayout> which
# does not wrap reasonably.
# Instead of a hard line break, start a new paragraph by inserting a blank line.
# trailing whitespace is an actual syntax element of classic Markdown/
# CommonMark to enforce a line break
[*.md]
trim_trailing_whitespace = true
trim_trailing_whitespace = unset
# binaries
[*.nib]
@@ -98,25 +87,8 @@ insert_final_newline = unset
indent_style = unset
trim_trailing_whitespace = unset
[pkgs/misc/documentation-highlighter/**]
insert_final_newline = unset
[pkgs/servers/dict/wordnet_structures.py]
trim_trailing_whitespace = unset
[pkgs/tools/misc/timidity/timidity.cfg]
trim_trailing_whitespace = unset
[pkgs/tools/virtualization/ovftool/*.ova]
end_of_line = unset
insert_final_newline = unset
trim_trailing_whitespace = unset
charset = unset
[lib/tests/*.plist]
indent_style = tab
insert_final_newline = unset
[pkgs/kde/generated/**]
insert_final_newline = unset
end_of_line = unset

View File

@@ -1,11 +1,5 @@
# This file contains a list of commits that are not likely what you
# are looking for in a blame, such as mass reformatting or renaming.
#
# If a commit's line ends with `# !autorebase <command>`,
# where <command> is an idempotent bash command that reapplies the changes from the commit,
# the `maintainers/scripts/auto-rebase/run.sh` script can be used to rebase
# across that commit while automatically resolving merge conflicts caused by the commit.
#
# You can set this file as a default ignore file for blame by running
# the following command.
#
@@ -45,187 +39,3 @@ d1c1a0c656ccd8bd3b25d3c4287f2d075faf3cf3
# fix indentation in meteor default.nix
a37a6de881ec4c6708e6b88fd16256bbc7f26bbd
# pkgs/stdenv/make-derivation: Reindent
b4cc2a2479a7ab0f6440b2e1319221920ef72699
# treewide: automatically md-convert option descriptions
2e751c0772b9d48ff6923569adfa661b030ab6a2
# nixos/*: automatically convert option docs
087472b1e5230ffc8ba642b1e4f9218adf4634a2
# nixos/*: automatically convert option descriptions
ef176dcf7e76c3639571d7c6051246c8fbadf12a
# nixos/*: automatically convert option docs to MD
61e93df1891972bae3e0c97a477bd44e8a477aa0
# nixos/*: convert options with admonitions to MD
722b99bc0eb57711c0498a86a3f55e6c69cdb05f
# nixos/*: automatically convert option docs
6039648c50c7c0858b5e506c6298773a98e0f066
# nixos/*: md-convert options with unordered lists
c915b915b5e466a0b0b2af2906cd4d2380b8a1de
# nixos/*: convert options with listings
f2ea09ecbe1fa1da32eaa6e036d64ac324a2986f
# nixos/*: convert straggler options to MD
1d41cff3dc4c8f37bb5841f51fcbff705e169178
# nixos/*: normalize manpage references to single-line form
423545fe4865d126e86721ba30da116e29c65004
# nixos/documentation: split options doc build
fc614c37c653637e5475a0b0a987489b4d1f351d
# nixos/*: convert options with admonitions to MD
722b99bc0eb57711c0498a86a3f55e6c69cdb05f
# nixos/*: convert internal option descriptions to MD
9547123258f69efd92b54763051d6dc7f3bfcaca
# nixos/*: replace </para><para> with double linebreaks
694d5b19d30bf66687b42fb77f43ea7cd1002a62
# treewide: add defaultText for options with simple interpolation defaults
fb0e5be84331188a69b3edd31679ca6576edb75a
# nixos/*: mark pre-existing markdown descriptions as mdDoc
7e7d68a250f75678451cd44f8c3d585bf750461e
# nixos/*: normalize link format
3aebb4a2be8821a6d8a695f0908d8567dc00de31
# nixos/*: replace <code> in option docs with <literal>
16102dce2fbad670bd47dd75c860a8daa5fe47ad
# nixos/*: add trivial defaultText for options with simple defaults
25124556397ba17bfd70297000270de1e6523b0a
# systemd: rewrite comments
92dfeb7b3dab820ae307c56c216d175c69ee93cd
# systemd: break too long lines of Nix code
67643f8ec84bef1482204709073e417c9f07eb87
# {pkgs/development/cuda-modules,pkgs/test/cuda,pkgs/top-level/cuda-packages.nix}: reformat all CUDA files with nixfmt-rfc-style 2023-03-01
802a1b4d3338f24cbc4efd704616654456d75a94
# postgresql: move packages.nix to ext/default.nix
719034f6f6749d624faa28dff259309fc0e3e730
# php ecosystem: reformat with nixfmt-rfc-style
75ae7621330ff8db944ce4dff4374e182d5d151f
c759efa5e7f825913f9a69ef20f025f50f56dc4d
# pkgs/os-specific/bsd: Reformat with nixfmt-rfc-style 2024-03-01
3fe3b055adfc020e6a923c466b6bcd978a13069a
# k3s: format with nixfmt-rfc-style
6cfcd3c75428ede517bc6b15a353d704837a2830
# python3Packages: format with nixfmt
59b1aef59071cae6e87859dc65de973d2cc595c0
# treewide description changes (#317959)
bf995e3641950f4183c1dd9010349263dfa0123b
755b915a158c9d588f08e9b08da9f7f3422070cc
f8c4a98e8e138e21353a2c33b90db3359f539b37
# vscode-extensions.*: format with nixfmt (RFC 166)
7bf9febfa6271012b1ef86647a3a06f06875fdcf
# remove uses of mdDoc (#303841)
1a24330f792c8625746d07d842290e6fd95ae6f9
acd0e3898feb321cb9a71a0fd376f1157d0f4553
1b28414d2886c57343864326dbb745a634d3e37d
6afb255d976f85f3359e4929abd6f5149c323a02
# azure-cli: move to by-name, nixfmt #325950
96cd538b68bd1d0a0a37979356d669abbba32ebc
# poptracker: format with nixfmt-rfc-style (#326697)
ff5c8f6cc3d1f2e017e86d50965c14b71f00567b
# mangal: format with nixfmt-rfc-style #328284
3bb5e993cac3a6e1c3056d2bc9bf43eb2c7a5951
# pico-sdk: switch to finalAttrs (#329438)
8946018b0391ae594d167f1e58497b18de068968
# ollama: format with nixfmt-rfc-style (#329353)
bdfde18037f8d9f9b641a4016c8ada4dc4cbf856
# nixos/ollama: format with nixfmt-rfc-style (#329561)
246d1ee533810ac1946d863bbd9de9b525818d56
# steam: cleanup (#216972)
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
# nrr: format with nixfmt-rfc-style (#334578)
cffc27daf06c77c0d76bc35d24b929cb9d68c3c9
# nixos/kanidm: inherit lib, nixfmt
8f18393d380079904d072007fb19dc64baef0a3a
# 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
# ant: format with nixfmt-rfc-style
2538d58436b8d0b56d29780aeebf4bf720ddb9ea
# treewide: migrate packages to pkgs/by-name, take 1
571c71e6f73af34a229414f51585738894211408
# format files with nixfmt (#347275)
adb9714bd909df283c66bbd641bd631ff50a4260
# treewide: incus packages
9ab59bb5fb943ad6740f64f5a79eae9642fb8211
# treewide nixfmt reformat pass 1, master, staging and staging-next
4f0dadbf38ee4cf4cc38cbc232b7708fddf965bc
667d42c00d566e091e6b9a19b365099315d0e611
84d4f874c2bac9f3118cb6907d7113b3318dcb5e
# tmuxPlugins sha-to-sri.py script
516b1e74c358a9c4b06e5591f8c1a2897aad0c33

3
.gitattributes vendored
View File

@@ -1,6 +1,5 @@
**/deps.nix linguist-generated
**/deps.json linguist-generated
**/deps.toml linguist-generated
**/node-packages.nix linguist-generated
pkgs/applications/editors/emacs-modes/*-generated.nix linguist-generated
@@ -16,5 +15,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

306
.github/CODEOWNERS vendored Normal file
View File

@@ -0,0 +1,306 @@
# 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.
# This file
/.github/CODEOWNERS @edolstra
# GitHub actions
/.github/workflows @NixOS/Security @Mic92 @zowoq
/.github/workflows/merge-staging @FRidh
# EditorConfig
/.editorconfig @Mic92 @zowoq
# Libraries
/lib @edolstra @nbp @infinisil
/lib/systems @alyssais @nbp @ericson2314 @matthewbauer
/lib/generators.nix @edolstra @nbp @Profpatsch
/lib/cli.nix @edolstra @nbp @Profpatsch
/lib/debug.nix @edolstra @nbp @Profpatsch
/lib/asserts.nix @edolstra @nbp @Profpatsch
# Nixpkgs Internals
/default.nix @nbp
/pkgs/top-level/default.nix @nbp @Ericson2314
/pkgs/top-level/impure.nix @nbp @Ericson2314
/pkgs/top-level/stage.nix @nbp @Ericson2314 @matthewbauer
/pkgs/top-level/splice.nix @Ericson2314 @matthewbauer
/pkgs/top-level/release-cross.nix @Ericson2314 @matthewbauer
/pkgs/stdenv/generic @Ericson2314 @matthewbauer
/pkgs/stdenv/generic/check-meta.nix @Ericson2314 @matthewbauer @piegamesde
/pkgs/stdenv/cross @Ericson2314 @matthewbauer
/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
# Nixpkgs build-support
/pkgs/build-support/writers @lassulus @Profpatsch
# Nixpkgs documentation
/maintainers/scripts/db-to-md.sh @jtojnar @ryantm
/maintainers/scripts/doc @jtojnar @ryantm
/doc/* @fricklerhandwerk
/doc/build-aux/pandoc-filters @jtojnar
/doc/builders/trivial-builders.chapter.md @fricklerhandwerk
/doc/contributing/ @fricklerhandwerk
/doc/contributing/contributing-to-documentation.chapter.md @jtojnar @fricklerhandwerk
/doc/stdenv @fricklerhandwerk
/doc/using @fricklerhandwerk
# NixOS Internals
/nixos/default.nix @nbp @infinisil
/nixos/lib/from-env.nix @nbp @infinisil
/nixos/lib/eval-config.nix @nbp @infinisil
/nixos/doc/manual/configuration/abstractions.xml @nbp
/nixos/doc/manual/configuration/config-file.xml @nbp
/nixos/doc/manual/configuration/config-syntax.xml @nbp
/nixos/doc/manual/configuration/modularity.xml @nbp
/nixos/doc/manual/development/assertions.xml @nbp
/nixos/doc/manual/development/meta-attributes.xml @nbp
/nixos/doc/manual/development/option-declarations.xml @nbp
/nixos/doc/manual/development/option-def.xml @nbp
/nixos/doc/manual/development/option-types.xml @nbp
/nixos/doc/manual/development/replace-modules.xml @nbp
/nixos/doc/manual/development/writing-modules.xml @nbp
/nixos/doc/manual/man-nixos-option.xml @nbp
/nixos/modules/installer/tools/nixos-option.sh @nbp
/nixos/modules/system @dasJ
/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
# 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
# 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
/maintainers/scripts/update-python-libraries @FRidh
/pkgs/top-level/python-packages.nix @FRidh @jonringer
/pkgs/development/interpreters/python @FRidh
/pkgs/development/python-modules @FRidh @jonringer
/doc/languages-frameworks/python.section.md @FRidh
/pkgs/development/tools/poetry2nix @adisbladis
/pkgs/development/interpreters/python/hooks @FRidh @jonringer
# Haskell
/doc/languages-frameworks/haskell.section.md @cdepillabout @sternenseemann @maralorn
/maintainers/scripts/haskell @cdepillabout @sternenseemann @maralorn
/pkgs/development/compilers/ghc @cdepillabout @sternenseemann @maralorn
/pkgs/development/haskell-modules @cdepillabout @sternenseemann @maralorn
/pkgs/test/haskell @cdepillabout @sternenseemann @maralorn
/pkgs/top-level/release-haskell.nix @cdepillabout @sternenseemann @maralorn
/pkgs/top-level/haskell-packages.nix @cdepillabout @sternenseemann @maralorn
# Perl
/pkgs/development/interpreters/perl @stigtsp @zakame @dasJ
/pkgs/top-level/perl-packages.nix @stigtsp @zakame @dasJ
/pkgs/development/perl-modules @stigtsp @zakame @dasJ
# R
/pkgs/applications/science/math/R @jbedo
/pkgs/development/r-modules @jbedo
# Ruby
/pkgs/development/interpreters/ruby @marsam
/pkgs/development/ruby-modules @marsam
# Rust
/pkgs/development/compilers/rust @Mic92 @LnL7 @zowoq
# C compilers
/pkgs/development/compilers/gcc @matthewbauer
/pkgs/development/compilers/llvm @matthewbauer
# Compatibility stuff
/pkgs/top-level/unix-tools.nix @matthewbauer
/pkgs/development/tools/xcbuild @matthewbauer
# 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
# 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 / KDE
/pkgs/applications/kde @ttuegel
/pkgs/desktops/plasma-5 @ttuegel
/pkgs/development/libraries/kde-frameworks @ttuegel
/pkgs/development/libraries/qt-5 @ttuegel
# PostgreSQL and related stuff
/pkgs/servers/sql/postgresql @thoughtpolice @marsam
/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
# Dhall
/pkgs/development/dhall-modules @Gabriella439 @Profpatsch @ehmry
/pkgs/development/interpreters/dhall @Gabriella439 @Profpatsch @ehmry
# Idris
/pkgs/development/idris-modules @Infinisil
# 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
# Neovim
/pkgs/applications/editors/neovim @figsoda @jonringer @teto
# VimPlugins
/pkgs/applications/editors/vim/plugins @figsoda @jonringer
# VsCode Extensions
/pkgs/applications/editors/vscode/extensions @jonringer
# Prometheus exporter modules and tests
/nixos/modules/services/monitoring/prometheus/exporters.nix @WilliButz
/nixos/modules/services/monitoring/prometheus/exporters.xml @WilliButz
/nixos/tests/prometheus-exporters.nix @WilliButz
# PHP interpreter, packages, extensions, tests and documentation
/doc/languages-frameworks/php.section.md @aanderse @etu @globin @ma27 @talyz
/nixos/tests/php @aanderse @etu @globin @ma27 @talyz
/pkgs/build-support/build-pecl.nix @aanderse @etu @globin @ma27 @talyz
/pkgs/development/interpreters/php @jtojnar @aanderse @etu @globin @ma27 @talyz
/pkgs/development/php-packages @aanderse @etu @globin @ma27 @talyz
/pkgs/top-level/php-packages.nix @jtojnar @aanderse @etu @globin @ma27 @talyz
# Podman, CRI-O modules and related
/nixos/modules/virtualisation/containers.nix @zowoq @adisbladis
/nixos/modules/virtualisation/cri-o.nix @zowoq @adisbladis
/nixos/modules/virtualisation/podman @zowoq @adisbladis
/nixos/tests/cri-o.nix @zowoq @adisbladis
/nixos/tests/podman @zowoq @adisbladis
# Docker tools
/pkgs/build-support/docker @roberth
/nixos/tests/docker-tools* @roberth
/doc/builders/images/dockertools.section.md @roberth
# Blockchains
/pkgs/applications/blockchains @mmahut @RaghavSood
# Go
/doc/languages-frameworks/go.section.md @kalbasit @Mic92 @zowoq
/pkgs/build-support/go @kalbasit @Mic92 @zowoq
/pkgs/development/compilers/go @kalbasit @Mic92 @zowoq
# GNOME
/pkgs/desktops/gnome @jtojnar
/pkgs/desktops/gnome/extensions @piegamesde @jtojnar
/pkgs/build-support/make-hardcode-gsettings-patch @jtojnar
# Cinnamon
/pkgs/desktops/cinnamon @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
# kubernetes
/nixos/doc/manual/configuration/kubernetes.chapter.md @zowoq
/nixos/modules/services/cluster/kubernetes @zowoq
/nixos/tests/kubernetes @zowoq
/pkgs/applications/networking/cluster/kubernetes @zowoq
# Matrix
/pkgs/servers/heisenbridge @piegamesde
/pkgs/servers/matrix-conduit @piegamesde
/nixos/modules/services/misc/heisenbridge.nix @piegamesde
/nixos/modules/services/misc/matrix-conduit.nix @piegamesde
/nixos/tests/matrix-conduit.nix @piegamesde
# Dotnet
/pkgs/build-support/dotnet @IvarWithoutBones
/pkgs/development/compilers/dotnet @IvarWithoutBones
# 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

View File

@@ -1,6 +1,11 @@
<!--
Please note: This blank issue template is meant for extraordinary issues
that do not fit the templates. Unless you know your issue is relevant to
Nixpkgs and requires the free-form blank issue, please use the issue
templates instead.
-->
## Issue description
### Steps to reproduce
## Technical details
Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.

View File

@@ -1,142 +0,0 @@
name: "Bug report (package)"
description: "Create a generic bug report against a package."
title: "PACKAGENAME: BUG TITLE"
labels: ["0.kind: bug"]
body:
- type: "markdown"
attributes:
value: |
<p align="center">
<a href="https://nixos.org">
<picture>
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png">
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png" width="400px" alt="NixOS logo">
</picture>
</a>
</p>
Welcome to Nixpkgs. Please replace the **`PACKAGENAME: BUG TITLE`** template above with the correct package name (As seen in the [NixOS Package Search](https://search.nixos.org/packages)) and a short title summarising what the bug entails.
> [!TIP]
> For instance, if you were filing a bug against the [`hello`](https://search.nixos.org/packages?channel=unstable&from=0&size=1&buckets=%7B%22package_attr_set%22%3A%5B%22No%20package%20set%22%5D%2C%22package_license_set%22%3A%5B%22GNU%20General%20Public%20License%20v3.0%20or%20later%22%5D%2C%22package_maintainers_set%22%3A%5B%5D%2C%22package_platforms%22%3A%5B%5D%7D&sort=relevance&type=packages&query=hello) package about it failing to launch on ARM Linux, your title would be as follows:
> `hello: fails to launch on aarch64-linux`
---
- type: "dropdown"
id: "version"
attributes:
label: "Nixpkgs version"
description: |
What version of Nixpkgs are you using?
> [!IMPORTANT]
> If you are using an older version, please update to the latest stable version and check if the issue persists before continuing this bug report.
options:
- "Please select a version."
- "- Unstable (25.05)"
- "- Stable (24.11)"
- "- Previous Stable (24.05)"
default: 0
validations:
required: true
- type: "textarea"
id: "description"
attributes:
label: "Describe the bug"
description: "Please include a clear and concise description of what the issue is."
validations:
required: true
- type: "textarea"
id: "how-to-reproduce"
attributes:
label: "Steps to reproduce"
description: "Please include a step-by-step guide for reproducing this issue. Consider writing in concise, numbered bullet points to ensure that Nixpkgs developers can retrace your steps."
validations:
required: true
- type: "input"
id: "expected-behaviour"
attributes:
label: "Expected behaviour"
description: "Please write a concise description of what was supposed to happen."
validations:
required: true
- type: "textarea"
id: "screenshots"
attributes:
label: "Screenshots"
description: |
If applicable, add screenshots to help explain your problem.
If you need help uploading images to GitHub, please review the [relevant documentation](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#uploading-assets).
validations:
required: false
- type: "textarea"
id: "logs"
attributes:
label: "Relevant log output"
description: |
If applicable, copy and paste any relevant log output.
This will be automatically formatted into code, so no need for backticks.
render: "console"
validations:
required: false
- type: "textarea"
id: "additional-context"
attributes:
label: "Additional context"
description: "Add any other context about the problem here."
validations:
required: false
- type: "textarea"
id: "metadata"
attributes:
label: "System metadata"
description: "Please run `nix-shell -p nix-info --run \"nix-info -m\"` on a terminal and paste the output of that command here."
validations:
required: true
- type: "textarea"
id: "maintainers"
attributes:
label: "Notify maintainers"
description: |
Please mention the people who are in the **Maintainers** list of the offending package. This is done by by searching for the package on the [NixOS Package Search](https://search.nixos.org/packages) and mentioning the people listed under **Maintainers** by prefixing their GitHub usernames with an '@' character. Please add the mentions above the `---` characters in the template below.
value: |
---
**Note for maintainers:** Please tag this issue in your pull request description. (i.e. `Resolves #ISSUE`.)
validations:
required: false
- type: "checkboxes"
id: "sanity-check"
attributes:
label: "I assert that this issue is relevant for Nixpkgs"
description: |
This bug tracker is for actionable issues that are not the result of user error. If you need help using your system and are unsure if this is a bug with Nixpkgs, please consider asking for help on the [NixOS Discourse](https://discourse.nixos.org/) or the [NixOS Matrix Space](https://matrix.to/#/#community:nixos.org) before opening an issue.
options:
- label: "I assert that this is a bug and not a support request."
required: true
- label: "I assert that this is not a [duplicate of an existing issue](https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aissue+label%3A%220.kind%3A+bug%22+-label%3A%226.topic%3A+darwin%22+-label%3A%226.topic%3A+nixos%22). "
required: true
- label: "I assert that I have read the [NixOS Code of Conduct](https://github.com/NixOS/.github/blob/master/CODE_OF_CONDUCT.md) and agree to abide by it."
required: true
- type: "markdown"
attributes:
value: |
# Thank you for helping improve Nixpkgs!
---
- type: "textarea"
id: "prioritisation"
attributes:
label: "Is this issue important to you?"
description: |
**Please do not modify this text area!**
This template helps Nixpkgs developers know which issues should be prioritised by allowing users to vote with a :+1: reaction.
This is not a guarantee that highly-requested issues will be fixed first, but it helps us to figure out what's important to users. Please react on other users' issues if you find them important.
value: |
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

@@ -1,156 +0,0 @@
name: "Bug report (macOS)"
description: "Create a bug report against a package where the issue only occurs on macOS."
title: "PACKAGENAME: BUG TITLE"
labels: ["0.kind: bug", "6.topic: darwin"]
body:
- type: "markdown"
attributes:
value: |
<p align="center">
<a href="https://nixos.org">
<picture>
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png">
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png" width="400px" alt="NixOS logo">
</picture>
</a>
</p>
Welcome to Nixpkgs. Please replace the **`PACKAGENAME: BUG TITLE`** template above with the correct package name (As seen in the [NixOS Package Search](https://search.nixos.org/packages)) and a short title summarising what the bug entails.
> [!TIP]
> For instance, if you were filing a bug against the [`hello`](https://search.nixos.org/packages?channel=unstable&from=0&size=1&buckets=%7B%22package_attr_set%22%3A%5B%22No%20package%20set%22%5D%2C%22package_license_set%22%3A%5B%22GNU%20General%20Public%20License%20v3.0%20or%20later%22%5D%2C%22package_maintainers_set%22%3A%5B%5D%2C%22package_platforms%22%3A%5B%5D%7D&sort=relevance&type=packages&query=hello) package about it failing to launch on Apple Silicon, your title would be as follows:
> `hello: fails to launch on aarch64-darwin`
---
- type: "dropdown"
id: "version"
attributes:
label: "Nixpkgs version"
description: |
What version of Nixpkgs are you using?
> [!IMPORTANT]
> If you are using an older version, please update to the latest stable version and check if the issue persists before continuing this bug report.
options:
- "Please select a version."
- "- Unstable (25.05)"
- "- Stable (24.11)"
- "- Previous Stable (24.05)"
default: 0
validations:
required: true
- type: "textarea"
id: "description"
attributes:
label: "Describe the bug"
description: "Please include a clear and concise description of what the issue is."
validations:
required: true
- type: "textarea"
id: "how-to-reproduce"
attributes:
label: "Steps to reproduce"
description: "Please include a step-by-step guide for reproducing this issue. Consider writing in concise, numbered bullet points to ensure that Nixpkgs developers can retrace your steps."
validations:
required: true
- type: "input"
id: "expected-behaviour"
attributes:
label: "Expected behaviour"
description: "Please write a concise description of what was supposed to happen."
validations:
required: true
- type: "textarea"
id: "screenshots"
attributes:
label: "Screenshots"
description: |
If applicable, add screenshots to help explain your problem.
If you need help uploading images to GitHub, please review the [relevant documentation](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#uploading-assets).
validations:
required: false
- type: "textarea"
id: "logs"
attributes:
label: "Relevant log output"
description: |
If applicable, copy and paste any relevant log output.
This will be automatically formatted into code, so no need for backticks.
render: "console"
validations:
required: false
- type: "textarea"
id: "additional-context"
attributes:
label: "Additional context"
description: "Add any other context about the problem here."
validations:
required: false
- type: "textarea"
id: "metadata"
attributes:
label: "System metadata"
description: "Please run `nix-shell -p nix-info --run \"nix-info -m\"` on a terminal and paste the output of that command here."
validations:
required: true
- type: "dropdown"
id: "nix-darwin"
attributes:
label: "Are you using nix-darwin?"
description: |
[`nix-darwin`](https://github.com/LnL7/nix-darwin) is a set of NixOS-like modules for macOS systems. Depending on your issue, this information may be relevant.
options:
- "Yes, I am using nix-darwin."
- "No, I am not using nix-darwin."
default: 1
validations:
required: true
- type: "textarea"
id: "maintainers"
attributes:
label: "Notify maintainers"
description: |
Please mention the people who are in the **Maintainers** list of the offending package. This is done by by searching for the package on the [NixOS Package Search](https://search.nixos.org/packages) and mentioning the people listed under **Maintainers** by prefixing their GitHub usernames with an '@' character. Please add the mentions above the `---` characters in the template below.
If this issue is related to the Darwin packaging architecture as a whole, or is related to the core Darwin frameworks, consider mentioning the `@NixOS/darwin-core` team.
value: |
---
**Note for maintainers:** Please tag this issue in your pull request description. (i.e. `Resolves #ISSUE`.)
validations:
required: false
- type: "checkboxes"
id: "sanity-check"
attributes:
label: "I assert that this issue is relevant for Nixpkgs"
description: |
This bug tracker is for actionable issues that are not the result of user error. If you need help using your system and are unsure if this is a bug with Nixpkgs/NixOS, please consider asking for help on the [NixOS Discourse](https://discourse.nixos.org/) or the [NixOS Matrix Space](https://matrix.to/#/#community:nixos.org) before opening an issue.
options:
- label: "I assert that this is a bug and not a support request."
required: true
- label: "I assert that this is not a [duplicate of an existing issue](https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aissue+label%3A%220.kind%3A+bug%22+label%3A%226.topic%3A+darwin%22). "
required: true
- label: "I assert that I have read the [NixOS Code of Conduct](https://github.com/NixOS/.github/blob/master/CODE_OF_CONDUCT.md) and agree to abide by it."
required: true
- type: "markdown"
attributes:
value: |
# Thank you for helping improve Nixpkgs!
---
- type: "textarea"
id: "prioritisation"
attributes:
label: "Is this issue important to you?"
description: |
**Please do not modify this text area!**
This template helps Nixpkgs developers know which issues should be prioritised by allowing users to vote with a :+1: reaction.
This is not a guarantee that highly-requested issues will be fixed first, but it helps us to figure out what's important to users. Please react on other users' issues if you find them important.
value: |
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

@@ -1,146 +0,0 @@
name: "Bug report (NixOS module)"
description: "Create a bug report against a NixOS Module."
title: "nixos/MODULENAME: BUG TITLE"
labels: ["0.kind: bug", "6.topic: nixos"]
body:
- type: "markdown"
attributes:
value: |
<p align="center">
<a href="https://nixos.org">
<picture>
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png">
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png" width="400px" alt="NixOS logo">
</picture>
</a>
</p>
Welcome to Nixpkgs. Please replace the **`nixos/MODULENAME: BUG TITLE`** template above with the correct module name (As seen in the [NixOS Option Search](https://search.nixos.org/options)) and a short title summarising what the bug entails.
> [!TIP]
> For instance, if you were filing a bug against the [`systemd-boot`](https://search.nixos.org/options?channel=unstable&show=boot.loader.systemd-boot.enable&from=0&size=1) module about it failing to install [`memtest86`](https://search.nixos.org/options?channel=unstable&show=boot.loader.systemd-boot.memtest86.enable&from=0&size=1), your title would be as follows:
> `nixos/systemd-boot: fails to install memtest86`
---
- type: "dropdown"
id: "version"
attributes:
label: "Nixpkgs version"
description: |
What version of Nixpkgs are you using?
> [!IMPORTANT]
> If you are using an older version, please [update to the latest stable version](https://nixos.org/download) and check if the issue persists before continuing this bug report.
options:
- "Please select a version."
- "- Unstable (25.05)"
- "- Stable (24.11)"
- "- Previous Stable (24.05)"
default: 0
validations:
required: true
- type: "textarea"
id: "description"
attributes:
label: "Describe the bug"
description: "Please include a clear and concise description of what the issue is."
validations:
required: true
- type: "textarea"
id: "how-to-reproduce"
attributes:
label: "Steps to reproduce"
description: "Please include a step-by-step guide for reproducing this issue. Consider writing in concise, numbered bullet points to ensure that Nixpkgs developers can retrace your steps."
validations:
required: true
- type: "input"
id: "expected-behaviour"
attributes:
label: "Expected behaviour"
description: "Please write a concise description of what was supposed to happen."
validations:
required: true
- type: "textarea"
id: "screenshots"
attributes:
label: "Screenshots"
description: |
If applicable, add screenshots to help explain your problem.
If you need help uploading images to GitHub, please review the [relevant documentation](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#uploading-assets).
validations:
required: false
- type: "textarea"
id: "logs"
attributes:
label: "Relevant log output"
description: |
If applicable, copy and paste any relevant log output.
This will be automatically formatted into code, so no need for backticks.
render: "console"
validations:
required: false
- type: "textarea"
id: "additional-context"
attributes:
label: "Additional context"
description: "Add any other context about the problem here."
validations:
required: false
- type: "textarea"
id: "metadata"
attributes:
label: "System metadata"
description: "Please run `nix-shell -p nix-info --run \"nix-info -m\"` on a terminal and paste the output of that command here."
validations:
required: true
- type: "textarea"
id: "maintainers"
attributes:
label: "Notify maintainers"
description: |
Please mention the people who are in the `meta.maintainers` list of the offending module. This is done by prefixing the person's username with an '@' character. You can quickly go to the source code of a module by searching for it on the [NixOS Option Search](https://search.nixos.org/options) and clicking the "Declared in..." button.
Please note that the maintainer attribute name does not always match the maintainer's GitHub username. If that occurs, try looking in [`maintainers/maintainer-list.nix`](https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix) for the maintainer attribute name, and checking if the maintainer has a listed GitHub username.
If in doubt, check `git blame` for whoever last touched the module, or check the associated package's maintainers. Please add the mentions above the `---` characters.
value: |
---
**Note for maintainers:** Please tag this issue in your pull request description. (i.e. `Resolves #ISSUE`.)
validations:
required: false
- type: "checkboxes"
id: "sanity-check"
attributes:
label: "I assert that this issue is relevant for Nixpkgs"
description: |
This bug tracker is for actionable issues that are not the result of user error. If you need help using your system and are unsure if this is a bug with Nixpkgs, please consider asking for help on the [NixOS Discourse](https://discourse.nixos.org/) or the [NixOS Matrix Space](https://matrix.to/#/#community:nixos.org) before opening an issue.
options:
- label: "I assert that this is a bug and not a support request."
required: true
- label: "I assert that this is not a [duplicate of an existing issue](https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aissue+label%3A%220.kind%3A+bug%22+label%3A%226.topic%3A+nixos%22). "
required: true
- label: "I assert that I have read the [NixOS Code of Conduct](https://github.com/NixOS/.github/blob/master/CODE_OF_CONDUCT.md) and agree to abide by it."
required: true
- type: "markdown"
attributes:
value: |
# Thank you for helping improve Nixpkgs!
---
- type: "textarea"
id: "prioritisation"
attributes:
label: "Is this issue important to you?"
description: |
**Please do not modify this text area!**
This template helps Nixpkgs developers know which issues should be prioritised by allowing users to vote with a :+1: reaction.
This is not a guarantee that highly-requested issues will be fixed first, but it helps us to figure out what's important to users. Please react on other users' issues if you find them important.
value: |
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

@@ -1,149 +0,0 @@
name: "Build failure"
description: "Report a package that is failing to build."
title: "Build failure: PACKAGENAME"
labels: ["0.kind: build failure"]
body:
- type: "markdown"
attributes:
value: |
<p align="center">
<a href="https://nixos.org">
<picture>
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png">
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png" width="400px" alt="NixOS logo">
</picture>
</a>
</p>
Welcome to Nixpkgs. Please replace the **`Build failure: PACKAGENAME`** template above with the correct package name (As seen in the [NixOS Package Search](https://search.nixos.org/packages)).
> [!TIP]
> For instance, if you were filing a build failure against the [`hello`](https://search.nixos.org/packages?channel=unstable&from=0&size=1&buckets=%7B%22package_attr_set%22%3A%5B%22No%20package%20set%22%5D%2C%22package_license_set%22%3A%5B%22GNU%20General%20Public%20License%20v3.0%20or%20later%22%5D%2C%22package_maintainers_set%22%3A%5B%5D%2C%22package_platforms%22%3A%5B%5D%7D&sort=relevance&type=packages&query=hello) package, your title would be as follows:
> `Build failure: hello`
---
- type: "dropdown"
id: "version"
attributes:
label: "Nixpkgs version"
description: |
In what version of Nixpkgs did the build failure occur?
> [!IMPORTANT]
> If you are using an older version, please update to the latest stable version and check if the build failure persists before continuing this report.
> If you are purposefully trying to build an ancient version of a package in an older Nixpkgs, please coordinate with the [NixOS Archivists](https://matrix.to/#/#archivists:nixos.org).
options:
- "Please select a version."
- "- Unstable (25.05)"
- "- Stable (24.11)"
- "- Previous Stable (24.05)"
default: 0
validations:
required: true
- type: "textarea"
id: "how-to-reproduce"
attributes:
label: "Steps to reproduce"
description: "Please include a step-by-step guide for reproducing this build failure. Consider writing in concise, numbered bullet points to ensure that Nixpkgs developers can retrace your steps."
validations:
required: true
- type: "dropdown"
id: "hydra"
attributes:
label: "Can Hydra reproduce this build failure?"
description: |
Can [Hydra](https://hydra.nixos.org), Nixpkgs' Continuous Integration system, reproduce this build failure?
Please use the search function in the header bar to locate the last build job for the package in question.
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/src/root/static/images/emojione-red-x-274c.svg" width="20px" align="top" alt="Red X"> icon near the package entry, say '**Yes, Hydra can reproduce this build failure.**'
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/src/root/static/images/emojione-gray-x-2716.svg" width="20px" align="top" alt="Dark Gray X"> icon near the package entry, then the build failure occurs with another package, and you need to track the original failing package by going down the chain of 'Cached failures' until you reach the final package in the failing dependency chain. Once you locate the failing package, re-write this report against that package and say '**Yes, Hydra can reproduce this build failure.**'
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/src/root/static/images/emojione-check-2714.svg" width="20px" align="top" alt="Green Check Mark"> icon near the package entry, then it most likely means it's a local issue with your system. (Maybe you ran out of space?)
You can still open a build failure report, but please say '**No, Hydra cannot reproduce this build failure.**' below.
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/src/root/static/images/emojione-question-2754.svg" width="20px" align="top" alt="Gray Question Mark"> icon near the package entry, say '**Hydra is currently rebuilding this package.**'
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/src/root/static/images/emojione-stopsign-1f6d1.svg" width="20px" align="top" alt="Red Stop Sign"> icon near the package entry, then the build job was stopped manually. If this occurs, please coordinate with the [Infrastructure Team](https://matrix.to/#/#infra:nixos.org), and say '**The last build job was manually cancelled.**'
options:
- "Please select the Hydra Status."
- "Yes, Hydra can reproduce this build failure."
- "No, Hydra cannot reproduce this build failure."
- "Hydra is currently rebuilding this package."
- "The last build job was manually cancelled."
default: 0
validations:
required: true
- type: "input"
id: "hydra-logs"
attributes:
label: "Link to Hydra build job"
description: "If you answered 'yes' in the question above, please copy-and-paste the link to the failing Hydra job here."
validations:
required: false
- type: "textarea"
id: "logs"
attributes:
label: "Relevant log output"
description: |
Please copy and paste the logs from the failed build.
This will be automatically formatted into code, so no need for backticks.
render: "console"
validations:
required: true
- type: "textarea"
id: "additional-context"
attributes:
label: "Additional context"
description: "Add any other context about the problem here."
validations:
required: false
- type: "textarea"
id: "metadata"
attributes:
label: "System metadata"
description: "Please run `nix-shell -p nix-info --run \"nix-info -m\"` on a terminal and paste the output of that command here."
validations:
required: true
- type: "textarea"
id: "maintainers"
attributes:
label: "Notify maintainers"
description: |
Please mention the people who are in the **Maintainers** list of the offending package. This is done by by searching for the package on the [NixOS Package Search](https://search.nixos.org/packages) and mentioning the people listed under **Maintainers** by prefixing their GitHub usernames with an '@' character. Please add the mentions above the `---` characters in the template below.
value: |
---
**Note for maintainers:** Please tag this issue in your pull request description. (i.e. `Resolves #ISSUE`.)
validations:
required: false
- type: "checkboxes"
id: "sanity-check"
attributes:
label: "I assert that this issue is relevant for Nixpkgs"
description: |
This bug tracker is for actionable issues that are not the result of user error. If you need help using your system and are unsure if this is a bug with Nixpkgs, please consider asking for help on the [NixOS Discourse](https://discourse.nixos.org/) or the [NixOS Matrix Space](https://matrix.to/#/#community:nixos.org) before opening an issue.
options:
- label: "I assert that this is a bug and not a support request."
required: true
- label: "I assert that this is not a [duplicate of an existing issue](https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aissue+label%3A%220.kind%3A+build+failure%22). "
required: true
- label: "I assert that I have read the [NixOS Code of Conduct](https://github.com/NixOS/.github/blob/master/CODE_OF_CONDUCT.md) and agree to abide by it."
required: true
- type: "markdown"
attributes:
value: |
# Thank you for helping improve Nixpkgs!
---
- type: "textarea"
id: "prioritisation"
attributes:
label: "Is this issue important to you?"
description: |
**Please do not modify this text area!**
This template helps Nixpkgs developers know which issues should be prioritised by allowing users to vote with a :+1: reaction.
This is not a guarantee that highly-requested issues will be fixed first, but it helps us to figure out what's important to users. Please react on other users' issues if you find them important.
value: |
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

@@ -1,127 +0,0 @@
name: "Request: new package"
description: "Create a package request for software that is not yet included in Nixpkgs."
title: "Package request: PACKAGENAME"
labels: ["0.kind: enhancement", "0.kind: packaging request", "9.needs: package (new)"]
body:
- type: "markdown"
attributes:
value: |
<p align="center">
<a href="https://nixos.org">
<picture>
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png">
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png" width="400px" alt="NixOS logo">
</picture>
</a>
</p>
Welcome to Nixpkgs. Please replace the **`Package request: PACKAGENAME`** template above with the correct package name (As seen in the [NixOS Package Search](https://search.nixos.org/packages)).
> [!TIP]
> For instance, if you were filing a request against the missing `hello` package, your title would be as follows:
> `Package request: hello`
---
- type: "dropdown"
id: "version"
attributes:
label: "Nixpkgs version"
description: |
What version of Nixpkgs are you using?
> [!IMPORTANT]
> If you are using an older or stable version, please update to the latest **unstable** version and check if the package still does not exist before continuing this request.
options:
- "Please select a version."
- "- Unstable (25.05)"
- "- Stable (24.11)"
- "- Previous Stable (24.05)"
default: 0
validations:
required: true
- type: "textarea"
id: "description"
attributes:
label: "Describe the package"
description: "Please include a clear and concise description of what the package is."
validations:
required: true
- type: "input"
id: "homepage"
attributes:
label: "Upstream homepage"
description: "Please copy and paste a link to the package's homepage. Leave this field blank if there is no upstream homepage."
validations:
required: false
- type: "input"
id: "source"
attributes:
label: "Source URL"
description: "Please copy and paste a link to the package's source code or binary download page."
validations:
required: true
- type: "input"
id: "license"
attributes:
label: "License"
description: "Please indicate the package's license. If the package has no license, or the source code is not public, please indicate the package is `unfree`."
validations:
required: true
- type: "dropdown"
id: "platforms"
attributes:
label: "Platforms"
description: "Please indicate the platforms this package compiles for. `darwin` refers to macOS. `Exotic` refers to uncommon platforms like RISC-V or 32-bit ARM; please mention in the 'Additional Context' section below if this package is supposed to compile for such exotic platforms."
multiple: true
options:
- "x86_64-linux"
- "aarch64-linux"
- "x86_64-darwin"
- "aarch64-darwin"
- "Exotic"
validations:
required: true
- type: "textarea"
id: "additional-context"
attributes:
label: "Additional context"
description: "Add any other context about the proposed module here."
validations:
required: false
- type: "checkboxes"
id: "sanity-check"
attributes:
label: "I assert that this issue is relevant for Nixpkgs"
options:
- label: "I assert that this package does not yet exist in an [open pull request](https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+is%3Apr+label%3A%228.has%3A+package+%28new%29%22) or in [Nixpkgs Unstable](https://search.nixos.org/packages?channel=unstable)."
required: true
- label: "I assert that this is not a [duplicate of any known issue](https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+label%3A%220.kind%3A+packaging+request%22)."
required: true
- label: "I assert that I have read the [NixOS Code of Conduct](https://github.com/NixOS/.github/blob/master/CODE_OF_CONDUCT.md) and agree to abide by it."
required: true
- type: "markdown"
attributes:
value: |
# Thank you for helping improve Nixpkgs!
---
- type: "textarea"
id: "prioritisation"
attributes:
label: "For this package's maintainers:"
description: |
**Please do not modify this text area!**
This template helps Nixpkgs developers know which issues should be prioritised by allowing users to vote with a :+1: reaction and also reminds them to tag this issue in their pull requests.
This is not a guarantee that highly-requested issues will be fixed first, but it helps us to figure out what's important to users. Please react on other users' issues if you find them important.
value: |
Please tag this issue in your pull request description. (i.e. `Resolves #ISSUE`.)
---
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

@@ -1,120 +0,0 @@
name: "Request: package update"
description: "Create an update request for an existing, but outdated package."
title: "Update Request: PACKAGENAME OLDVERSION → NEWVERSION"
labels: ["0.kind: enhancement", "9.needs: package (update)"]
body:
- type: "markdown"
attributes:
value: |
<p align="center">
<a href="https://nixos.org">
<picture>
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png">
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png" width="400px" alt="NixOS logo">
</picture>
</a>
</p>
Welcome to Nixpkgs. Please replace the **`Update Request: PACKAGENAME OLDVERSION → NEWVERSION`** template above with the correct package name (As seen in the [NixOS Package Search](https://search.nixos.org/packages)), the current version of the package, and the latest version of the package.
> [!TIP]
> For instance, if you were filing a request against the out of date `hello` package, where the current version in Nixpkgs is 1.0.0, but the latest version upstream is 1.0.1, your title would be as follows:
> `Update Request: hello 1.0.0 → 1.0.1`
> [!NOTE]
> If you are filing an update request to change a package's source to a fork, please file a new package request instead. Even if the original upstream is outdated, the fork should be considered a new package.
---
- type: "dropdown"
id: "version"
attributes:
label: "Nixpkgs version"
description: |
What version of Nixpkgs are you using?
> [!IMPORTANT]
> If you are using an older or stable version, please update to the latest **unstable** version and check if the package is still out of date.
> If the package has been updated in unstable, but you believe the update should be backported to the stable release of Nixpkgs, please file the '**Request: backport to stable**' form instead.
options:
- "Please select a version."
- "- Unstable (25.05)"
- "- Stable (24.11)"
- "- Previous Stable (24.05)"
default: 0
validations:
required: true
- type: "input"
id: "name"
attributes:
label: "Package name"
description: "Please indicate the name of the package."
validations:
required: true
- type: "input"
id: "upstream-version"
attributes:
label: "Upstream version"
description: "Please indicate the latest version of the package."
validations:
required: true
- type: "input"
id: "nixpkgs-version"
attributes:
label: "Nixpkgs version"
description: |
Please indicate the current version number in Nixpkgs' **unstable** channel. You can check this by setting the [NixOS Package Search](https://search.nixos.org/packages?channel=unstable) channel to 'unstable' and searching for the package.
If you meant to request an upgrade in the stable channel, please file the '**Request: backport to stable**' form instead.
validations:
required: true
- type: "input"
id: "changelog"
attributes:
label: "Changelog"
description: "If applicable, please link the upstream changelog for the latest version."
validations:
required: false
- type: "textarea"
id: "maintainers"
attributes:
label: "Notify maintainers"
description: |
Please mention the people who are in the **Maintainers** list of the offending package. This is done by by searching for the package on the [NixOS Package Search](https://search.nixos.org/packages) and mentioning the people listed under **Maintainers** by prefixing their GitHub usernames with an '@' character. Please add the mentions above the `---` characters in the template below.
value: |
---
**Note for maintainers:** Please tag this issue in your pull request description. (i.e. `Resolves #ISSUE`.)
validations:
required: false
- type: "checkboxes"
id: "sanity-check"
attributes:
label: "I assert that this issue is relevant for Nixpkgs"
options:
- label: "I assert that this package update does not yet exist in an [open pull request](https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+is%3Apr+label%3A%228.has%3A+package+%28update%29%22) or in [Nixpkgs Unstable](https://search.nixos.org/packages?channel=unstable)."
required: true
- label: "I assert that this is not a [duplicate of any known issue](https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aissue+label%3A%229.needs%3A+package+%28update%29%22)."
required: true
- label: "I assert that I have read the [NixOS Code of Conduct](https://github.com/NixOS/.github/blob/master/CODE_OF_CONDUCT.md) and agree to abide by it."
required: true
- type: "markdown"
attributes:
value: |
# Thank you for helping improve Nixpkgs!
---
- type: "textarea"
id: "prioritisation"
attributes:
label: "Is this issue important to you?"
description: |
**Please do not modify this text area!**
This template helps Nixpkgs developers know which issues should be prioritised by allowing users to vote with a :+1: reaction.
This is not a guarantee that highly-requested issues will be fixed first, but it helps us to figure out what's important to users. Please react on other users' issues if you find them important.
value: |
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

@@ -1,100 +0,0 @@
name: "Request: NixOS module"
description: "Create a new NixOS Module request for an existing package."
title: "Module Request: nixos/MODULENAME"
labels: ["0.kind: enhancement", "6.topic: nixos", "9.needs: module (new)"]
body:
- type: "markdown"
attributes:
value: |
<p align="center">
<a href="https://nixos.org">
<picture>
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png">
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png" width="400px" alt="NixOS logo">
</picture>
</a>
</p>
Welcome to Nixpkgs. Please replace the **`Module Request: nixos/MODULENAME`** template above with the correct module name (As seen in the [NixOS Option Search](https://search.nixos.org/options)).
> [!TIP]
> For instance, if you were filing a request against the missing `hello` module, your title would be as follows:
> `Module Request: nixos/hello`
---
- type: "dropdown"
id: "version"
attributes:
label: "Nixpkgs version"
description: |
What version of Nixpkgs are you using?
> [!IMPORTANT]
> If you are using an older or stable version, please update to the latest **unstable** version and check if the module still does not exist before continuing this request.
options:
- "Please select a version."
- "- Unstable (25.05)"
- "- Stable (24.11)"
- "- Previous Stable (24.05)"
default: 0
validations:
required: true
- type: "textarea"
id: "description"
attributes:
label: "Describe the proposed module"
description: "Please include a clear and concise description of what the module should accomplish."
validations:
required: true
- type: "textarea"
id: "additional-context"
attributes:
label: "Additional context"
description: "Add any other context about the proposed module here."
validations:
required: false
- type: "textarea"
id: "maintainers"
attributes:
label: "Notify maintainers"
description: |
Please mention the people who are in the **Maintainers** list of the offending package. This is done by by searching for the package on the [NixOS Package Search](https://search.nixos.org/packages) and mentioning the people listed under **Maintainers** by prefixing their GitHub usernames with an '@' character. Please add the mentions above the `---` characters in the template below.
value: |
---
**Note for maintainers:** Please tag this issue in your pull request description. (i.e. `Resolves #ISSUE`.)
validations:
required: false
- type: "checkboxes"
id: "sanity-check"
attributes:
label: "I assert that this issue is relevant for Nixpkgs"
options:
- label: "I assert that this module does not yet exist in an [open pull request](https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+is%3Apr+label%3A%228.has%3A+module+%28new%29%22) or in [NixOS Unstable](https://search.nixos.org/options?channel=unstable)."
required: true
- label: "I assert that this is not a [duplicate of an existing issue](https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aissue+label%3A%229.needs%3A+module+%28new%29%22). "
required: true
- label: "I assert that I have read the [NixOS Code of Conduct](https://github.com/NixOS/.github/blob/master/CODE_OF_CONDUCT.md) and agree to abide by it."
required: true
- type: "markdown"
attributes:
value: |
# Thank you for helping improve NixOS!
---
- type: "textarea"
id: "prioritisation"
attributes:
label: "Is this issue important to you?"
description: |
**Please do not modify this text area!**
This template helps Nixpkgs developers know which issues should be prioritised by allowing users to vote with a :+1: reaction.
This is not a guarantee that highly-requested issues will be fixed first, but it helps us to figure out what's important to users. Please react on other users' issues if you find them important.
value: |
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

@@ -1,102 +0,0 @@
name: "Request: backport to stable"
description: "Create a backport request for a package that is up-to-date in the unstable channel, but outdated in the stable channel."
title: "Backport to Stable: PACKAGENAME OLDVERSION → NEWVERSION"
labels: ["0.kind: enhancement", "9.needs: port to stable"]
body:
- type: "markdown"
attributes:
value: |
<p align="center">
<a href="https://nixos.org">
<picture>
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png">
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png" width="400px" alt="NixOS logo">
</picture>
</a>
</p>
> [!CAUTION]
> **Before you begin:** Be advised that backports are subject to the [release suitability guidelines](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#changes-acceptable-for-releases).
> Stable releases of Nixpkgs do not receive breaking changes, which include major package updates that have incompatible API changes and break backwards compatibility. In the [Semantic Versioning standard](https://semver.org/), this is the first version number. (1.X.X)
> Generally, only minor package updates, such as security patches, bug fixes and feature additions (but not removals!) will be considered for backporting. Please read the rules above carefully before filing this backport request.
Welcome to Nixpkgs. Please replace the **`Backport to Stable: PACKAGENAME OLDVERSION → NEWVERSION`** template above with the correct package name (As seen in the [NixOS Package Search](https://search.nixos.org/packages)), the current version of the package in Nixpkgs Stable and the current version of the package in Nixpkgs Unstable.
> [!TIP]
> For instance, if you were filing a request against the out of date `hello` package, where the current version in Nixpkgs Unstable is 1.0.1, but the current version in Nixpkgs Stable is 1.0.0, your title would be as follows:
> `Backport to Stable: hello 1.0.0 → 1.0.1`
---
- type: "input"
id: "name"
attributes:
label: "Package name"
description: "Please indicate the name of the package."
validations:
required: true
- type: "input"
id: "unstable-version"
attributes:
label: "Version in unstable"
description: "Please indicate the current version of the package in the unstable channel."
validations:
required: true
- type: "input"
id: "stable-version"
attributes:
label: "Version in stable"
description: "Please indicate the current version of the package in the stable channel."
validations:
required: true
- type: "textarea"
id: "reasoning"
attributes:
label: "Reasoning for backport"
description: "Please briefly explain why this backport fits the [release suitability guidelines](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#changes-acceptable-for-releases) and why you think this update should be backported."
validations:
required: false
- type: "textarea"
id: "maintainers"
attributes:
label: "Notify maintainers"
description: |
Please mention the people who are in the **Maintainers** list of the offending package. This is done by by searching for the package on the [NixOS Package Search](https://search.nixos.org/packages) and mentioning the people listed under **Maintainers** by prefixing their GitHub usernames with an '@' character. Please add the mentions above the `---` characters in the template below.
value: |
---
**Note for maintainers:** Please tag this issue in your pull request description. (i.e. `Resolves #ISSUE`.)
validations:
required: false
- type: "checkboxes"
id: "sanity-check"
attributes:
label: "I assert that this issue is relevant for Nixpkgs"
options:
- label: "I assert that this backport does not yet exist in an [open pull request](https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+in%3Atitle+backport)."
required: true
- label: "I assert that this is not a [duplicate of any known issue](https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+label%3A%229.needs%3A+port+to+stable%22+)."
required: true
- label: "I assert that I have read the [NixOS Code of Conduct](https://github.com/NixOS/.github/blob/master/CODE_OF_CONDUCT.md) and agree to abide by it."
required: true
- type: "markdown"
attributes:
value: |
# Thank you for helping improve Nixpkgs!
---
- type: "textarea"
id: "prioritisation"
attributes:
label: "Is this issue important to you?"
description: |
**Please do not modify this text area!**
This template helps Nixpkgs developers know which issues should be prioritised by allowing users to vote with a :+1: reaction.
This is not a guarantee that highly-requested issues will be fixed first, but it helps us to figure out what's important to users. Please react on other users' issues if you find them important.
value: |
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

@@ -1,86 +0,0 @@
name: "Request: documentation"
description: "Report missing or incorrect documentation in the NixOS or Nixpkgs manuals."
title: "Missing Documentation: PACKAGENAME"
labels: ["0.kind: enhancement", "9.needs: documentation"]
body:
- type: "markdown"
attributes:
value: |
<p align="center">
<a href="https://nixos.org">
<picture>
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png">
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png" width="400px" alt="NixOS logo">
</picture>
</a>
</p>
Welcome to Nixpkgs. Please replace the **`Missing Documentation: PACKAGENAME`** template above with the correct package name (As seen in the [NixOS Package Search](https://search.nixos.org/packages)) or module name (As seen in the [NixOS Option Search](https://search.nixos.org/options)).
> [!TIP]
> For instance, if you were filing an issue against the [`hello`](https://search.nixos.org/packages?channel=unstable&from=0&size=1&buckets=%7B%22package_attr_set%22%3A%5B%22No%20package%20set%22%5D%2C%22package_license_set%22%3A%5B%22GNU%20General%20Public%20License%20v3.0%20or%20later%22%5D%2C%22package_maintainers_set%22%3A%5B%5D%2C%22package_platforms%22%3A%5B%5D%7D&sort=relevance&type=packages&query=hello) package about it not having any NixOS-specific documentation, your title would be as follows:
> `Missing Documentation: hello`
---
- type: "textarea"
id: "description"
attributes:
label: "Describe the problem"
description: "Please include a clear and concise description of what the issue is."
validations:
required: true
- type: "textarea"
id: "proposal"
attributes:
label: "Proposed solution"
description: |
If possible, please draft a tentative documentation chapter to resolve this issue.
Your proposal should be written in CommonMark Markdown, optionally enhanced with [Nix-specific extensions](https://github.com/NixOS/nixpkgs/tree/master/doc#syntax).
render: "markdown"
validations:
required: false
- type: "textarea"
id: "maintainers"
attributes:
label: "Notify maintainers"
description: |
Please mention the people who are in the **Maintainers** list of the offending package. This is done by by searching for the package on the [NixOS Package Search](https://search.nixos.org/packages) and mentioning the people listed under **Maintainers** by prefixing their GitHub usernames with an '@' character. Please add the mentions above the `---` characters in the template below.
value: |
---
**Note for maintainers:** Please tag this issue in your pull request description. (i.e. `Resolves #ISSUE`.)
validations:
required: false
- type: "checkboxes"
id: "sanity-check"
attributes:
label: "I assert that this issue is relevant for Nixpkgs"
options:
- label: "I assert that this request is not already implemented in the latest [NixOS](https://nixos.org/manual/nixos/unstable/) or [Nixpkgs](https://nixos.org/manual/nixpkgs/unstable/) manuals."
required: true
- label: "I assert that this is not a [duplicate of an existing documentation issue](https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+label%3A%229.needs%3A+documentation%22)."
required: true
- label: "I assert that I have read the [NixOS Code of Conduct](https://github.com/NixOS/.github/blob/master/CODE_OF_CONDUCT.md) and agree to abide by it."
required: true
- type: "markdown"
attributes:
value: |
# Thank you for helping improve Nixpkgs!
---
- type: "textarea"
id: "priorisation"
attributes:
label: "Is this issue important to you?"
description: |
**Please do not modify this text area!**
This template helps Nixpkgs developers know which issues should be prioritised by allowing users to vote with a :+1: reaction.
This is not a guarantee that highly-requested issues will be fixed first, but it helps us to figure out what's important to users. Please react on other users' issues if you find them important.
value: |
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

@@ -1,157 +0,0 @@
name: "Unreproducible Package"
description: "Report a package that does not produce a bit-by-bit reproducible result each time it is built."
title: "Unreproducible Package: PACKAGENAME"
labels: ["0.kind: enhancement", "6.topic: reproducible builds"]
body:
- type: "markdown"
attributes:
value: |
<p align="center">
<a href="https://nixos.org">
<picture>
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png">
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png" width="400px" alt="NixOS logo">
</picture>
</a>
</p>
Welcome to Nixpkgs. Please replace the **`Unreproducible Package: PACKAGENAME`** template above with the correct package name (As seen in the [NixOS Package Search](https://search.nixos.org/packages)).
> [!NOTE]
> This form is for reporting unreproducible packages. For more information, see the [Reproducible Builds Status](https://reproducible.nixos.org/) page.
> To report a package that fails to build entirely, please use the "Build Failure" form instead.
---
- type: "input"
id: "version"
attributes:
label: "Nixpkgs Revision"
description: "In which commit of Nixpkgs is this package displaying unreproducibility?"
- type: "textarea"
id: "introduction"
attributes:
label: "Introduction"
description: |
This is a generic introduction to build reproducibility.
Please replace **PACKAGENAME** below with the canonical package name of the package, as you have done for the title above.
value: |
Building **PACKAGENAME** multiple times does not yield bit-by-bit identical
results, complicating the detection of Continuous Integration (CI) breaches. For
more information on this issue, visit [reproducible-builds.org](https://reproducible-builds.org/).
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.
validations:
required: true
- type: "textarea"
id: "how-to-reproduce"
attributes:
label: "Steps to reproduce"
description: |
This is a step-by-step instruction set meant for maintainers to debug the package that is failing to reproduce. You should also follow it to gather the `diffoscope` logs that will be needed below.
Please replace **PACKAGENAME** below with the canonical package name of the package, as you have done for the introduction and the title above.
value: |
### 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.
Execute the following command:
```
nix-build '<nixpkgs>' -A PACKAGENAME && nix-build '<nixpkgs>' -A PACKAGENAME --check --keep-failed
```
Or using the new command line style:
```
nix build nixpkgs#PACKAGENAME && nix build nixpkgs#PACKAGENAME --rebuild --keep-failed
```
### 2. Compare the build artifacts
If the previous command completes successfully, no differences were found and
there's nothing to do, builds are reproducible.
If it terminates with the error message `error: derivation '<X>' may not be
deterministic: output '<Y>' differs from '<Z>'`, use `diffoscope` to investigate
the discrepancies between the two build outputs. You may need to add the
`--exclude-directory-metadata recursive` option to ignore files and directories
metadata (*e.g. timestamp*) differences.
```
nix run nixpkgs#diffoscopeMinimal -- --exclude-directory-metadata recursive <Y> <Z>
```
### 3. Examine the build log
To examine the build log, use:
```
nix-store --read-log $(nix-instantiate '<nixpkgs>' -A PACKAGENAME)
```
Or with the new command line style:
```
nix log $(nix path-info --derivation nixpkgs#PACKAGENAME)
```
validations:
required: true
- type: "textarea"
id: "logs"
attributes:
label: "Diffoscope log"
description: |
Please copy and paste the relevant `diffoscope` log output, gathered from the steps above.
This will be automatically formatted into a monospaced text block, so no need for backticks.
render: "console"
- type: "textarea"
id: "additional-context"
attributes:
label: "Additional context"
description: "Add any other context about the problem here."
validations:
required: false
id: "maintainers"
attributes:
label: "Notify maintainers"
description: |
Please mention the people who are in the **Maintainers** list of the offending package. This is done by by searching for the package on the [NixOS Package Search](https://search.nixos.org/packages) and mentioning the people listed under **Maintainers** by prefixing their GitHub usernames with an '@' character. Please add the mentions above the `---` characters in the template below.
value: |
---
**Note for maintainers:** Please tag this issue in your pull request description. (i.e. `Resolves #ISSUE`.)
validations:
required: false
- type: "checkboxes"
id: "sanity-check"
attributes:
label: "I assert that this issue is relevant for Nixpkgs"
options:
- label: "I assert that this is not a [duplicate of any known issue](https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aissue+label%3A%226.topic%3A+reproducible+builds%22)."
required: true
- label: "I assert that I have read the [NixOS Code of Conduct](https://github.com/NixOS/.github/blob/master/CODE_OF_CONDUCT.md) and agree to abide by it."
required: true
- type: "markdown"
attributes:
value: |
# Thank you for helping improve Nixpkgs!
---
- type: "textarea"
id: "prioritisation"
attributes:
label: "Is this issue important to you?"
description: |
**Please do not modify this text area!**
This template helps Nixpkgs developers know which issues should be prioritised by allowing users to vote with a :+1: reaction.
This is not a guarantee that highly-requested issues will be fixed first, but it helps us to figure out what's important to users. Please react on other users' issues if you find them important.
value: |
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

40
.github/ISSUE_TEMPLATE/bug_report.md vendored Normal file
View File

@@ -0,0 +1,40 @@
---
name: Bug report
about: Create a report to help us improve
title: ''
labels: '0.kind: bug'
assignees: ''
---
### 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
A clear and concise description of what you expected to happen.
### Screenshots
If applicable, add screenshots to help explain your problem.
### Additional context
Add any other context about the problem here.
### 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.
```console
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here
```

34
.github/ISSUE_TEMPLATE/build_failure.md vendored Normal file
View File

@@ -0,0 +1,34 @@
---
name: Build failure
about: Create a report to help us improve
title: ''
labels: '0.kind: build failure'
assignees: ''
---
### Steps To Reproduce
Steps to reproduce the behavior:
1. build *X*
### Build log
```
log here if short otherwise a link to a gist
```
### Additional context
Add any other context about the problem here.
### 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.
```console
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here
```

View File

@@ -0,0 +1,32 @@
---
name: Missing or incorrect documentation
about: Help us improve the Nixpkgs and NixOS reference manuals
title: ''
labels: '9.needs: documentation'
assignees: ''
---
## Problem
<!-- describe your problem -->
## Checklist
<!-- make sure this issue is not redundant or obsolete -->
- [ ] checked [latest Nixpkgs manual] \([source][nixpkgs-source]) and [latest NixOS manual] \([source][nixos-source])
- [ ] checked [open documentation issues] for possible duplicates
- [ ] checked [open documentation pull requests] for possible solutions
[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
## Proposal
<!-- propose a solution -->

View File

@@ -0,0 +1,48 @@
---
name: Out-of-date package reports
about: For packages that are out-of-date
title: ''
labels: '9.needs: package (update)'
assignees: ''
---
###### Checklist
<!-- Note that these are hard requirements -->
<!--
You can use the "Go to file" functionality on GitHub to find the package
Then you can go to the history for this package
Find the latest "package_name: old_version -> new_version" commit
The "new_version" is the current version of the package
-->
- [ ] Checked the [nixpkgs master branch](https://github.com/NixOS/nixpkgs)
<!--
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)
###### Project name
`nix search` name:
<!--
The current version can be found easily with the same process as above for checking the master branch
If an open PR is present for the package, take this version as the current one and link to the PR
-->
current version:
desired version:
###### Notify maintainers
<!--
Search your package here: https://search.nixos.org/packages?channel=unstable
If no maintainer is listed for your package, tag the person that last updated the package
-->
maintainers:
###### Note for maintainers
Please tag this issue in your PR.

View File

@@ -0,0 +1,18 @@
---
name: Packaging requests
about: For packages that are missing
title: ''
labels: '0.kind: packaging request'
assignees: ''
---
**Project description**
_describe the project a little_
**Metadata**
* homepage URL:
* source URL:
* license: mit, bsd, gpl2+ , ...
* platforms: unix, linux, darwin, ...

View File

@@ -0,0 +1,31 @@
---
name: Unreproducible package
about: A package that does not produce a bit-by-bit reproducible result each time it is built
title: ''
labels: '0.kind: enhancement', '6.topic: reproducible builds'
assignees: ''
---
Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible-builds.org/ .
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
```
nix-build '<nixpkgs>' -A ... --check --keep-failed
```
You can use `diffoscope` to analyze the differences in the output of the two builds.
To view the build log of the build that produced the artifact in the binary cache:
```
nix-store --read-log $(nix-instantiate '<nixpkgs>' -A ...)
```
### Additional context
(please share the relevant fragment of the diffoscope output here,
and any additional analysis you may have done)

View File

@@ -1,12 +1,11 @@
###### 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.
-->
## Things done
###### Things done
<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->
@@ -15,20 +14,19 @@ For new packages please briefly describe the package or provide a link to its ho
- [ ] aarch64-linux
- [ ] x86_64-darwin
- [ ] aarch64-darwin
- For non-Linux: Is sandboxing enabled in `nix.conf`? (See [Nix manual](https://nixos.org/manual/nix/stable/command-ref/conf-file.html))
- [ ] `sandbox = relaxed`
- [ ] `sandbox = true`
- [ ] For non-Linux: Is `sandbox = true` set in `nix.conf`? (See [Nix manual](https://nixos.org/manual/nix/stable/command-ref/conf-file.html))
- [ ] Tested, as applicable:
- [NixOS test(s)](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
- and/or [package tests](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests)
- and/or [package tests](https://nixos.org/manual/nixpkgs/unstable/#sec-package-tests)
- or, for functions and "core" functionality, tests in [lib/tests](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or [pkgs/test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test)
- made sure NixOS tests are [linked](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#linking-nixos-module-tests-to-a-package) to the relevant packages
- made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages
- [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"`. Note: all changes have to be committed, also see [nixpkgs-review usage](https://github.com/Mic92/nixpkgs-review#usage)
- [ ] Tested basic functionality of all binary files (usually in `./result/bin/`)
- [25.05 Release Notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2505.section.md) (or backporting [24.11](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2411.section.md) and [25.05](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2505.section.md) Release notes)
- [23.05 Release Notes (or backporting 22.11 Release notes)](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2305-release-notes)
- [ ] (Package updates) Added a release notes entry if the change is major or breaking
- [ ] (Module updates) Added a release notes entry if the change is significant
- [ ] (Module addition) Added a release notes entry if adding a new NixOS module
- [ ] (Release notes changes) Ran `nixos/doc/manual/md-to-db.sh` to update generated release notes
- [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
<!--
@@ -39,12 +37,5 @@ Reviewing helps to reduce the average time-to-merge for everyone.
Thanks a lot if you do!
List of open PRs: https://github.com/NixOS/nixpkgs/pulls
Reviewing guidelines: https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#reviewing-contributions
Reviewing guidelines: https://nixos.org/manual/nixpkgs/unstable/#chap-reviewing-contributions
-->
---
Add a :+1: [reaction] to [pull requests you find important].
[reaction]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
[pull requests you find important]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+sort%3Areactions-%2B1-desc

View File

@@ -1,28 +0,0 @@
# This file is used by .github/workflows/labels.yml
# This version uses `sync-labels: false`, meaning that a non-match will NOT remove the label
"backport release-24.11":
- any:
- changed-files:
- any-glob-to-any-file:
- .github/workflows/*
- ci/**/*.*
"6.topic: policy discussion":
- any:
- changed-files:
- any-glob-to-any-file:
- .github/**/*
- CONTRIBUTING.md
- pkgs/README.md
- nixos/README.md
- maintainers/README.md
- lib/README.md
- doc/README.md
"8.has: documentation":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/**/*
- nixos/doc/**/*

632
.github/labeler.yml vendored
View File

@@ -1,581 +1,163 @@
# This file is used by .github/workflows/labels.yml
# This version uses `sync-labels: true`, meaning that a non-match will remove the label
# NOTE: bsd, darwin and cross-compilation labels are handled by ofborg
"6.topic: agda":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/agda.section.md
- nixos/tests/agda.nix
- pkgs/build-support/agda/**/*
- pkgs/development/libraries/agda/**/*
- pkgs/top-level/agda-packages.nix
- doc/languages-frameworks/agda.section.md
- nixos/tests/agda.nix
- pkgs/build-support/agda/**/*
- pkgs/development/libraries/agda/**/*
- pkgs/top-level/agda-packages.nix
"6.topic: cinnamon":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/services/x11/desktop-managers/cinnamon.nix
- nixos/tests/cinnamon.nix
- nixos/tests/cinnamon-wayland.nix
- pkgs/by-name/ci/cinnamon-*/**/*
- pkgs/by-name/cj/cjs/**/*
- pkgs/by-name/mu/muffin/**/*
- 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:
- any-glob-to-any-file:
- doc/languages-frameworks/dotnet.section.md
- maintainers/scripts/update-dotnet-lockfiles.nix
- pkgs/build-support/dotnet/**/*
- pkgs/development/compilers/dotnet/**/*
- pkgs/test/dotnet/**/*
- pkgs/top-level/dotnet-packages.nix
- pkgs/desktops/cinnamon/**/*
- nixos/modules/services/x11/desktop-managers/cinnamon.nix
- nixos/tests/cinnamon.nix
"6.topic: emacs":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/services/editors/emacs.nix
- nixos/modules/services/editors/emacs.xml
- nixos/tests/emacs-daemon.nix
- pkgs/applications/editors/emacs/build-support/**/*
- pkgs/applications/editors/emacs/elisp-packages/**/*
- pkgs/applications/editors/emacs/**/*
- pkgs/top-level/emacs-packages.nix
"6.topic: Enlightenment DE":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/services/x11/desktop-managers/enlightenment.nix
- pkgs/desktops/enlightenment/**/*
- pkgs/development/python-modules/python-efl/*
- nixos/modules/services/editors/emacs.nix
- nixos/modules/services/editors/emacs.xml
- nixos/tests/emacs-daemon.nix
- pkgs/applications/editors/emacs/elisp-packages/**/*
- pkgs/applications/editors/emacs/**/*
- pkgs/build-support/emacs/**/*
- pkgs/top-level/emacs-packages.nix
"6.topic: erlang":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/beam.section.md
- pkgs/development/beam-modules/**/*
- pkgs/development/interpreters/elixir/**/*
- pkgs/development/interpreters/erlang/**/*
- pkgs/development/tools/build-managers/rebar/**/*
- pkgs/development/tools/build-managers/rebar3/**/*
- pkgs/development/tools/erlang/**/*
- pkgs/top-level/beam-packages.nix
- doc/languages-frameworks/beam.section.md
- pkgs/development/beam-modules/**/*
- pkgs/development/interpreters/elixir/**/*
- pkgs/development/interpreters/erlang/**/*
- pkgs/development/tools/build-managers/rebar/**/*
- pkgs/development/tools/build-managers/rebar3/**/*
- pkgs/development/tools/erlang/**/*
- pkgs/top-level/beam-packages.nix
"6.topic: fetch":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/build-support/fetch*/**/*
"6.topic: flakes":
- any:
- changed-files:
- any-glob-to-any-file:
- '**/flake.nix'
- lib/systems/flake-systems.nix
- nixos/modules/config/nix-flakes.nix
"6.topic: flutter":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/build-support/flutter/*.nix
- pkgs/development/compilers/flutter/**/*.nix
"6.topic: games":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/games/**/*
- pkgs/build-support/fetch*/**/*
"6.topic: GNOME":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/gnome.section.md
- nixos/modules/services/desktops/gnome/**/*
- nixos/modules/services/x11/desktop-managers/gnome.nix
- nixos/tests/gnome-xorg.nix
- nixos/tests/gnome.nix
- pkgs/desktops/gnome/**/*
- doc/languages-frameworks/gnome.section.md
- nixos/modules/services/desktops/gnome/**/*
- nixos/modules/services/x11/desktop-managers/gnome.nix
- nixos/tests/gnome-xorg.nix
- nixos/tests/gnome.nix
- pkgs/desktops/gnome/**/*
"6.topic: golang":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/go.section.md
- pkgs/build-support/go/**/*
- pkgs/development/compilers/go/**/*
"6.topic: hardware":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/hardware/**/*
- doc/languages-frameworks/go.section.md
- pkgs/build-support/go/**/*
- pkgs/development/compilers/go/**/*
"6.topic: haskell":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/haskell.section.md
- maintainers/scripts/haskell/**/*
- pkgs/development/compilers/ghc/**/*
- pkgs/development/haskell-modules/**/*
- pkgs/development/tools/haskell/**/*
- pkgs/test/haskell/**/*
- pkgs/top-level/haskell-packages.nix
- pkgs/top-level/release-haskell.nix
"6.topic: java":
- any:
- changed-files:
- any-glob-to-any-file:
# Distributions
- pkgs/development/compilers/adoptopenjdk-icedtea-web/**/*
- pkgs/development/compilers/corretto/**/*
- pkgs/development/compilers/graalvm/**/*
- pkgs/development/compilers/openjdk/**/*
- pkgs/by-name/op/openjfx/**/*
- pkgs/development/compilers/semeru-bin/**/*
- pkgs/development/compilers/temurin-bin/**/*
- pkgs/development/compilers/zulu/**/*
# Documentation
- doc/languages-frameworks/java.section.md
# Gradle
- doc/languages-frameworks/gradle.section.md
- pkgs/development/tools/build-managers/gradle/**/*
- pkgs/by-name/gr/gradle-completion/**/*
# Maven
- pkgs/by-name/ma/maven/**/*
- doc/languages-frameworks/maven.section.md
# Ant
- pkgs/by-name/an/ant/**/*
# javaPackages attrset
- pkgs/development/java-modules/**/*
- pkgs/top-level/java-packages.nix
# Maintainer tooling
- pkgs/by-name/ni/nixpkgs-openjdk-updater/**/*
# Misc
- nixos/modules/programs/java.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:
- any-glob-to-any-file:
- doc/languages-frameworks/julia.section.md
- pkgs/development/compilers/julia/**/*
- pkgs/development/julia-modules/**/*
"6.topic: jupyter":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/development/python-modules/jupyter*/**/*
- pkgs/development/python-modules/mkdocs-jupyter/*
- nixos/modules/services/development/jupyter/**/*
- pkgs/applications/editors/jupyter-kernels/**/*
- pkgs/applications/editors/jupyter/**/*
"6.topic: k3s":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/services/cluster/k3s/**/*
- nixos/tests/k3s/**/*
- pkgs/applications/networking/cluster/k3s/**/*
- doc/languages-frameworks/haskell.section.md
- maintainers/scripts/haskell/**/*
- pkgs/development/compilers/ghc/**/*
- pkgs/development/haskell-modules/**/*
- pkgs/development/tools/haskell/**/*
- pkgs/test/haskell/**/*
- pkgs/top-level/haskell-packages.nix
- pkgs/top-level/release-haskell.nix
"6.topic: kernel":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/build-support/kernel/**/*
- pkgs/os-specific/linux/kernel/**/*
"6.topic: lib":
- any:
- changed-files:
- any-glob-to-any-file:
- lib/**
"6.topic: llvm/clang":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/development/compilers/llvm/**/*
- pkgs/build-support/kernel/**/*
- pkgs/os-specific/linux/kernel/**/*
"6.topic: lua":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/development/tools/misc/luarocks/*
- pkgs/development/interpreters/lua-5/**/*
- pkgs/development/interpreters/luajit/**/*
- pkgs/development/lua-modules/**/*
- pkgs/top-level/lua-packages.nix
"6.topic: Lumina DE":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/services/x11/desktop-managers/lumina.nix
- pkgs/desktops/lumina/**/*
"6.topic: LXQt":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/services/x11/desktop-managers/lxqt.nix
- pkgs/desktops/lxqt/**/*
"6.topic: mate":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/services/x11/desktop-managers/mate.nix
- nixos/tests/mate.nix
- pkgs/desktops/mate/**/*
"6.topic: module system":
- any:
- changed-files:
- any-glob-to-any-file:
- lib/modules.nix
- lib/types.nix
- lib/options.nix
- lib/tests/modules.sh
- lib/tests/modules/**
"6.topic: musl":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/os-specific/linux/musl/**/*
- pkgs/development/interpreters/lua-5/**/*
- pkgs/development/interpreters/luajit/**/*
- pkgs/development/lua-modules/**/*
- pkgs/top-level/lua-packages.nix
"6.topic: nixos":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/**/*
- pkgs/by-name/sw/switch-to-configuration-ng/**/*
- pkgs/by-name/ni/nixos-rebuild-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/**/*
- nixos/**/*
- pkgs/os-specific/linux/nixos-rebuild/**/*
"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/build-support/build-nim-sbom.nix
- pkgs/by-name/ni/nim*
- pkgs/top-level/nim-overrides.nix
"6.topic: nodejs":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/javascript.section.md
- pkgs/build-support/node/**/*
- pkgs/development/node-packages/**/*
- pkgs/development/tools/yarn/*
- pkgs/development/tools/yarn2nix-moretea/**/*
- 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/**/*
- doc/languages-frameworks/nim.section.md
- pkgs/development/compilers/nim/*
- pkgs/development/nim-packages/**/*
- pkgs/top-level/nim-packages.nix
"6.topic: ocaml":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/ocaml.section.md
- pkgs/development/compilers/ocaml/**/*
- pkgs/development/compilers/reason/**/*
- pkgs/development/ocaml-modules/**/*
- pkgs/development/tools/ocaml/**/*
- pkgs/top-level/ocaml-packages.nix
- doc/languages-frameworks/ocaml.section.md
- pkgs/development/compilers/ocaml/**/*
- pkgs/development/compilers/reason/**/*
- pkgs/development/ocaml-modules/**/*
- pkgs/development/tools/ocaml/**/*
- pkgs/top-level/ocaml-packages.nix
"6.topic: pantheon":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/services/desktops/pantheon/**/*
- nixos/modules/services/x11/desktop-managers/pantheon.nix
- nixos/modules/services/x11/display-managers/lightdm-greeters/pantheon.nix
- nixos/tests/pantheon.nix
- pkgs/desktops/pantheon/**/*
- nixos/modules/services/desktops/pantheon/**/*
- nixos/modules/services/x11/desktop-managers/pantheon.nix
- nixos/modules/services/x11/display-managers/lightdm-greeters/pantheon.nix
- nixos/tests/pantheon.nix
- pkgs/desktops/pantheon/**/*
"6.topic: php":
- any:
- 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/php-packages/**/*
- pkgs/test/php/default.nix
- pkgs/top-level/php-packages.nix
"6.topic: policy discussion":
- .github/**/*
"6.topic: printing":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/services/printing/cupsd.nix
- pkgs/misc/cups/**/*
- nixos/modules/services/printing/cupsd.nix
- pkgs/misc/cups/**/*
"6.topic: python":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/python.section.md
- pkgs/development/interpreters/python/**/*
- pkgs/development/python-modules/**/*
- pkgs/top-level/python-packages.nix
- doc/languages-frameworks/python.section.md
- pkgs/development/interpreters/python/**/*
- pkgs/development/python-modules/**/*
- pkgs/top-level/python-packages.nix
"6.topic: qt/kde":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/qt.section.md
- nixos/modules/services/x11/desktop-managers/plasma5.nix
- nixos/tests/plasma5.nix
- pkgs/applications/kde/**/*
- pkgs/desktops/plasma-5/**/*
- 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/**/*
- doc/languages-frameworks/qt.section.md
- nixos/modules/services/x11/desktop-managers/plasma5.nix
- nixos/tests/plasma5.nix
- pkgs/applications/kde/**/*
- pkgs/desktops/plasma-5/**/*
- pkgs/development/libraries/kde-frameworks/**/*
- pkgs/development/libraries/qt-5/**/*
"6.topic: ruby":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/ruby.section.md
- pkgs/development/interpreters/ruby/**/*
- pkgs/development/ruby-modules/**/*
- pkgs/top-level/ruby-packages.nix
- doc/languages-frameworks/ruby.section.md
- pkgs/development/interpreters/ruby/**/*
- pkgs/development/ruby-modules/**/*
"6.topic: rust":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/rust.section.md
- pkgs/build-support/rust/**/*
- pkgs/development/compilers/rust/**/*
- doc/languages-frameworks/rust.section.md
- pkgs/build-support/rust/**/*
- pkgs/development/compilers/rust/**/*
"6.topic: stdenv":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/stdenv/**/*
- pkgs/stdenv/**/*
"6.topic: steam":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/games/steam/**/*
- pkgs/games/steam/**/*
"6.topic: systemd":
- any:
- changed-files:
- any-glob-to-any-file:
- 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: teams":
- any:
- changed-files:
- any-glob-to-any-file:
- maintainers/team-list.nix
- pkgs/os-specific/linux/systemd/**/*
- nixos/modules/system/boot/systemd*/**/*
"6.topic: TeX":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/texlive.section.md
- pkgs/test/texlive/**
- pkgs/tools/typesetting/tex/**/*
"6.topic: testing":
- any:
- changed-files:
- any-glob-to-any-file:
# NOTE: Let's keep the scope limited to test frameworks that are
# *developed in this repo*;
# - not individual tests
# - not packages for test frameworks
- pkgs/build-support/testers/**
- nixos/lib/testing/**
- nixos/lib/test-driver/**
- nixos/tests/nixos-test-driver/**
- nixos/lib/testing-python.nix # legacy
- 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/**/*
- doc/languages-frameworks/texlive.section.md
- pkgs/tools/typesetting/tex/**/*
"6.topic: vim":
- any:
- changed-files:
- any-glob-to-any-file:
- doc/languages-frameworks/vim.section.md
- pkgs/applications/editors/vim/**/*
- pkgs/applications/editors/vim/plugins/**/*
- nixos/modules/programs/neovim.nix
- pkgs/applications/editors/neovim/**/*
- doc/languages-frameworks/vim.section.md
- pkgs/applications/editors/vim/**/*
- pkgs/applications/editors/vim/plugins/**/*
- nixos/modules/programs/neovim.nix
- pkgs/applications/editors/neovim/**/*
"6.topic: vscode":
- any:
- changed-files:
- 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/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/*
- pkgs/applications/editors/vscode/**/*
"6.topic: xfce":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/doc/manual/configuration/xfce.xml
- nixos/modules/services/x11/desktop-managers/xfce.nix
- nixos/tests/xfce.nix
- pkgs/desktops/xfce/**/*
"6.topic: zig":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/development/compilers/zig/**/*
- doc/hooks/zig.section.md
- nixos/doc/manual/configuration/xfce.xml
- nixos/modules/services/x11/desktop-managers/xfce.nix
- nixos/tests/xfce.nix
- pkgs/desktops/xfce/**/*
"8.has: changelog":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/doc/manual/release-notes/**/*
- nixos/doc/manual/release-notes/**/*
"8.has: documentation":
- doc/**/*
- nixos/doc/**/*
"8.has: module (update)":
- any:
- changed-files:
- any-glob-to-any-file:
- nixos/modules/**/*
"8.has: maintainer-list (update)":
- any:
- changed-files:
- any-glob-to-any-file:
- maintainers/maintainer-list.nix
- nixos/modules/**/*

View File

@@ -1,20 +0,0 @@
# GitHub Actions Workflows
Some architectural notes about key decisions and concepts in our workflows:
- Instead of `pull_request` we use [`pull_request_target`](https://docs.github.com/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target) for all PR-related workflows. This has the advantage that those workflows will run without prior approval for external contributors.
- Running on `pull_request_target` also optionally provides us with a GH_TOKEN with elevated privileges (write access), which we need to do things like adding labels, requesting reviewers or pushing branches. **Note about security:** We need to be careful to limit the scope of elevated privileges as much as possible. Thus they should be lowered to the minimum with `permissions: {}` in every workflow by default.
- By definition `pull_request_target` runs in the context of the **base** of the pull request. This means, that the workflow files to run will be taken from the base branch, not the PR, and actions/checkout will not checkout the PR, but the base branch, by default. To protect our secrets, we need to make sure to **never execute code** from the pull request and always evaluate or build nix code from the pull request with the **sandbox enabled**.
- To test the pull request's contents, we checkout the "test merge commit". This is a temporary commit that GitHub creates automatically as "what would happen, if this PR was merged into the base branch now?". The checkout could be done via the virtual branch `refs/pull/<pr-number>/merge`, but doing so would cause failures when this virtual branch doesn't exist (anymore). This can happen when the PR has conflicts, in which case the virtual branch is not created, or when the PR is getting merged while workflows are still running, in which case the branch won't exist anymore at the time of checkout. Thus, we use the `get-merge-commit.yml` workflow to check whether the PR is mergeable and the test merge commit exists and only then run the relevant jobs.
- Various workflows need to make comparisons against the base branch. In this case, we checkout the parent of the "test merge commit" for best results. Note, that this is not necessarily the same as the default commit that actions/checkout would use, which is also a commit from the base branch (see above), but might be older.
## Terminology
- **base commit**: The pull_request_target event's context commit, i.e. the base commit given by GitHub Actions. Same as `github.event.pull_request.base.sha`.
- **head commit**: The HEAD commit in the pull request's branch. Same as `github.event.pull_request.head.sha`.
- **merge commit**: The temporary "test merge commit" that GitHub Actions creates and updates for the pull request. Same as `refs/pull/${{ github.event.pull_request.number }}/merge`.
- **target commit**: The base branch's parent of the "test merge commit" to compare against.

View File

@@ -1,43 +1,38 @@
name: Backport
on:
pull_request_target:
types: [closed, labeled]
# WARNING:
# When extending this action, be aware that $GITHUB_TOKEN allows write access to
# the GitHub repository. This means that it should not evaluate user input in a
# way that allows code injection.
name: Backport
on:
pull_request_target:
types: [closed, labeled]
permissions: {}
permissions:
contents: read
jobs:
backport:
permissions:
contents: write # for zeebe-io/backport-action to create branch
pull-requests: write # for zeebe-io/backport-action to create PR to backport
name: Backport Pull Request
if: github.repository_owner == 'NixOS' && github.event.pull_request.merged == true && (github.event_name != 'labeled' || startsWith('backport', github.event.label.name))
runs-on: ubuntu-24.04
runs-on: ubuntu-latest
steps:
# Use a GitHub App to create the PR so that CI gets triggered
# The App is scoped to Repository > Contents and Pull Requests: write for Nixpkgs
- uses: actions/create-github-app-token@67e27a7eb7db372a1c61a7f9bdab8699e9ee57f7 # v1.11.3
id: app-token
with:
app-id: ${{ vars.NIXPKGS_CI_APP_ID }}
private-key: ${{ secrets.NIXPKGS_CI_APP_PRIVATE_KEY }}
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/checkout@v3
with:
# required to find all branches
fetch-depth: 0
ref: ${{ github.event.pull_request.head.sha }}
token: ${{ steps.app-token.outputs.token }}
- name: Create backport PRs
uses: korthout/backport-action@be567af183754f6a5d831ae90f648954763f17f5 # v3.1.0
uses: zeebe-io/backport-action@v0.0.9
with:
# Config README: https://github.com/korthout/backport-action#backport-action
copy_labels_pattern: 'severity:\ssecurity'
github_token: ${{ steps.app-token.outputs.token }}
# Config README: https://github.com/zeebe-io/backport-action#backport-action
github_token: ${{ secrets.GITHUB_TOKEN }}
github_workspace: ${{ github.workspace }}
pull_description: |-
Bot-based backport to `${target_branch}`, triggered by a label in #${pull_number}.
* [ ] Before merging, ensure that this backport is [acceptable for the release](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#changes-acceptable-for-releases).
* Even as a non-commiter, if you find that it is not acceptable, leave a comment.
* [ ] Before merging, ensure that this backport complies with the [Criteria for Backporting](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#criteria-for-backporting-changes).
* Even as a non-commiter, if you find that it does not comply, leave a comment.

29
.github/workflows/basic-eval.yml vendored Normal file
View File

@@ -0,0 +1,29 @@
name: Basic evaluation checks
on:
workflow_dispatch
# pull_request:
# branches:
# - master
# - release-**
# push:
# branches:
# - master
# - release-**
permissions:
contents: read
jobs:
tests:
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@v3
- uses: cachix/install-nix-action@v18
- uses: cachix/cachix-action@v12
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 }}'
# explicit list of supportedSystems is needed until aarch64-darwin becomes part of the trunk jobset
- run: nix-build pkgs/top-level/release.nix -A tarball.nixpkgs-basic-release-checks --arg supportedSystems '[ "aarch64-darwin" "aarch64-linux" "x86_64-linux" "x86_64-darwin" ]'

View File

@@ -1,28 +0,0 @@
name: "Check cherry-picks"
on:
pull_request_target:
branches:
- 'release-**'
- 'staging-**'
- '!staging-next'
permissions: {}
jobs:
check:
name: cherry-pick-check
runs-on: ubuntu-24.04
if: github.repository_owner == 'NixOS'
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
fetch-depth: 0
filter: blob:none
- name: Check cherry-picks
env:
BASE_SHA: ${{ github.event.pull_request.base.sha }}
HEAD_SHA: ${{ github.event.pull_request.head.sha }}
run: |
./maintainers/scripts/check-cherry-picks.sh "$BASE_SHA" "$HEAD_SHA"

View File

@@ -1,28 +0,0 @@
name: "Check that maintainer list is sorted"
on:
pull_request_target:
paths:
- 'maintainers/maintainer-list.nix'
permissions: {}
jobs:
nixos:
name: maintainer-list-check
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: refs/pull/${{ github.event.pull_request.number }}/merge
# Only these directories to perform the check
sparse-checkout: |
lib
maintainers
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
with:
extra_nix_config: sandbox = true
- name: Check that maintainer-list.nix is sorted
run: nix-instantiate --eval maintainers/scripts/check-maintainers-sorted.nix

View File

@@ -1,100 +0,0 @@
# This file was copied mostly from check-maintainers-sorted.yaml.
# NOTE: Formatting with the RFC-style nixfmt command is not yet stable. See
# https://github.com/NixOS/rfcs/pull/166.
# Because of this, this action is not yet enabled for all files -- only for
# those who have opted in.
name: Check that Nix files are formatted
on:
pull_request_target:
types: [opened, synchronize, reopened, edited]
permissions: {}
jobs:
get-merge-commit:
uses: ./.github/workflows/get-merge-commit.yml
nixos:
name: nixfmt-check
runs-on: ubuntu-24.04
needs: get-merge-commit
if: "needs.get-merge-commit.outputs.mergedSha && !contains(github.event.pull_request.title, '[skip treewide]')"
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: ${{ needs.get-merge-commit.outputs.mergedSha }}
# Fetches the merge commit and its parents
fetch-depth: 2
- name: Checking out target branch
run: |
target=$(mktemp -d)
targetRev=$(git rev-parse HEAD^1)
git worktree add "$target" "$targetRev"
echo "targetRev=$targetRev" >> "$GITHUB_ENV"
echo "target=$target" >> "$GITHUB_ENV"
- name: Get Nixpkgs revision for nixfmt
run: |
# pin to a commit from nixpkgs-unstable to avoid e.g. building nixfmt
# from staging
# 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
with:
extra_nix_config: sandbox = true
nix_path: nixpkgs=${{ env.url }}
- name: Install nixfmt
run: "nix-env -f '<nixpkgs>' -iAP nixfmt-rfc-style"
- name: Check that Nix files are formatted according to the RFC style
run: |
unformattedFiles=()
# TODO: Make this more parallel
# Loop through all Nix files touched by the PR
while readarray -d '' -n 2 entry && (( ${#entry[@]} != 0 )); do
type=${entry[0]}
file=${entry[1]}
case $type in
A*)
source=""
dest=$file
;;
M*)
source=$file
dest=$file
;;
C*|R*)
source=$file
read -r -d '' dest
;;
*)
echo "Ignoring file $file with type $type"
continue
esac
# Ignore files that weren't already formatted
if [[ -n "$source" ]] && ! nixfmt --check ${{ env.target }}/"$source" 2>/dev/null; then
echo "Ignoring file $file because it's not formatted in the target commit"
elif ! nixfmt --check "$dest"; then
unformattedFiles+=("$dest")
fi
done < <(git diff -z --name-status ${{ env.targetRev }} -- '*.nix')
if (( "${#unformattedFiles[@]}" > 0 )); then
echo "Some new/changed Nix files are not properly formatted"
echo "Please format them using the Nixpkgs-specific \`nixfmt\` by going to the Nixpkgs root directory, running \`nix-shell\`, then:"
echo
echo "nixfmt ${unformattedFiles[*]@Q}"
echo
echo "Make sure your branch is up to date with master; rebase if not."
echo "If you're having trouble, please ping @NixOS/nix-formatting"
exit 1
fi

View File

@@ -1,132 +0,0 @@
name: Check changed Nix files with nixf-tidy (experimental)
on:
pull_request_target:
types: [opened, synchronize, reopened, edited]
permissions: {}
jobs:
nixos:
name: exp-nixf-tidy-check
runs-on: ubuntu-24.04
if: "!contains(github.event.pull_request.title, '[skip treewide]')"
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: refs/pull/${{ github.event.pull_request.number }}/merge
# Fetches the merge commit and its parents
fetch-depth: 2
- name: Checking out target branch
run: |
target=$(mktemp -d)
targetRev=$(git rev-parse HEAD^1)
git worktree add "$target" "$targetRev"
echo "targetRev=$targetRev" >> "$GITHUB_ENV"
echo "target=$target" >> "$GITHUB_ENV"
- name: Get Nixpkgs revision for nixf
run: |
# pin to a commit from nixpkgs-unstable to avoid e.g. building nixf
# from staging
# 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
with:
extra_nix_config: sandbox = true
nix_path: nixpkgs=${{ env.url }}
- name: Install nixf and jq
# provided jq is incompatible with our expression
run: "nix-env -f '<nixpkgs>' -iAP nixf jq"
- name: Check that Nix files pass nixf-tidy
run: |
# Filtering error messages we don't like
nixf_wrapper(){
nixf-tidy --variable-lookup < "$1" | jq -r '
[
"sema-escaping-with"
]
as $ignored_errors|[.[]|select(.sname as $s|$ignored_errors|index($s)|not)]
'
}
failedFiles=()
# Don't report errors to file overview
# to avoid duplicates when editing title and description
if [[ "${{ github.event.action }}" == 'edited' ]] && [[ -z "${{ github.event.edited.changes.base }}" ]]; then
DONT_REPORT_ERROR=1
else
DONT_REPORT_ERROR=
fi
# TODO: Make this more parallel
# Loop through all Nix files touched by the PR
while readarray -d '' -n 2 entry && (( ${#entry[@]} != 0 )); do
type=${entry[0]}
file=${entry[1]}
case $type in
A*)
source=""
dest=$file
;;
M*)
source=$file
dest=$file
;;
C*|R*)
source=$file
read -r -d '' dest
;;
*)
echo "Ignoring file $file with type $type"
continue
esac
if [[ -n "$source" ]] && [[ "$(nixf_wrapper ${{ env.target }}/"$source")" != '[]' ]] 2>/dev/null; then
echo "Ignoring file $file because it doesn't pass nixf-tidy in the target commit"
echo # insert blank line
else
nixf_report="$(nixf_wrapper "$dest")"
if [[ "$nixf_report" != '[]' ]]; then
echo "$dest doesn't pass nixf-tidy. Reported by nixf-tidy:"
errors=$(echo "$nixf_report" | jq -r --arg dest "$dest" '
def getLCur: "line=" + (.line+1|tostring) + ",col=" + (.column|tostring);
def getRCur: "endLine=" + (.line+1|tostring) + ",endColumn=" + (.column|tostring);
def getRange: "file=\($dest)," + (.lCur|getLCur) + "," + (.rCur|getRCur);
def getBody: . as $top|(.range|getRange) + ",title="+ .sname + "::" +
(.message|sub("{}" ; ($top.args.[]|tostring)));
def getNote: "\n::notice " + (.|getBody);
def getMessage: "::error " + (.|getBody) + (if (.notes|length)>0 then
([.notes.[]|getNote]|add) else "" end);
.[]|getMessage
')
if [[ -z "$DONT_REPORT_ERROR" ]]; then
echo "$errors"
else
# just print in plain text
echo "${errors/::/}"
echo # add one empty line
fi
failedFiles+=("$dest")
fi
fi
done < <(git diff -z --name-status ${{ env.targetRev }} -- '*.nix')
if [[ -n "$DONT_REPORT_ERROR" ]]; then
echo "Edited the PR but didn't change the base branch, only the description/title."
echo "Not reporting errors again to avoid duplication."
echo # add one empty line
fi
if (( "${#failedFiles[@]}" > 0 )); then
echo "Some new/changed Nix files don't pass nixf-tidy."
echo "See ${{ github.event.pull_request.html_url }}/files for reported errors."
echo "If you believe this is a false positive, ping @Aleksanaa and @inclyc in this PR."
exit 1
fi

View File

@@ -1,33 +0,0 @@
name: "Check shell"
on:
pull_request_target:
paths:
- 'shell.nix'
- 'ci/**'
permissions: {}
jobs:
shell-check:
strategy:
fail-fast: false
matrix:
include:
- runner: ubuntu-24.04
system: x86_64-linux
- runner: macos-14
system: aarch64-darwin
name: shell-check-${{ matrix.system }}
runs-on: ${{ matrix.runner }}
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
- name: Build shell
run: nix-build shell.nix

View File

@@ -1,111 +0,0 @@
# 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.
#
# Note that the latter is also used for ./eval.yml requesting reviewers.
name: Codeowners v2
on:
pull_request_target:
types: [opened, ready_for_review, synchronize, reopened, edited]
permissions: {}
env:
OWNERS_FILE: ci/OWNERS
# Don't do anything on draft PRs
DRY_MODE: ${{ github.event.pull_request.draft && '1' || '' }}
jobs:
get-merge-commit:
if: github.repository_owner == 'NixOS'
uses: ./.github/workflows/get-merge-commit.yml
# Check that code owners is valid
check:
name: Check
runs-on: ubuntu-24.04
needs: get-merge-commit
if: github.repository_owner == 'NixOS' && needs.get-merge-commit.outputs.mergedSha
steps:
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
- 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 }}'
# 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@67e27a7eb7db372a1c61a7f9bdab8699e9ee57f7 # v1.11.3
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: ${{ needs.get-merge-commit.outputs.mergedSha }}
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-24.04
if: github.repository_owner == 'NixOS'
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@67e27a7eb7db372a1c61a7f9bdab8699e9ee57f7 # v1.11.3
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-code-owner-reviews.sh ${{ github.repository }} ${{ github.event.number }} "$OWNERS_FILE"
env:
GH_TOKEN: ${{ steps.app-token.outputs.token }}

21
.github/workflows/compare-manuals.sh vendored Executable file
View File

@@ -0,0 +1,21 @@
#!/usr/bin/env nix-shell
#! nix-shell -i bash -p html-tidy
set -euo pipefail
shopt -s inherit_errexit
normalize() {
tidy \
--anchor-as-name no \
--coerce-endtags no \
--escape-scripts no \
--fix-backslash no \
--fix-style-tags no \
--fix-uri no \
--indent yes \
--wrap 0 \
< "$1" \
2> /dev/null
}
diff -U3 <(normalize "$1") <(normalize "$2")

37
.github/workflows/direct-push.yml vendored Normal file
View File

@@ -0,0 +1,37 @@
name: "Direct Push Warning"
on:
push:
branches:
- master
- release-**
permissions:
contents: read
jobs:
build:
permissions:
contents: write # for peter-evans/commit-comment to comment on commit
runs-on: ubuntu-latest
if: github.repository_owner == 'NixOS'
env:
GITHUB_SHA: ${{ github.sha }}
GITHUB_REPOSITORY: ${{ github.repository }}
steps:
- name: Check if commit is a merge commit
id: ismerge
run: |
ISMERGE=$(curl -H 'Accept: application/vnd.github.groot-preview+json' -H "authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" https://api.github.com/repos/${{ env.GITHUB_REPOSITORY }}/commits/${{ env.GITHUB_SHA }}/pulls | jq -r '.[] | select(.merge_commit_sha == "${{ env.GITHUB_SHA }}") | any')
echo "ismerge=$ISMERGE" >> $GITHUB_OUTPUT
# github events are eventually consistent, so wait until changes propagate to thier DB
- run: sleep 60
if: steps.ismerge.outputs.ismerge != 'true'
- name: Warn if the commit was a direct push
if: steps.ismerge.outputs.ismerge != 'true'
uses: peter-evans/commit-comment@v2
with:
body: |
@${{ github.actor }}, you pushed a commit directly to master/release branch
instead of going through a Pull Request.
That's highly discouraged beyond the few exceptions listed
on https://github.com/NixOS/nixpkgs/issues/118661

View File

@@ -1,47 +0,0 @@
name: "Checking EditorConfig v2"
on:
pull_request_target:
permissions: {}
jobs:
get-merge-commit:
uses: ./.github/workflows/get-merge-commit.yml
tests:
name: editorconfig-check
runs-on: ubuntu-24.04
needs: get-merge-commit
if: "needs.get-merge-commit.outputs.mergedSha && !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/${{ github.repository }}/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:
ref: ${{ needs.get-merge-commit.outputs.mergedSha }}
- 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: |
< "$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."

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

@@ -0,0 +1,43 @@
name: "Checking EditorConfig"
permissions: read-all
on:
# avoids approving first time contributors
pull_request_target:
branches-ignore:
- 'release-**'
jobs:
tests:
runs-on: ubuntu-latest
if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip editorconfig]')"
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@v3
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@v18
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: install editorconfig-checker
run: nix-env -iA editorconfig-checker -f '<nixpkgs>'
- name: Checking EditorConfig
run: |
cat "$HOME/changed_files" | 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,30 +0,0 @@
name: "Building Nixpkgs lib-tests"
on:
pull_request_target:
paths:
- 'lib/**'
permissions: {}
jobs:
get-merge-commit:
uses: ./.github/workflows/get-merge-commit.yml
nixpkgs-lib-tests:
name: nixpkgs-lib-tests
runs-on: ubuntu-24.04
needs: get-merge-commit
if: needs.get-merge-commit.outputs.mergedSha
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: ${{ needs.get-merge-commit.outputs.mergedSha }}
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
with:
extra_nix_config: sandbox = true
- name: Building Nixpkgs lib-tests
run: |
nix-build --arg pkgs "(import ./ci/. {}).pkgs" ./lib/tests/release.nix

View File

@@ -1,339 +0,0 @@
name: Eval
on:
pull_request_target:
types: [opened, ready_for_review, synchronize, reopened]
push:
# Keep this synced with ci/request-reviews/dev-branches.txt
branches:
- master
- staging
- release-*
- staging-*
- haskell-updates
- python-updates
permissions: {}
jobs:
get-merge-commit:
uses: ./.github/workflows/get-merge-commit.yml
attrs:
name: Attributes
runs-on: ubuntu-24.04
needs: get-merge-commit
if: needs.get-merge-commit.outputs.mergedSha
outputs:
targetSha: ${{ steps.targetSha.outputs.targetSha }}
systems: ${{ steps.systems.outputs.systems }}
steps:
- name: Check out the PR at the test merge commit
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: ${{ needs.get-merge-commit.outputs.mergedSha }}
fetch-depth: 2
path: nixpkgs
- name: Determine target commit
if: github.event_name == 'pull_request_target'
id: targetSha
run: |
targetSha=$(git -C nixpkgs rev-parse HEAD^1)
echo "targetSha=$targetSha" >> "$GITHUB_OUTPUT"
- name: Install Nix
uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
with:
extra_nix_config: sandbox = true
- name: Evaluate the list of all attributes and get the systems matrix
id: systems
run: |
nix-build nixpkgs/ci -A eval.attrpathsSuperset
echo "systems=$(<result/systems.json)" >> "$GITHUB_OUTPUT"
- name: Upload the list of all attributes
uses: actions/upload-artifact@65c4c4a1ddee5b72f698fdd19549f0f0fb45cf08 # v4.6.0
with:
name: paths
path: result/*
eval-aliases:
name: Eval nixpkgs with aliases enabled
runs-on: ubuntu-24.04
needs: [ get-merge-commit ]
steps:
- name: Check out the PR at the test merge commit
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: ${{ needs.get-merge-commit.outputs.mergedSha }}
path: nixpkgs
- name: Install Nix
uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
with:
extra_nix_config: sandbox = true
- name: Query nixpkgs with aliases enabled to check for basic syntax errors
run: |
time nix-env -I ./nixpkgs -f ./nixpkgs -qa '*' --option restrict-eval true --option allow-import-from-derivation false >/dev/null
outpaths:
name: Outpaths
runs-on: ubuntu-24.04
needs: [ attrs, get-merge-commit ]
strategy:
fail-fast: false
matrix:
system: ${{ fromJSON(needs.attrs.outputs.systems) }}
steps:
- name: Enable swap
run: |
sudo fallocate -l 10G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
- name: Download the list of all attributes
uses: actions/download-artifact@fa0a91b85d4f404e444e00e005971372dc801d16 # v4.1.8
with:
name: paths
path: paths
- name: Check out the PR at the test merge commit
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: ${{ needs.get-merge-commit.outputs.mergedSha }}
path: nixpkgs
- name: Install Nix
uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
with:
extra_nix_config: sandbox = true
- name: Evaluate the ${{ matrix.system }} output paths for all derivation attributes
env:
MATRIX_SYSTEM: ${{ matrix.system }}
run: |
nix-build nixpkgs/ci -A eval.singleSystem \
--argstr evalSystem "$MATRIX_SYSTEM" \
--arg attrpathFile ./paths/paths.json \
--arg chunkSize 10000
# If it uses too much memory, slightly decrease chunkSize
- name: Upload the output paths and eval stats
uses: actions/upload-artifact@65c4c4a1ddee5b72f698fdd19549f0f0fb45cf08 # v4.6.0
with:
name: intermediate-${{ matrix.system }}
path: result/*
process:
name: Process
runs-on: ubuntu-24.04
needs: [ outpaths, attrs, get-merge-commit ]
outputs:
targetRunId: ${{ steps.targetRunId.outputs.targetRunId }}
steps:
- name: Download output paths and eval stats for all systems
uses: actions/download-artifact@fa0a91b85d4f404e444e00e005971372dc801d16 # v4.1.8
with:
pattern: intermediate-*
path: intermediate
- name: Check out the PR at the test merge commit
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: ${{ needs.get-merge-commit.outputs.mergedSha }}
fetch-depth: 2
path: nixpkgs
- name: Install Nix
uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
with:
extra_nix_config: sandbox = true
- name: Combine all output paths and eval stats
run: |
nix-build nixpkgs/ci -A eval.combine \
--arg resultsDir ./intermediate \
-o prResult
- name: Upload the combined results
uses: actions/upload-artifact@65c4c4a1ddee5b72f698fdd19549f0f0fb45cf08 # v4.6.0
with:
name: result
path: prResult/*
- name: Get target run id
if: needs.attrs.outputs.targetSha
id: targetRunId
run: |
# Get the latest eval.yml workflow run for the PR's target commit
if ! run=$(gh api --method GET /repos/"$REPOSITORY"/actions/workflows/eval.yml/runs \
-f head_sha="$TARGET_SHA" -f event=push \
--jq '.workflow_runs | sort_by(.run_started_at) | .[-1]') \
|| [[ -z "$run" ]]; then
echo "Could not find an eval.yml workflow run for $TARGET_SHA, cannot make comparison"
exit 1
fi
echo "Comparing against $(jq .html_url <<< "$run")"
runId=$(jq .id <<< "$run")
conclusion=$(jq -r .conclusion <<< "$run")
while [[ "$conclusion" == null || "$conclusion" == "" ]]; do
echo "Workflow not done, waiting 10 seconds before checking again"
sleep 10
conclusion=$(gh api /repos/"$REPOSITORY"/actions/runs/"$runId" --jq '.conclusion')
done
if [[ "$conclusion" != "success" ]]; then
echo "Workflow was not successful (conclusion: $conclusion), cannot make comparison"
exit 1
fi
echo "targetRunId=$runId" >> "$GITHUB_OUTPUT"
env:
REPOSITORY: ${{ github.repository }}
TARGET_SHA: ${{ needs.attrs.outputs.targetSha }}
GH_TOKEN: ${{ github.token }}
- uses: actions/download-artifact@v4
if: steps.targetRunId.outputs.targetRunId
with:
name: result
path: targetResult
github-token: ${{ github.token }}
run-id: ${{ steps.targetRunId.outputs.targetRunId }}
- name: Compare against the target branch
if: steps.targetRunId.outputs.targetRunId
run: |
git -C nixpkgs worktree add ../target ${{ needs.attrs.outputs.targetSha }}
git -C nixpkgs diff --name-only ${{ needs.attrs.outputs.targetSha }} \
| jq --raw-input --slurp 'split("\n")[:-1]' > touched-files.json
# Use the target branch to get accurate maintainer info
nix-build target/ci -A eval.compare \
--arg beforeResultDir ./targetResult \
--arg afterResultDir ./prResult \
--arg touchedFilesJson ./touched-files.json \
-o comparison
cat comparison/step-summary.md >> "$GITHUB_STEP_SUMMARY"
- name: Upload the combined results
if: steps.targetRunId.outputs.targetRunId
uses: actions/upload-artifact@65c4c4a1ddee5b72f698fdd19549f0f0fb45cf08 # v4.6.0
with:
name: comparison
path: comparison/*
# Separate job to have a very tightly scoped PR write token
tag:
name: Tag
runs-on: ubuntu-24.04
needs: [ attrs, process ]
if: needs.process.outputs.targetRunId
permissions:
pull-requests: write
statuses: write
steps:
# See ./codeowners-v2.yml, reuse the same App because we need the same permissions
# Can't use the token received from permissions above, because it can't get enough permissions
- uses: actions/create-github-app-token@67e27a7eb7db372a1c61a7f9bdab8699e9ee57f7 # v1.11.3
id: app-token
with:
app-id: ${{ vars.OWNER_APP_ID }}
private-key: ${{ secrets.OWNER_APP_PRIVATE_KEY }}
- name: Download process result
uses: actions/download-artifact@fa0a91b85d4f404e444e00e005971372dc801d16 # v4.1.8
with:
name: comparison
path: comparison
- name: Install Nix
uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
# Important: This workflow job runs with extra permissions,
# so we need to make sure to not run untrusted code from PRs
- name: Check out Nixpkgs at the base commit
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: ${{ needs.attrs.outputs.targetSha }}
path: base
sparse-checkout: ci
- name: Build the requestReviews derivation
run: nix-build base/ci -A requestReviews
- name: Labelling pull request
run: |
# Get all currently set rebuild labels
gh api \
/repos/"$REPOSITORY"/issues/"$NUMBER"/labels \
--jq '.[].name | select(startswith("10.rebuild"))' \
| sort > before
# And the labels that should be there
jq -r '.labels[]' comparison/changed-paths.json \
| sort > after
# Remove the ones not needed anymore
while read -r toRemove; do
echo "Removing label $toRemove"
gh api \
--method DELETE \
/repos/"$REPOSITORY"/issues/"$NUMBER"/labels/"$toRemove"
done < <(comm -23 before after)
# And add the ones that aren't set already
while read -r toAdd; do
echo "Adding label $toAdd"
gh api \
--method POST \
/repos/"$REPOSITORY"/issues/"$NUMBER"/labels \
-f "labels[]=$toAdd"
done < <(comm -13 before after)
env:
GH_TOKEN: ${{ github.token }}
REPOSITORY: ${{ github.repository }}
NUMBER: ${{ github.event.number }}
- name: Add eval summary to commit statuses
if: ${{ github.event_name == 'pull_request_target' }}
run: |
description=$(jq -r '
"Package: added " + (.attrdiff.added | length | tostring) +
", removed " + (.attrdiff.removed | length | tostring) +
", changed " + (.attrdiff.changed | length | tostring) +
", Rebuild: linux " + (.rebuildCountByKernel.linux | tostring) +
", darwin " + (.rebuildCountByKernel.darwin | tostring)
' <comparison/changed-paths.json)
target_url="$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID?pr=$NUMBER"
gh api --method POST \
-H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" \
"/repos/$GITHUB_REPOSITORY/statuses/$PR_HEAD_SHA" \
-f "context=Eval / Summary" -f "state=success" -f "description=$description" -f "target_url=$target_url"
env:
GH_TOKEN: ${{ github.token }}
PR_HEAD_SHA: ${{ github.event.pull_request.head.sha }}
NUMBER: ${{ github.event.number }}
- name: Requesting maintainer reviews
run: |
# maintainers.json contains GitHub IDs. Look up handles to request reviews from.
# There appears to be no API to request reviews based on GitHub IDs
jq -r 'keys[]' comparison/maintainers.json \
| while read -r id; do gh api /user/"$id" --jq .login; done \
| GH_TOKEN=${{ steps.app-token.outputs.token }} result/bin/request-reviewers.sh "$REPOSITORY" "$NUMBER" "$AUTHOR"
env:
GH_TOKEN: ${{ github.token }}
REPOSITORY: ${{ github.repository }}
NUMBER: ${{ github.event.number }}
AUTHOR: ${{ github.event.pull_request.user.login }}
# Don't request reviewers on draft PRs
DRY_MODE: ${{ github.event.pull_request.draft && '1' || '' }}

View File

@@ -1,43 +0,0 @@
name: Get merge commit
on:
workflow_call:
outputs:
mergedSha:
description: "The merge commit SHA"
value: ${{ jobs.resolve-merge-commit.outputs.mergedSha }}
permissions: {}
jobs:
resolve-merge-commit:
runs-on: ubuntu-24.04
outputs:
mergedSha: ${{ steps.merged.outputs.mergedSha }}
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
path: base
sparse-checkout: ci
- name: Check if the PR can be merged and get the test merge commit
id: merged
env:
GH_TOKEN: ${{ github.token }}
GH_EVENT: ${{ github.event_name }}
run: |
case "$GH_EVENT" in
push)
echo "mergedSha=${{ github.sha }}" >> "$GITHUB_OUTPUT"
;;
pull_request_target)
if mergedSha=$(base/ci/get-merge-commit.sh ${{ github.repository }} ${{ github.event.number }}); then
echo "Checking the merge commit $mergedSha"
echo "mergedSha=$mergedSha" >> "$GITHUB_OUTPUT"
else
# Skipping so that no notifications are sent
echo "Skipping the rest..."
fi
;;
esac
rm -rf base

View File

@@ -1,31 +1,24 @@
# WARNING:
# When extending this action, be aware that $GITHUB_TOKEN allows some write
# access to the GitHub API. This means that it should not evaluate user input in
# a way that allows code injection.
name: "Label PR"
on:
pull_request_target:
types: [edited, opened, synchronize, reopened]
# WARNING:
# When extending this action, be aware that $GITHUB_TOKEN allows some write
# access to the GitHub API. This means that it should not evaluate user input in
# a way that allows code injection.
permissions:
contents: read
pull-requests: write
jobs:
labels:
name: label-pr
runs-on: ubuntu-24.04
if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
runs-on: ubuntu-latest
if: github.repository_owner == 'NixOS'
steps:
- uses: actions/labeler@8558fd74291d67161a8a78ce36a881fa63b766a9 # v5.0.0
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
configuration-path: .github/labeler.yml # default
sync-labels: true
- uses: actions/labeler@8558fd74291d67161a8a78ce36a881fa63b766a9 # v5.0.0
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
configuration-path: .github/labeler-no-sync.yml
sync-labels: false
- uses: actions/labeler@v4
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
sync-labels: true

View File

@@ -1,7 +0,0 @@
#!/usr/bin/env nix-shell
#!nix-shell -i bash -p bash actionlint shellcheck -I nixpkgs=../..
set -euo pipefail
SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )"
cd "$SCRIPT_DIR/../.."
actionlint

View File

@@ -1,33 +0,0 @@
name: "Build NixOS manual v2"
on:
pull_request_target:
branches:
- master
paths:
- 'nixos/**'
permissions: {}
jobs:
nixos:
name: nixos-manual-build
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
with:
extra_nix_config: sandbox = true
- 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 }}'
- name: Building NixOS manual
run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true nixos/release.nix -A manual.x86_64-linux

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

@@ -0,0 +1,39 @@
name: "Build NixOS manual"
permissions: read-all
on:
pull_request_target:
branches:
- master
paths:
- 'nixos/**'
jobs:
nixos:
runs-on: ubuntu-latest
if: github.repository_owner == 'NixOS'
steps:
- uses: actions/checkout@v3
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@v18
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true
- uses: cachix/cachix-action@v12
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 }}'
- name: Building NixOS manual with DocBook options
run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true nixos/release.nix -A manual.x86_64-linux
- name: Building NixOS manual with Markdown options
run: |
export NIX_PATH=nixpkgs=$(pwd)
nix-build \
--option restrict-eval true \
--arg configuration '{ documentation.nixos.options.allowDocBook = false; }' \
nixos/release.nix \
-A manual.x86_64-linux

View File

@@ -1,35 +0,0 @@
name: "Build Nixpkgs manual v2"
on:
pull_request_target:
branches:
- master
paths:
- 'doc/**'
- 'lib/**'
- 'pkgs/tools/nix/nixdoc/**'
permissions: {}
jobs:
nixpkgs:
name: nixpkgs-manual-build
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
with:
extra_nix_config: sandbox = true
- 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 }}'
- 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

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

@@ -0,0 +1,31 @@
name: "Build Nixpkgs manual"
permissions: read-all
on:
pull_request_target:
branches:
- master
paths:
- 'doc/**'
jobs:
nixpkgs:
runs-on: ubuntu-latest
if: github.repository_owner == 'NixOS'
steps:
- uses: actions/checkout@v3
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@v18
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true
- uses: cachix/cachix-action@v12
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 }}'
- name: Building Nixpkgs manual
run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true pkgs/top-level/release.nix -A manual

64
.github/workflows/manual-rendering.yml vendored Normal file
View File

@@ -0,0 +1,64 @@
name: "Check NixOS Manual DocBook rendering against MD rendering"
on:
schedule:
# * is a special character in YAML so you have to quote this string
# Check every 24 hours
- cron: '0 0 * * *'
permissions:
contents: read
jobs:
check-rendering-equivalence:
permissions:
pull-requests: write # for peter-evans/create-or-update-comment to create or update comment
if: github.repository_owner == 'NixOS'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: cachix/install-nix-action@v18
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true
- uses: cachix/cachix-action@v12
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 }}'
- name: Build DocBook and MD manuals
run: |
export NIX_PATH=nixpkgs=$(pwd)
nix-build \
--option restrict-eval true \
-o docbook nixos/release.nix \
-A manual.x86_64-linux
nix-build \
--option restrict-eval true \
--arg configuration '{ documentation.nixos.options.allowDocBook = false; }' \
-o md nixos/release.nix \
-A manual.x86_64-linux
- name: Compare DocBook and MD manuals
id: check
run: |
export NIX_PATH=nixpkgs=$(pwd)
.github/workflows/compare-manuals.sh \
docbook/share/doc/nixos/options.html \
md/share/doc/nixos/options.html
# if the manual can't be built we don't want to notify anyone.
# while this may temporarily hide rendering failures it will be a lot
# less noisy until all nixpkgs pull requests have stopped using
# docbook for option docs.
- name: Comment on failure
uses: peter-evans/create-or-update-comment@v2
if: ${{ failure() && steps.check.conclusion == 'failure' }}
with:
issue-number: 189318
body: |
Markdown and DocBook manuals do not agree.
Check https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }} for details.

View File

@@ -1,47 +0,0 @@
name: "Check whether nix files are parseable v2"
on:
pull_request_target:
permissions: {}
jobs:
get-merge-commit:
uses: ./.github/workflows/get-merge-commit.yml
tests:
name: nix-files-parseable-check
runs-on: ubuntu-24.04
needs: get-merge-commit
if: "needs.get-merge-commit.outputs.mergedSha && !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/${{ github.repository }}/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:
ref: ${{ needs.get-merge-commit.outputs.mergedSha }}
if: ${{ env.CHANGED_FILES && env.CHANGED_FILES != '' }}
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
with:
extra_nix_config: sandbox = true
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 != '' }}

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

@@ -0,0 +1,34 @@
name: NixOS manual checks
permissions: read-all
on:
pull_request_target:
branches-ignore:
- 'release-**'
paths:
- 'nixos/**/*.xml'
- 'nixos/**/*.md'
jobs:
tests:
runs-on: ubuntu-latest
if: github.repository_owner == 'NixOS'
steps:
- uses: actions/checkout@v3
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@v18
- name: Check DocBook files generated from Markdown are consistent
run: |
nixos/doc/manual/md-to-db.sh
git diff --exit-code || {
echo
echo 'Generated manual files are out of date.'
echo 'Please run'
echo
echo ' nixos/doc/manual/md-to-db.sh'
echo
exit 1
}

View File

@@ -1,73 +0,0 @@
# `nixpkgs-vet` is a tool to vet Nixpkgs: its architecture, package structure, and more.
# Among other checks, it makes sure that `pkgs/by-name` (see `../../pkgs/by-name/README.md`) follows the validity rules outlined in [RFC 140](https://github.com/NixOS/rfcs/pull/140).
# When you make changes to this workflow, please also update `ci/nixpkgs-vet.sh` to reflect the impact of your work to the CI.
# See https://github.com/NixOS/nixpkgs-vet for details on the tool and its checks.
name: Vet nixpkgs
on:
pull_request_target:
# This workflow depends on the base branch of the PR, but changing the base branch is not included in the default trigger events, which would be `opened`, `synchronize` or `reopened`.
# Instead it causes an `edited` event, so we need to add it explicitly here.
# While `edited` is also triggered when the PR title/body is changed, this PR action is fairly quick, and PRs don't get edited **that** often, so it shouldn't be a problem.
# There is a feature request for adding a `base_changed` event: https://github.com/orgs/community/discussions/35058
types: [opened, synchronize, reopened, edited]
permissions: {}
# We don't use a concurrency group here, because the action is triggered quite often (due to the PR edit trigger), and contributors would get notified on any canceled run.
# There is a feature request for suppressing notifications on concurrency-canceled runs: https://github.com/orgs/community/discussions/13015
jobs:
get-merge-commit:
uses: ./.github/workflows/get-merge-commit.yml
check:
name: nixpkgs-vet
# This needs to be x86_64-linux, because we depend on the tooling being pre-built in the GitHub releases.
runs-on: ubuntu-24.04
# This should take 1 minute at most, but let's be generous. The default of 6 hours is definitely too long.
timeout-minutes: 10
needs: get-merge-commit
if: needs.get-merge-commit.outputs.mergedSha
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: ${{ needs.get-merge-commit.outputs.mergedSha }}
# Fetches the merge commit and its parents
fetch-depth: 2
- name: Checking out target branch
run: |
target=$(mktemp -d)
git worktree add "$target" "$(git rev-parse HEAD^1)"
echo "target=$target" >> "$GITHUB_ENV"
- uses: cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72 # v30
- name: Fetching the pinned tool
# Update the pinned version using ci/nixpkgs-vet/update-pinned-tool.sh
run: |
# The pinned version of the tooling to use.
toolVersion=$(<ci/nixpkgs-vet/pinned-version.txt)
# Fetch the x86_64-linux-specific release artifact containing the gzipped NAR of the pre-built tool.
toolPath=$(curl -sSfL https://github.com/NixOS/nixpkgs-vet/releases/download/"$toolVersion"/x86_64-linux.nar.gz \
| gzip -cd | nix-store --import | tail -1)
# Adds a result symlink as a GC root.
nix-store --realise "$toolPath" --add-root result
- name: Running nixpkgs-vet
env:
# Force terminal colors to be enabled. The library that `nixpkgs-vet` uses respects https://bixense.com/clicolors/
CLICOLOR_FORCE: 1
run: |
if result/bin/nixpkgs-vet --base "$target" .; then
exit 0
else
exitCode=$?
echo "To run locally: ./ci/nixpkgs-vet.sh $GITHUB_BASE_REF https://github.com/$GITHUB_REPOSITORY.git"
echo "If you're having trouble, ping @NixOS/nixpkgs-vet"
exit "$exitCode"
fi

View File

@@ -1,25 +1,26 @@
name: "No channel PR"
on:
pull_request_target:
# Re-run should be triggered when the base branch is updated, instead of silently failing
types: [opened, synchronize, reopened, edited]
pull_request:
branches:
- 'nixos-**'
- 'nixpkgs-**'
permissions: {}
permissions:
contents: read
jobs:
fail:
permissions:
contents: none
name: "This PR is is targeting a channel branch"
runs-on: ubuntu-24.04
runs-on: ubuntu-latest
steps:
- run: |
cat <<EOF
The nixos-* and nixpkgs-* branches are pushed to by the channel
release script and should not be merged into directly.
- run: |
cat <<EOF
The nixos-* and nixpkgs-* branches are pushed to by the channel
release script and should not be merged into directly.
Please target the equivalent release-* branch or master instead.
EOF
exit 1
Please target the equivalent release-* branch or master instead.
EOF
exit 1

33
.github/workflows/ofborg-pending.yml vendored Normal file
View File

@@ -0,0 +1,33 @@
name: "Set pending OfBorg status"
on:
pull_request_target:
# Sets the ofborg-eval status to "pending" to signal that we are waiting for
# OfBorg even if it is running late. The status will be overwritten by OfBorg
# once it starts evaluation.
# WARNING:
# When extending this action, be aware that $GITHUB_TOKEN allows (restricted) write access to
# the GitHub repository. This means that it should not evaluate user input in a
# way that allows code injection.
permissions:
contents: read
jobs:
action:
if: github.repository_owner == 'NixOS'
permissions:
statuses: write
runs-on: ubuntu-latest
steps:
- name: "Set pending OfBorg status"
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
curl \
-X POST \
-H "Accept: application/vnd.github.v3+json" \
-H "Authorization: Bearer $GITHUB_TOKEN" \
-d '{"context": "ofborg-eval", "state": "pending", "description": "Waiting for OfBorg..."}' \
"https://api.github.com/repos/NixOS/nixpkgs/commits/${{ github.event.pull_request.head.sha }}/statuses"

View File

@@ -7,18 +7,23 @@
name: "Periodic Merges (24h)"
on:
schedule:
# * is a special character in YAML so you have to quote this string
# Merge every 24 hours
- cron: '0 0 * * *'
workflow_dispatch:
permissions: {}
permissions:
contents: read
jobs:
periodic-merge:
permissions:
contents: write # for devmasx/merge-branch to merge branches
pull-requests: write # for peter-evans/create-or-update-comment to create or update comment
if: github.repository_owner == 'NixOS'
runs-on: ubuntu-latest
strategy:
# don't fail fast, so that all pairs are tried
fail-fast: false
@@ -27,14 +32,32 @@ jobs:
max-parallel: 1
matrix:
pairs:
- from: release-24.11
into: staging-next-24.11
- from: staging-next-24.11
into: staging-24.11
- from: master staging
- from: master
into: haskell-updates
uses: ./.github/workflows/periodic-merge.yml
with:
from: ${{ matrix.pairs.from }}
into: ${{ matrix.pairs.into }}
secrets: inherit
- from: release-22.11
into: staging-next-22.11
- from: staging-next-22.11
into: staging-22.11
- from: release-22.05
into: staging-next-22.05
- from: staging-next-22.05
into: staging-22.05
name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
steps:
- uses: actions/checkout@v3
- name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
uses: devmasx/merge-branch@1.4.0
with:
type: now
from_branch: ${{ matrix.pairs.from }}
target_branch: ${{ matrix.pairs.into }}
github_token: ${{ secrets.GITHUB_TOKEN }}
- name: Comment on failure
uses: peter-evans/create-or-update-comment@v2
if: ${{ failure() }}
with:
issue-number: 105153
body: |
Periodic merge from `${{ matrix.pairs.from }}` into `${{ matrix.pairs.into }}` has [failed](https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}).

View File

@@ -7,18 +7,23 @@
name: "Periodic Merges (6h)"
on:
schedule:
# * is a special character in YAML so you have to quote this string
# Merge every 6 hours
- cron: '0 */6 * * *'
workflow_dispatch:
permissions: {}
permissions:
contents: read
jobs:
periodic-merge:
permissions:
contents: write # for devmasx/merge-branch to merge branches
pull-requests: write # for peter-evans/create-or-update-comment to create or update comment
if: github.repository_owner == 'NixOS'
runs-on: ubuntu-latest
strategy:
# don't fail fast, so that all pairs are tried
fail-fast: false
@@ -31,8 +36,22 @@ jobs:
into: staging-next
- from: staging-next
into: staging
uses: ./.github/workflows/periodic-merge.yml
with:
from: ${{ matrix.pairs.from }}
into: ${{ matrix.pairs.into }}
secrets: inherit
name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
steps:
- uses: actions/checkout@v3
- name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
uses: devmasx/merge-branch@1.4.0
with:
type: now
from_branch: ${{ matrix.pairs.from }}
target_branch: ${{ matrix.pairs.into }}
github_token: ${{ secrets.GITHUB_TOKEN }}
- name: Comment on failure
uses: peter-evans/create-or-update-comment@v2
if: ${{ failure() }}
with:
issue-number: 105153
body: |
Periodic merge from `${{ matrix.pairs.from }}` into `${{ matrix.pairs.into }}` has [failed](https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}).

View File

@@ -1,58 +0,0 @@
name: "Merge"
on:
workflow_call:
inputs:
from:
description: Branch to merge into target branch. Can also be two branches separated by space to find the merge base between them.
required: true
type: string
into:
description: Target branch to merge into.
required: true
type: string
jobs:
merge:
runs-on: ubuntu-24.04
name: ${{ inputs.from }} → ${{ inputs.into }}
steps:
# Use a GitHub App to create the PR so that CI gets triggered
# The App is scoped to Repository > Contents and Pull Requests: write for Nixpkgs
- uses: actions/create-github-app-token@67e27a7eb7db372a1c61a7f9bdab8699e9ee57f7 # v1.11.3
id: app-token
with:
app-id: ${{ vars.NIXPKGS_CI_APP_ID }}
private-key: ${{ secrets.NIXPKGS_CI_APP_PRIVATE_KEY }}
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- name: Find merge base between two branches
if: contains(inputs.from, ' ')
id: merge_base
env:
branches: ${{ inputs.from }}
run: |
# turn into bash array, split on space
read -ra branches <<< "$branches"
git fetch --shallow-since="1 month ago" origin "${branches[@]}"
merge_base="$(git merge-base "refs/remotes/origin/${branches[0]}" "refs/remotes/origin/${branches[1]}")"
echo "Found merge base: $merge_base" >&2
echo "merge_base=$merge_base" >> "$GITHUB_OUTPUT"
- name: ${{ inputs.from }} → ${{ inputs.into }}
uses: devmasx/merge-branch@854d3ac71ed1e9deb668e0074781b81fdd6e771f # 1.4.0
with:
type: now
from_branch: ${{ steps.merge_base.outputs.merge_base || inputs.from }}
target_branch: ${{ inputs.into }}
github_token: ${{ steps.app-token.outputs.token }}
- name: Comment on failure
uses: peter-evans/create-or-update-comment@71345be0265236311c031f5c7866368bd1eff043 # v4.0.0
if: ${{ failure() }}
with:
issue-number: 105153
body: |
Periodic merge from `${{ inputs.from }}` into `${{ inputs.into }}` has [failed](https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}).
token: ${{ steps.app-token.outputs.token }}

View File

@@ -0,0 +1,55 @@
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, for peter-evans/create-or-update-comment to create or update comment
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@v3
- uses: cachix/install-nix-action@v18
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
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: clean repo
run: |
git clean -f
- name: create PR
uses: peter-evans/create-pull-request@v4
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 }}
Check that all providers build with:
```
@ofborg build terraform.full
```
branch: terraform-providers-update
delete-branch: false
title: ${{ steps.setup.outputs.title }}
token: ${{ secrets.GITHUB_TOKEN }}

8
.gitignore vendored
View File

@@ -5,23 +5,18 @@
.\#*
\#*\#
.idea/
.nixos-test-history
.vscode/
.helix/
outputs/
result-*
result
repl-result-*
tags
!pkgs/development/python-modules/result
/doc/NEWS.html
/doc/NEWS.txt
/doc/manual.html
/doc/manual.pdf
/result
/source/
.version-suffix
.direnv
.envrc
.DS_Store
.mypy_cache
@@ -33,7 +28,6 @@ __pycache__
# generated by pkgs/common-updater/update-script.nix
update-git-commits.txt
/*.log
# JetBrains IDEA module declaration file
/nixpkgs.iml

View File

@@ -1,30 +1,14 @@
ajs124 <git@ajs124.de> <ajs124@users.noreply.github.com>
Anderson Torres <torres.anderson.85@protonmail.com>
Atemu <git@atemu.net> <atemu.main@gmail.com>
Christina Sørensen <christina@cafkafk.com>
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>
jopejoe1 <nixpkgs@missing.ninja>
jopejoe1 <nixpkgs@missing.ninja> <johannes@joens.email>
jopejoe1 <nixpkgs@missing.ninja> <34899572+jopejoe1@users.noreply.github.com>
Jörg Thalheim <joerg@thalheim.io> <Mic92@users.noreply.github.com>
Lin Jian <me@linj.tech> <linj.dev@outlook.com>
Lin Jian <me@linj.tech> <75130626+jian-lin@users.noreply.github.com>
Martin Weinelt <hexa@darmstadt.ccc.de> <mweinelt@users.noreply.github.com>
moni <lythe1107@gmail.com> <lythe1107@icloud.com>
R. RyanTM <ryantm-bot@ryantm.com>
Robert Hensing <robert@roberthensing.nl> <roberth@users.noreply.github.com>
Sandro Jäckel <sandro.jaeckel@gmail.com>
Sandro Jäckel <sandro.jaeckel@gmail.com> <sandro.jaeckel@sap.com>
superherointj <5861043+superherointj@users.noreply.github.com>
Tomodachi94 <tomodachi94@protonmail.com> Tomo <68489118+Tomodachi94@users.noreply.github.com>
Vladimír Čunát <v@cunat.cz> <vcunat@gmail.com>
Vladimír Čunát <v@cunat.cz> <vladimir.cunat@nic.cz>
Yifei Sun <ysun@hey.com> StepBroBD <Hi@StepBroBD.com>
Yifei Sun <ysun@hey.com> <ysun+git@stepbrobd.com>

View File

@@ -1,21 +0,0 @@
queue_rules:
# This rule is for https://docs.mergify.com/commands/queue/
# and can be triggered with: @mergifyio queue
- name: default
merge_conditions:
# all github action checks in this list are required to merge a pull request
- check-success=Attributes
- check-success=Check
- check-success=Outpaths (aarch64-darwin)
- check-success=Outpaths (aarch64-linux)
- check-success=Outpaths (x86_64-darwin)
- check-success=Outpaths (x86_64-linux)
- check-success=Process
- check-success=Request
- check-success=editorconfig-check
- check-success=label-pr
- check-success=nix-files-parseable-check
- check-success=nixfmt-check
- check-success=nixpkgs-vet
# queue up to 5 pull requests at a time
batch_size: 5

View File

@@ -1 +0,0 @@
lib/.version

1
.version Normal file
View File

@@ -0,0 +1 @@
23.05

View File

@@ -1,206 +1,75 @@
# Contributing to Nixpkgs
# How to contribute
This document is for people wanting to contribute to the implementation of Nixpkgs.
This involves interacting with implementation changes that are proposed using [GitHub](https://github.com/) [pull requests](https://docs.github.com/pull-requests) to the [Nixpkgs](https://github.com/nixos/nixpkgs/) repository (which you're in right now).
Note: contributing implies licensing those contributions
under the terms of [COPYING](COPYING), which is an MIT-like license.
As such, a GitHub account is recommended, which you can sign up for [here](https://github.com/signup).
See [here](https://discourse.nixos.org/t/about-the-patches-category/477) for how to contribute without a GitHub account.
## Opening issues
Additionally this document assumes that you already know how to use GitHub and Git.
If that's not the case, we recommend learning about it first [here](https://docs.github.com/en/get-started/quickstart/hello-world).
* Make sure you have a [GitHub account](https://github.com/signup/free)
* Make sure there is no open issue on the topic
* [Submit a new issue](https://github.com/NixOS/nixpkgs/issues/new/choose) by choosing the kind of topic and fill out the template
## Overview
[overview]: #overview
## Submitting changes
This file contains general contributing information, but individual parts also have more specific information to them in their respective `README.md` files, linked here:
- [`lib`](./lib/README.md): Sources and documentation of the [library functions](https://nixos.org/manual/nixpkgs/stable/#chap-functions)
- [`maintainers`](./maintainers/README.md): Nixpkgs maintainer and team listings, maintainer scripts
- [`pkgs`](./pkgs/README.md): Package and [builder](https://nixos.org/manual/nixpkgs/stable/#part-builders) definitions
- [`doc`](./doc/README.md): Sources and infrastructure for the [Nixpkgs manual](https://nixos.org/manual/nixpkgs/stable/)
- [`nixos`](./nixos/README.md): Implementation of [NixOS](https://nixos.org/manual/nixos/stable/)
Read the ["Submitting changes"](https://nixos.org/nixpkgs/manual/#chap-submitting-changes) section of the nixpkgs manual. It explains how to write, test, and iterate on your change, and which branch to base your pull request against.
# How to's
Below is a short excerpt of some points in there:
## How to create pull requests
[pr-create]: #how-to-create-pull-requests
* Format the commit messages in the following way:
This section describes in some detail how changes can be made and proposed with pull requests.
```
(pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc)
> [!Note]
> Be aware that contributing implies licensing those contributions under the terms of [COPYING](./COPYING), an MIT-like license.
0. Set up a local version of Nixpkgs to work with using GitHub and Git
1. [Fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo#forking-a-repository) the [Nixpkgs repository](https://github.com/nixos/nixpkgs/).
1. [Clone the forked repository](https://docs.github.com/en/get-started/quickstart/fork-a-repo#cloning-your-forked-repository) into a local `nixpkgs` directory.
1. [Configure the upstream Nixpkgs repository](https://docs.github.com/en/get-started/quickstart/fork-a-repo#configuring-git-to-sync-your-fork-with-the-upstream-repository).
1. Figure out the branch that should be used for this change by going through [this section][branch].
If in doubt use `master`, that's where most changes should go.
This can be changed later by [rebasing][rebase].
2. Create and switch to a new Git branch, ideally such that:
- The name of the branch hints at the change you'd like to implement, e.g. `update-hello`.
- The base of the branch includes the most recent changes on the base branch from step 1, we'll assume `master` here.
```bash
# Make sure you have the latest changes from upstream Nixpkgs
git fetch upstream
# Create and switch to a new branch based off the master branch in Nixpkgs
git switch --create update-hello upstream/master
```
To avoid having to download and build potentially many derivations, at the expense of using a potentially outdated version, you can base the branch off a specific [Git commit](https://www.git-scm.com/docs/gitglossary#def_commit) instead:
- The commit of the latest `nixpkgs-unstable` channel, available [here](https://channels.nixos.org/nixpkgs-unstable/git-revision).
- The commit of a local Nixpkgs downloaded using [nix-channel](https://nixos.org/manual/nix/stable/command-ref/nix-channel), available using `nix-instantiate --eval --expr '(import <nixpkgs/lib>).trivial.revisionWithDefault null'`
- If you're using NixOS, the commit of your NixOS installation, available with `nixos-version --revision`.
Once you have an appropriate commit you can use it instead of `upstream/master` in the above command:
```bash
git switch --create update-hello <the desired base commit>
```
3. Make the desired changes in the local Nixpkgs repository using an editor of your choice.
Make sure to:
- Adhere to both the [general code conventions][code-conventions], and the code conventions specific to the part you're making changes to.
See the [overview section][overview] for more specific information.
- Test the changes.
See the [overview section][overview] for more specific information.
- If necessary, document the change.
See the [overview section][overview] for more specific information.
4. Commit your changes using `git commit`.
Make sure to adhere to the [commit conventions](#commit-conventions).
Repeat the steps 3-4 as many times as necessary.
Advance to the next step if all the commits (viewable with `git log`) make sense together.
5. Push your commits to your fork of Nixpkgs.
```
git push --set-upstream origin HEAD
```
The above command will output a link that allows you to directly quickly do the next step:
```
remote: Create a pull request for 'update-hello' on GitHub by visiting:
remote: https://github.com/myUser/nixpkgs/pull/new/update-hello
```
6. [Create a pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request#creating-the-pull-request) from the new branch in your Nixpkgs fork to the upstream Nixpkgs repository.
Use the branch from step 2 as the pull requests base branch.
Go through the [pull request template](#pull-request-template) in the pre-filled default description.
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.
- To add new commits, repeat steps 3-4 and push the result using
```
git push
```
- To change existing commits you will have to [rewrite Git history](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History).
Useful Git commands that can help a lot with this are `git commit --patch --amend` and `git rebase --interactive`.
With a rewritten history you need to force-push the commits using
```
git push --force-with-lease
```
- In case of merge conflicts you will also have to [rebase the branch](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) on top of current `master`.
Sometimes this can be done [on GitHub directly](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/keeping-your-pull-request-in-sync-with-the-base-branch#updating-your-pull-request-branch), but if not you will have to rebase locally using
```
git fetch upstream
git rebase upstream/master
git push --force-with-lease
```
- If you need to change the base branch of the pull request, you can do so by [rebasing][rebase].
8. If your pull request is merged and [acceptable for releases][release-acceptable] you may [backport][pr-backport] the pull request.
### Pull request template
[pr-template]: #pull-request-template
The pull request template helps determine what steps have been made for a contribution so far, and will help guide maintainers on the status of a change. The motivation section of the PR should include any extra details the title does not address and link any existing issues related to the pull request.
When a PR is created, it will be pre-populated with some checkboxes detailed below:
#### Tested using sandboxing
When sandbox builds are enabled, Nix will set up an isolated environment for each build process.
It is used to remove further hidden dependencies set by the build environment to improve reproducibility.
This includes access to the network during the build outside of `fetch*` functions and files outside the Nix store.
Depending on the operating system, access to other resources is blocked as well (e.g., inter-process communication is isolated on Linux); see [sandbox](https://nixos.org/manual/nix/stable/command-ref/conf-file#conf-sandbox) in the Nix manual for details.
In pull requests for [nixpkgs](https://github.com/NixOS/nixpkgs/) people are asked to test builds with sandboxing enabled (see `Tested using sandboxing` in the pull request template) because in [Hydra](https://nixos.org/hydra/) sandboxing is also used.
If you are on Linux, sandboxing is enabled by default.
On other platforms, sandboxing is disabled by default due to a small performance hit on each build.
Please enable sandboxing **before** building the package by adding the following to: `/etc/nix/nix.conf`:
```ini
sandbox = true
(Motivation for change. Link to release notes. Additional information.)
```
#### Built on platform(s)
For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message).
Many Nix packages are designed to run on multiple platforms. As such, its important to let the maintainer know which platforms your changes have been tested on. Its not always practical to test a change on all platforms, and is not required for a pull request to be merged. Only check the systems you tested the build on in this section.
Examples:
#### Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
* nginx: init at 2.0.1
* firefox: 54.0.1 -> 55.0
https://www.mozilla.org/en-US/firefox/55.0/releasenotes/
* nixos/hydra: add bazBaz option
Packages with automated tests are much more likely to be merged in a timely fashion because it doesnt require as much manual testing by the maintainer to verify the functionality of the package. If there are existing tests for the package, they should be run to verify your changes do not break the tests. Tests can only be run on Linux. For more details on writing and running tests, see the [section in the NixOS manual](https://nixos.org/nixos/manual/index.html#sec-nixos-tests).
Dual baz behavior is needed to do foo.
* nixos/nginx: refactor config generation
#### Tested compilation of all pkgs that depend on this change using `nixpkgs-review`
The old config generation system used impure shell scripts and could break in specific circumstances (see #1234).
If you are modifying a package, you can use `nixpkgs-review` to make sure all packages that depend on the updated package still compile correctly. The `nixpkgs-review` utility can look for and build all dependencies either based on uncommitted changes with the `wip` option or specifying a GitHub pull request number.
* `meta.description` should:
* Be capitalized.
* Not start with the package name.
* Not have a period at the end.
* `meta.license` must be set and fit the upstream license.
* If there is no upstream license, `meta.license` should default to `lib.licenses.unfree`.
* `meta.maintainers` must be set.
Review changes from pull request number 12345:
See the nixpkgs manual for more details on [standard meta-attributes](https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes).
```ShellSession
nix-shell -p nixpkgs-review --run "nixpkgs-review pr 12345"
```
## Writing good commit messages
Alternatively, with flakes (and analogously for the other commands below):
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.
```ShellSession
nix run nixpkgs#nixpkgs-review -- pr 12345
```
Package version upgrades usually allow for simpler commit messages, including attribute name, old and new version, as well as a reference to the relevant release notes/changelog. Every once in a while a package upgrade requires more extensive changes, and that subsequently warrants a more verbose message.
Review uncommitted changes:
Pull requests should not be squash merged in order to keep complete commit messages and GPG signatures intact and must not be when the change doesn't make sense as a single commit.
This means that, when addressing review comments in order to keep the pull request in an always mergeable status, you will sometimes need to rewrite your branch's history and then force-push it with `git push --force-with-lease`.
Useful git commands that can help a lot with this are `git commit --patch --amend` and `git rebase --interactive @~3`. For more details consult the git man pages.
```ShellSession
nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
```
Review changes from last commit:
```ShellSession
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
```
#### Tested execution of all binary files (usually in `./result/bin/`)
Its important to test any executables generated by a build when you change or create a package in nixpkgs. This can be done by looking in `./result/bin` and running any files in there, or at a minimum, the main executable for the package. For example, if you make a change to texlive, you probably would only check the binaries associated with the change you made rather than testing all of them.
#### Meets Nixpkgs contribution standards
The last checkbox is about whether it fits the guidelines in this `CONTRIBUTING.md` file. This document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
### Rebasing between branches (i.e. from master to staging)
[rebase]: #rebasing-between-branches-ie-from-master-to-staging
## Rebasing between branches (i.e. 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.
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,574 +98,42 @@ git status
git push origin feature --force-with-lease
```
## How to backport pull requests
[pr-backport]: #how-to-backport-pull-requests
## Backporting changes
Once a pull request has been merged into `master`, a backport pull request to the corresponding `release-YY.MM` branch can be created either automatically or manually.
Follow these steps to backport a change into a release branch in compliance with the [commit policy](https://nixos.org/nixpkgs/manual/#submitting-changes-stable-release-branches).
### Automatically backporting changes
You can add a label such as `backport release-22.11` to a PR, so that merging it will
automatically create a backport (via [a GitHub Action](.github/workflows/backport.yml)).
This also works for PR's that have already been merged, and might take a couple of minutes to trigger.
> [!Note]
> You have to be a [Nixpkgs maintainer](./maintainers) to automatically create a backport pull request.
You can also create the backport manually:
Add the [`backport release-YY.MM` label](https://github.com/NixOS/nixpkgs/labels?q=backport) to the pull request on the `master` branch.
This will cause [a GitHub Action](.github/workflows/backport.yml) to open a pull request to the `release-YY.MM` branch a few minutes later.
This can be done on both open or already merged pull requests.
1. Take note of the commits in which the change was introduced into `master` branch.
2. Check out the target _release branch_, e.g. `release-22.11`. Do not use a _channel branch_ like `nixos-22.11` or `nixpkgs-22.11-darwin`.
3. Create a branch for your change, e.g. `git checkout -b backport`.
4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request.
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-22.11`) as the target branch of the pull request, and link to the pull request in which the original change was committed to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[22.11]`.
6. When the backport pull request is merged and you have the necessary privileges you can also replace the label `9.needs: port to stable` with `8.has: port to stable` on the original pull request. This way maintainers can keep track of missing backports easier.
### Manually backporting changes
## Criteria for Backporting changes
To manually create a backport pull request, follow [the standard pull request process][pr-create], with these notable differences:
Anything that does not cause user or downstream dependency regressions can be backported. This includes:
- New Packages / Modules
- Security / Patch updates
- Version updates which include new functionality (but no breaking changes)
- Services which require a client to be up-to-date regardless. (E.g. `spotify`, `steam`, or `discord`)
- Security critical applications (E.g. `firefox`)
- Use `release-YY.MM` for the base branch, both for the local branch and the pull request.
## Generating 23.05 Release Notes
> [!Warning]
> Do not use the `nixos-YY.MM` branch, that is a branch pointing to the tested release channel commit
Documentation in nixpkgs is transitioning to a markdown-centric workflow. Release notes now require a translation step to convert from markdown to a compatible docbook document.
- Instead of manually making and committing the changes, use [`git cherry-pick -x`](https://git-scm.com/docs/git-cherry-pick) for each commit from the pull request you'd like to backport.
Either `git cherry-pick -x <commit>` when the reason for the backport is obvious (such as minor versions, fixes, etc.), otherwise use `git cherry-pick -xe <commit>` to add a reason for the backport to the commit message.
Here is [an example](https://github.com/nixos/nixpkgs/commit/5688c39af5a6c5f3d646343443683da880eaefb8) of this.
Steps for updating 23.05 Release notes:
> [!Warning]
> Ensure the commits exists on the master branch.
> In the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request.
1. Edit `nixos/doc/manual/release-notes/rl-2305.section.md` with the desired changes
2. Run `./nixos/doc/manual/md-to-db.sh` to render `nixos/doc/manual/from_md/release-notes/rl-2305.section.xml`
3. Include changes to `rl-2305.section.md` and `rl-2305.section.xml` in the same commit.
- In the pull request description, link to the original pull request to `master`.
The pull request title should include `[YY.MM]` matching the release you're backporting to.
## Reviewing contributions
- When the backport pull request is merged and you have the necessary privileges you can also replace the label `9.needs: port to stable` with `8.has: port to stable` on the original pull request.
This way maintainers can keep track of missing backports easier.
## How to review pull requests
[pr-review]: #how-to-review-pull-requests
> [!Warning]
> The following section is a draft, and the policy for reviewing is still being discussed in issues such as [#11166](https://github.com/NixOS/nixpkgs/issues/11166) and [#20836](https://github.com/NixOS/nixpkgs/issues/20836).
The Nixpkgs project receives a fairly high number of contributions via GitHub pull requests. Reviewing and approving these is an important task and a way to contribute to the project.
The high change rate of Nixpkgs makes any pull request that remains open for too long subject to conflicts that will require extra work from the submitter or the merger. Reviewing pull requests in a timely manner and being responsive to the comments is the key to avoid this issue. GitHub provides sort filters that can be used to see the [most recently](https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc) and the [least recently](https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc) updated pull requests. We highly encourage looking at [this list of ready to merge, unreviewed pull requests](https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+review%3Anone+status%3Asuccess+-label%3A%222.status%3A+work-in-progress%22+no%3Aproject+no%3Aassignee+no%3Amilestone).
When reviewing a pull request, please always be nice and polite. Controversial changes can lead to controversial opinions, but it is important to respect every community member and their work.
GitHub provides reactions as a simple and quick way to provide feedback to pull requests or any comments. The thumb-down reaction should be used with care and if possible accompanied with some explanation so the submitter has directions to improve their contribution.
When doing a review:
- Aim to drive the proposal to a timely conclusion.
- Focus on the proposed changes to keep the scope of the discussion narrow.
- Help the contributor prioritise their efforts towards getting their change merged.
If you find anything related that could be improved but is not immediately required for acceptance, consider
- Implementing the changes yourself in a follow-up pull request (and request review from the person who inspired you)
- Tracking your idea in an issue
- Offering the original contributor to review a follow-up pull request
- Making concrete [suggestions](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request) in the same pull request.
For example, follow-up changes could involve refactoring code in the affected files.
But please remember not to make such additional considerations a blocker, and communicate that to the contributor, for example by following the [conventional comments](https://conventionalcomments.org/) pattern.
If the related change is essential for the contribution at hand, make clear why you think it is important to address that first.
Pull request reviews should include a list of what has been reviewed in a comment, so other reviewers and mergers can know the state of the review.
All the review template samples provided in this section are generic and meant as examples. Their usage is optional and the reviewer is free to adapt them to their liking.
To get more information about how to review specific parts of Nixpkgs, refer to the documents linked to in the [overview section][overview].
If a pull request contains documentation changes that might require feedback from the documentation team, ping [@NixOS/documentation-team](https://github.com/orgs/nixos/teams/documentation-team) on the pull request.
If you consider having enough knowledge and experience in a topic and would like to be a long-term reviewer for related submissions, please contact the current reviewers for that topic. They will give you information about the reviewing process. The main reviewers for a topic can be hard to find as there is no list, but checking past pull requests to see who reviewed or git-blaming the code to see who committed to that topic can give some hints.
Container system, boot system and library changes are some examples of the pull requests fitting this category.
## How to merge pull requests yourself
[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).
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
to modify the PR, consider applying it yourself (or commit the existing review
suggestion). You should pay extra attention to make sure the addition doesn't go
against the idea of the original PR and would not be opposed by the author.
<!--
The following paragraphs about how to deal with unactive contributors is just a proposition and should be modified to what the community agrees to be the right policy.
Please note that contributors with commit rights unactive for more than three months will have their commit rights revoked.
-->
Please see the discussion in [GitHub nixpkgs issue #321665](https://github.com/NixOS/nixpkgs/issues/321665) for information on how to proceed to be granted this level of access.
In a case a contributor definitively leaves the Nix community, they should create an issue or post on [Discourse](https://discourse.nixos.org) with references of packages and modules they maintain so the maintainership can be taken over by other contributors.
# Flow of merged pull requests
After a pull request is merged, it eventually makes it to the [official Hydra CI](https://hydra.nixos.org/).
Hydra regularly evaluates and builds Nixpkgs, updating [the official channels](https://channels.nixos.org/) when specific Hydra jobs succeeded.
See [Nix Channel Status](https://status.nixos.org/) for the current channels and their state.
Here's a brief overview of the main Git branches and what channels they're used for:
- `master`: The main branch, used for the unstable channels such as `nixpkgs-unstable`, `nixos-unstable` and `nixos-unstable-small`.
- `release-YY.MM` (e.g. `release-25.05`): The NixOS release branches, used for the stable channels such as `nixos-25.05`, `nixos-25.05-small` and `nixpkgs-25.05-darwin`.
When a channel is updated, a corresponding Git branch is also updated to point to the corresponding commit.
So e.g. the [`nixpkgs-unstable` branch](https://github.com/nixos/nixpkgs/tree/nixpkgs-unstable) corresponds to the Git commit from the [`nixpkgs-unstable` channel](https://channels.nixos.org/nixpkgs-unstable).
Nixpkgs in its entirety is tied to the NixOS release process, which is documented in the [NixOS Release Wiki](https://nixos.github.io/release-wiki/).
See [this section][branch] to know when to use the release branches.
## Staging
[staging]: #staging
The staging workflow exists to batch Hydra builds of many packages together.
It is coordinated in the [Staging room](https://matrix.to/#/#staging:nixos.org) on Matrix.
It works by directing commits that cause [mass rebuilds][mass-rebuild] to a separate `staging` branch that isn't directly built by Hydra.
Regularly, the `staging` branch is _manually_ merged into a `staging-next` branch to be built by Hydra using the [`nixpkgs:staging-next` jobset](https://hydra.nixos.org/jobset/nixpkgs/staging-next).
The `staging-next` branch should then only receive changes that fix Hydra builds;
**for anything else, ask the [Staging room](https://matrix.to/#/#staging:nixos.org) first**.
Once it is verified that there are no major regressions, it is merged into `master` using [a pull request](https://github.com/NixOS/nixpkgs/pulls?q=head%3Astaging-next).
This is done manually in order to ensure it's a good use of Hydra's computing resources.
By keeping the `staging-next` branch separate from `staging`, this batching does not block developers from merging changes into `staging`.
In order for the `staging` and `staging-next` branches to be up-to-date with the latest commits on `master`, there are regular _automated_ merges from `master` into `staging-next` and `staging`.
This is implemented using GitHub workflows [here](.github/workflows/periodic-merge-6h.yml) and [here](.github/workflows/periodic-merge-24h.yml).
> [!Note]
> Changes must be sufficiently tested before being merged into any branch.
> Hydra builds should not be used as testing platform.
Here is a Git history diagram showing the flow of commits between the three branches:
```mermaid
%%{init: {
'theme': 'base',
'themeVariables': {
'gitInv0': '#ff0000',
'gitInv1': '#ff0000',
'git2': '#ff4444',
'commitLabelFontSize': '15px'
},
'gitGraph': {
'showCommitLabel':true,
'mainBranchName': 'master',
'rotateCommitLabel': true
}
} }%%
gitGraph
commit id:" "
branch staging
commit id:" "
branch staging-next
merge master id:"automatic"
checkout staging
merge staging-next id:"automatic "
checkout staging-next
merge staging type:HIGHLIGHT id:"manual"
commit id:"fixup"
checkout master
checkout staging
checkout master
commit id:" "
checkout staging-next
merge master id:"automatic "
checkout staging
merge staging-next id:"automatic "
checkout staging-next
commit id:"fixup "
checkout master
merge staging-next type:HIGHLIGHT id:"manual (PR)"
```
Here's an overview of the different branches:
| branch | `master` | `staging-next` | `staging` |
| --- | --- | --- | --- |
| Used for development | ✔️ | ❌ | ✔️ |
| Built by Hydra | ✔️ | ✔️ | ❌ |
| [Mass rebuilds][mass-rebuild] | ❌ | ⚠️ Only to fix Hydra builds | ✔️ |
| Critical security fixes | ✔️ for non-mass-rebuilds | ✔️ for mass-rebuilds | ❌ |
| Automatically merged into | `staging-next` | `staging` | - |
| Manually merged into | - | `master` | `staging-next` |
The staging workflow is used for all main branches, `master` and `release-YY.MM`, with corresponding names:
- `master`/`release-YY.MM`
- `staging`/`staging-YY.MM`
- `staging-next`/`staging-next-YY.MM`
# Conventions
## Branch conventions
<!-- This section is relevant to both contributors and reviewers -->
[branch]: #branch-conventions
Most changes should go to the `master` branch, but sometimes other branches should be used instead.
Use the following decision process to figure out which one it should be:
Is the change [acceptable for releases][release-acceptable] and do you wish to have the change in the release?
- No: Use the `master` branch, do not backport the pull request.
- Yes: Can the change be implemented the same way on the `master` and release branches?
For example, a packages major version might differ between the `master` and release branches, such that separate security patches are required.
- Yes: Use the `master` branch and [backport the pull request](#how-to-backport-pull-requests).
- No: Create separate pull requests to the `master` and `release-XX.YY` branches.
Furthermore, if the change causes a [mass rebuild][mass-rebuild], use the appropriate staging branch instead:
- Mass rebuilds to `master` should go to `staging` instead.
- Mass rebuilds to `release-XX.YY` should go to `staging-XX.YY` instead.
See [this section][staging] for more details about such changes propagate between the branches.
### Changes acceptable for releases
[release-acceptable]: #changes-acceptable-for-releases
Only changes to supported releases may be accepted.
The oldest supported release (`YYMM`) can be found using
```
nix-instantiate --eval -A lib.trivial.oldestSupportedRelease
```
The release branches should generally only receive backwards-compatible changes, both for the Nix expressions and derivations.
Here are some examples of backwards-compatible changes that are okay to backport:
- ✔️ New packages, modules and functions
- ✔️ Security fixes
- ✔️ Package version updates
- ✔️ Patch versions with fixes
- ✔️ Minor versions with new functionality, but no breaking changes
In addition, major package version updates with breaking changes are also acceptable for:
- ✔️ Services that would fail without up-to-date client software, such as `spotify`, `steam`, and `discord`
- ✔️ Security critical applications, such as `firefox` and `chromium`
### Changes causing mass rebuilds
[mass-rebuild]: #changes-causing-mass-rebuilds
Which changes cause mass rebuilds is not formally defined.
In order to help the decision, CI automatically assigns [`rebuild` labels](https://github.com/NixOS/nixpkgs/labels?q=rebuild) to pull requests based on the number of packages they cause rebuilds for.
As a rule of thumb, if the number of rebuilds is **over 500**, it can be considered a mass rebuild.
To get a sense for what changes are considered mass rebuilds, see [previously merged pull requests to the staging branches](https://github.com/NixOS/nixpkgs/issues?q=base%3Astaging+-base%3Astaging-next+is%3Amerged).
## Commit conventions
[commit-conventions]: #commit-conventions
- Create a commit for each logical unit.
- Check for unnecessary whitespace with `git diff --check` before committing.
- If you have commits `pkg-name: oh, forgot to insert whitespace`: squash commits in this case. Use `git rebase -i`.
See [Squashing Commits](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing) for additional information.
- For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message).
- When adding yourself as maintainer in the same pull request, make a separate
commit with the message `maintainers: add <handle>`.
Add the commit before those making changes to the package or module.
See [Nixpkgs Maintainers](./maintainers/README.md) for details.
- Make sure you read about any commit conventions specific to the area you're touching. See:
- [Commit conventions](./pkgs/README.md#commit-conventions) for changes to `pkgs`.
- [Commit conventions](./lib/README.md#commit-conventions) for changes to `lib`.
- [Commit conventions](./nixos/README.md#commit-conventions) for changes to `nixos`.
- [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.
Package version upgrades usually allow for simpler commit messages, including attribute name, old and new version, as well as a reference to the relevant release notes/changelog. Every once in a while a package upgrade requires more extensive changes, and that subsequently warrants a more verbose message.
Pull requests should not be squash merged in order to keep complete commit messages and GPG signatures intact and must not be when the change doesn't make sense as a single commit.
## Code conventions
[code-conventions]: #code-conventions
### Release notes
If you removed packages or made some major NixOS changes, write about it in the release notes for the next stable release in [`nixos/doc/manual/release-notes`](./nixos/doc/manual/release-notes).
### File naming and organisation
Names of files and directories should be in lowercase, with dashes between words — not in camel case. For instance, it should be `all-packages.nix`, not `allPackages.nix` or `AllPackages.nix`.
### Syntax
- Set up [editorconfig](https://editorconfig.org/) for your editor, such that [the settings](./.editorconfig) are automatically applied.
- Use `lowerCamelCase` for variable names, not `UpperCamelCase`. Note, this rule does not apply to package attribute names, which instead follow the rules in [package naming](./pkgs/README.md#package-naming).
- New files must be formatted by entering the `nix-shell` from the repository root and running `nixfmt`.
- Functions should list their expected arguments as precisely as possible. That is, write
```nix
{ stdenv, fetchurl, perl }: <...>
```
instead of
```nix
args: with args; <...>
```
or
```nix
{ stdenv, fetchurl, perl, ... }: <...>
```
For functions that are truly generic in the number of arguments (such as wrappers around `mkDerivation`) that have some required arguments, you should write them using an `@`-pattern:
```nix
{ stdenv, doCoverageAnalysis ? false, ... } @ args:
stdenv.mkDerivation (args // {
foo = if doCoverageAnalysis then "bla" else "";
})
```
instead of
```nix
args:
args.stdenv.mkDerivation (args // {
foo = if args ? doCoverageAnalysis && args.doCoverageAnalysis then "bla" else "";
})
```
- Unnecessary string conversions should be avoided. Do
```nix
{
rev = version;
}
```
instead of
```nix
{
rev = "${version}";
}
```
- Building lists conditionally _should_ be done with `lib.optional(s)` instead of using `if cond then [ ... ] else null` or `if cond then [ ... ] else [ ]`.
```nix
{
buildInputs = lib.optional stdenv.hostPlatform.isDarwin iconv;
}
```
instead of
```nix
{
buildInputs = if stdenv.hostPlatform.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.
See the nixpkgs manual for more details on how to [Review contributions](https://nixos.org/nixpkgs/manual/#chap-reviewing-contributions).

View File

@@ -1,4 +1,4 @@
Copyright (c) 2003-2025 Eelco Dolstra and the Nixpkgs/NixOS contributors
Copyright (c) 2003-2022 Eelco Dolstra and the Nixpkgs/NixOS contributors
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the

View File

@@ -1,20 +1,19 @@
<p align="center">
<a href="https://nixos.org">
<picture>
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png">
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png" width="500px" alt="NixOS logo">
</picture>
<a href="https://nixos.org#gh-light-mode-only">
<img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/master/logo/nixos-hires.png" width="500px" alt="NixOS logo"/>
</a>
<a href="https://nixos.org#gh-dark-mode-only">
<img src="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png" width="500px" alt="NixOS logo"/>
</a>
</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>
[Nixpkgs](https://github.com/nixos/nixpkgs) is a collection of over
100,000 software packages that can be installed with the
80,000 software packages that can be installed with the
[Nix](https://nixos.org/nix/) package manager. It also implements
[NixOS](https://nixos.org/nixos/), a purely-functional Linux distribution.
@@ -29,8 +28,8 @@
* [Discourse Forum](https://discourse.nixos.org/)
* [Matrix Chat](https://matrix.to/#/#community:nixos.org)
* [NixOS Weekly](https://weekly.nixos.org/)
* [Official wiki](https://wiki.nixos.org/)
* [Community-maintained list of ways to get in touch](https://wiki.nixos.org/wiki/Get_In_Touch#Chat) (Discord, Telegram, IRC, etc.)
* [Community-maintained wiki](https://nixos.wiki/)
* [Community-maintained list of ways to get in touch](https://nixos.wiki/wiki/Get_In_Touch#Chat) (Discord, Telegram, IRC, etc.)
# Other Project Repositories
@@ -52,14 +51,14 @@ Nixpkgs and NixOS are built and tested by our continuous integration
system, [Hydra](https://hydra.nixos.org/).
* [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
* [Continuous package builds for the NixOS 24.11 release](https://hydra.nixos.org/jobset/nixos/release-24.11)
* [Continuous package builds for the NixOS 22.11 release](https://hydra.nixos.org/jobset/nixos/release-22.11)
* [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
* [Tests for the NixOS 24.11 release](https://hydra.nixos.org/job/nixos/release-24.11/tested#tabs-constituents)
* [Tests for the NixOS 22.11 release](https://hydra.nixos.org/job/nixos/release-22.11/tested#tabs-constituents)
Artifacts successfully built with Hydra are published to cache at
https://cache.nixos.org/. When successful build and test criteria are
met, the Nixpkgs expressions are distributed via [Nix
channels](https://nix.dev/manual/nix/stable/command-ref/nix-channel.html).
channels](https://nixos.org/manual/nix/stable/package-management/channels.html).
# Contributing
@@ -71,10 +70,29 @@ Linux distribution. The [GitHub Insights](https://github.com/NixOS/nixpkgs/pulse
page gives a sense of the project activity.
Community contributions are always welcome through GitHub Issues and
Pull Requests.
Pull Requests. When pull requests are made, our tooling automation bot,
[OfBorg](https://github.com/NixOS/ofborg) will perform various checks
to help ensure expression quality.
The *Nixpkgs maintainers* are people who have assigned themselves to
maintain specific individual packages. We encourage people who care
about a package to assign themselves as a maintainer. When a pull
request is made against a package, OfBorg will notify the appropriate
maintainer(s). The *Nixpkgs committers* are people who have been given
permission to merge.
Most contributions are based on and merged into these branches:
* `master` is the main branch where all small contributions go
* `staging` is branched from master, changes that have a big impact on
Hydra builds go to this branch
* `staging-next` is branched from staging and only fixes to stabilize
and security fixes with a big impact on Hydra builds should be
contributed to this branch. This branch is merged into master when
deemed of sufficiently high quality
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

444
ci/OWNERS
View File

@@ -1,444 +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/*_TEMPLATE* @SigmaSquadron
/.github/workflows @NixOS/Security @Mic92 @zowoq @infinisil @azuwis @wolfgangwalther
/.github/workflows/check-nix-format.yml @infinisil @wolfgangwalther
/.github/workflows/codeowners-v2.yml @infinisil @wolfgangwalther
/.github/workflows/nixpkgs-vet.yml @infinisil @philiptaron @wolfgangwalther
/ci @infinisil @philiptaron @NixOS/Security @wolfgangwalther
/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
## Format generators/serializers
/pkgs/pkgs-lib @Stunkymonkey @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/misc/ids.nix @R-VdP
/nixos/modules/system/activation/bootspec.nix @grahamc @cole-h @raitobezarius
/nixos/modules/system/activation/bootspec.cue @grahamc @cole-h @raitobezarius
# NixOS Render Docs
/pkgs/by-name/ni/nixos-render-docs @fricklerhandwerk @GetPsyched @hsjobeki
/doc/redirects.json @fricklerhandwerk @GetPsyched @hsjobeki
/nixos/doc/manual/redirects.json @fricklerhandwerk @GetPsyched @hsjobeki
# 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
/nixos/modules/services/monitoring/amazon-cloudwatch-agent.nix @philipmw
/nixos/tests/amazon-cloudwatch-agent.nix @philipmw
# nixos-rebuild-ng
/pkgs/by-name/ni/nixos-rebuild-ng @thiagokokada
# 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/by-name/up/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
/pkgs/build-support/rust/fetch-cargo-vendor* @TomaSajt
/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 @networkException
/nixos/tests/chromium.nix @emilylange @networkException
# 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
/nixos/modules/programs/java.nix @NixOS/java
/pkgs/top-level/java-packages.nix @NixOS/java
# Jetbrains
/pkgs/applications/editors/jetbrains @edwtjo @leona-ya @theCapypara
# 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/by-name/ps/psqlodbc @NixOS/postgres
/pkgs/servers/sql/postgresql @NixOS/postgres
/pkgs/development/tools/rust/cargo-pgrx @NixOS/postgres
/nixos/modules/services/databases/postgresql.md @NixOS/postgres
/nixos/modules/services/databases/postgresql.nix @NixOS/postgres
/nixos/tests/postgresql @NixOS/postgres
# MySQL/MariaDB and related stuff
/nixos/modules/services/backup/mysql-backup.nix @6543
# 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/build-support/build-nim-sbom.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
# Zig
/pkgs/development/compilers/zig @figsoda @RossComputerGuy
/doc/hooks/zig.section.md @figsoda @RossComputerGuy
# 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

@@ -1,85 +0,0 @@
# CI support files
This directory contains files to support CI, such as [GitHub Actions](https://github.com/NixOS/nixpkgs/tree/master/.github/workflows) and [Ofborg](https://github.com/nixos/ofborg).
This is in contrast with [`maintainers/scripts`](../maintainers/scripts) which is for human use instead.
## Pinned Nixpkgs
CI may need certain packages from Nixpkgs.
In order to ensure that the needed packages are generally available without building,
[`pinned-nixpkgs.json`](./pinned-nixpkgs.json) contains a pinned Nixpkgs version tested by Hydra.
Run [`update-pinned-nixpkgs.sh`](./update-pinned-nixpkgs.sh) to update it.
## `ci/nixpkgs-vet.sh BASE_BRANCH [REPOSITORY]`
Runs the [`nixpkgs-vet` tool](https://github.com/NixOS/nixpkgs-vet) on the HEAD commit, closely matching what CI does. This can't do exactly the same as CI, because CI needs to rely on GitHub's server-side Git history to compute the mergeability of PRs before the check can be started.
In turn, when contributors are running this tool locally, we don't want to have to push commits to test them, and we can also rely on the local Git history to do the mergeability check.
Arguments:
- `BASE_BRANCH`: The base branch to use, e.g. master or release-24.05
- `REPOSITORY`: The repository from which to fetch the base branch. Defaults to <https://github.com/NixOS/nixpkgs.git>.
## `ci/nixpkgs-vet`
This directory contains scripts and files used and related to [`nixpkgs-vet`](https://github.com/NixOS/nixpkgs-vet/), which the CI uses to implement `pkgs/by-name` checks, along with many other Nixpkgs architecture rules.
See also the [CI GitHub Action](../.github/workflows/nixpkgs-vet.yml).
## `ci/nixpkgs-vet/update-pinned-tool.sh`
Updates the pinned [`nixpkgs-vet` tool](https://github.com/NixOS/nixpkgs-vet) in [`ci/nixpkgs-vet/pinned-version.txt`](./nixpkgs-vet/pinned-version.txt) to the latest [release](https://github.com/NixOS/nixpkgs-vet/releases).
Each release contains a pre-built `x86_64-linux` version of the tool which is used by CI.
This script currently needs to be called manually when the CI tooling needs to be updated.
Why not just build the tooling right from the PRs Nixpkgs version?
- Because it allows CI to check all PRs, even if they would break the CI tooling.
- Because it makes the CI check very fast, since no Nix builds need to be done, even for mass rebuilds.
- 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 is implemented as a reusable GitHub Actions workflow, and can be used 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:
get-merge-commit:
# use the relative path of the get-merge-commit workflow yaml here
uses: ./.github/workflows/get-merge-commit.yml
build:
name: Build
runs-on: ubuntu-24.04
needs: get-merge-commit
steps:
- uses: actions/checkout@<VERSION>
# Add this to _all_ subsequent steps to skip them
if: needs.get-merge-commit.outputs.mergedSha
with:
ref: ${{ needs.get-merge-commit.outputs.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,30 +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 { };
eval = pkgs.callPackage ./eval { };
}

View File

@@ -1,21 +0,0 @@
# Nixpkgs CI evaluation
The code in this directory is used by the [eval.yml](../../.github/workflows/eval.yml) GitHub Actions workflow to evaluate the majority of Nixpkgs for all PRs, effectively making sure that when the development branches are processed by Hydra, no evaluation failures are encountered.
Furthermore it also allows local evaluation using
```
nix-build ci -A eval.full \
--max-jobs 4 \
--cores 2 \
--arg chunkSize 10000 \
--arg evalSystems '["x86_64-linux" "aarch64-darwin"]'
```
- `--max-jobs`: The maximum number of derivations to run at the same time. Only each [supported system](../supportedSystems.nix) gets a separate derivation, so it doesn't make sense to set this higher than that number.
- `--cores`: The number of cores to use for each job. Recommended to set this to the amount of cores on your system divided by `--max-jobs`.
- `chunkSize`: The number of attributes that are evaluated simultaneously on a single core. Lowering this decreases memory usage at the cost of increased evaluation time. If this is too high, there won't be enough chunks to process them in parallel, and will also increase evaluation time.
- `evalSystems`: The set of systems for which `nixpkgs` should be evaluated. Defaults to the four official platforms (`x86_64-linux`, `aarch64-linux`, `x86_64-darwin` and `aarch64-darwin`).
A good default is to set `chunkSize` to 10000, which leads to about 3.6GB max memory usage per core, so suitable for fully utilising machines with 4 cores and 16GB memory, 8 cores and 32GB memory or 16 cores and 64GB memory.
Note that 16GB memory is the recommended minimum, while with less than 8GB memory evaluation time suffers greatly.

View File

@@ -1,132 +0,0 @@
{
lib,
jq,
runCommand,
writeText,
...
}:
{
beforeResultDir,
afterResultDir,
touchedFilesJson,
}:
let
/*
Derivation that computes which packages are affected (added, changed or removed) between two revisions of nixpkgs.
Note: "platforms" are "x86_64-linux", "aarch64-darwin", ...
---
Inputs:
- beforeResultDir, afterResultDir: The evaluation result from before and after the change.
They can be obtained by running `nix-build -A ci.eval.full` on both revisions.
---
Outputs:
- changed-paths.json: Various information about the changes:
{
attrdiff: {
added: ["package1"],
changed: ["package2", "package3"],
removed: ["package4"],
},
labels: [
"10.rebuild-darwin: 1-10",
"10.rebuild-linux: 1-10"
],
rebuildsByKernel: {
darwin: ["package1", "package2"],
linux: ["package1", "package2", "package3"]
},
rebuildCountByKernel: {
darwin: 2,
linux: 3,
},
rebuildsByPlatform: {
aarch64-darwin: ["package1", "package2"],
aarch64-linux: ["package1", "package2"],
x86_64-linux: ["package1", "package2", "package3"],
x86_64-darwin: ["package1"],
},
}
- step-summary.md: A markdown render of the changes
---
Implementation details:
Helper functions can be found in ./utils.nix.
Two main "types" are important:
- `packagePlatformPath`: A string of the form "<PACKAGE_PATH>.<PLATFORM>"
Example: "python312Packages.numpy.x86_64-linux"
- `packagePlatformAttr`: An attrs representation of a packagePlatformPath:
Example: { name = "python312Packages.numpy"; platform = "x86_64-linux"; }
*/
inherit (import ./utils.nix { inherit lib; })
diff
groupByKernel
convertToPackagePlatformAttrs
groupByPlatform
extractPackageNames
getLabels
;
getAttrs = dir: builtins.fromJSON (builtins.readFile "${dir}/outpaths.json");
beforeAttrs = getAttrs beforeResultDir;
afterAttrs = getAttrs afterResultDir;
# Attrs
# - keys: "added", "changed" and "removed"
# - values: lists of `packagePlatformPath`s
diffAttrs = diff beforeAttrs afterAttrs;
rebuilds = diffAttrs.added ++ diffAttrs.changed;
rebuildsPackagePlatformAttrs = convertToPackagePlatformAttrs rebuilds;
changed-paths =
let
rebuildsByPlatform = groupByPlatform rebuildsPackagePlatformAttrs;
rebuildsByKernel = groupByKernel rebuildsPackagePlatformAttrs;
rebuildCountByKernel = lib.mapAttrs (
kernel: kernelRebuilds: lib.length kernelRebuilds
) rebuildsByKernel;
in
writeText "changed-paths.json" (
builtins.toJSON {
attrdiff = lib.mapAttrs (_: extractPackageNames) diffAttrs;
inherit
rebuildsByPlatform
rebuildsByKernel
rebuildCountByKernel
;
labels =
(getLabels rebuildCountByKernel)
# Adds "10.rebuild-*-stdenv" label if the "stdenv" attribute was changed
++ lib.mapAttrsToList (kernel: _: "10.rebuild-${kernel}-stdenv") (
lib.filterAttrs (_: kernelRebuilds: kernelRebuilds ? "stdenv") rebuildsByKernel
);
}
);
maintainers = import ./maintainers.nix {
changedattrs = lib.attrNames (lib.groupBy (a: a.name) rebuildsPackagePlatformAttrs);
changedpathsjson = touchedFilesJson;
};
in
runCommand "compare"
{
nativeBuildInputs = [ jq ];
maintainers = builtins.toJSON maintainers;
passAsFile = [ "maintainers" ];
}
''
mkdir $out
cp ${changed-paths} $out/changed-paths.json
jq -r -f ${./generate-step-summary.jq} < ${changed-paths} > $out/step-summary.md
cp "$maintainersPath" "$out/maintainers.json"
# TODO: Compare eval stats
''

View File

@@ -1,30 +0,0 @@
def truncate(xs; n):
if xs | length > n then xs[:n] + ["..."]
else xs
end;
def itemize_packages(xs):
truncate(xs; 2000) |
map("- [\(.)](https://search.nixos.org/packages?channel=unstable&show=\(.)&from=0&size=50&sort=relevance&type=packages&query=\(.))") |
join("\n");
def get_title(s; xs):
s + " (" + (xs | length | tostring) + ")";
def section(title; xs):
"<details> <summary>" + get_title(title; xs) + "</summary>\n\n" + itemize_packages(xs) + "</details>";
def fallback_document(content; n):
if content | utf8bytelength > n then
get_title("Added packages"; .attrdiff.added) + "\n\n" +
get_title("Removed packages"; .attrdiff.removed) + "\n\n" +
get_title("Changed packages"; .attrdiff.changed)
else content
end;
# we truncate the list to stay below the GitHub limit of 1MB per step summary.
fallback_document(
section("Added packages"; .attrdiff.added) + "\n\n" +
section("Removed packages"; .attrdiff.removed) + "\n\n" +
section("Changed packages"; .attrdiff.changed); 1000 * 1000
)

View File

@@ -1,94 +0,0 @@
# Almost directly vendored from https://github.com/NixOS/ofborg/blob/5a4e743f192fb151915fcbe8789922fa401ecf48/ofborg/src/maintainers.nix
{ changedattrs, changedpathsjson }:
let
pkgs = import ../../.. {
system = "x86_64-linux";
config = { };
overlays = [ ];
};
inherit (pkgs) lib;
changedpaths = builtins.fromJSON (builtins.readFile changedpathsjson);
anyMatchingFile =
filename: builtins.any (changed: lib.strings.hasSuffix changed filename) changedpaths;
anyMatchingFiles = files: builtins.any anyMatchingFile files;
enrichedAttrs = builtins.map (name: {
path = lib.splitString "." name;
name = name;
}) changedattrs;
validPackageAttributes = builtins.filter (
pkg:
if (lib.attrsets.hasAttrByPath pkg.path pkgs) then
(
if (builtins.tryEval (lib.attrsets.attrByPath pkg.path null pkgs)).success then
true
else
builtins.trace "Failed to access ${pkg.name} even though it exists" false
)
else
builtins.trace "Failed to locate ${pkg.name}." false
) enrichedAttrs;
attrsWithPackages = builtins.map (
pkg: pkg // { package = lib.attrsets.attrByPath pkg.path null pkgs; }
) validPackageAttributes;
attrsWithMaintainers = builtins.map (
pkg: pkg // { maintainers = (pkg.package.meta or { }).maintainers or [ ]; }
) attrsWithPackages;
relevantFilenames =
drv:
(lib.lists.unique (
builtins.map (pos: lib.strings.removePrefix (toString ../..) pos.file) (
builtins.filter (x: x != null) [
(builtins.unsafeGetAttrPos "maintainers" (drv.meta or { }))
(builtins.unsafeGetAttrPos "src" drv)
# broken because name is always set by stdenv:
# # A hack to make `nix-env -qa` and `nix search` ignore broken packages.
# # TODO(@oxij): remove this assert when something like NixOS/nix#1771 gets merged into nix.
# name = assert validity.handled; name + lib.optionalString
#(builtins.unsafeGetAttrPos "name" drv)
(builtins.unsafeGetAttrPos "pname" drv)
(builtins.unsafeGetAttrPos "version" drv)
# Use ".meta.position" for cases when most of the package is
# defined in a "common" section and the only place where
# reference to the file with a derivation the "pos"
# attribute.
#
# ".meta.position" has the following form:
# "pkgs/tools/package-management/nix/default.nix:155"
# We transform it to the following:
# { file = "pkgs/tools/package-management/nix/default.nix"; }
{ file = lib.head (lib.splitString ":" (drv.meta.position or "")); }
]
)
));
attrsWithFilenames = builtins.map (
pkg: pkg // { filenames = relevantFilenames pkg.package; }
) attrsWithMaintainers;
attrsWithModifiedFiles = builtins.filter (pkg: anyMatchingFiles pkg.filenames) attrsWithFilenames;
listToPing = lib.concatMap (
pkg:
builtins.map (maintainer: {
id = maintainer.githubId;
packageName = pkg.name;
dueToFiles = pkg.filenames;
}) pkg.maintainers
) attrsWithModifiedFiles;
byMaintainer = lib.groupBy (ping: toString ping.id) listToPing;
packagesPerMaintainer = lib.attrsets.mapAttrs (
maintainer: packages: builtins.map (pkg: pkg.packageName) packages
) byMaintainer;
in
packagesPerMaintainer

View File

@@ -1,238 +0,0 @@
{ lib, ... }:
rec {
# Borrowed from https://github.com/NixOS/nixpkgs/pull/355616
uniqueStrings = list: builtins.attrNames (builtins.groupBy lib.id list);
/*
Converts a `packagePlatformPath` into a `packagePlatformAttr`
Turns
"hello.aarch64-linux"
into
{
name = "hello";
packagePath = [ "hello" ];
platform = "aarch64-linux";
}
*/
convertToPackagePlatformAttr =
packagePlatformPath:
let
# python312Packages.numpy.aarch64-linux -> ["python312Packages" "numpy" "aarch64-linux"]
splittedPath = lib.splitString "." packagePlatformPath;
# ["python312Packages" "numpy" "aarch64-linux"] -> ["python312Packages" "numpy"]
packagePath = lib.sublist 0 (lib.length splittedPath - 1) splittedPath;
# "python312Packages.numpy"
name = lib.concatStringsSep "." packagePath;
in
if name == "" then
null
else
{
# [ "python312Packages" "numpy" ]
inherit packagePath;
# python312Packages.numpy
inherit name;
# "aarch64-linux"
platform = lib.last splittedPath;
};
/*
Converts a list of `packagePlatformPath`s into a list of `packagePlatformAttr`s
Turns
[
"hello.aarch64-linux"
"hello.x86_64-linux"
"hello.aarch64-darwin"
"hello.x86_64-darwin"
"bye.x86_64-darwin"
"bye.aarch64-darwin"
"release-checks" <- Will be dropped
]
into
[
{ name = "hello"; platform = "aarch64-linux"; packagePath = [ "hello" ]; }
{ name = "hello"; platform = "x86_64-linux"; packagePath = [ "hello" ]; }
{ name = "hello"; platform = "aarch64-darwin"; packagePath = [ "hello" ]; }
{ name = "hello"; platform = "x86_64-darwin"; packagePath = [ "hello" ]; }
{ name = "bye"; platform = "aarch64-darwin"; packagePath = [ "hello" ]; }
{ name = "bye"; platform = "x86_64-darwin"; packagePath = [ "hello" ]; }
]
*/
convertToPackagePlatformAttrs =
packagePlatformPaths:
builtins.filter (x: x != null) (builtins.map convertToPackagePlatformAttr packagePlatformPaths);
/*
Converts a list of `packagePlatformPath`s directly to a list of (unique) package names
Turns
[
"hello.aarch64-linux"
"hello.x86_64-linux"
"hello.aarch64-darwin"
"hello.x86_64-darwin"
"bye.x86_64-darwin"
"bye.aarch64-darwin"
]
into
[
"hello"
"bye"
]
*/
extractPackageNames =
packagePlatformPaths:
let
packagePlatformAttrs = convertToPackagePlatformAttrs (uniqueStrings packagePlatformPaths);
in
uniqueStrings (builtins.map (p: p.name) packagePlatformAttrs);
/*
Computes the key difference between two attrs
{
added: [ <keys only in the second object> ],
removed: [ <keys only in the first object> ],
changed: [ <keys with different values between the two objects> ],
}
*/
diff =
let
filterKeys = cond: attrs: lib.attrNames (lib.filterAttrs cond attrs);
in
old: new: {
added = filterKeys (n: _: !(old ? ${n})) new;
removed = filterKeys (n: _: !(new ? ${n})) old;
changed = filterKeys (
n: v:
# Filter out attributes that don't exist anymore
(new ? ${n})
# Filter out attributes that are the same as the new value
&& (v != (new.${n}))
) old;
};
/*
Group a list of `packagePlatformAttr`s by platforms
Turns
[
{ name = "hello"; platform = "aarch64-linux"; ... }
{ name = "hello"; platform = "x86_64-linux"; ... }
{ name = "hello"; platform = "aarch64-darwin"; ... }
{ name = "hello"; platform = "x86_64-darwin"; ... }
{ name = "bye"; platform = "aarch64-darwin"; ... }
{ name = "bye"; platform = "x86_64-darwin"; ... }
]
into
{
aarch64-linux = [ "hello" ];
x86_64-linux = [ "hello" ];
aarch64-darwin = [ "hello" "bye" ];
x86_64-darwin = [ "hello" "bye" ];
}
*/
groupByPlatform =
packagePlatformAttrs:
let
packagePlatformAttrsByPlatform = builtins.groupBy (p: p.platform) packagePlatformAttrs;
extractPackageNames = map (p: p.name);
in
lib.mapAttrs (_: extractPackageNames) packagePlatformAttrsByPlatform;
# Turns
# [
# { name = "hello"; platform = "aarch64-linux"; ... }
# { name = "hello"; platform = "x86_64-linux"; ... }
# { name = "hello"; platform = "aarch64-darwin"; ... }
# { name = "hello"; platform = "x86_64-darwin"; ... }
# { name = "bye"; platform = "aarch64-darwin"; ... }
# { name = "bye"; platform = "x86_64-darwin"; ... }
# ]
#
# into
#
# {
# linux = [ "hello" ];
# darwin = [ "hello" "bye" ];
# }
groupByKernel =
packagePlatformAttrs:
let
filterKernel =
kernel:
builtins.attrNames (
builtins.groupBy (p: p.name) (
builtins.filter (p: lib.hasSuffix kernel p.platform) packagePlatformAttrs
)
);
in
lib.genAttrs [ "linux" "darwin" ] filterKernel;
/*
Maps an attrs of `kernel - rebuild counts` mappings to a list of labels
Turns
{
linux = 56;
darwin = 1;
}
into
[
"10.rebuild-darwin: 1"
"10.rebuild-darwin: 1-10"
"10.rebuild-linux: 11-100"
]
*/
getLabels =
rebuildCountByKernel:
lib.concatLists (
lib.mapAttrsToList (
kernel: rebuildCount:
let
numbers =
if rebuildCount == 0 then
[ "0" ]
else if rebuildCount == 1 then
[
"1"
"1-10"
]
else if rebuildCount <= 10 then
[ "1-10" ]
else if rebuildCount <= 100 then
[ "11-100" ]
else if rebuildCount <= 500 then
[ "101-500" ]
else if rebuildCount <= 1000 then
[
"501-1000"
"501+"
]
else if rebuildCount <= 2500 then
[
"1001-2500"
"501+"
]
else if rebuildCount <= 5000 then
[
"2501-5000"
"501+"
]
else
[
"5001+"
"501+"
];
in
lib.forEach numbers (number: "10.rebuild-${kernel}: ${number}")
) rebuildCountByKernel
);
}

View File

@@ -1,294 +0,0 @@
{
lib,
runCommand,
writeShellScript,
writeText,
linkFarm,
time,
procps,
nixVersions,
jq,
sta,
}:
let
nixpkgs =
with lib.fileset;
toSource {
root = ../..;
fileset = unions (
map (lib.path.append ../..) [
"default.nix"
"doc"
"lib"
"maintainers"
"nixos"
"pkgs"
".version"
"ci/supportedSystems.nix"
]
);
};
nix = nixVersions.nix_2_24;
supportedSystems = import ../supportedSystems.nix;
attrpathsSuperset =
runCommand "attrpaths-superset.json"
{
src = nixpkgs;
nativeBuildInputs = [
nix
time
];
env.supportedSystems = builtins.toJSON supportedSystems;
passAsFile = [ "supportedSystems" ];
}
''
export NIX_STATE_DIR=$(mktemp -d)
mkdir $out
export GC_INITIAL_HEAP_SIZE=4g
command time -f "Attribute eval done [%MKB max resident, %Es elapsed] %C" \
nix-instantiate --eval --strict --json --show-trace \
"$src/pkgs/top-level/release-attrpaths-superset.nix" \
-A paths \
-I "$src" \
--option restrict-eval true \
--option allow-import-from-derivation false \
--arg enableWarnings false > $out/paths.json
mv "$supportedSystemsPath" $out/systems.json
'';
singleSystem =
{
# The system to evaluate.
# Note that this is intentionally not called `system`,
# because `--argstr system` would only be passed to the ci/default.nix file!
evalSystem,
# The path to the `paths.json` file from `attrpathsSuperset`
attrpathFile,
# The number of attributes per chunk, see ./README.md for more info.
chunkSize,
checkMeta ? true,
includeBroken ? true,
# Whether to just evaluate a single chunk for quick testing
quickTest ? false,
}:
let
singleChunk = writeShellScript "single-chunk" ''
set -euo pipefail
chunkSize=$1
myChunk=$2
system=$3
outputDir=$4
export NIX_SHOW_STATS=1
export NIX_SHOW_STATS_PATH="$outputDir/stats/$myChunk"
echo "Chunk $myChunk on $system start"
set +e
command time -f "Chunk $myChunk on $system done [%MKB max resident, %Es elapsed] %C" \
nix-env -f "${nixpkgs}/pkgs/top-level/release-attrpaths-parallel.nix" \
--option restrict-eval true \
--option allow-import-from-derivation false \
--query --available \
--no-name --attr-path --out-path \
--show-trace \
--arg chunkSize "$chunkSize" \
--arg myChunk "$myChunk" \
--arg attrpathFile "${attrpathFile}" \
--arg systems "[ \"$system\" ]" \
--arg checkMeta ${lib.boolToString checkMeta} \
--arg includeBroken ${lib.boolToString includeBroken} \
-I ${nixpkgs} \
-I ${attrpathFile} \
> "$outputDir/result/$myChunk"
exitCode=$?
set -e
if (( exitCode != 0 )); then
echo "Evaluation failed with exit code $exitCode"
# This immediately halts all xargs processes
kill $PPID
fi
'';
in
runCommand "nixpkgs-eval-${evalSystem}"
{
nativeBuildInputs = [
nix
time
procps
jq
];
env = {
inherit evalSystem chunkSize;
};
}
''
export NIX_STATE_DIR=$(mktemp -d)
nix-store --init
echo "System: $evalSystem"
cores=$NIX_BUILD_CORES
echo "Cores: $cores"
attrCount=$(jq length "${attrpathFile}")
echo "Attribute count: $attrCount"
echo "Chunk size: $chunkSize"
# Same as `attrCount / chunkSize` but rounded up
chunkCount=$(( (attrCount - 1) / chunkSize + 1 ))
echo "Chunk count: $chunkCount"
mkdir $out
# Record and print stats on free memory and swap in the background
(
while true; do
availMemory=$(free -b | grep Mem | awk '{print $7}')
freeSwap=$(free -b | grep Swap | awk '{print $4}')
echo "Available memory: $(( availMemory / 1024 / 1024 )) MiB, free swap: $(( freeSwap / 1024 / 1024 )) MiB"
if [[ ! -f "$out/min-avail-memory" ]] || (( availMemory < $(<$out/min-avail-memory) )); then
echo "$availMemory" > $out/min-avail-memory
fi
if [[ ! -f $out/min-free-swap ]] || (( availMemory < $(<$out/min-free-swap) )); then
echo "$freeSwap" > $out/min-free-swap
fi
sleep 4
done
) &
seq_end=$(( chunkCount - 1 ))
${lib.optionalString quickTest ''
seq_end=0
''}
chunkOutputDir=$(mktemp -d)
mkdir "$chunkOutputDir"/{result,stats}
seq -w 0 "$seq_end" |
command time -f "%e" -o "$out/total-time" \
xargs -I{} -P"$cores" \
${singleChunk} "$chunkSize" {} "$evalSystem" "$chunkOutputDir"
if (( chunkSize * chunkCount != attrCount )); then
# A final incomplete chunk would mess up the stats, don't include it
rm "$chunkOutputDir"/stats/"$seq_end"
fi
# Make sure the glob doesn't break when there's no files
shopt -s nullglob
cat "$chunkOutputDir"/result/* > $out/paths
cat "$chunkOutputDir"/stats/* > $out/stats.jsonstream
'';
combine =
{
resultsDir,
}:
runCommand "combined-result"
{
nativeBuildInputs = [
jq
sta
];
}
''
mkdir -p $out
# Transform output paths to JSON
cat ${resultsDir}/*/paths |
jq --sort-keys --raw-input --slurp '
split("\n") |
map(select(. != "") | split(" ") | map(select(. != ""))) |
map(
{
key: .[0],
value: .[1] | split(";") | map(split("=") |
if length == 1 then
{ key: "out", value: .[0] }
else
{ key: .[0], value: .[1] }
end) | from_entries}
) | from_entries
' > $out/outpaths.json
# Computes min, mean, error, etc. for a list of values and outputs a JSON from that
statistics() {
local stat=$1
sta --transpose |
jq --raw-input --argjson stat "$stat" -n '
[
inputs |
split("\t") |
{ key: .[0], value: (.[1] | fromjson) }
] |
from_entries |
{
key: ($stat | join(".")),
value: .
}'
}
# Gets all available number stats (without .sizes because those are constant and not interesting)
readarray -t stats < <(jq -cs '.[0] | del(.sizes) | paths(type == "number")' ${resultsDir}/*/stats.jsonstream)
# Combines the statistics from all evaluations
{
echo "{ \"key\": \"minAvailMemory\", \"value\": $(cat ${resultsDir}/*/min-avail-memory | sta --brief --min) }"
echo "{ \"key\": \"minFreeSwap\", \"value\": $(cat ${resultsDir}/*/min-free-swap | sta --brief --min) }"
cat ${resultsDir}/*/total-time | statistics '["totalTime"]'
for stat in "''${stats[@]}"; do
cat ${resultsDir}/*/stats.jsonstream |
jq --argjson stat "$stat" 'getpath($stat)' |
statistics "$stat"
done
} |
jq -s from_entries > $out/stats.json
'';
compare = import ./compare {
inherit
lib
jq
runCommand
writeText
supportedSystems
;
};
full =
{
# Whether to evaluate on a specific set of systems, by default all are evaluated
evalSystems ? if quickTest then [ "x86_64-linux" ] else supportedSystems,
# The number of attributes per chunk, see ./README.md for more info.
chunkSize,
quickTest ? false,
}:
let
results = linkFarm "results" (
map (evalSystem: {
name = evalSystem;
path = singleSystem {
inherit quickTest evalSystem chunkSize;
attrpathFile = attrpathsSuperset + "/paths.json";
};
}) evalSystems
);
in
combine {
resultsDir = results;
};
in
{
inherit
attrpathsSuperset
singleSystem
combine
compare
# The above three are used by separate VMs in a GitHub workflow,
# while the below is intended for testing on a single local machine
full
;
}

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,71 +0,0 @@
#!/usr/bin/env nix-shell
#!nix-shell -i bash -p jq
set -o pipefail -o errexit -o nounset
trace() { echo >&2 "$@"; }
tmp=$(mktemp -d)
cleanup() {
# Don't exit early if anything fails to cleanup
set +o errexit
trace -n "Cleaning up.. "
[[ -e "$tmp/base" ]] && git worktree remove --force "$tmp/base"
[[ -e "$tmp/merged" ]] && git worktree remove --force "$tmp/merged"
rm -rf "$tmp"
trace "Done"
}
trap cleanup exit
repo=https://github.com/NixOS/nixpkgs.git
if (( $# != 0 )); then
baseBranch=$1
shift
else
trace "Usage: $0 BASE_BRANCH [REPOSITORY]"
trace "BASE_BRANCH: The base branch to use, e.g. master or release-23.11"
trace "REPOSITORY: The repository to fetch the base branch from, defaults to $repo"
exit 1
fi
if (( $# != 0 )); then
repo=$1
shift
fi
if [[ -n "$(git status --porcelain)" ]]; then
trace -e "\e[33mWarning: Dirty tree, uncommitted changes won't be taken into account\e[0m"
fi
headSha=$(git rev-parse HEAD)
trace -e "Using HEAD commit \e[34m$headSha\e[0m"
trace -n "Creating Git worktree for the HEAD commit in $tmp/merged.. "
git worktree add --detach -q "$tmp/merged" HEAD
trace "Done"
trace -n "Fetching base branch $baseBranch to compare against.. "
git fetch -q "$repo" refs/heads/"$baseBranch"
baseSha=$(git rev-parse FETCH_HEAD)
trace -e "\e[34m$baseSha\e[0m"
trace -n "Creating Git worktree for the base branch in $tmp/base.. "
git worktree add -q "$tmp/base" "$baseSha"
trace "Done"
trace -n "Merging base branch into the HEAD commit in $tmp/merged.. "
git -C "$tmp/merged" merge -q --no-edit "$baseSha"
trace -e "\e[34m$(git -C "$tmp/merged" rev-parse HEAD)\e[0m"
trace -n "Reading pinned nixpkgs-vet version from pinned-version.txt.. "
toolVersion=$(<"$tmp/merged/ci/nixpkgs-vet/pinned-version.txt")
trace -e "\e[34m$toolVersion\e[0m"
trace -n "Building tool.. "
nix-build https://github.com/NixOS/nixpkgs-vet/tarball/"$toolVersion" -o "$tmp/tool" -A build
trace "Running nixpkgs-vet.."
"$tmp/tool/bin/nixpkgs-vet" --base "$tmp/base" "$tmp/merged"

View File

@@ -1 +0,0 @@
0.1.4

View File

@@ -1,22 +0,0 @@
#!/usr/bin/env nix-shell
#!nix-shell -i bash -p jq curl
set -o pipefail -o errexit -o nounset
trace() { echo >&2 "$@"; }
SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )
repository=NixOS/nixpkgs-vet
pin_file=$SCRIPT_DIR/pinned-version.txt
trace -n "Fetching latest release of $repository.. "
latestRelease=$(curl -sSfL \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/repos/"$repository"/releases/latest)
latestVersion=$(jq .tag_name -r <<< "$latestRelease")
trace "$latestVersion"
trace "Updating $pin_file"
echo "$latestVersion" > "$pin_file"

View File

@@ -1,4 +0,0 @@
{
"rev": "5757bbb8bd7c0630a0cc4bb19c47e588db30b97c",
"sha256": "0px0lr7ad2zrws400507c9w5nnaffz9mp9hqssm64icdm6f6h0fz"
}

View File

@@ -1,44 +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-code-owners.sh
./request-reviewers.sh
./request-code-owner-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,9 +0,0 @@
# Trusted development branches:
# These generally require PRs to update and are built by Hydra.
# Keep this synced with the branches in .github/workflows/eval.yml
master
staging
release-*
staging-*
haskell-updates
python-updates

View File

@@ -1,97 +0,0 @@
#!/usr/bin/env bash
# Get the code owners of the files changed by a PR, returning one username per line
set -euo pipefail
log() {
echo "$@" >&2
}
if (( "$#" < 4 )); then
log "Usage: $0 GIT_REPO OWNERS_FILE BASE_REF HEAD_REF"
exit 1
fi
gitRepo=$1
ownersFile=$2
baseRef=$3
headRef=$4
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")
# Remove the file prefix and trim the surrounding spaces
read -r owners <<< "${result#"$file"}"
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
printf "%s\n" "${!users[@]}"

View File

@@ -1,82 +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 "Requesting reviews from code owners"
"$SCRIPT_DIR"/get-code-owners.sh "$tmp/nixpkgs.git" "$ownersFile" "$baseBranch" "$headRef" | \
"$SCRIPT_DIR"/request-reviewers.sh "$baseRepo" "$prNumber" "$prAuthor"

View File

@@ -1,88 +0,0 @@
#!/usr/bin/env bash
# Request reviewers for a PR, reading line-separated usernames on stdin,
# filtering for valid reviewers before using 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
tmp=$(mktemp -d)
trap 'rm -rf "$tmp"' exit
log() {
echo "$@" >&2
}
effect() {
if [[ -n "${DRY_MODE:-}" ]]; then
log "Skipping in dry mode:" "${@@Q}"
else
"$@"
fi
}
if (( "$#" < 3 )); then
log "Usage: $0 BASE_REPO PR_NUMBER PR_AUTHOR"
exit 1
fi
baseRepo=$1
prNumber=$2
prAuthor=$3
tmp=$(mktemp -d)
trap 'rm -rf "$tmp"' exit
declare -A users=()
while read -r handle && [[ -n "$handle" ]]; do
users[${handle,,}]=
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 potential reviewer, but has already left a review, ignoring"
unset 'users[${user,,}]'
fi
done < "$tmp/already-reviewed-by"
for user in "${!users[@]}"; do
if ! gh api \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
"/repos/$baseRepo/collaborators/$user" >&2; then
log "User $user is not a repository collaborator, probably missed the automated invite to the maintainers team (see <https://github.com/NixOS/nixpkgs/issues/234293>), ignoring"
unset 'users[$user]'
fi
done
if [[ "${#users[@]}" -gt 10 ]]; then
log "Too many reviewers (${!users[*]}), skipping review requests"
exit 0
fi
for user in "${!users[@]}"; do
log "Requesting review from: $user"
if ! response=$(jq -n --arg user "$user" '{ reviewers: [ $user ] }' | \
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 -); then
log "Failed to request review from $user: $response"
fi
done

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

@@ -1,6 +0,0 @@
[
"aarch64-linux"
"aarch64-darwin"
"x86_64-linux"
"x86_64-darwin"
]

View File

@@ -1,17 +0,0 @@
#!/usr/bin/env nix-shell
#!nix-shell -i bash -p jq
set -euo pipefail
# https://stackoverflow.com/a/246128
SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )
repo=https://github.com/nixos/nixpkgs
branch=nixpkgs-unstable
file=$SCRIPT_DIR/pinned-nixpkgs.json
defaultRev=$(git ls-remote "$repo" refs/heads/"$branch" | cut -f1)
rev=${1:-$defaultRev}
sha256=$(nix-prefetch-url --unpack "$repo/archive/$rev.tar.gz" --name source)
jq -n --arg rev "$rev" --arg sha256 "$sha256" '$ARGS.named' | tee /dev/stderr > $file

View File

@@ -1,8 +1,6 @@
let
requiredVersion = import ./lib/minver.nix;
in
let requiredVersion = import ./lib/minver.nix; in
if !builtins ? nixVersion || builtins.compareVersions requiredVersion builtins.nixVersion == 1 then
if ! builtins ? nixVersion || builtins.compareVersions requiredVersion builtins.nixVersion == 1 then
abort ''

8
doc/.gitignore vendored Normal file
View File

@@ -0,0 +1,8 @@
*.chapter.xml
*.section.xml
.version
functions/library/generated
functions/library/locations.xml
highlightjs
manual-full.xml
out

116
doc/Makefile Normal file
View File

@@ -0,0 +1,116 @@
MD_TARGETS=$(addsuffix .xml, $(basename $(shell find . -type f -regex '.*\.md$$' -not -name README.md)))
PANDOC ?= pandoc
pandoc_media_dir = media
# NOTE: Keep in sync with NixOS manual (/nixos/doc/manual/md-to-db.sh) and conversion script (/maintainers/scripts/db-to-md.sh).
# TODO: Remove raw-attribute when we can get rid of DocBook altogether.
pandoc_commonmark_enabled_extensions = +attributes+fenced_divs+footnotes+bracketed_spans+definition_lists+pipe_tables+raw_attribute
# Not needed:
# - docbook-reader/citerefentry-to-rst-role.lua (only relevant for DocBook → MarkDown/rST/MyST)
pandoc_flags = --extract-media=$(pandoc_media_dir) \
--lua-filter=$(PANDOC_LUA_FILTERS_DIR)/diagram-generator.lua \
--lua-filter=build-aux/pandoc-filters/myst-reader/roles.lua \
--lua-filter=build-aux/pandoc-filters/link-unix-man-references.lua \
--lua-filter=build-aux/pandoc-filters/docbook-writer/rst-roles.lua \
--lua-filter=build-aux/pandoc-filters/docbook-writer/labelless-link-is-xref.lua \
-f commonmark$(pandoc_commonmark_enabled_extensions)+smart
.PHONY: all
all: validate format out/html/index.html out/epub/manual.epub
.PHONY: debug
debug:
nix-shell --run "xmloscopy --docbook5 ./manual.xml ./manual-full.xml"
.PHONY: format
format: doc-support/result
find . -iname '*.xml' -type f | while read f; do \
echo $$f ;\
xmlformat --config-file "doc-support/result/xmlformat.conf" -i $$f ;\
done
.PHONY: fix-misc-xml
fix-misc-xml:
find . -iname '*.xml' -type f \
-exec ../nixos/doc/varlistentry-fixer.rb {} ';'
.PHONY: clean
clean:
rm -f ${MD_TARGETS} doc-support/result .version manual-full.xml functions/library/locations.xml functions/library/generated
rm -rf ./out/ ./highlightjs ./media
.PHONY: validate
validate: manual-full.xml doc-support/result
jing doc-support/result/docbook.rng manual-full.xml
out/html/index.html: doc-support/result manual-full.xml style.css highlightjs
mkdir -p out/html
xsltproc \
--nonet --xinclude \
--output $@ \
doc-support/result/xhtml.xsl \
./manual-full.xml
mkdir -p out/html/highlightjs/
cp -r highlightjs out/html/
cp -r $(pandoc_media_dir) out/html/
cp ./overrides.css out/html/
cp ./style.css out/html/style.css
mkdir -p out/html/images/callouts
cp doc-support/result/xsl/docbook/images/callouts/*.svg out/html/images/callouts/
chmod u+w -R out/html/
out/epub/manual.epub: manual-full.xml
mkdir -p out/epub/scratch
xsltproc --nonet \
--output out/epub/scratch/ \
doc-support/result/epub.xsl \
./manual-full.xml
cp -r $(pandoc_media_dir) out/epub/scratch/OEBPS
cp ./overrides.css out/epub/scratch/OEBPS
cp ./style.css out/epub/scratch/OEBPS
mkdir -p out/epub/scratch/OEBPS/images/callouts/
cp doc-support/result/xsl/docbook/images/callouts/*.svg out/epub/scratch/OEBPS/images/callouts/
echo "application/epub+zip" > mimetype
zip -0Xq "out/epub/manual.epub" mimetype
rm mimetype
cd "out/epub/scratch/" && zip -Xr9D "../manual.epub" *
rm -rf "out/epub/scratch/"
highlightjs: doc-support/result
mkdir -p highlightjs
cp -r doc-support/result/highlightjs/highlight.pack.js highlightjs/
cp -r doc-support/result/highlightjs/LICENSE highlightjs/
cp -r doc-support/result/highlightjs/mono-blue.css highlightjs/
cp -r doc-support/result/highlightjs/loader.js highlightjs/
manual-full.xml: ${MD_TARGETS} .version functions/library/locations.xml functions/library/generated *.xml **/*.xml **/**/*.xml
xmllint --nonet --xinclude --noxincludenode manual.xml --output manual-full.xml
.version: doc-support/result
ln -rfs ./doc-support/result/version .version
doc-support/result: doc-support/default.nix
(cd doc-support; nix-build)
functions/library/locations.xml: doc-support/result
ln -rfs ./doc-support/result/function-locations.xml functions/library/locations.xml
functions/library/generated: doc-support/result
ln -rfs ./doc-support/result/function-docs functions/library/generated
%.section.xml: %.section.md
$(PANDOC) $^ -t docbook \
$(pandoc_flags) \
-o $@
%.chapter.xml: %.chapter.md
$(PANDOC) $^ -t docbook \
--top-level-division=chapter \
$(pandoc_flags) \
-o $@

View File

@@ -1,394 +1,12 @@
# Contributing to the Nixpkgs reference manual
This directory houses the sources files for the Nixpkgs reference manual.
# Nixpkgs/doc
> [!IMPORTANT]
> We are actively restructuring our documentation to follow the [Diátaxis framework](https://diataxis.fr/)
>
> Going forward, this directory should **only** contain [reference documentation](https://nix.dev/contributing/documentation/diataxis#reference).
> For tutorials, guides and explanations, contribute to <https://nix.dev/> instead.
>
> We are actively working to generate **all** reference documentation from the [doc-comments](https://github.com/NixOS/rfcs/blob/master/rfcs/0145-doc-strings.md) present in code.
> This also provides the benefit of using `:doc` in the `nix repl` to view reference documentation locally on the fly.
This directory houses the sources files for the Nixpkgs manual.
For documentation only relevant for contributors, use Markdown files next to the source and regular code comments.
You can find the [rendered documentation for Nixpkgs `unstable` on nixos.org](https://nixos.org/manual/nixpkgs/unstable/).
> [!TIP]
> Feedback for improving support for parsing and rendering doc-comments is highly appreciated.
> [Open an issue](https://github.com/NixOS/nixpkgs/issues/new?labels=6.topic%3A+documentation&title=Doc%3A+) to request bugfixes or new features.
[Docs for Nixpkgs stable](https://nixos.org/manual/nixpkgs/stable/) are also available.
Rendered documentation:
- [Unstable (from master)](https://nixos.org/manual/nixpkgs/unstable/)
- [Stable (from latest release)](https://nixos.org/manual/nixpkgs/stable/)
If you want to contribute to the documentation, [here's how to do it](https://nixos.org/manual/nixpkgs/unstable/#chap-contributing).
The rendering tool is [nixos-render-docs](../pkgs/by-name/ni/nixos-render-docs), sometimes abbreviated `nrd`.
## Contributing to this documentation
You can quickly check your edits with `nix-build`:
```ShellSession
$ cd /path/to/nixpkgs
$ nix-build doc
```
If the build succeeds, the manual will be in `./result/share/doc/nixpkgs/manual.html`.
### devmode
The shell in the manual source directory makes available a command, `devmode`.
It is a daemon, that:
1. watches the manual's source for changes and when they occur — rebuilds
2. HTTP serves the manual, injecting a script that triggers reload on changes
3. opens the manual in the default browser
### Testing redirects
Once you have a successful build, you can open the relevant HTML (path mentioned above) in a browser along with the anchor, and observe the redirection.
Note that if you already loaded the page and *then* input the anchor, you will need to perform a reload. This is because browsers do not re-run client JS code when only the anchor has changed.
## Syntax
As per [RFC 0072](https://github.com/NixOS/rfcs/pull/72), all new documentation content should be written in [CommonMark](https://commonmark.org/) Markdown dialect.
Additional syntax extensions are available, all of which can be used in NixOS option documentation. The following extensions are currently used:
#### Tables
Tables, using the [GitHub-flavored Markdown syntax](https://github.github.com/gfm/#tables-extension-).
#### Anchors
Explicitly defined **anchors** on headings, to allow linking to sections. These should be always used, to ensure the anchors can be linked even when the heading text changes, and to prevent conflicts between [automatically assigned identifiers](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/auto_identifiers.md).
It uses the widely compatible [header attributes](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/attributes.md) syntax:
```markdown
## Syntax {#sec-contributing-markup}
```
> [!Note]
> NixOS option documentation does not support headings in general.
#### Inline Anchors
Allow linking arbitrary place in the text (e.g. individual list items, sentences…).
They are defined using a hybrid of the link syntax with the attributes syntax known from headings, called [bracketed spans](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/bracketed_spans.md):
```markdown
- []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGApps*` hook will prepend it to `XDG_DATA_DIRS`.
```
#### Automatic links
If you **omit a link text** for a link pointing to a section, the text will be substituted automatically. For example `[](#chap-contributing)`.
This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/using/syntax.html#targets-and-cross-referencing).
#### HTML
Inlining HTML is not allowed. Parts of the documentation gets rendered to various non-HTML formats, such as man pages in the case of NixOS manual.
#### Roles
If you want to link to a man page, you can use `` {manpage}`nix.conf(5)` ``. The references will turn into links when a mapping exists in [`doc/manpage-urls.json`](./manpage-urls.json).
Please keep the `manpage-urls.json` file alphabetically sorted.
A few markups for other kinds of literals are also available:
- `` {command}`rm -rfi` ``
- `` {env}`XDG_DATA_DIRS` ``
- `` {file}`/etc/passwd` ``
- `` {option}`networking.useDHCP` ``
- `` {var}`/etc/passwd` ``
These literal kinds are used mostly in NixOS option documentation.
This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html#roles-an-in-line-extension-point). Though, the feature originates from [reStructuredText](https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-manpage) with slightly different syntax.
#### Admonitions
Set off from the text to bring attention to something.
It uses pandocs [fenced `div`s syntax](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/fenced_divs.md):
```markdown
::: {.warning}
This is a warning
:::
```
The following are supported:
- `caution`
- `important`
- `note`
- `tip`
- `warning`
- `example`
Example admonitions require a title to work.
If you don't provide one, the manual won't be built.
```markdown
::: {.example #ex-showing-an-example}
# Title for this example
Text for the example.
:::
```
#### [Definition lists](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/definition_lists.md)
For defining a group of terms:
```markdown
pear
: green or yellow bulbous fruit
watermelon
: green fruit with red flesh
```
## Commit conventions
- Make sure you read about the [commit conventions](../CONTRIBUTING.md#commit-conventions) common to Nixpkgs as a whole.
- If creating a commit purely for documentation changes, format the commit message in the following way:
```
doc: (documentation summary)
(Motivation for change, relevant links, additional information.)
```
Examples:
* doc: update the kernel config documentation to use `nix-shell`
* doc: add information about `nix-update-script`
Closes #216321.
- If the commit contains more than just documentation changes, follow the commit message format relevant for the rest of the changes.
## Documentation conventions
In an effort to keep the Nixpkgs manual in a consistent style, please follow the conventions below, unless they prevent you from properly documenting something.
In that case, please open an issue about the particular documentation convention and tag it with a "needs: documentation" label.
When needed, each convention explain why it exists, so you can make a decision whether to follow it or not based on your particular case.
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.
### Callouts and examples
Use the [admonition syntax](#admonitions) for callouts and examples.
### Provide self-contained 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.
Example code should be such that it can be passed to `pkgs.callPackage`.
Instead of something like:
```nix
pkgs.dockerTools.buildLayeredImage {
name = "hello";
contents = [ pkgs.hello ];
}
```
Write something like:
```nix
{ dockerTools, hello }:
dockerTools.buildLayeredImage {
name = "hello";
contents = [ hello ];
}
```
### REPLs
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.
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.
### Headings for inputs, outputs and examples
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.
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
Some explanation about the function here.
Describe a particular scenario, and point to [](#ex-dockerTools-buildImage), which is an example demonstrating it.
### Inputs
Documentation for the inputs of `buildImage`.
Perhaps even point to [](#ex-dockerTools-buildImage) again when talking about something specifically linked to it.
### Passthru outputs
Documentation for any passthru outputs of `buildImage`.
### Examples
Note that this is the last nested heading in the `buildImage` section.
:::{.example #ex-dockerTools-buildImage}
# Using `buildImage`
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.
## 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.
*`name`* (String)
: The name of the resulting image.
*`config`* (Attribute set)
: Introduce the parameter. Maybe you have a test to make sure `{ }` is a sensible default; then you can say: these attributes are optional; `{ }` is a valid argument.
`outputHash` (String; _optional_)
: A brief explanation including when and when not to pass this attribute.
: _Default:_ the output path's hash.
```
Checklist:
- Start with a synopsis, to show the order of positional arguments.
- Metavariables are in emphasized code spans: ``` *`arg1`* ```. Metavariables are placeholders where users may write arbitrary expressions. This includes positional arguments.
- Attribute names are regular code spans: ``` `attr1` ```. These identifiers can _not_ be picked freely by users, so they are _not_ metavariables.
- _optional_ attributes have a _`Default:`_ if it's easily described as a value.
- _optional_ attributes have a _`Default behavior:`_ if it's not easily described using a value.
- Nix types aren't in code spans, because they are not code
- Nix types are capitalized, to distinguish them from the camelCase Module System types, which _are_ code and behave like functions.
#### Examples
To define a referenceable figure use the following fencing:
```markdown
:::{.example #an-attribute-set-example}
# An attribute set example
You can add text before
```nix
{ a = 1; b = 2;}
```
and after code fencing
:::
```
Defining examples through the `example` fencing class adds them to a "List of Examples" section after the Table of Contents.
Though this is not shown in the rendered documentation on nixos.org.
#### Figures
To define a referenceable figure use the following fencing:
```markdown
::: {.figure #nixos-logo}
# NixOS Logo
![NixOS logo](./nixos_logo.png)
:::
```
Defining figures through the `figure` fencing class adds them to a `List of Figures` after the `Table of Contents`.
Though this is not shown in the rendered documentation on nixos.org.
#### Footnotes
To add a foonote explanation, use the following syntax:
```markdown
Sometimes it's better to add context [^context] in a footnote.
[^context]: This explanation will be rendered at the end of the chapter.
```
#### Inline comments
Inline comments are supported with following syntax:
```markdown
<!-- This is an inline comment -->
```
The comments will not be rendered in the rendered HTML.
#### Link reference definitions
Links can reference a label, for example, to make the link target reusable:
```markdown
::: {.note}
Reference links can also be used to [shorten URLs][url-id] and keep the markdown readable.
:::
[url-id]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/doc/README.md
```
This syntax is taken from [CommonMark](https://spec.commonmark.org/0.30/#link-reference-definitions).
#### Typographic replacements
Typographic replacements are enabled. Check the [list of possible replacement patterns check](https://github.com/executablebooks/markdown-it-py/blob/3613e8016ecafe21709471ee0032a90a4157c2d1/markdown_it/rules_core/replacements.py#L1-L15).
## Getting help
If you need documentation-specific help or reviews, ping [@NixOS/documentation-team](https://github.com/orgs/nixos/teams/documentation-team) on your pull request.
If you're only getting started with Nix, go to [nixos.org/learn](https://nixos.org/learn).

View File

@@ -1,3 +0,0 @@
document.addEventListener('DOMContentLoaded', function(event) {
anchors.add('h1[id]:not(div.note h1, div.warning h1, div.tip h1, div.caution h1, div.important h1), h2[id]:not(div.note h2, div.warning h2, div.tip h2, div.caution h2, div.important h2), h3[id]:not(div.note h3, div.warning h3, div.tip h3, div.caution h3, div.important h3), h4[id]:not(div.note h4, div.warning h4, div.tip h4, div.caution h4, div.important h4), h5[id]:not(div.note h5, div.warning h5, div.tip h5, div.caution h5, div.important h5), h6[id]:not(div.note h6, div.warning h6, div.tip h6, div.caution h6, div.important h6)');
});

9
doc/anchor.min.js vendored

File diff suppressed because one or more lines are too long

View File

@@ -0,0 +1,23 @@
--[[
Converts Code AST nodes produced by pandocs DocBook reader
from citerefentry elements into AST for corresponding role
for reStructuredText.
We use subset of MyST syntax (CommonMark with features from rST)
so lets use the rST AST for rST features.
Reference: https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-manpage
]]
function Code(elem)
elem.classes = elem.classes:map(function (x)
if x == 'citerefentry' then
elem.attributes['role'] = 'manpage'
return 'interpreted-text'
else
return x
end
end)
return elem
end

View File

@@ -0,0 +1,11 @@
--[[
Converts some HTML elements commonly used in Markdown to corresponding DocBook elements.
]]
function RawInline(elem)
if elem.format == 'html' and elem.text == '<kbd>' then
return pandoc.RawInline('docbook', '<keycap>')
elseif elem.format == 'html' and elem.text == '</kbd>' then
return pandoc.RawInline('docbook', '</keycap>')
end
end

View File

@@ -0,0 +1,34 @@
--[[
Converts Link AST nodes with empty label to DocBook xref elements.
This is a temporary script to be able use cross-references conveniently
using syntax taken from MyST, while we still use docbook-xsl
for generating the documentation.
Reference: https://myst-parser.readthedocs.io/en/latest/using/syntax.html#targets-and-cross-referencing
]]
local function starts_with(start, str)
return str:sub(1, #start) == start
end
local function escape_xml_arg(arg)
amps = arg:gsub('&', '&amp;')
amps_quotes = amps:gsub('"', '&quot;')
amps_quotes_lt = amps_quotes:gsub('<', '&lt;')
return amps_quotes_lt
end
function Link(elem)
has_no_content = #elem.content == 0
targets_anchor = starts_with('#', elem.target)
has_no_attributes = elem.title == '' and elem.identifier == '' and #elem.classes == 0 and #elem.attributes == 0
if has_no_content and targets_anchor and has_no_attributes then
-- xref expects idref without the pound-sign
target_without_hash = elem.target:sub(2, #elem.target)
return pandoc.RawInline('docbook', '<xref linkend="' .. escape_xml_arg(target_without_hash) .. '" />')
end
end

View File

@@ -0,0 +1,44 @@
--[[
Converts AST for reStructuredText roles into corresponding
DocBook elements.
Currently, only a subset of roles is supported.
Reference:
List of roles:
https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html
manpage:
https://tdg.docbook.org/tdg/5.1/citerefentry.html
file:
https://tdg.docbook.org/tdg/5.1/filename.html
]]
function Code(elem)
if elem.classes:includes('interpreted-text') then
local tag = nil
local content = elem.text
if elem.attributes['role'] == 'manpage' then
tag = 'citerefentry'
local title, volnum = content:match('^(.+)%((%w+)%)$')
if title == nil then
-- No volnum in parentheses.
title = content
end
content = '<refentrytitle>' .. title .. '</refentrytitle>' .. (volnum ~= nil and ('<manvolnum>' .. volnum .. '</manvolnum>') or '')
elseif elem.attributes['role'] == 'file' then
tag = 'filename'
elseif elem.attributes['role'] == 'command' then
tag = 'command'
elseif elem.attributes['role'] == 'option' then
tag = 'option'
elseif elem.attributes['role'] == 'var' then
tag = 'varname'
elseif elem.attributes['role'] == 'env' then
tag = 'envar'
end
if tag ~= nil then
return pandoc.RawInline('docbook', '<' .. tag .. '>' .. content .. '</' .. tag .. '>')
end
end
end

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