Existing deployments using MySQL or Percona Server with `services.mysql`
do not restrict authentication to the root@localhost user allowing any
user on the system to log in without a password.
With this changes:
* new deployments will use the `auth_socket` authentication by default
to only allow the local root user to log in as the MySQL root user
* existing deployments with a stateVersion > 26.05 will also be moved to
the `auth_socket` authentication
* existing deployments with a stateVersion <= 26.05 have a warning
logged when the local authentication seems to be open
Users can disable this behavior by setting `services.mysql.secureSuperUserByDefault`
to `false`.
(cherry picked from commit 1d6947077e)
This will apply to the stable release branches too, but that seems
unavoidable: we use `nixpkgs-unstable` in `ci/pinned.json`, which
means that the development shell for stable release branches is based
on the unstable branch. Once we drop support for a system on the
unstable branch, it can no longer be used for Nixpkgs development on
the next pin, even when targeting already‐released stable branches.
Since Nixpkgs contributors would generally be expected to be less
likely to be using deprecated platforms, and we usually operate with
a backport workflow where changes target the unstable branch first,
this is probably acceptable. A potential alternative would be to pin
the stable branch for CI instead.
(cherry picked from commit 8ccb319a2e)
This reverts commit 309d5c169b.
The instructions don't work on NixOS 25.11: Nix 2.31 doesn't suport SRI
hashes in builtins.fetchTarball. Moreover the NixOS manual shouldn't
recomment using experimental commands.
(cherry picked from commit e0a630cb36)
It was marked broken in 1dc27975d1 (May
2025).
But the bug was fixed in October 2025 with:
d8c28ab3f3/
Since there were new commits, but no release. I asked the upstream
maintainer to push the 1.6.3 tag.
I tested it works by importing the library:
nix-shell -p "octave.withPackages (ps: [ ps.optim ])" --run 'octave
--eval "pkg load optim; disp(\"Success!\")"'
(cherry picked from commit cbbc21f9f8)
zigbee2mqtt supports listening on unix domain sockets, if a path is
specified in the `frontend.host` config key.
This currently fails with the following log message:
> zigbee2mqtt[4551]: Error: listen EAFNOSUPPORT: address family not supported /path/to/zigbee2mqtt.sock
Listening on unix domain sockets is a reasonable thing to have enabled,
so let's add it to the list.
(cherry picked from commit 93c9f9cde4)
PR #485779 dropped the gpgui.desktop install, reasoning that all gpgui
files require the proprietary gpgui binary. But the desktop file is not
gpgui-only: its Exec is `gpclient launch-gui %u`, the free CLI subcommand
that receives the SAML auth callback. Without it the
x-scheme-handler/globalprotectcallback handler is unregistered, so
external-browser SSO (`gpclient connect --browser <x>`) hangs after login
- the browser opens globalprotectcallback://<data> with nothing to handle
it, and the auth cookie never returns to the waiting connect process.
Reinstall the desktop file on Linux and point Exec at the gpclient in
$out, matching the pre-2.5.1 behaviour.
(cherry picked from commit 4d50d7d087)
A per-connection instance spawned by an Accept=yes socket (e.g.
foo@1234.service) has an implicit socket of foo.socket, but the implicit
name was derived from the template base name including the trailing "@",
yielding foo@.socket. That never matches an active unit, so such running
instances were treated as non-socket-activated and the activation script
tried to start them directly on a configuration switch. That fails
because there is no connection socket to pass, sending the instance into
a restart loop.
Strip the trailing "@" so the implicit socket resolves correctly; the
running instances are then stopped and their socket restarted, leaving
systemd to spawn fresh instances for new connections.
Resolves: https://github.com/NixOS/nixpkgs/issues/533205
Assisted-by: Claude:claude-opus-4-8
(cherry picked from commit ad3e95b093)
The performance comparison summary previously stated it compared against
"its pull request base branch (e.g., 'master')" regardless of the actual
base branch.
Plumb the base branch classification computed in prepare.js through the
eval workflow to the `compare` derivation so the summary names the real
base branch (e.g. "staging-25.11"). The local `eval.full` helper defaults
to "master", matching its touched-files convention.
Assisted-by: claude-code with claude-opus-4-8[1m]-high
(cherry picked from commit a100d091a0)
Adapt the package to upstream's packaging refactor in this release:
- Upstream now downloads a prebuilt ffmpeg from LizardByte/build-deps at
cmake configure time. Fetch it via fetchzip and point cmake at it with
FFMPEG_PREPARED_BINARIES. Sunshine pins build-deps via a git submodule
at third-party/build-deps; the matching release tag is derived from
that commit. Extend updater.sh to refresh both the tag and the
per-architecture tarball hashes.
- The boost version pin in cmake/dependencies/Boost_Sunshine.cmake
bumped to 1.89.0. Switch the substitution to a sed regex so future
upstream bumps don't break the patch.
- The .desktop file now Exec's `/usr/bin/env systemctl start --u
app-@PROJECT_FQDN@`; update the replace-fail pattern. The remaining
@VAR@ placeholders are handled by cmake's configure_file(@ONLY) now.
- packaging/linux/sunshine.service.in was renamed to
packaging/linux/app-dev.lizardbyte.app.Sunshine.service.in and now
uses @SUNSHINE_SERVICE_START_COMMAND@/@SUNSHINE_SERVICE_STOP_COMMAND@
instead of @SUNSHINE_EXECUTABLE_PATH@. Drop the postPatch subst-var-by
lines and set SUNSHINE_EXECUTABLE_PATH via a cmake flag instead.
- cmake/packaging/linux.cmake now installs the .desktop file itself, so
the redundant postInstall is removed.
- Add shaderc (glslc), vulkan-loader, and pipewire to inputs, all new
configure-time requirements.
- glad's generator wants jinja2 + setuptools at configure time. Provide
them via python3.withPackages and set GLAD_SKIP_PIP_INSTALL=ON so
cmake doesn't try to pip-install.
Assisted-by: Claude Code 4.7
(cherry picked from commit 391d69d880)
The script broke when invoked from the package directory: nix-update
looked for a default.nix in the cwd. Move to the nixpkgs root before
calling it.
`--generate-lockfile` and the npmDepsHash refresh are mutually exclusive
in a single nix-update pass, so the ui subpackage hash was never
updated.
Split the ui update into two passes.
Also restore the early-exit when UPDATE_NIX_OLD_VERSION matches, quote
$version, and add the shellcheck shell directive.
Assisted-by: Claude Code 4.7
(cherry picked from commit 0085f4f7a8)
We discussed in #staging:nixos.org (Matrix) that the drivers itself are
helpful for development, but that executing them in Hydra don't provide
a benefit over executing the tests themself.
(cherry picked from commit 04f9176915)
This fixes eval on staging, because there Python 3.14 is the default and
backports-zstd is null, because it is included by default.
(cherry picked from commit 0fd69dc26c)
With the addition of `remap-path-prefix` to buildRustCrate, we now
can pull in two rustc variants when cross compiling, since the rustc
that is string-interpolated for passing the remap flag is not pulled
from the proper package-set. Depending on the host platform used, this
rustc variant may not even build. In order to only pull in one variant,
and to properly mask the rustc used for building with the
remap-path-prefix flag, rustc is passed explicitly from pkgsBuildHost.
(cherry picked from commit 1729f540be)
Although we had `systemd` included in `buildFeatures`, it didn't reach
`$out/bin/pizauth`, because upstream's Makefile used
`target/release/pizauth` as a Makefile target that `cargo build
--release` (with or without `--features=systemd`) solves.
(cherry picked from commit 583024221d)
The only difference on all vanilla kernels across {aarch64,x86_64}-linux
is that aarch64-linux 6.18 gets PREEMPT_LAZY consistently.
(cherry picked from commit 143dd2e587)
When setting a non-`source` update channel, the build fails on
x86_64-darwin.
The build fails with:
```
source not found twice in ChannelPrefs
source
stringWithCString:encoding:
```
Which definitely means it is caused by the strings command here.
When manually executing the strings command on the file, I can repeat
getting only one `source` result on x86 mac, while getting two on arm64
or linux. After digging around, I tried with the flag `-arch all`, and
both `source` values are found on x86 mac. Full command: `strings -n 3
-arch all $binary`.
Also reported to upstream in https://github.com/zotero/zotero/pull/5926
(cherry picked from commit 96a484e28e)
Our zotero build had the version string 9.0.2.SOURCE.000000000, while
upstream releases of course only have 9.0.2. This leaks in HTTP headers
and JavaScript functions, which is used e.g. by Better BibTeX. This
add-on actually partially fails due to the unexpected version string.
This commit switches to the release channel. This also would enable
updates, which fail/hang because the firefox updater is not included in
our firefox builds.
Instead of patching app/scripts/dir_build, I opt to call
app/scripts/prepare_build and app/build.sh directly. This also brings us
closer to cross-compile support (as we now select the build system and
architecture from targetHost).
(cherry picked from commit e12e834060)
This now uses reqwest, so HTTP_PROXY works.
It also now has a --fetch-concurrency flag to make the amount of
download threads configurable.
(cherry picked from commit cd7818254b)
The current update script hashes the archive instead of the contents and
therefore fails (see the [nixpkgs-update logs][0]). This changes that
behavior to hash the unpacked contents before anything is altered.
[0]: https://nixpkgs-update-logs.nix-community.org/melos/2026-06-03.log
(cherry picked from commit 175f077ef5)
As reported in
https://github.com/NixOS/nixpkgs/pull/475929#issuecomment-4671420403,
2.7.3 is nowhere to be found / has been scrubbed upstream.
We're only still able to build this because the FOD is in
cache.nixos.org.
Meanwhile 2.7.2.20 has been tagged however, and it has the patches from
https://github.com/zeroc-ice/mcpp/pull/12 merged, so let's update our
derivation to that.
We still keep an empty `patches = []` around, as we still don't want to
use the patches from the non-forked mcpp.
(cherry picked from commit e49bc27926)
This asserts that the names of derivations created with requireFile
are not influenced by differing package sets.
(cherry picked from commit cdf24c1fec)
When not using stdenvNoCC with a package-set setup for
cross-compilation, the host platform's target triplet is added as a
suffix to the derivation name, invalidating the requireFile FOD. Using
stdenvNoCC prevents that due to some logic in `make-derivation.nix`,
which more closely matches the behavior before switching to `extendMkDerivation`.
(cherry picked from commit d2d149334a)
The commit 011471c7f2 ("fetchgit: disable git maintenance") disabled
git's maintenance mode, but that does not affect git repositories with
submodules.
Switch to using the GIT_CONFIG_* environment variables. This is done in
a way to make the approach more generic, but also kinda not the best
("insane") so that it works with any future change, even with
`impureEnvVars`.
Maybe `git -c maintenance.auto=false` can work but I cannot figure out
how to use that here. I would prefer disabling maintenance mode in Git's
derivation itself but did not find any build-time knob to toggle that.
(cherry picked from commit 88cfc54552)
Before bcachefs-tools v1.34.0, scrub command was `bcachefs data scrub
…`, then it got `bcachefs scrub …` with the old one still working. The
old one doesn't work anymore.
Fix the command for `services.bcachefs.autoScrub`, including version switch.
(cherry picked from commit 84ef80c6e7)
The passthru has been added to give a migration path, but those outputs
were not present on the 25.11's `nodejs` derivation. Removing those
is helpful to use them to discriminate between the slim and non-slim
variants for derivations that accept one or the other.
(cherry picked from commit 3c9cf6210c)
hakyll 4.17 is 4.16.8.0, but has its version number updated so it is in
keeping with Haskell's PVP.
> This release is nearly identical to 4.16.8.0. However, 4.16.8.0
> contains a breaking change which was not caught. Therefore, release
> 4.16.8.0 is deprecated on Hackage, and 4.17.0.0 should be preferred.
WSL and other container-brained-but-not-really systems may not want a kernel,
and now that bootspec is no longer optional, this pulls one in anyway.
(cherry picked from commit 1fdf8fd586)
Release notes: https://github.com/mostlygeek/llama-swap/releases
Additional changes:
1. One of the tests now creates a bash script, so we need to fix said
bash script's shebang.
2. The embedded UI has moved.
(cherry picked from commit c8fec47e78)
as is, plover has a desktop entry in the source tree but it is not
actually shipped in nixpkgs. we place it in the standard
$out/share/applications directory so it can be found by e.g. launchers.
(cherry picked from commit 7097b20ea1)
Xen Security Advisory CVE-2026-42488 / XSA-494
version 3
x86: mismatched mapcache metadata
Some shadow paging errors paths will switch the page-tables without
updating the currently running vCPU reference. This causes a mismatch
between the loaded page-tables and the mapcache metadata which can lead
to corruption of the mapcache.
Privilege escalation, Denial of Service (DoS) affecting the entire host,
and information leaks.
https://xenbits.xen.org/xsa/advisory-494.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
(cherry picked from commit c8ec62ac39)
ARM-only issue. Despite us not supporting Aarch64 Xen on NixOS, it costs us
nothing to add the patches.
Xen Security Advisory CVE-2025-10263 / XSA-493
version 2
Arm: Completion of memory accesses not guaranteed by completion of a TLBI
A hardware issue has been identified in certain Arm CPU designs. A
broadcast TLBI on one PE may complete before affected memory accesses
on another PE are globally observed. This may permit bypass of Stage 1
translation, Stage 2 translation, or GPT protection.
The erratum occurs when all of the following conditions are met:
- A PE (PEx) executes a store.
- Another PE (PEy) executes a TLBI instruction which applies to
Stage 1 only information, Stage 1 and 2 information, or GPT
information (but not Stage 2 only information), applies to the
Inner Shareable or Outer Shareable domain containing PEx, and
affects at least one of the bytes accessed by PEx's store.
- PEy executes a DSB instruction which is sufficient to complete the
TLBI instruction.
- Complex micro-architectural conditions occur.
When all conditions are met, PEy's DSB may complete before the global
observation of a portion of PEx's store which was affected by the TLB
invalidation. This store may complete at a later time, after memory
accesses which are ordered after the DSB.
The relevant TLB entries are invalidated correctly before the
completion of the DSB. This erratum does not affect reads.
For more details, please refer to the Arm Security Center:
https://developer.arm.com/Arm%20Security%20Center
A malicious guest may be able to write to memory it no longer has
permission to write to, after Xen has modified Stage 2 translation to
forbid writes to that location. This could allow a guest to escalate
its privileges to that of the hypervisor.
https://xenbits.xen.org/xsa/advisory-493.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
(cherry picked from commit 542f4fed39)
Xen Security Advisory CVE-2026-42489,CVE-2026-42490 / XSA-492
version 3
domctl lock open to abuse
To create and manage guests, domctl operations are used by the control
domain, a possible Xenstore domain, or by a domain controlling a
particular guest. Some of these operations may not be executed in
parallel, so a system-wide lock is used. The way that lock is acquired
is, however, not providing any fairness. This is CVE-2026-42489.
Furthermore, with XSM/Flask in use, the lock acquire will, for some
operations, occur ahead of any permission checking. This is
CVE-2026-42490.
A less privileged entity may stall an equally or more privileged entity,
potentially leading to a Denial od Service (DoS) of up to the entire
host.
https://xenbits.xen.org/xsa/advisory-492.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
(cherry picked from commit 3d1d9bee16)
Xen Security Advisory CVE-2026-42487 / XSA-491
version 2
x86 HVM I/O port list traversal
HVM guest I/O port accesses are subject to either emulation or at least
translation. Translations are managed by the device model (via
XEN_DOMCTL_ioport_mapping), and hence the linked list used may changed
at any time. Traversal of those lists (while handling guest I/O port
accesses) therefore needs synchronizing with updates, which was missing
so far.
A device model of a HVM guest can cause a hypervisor crash, causing a
Denial of Service (DoS) of the entire host. Privilege escalation and
information leaks cannot be ruled out.
https://xenbits.xen.org/xsa/advisory-491.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
(cherry picked from commit 1629ccf012)
Released a while ago. We had difficulties adding it to Nixpkgs at the time as
our Xen needed to be updated to the .3 release.
Xen Security Advisory CVE-2025-54518 / XSA-490
x86: CPU Opcode Cache corruption
AMD have disclosed a potential vulnerability in certain CPUs which can
cause instructions to execute at a higher privilege.
For more information, see:
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7052.html
Code of any privilege could escalate to a higher privilege, including
userspace to kernel, and guest to host.
https://xenbits.xen.org/xsa/advisory-490.html
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
(cherry picked from commit a343770e93)
pnpm9 is now EOL and should no longer be used (#529285)
Also update fetchPnpmDeps to fetcherVersion=4 as recommended
(cherry picked from commit 851cbf9e1e)
When the 'banner' option was removed in favour of settings.Banner,
it was made a path-typed option, but the current mkValueString doesn't
accept path-typed values so assigning a file to this option results in:
`error: unsupported type path: <store path>`
By adding the appropriate handling for mkValueString, this works as
expected.
(cherry picked from commit ef4ab8eaaa)
Use nixpkgs from the current directory because otherwise the npins used
could be outdated.
Also run npins upgrade as part of the script.
(cherry picked from commit 089cd8fbac)
Add a `services.prometheus.exporters.elasticsearch` module wrapping
`pkgs.prometheus-elasticsearch-exporter`, which also supports OpenSearch.
Credentials are kept out of the process arguments and the store via an
`environmentFile` carrying `ES_USERNAME`/`ES_PASSWORD` or `ES_API_KEY`,
which override any auth embedded in `--es.uri`. Collector toggles go
through the framework's `extraFlags`.
A NixOS test exercises the exporter against a single-node OpenSearch
instance.
Assisted-by: claude-code: claude-opus-4-8
(cherry picked from commit 7195e583ce)
Inspired by treefmt-nix's `config.build.check` option, add a similar
check function to `treefmt.withConfig`'s wrapper.
`check` is a function of `Path → Derivation`, which returns a derivation
that builds ok when the path is already formatted, or fails to build if
the wrapped-treefmt would change the path's formatting.
Add the `check` function, tests for it, and initial docs.
See treefmt-nix: https://github.com/numtide/treefmt-nix/blob/db947814/module-options.nix#L301-L349
(cherry picked from commit 134bfa753c)
This fixes#509315. The gappsWrapperArgsHook has to be invoked
explicitly as it is normally invoked in preFixupPhase, which is not
present in symlinkJoin.
(cherry picked from commit 3bd8e16832)
Test that the service runs and uses our configured (TCP) port.
This should prevent https://github.com/NixOS/nixpkgs/issues/475043
("nixos/scanservjs: settings (host/port) ignored in v3.0.4") from
happening again.
(cherry picked from commit 32157e1c52)
scanservjs has been ignoring the configuration options set by the NixOS
module since the v3.0.4 upgrade. This fixes it.
Create dirs/files in the NixOS module as needed by the new scanservjs
build.
Fixes: 7432e50d62 ("scanservjs: 2.27.1 -> 3.0.4")
Fixes: https://github.com/NixOS/nixpkgs/issues/475043 ("nixos/scanservjs: settings (host/port) ignored in v3.0.4")
Co-authored-by: Bjørn Forsman <bjorn.forsman@gmail.com>
(cherry picked from commit 008e87e5c2)
Since Hydra no longer builds the texlivePackages subtree, texsource containers
can now be treated as regular outputs in buildTeXLivePackage.
This also enables the withSources argument of buildTeXEnv to work as intended.
(cherry picked from commit 895c726b94)
rebar3 itself actually compiles, it's just the tests that are failing.
Patch to disable another warning until upstream fixes the tests.
(cherry picked from commit 09d3443b49)
MLX backends require xcrun metal/metalib which are unavailable in the
Nix sandbox. Pass -DOLLAMA_MLX_BACKENDS="" to cmake to skip the
Metal toolchain check. Core Metal/llama.cpp backend is unaffected.
(cherry picked from commit b195b40fb0)
Addresses two review comments — different reviewers, same direction:
* @SuperSandro2000 on the original PR #528150 (line 118 of
pkgs/by-name/ol/ollama/package.nix): "Why are we not using tag if
there is a tag?". Drop the SHA + `# tag b9509` shape that required
reviewers to cross-check the SHA matched the inline comment.
* @prusnak on this follow-up #528374: "I think we should use `tag`
instead of `rev`." `fetchFromGitHub`'s dedicated `tag` field is
preferred over `rev = "<tag-string>"` — same git object, same
tarball, same hash, but signals intent at the schema level and
renders into the store path nicely.
* Line 113 prose comment (the other half of SuperSandro's review on
#528150): "We should not repeat the version in this comment and
have to update that, too, on every update." Drop `currently b9509`
from the prose; the remaining text explains the mechanism (tracks
upstream's `LLAMA_CPP_VERSION` file, pre-staged because
FetchContent can't network in the sandbox) without naming a
specific version that would drift on every bump.
Pure source-readability change. `nix-build -A ollama --no-out-link`
on x86_64-linux produces the same store path as master, confirming
the tag resolves to the same git object → same tarball → same hash
→ no rebuild impact.
The same lines exist on `release-26.05` via the original backport
#528272; happy to mirror this fix there if you apply the
`backport release-26.05` label.
Assisted-by: Claude <noreply@anthropic.com>
(cherry picked from commit 1e9315fd0c)
Previously the eval comparison was skipped entirely when packages were
added or removed between revisions, leaving only a "stats were skipped"
message. cmp-stats already joins on the stats chunks present in both
revisions, so a comparison can still be produced. Always run it and add
a GitHub note caveating that the figures are approximate when the
package sets differ.
Assisted-by: claude-code with claude-opus-4-7[1m]-xhigh
(cherry picked from commit 25f9394b8a)
The built-in browser does not work and shows "TLS support is not
available". Fix this by wrapping `glib-networking` and adding it to the
environment variable `GIO_EXTRA_MODULES`.
Fixes: #528935
Signed-off-by: Felix Singer <felixsinger@posteo.net>
(cherry picked from commit d2a5c9bf0b)
Upstream's intended bypass is TrustedUids in fwupd.conf, but on NixOS
the fwupd-refresh uid is allocated at activation time and is not known
during evaluation. Add a polkit rule keyed on the user name instead.
(cherry picked from commit d9bf382cad)
When instantiating an environment with the Python interpreter built
with both free threading (aka. without GIL) and `pydebug`, the value
of `passthru.executable` doesn't match any installed file. This was
noticed when building CI pipelines that require the Python interpreter
built with both debug features and free threading.
The cause is that `executable` was built from `libPrefix`, which only
tracks the `t` suffix from `--without-gil` and not the `d` suffix from
`--with-pydebug`. `libPrefix` doubles as the stdlib install directory,
and cpython deliberately shares that directory between debug and
non-debug builds of a given version, so the `d` is intentionally
absent there.
This slipped through because cpython only ever installs a
`python$VERSION -> python$LDVERSION` symlink (e.g. `python3.13 ->
python3.13d`). For debug-only builds the old code happened to ask for
`python3.13`, which is that symlink, so it worked by accident. For
FT+debug, `libPrefix` is `python3.13t`, but cpython installs no such
file; only `python3.13` (symlink) and `python3.13td` (binary).
Fix: append `d` to `executable` (and to the `cp<ver>` wheel ABI tag in
`pythonABITags`) when `enableDebug` is true.
Reproducer for the problem as a bash script:
```bash
set -euo pipefail
nixpkgs="${1:-<nixpkgs>}" # Either custom path if provided, or just <nixpkgs>
read -r -d '' expr <<EOF || true
let
pkgs = import ${nixpkgs} { };
py = pkgs.python313FreeThreading.override {
enableDebug = true;
self = py;
pythonAttr = "python313FreeThreading";
};
in py
EOF
executable=$(nix-instantiate --eval --json --expr "($expr).executable" | tr -d '"')
echo "passthru.executable = ${executable}"
out=$(nix-build --no-out-link --expr "$expr")
echo "store path: ${out}"
if [[ -e "${out}/bin/${executable}" ]]; then
echo "result: OK (binary exists)"
exit 0
fi
echo "result: FAIL (${out}/bin/${executable} not found)"
echo "actually installed:"
ls "${out}/bin/" | grep '^python3\.' | sed 's/^/ /'
exit 1
```
(cherry picked from commit fa6a2e8f1f)
The problem was that Cargo didn't have a way to find a linker for the
build platform which is required to link the build script. So, when
cross compiling we add in the standard build -> build compiler so that
it can compile the build script.
This fix was taken from the ideas of @magicquark and @nwf in
https://github.com/NixOS/nixpkgs/issues/523378.
Fixes#523378
(cherry picked from commit bbe694f8ea)
Two darwin-only issues surfaced when building on x86_64-darwin:
1. The conditional postPatch removed three test files
(ml/backend/ggml/ggml_test.go, ml/nn/pooling/pooling_test.go,
model/models/nemotronh/model_omni_test.go) that no longer exist
in v0.30.5 upstream. The `rm` failed with "No such file or directory"
and aborted patchPhase. Tests in the new paths
(e.g. fs/ggml/ggml_test.go) pass on darwin without removal — verified
via the test phase in this commit's local build.
2. preFixup ran `patchelf --shrink-rpath` unconditionally; patchelf is
ELF-only and darwin's Mach-O dylibs don't carry the build-dir RPATH
problem in the first place. Gated on stdenv.hostPlatform.isLinux.
Verified: nix-build -A ollama on x86_64-darwin (macOS 15.6.1, Sequoia)
lands /nix/store/.../ollama-0.30.5; checkPhase green for all listed
packages including x/models/gemma4; ollama --version reports 0.30.5.
Assisted-by: Claude Opus 4.7 <noreply@anthropic.com>
(cherry picked from commit bba51cb247)
Upstream patch release; notably fixes a divide-by-zero crash in
gemma3:12b. Bumps the vendored llama.cpp pin b9493 -> b9509 to match
upstream's LLAMA_CPP_VERSION. Verified ollama-cuda + ollama-vulkan
build on x86_64-linux.
https://github.com/ollama/ollama/releases/tag/v0.30.5
Assisted-by: Claude Opus 4.7 <noreply@anthropic.com>
(cherry picked from commit 0e1071782c)
Two layers were missing for ollama-vulkan after the 0.30.x bump's switch to
per-accelerator runners via ExternalProject_Add:
1. spirv-headers wasn't in nativeBuildInputs, so the parent cmake configure
never even saw `SPIRV-HeadersConfig.cmake`. Add it (header-only — native
is the right slot).
2. The runner sub-builds (`ollama-llama-server-vulkan` et al.) are launched
by `cmake/local.cmake`'s `ExternalProject_Add`, whose child cmake process
inherits env vars but not the parent's `-D` flags. Even after fixing
(1), the child's `find_package(SPIRV-Headers REQUIRED)` at
`ggml-vulkan/CMakeLists.txt:14` couldn't see the config, and once that
was worked around with `CMAKE_PREFIX_PATH` as env, the compile then
failed with `fatal error: spirv/unified1/spirv.hpp` — because
upstream's `target_link_libraries(ggml-vulkan PRIVATE Vulkan::Vulkan)`
notably does NOT link `SPIRV-Headers::SPIRV-Headers`, so the interface
include path the cmake config exports never flows into the compile
commands. Force the include via `NIX_CFLAGS_COMPILE` rather than
patching upstream's CMakeLists across llama.cpp pins.
Verified: `ollama-vulkan` builds end-to-end; `$out/lib/ollama/vulkan/libggml-vulkan.so`
is present (not a silent CPU fallback like the cuda variant suffered in
the first 0.30 attempt).
🤖 Assisted by Claude
(cherry picked from commit 6432d78bff)
Notable upstream build changes folded into this bump:
* llama.cpp moved from in-tree vendoring to CMake FetchContent, pinned
via the `LLAMA_CPP_VERSION` file at the repo root (b9493 here →
llama.cpp commit a731805c). Pre-stage it as `fetchFromGitHub` and
apply Ollama's compat patch in `postPatch` — neither
`cmake/local.cmake` nor `llama/server/CMakeLists.txt` auto-applies
the patch when the source is overridden via
`FETCHCONTENT_SOURCE_DIR_LLAMA_CPP` (the parent's `ExternalProject_Add`
passes `OLLAMA_LLAMA_CPP_SKIP_COMPAT_PATCH=ON` to the child build).
The `apply-patch.cmake` script is idempotent.
* Since 0.30, `cmake/local.cmake` splits the llama.cpp build into
per-runner sub-projects gated by `OLLAMA_LLAMA_BACKENDS`. Without
setting it, only the CPU runner is built — `ollama-cuda` /
`ollama-rocm` / `ollama-vulkan` would all silently fall back to CPU
at runtime, with `libggml-{cuda,hip,vulkan}.so` absent from
`$out/lib/ollama`. Map the package's `acceleration` value to the
cmake backend name the elseif chain accepts:
cuda → cuda_v${cudaMajor} (cuda_v12 / cuda_v13)
rocm → rocm_v${rocmMajor}_${rocmMinor} (rocm_v7_1 / rocm_v7_2)
vulkan → vulkan
* `cmd/launch/*_test.go` are integration tests for user-facing CLI
launchers (claude, qwen, cline, codex, kimi, droid, openclaw,
hermes, …) that install the target binary via npm and exec it on
PATH. Both prerequisites are unavailable in the nix sandbox, so the
launch subpackage's tests can't pass here. Drop them — same
precedent as the existing darwin Metal test removals.
* The llama.cpp sub-build is driven by ExternalProject_Add and does
not inherit the parent's `CMAKE_SKIP_BUILD_RPATH` setting, so its
`.so` payloads end up with build-dir entries in RPATH. Strip with
`patchelf --shrink-rpath --allowed-rpath-prefixes /nix/store` in
preFixup; `$ORIGIN` is preserved unconditionally (non-absolute
entries always allowed) so peer-lib lookup in `$out/lib/ollama`
still works.
Drive-by cleanup: deadnix + statix passes (overrideModAttrs unused
lambda args → `_:_`, `inherit (rocmPackages) stdenv;` /
`inherit (vulkan-tools) stdenv;` for `buildGoModule.override`, drop
unused `coreutils` input — the old launch-test substitutions that
needed coreutils are dropped along with the tests).
Release notes:
https://github.com/ollama/ollama/releases/tag/v0.30.4https://github.com/ollama/ollama/releases/tag/v0.30.0
Assisted-by: Claude Opus 4.7 <noreply@anthropic.com>
(cherry picked from commit 63e0d2d52d)
Otherwise the recursive chown can fail, hence wpa_supplicant doesn't
start, if some read-only file has been bind-mounted into
/etc/wpa_supplicant.
This can happen if one uses `extraConfigFile` to add a file that is
under /etc/wpa_supplicant.
(cherry picked from commit 197a055a02)
polyc linking script hardcodes the linker to be the value of `$CXX` at
compile time. This is bad for environments without `g++` in path. Fix
this by patching the correct path into the script.
Co-Authored-By: Ricardo Correia <someplaceguy@wizy.org>
Co-Authored-By: Ivan Trubach <mr.trubach@icloud.com>
(cherry picked from commit 3a717e7522)
Compilation requires running one of the make build targets, so cross
compilation isn't possible
Also remove old design patterns in favour of newer ones.
(cherry picked from commit 6e36170c0f)
The previous `if ! ( ... )` wrapper put the check body in a context
where bash ignores `set -e`, so a failing command in the middle of a
check would not abort it and the switch would proceed. Run the
subshell outside any conditional and capture $? explicitly instead.
(cherry picked from commit 69dc41f083)
needed so github-desktop's git wrapper (dugite) can find subcommands
like `git-submodule` etc. Retrieve the full list with `ls -l $(nix build
--print-out-paths nixpkgs#git)/libexec/git-core | grep -vE '( -> )?git$'
| awk '{ print $7 }'`.
Fixes#524797
(cherry picked from commit 3fd65b2bc8)
Weblate generates an SSH wrapper with some preset options
that uses the absolute path of the ssh binary internally.
As the wrapper is only regenerated when the generator itself
is changed, this absolute nix store path becomes unusable once
ssh is updated and the path is garbage collected.
As generating the wrappers is a quick operation, simply deleting the wrapper
directory before service start ensures they are up to date.
(cherry picked from commit 9ea977e104)
virtual-machine releases use virtualisation.incus.package to find
where the agent-loader configuration is defined. In practice it's
likely not a problem, but when marking lts v6 on 25.11 as vulnerable
it exposed the mismatch. For correctness we should ensure the VM
tests are using the agent loader from the relevant incus package.
(cherry picked from commit 9bebd86680)
Environment variables to pass to Heroic.
For example:
pkgs.heroic.override {
extraEnv.PROTON_ENABLE_WAYLAND = true;
}
Adds feature parity with `steam` package.
(cherry picked from commit 6b9bf6240f)
Build against the default OCaml (5.4) set instead of the 5.3 pin, using the
module-mode launcher (ocaml-hol). Carries a patch so the pa_j chooser
accepts camlp5 8.05, links findlib into ocaml-hol, and sets up the runtime
OCAMLPATH/CAML_LD_LIBRARY_PATH. Drops the camlp5 8.03.2 downgrade.
(cherry picked from commit 7579aa2942)
camlp5's META requires pcre2 and fmt, but they were only buildInputs, so
findlib consumers of camlp5 could not resolve them. Move them to
propagatedBuildInputs.
(cherry picked from commit 74a82ccd8e)
In 52a23a9 the configuration `data-dir $out/share/aspell` was
introduced to make sure that `aspell --lang=<LANG> create
master ...` finds the LANG.dat file. However, the correct location
for language data files is $out/lib/aspell. This confusion also
broke filter discovery as described in #476684.
This commit fixes the location of language data files.
Note: `aspell --lang=<LANG> create master ...` will fail if the
dictionary has not been installed in the environment via
`aspellWithDicts (dict: [ dict.<LANG> ])` which is expected.
Fixes#476684
(cherry picked from commit e7dd5593e8)
Upstream added versions with -exp-\d suffix which broke the script.
Instead of adding another filter to the current query, let's try getting
the latest stable version instead.
IIRC previously they didn't correctly mark stable releases which is why
we didn't use this method.
(cherry picked from commit 1c03a3fb23)
This came up in Firefox as
https://bugzilla.mozilla.org/show_bug.cgi?id=2042197, where policies
caused different behavior to be active (also see
https://github.com/NixOS/nixpkgs/pull/524793). We should not observe any
such differences, but this indicates that the policy is unnecessary for
disabling the updater.
Tor/Mullvad Browser have supported is-packaged-app for a long time
(https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/985),
and it's preferred by Firefox (i.e. it actually has meaning there:
https://searchfox.org/firefox-main/search?q=is-packaged-app&path=&case=false®exp=false), so we switch from `system-install` to that one. This shouldn't
change anything else user visible.
This removes the "Your browser is being managed by your organization."
text from about:preferences and changes about:policies from showing this
singular policy to "The Enterprise Policies service is inactive." (the
intended upstream behavior), so this seems like a win for clarity.
Tested by downgrading the version in the derivation, and seeing no
update UI appear, either in the hamburger menu in the toolbar or under
Help > About Mullvad Browser.
(cherry picked from commit 75b48cfbf1)
This came up in Firefox as
https://bugzilla.mozilla.org/show_bug.cgi?id=2042197, where policies
caused different behavior to be active (also see
https://github.com/NixOS/nixpkgs/pull/524793). We should not observe any
such differences, but this indicates that the policy is unnecessary for
disabling the updater.
Tor/Mullvad Browser have supported is-packaged-app for a long time
(https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/985),
and it's preferred by Firefox (i.e. it actually has meaning there:
https://searchfox.org/firefox-main/search?q=is-packaged-app&path=&case=false®exp=false), so we switch from `system-install` to that one. This shouldn't
change anything else user visible.
This removes the "Your browser is being managed by your organization."
text from about:preferences and changes about:policies from showing this
singular policy to "The Enterprise Policies service is inactive." (the
intended upstream behavior), so this seems like a win for clarity.
Tested by downgrading the version in the derivation, and seeing no
update UI appear, either in the hamburger menu in the toolbar or under
Help > About Tor Browser.
(cherry picked from commit 8fce018efd)
Replace the `passthru.tests` --version test by running versionCheckHook
during the package build.
As `haskellPackages.mkDerivation` is very locked-down and doesn't allow
access to things like `nativeInstallCheckInputs` (or any input lists),
we add a separate `.overrideAttrs` call to the pipeline.
Running phase: installCheckPhase
Executing versionCheckPhase
Successfully managed to find version 1.3.0 in the output of the command /nix/store/3fg7y7qww3c3hvyb66n75d9j5y362n4j-nixfmt-1.3.0/bin/nixfmt --version
nixfmt 1.3.0
Finished versionCheckPhase
(cherry picked from commit ce5210e9c7)
Apply the Linux patch to the initialization string for `clang_path_include`
instead of replacing `clang_path_include` with the patched string. This
allows the correct value for Darwin to be selected by the ternary expression.
(cherry picked from commit 6f2c0a34f3)
Because stdenv instructs meson to enable all features automatically,
it's redundant to have any lib.mesonEnable that just sets a literal
true. Keeping the `supported_build` feature flag to explicitly convey
the intention behind it.
(cherry picked from commit 6fe7674824)
Especially major versions contain API breakage and we always require
a compatible home-assistant version. Not all API surfaces are
being exercised in home-assistant tests, so don't fool yourself by
nixpkgs-review not revealing any breakages.
(cherry picked from commit ed1de9a708)
Obsidian's app:// scheme lacks `corsEnabled`, which breaks the internal
PDF viewer on Electron 40. Add it to the scheme registration.
Fixes#523846
Assisted-by: Claude Code (Claude Opus 4.8)
(cherry picked from commit d54367545e)
A non-interactive polkit authentication agent that answers PAM prompts
from a file descriptor. Provides the missing `sudo --stdin` equivalent
for run0/systemd-run, which authorise via polkit and otherwise require
a controlling terminal for pkttyagent.
Used by the upcoming `nixos-rebuild --elevate=run0
--ask-elevate-password`.
Reason for backport:
Useful for VM tests of run0systemd-run/pkexec independent of
`nixos-rebuild`. Also useful for tools such as run0-sudo-shim to emulate
`sudo --stdin` with run0. That shim may be used with nixpkgs 26.05,
handling that is significantly easier if `polkit-stdin-agent` is
universally available.
(cherry picked from commit 4d4952ae28)
The check phase for the config file has to replace any instances of
user and group with the current ones, since logrotate checks whether
they actually exist. However, the create/createolddir substitution
expressions didn't take all different parameter formats into
account. Mainly, if the mode was specified, but not user and group,
the result would be something like
create 0644nixbld nixbld
since it relies on matching a space at the end of the mode
specification.
To fix this, always append a space before the substituted user and
group.
Also, simplify the formatting by using extended regex and check for
word boundaries after create/createolddir to exclude any incorrect or
unsupported suffixes.
(cherry picked from commit dfe85974ca)
The unquoted $out/${libDir}/is-packaged-app path word-splits on
applicationNames containing spaces (e.g. "Firefox Developer Edition"),
breaking the Darwin build for firefox-devedition and similar variants.
Regression from 1da3ca7373.
(cherry picked from commit a2e905224c)
This avoids an unfixable Hydra build failure [1] caused by the file
required by `requireFile` not being present in Hydra's store.
A long-term fix for this and similar issues is already on `master` [2]
but constitutes a breaking change, which is why we cannot backport it.
[1] https://hydra.nixos.org/build/329892892
[2] https://github.com/NixOS/nixpkgs/pull/515536
Not-cherry-picked-because: Different fix on master, not backportable
By using unittest's assertEqual you actually see how often the
activation script was being run, i.e. the expected value.
(cherry picked from commit 864a84d3e9)
(cherry picked from commit b1a881edb9)
stc-ng starts every active target (including default.target) and then
explicitly restarts nixos-activation.service. As a Type=oneshot without
RemainAfterExit the unit is inactive after login, so the default.target
start job re-runs it via Wants=, and the explicit restart runs it again
(or, depending on ordering, SIGTERMs the currently running script and re-runs it).
Set RemainAfterExit=yes so target starts are a no-op for an already-run
activation, and restartIfChanged=false so the unit-diff pass leaves it
alone when the script changes. The explicit restart in stc-ng remains
the single trigger per switch. Print that restart so it is visible in
the switch output, and drop it from the "NOT restarting" list.
Extend the user-activation-scripts test to assert the activation is
only run once, and never killed.
(cherry picked from commit 663a59e0b6)
The previous "FragmentPath not under /etc" deny-list swept up units that
were never managed by a per-user manager (e.g. dbus-broker, whose
FragmentPath systemd reports under /run/current-system/sw/share via
systemd.packages) and missed nothing it should have caught, but for the
wrong reason.
Make the intent explicit. A unit is a migration candidate iff it is
active, the new generation defines it in /etc/systemd/user, and either
* its FragmentPath is under $XDG_CONFIG_HOME/systemd/user (the
home-manager case; ~/.config shadows /etc, so we must wait for
sd-switch to remove the copy), or
* its FragmentPath is anywhere else outside /etc and the previous
generation did not have it in /etc (package-shipped units found via
$XDG_DATA_HOME / $XDG_DATA_DIRS, e.g. ~/.nix-profile/share; /etc
outranks these so it wins on daemon-reload).
The "previous generation did not have it" guard keeps units that have
always been in /etc, but whose FragmentPath systemd reports elsewhere, out
of the candidate set, and the existing now_etc check verifies /etc
actually won before acting. Compare FragmentPath by parent directory
instead of string prefix while here.
Covered by a new switch-test case that seeds a unit in
~/.local/share/systemd/user.
(cherry picked from commit 6ced06a1b3)
The post-activation pass added in 5cc82c4922 to handle units migrating
from a per-user manager (home-manager) to NixOS unconditionally restarts
or starts any candidate. dbus-broker.service explicitly opts out of
restarts via reloadIfChanged because restarting the session bus kills
running clients; the second pass ignored that and restarted it anyway.
Apply the same X-ReloadIfChanged / X-RestartIfChanged / RefuseManualStop /
RefuseManualStart / X-OnlyManualStart checks that handle_modified_unit
performs, so a migrated unit is reloaded, skipped, restarted or started
as its directives require.
Covered by new switch-test specialisations for reloadIfChanged and
restartIfChanged = false.
(cherry picked from commit 76c8d45099)
Fixes odd bulletpoints and bare URLs that are prohibited by most
Markdown linters and specs.
Signed-off-by: NotAShelf <raf@notashelf.dev>
Change-Id: Iae14dce3d158ac11c59d9117694ccde46a6a6964
(cherry picked from commit b786821e13)
Picks up upstream commits including the fix for the `LayoutManager.hpp`
include path, which was breaking the build against the Hyprland version
currently in nixpkgs.
Fixes: https://hydra.nixos.org/build/327871454
(cherry picked from commit 90a7638678)
Follow-up to the 9.0.4 update in aa9f3b7824 that broke the (completely
optional) tests, because upstream renamed the already ignored tests (as
they try to access internet resources) in 5ebe8ea15f.
(cherry picked from commit 45185e91bf)
This should help debugging config values. I verified that `pnpm config
list` works across pnpm_8, pnpm_9, pnpm_10, pnpm_10_29_2 and pnpm_11.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
(cherry picked from commit d5cbb9e641)
These checks are still performed in fetchPnpmDeps. These checks require
access to the registries used in the lockfile, making it infeasible to
run during configurePhase in a sandboxed build.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
(cherry picked from commit 599909067c)
See 63147b12a5
Apparently on i686-linux the test isn't flaky but failing reliably.
So restarting on Hydra won't help, and waiting for staging*
would take a few weeks.
(cherry picked from commit 664e60aa95)
This might be a nice way to use our reach to remind users to donate to
FLOSS projects that they use and love.
Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
(cherry picked from commit 9d2f2d71e4)
This patch is merged upstream and can be reverted on the next update.
Fetchpatch does not work against framagit.org, which is why I vendored
the patch instead.
(cherry picked from commit 1a7b7c7ddf)
machine-learning[1920443]: mkdir -p failed for path /var/empty/.config/matplotlib: [Errno 1] Operation not permitted: '/var/empty/.config'
machine-learning[1920443]: Matplotlib created a temporary cache directory at /tmp/matplotlib-uo52wf71 because there was an issue with the default path (/var/empty/.config/matplotlib); it is highly recommended to set the MPLCONFIGDIR environment variable to a writable directory, in particular to speed up the import of Matplotlib and to better support multiprocessing.
(cherry picked from commit cb2ed10279)
By default, Git commands will trigger background processes to perform
repository maintenance. As of Git v2.54.0, and in particular as of
452b12c2e0 (builtin/maintenance: use "geometric" strategy by default,
2026-02-24), Git has changed the strategy it uses to decide whether
maintenance needs performing, and as a result will kick off background
maintenance processes much more often.
These background processes will potentially change the contents of the
`.git` directory while `nix-prefetch-git` is deleting it. This results in
effectively random failures, when files are added to the `.git`
directory during the `rm -rf` operation (causing it to fail) or after
the operation has completed (causing the `.git` directory to be
recreated and resulting in a FOD hash mismatch).
This also causes problems for the determinism of Git's own tests.
They've resolved this in 09505b1115 (t: fix races caused by background
maintenance, 2026-02-24) by having the maintenance processes run in the
foreground. The discussion in that commit explains they considered just
disabling maintenance entirely, but opted for the foreground option
because disabling maintenance would mean the tests looked even less like
how most Git users work with Git.
`nix-prefetch-git` is nothing like most Git users. In almost every
case, the `.git` directory will be deleted during or immediately after
the script is called. The repositories certainly don't benefit from
ongoing maintenance. To avoid the non-determinism created by the
background maintenance processes, just disable maintenance entirely.
This is done with `git config` after initialising the repository, rather
than `git config --global` earlier in the script, as `git config
--global` will fail if `fetchgit` was called with a `gitConfig`
argument.
It would be possible to set this option with
`GIT_CONFIG_[COUNT|KEY_<n>|VALUE_<n>]` environment variables; I've opted
against that because (a) they're less familiar to most people who might
want to come to edit this script in future and (b) because if someone is
using those values themselves via `impureEnvVars` or similar, making our
configuration play nicely with someone else's would require some fairly
complex logic.
I haven't made this a configurable option: any use of `nix-prefetch-git`
will run with maintenance disabled, as I cannot think of a use case
where it would be useful. If there is such a use case, it would be
straightforward to extend `nix-prefetch-git` and `fetchgit` to allow
users to change the behaviour.
Fixes#524215.
(cherry picked from commit 011471c7f2)
Update to latest pre-release to fix multiple security vulnerabilities:
- CVE-2026-9500: heap-buffer-overflow in decode.c (decompress_R2004_section)
- CVE-2026-9501: heap-buffer-overflow in decode.c (read_2004_compressed_section)
- CVE-2026-9502: heap-buffer-overflow in decode.c (decompress_R2004_section)
- CVE-2026-9503: heap-buffer-overflow in decode.c (decompress_R2004_section)
- CVE-2026-9504: null pointer dereference in dwggrep.c (main)
- CVE-2026-9529: heap-buffer-overflow in decode.c (decompress_R2004_section)
- CVE-2026-9530: heap-buffer-overflow in decode.c (decompress_R2004_section)
- CVE-2026-9605: heap-buffer-overflow in decode.c (decompress_R2004_section)
Individual backports were not feasible as the decompressor was significantly
refactored on upstream's main branch between 0.13.4 and the fixes.
(cherry picked from commit b27ee09e7d)
The 9.4.14 tarball is no longer hosted at download.nomachine.com; the
old URL now redirects to the vendor homepage and breaks fetchurl. Bump
to the current upstream release. Both x86_64 and i686 release tarballs
use build suffix _2.
Hashes recomputed via nix-prefetch-url against
https://download.nomachine.com/download/9.5/Linux/.
(cherry picked from commit 0f906ee9b4)
The crates.io API server's 1 req/sec rate limit currently surfaces as
intermittent HTTP 403 errors when vendoring lockfiles. Switch to the CDN
endpoint as recommended by upstream (rust-lang/crates.io#13482), mirroring
the fix already applied to fetchCargoVendor in #512735.
fetchurl is content-addressed by sha256, so the URL change does not affect
any downstream store paths.
Fixes#524979
(cherry picked from commit f830e6112b)
Versions before 144 vendor bindgen 0.69, which emits invalid Rust for
libc++ 21's attributed basic_string::__self_view alias on Darwin.
This was exposed by commit 0758fc3add ("darwin.libcxx:
20.1.0+apple-sdk-26.0 -> 21.1.6+apple-sdk-26.4"), where libc++
changed `basic_string::__self_view` from a typedef to an attributed
`using` alias. bindgen then drops the alias template parameter and emits
`basic_string___self_view = ...<_CharT>`.
The solution is to blocklist the unused `string_view` internals for the
profiler Rust API. They are not used in the actual build.
Note: Mozilla 144 updated vendored bindgen via:
https://bugzilla.mozilla.org/show_bug.cgi?id=1985509
Assisted-by: Codex gpt-5.5 xhigh
(cherry picked from commit c19203e06f)
I suspect it was commit 0968bb28e2 that
broke the build with nodejs_24, presumably because of npm updating from
11.11.1 to 11.12.1.
(cherry picked from commit 78df8f88a5)
By using unittest's assertEqual you actually see how often the
activation script was being run, i.e. the expected value.
(cherry picked from commit 864a84d3e9)
(cherry picked from commit b1a881edb9)
stc-ng starts every active target (including default.target) and then
explicitly restarts nixos-activation.service. As a Type=oneshot without
RemainAfterExit the unit is inactive after login, so the default.target
start job re-runs it via Wants=, and the explicit restart runs it again
(or, depending on ordering, SIGTERMs the currently running script and re-runs it).
Set RemainAfterExit=yes so target starts are a no-op for an already-run
activation, and restartIfChanged=false so the unit-diff pass leaves it
alone when the script changes. The explicit restart in stc-ng remains
the single trigger per switch. Print that restart so it is visible in
the switch output, and drop it from the "NOT restarting" list.
Extend the user-activation-scripts test to assert the activation is
only run once, and never killed.
(cherry picked from commit 663a59e0b6)
The previous "FragmentPath not under /etc" deny-list swept up units that
were never managed by a per-user manager (e.g. dbus-broker, whose
FragmentPath systemd reports under /run/current-system/sw/share via
systemd.packages) and missed nothing it should have caught, but for the
wrong reason.
Make the intent explicit. A unit is a migration candidate iff it is
active, the new generation defines it in /etc/systemd/user, and either
* its FragmentPath is under $XDG_CONFIG_HOME/systemd/user (the
home-manager case; ~/.config shadows /etc, so we must wait for
sd-switch to remove the copy), or
* its FragmentPath is anywhere else outside /etc and the previous
generation did not have it in /etc (package-shipped units found via
$XDG_DATA_HOME / $XDG_DATA_DIRS, e.g. ~/.nix-profile/share; /etc
outranks these so it wins on daemon-reload).
The "previous generation did not have it" guard keeps units that have
always been in /etc, but whose FragmentPath systemd reports elsewhere, out
of the candidate set, and the existing now_etc check verifies /etc
actually won before acting. Compare FragmentPath by parent directory
instead of string prefix while here.
Covered by a new switch-test case that seeds a unit in
~/.local/share/systemd/user.
(cherry picked from commit 6ced06a1b3)
The post-activation pass added in 5cc82c4922 to handle units migrating
from a per-user manager (home-manager) to NixOS unconditionally restarts
or starts any candidate. dbus-broker.service explicitly opts out of
restarts via reloadIfChanged because restarting the session bus kills
running clients; the second pass ignored that and restarted it anyway.
Apply the same X-ReloadIfChanged / X-RestartIfChanged / RefuseManualStop /
RefuseManualStart / X-OnlyManualStart checks that handle_modified_unit
performs, so a migrated unit is reloaded, skipped, restarted or started
as its directives require.
Covered by new switch-test specialisations for reloadIfChanged and
restartIfChanged = false.
(cherry picked from commit 76c8d45099)
The fix in #523016 fixes an issue with the default gateway, however it
does so by unconditionally defining `networking.interfaces.eth0`. This
makes so if you had other methods of defining the addresses for eth0,
those now get blanked out.
Instead, move the logic around so we only define
networking.interfaces.eth0 if we really have to.
(cherry picked from commit 217d834eb9)
With kernel lockdown the tun kmod is not necessarily available in stage2,
but Lix dependes on it through pasta.
nix-daemon[682677]: remote pid 682659 is user build (trusted)
nix-daemon[682711]: Failed to open() /dev/net/tun: No such device
nix-daemon[682702]: Failed to set up tap device in namespace
(cherry picked from commit 34fbf0285a)
Commit 5aa9012bb3 (nixos: replace 'text' with structured PAM rules
(#420889), 2026-04-14) resulted in the vsftpd module no longer creating
a PAM module, and therefore configurations relying on `cfg.localUsers`
stopped permitting logins unless the PAM module was being set up by
other configuration.
In the absence of a better fix, document this change of behaviour as a
regression. Per the discussion at [0], provide a mechanims to restore
the previous behaviour, but with the caveat that this may be insecure.
I'd prefer more useful advice, but if I had a better understanding of
NixOS's PAM configuration and how it interacts with vsftpd, I'd just be
providing the better fix in the first place.
[0]: https://github.com/NixOS/nixpkgs/issues/515531#issuecomment-4367747991
(cherry picked from commit 93699b88a5)
This replaces the earlier 2.86 patch.
One may consider bumping the source to something newer than the 8 year old release, but that's out of scope for this fix.
Signed-off-by: benaryorg <binary@benary.org>
(cherry picked from commit 79f6dec101)
Define ANSI_FUNC so corkscrew uses ANSI C function definitions instead of legacy K&R definitions rejected by modern Clang/C23.
Assisted-by: OpenCode (openai/gpt-5.5)
(cherry picked from commit 47eb5f6f4d)
The test created ZFS datasets with canmount=noauto, but pam_zfs_key's
mount_dataset() now checks canmount == ZFS_CANMOUNT_ON and skips
mounting otherwise (added in
https://github.com/openzfs/zfs/commit/387ed5ca41). Use the default
canmount=on and unmount before unloading the key to compensate for
the auto-mount that happens when the key is loaded during creation.
This also silences the warning for forceImportRoot.
Assisted-by: opencode with DeepSeek V4 Flash Free
(cherry picked from commit 3fdfb983c7)
also switches to the new `generate_db.py` script
this was done because the old `lensfun_convert_db_v2_to_v1.py` script has been
removed upstream and this is the new preferred method
additionally, this adds the optional `lensfunDatabases` argument which can be
used to override the lens database used when building the package
(cherry picked from commit f652ee5019)
This gives us better UI in the PR by hiding the commits that are already
on the base branch (mostly staging) after the periodic merge. Without
this, the PR has 100s of commits listed after a few days.
(cherry picked from commit 5439176950)
Replace gitUpdater with a shell script that invokes
update-source-version once per system using
--source-key, so both per-arch AppImage hashes are
refreshed on each version bump.
(cherry picked from commit ec5d28b85b)
MemoryDenyWriteExecute=true breaks pyopenssl's cffi calls, used in the remote access feature.
```
2026-05-24 17:32:58.344 ERROR (MainThread) [music_assistant] Error doing task: Task exception was never retrieved
Traceback (most recent call last):
File "/nix/store/mmv9717wjskv3q5v4768dq0fq5hf4jry-python3.13-aiortc-1.14.0/lib/python3.13/site-packages/aiortc/rtcpeerconnection.py", line 1084, in __connect
await dtlsTransport.start(self.__remoteDtls[self.__sctp])
File "/nix/store/mmv9717wjskv3q5v4768dq0fq5hf4jry-python3.13-aiortc-1.14.0/lib/python3.13/site-packages/aiortc/rtcdtlstransport.py", line 518, in start
self.__local_certificate._create_ssl_context(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
srtp_profiles=self._srtp_profiles
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/nix/store/mmv9717wjskv3q5v4768dq0fq5hf4jry-python3.13-aiortc-1.14.0/lib/python3.13/site-packages/aiortc/rtcdtlstransport.py", line 198, in _create_ssl_context
ctx.set_verify(
~~~~~~~~~~~~~~^
SSL.VERIFY_PEER | SSL.VERIFY_FAIL_IF_NO_PEER_CERT, lambda *args: True
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/nix/store/5kwsndvbzfj3dv4fwpdlgin42mgbd4xk-python3.13-pyopenssl-26.0.0/lib/python3.13/site-packages/OpenSSL/SSL.py", line 867, in inner
return f(self, *args, **kwargs)
File "/nix/store/5kwsndvbzfj3dv4fwpdlgin42mgbd4xk-python3.13-pyopenssl-26.0.0/lib/python3.13/site-packages/OpenSSL/SSL.py", line 1390, in set_verify
self._verify_helper = _VerifyHelper(callback)
~~~~~~~~~~~~~^^^^^^^^^^
File "/nix/store/5kwsndvbzfj3dv4fwpdlgin42mgbd4xk-python3.13-pyopenssl-26.0.0/lib/python3.13/site-packages/OpenSSL/SSL.py", line 527, in __init__
self.callback = _ffi.callback(
~~~~~~~~~~~~~^
"int (*)(int, X509_STORE_CTX *)", wrapper
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
MemoryError: Cannot allocate write+execute memory for ffi.callback(). You might be running on a system that prevents this. For more information, see https://cffi.readthedocs.io/en/latest/using.html#callbacks
```
(cherry picked from commit 6b53fc13e3)
I assume quadradical doesn't want to re-assume maintainership simply because I reverted the package drop for my own purposes.
(cherry picked from commit 261eac2ed0)
qbz uses pactl for PipeWire device enumeration and sink routing, and
pw-metadata for bit-perfect sample rate queries. Without these on PATH,
audio playback fails with "Failed to run pactl: No such file or directory".
(cherry picked from commit feafc3f846)
And also add an additional check to preCheck that will enable us to
catch executable stack issues earlier next time.
(cherry picked from commit 5198c49a5a)
I've been keeping this package up to date over the past few years, since
I run a webserver that depends on it. I'd be happy to be co-maintainer
for it, and hopefully reduce the load on others.
(cherry picked from commit 1665623390)
LibreSSL branches are supported for one year after the OpenBSD release
in which they are included. LibreSSL 4.1 was part of OpenBSD 7.7, which
was released on April 28, 2025, so it's end of life now.
(cherry picked from commit 0bfe3de9ed)
I also added expiration date comments on all of them, because I always
spend some time chasing what the support dates are, and it would save
maintainer time to be able to see what to do with these branches.
(cherry picked from commit feb7c9ff78)
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 (26.11)"
- "- Stable (26.05)"
- "- Unstable (26.05)"
- "- Stable (25.11)"
default:0
validations:
required:true
@@ -99,7 +99,7 @@ body:
attributes:
label:"Are you using nix-darwin?"
description:|
[`nix-darwin`](https://github.com/nix-darwin/nix-darwin) is a set of NixOS-like modules for macOS systems. Depending on your issue, this information may be relevant.
[`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.
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 (26.11)"
- "- Stable (26.05)"
- "- Unstable (26.05)"
- "- Stable (25.11)"
default:0
validations:
required:true
@@ -56,12 +56,12 @@ body:
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/subprojects/hydra/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/subprojects/hydra/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/subprojects/hydra/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?)
- 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/subprojects/hydra/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/subprojects/hydra/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.**'
- 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.**'
- If Hydra isn't supposed to build the package at all, say '**Hydra doesn’t try to build the package.**'
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.
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.
[Nixpkgs](https://github.com/nixos/nixpkgs) is a collection of over 140,000 software packages that can be installed with the [Nix](https://nixos.org/nix/) package manager.
[Nixpkgs](https://github.com/nixos/nixpkgs) is a collection of over 120,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.
@@ -51,16 +51,6 @@ To ensure security and a focused utility, the bot adheres to specific limitation
- opened by [@r-ryantm](https://nix-community.github.io/nixpkgs-update/r-ryantm/).
- The user attempting to merge is a member of [@NixOS/nixpkgs-maintainers].
- The user attempting to merge is a maintainer of all packages touched by the PR.
- No [committer][@NixOS/nixpkgs-committers] has an outstanding "changes requested" review.
These block both the merge queue and auto-merge, so the bot refuses to merge until the review is addressed or dismissed.
Once these constraints are met, the bot picks a merge strategy based on the `no PR failures` commit status:
- CI passing: the PR is added to the merge queue.
- CI unfinished (pending or missing status): the bot enables [Auto Merge], which queues the PR once required checks succeed.
Note that if CI later fails, nothing happens until it is fixed and passes.
- CI already failing (`error`/`failure` status): the bot does not enable Auto Merge, because it would never trigger, and fixing CI requires a new push that invalidates the merge command.
A fresh `@NixOS/nixpkgs-merge-bot merge` comment is needed once CI is green again.
### Approving merge bot changes
@@ -114,4 +104,3 @@ This script can also be run locally to print basic test cases.
`:heavy_check_mark: Enabled Auto Merge (#306934)`,
'',
'> [!TIP]',
'> [Auto Merge](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request) will queue this PR once required CI checks succeed.',
'> If CI fails instead, fixing it needs a new push, which disables Auto Merge and invalidates this command — comment `@NixOS/nixpkgs-merge-bot merge` again once CI is green.',
'> If GitHub gets stuck even though CI passed (it sometimes does), leaving another approval should kick off the merge.',
],
}
return[
`:heavy_check_mark: Enabled Auto Merge (#306934)`,
'',
'> [!TIP]',
'> Sometimes GitHub gets stuck after enabling Auto Merge. In this case, leaving another approval should trigger the merge.',
This directory houses the source files for the Nixpkgs manual.
This directory houses the source files for the Nixpkgs reference manual.
> [!NOTE]
> [!IMPORTANT]
> We are actively restructuring our documentation to follow the [Diátaxis framework](https://diataxis.fr/)
>
> We are actively restructuring our documentation to be more beginner friendly.
> 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.
When writing new docs use **Progressive Disclosure**
For documentation only relevant for contributors, use Markdown files next to the source and regular code comments.
Start simple, pick up beginners.
Use **examples** first to show how to get something done. Keep **Explanation** lean.
Use our [styleguide](./styleguide.md) for more in depth guidance on writing good documentation.
This directory contains **guides** and **reference** documentation for Nixpkgs.
Borrowing from [Diátaxis framework](https://diataxis.fr/) what suits our needs:
**Guides** are task-oriented. They can be tutorial-style walkthroughs or how-to sections.
Explanations appear as prose after examples.
**Reference** documentation is the specification of functions and attributes.
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.
See [Document structure](#document-structure) for a structural template.
> [!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.
@@ -47,7 +36,7 @@ If the build succeeds, the manual will be in `./result/share/doc/nixpkgs/manual.
### Development environment
To reduce repetition, consider using tools from the provided development environment:
In order to reduce repetition, consider using tools from the provided development environment:
Load it from the Nixpkgs documentation directory with
@@ -65,11 +54,9 @@ Make sure that your local files aren't added to Git history by adding the follow
/**/.direnv
```
#### Live preview
#### `devmode`
Run [`devmode`](../pkgs/by-name/de/devmode/README.md) for a live preview while editing the manual: it rebuilds on every change and reloads the page in your browser automatically.
Changes to the renderer 'pkgs/by-name/ni/nixos-render-docs' need a manual restart. Run: `devmode` again.
Use [`devmode`](../pkgs/by-name/de/devmode/README.md) for a live preview when editing the manual.
### Testing redirects
@@ -220,64 +207,6 @@ When needed, each convention explains why it exists, so you can make a decision
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.
**For prose style, see the [documentation styleguide](./styleguide.md).**
### Document structure
Organize each chapter as guide sections first, then a single `## Reference` section.
A well-structured chapter looks like this:
````markdown
# Foo {#foo}
`foo` builds Foo projects from a `foo.toml`.
## Package a Foo application {#foo-packaging}
:::{.example #ex-foo-packaging}
# Package the hello app
```nix
{ foo }:
buildFooPackage {
pname = "hello";
version = "1.0";
}
```
:::
`buildFooPackage` needs `pname` and `version`.
Keep explanation short, and place it after the example.
## Reference {#foo-reference}
### `buildFooPackage` {#foo-buildFooPackage}
Builds a Foo application from source.
#### Inputs {#foo-buildFooPackage-inputs}
`pname` (String)
: The program name.
#### Examples {#foo-buildFooPackage-examples}
See [](#ex-foo-packaging).
````
Examples live in one place: the guide owns them and the reference links to them.
Guides introduce minimal working examples that are goal-oriented (typical usage).
Reference may introduce additional examples that are unit-oriented. (minimal usage, edge-cases).
If the guide example is already sufficient, just link to it from the reference.
Follow this structure strictly; to deviate, ping @NixOS/documentation-team.
### One sentence per line
Put each sentence in its own line.
@@ -290,16 +219,17 @@ When changing existing content, update formatting if possible, but avoid excessi
### Examples first
Put examples before detailed explanations (see the [styleguide](./styleguide.md) for the rationale).
Readers look at examples first: an example communicates what something does faster than a description.
Put examples before detailed explanations.
Use this structure for each documented item:
Prefer this structure for each documented item:
1. Title
2. Abstract (optional, one sentence max)
2. Abstract (optional, one sentence max, the example often speaks for itself)
# Fixed-point arguments of build helpers {#chap-build-helpers-finalAttrs}
`stdenv.mkDerivation`also accepts a [fixed-point function](#function-library-lib.fixedPoints.fix) instead of a plain attribute set:
As mentioned in the beginning of this part, `stdenv.mkDerivation`could alternatively accept a fixed-point function. The input of this function, typically named `finalAttrs`, is expected to be the final state of the attribute set. A build helper like this is said to accept **fixed-point arguments**.
```nix
{
stdenv,
fetchurl,
}:
stdenv.mkDerivation(finalAttrs:{
pname="hello";
version="2.12";
Build helpers don't always support fixed-point arguments yet, as support in [`stdenv.mkDerivation`](#mkderivation-recursive-attributes) was first included in Nixpkgs 22.05.
## Defining a build helper with `lib.extendMkDerivation` {#sec-build-helper-extendMkDerivation}
The function's input, conventionally named `finalAttrs`, is the final state of the attribute set. Here `src` reads `finalAttrs.version` instead of repeating the version string. A build helper like this is said to accept **fixed-point arguments**.
Attributes that reference each other through `finalAttrs` stay correct when changing any of them with [`overrideAttrs`](#sec-pkg-overrideAttrs), because they all access the final values of the fixed-point computation.
`rec` cannot do this: its self-references are fixed when the set is defined and ignore later overrides.
See [recursive-sets](https://nix.dev/manual/nix/stable/language/syntax#recursive-sets) for the underlying mechanism.
## Define a build helper with `lib.extendMkDerivation` {#sec-build-helper-extendMkDerivation}
Use [`lib.customisation.extendMkDerivation`](#function-library-lib.customisation.extendMkDerivation) to define a build helper with fixed-point support from an existing one.
Its argument `extendDrvArgs` takes an attribute overlay similar to [`<pkg>.overrideAttrs`](#sec-pkg-overrideAttrs).
Developers can use the Nixpkgs library function [`lib.customisation.extendMkDerivation`](#function-library-lib.customisation.extendMkDerivation) to define a build helper supporting fixed-point arguments from an existing one with such support, with an attribute overlay similar to the one taken by [`<pkg>.overrideAttrs`](#sec-pkg-overrideAttrs).
Besides overriding, `lib.extendMkDerivation` also supports `excludeDrvArgNames` to optionally exclude some arguments in the input fixed-point arguments from passing down to the base build helper (specified as `constructDrv`).
# Example `mkLocalDerivation` - a build helper over `mkDerivation`
# Example definition of `mkLocalDerivation` extended from `stdenv.mkDerivation` with `lib.extendMkDerivation`
Define a build helper named `mkLocalDerivation` that builds locally without using substitutes by default.
We want to define a build helper named `mkLocalDerivation` that builds locally without using substitutes by default.
Use `lib.extendMkDerivation`:
Instead of taking a plain attribute set,
```nix
{
lib,
stdenv,
}:
preferLocalBuild?true,
allowSubstitute?false,
specialArg?(_:false),
...
}@args:
stdenv.mkDerivation(
removeAttrs[
# Don't pass specialArg into mkDerivation.
"specialArg"
]args
//{
# Arguments to pass
inheritpreferLocalBuildallowSubstitute;
# Some expressions involving specialArg
greeting=ifspecialArg"hi"then"hi"else"hello";
}
)
```
we could define with `lib.extendMkDerivation` an attribute overlay to make the result build helper also accept the attribute set's fixed point passing to the underlying `stdenv.mkDerivation`, named `finalAttrs` here:
```nix
lib.extendMkDerivation{
constructDrv=stdenv.mkDerivation;
excludeDrvArgNames=[
@@ -69,78 +67,4 @@ lib.extendMkDerivation {
```
:::
To apply extra changes to the result derivation, pass `transformDrv`to`lib.extendMkDerivation`:
If one needs to apply extra changes to the result derivation, pass the derivation transformation function to `lib.extendMkDerivation`as`lib.customisation.extendMkDerivation { transformDrv = drv: ...; }`.
: Whether the site is expected to be relocatable, i.e. servable from any URL path prefix.
When `true` (the default), root-relative links (starting with `/`) are treated as errors, because they break when the site is served from a subpath or opened via `file://` URLs.
When `false`, root-relative links are resolved against the `site` directory.
Compliance suite for [modular service](https://nixos.org/manual/nixos/unstable/#modular-services) integrations.
Tests that a service manager integration correctly handles the portable modular services contract: `process.argv`, sub-services, assertions, and warnings.
### Return value {#tester-modularServiceCompliance-return}
An attribute set of derivations which perform the tests during their build.
Function to evaluate the given services in the integration's full context.
This function is called for evaluation checks on configurations that will not be run.
- Input `services` is an attrset of modular service configurations. These should be used verbatim.
- Output attribute `config` is the resulting evaluated services attrset (e.g., the value of the `system.services` option in NixOS).
This attribute must be available even if `checkDrv` would fail.
- Output attribute `checkDrv` is a representative derivation whose existence and buildability prove the eval is sound (e.g., `system.build.toplevel` in NixOS, but could perhaps be more specific in the case of another process manager integration).
`mkTest` (function)
: `{ name, services, testExe } -> derivation`.
- Input `name` is a test name, suitable for use as a derivation name.
- Input `services` is an attrset of modular service configurations, matching the structure of the integration's services option.
- Input `testExe` is a store path to an executable that verifies the services.
- Output: a derivation that runs the service manager with the provided configuration inputs and then calls `testExe` after starting the services. That executable must have access to `sharedDir`.
`sharedDir` (string)
: Path to a directory writable by service processes and readable by `testExe`.
The integration must ensure this directory is available when the services and `testExe` run.
@@ -165,7 +165,7 @@ They are useful for creating files from Nix expressions, and are all implemented
Each of these functions will cause a derivation to be produced.
When you coerce the result of each of these functions to a string with [string interpolation](https://nixos.org/manual/nix/stable/language/string-interpolation) or [`toString`](https://nixos.org/manual/nix/stable/language/builtins#builtins-toString), it will evaluate to the [store path](https://nixos.org/manual/nix/stable/store/store-path) of this derivation.
::: {.note}
:::: {.note}
Some of these functions will put the resulting files within a directory inside the [derivation output](https://nixos.org/manual/nix/stable/language/derivations#attr-outputs).
If you need to refer to the resulting files somewhere else in a Nix expression, append their path to the derivation's store path.
@@ -125,7 +125,7 @@ There are 2 ways to package backend dependencies: either per-dependency mix2nix
When writing an elixir project targeting `mixRelease`, you can also consider using [deps_nix](https://github.com/code-supply/deps_nix) with `mixNixDeps`. `deps_nix` supports git dependencies, but is intended to be added to the project's `mix.exs` directly.
##### mix2nix {#mix2nix}
###### mix2nix {#mix2nix}
`mix2nix` is a cli tool available in Nixpkgs. It will generate a Nix expression from a `mix.lock` file. It is quite standard in the 2nix tool series.
@@ -175,7 +175,7 @@ If there are git dependencies.
You will need to run the build process once to fix the hash to correspond to your new git src.
##### FOD {#fixed-output-derivation}
###### FOD {#fixed-output-derivation}
A fixed output derivation will download mix dependencies from the internet. To ensure reproducibility, a hash will be supplied. Note that mix is relatively reproducible. An FOD generating a different hash on each run hasn't been observed (as opposed to npm where the chances are relatively high). See [akkoma](https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/ak/akkoma/package.nix) for a usage example of FOD.
@@ -255,7 +255,7 @@ Setup will require the following steps:
#### Example of creating a service for an Elixir - Phoenix project {#example-of-creating-a-service-for-an-elixir---phoenix-project}
To create a service with your release, you could add a `service.nix`
In order to create a service with your release, you could add a `service.nix`
@@ -105,7 +105,7 @@ Given the requirements above, the package expression would become messy quickly:
}
```
Fortunately, we have a [family of hooks]{#ssec-gnome-hooks-wrapgappshook} that automate this. They work in conjunction with other setup hooks that populate environment variables, and will then wrap all executables in `bin` and `libexec` directories using said variables. If a package has multiple outputs, these hooks will work on `outputBin` by default, or on the outputs listed in `wrapGAppsInOutputs` if set.
Fortunately, we have a [family of hooks]{#ssec-gnome-hooks-wrapgappshook} that automate this. They work in conjunction with other setup hooks that populate environment variables, and will then wrap all executables in `bin` and `libexec` directories using said variables.
- [`wrapGAppsHook3`]{#ssec-gnome-hooks-wrapgappshook3} for GTK 3 apps. For convenience, it also adds `dconf.lib` for a GIO module implementing a GSettings backend using `dconf`, `gtk3` for GSettings schemas, and `librsvg` for GdkPixbuf loader to the closure.
- [`wrapGAppsHook4`]{#ssec-gnome-hooks-wrapgappshook4} for GTK 4 apps. Same as `wrapGAppsHook3` but replaces `gtk3` with `gtk4`.
The [standard build environment](#chap-stdenv) makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accommodated by overriding the appropriate phases of `stdenv`. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
::: {.tip}
New to packaging? Start with [](#chap-first-package), then return here for the ecosystem you need.
:::
Each supported language or software ecosystem has its own package set named `<language or ecosystem>Packages`, which can be explored in various ways:
- Search on [search.nixos.org](https://search.nixos.org/packages)
@@ -305,12 +305,10 @@ This package puts the corepack wrappers for pnpm and yarn in your PATH, and they
### pnpm {#javascript-pnpm}
pnpm is available as the top-level package `pnpm`. Additionally, there are variants pinned to certain major versions, like `pnpm_9`, `pnpm_10`, `pnpm_10_29_2` and `pnpm_11`, which support different sets of lock file versions.
pnpm is available as the top-level package `pnpm`. Additionally, there are variants pinned to certain major versions, like `pnpm_8`, `pnpm_9`, `pnpm_10`, `pnpm_10_29_2` and `pnpm_11`, which support different sets of lock file versions.
When packaging an application that includes a `pnpm-lock.yaml`, you need to fetch the pnpm store for that project using a fixed-output-derivation. The function `fetchPnpmDeps` can create this pnpm store derivation. In conjunction, the setup hook `pnpmConfigHook` will prepare the build environment to install the pre-fetched dependencies store. Here is an example for a package that contains `package.json` and a `pnpm-lock.yaml` files using the fetcher and setup hook above:
There is also the [`pnpmBuildHook`](#pnpm-build-hook) for building packages with `pnpm`, as seen in [](#ex-pnpm-build-hook).
```nix
{
fetchPnpmDeps,
@@ -408,8 +406,6 @@ In case you are patching `package.json` or `pnpm-lock.yaml`, make sure to pass `
}
```
If needed, `dontPnpmConfigure = true;` can be used to fully disable `pnpmConfigHook` without manually removing it from inputs.
#### Dealing with `sourceRoot` {#javascript-pnpm-sourceRoot}
If the pnpm project is in a subdirectory, you can just define `sourceRoot` or `setSourceRoot` for `fetchPnpmDeps`.
@@ -495,7 +491,7 @@ In this example, `prePnpmInstall` will be run by both `pnpmConfigHook` and by th
This is the version of the output of `fetchPnpmDeps`. New packages should use `4`:
This is the version of the output of `fetchPnpmDeps`. New packages should use `3`:
```nix
{
@@ -515,10 +511,10 @@ Changes can include workarounds or bug fixes to existing PNPM issues.
##### Version history {#javascript-pnpm-fetcherVersion-versionHistory}
Version 3 is the minimum supported value. Versions 1 and 2 were removed in the 26.11 release; packages that still use them fail to evaluate and must migrate to `fetcherVersion = 3` (or later) and regenerate their hashes.
Version 3 is the recommended value for new packages. Versions 1 and 2 are deprecated and scheduled for removal in the 26.11 release; existing packages must migrate.
- 1: Initial version, nothing special. (removed in 26.11)
- 2: [Ensure consistent permissions](https://github.com/NixOS/nixpkgs/pull/422975) (removed in 26.11)
To add a new package without updating all packages, run
```sh
nix-shell -p luarocks-packages-updater
luarocks-packages-updater add <package-name>
```
[luarocks2nix](https://github.com/nix-community/luarocks) is a tool capable of generating nix derivations from both rockspec and src.rock (and favors the src.rock).
The automation only goes so far though and some packages need to be customized.
These customizations go in [pkgs/development/lua-modules/overrides.nix](https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/lua-modules/overrides.nix).
@@ -174,59 +174,6 @@ To make sure that your package does not add extra manual effort when upgrading M
</plugin>
```
## Maven 4 {#maven-4}
Alongside the default `maven` package (the latest Maven 3 release), nixpkgs ships `maven_4`, which packages the [Maven 4](https://maven.apache.org/whatsnewinmaven4.html) release line.
`maven_4` is a standalone derivation and can be used as a drop-in replacement wherever `maven` is used, for example to build a project with the latest Maven 4:
`maven_4` exposes the same `buildMavenPackage` helper as `maven` (see [](#maven-buildmavenpackage)), so all of the patterns documented above apply equally. Note that the Maven dependencies resolved by Maven 4 differ from those resolved by Maven 3, so `mvnHash` must be recomputed when switching between the two.
## Manually using `mvn2nix` {#maven-mvn2nix}
::: {.warning}
This way is no longer recommended; see [](#maven-buildmavenpackage) for the simpler and preferred way.
@@ -341,7 +288,7 @@ The double invocation is a _simple_ way to get around the problem that `nix-buil
It treats the entire Maven repository as a single source to be downloaded, relying on Maven's dependency resolution to satisfy the output hash. This is similar to fetchers like `fetchgit`, except it has to run a Maven build to determine what to download.
The first step will be to build the Maven project as a fixed-output derivation to collect the Maven repository -- below is an [example](https://github.com/fzakaria/nixos-maven-example/blob/main/double-invocation-repository.nix).
The first step will be to build the Maven project as a fixed-output derivation in order to collect the Maven repository -- below is an [example](https://github.com/fzakaria/nixos-maven-example/blob/main/double-invocation-repository.nix).
::: {.note}
Traditionally the Maven repository is at `~/.m2/repository`. We will override this to be the `$out` directory.
@@ -469,7 +416,7 @@ The previous example builds a `jar` file but that's not a file one can run.
You need to use it with `java -jar $out/share/java/output.jar` and make sure to provide the required dependencies on the classpath.
The following explains how to use `makeWrapper` to make the derivation produce an executable that will run the JAR file you created.
The following explains how to use `makeWrapper` in order to make the derivation produce an executable that will run the JAR file you created.
We will use the same repository we built above (either _double invocation_ or _buildMaven_) to setup a CLASSPATH for our JAR.
# See examples below on how to use custom packages.
@@ -47,7 +47,7 @@ neovim-qt.override {
neovim=neovim.override{
configure={
customRC=''
"yourcustomvimlconfiguration
#yourcustomvimlconfiguration
'';
};
};
@@ -64,14 +64,11 @@ For instance, `sqlite-lua` needs `g:sqlite_clib_path` to be set to work. Nixpkgs
-`wrapRc`: Nix, not being able to write in your `$HOME`, loads the
generated Neovim configuration via the `$VIMINIT` environment variable, i.e. : `export VIMINIT='lua dofile("/nix/store/…-init.lua")'`. This has side effects like preventing Neovim from sourcing your `init.lua` in `$XDG_CONFIG_HOME/nvim` (see bullet 7 of [`:help startup`](https://neovim.io/doc/user/starting.html#startup) in Neovim). Disable it if you want to generate your own wrapper. You can still reuse the generated vimscript init code via `neovim.passthru.initRc`.
-`plugins`: A list of plugins to add to the wrapper.
-`extraLuaPackages`: A function passed on to `lua.withPackages`.
-`extraPython3Packages`: A function passed on to `python3.withPackages`.
-`withPython3`, `withNodeJs`, `withRuby`, `withPerl` control when to enable neovim
-`extraLuaPackages`: A function passed on to `lua.withPackages`
-`withPython3`, `withNodeJs`, `withRuby` control when to enable neovim
providers (see `:h provider`).
-`vimAlias` and `viAlias` control whether to symlink the `vim` and `vi` binaries to `nvim` respectively.
-`extraName` is a string appended to the package name and derivation name.
You can explore the configuration with`nix repl` to discover these options and
You can explore the configuration with`nix repl` to discover these options and
override them. For instance:
```nix
neovim.override{
neovim.overrideAttrs(oldAttrs:{
autowrapRuntimeDeps=false;
}
})
```
## Specificities for some plugins {#neovim-plugin-specificities}
@@ -152,7 +136,7 @@ For example, if upstream documents that a plugin uses the Vim license but GitHub
## LuaRocks based plugins {#neovim-luarocks-based-plugins}
To automatically handle plugin dependencies, several Neovim plugins
In order to automatically handle plugin dependencies, several Neovim plugins
upload their package to [LuaRocks](https://www.luarocks.org). This means less work for nixpkgs maintainers in the long term as dependencies get updated automatically.
This means several Neovim plugins are first packaged as nixpkgs [lua
packages](#packaging-a-library-on-luarocks), and converted via `buildNeovimPlugin` in
@@ -167,8 +151,6 @@ For instance:
```
To update these packages, you should use the lua updater rather than vim's.
To add a lua package to the `vimPlugins` set, add it to the `luarocksPackageNames` list in [luaPackagePlugins.nix](https://github.com/nixos/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/luaPackagePlugins.nix).
## Treesitter {#neovim-plugin-treesitter}
[Treesitter](https://tree-sitter.github.io/) provides syntax parsing for Neovim, enabling features like:
@@ -264,43 +246,6 @@ You can install the standalone parsers and queries directly without installing `
})
```
### Treesitter setup using WASM parsers and queries {#neovim-plugin-treesitter-wasm}
Neovim can load WASM parsers when it is built with Wasmtime support.
In nixpkgs, WASM parser plugins are available from the `wasi32` cross package set:
##### Using fixed-point arguments {#buildpythonpackage-fixed-point-arguments}
Use `finalAttrs` to make a package easy to update and override:
Both `buildPythonPackage` and `buildPythonApplication` support [fixed-point arguments](#chap-build-helpers-finalAttrs), similar to `stdenv.mkDerivation`.
This allows you to reference the final attributes of the derivation.
When a downstream callsite *overrides* `version` the override becomes visible as `finalAttrs.version`.
Both `buildPythonPackage` and `buildPythonApplication` support [fixed-point arguments](#chap-build-helpers-finalAttrs), similar to `stdenv.mkDerivation`.
See the [general documentation on fixed-point arguments](#chap-build-helpers-finalAttrs) for more details on the benefits of this pattern.
::: {.note}
@@ -270,27 +287,29 @@ because their behaviour is different:
The `buildPythonPackage` function has a `overridePythonAttrs` method that can be
used to override the package. In the following example we create an environment
where we have the `blaze` package using an older version of `pandas`. We
first override the Python package set, then instantiate an interpreter with
that package set.
override first the Python interpreter and pass `packageOverrides` which contains
@@ -51,7 +51,7 @@ The recommended way of defining a derivation for a Rocq library, is to use the `
* if it is a string of the form `owner:branch` then it tries to download the `branch` of owner `owner` for a project of the same name using the same vcs, and the `version` attribute of the resulting derivation is set to `"dev"`, additionally if the owner is not provided (i.e. if the `owner:` prefix is missing), it defaults to the original owner of the package (see below),
* if it is a string of the form `"#N"`, and the domain is github, then it tries to download the current head of the pull request `#N` from github,
*`defaultVersion` (optional). Rocq libraries may be compatible with some specific versions of Rocq only. The `defaultVersion` attribute is used when no `version` is provided (or if `version = null`) to select the version of the library to use by default, depending on the context. This selection will mainly depend on a `rocq-core` version number but also possibly on other packages versions (e.g. `mathcomp`). If its value ends up to be `null`, the package is marked for removal in end-user `rocqPackages` attribute set.
*`release` (optional, defaults to `{}`), lists all the known releases of the library and for each of them provides an attribute set with at least a `hash` attribute (you may put the empty string `""` to automatically insert a fake hash, this will trigger an error which will allow you to find the correct hash), each attribute set of the list of releases also takes optional overloading arguments for the fetcher as below (i.e.`domain`, `owner`, `repo`, `rev`, `artifact` assuming the default fetcher is used) and optional overrides for the result of the fetcher (i.e. `version` and `src`).
*`release` (optional, defaults to `{}`), lists all the known releases of the library and for each of them provides an attribute set with at least a `hash` attribute (you may put the empty string `""` in order to automatically insert a fake hash, this will trigger an error which will allow you to find the correct hash), each attribute set of the list of releases also takes optional overloading arguments for the fetcher as below (i.e.`domain`, `owner`, `repo`, `rev`, `artifact` assuming the default fetcher is used) and optional overrides for the result of the fetcher (i.e. `version` and `src`).
*`fetcher` (optional, defaults to a generic fetching mechanism supporting github or gitlab based infrastructures), is a function that takes at least an `owner`, a `repo`, a `rev`, and a `hash` and returns an attribute set with a `version` and `src`.
*`repo` (optional, defaults to the value of `pname`),
*`owner` (optional, defaults to `"rocq-community"`).
@@ -59,7 +59,7 @@ The recommended way of defining a derivation for a Rocq library, is to use the `
*`releaseRev` (optional, defaults to `(v: v)`), provides a default mapping from release names to revision hashes/branch names/tags,
*`releaseArtifact` (optional, defaults to `(v: null)`), provides a default mapping from release names to artifact names (only works for github artifact for now),
*`displayVersion` (optional), provides a way to alter the computation of `name` from `pname`, by explaining how to display version numbers,
*`namePrefix` (optional, defaults to `[ "rocq" ]`), provides a way to alter the computation of `name` from `pname`, by explaining which dependencies must occur in `name`,
*`namePrefix` (optional, defaults to `[ "rocq-core" ]`), provides a way to alter the computation of `name` from `pname`, by explaining which dependencies must occur in `name`,
*`nativeBuildInputs` (optional), is a list of executables that are required to build the current derivation, in addition to the default ones (namely `which`, `dune` and `ocaml` depending on whether `useDune`, `useDuneifVersion` and `mlPlugin` are set).
*`extraNativeBuildInputs` (optional, deprecated), an additional list of derivation to add to `nativeBuildInputs`,
*`overrideNativeBuildInputs` (optional) replaces the default list of derivation to which `nativeBuildInputs` and `extraNativeBuildInputs` adds extra elements,
@@ -74,8 +74,6 @@ The recommended way of defining a derivation for a Rocq library, is to use the `
*`enableParallelBuilding` (optional, defaults to `true`), since it is activated by default, we provide a way to disable it.
*`extraInstallFlags` (optional), allows to extend `installFlags` which initializes the variables `COQLIBINSTALL` and `COQPLUGININSTALL` so as to install in the proper subdirectory. Indeed Rocq libraries should be installed in `$(out)/lib/coq/${rocq-core.rocq-version}/user-contrib/`. Such directories are automatically added to the `$ROCQPATH` environment variable by the hook defined in the Rocq derivation.
*`setROCQBIN` (optional, defaults to `true`), by default, the environment variable `$ROCQBIN` is set to the current Rocq's binary, but one can disable this behavior by setting it to `false`,
*`useCoq` (optional, defaults to `false`), adds the Coq compatibility binaries to the build environment, which is necessary for some packages that still depend on them and sets `COQBIN` to the path of the `coqc` binary (if `setROCQBIN` is also set to `true`). A wrapper `mkCoqDerivation` is provided that sets this option to `true`.
*`useCoqifVersion` (optional, defaults to `(x: false)`), adds the Coq compatibility binaries to the build environment if the provided predicate evaluates to true on the version. This can be useful for supporting old package versions that need the Coq compatibility binaries, while newer versions do not.
*`useMelquiondRemake` (optional, default to `null`) is an attribute set, which, if given, overloads the `preConfigurePhases`, `configureFlags`, `buildPhase`, and `installPhase` attributes of the derivation for a specific use in libraries using `remake` as set up by Guillaume Melquiond for `flocq`, `gappalib`, `interval`, and `coquelicot` (see the corresponding derivation for concrete examples of use of this option). For backward compatibility, the attribute `useMelquiondRemake.logpath` must be set to the logical root of the library (otherwise, one can pass `useMelquiondRemake = {}` to activate this without backward compatibility).
*`dropAttrs`, `keepAttrs`, `dropDerivationAttrs` are all optional and allow to tune which attribute is added or removed from the final call to `mkDerivation`.
@@ -155,7 +153,7 @@ For example, assuming you have a special `mathcomp` dependency you want to use,
@@ -125,7 +125,7 @@ With this file in your directory, you can run `nix-shell` to build and use the g
The `bundlerEnv` is a wrapper over all the gems in your gemset. This means that all the `/lib` and `/bin` directories will be available, and the executables of all gems (even of indirect dependencies) will end up in your `$PATH`. The `wrappedRuby` provides you with all executables that come with Ruby itself, but wrapped so they can easily find the gems in your gemset.
One common issue that you might have is that you have Ruby, but also `bundler` in your gemset. That leads to a conflict for `/bin/bundle` and `/bin/bundler`. You can resolve this by wrapping either your Ruby or your gems in a `lowPrio` call. So to give the `bundler` from your gemset priority, it would be used like this:
One common issue that you might have is that you have Ruby, but also `bundler` in your gemset. That leads to a conflict for `/bin/bundle` and `/bin/bundler`. You can resolve this by wrapping either your Ruby or your gems in a `lowPrio` call. So in order to give the `bundler` from your gemset priority, it would be used like this:
```nix
# ...
@@ -265,7 +265,7 @@ Now that you know how to get a working Ruby environment with Nix, it's time to g
All gems in the standard set are automatically generated from a single `Gemfile`. The dependency resolution is done with `bundler` and makes it more likely that all gems are compatible with each other.
To add a new gem to nixpkgs, you can put it into the `/pkgs/development/ruby-modules/with-packages/Gemfile` and run `./maintainers/scripts/update-ruby-packages`.
In order to add a new gem to nixpkgs, you can put it into the `/pkgs/development/ruby-modules/with-packages/Gemfile` and run `./maintainers/scripts/update-ruby-packages`.
To test that it works, you can then try using the gem with:
@@ -153,7 +153,7 @@ Nix expressions for Vim plugins are stored in [pkgs/applications/editors/vim/plu
When the vim updater detects an nvim-treesitter update, it also runs [`nvim-treesitter/update.py $(nix-build -A vimPlugins.nvim-treesitter)`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/utils/update.py) to update the tree sitter grammars for `nvim-treesitter`.
Some plugins require overrides to function properly. Overrides are placed in [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:
Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:
@@ -10,7 +10,7 @@ The tarball archive needs to be downloaded manually, as the license agreements o
The [self-service](https://support.citrix.com/article/CTX200337) is an application for managing Citrix desktops and applications. Please note that this feature only works with at least `citrix_workspace_20_06_0` and later versions.
To set this up, you first have to [download the `.cr` file from the Netscaler Gateway](https://its.uiowa.edu/support/article/102186). After that, you can configure the `selfservice` like this:
In order to set this up, you first have to [download the `.cr` file from the Netscaler Gateway](https://its.uiowa.edu/support/article/102186). After that, you can configure the `selfservice` like this:
```ShellSession
$ storebrowse -C ~/Downloads/receiverconfig.cr
@@ -19,7 +19,7 @@ $ selfservice
## Custom certificates {#sec-citrix-custom-certs}
The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However, several companies using Citrix might require their own corporate certificate. On distros with imperative packaging, these certs can be stored easily in [`$ICAROOT`](https://citrix.github.io/receiver-for-linux-command-reference/), however, this directory is a store path in `nixpkgs`. To work around this issue, the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However, several companies using Citrix might require their own corporate certificate. On distros with imperative packaging, these certs can be stored easily in [`$ICAROOT`](https://citrix.github.io/receiver-for-linux-command-reference/), however, this directory is a store path in `nixpkgs`. In order to work around this issue, the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
@@ -24,7 +24,7 @@ The Emacs package comes with some extra helpers to make it easier to configure.
}
```
You can install it like any other package via `nix-env -iA myEmacs`. However, this will only install those packages. It will not `configure` them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provides a `default.el` file in `/share/emacs/site-start/`. Emacs knows to load this file automatically when it starts. Similarly, for `early-init.el`, you can create a package that provides an `early-default.el` file in `/share/emacs/site-start/`.
You can install it like any other package via `nix-env -iA myEmacs`. However, this will only install those packages. It will not `configure` them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provides a `default.el` file in `/share/emacs/site-start/`. Emacs knows to load this file automatically when it starts.
- `collabora-desktop` The desktop version of Collabora Office is now available, package version `25.05.9.2-2`.
- The `services.geoserver` NixOS module has been added to allow running [Geoserver](https://geoserver.org/) as a service.
- `fetchPnpmDeps` and `pnpmConfigHook` were added as top-level attributes, replacing the now deprecated `pnpm.fetchDeps` and `pnpm.configHook` attributes.
- `fetchPnpmDeps`' `fetcherVersion = 1` and `fetcherVersion = 2` are deprecated
<!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
- []{#x86_64-darwin-26.11}
Support for `x86_64-darwin` has been dropped, due to Apple’s deprecation of the platform and limited build infrastructure and developer time.
We will no longer build packages for the platform or support building them from source.
The Nixpkgs 26.05 stable branch will still maintain platform support and binaries will be built until it goes out of support at the end of 2026.
Users of `x86_64-darwin` will receive an error message explaining how to switch to 26.05.
By the time of this release, Homebrew will offer only limited [Tier 3](https://docs.brew.sh/Support-Tiers#tier-3) support for the platform, but MacPorts will likely continue to support it for a long time.
We also recommend users consider installing NixOS, which should continue to run on essentially all Intel Macs, especially after Apple stops security support for macOS 26 in 2028.
- `databricks-cli` has been updated from `0.290.2` to `1.x.x`, the first major release. OAuth tokens for interactive logins (`auth_type = databricks-cli`) are now stored in the OS-native secure store by default (Secret Service on Linux) instead of `~/.databricks/token-cache.json`; cached tokens from older versions are not migrated, so run `databricks auth login` once per profile after upgrading. To keep the previous file-backed storage, set `DATABRICKS_AUTH_STORAGE=plaintext` or add `auth_storage = plaintext` under `[__settings__]` in `~/.databrickscfg`. Additionally, the `vector_search_endpoints` DABs resource renamed `min_qps` to `target_qps` (and the `vector-search-endpoints` command renamed `--min-qps` to `--target-qps`). See the [upstream changelog](https://github.com/databricks/cli/blob/main/CHANGELOG.md) for details.
- `hurl` has been updated to `8.x.x` which has some breaking changes. See [upstream changelog](https://github.com/Orange-OpenSource/hurl/releases/tag/8.0.0) for details.
- `gotosocial` has been updated to 0.22.0. This release contains a very long database migration, which should not be cancelled or interrupted under any circumstances.
- Postgres users: Following the migration, if you encounter slowdown on Postgres specifically (ie., timing out while loading timelines) you may need to run some manual database maintenance steps. Please check https://docs.gotosocial.org/en/stable/admin/database_maintenance/#postgres.
- `xsecurelock` no longer supports authentication via htaccess files (`~/.xsecurelock.pw`) or via the `pamtester` program by default. Only the recommended PAM module is supported unless rebuilt with `withHtaccess` or `withPamtester`.
- `python3Packages.django-health-check` has been updated to major version 4. See its [migration guide](https://codingjoe.dev/django-health-check/migrate-to-v4/) and [changelog](https://github.com/codingjoe/django-health-check/releases/tag/4.0.0) for breaking changes.
- `libgdata` has been removed, as it was archived upstream and relied on the insecure libsoup 2.4.
- `mcphost` has been removed, as it was archived upstream and declared unmaintained.
- `fflogs` has been removed because it was no longer functional. Users should switch to `archon-lite`.
- `services.mysql` now sets `root@localhost` authentication to `auth_socket` when used with `mysql` or `percona-server`.
Existing deployments will also be adjusted if possible. See the [security advisory GHSA-6qxx-6rg8-c4p8](https://github.com/NixOS/nixpkgs/security/advisories/GHSA-6qxx-6rg8-c4p8) for more information.
- `zerofs` has been updated from `1.x` to `2.x` which is a breaking change. Volumes created by earlier releases are refused at open with a clear error. There is no migration tool; older volumes remain readable and writable by the release that created them.
- `keycloak.plugins.keycloak-metrics-spi` has been removed. Keycloak exposes Prometheus metrics natively on its management interface; enable them with the `metrics-enabled` setting (and `event-metrics-user-enabled` for login and event counters). See [Gaining insights with metrics](https://www.keycloak.org/observability/configuration-metrics).
- `alps` has been rewritten upstream, see [upstream repository](https://github.com/migadu/alps) for documentation.
- `uhttpmock` providing 0.0 ABI was removed. `uhttpmock_1_0` providing 1.0 ABI was renamed to `uhttpmock` and `uhttpmock_1_0` was kept as an alias.
- `nix-serve-ng` (and `haskellPackages.nix-serve-ng`) is now built against Lix instead of CppNix, following upstream which has switched to Lix as its supported Nix implementation.
- Linux kernel configuration has been moved out of the `linux-kernel` field of the platform structure into the kernel builders:
- `linux-kernel.name` has been removed.
- `linux-kernel.target` is available as the `target` parameter and passthru attribute on the kernel builders.
- `linux-kernel.installTarget` has been removed, as it should not be necessary to customize.
- `linux-kernel.DTB` is available as the `buildDTBs` parameter and passthru attribute on the kernel builders.
- `linux-kernel.{autoModules,preferBuiltin,extraConfig}` were already available as kernel builder parameters.
- The `img` argument of `vmTools` has been renamed to `kernelImage`, as it collided with the top-level `img` package.
Additionally, the kernel module tree used inside the VM has been split out of the `kernel` argument into a new `kernelModules` argument (defaulting to `kernel`).
Callers that overrode `kernel` with a module tree (e.g. from `pkgs.aggregateModules`) to make extra modules available must now pass it via `kernelModules` instead, keeping `kernel` pointing at a bootable kernel derivation.
- The ARMv5 Linux kernel build now uses a standard configuration and generates a standard compressed image instead of the deprecated legacy U‐Boot image format.
`lib.systems.{examples,platforms}.{sheevaplug,pogoplug4}` have been unified into `lib.systems.examples.armv5tel-multiplatform`.
Note that there is no official support for ARMv5 and it is not possible to build even a simple NixOS configuration out of the box.
- `pdns` has been updated from `5.0.x` to `5.1.x`. Please be sure to review the [Upgrade Notes](https://doc.powerdns.com/authoritative/upgrading.html#to-5-1-0) before upgrading. Namely LUA record updates are no longer allowed by default, and the embedded webserver no longer includes a `access-control-allow-origin: *` header by default.
- Support for the legacy U‐Boot image format has been removed from the Linux kernel builders, as it is deprecated upstream and no longer used by any platform in Nixpkgs.
- `etcd_3_4` package was dropped, as it's gone EOL. Please upgrade to either 3.5 or 3.6. See [migration notes](https://etcd.io/docs/v3.6/upgrades/upgrade_3_6/) for incompatibilities and upgrade procedure.
- `rke2` retires ingress-nginx and transitions to Traefik starting in `rke2_1_36`. Because ingress-nginx was retired upstream as of March 2026, Traefik is now the default
for new clusters starting in v1.36 (existing clusters will keep their current ingress upon upgrade to avoid breakage). This transition brings the following structural changes:
- Airgapped Environments: The rke2-images-core tarball now contains Traefik images instead of ingress-nginx. The standalone rke2-images-traefik tarball has been removed.
Users who must continue using ingress-nginx will now need to manually provide the rke2-images-ingress-nginx tarball.
- Future Removal: The ingress-nginx chart will not receive any additional updates and will be completely removed in v1.37 for community users.
- `buildFHSEnvChroot` has been removed after deprecation in 23.05.
- `gh-actions-cache` has been removed since its functionality has been integrated directly into `gh` (`gh cache`). See [upstream readme](https://github.com/actions/gh-actions-cache).
- `requireFile` now sets `meta.license = lib.licenses.unfree` by default. Users of `requireFile`-based derivations that preserve this default will need to explicitly allow their evaluation as described in [](#sec-allow-unfree).
- `texlive.combine` is deprecated and scheduled for removal in 27.05. Please migrate to `texliveSmall.withPackages` (see [](#sec-language-texlive-user-guide)).
- `keycloak` was updated to >= 26.7.0 and includes some breaking internal (API) changes. See the [upstream migration guide](https://www.keycloak.org/docs/latest/upgrading/#migrating-to-26-7-0) for more information.
- `librest` providing 0.7 ABI was removed. `librest_1_0` providing 1.0 ABI was renamed to `librest` and `librest_1_0` was kept as an alias.
- `pnpm_10` was upgraded to version 10.34.1+, which introduced stricter integrity checks. If you encounter `ERR_PNPM_MISSING_TARBALL_INTEGRITY`, you can fall back to the older `pnpm_10_34_0`.
- `fetchPnpmDeps`' `fetcherVersion = 1` and `fetcherVersion = 2` have been
removed, as announced in the 26.05 release. Packages still using them now
throw an evaluation error and must migrate to `fetcherVersion = 3` (or later)
and regenerate their hashes. See the
[pnpm `fetcherVersion` section](#javascript-pnpm-fetcherVersion) of the manual
for details.
- `rebuilderd` has been updated to 0.27.0 introducing breaking changes. See upstream changelog for details: [0.26.0](https://github.com/kpcyrd/rebuilderd/releases/tag/v0.26.0), [0.27.0](https://github.com/kpcyrd/rebuilderd/releases/tag/v0.27.0)
- Starting with v14, `flameshot` will primarily utilise xdg-desktop-portal calls for screenshotting. This will directly affect users on X11 window managers due to the lack of a compatible portal with Screenshot feature. See [upstream changelog](https://github.com/flameshot-org/flameshot/releases/tag/v14.0.0) or [NixOS Flameshot](https://wiki.nixos.org/wiki/Flameshot) wiki page for workarounds.
- `nim1` and respective aliases have been removed due to entering EOL; please migrate to `nim` or `nim-unwrapped` (nim 2).
- `nim-2_0` & `nim-2_2` and respective aliases have been removed; please migrate to `nim` or `nim-unwrapped` (nim 2.2.10).
- `domoticz` has been updated from `2024.7` to `2026.x`, breaking third party applications and scripts using the old RType calls. Review the [release notes](https://github.com/domoticz/domoticz/blob/2026.2/History.txt#L398) for more information.
- `vimacs` has been removed, as it has not been maintained in 10 years and was built for an old version of vim (6.0).
- Create the first release note entry in this section!
## Other Notable Changes {#sec-nixpkgs-release-26.11-notable-changes}
<!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
- `super-productivity` has been updated. The binary has been renamed from `super-productivity` to `superproductivity`. A symlink from the old name is provided for backward compatibility.
- Package-URL (PURL, https://github.com/package-url/purl-spec) metadata identifier has been added for `fetchgit`, `fetchpypi` and `fetchFromGithub` fetchers.
`mkDerivation` has been adjusted to reuse this information.
Package-URLs allow reliably identifying and locating software packages.
Maintainers of derivations using the adapted fetchers should rely on the `drv.src.meta.identifiers.v1.purl` default identifier and can enhance their `drv.meta.identifiers.v1.purls` list once they would like to have additional identifiers.
Maintainers using `fetchurl` for `drv.src` are urged to adapt their `drv.meta.identifiers.purlParts` for proper identification.
- Emacs loads the `early-default` library after `early-init.el`.
Users can add `early-init.el` via `emacs.pkgs.withPackages`
by packaging `early-init.el` into a library named `early-default`.
To prevent loading the `early-default` library,
set `inhibit-early-default-init` in `early-init.el`.
- `services.ceph` enabled the generation of Ceph log files at `/var/log/ceph/`.
They were missing before because Ceph omitted logs when this directory was missing.
Ceph logs can grow large, so you may want to configure rotation of these logs.
- Create the first release note entry in this section!
- `fittrackee` 1.0.0 now requires postgres with postgis. The [upgrade guide](https://docs.fittrackee.org/en/upgrading-to-1.0.0.html) has steps to prepare for this upgrade.
- Create the first release note entry in this section!
@@ -50,7 +50,7 @@ The exact schema these fields follow is a bit ill-defined due to a long and conv
`system`
: This is a two-component shorthand for the platform. Examples of this would be "aarch64-darwin" and "i686-linux"; see `lib.systems.doubles` for more. The first component corresponds to the CPU architecture of the platform and the second to the operating system of the platform (`[cpu]-[os]`). This format has built-in support in Nix, such as the `builtins.currentSystem` impure string.
: This is a two-component shorthand for the platform. Examples of this would be "x86_64-darwin" and "i686-linux"; see `lib.systems.doubles` for more. The first component corresponds to the CPU architecture of the platform and the second to the operating system of the platform (`[cpu]-[os]`). This format has built-in support in Nix, such as the `builtins.currentSystem` impure string.
@@ -77,7 +77,7 @@ A link or a list of links to the location of Changelog for a package. A link may
### `license` {#var-meta-license}
The license, or licenses, for the package. One from the attribute set defined in [`nixpkgs/lib/licenses/licenses.nix`](https://github.com/NixOS/nixpkgs/blob/master/lib/licenses/licenses.nix). At this moment using both a list of licenses and a single license is valid. If the license field is in the form of a list representation, then it means that parts of the package are licensed differently. Each license should preferably be referenced by their attribute. The non-list attribute value can also be a space delimited string representation of the contained attribute `shortNames` or `spdxIds`. The following are all valid examples:
The license, or licenses, for the package. One from the attribute set defined in [`nixpkgs/lib/licenses.nix`](https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix). At this moment using both a list of licenses and a single license is valid. If the license field is in the form of a list representation, then it means that parts of the package are licensed differently. Each license should preferably be referenced by their attribute. The non-list attribute value can also be a space delimited string representation of the contained attribute `shortNames` or `spdxIds`. The following are all valid examples:
- Single license referenced by attribute (preferred) `lib.licenses.gpl3Only`.
- Single license referenced by its attribute shortName (frowned upon) `"gpl3Only"`.
@@ -157,8 +157,6 @@ The list of Nix platform types for which the [Hydra](https://github.com/nixos/hy
}
```
Note that this does not affect whether reverse dependencies of the package are built on Hydra.
### `broken` {#var-meta-broken}
If set to `true`, the package is marked as "broken", meaning that it won’t show up in [search.nixos.org](https://search.nixos.org/packages), and cannot be built or installed unless [explicitly allowed](#sec-allow-broken).
@@ -216,7 +214,7 @@ If this list is not empty, the package is marked as "insecure", meaning that it
## Licenses {#sec-meta-license}
The `meta.license` attribute should preferably contain a value from `lib.licenses` defined in [`nixpkgs/lib/licenses/licenses.nix`](https://github.com/NixOS/nixpkgs/blob/master/lib/licenses/licenses.nix), or in-place license description of the same format if the license is unlikely to be useful in another expression.
The `meta.license` attribute should preferably contain a value from `lib.licenses` defined in [`nixpkgs/lib/licenses.nix`](https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix), or in-place license description of the same format if the license is unlikely to be useful in another expression.
Although it’s typically better to indicate the specific license, a few generic options are available:
@@ -342,30 +340,3 @@ A readonly attribute that concatenates all CPE parts in one string.
A readonly attribute containing the list of guesses for what CPE for this package can look like. It includes all variants of version handling mentioned above. Each item is an attrset with attributes `cpeParts` and `cpe` for each guess.
### Package URL {#sec-meta-identifiers-purl}
[Package-URL](https://github.com/package-url/purl-spec) (PURL) is a specification to reliably identify and locate software packages.
Through identification of software packages, additional (non-major) use cases are e.g. software license cross-verification via third party databases or initial vulnerability response management.
Package-URLs shall default to the `mkDerivation.src`, as the original consumed software package is the single source of truth.
This attribute contains an attribute set of all parts of the PURL for this package.
* `type` mandatory [type](https://github.com/package-url/purl-spec/blob/18fd3e395dda53c00bc8b11fe481666dc7b3807a/docs/standard/summary.md) which needs to be provided
* `spec` specify the PURL in accordance with the [purl-spec](https://github.com/package-url/purl-spec/blob/18fd3e395dda53c00bc8b11fe481666dc7b3807a/purl-specification.md)
An extendable list attribute which defaults to a single element equal to [`meta.identifiers.purl`](#var-meta-identifiers-purl).
It provides an interface for additional identifiers of `mkDerivation.src` or for identifiers of vendored dependencies inside `mkDerivation.src`, which maintainers may carefully consider to specify as well.
Additional identifiers are generally not recommended, as they might cause maintenance overhead or diverge.
For example, a source distribution `pkg:github` may be hard to keep correctly aligned with the corresponding binary distribution `pkg:pypi`.
By default, the configure phase applies some special hackery to all files called `ltmain.sh` before running the configure script to improve the purity of Libtool-based packages [^footnote-stdenv-sys-lib-search-path] . If this is undesirable, set this variable to true.
By default, the configure phase applies some special hackery to all files called `ltmain.sh` before running the configure script in order to improve the purity of Libtool-based packages [^footnote-stdenv-sys-lib-search-path] . If this is undesirable, set this variable to true.
@@ -939,7 +939,7 @@ The fixup phase performs (Nix-specific) post-processing actions on the files ins
- It moves the `man/`, `doc/` and `info/` subdirectories of `$out` to `share/`.
- It strips libraries and executables of debug information.
- On Linux, it applies the `patchelf` command to ELF executables and libraries to remove unused directories from the `RPATH` to prevent unnecessary runtime dependencies.
- On Linux, it applies the `patchelf` command to ELF executables and libraries to remove unused directories from the `RPATH` in order to prevent unnecessary runtime dependencies.
- It rewrites the interpreter paths of shell scripts to paths found in `PATH`. E.g., `/usr/bin/perl` will be rewritten to `/nix/store/some-perl/bin/perl` found in `PATH`. See [](#patch-shebangs.sh) for details.
#### Variables controlling the fixup phase {#variables-controlling-the-fixup-phase}
@@ -1345,7 +1345,7 @@ $ echo $configureFlags
Nix itself considers a build-time dependency as merely something that should previously be built and accessible at build time—packages themselves are on their own to perform any additional setup. In most cases, that is fine, and the downstream derivation can deal with its own dependencies. But for a few common tasks, that would result in almost every package doing the same sort of setup work—depending not on the package itself, but entirely on which dependencies were used.
To alleviate this burden, the setup hook mechanism was written, where any package can include a shell script that \[by convention rather than enforcement by Nix\], any downstream reverse-dependency will source as part of its build process. That allows the downstream dependency to merely specify its dependencies, and lets those dependencies effectively initialize themselves. No boilerplate mirroring the list of dependencies is needed.
In order to alleviate this burden, the setup hook mechanism was written, where any package can include a shell script that \[by convention rather than enforcement by Nix\], any downstream reverse-dependency will source as part of its build process. That allows the downstream dependency to merely specify its dependencies, and lets those dependencies effectively initialize themselves. No boilerplate mirroring the list of dependencies is needed.
The setup hook mechanism is a bit of a sledgehammer though: a powerful feature with a broad and indiscriminate area of effect. The combination of its power and implicit use may be expedient, but isn’t without costs. Nix itself is unchanged, but the spirit of added dependencies being effect-free is violated even if the latter isn’t. For example, if a derivation path is mentioned more than once, Nix itself doesn’t care and makes sure the dependency derivation is already built just the same—depending is just needing something to exist, and needing is idempotent. However, a dependency specified twice will have its setup hook run twice, and that could easily change the build environment (though a well-written setup hook will therefore strive to be idempotent so this is in fact not observable). More broadly, setup hooks are anti-modular in that multiple dependencies, whether the same or different, should not interfere and yet their setup hooks may well do so.
A consistent style greatly increases the usability of all documentation and communication.
Use this page as a reference and style guide for our internal and external documentation.
### Knowledge Expectations
**Assume competence, not familiarity.**
Write for someone who knows a great deal — up to but not including this project.
**What readers know:**
- Basic computer operation
- Command line familiarity
- General interest in systems configuration
**What readers don't know:**
- NixOS-specific concepts
- NixOS ecosystem details or grammar
- NixOS workflows
If specific knowledge is required, mention it at the start of the page.
#### Show, Don't Tell
The fastest path to understanding is a working example.
People learn by doing, not by reading about doing.
**Recommended structure:**
- Start with the minimal working code or command
- Briefly explain what it does
- Cover edge cases or variations
- Link to further information instead of including it
#### Grammar and Style
**Sentence structure:**
- Use simple, direct sentences
- Break complex ideas into multiple short sentences
- Avoid nested clauses
**Bad:**
> The following command, which utilizes nixos-generate-config to produce a comprehensive hardware configuration, will write the results back into the respective configuration directory located on your local machine.
What the user does is hidden in the middle.
`nixos-generate-config` is a leaked implementation detail.
Users care about *detecting hardware*, not *the tool that does it*.
**Good:**
> This command detects your hardware and saves the configuration.
#### Content Organization
Lead with value. State what the reader will accomplish before explaining how.
**Bad:**
> To create a new NixOS configuration that you can later use as a webserver, first navigate to your project directory, then add a new host configuration file with the desired machine name.
**Good:**
Add a webserver configuration to your NixOS setup:
```nix
# hosts/webserver/configuration.nix
{...}:
{
services.nginx.enable=true;
}
```
Use **progressive disclosure**. Introduce concepts only when needed.
**Recommended structure:**
1. State the goal (one sentence)
2. Show the simplest working example
3. Explain concepts if needed
4. Provide advanced options separately or link to the reference
#### No Meta-commentary
Don't describe what the documentation does. Just do it.
**Don't:**
> This section explains how to configure networking.
> The following guide walks you through setting up a web server.
**Do:**
> Configure networking by setting:
> Set up a web server:
#### Code Examples
**Keep examples focused:**
- Show one concept at a time
- Use realistic but simple scenarios
- Avoid dependencies on other examples
**Minimal comments**
Let the code speak for itself.
Paste code examples directly and without further alteration.
**Bad:**
```nix
# This sets the hostname for the machine
{
networking.hostName="webserver";# Change this to your machine's hostname
# This enables SSH access
services.openssh.enable=true;# Required for remote deployment
}
```
**Good:**
```nix
{
networking.hostName="webserver";
services.openssh.enable=true;
}
```
#### Lead with Practical Examples
Don't front-load theory. Readers want to accomplish something first, then understand why it works.
- Show configuration as *what you want*, not *how the module system works*
- Introduce Nix-specific concepts only when they are needed to complete the task
- Defer language mechanics to reference pages or `nix.dev`
**Bad:**
> Before adding a service, you need to understand the NixOS module system and attribute set merging.
**Good:**
Enable nginx:
```nix
{services.nginx.enable=true;}
```
This adds nginx to your system configuration. Rebuild to apply:
```bash
sudo nixos-rebuild switch
```
#### Teach Nix through examples, not theory
Users learn the NixOS module system by seeing patterns first.
- Start with a working example
- Explanation follows the code
- Link deeper concepts instead of inlining them
- Link to `nix.dev` for optional learning
#### General Rules
- Abbreviate keys like `ssh-ed25519 AAAAC3NzaC…`
- Abbreviate IP addresses like `192.168.XXX.XXX`
- Variables are capitalized and start with `$`, e.g. `$YOUR_HOSTNAME`
- Variables should be directly usable during copy-paste
- Do **not** describe missing code parts (`#elided`, `#omitted`)
- **Machine vs Host**: use "machine" for the NixOS system identity, "host" for the physical or virtual hardware
#### Capitalization
- GB / RAM / HDD
- bootable USB drive
- Wi-Fi / DHCP / DNS
- macOS / NixOS / Nix / Linux
- Flakes
- git
#### Headings
Use sentence case. A reader scanning only headings should understand the page.
**Don't:**
> Getting Started
> Overview
> Configure The Database
**Do:**
> Set up a PostgreSQL database
> Configure networking
> Add a user to the system
#### Imperative Mood, Voice, and Person
Use imperative mood for instructions. Address the reader as "you", not "the user". Use active voice; in other words, make the subject do the action.
**Don't:**
> The user should run the following command.
> The configuration will need to be updated.
> The key is generated by the system.
**Do:**
> Run the command.
> Update the configuration.
> The system generates the key.
#### Tense
Use present tense for descriptions. Future tense makes documentation feel tentative.
**Don't:**
> This will create a new folder.
> Running this command will install the package.
**Do:**
> This creates a new folder.
> Running this command installs the package.
#### Be Confident
State facts. Don't hedge with "should," "might," "typically," or "usually" unless the behavior genuinely varies.
**Don't:**
> This should create the configuration file.
> The service will usually start automatically.
**Do:**
> This creates the configuration file.
> The service starts automatically.
#### Avoid Nominalizations
A nominalization is a verb turned into a noun, often by adding *-tion*, *-meant*, or *-ance* (e.g. "explanation", "selection"). The fix: find the hidden verb and use it directly.
**Don't:**
> Make a selection from the list.
> Provide an explanation of the error.
**Do:**
> Select from the list.
> Explain the error.
#### Plain Words
Technical precision for technical terms; plain language for everything else.
- "use" not "utilize"
- "start" not "initiate"
- "end" not "terminate"
- "help" not "facilitate"
- "send" not "transmit"
- "set up" not "establish"
- "find out" not "ascertain"
#### Filler Words and Weak Phrases
Cut words and phrases that add length without meaning.
> In order to deploy, you first need to run the command, which allows you to push the config.
> It's worth noting that this requires root access.
**Do:**
> Run `nixos-rebuild switch`.
> To deploy, run:
> This requires root access.
Every word must earn its place.
#### Writing Procedures
One instruction per sentence. Don't pack multiple actions into one sentence.
**Don't:**
> Navigate to your project directory and run the command, then check the output.
**Do:**
1. Navigate to your project directory.
2. Run the command.
3. Check the output.
Don't bury the negative. Key limitations should be prominent, not a footnote after a positive description.
**Don't:**
> This service supports multiple roles, integrates with existing modules, and works great for most setups (note that multiple instances are not supported).
**Do:**
> This service does not support multiple instances.
#### Consistent Terminology
Pick a term and stick to it. Don't swap synonyms to avoid repetition. In technical documentation, repetition is clarity.
**Don't:**
> Create a machine... configure the host... deploy the node.
**Do:**
> Create a machine... configure the machine... deploy the machine.
#### Links
Use descriptive link text. Never use "click here" or "this link."
**Don't:**
> For more information, see `[this page](url)`.
> Click `[here](url)` to read the reference.
**Do:**
> See the `[NixOS options reference](url)` for details.
> Read the `[NixOS module system guide](url)`.
Only link when the destination is directly relevant, not for generic background context (sometimes known as "Wikipedia-style links"). Readers feel obligated to click links, fearing they'll miss something important. Don't send them to a generic article about a technology when they're looking for how *your* system uses it.
**Don't:**
> Our software uses [SQLite](https://sqlite.org/) for storage.
(Note that in the above example, the SQLite link is the SQLite home page, which is likely not pertinent.)
**Do:**
> See `[database schema](url)` for the full table structure.
#### UI Language
Match UI element names exactly: wording, casing, and spacing (even if a label seems oddly worded).
**Don't:**
> Click the generator button.
> Select the save option.
**Do:**
> Click **Generate a Key**.
> Click **Save Changes**.
Someone will go looking for a button labeled "generator." They will not find it. They will be frustrated.
Consistency between documentation and interface builds confidence. Words are part of the interface.
:::{.tip}
This can be tricky as UI changes; we don't yet have a policy in place for how to handle this. We welcome comments and suggestions.
:::
#### Clean system discipline
Your machine has things new users don't: cached credentials, installed tools, environment variables, existing configuration. When writing or updating documentation:
**Don't:**
> Write steps from memory on your development machine, assuming what works there will work everywhere.
**Do:**
> - Start on a clean system — a fresh VM or new user account
> - Take notes in real time as you work through the steps
> - Document every warning, prompt, or unexpected output the system shows
Also think in combinations: WSL vs native Linux, with and without existing keys. You don't need to test every matrix square — but you need to know which ones diverge.
#### Never type code — always copy-paste
Always copy commands and code from a terminal where you just ran them successfully. Never retype from memory.
**Don't:**
> Retype a command from memory into the documentation.
> Retype code into a code-block from memory
**Do:**
> Paste commands directly from the shell or IDE.
> Paste code that has been successfully validated with nix-instantiate or nix-build
Replace sensitive values with placeholders: `<YOUR-KEY>`, `<YOUR-HOST>`, `<YOUR-TOKEN>`.
Typed-from-memory commands introduce subtle errors. Even the most experienced software developers have occasional typos.
@@ -152,7 +152,7 @@ There are several ways to tweak how Nix handles a package which has been marked
Note that `allowlistedLicenses` only applies to unfree licenses unless `allowUnfree` is enabled. It is not a generic allowlist for all types of licenses. `blocklistedLicenses` applies to all licenses.
A complete list of licenses can be found in the file [`nixpkgs/lib/licenses/licenses.nix`](https://github.com/NixOS/nixpkgs/blob/master/lib/licenses/licenses.nix) of the nixpkgs tree.
A complete list of licenses can be found in the file `lib/licenses.nix` of the nixpkgs tree.
Packages receive varying degrees of support, both in terms of maintainer and security team attention and available computation resources for continuous integration (CI). We have 7 defined tiers denoting how well supported each platform is.
Packages receive varying degrees of support, both in terms of maintainer attention and available computation resources for continuous integration (CI). We have 7 defined tiers denoting how well supported each platform is.
## Tiers {#sec-platform-tiers}
### Tier 1 {#sec-platform-tier1}
[Tier 1](https://github.com/NixOS/rfcs/blob/master/rfcs/0046-platform-support-tiers.md#tier-1) platforms receive the highest level of support where problems can block updates, security fixes are treated with urgency, platform-specific patches are freely applied, and most packages are expected to work.
[Tier 1](https://github.com/NixOS/rfcs/blob/master/rfcs/0046-platform-support-tiers.md#tier-1) platforms receive the highest level of support where problems can block updates, platform-specific patches are freely applied, and most packages are expected to work.
### Tier 2 {#sec-platform-tier2}
[Tier 2](https://github.com/NixOS/rfcs/blob/master/rfcs/0046-platform-support-tiers.md#tier-2) platforms are expected to remain functional and secure with updates, receive platform-specific patches as needed, and have many packages built by Hydra with full ofBorg support.
[Tier 2](https://github.com/NixOS/rfcs/blob/master/rfcs/0046-platform-support-tiers.md#tier-2) platforms are expected to remain functional with updates, receive platform-specific patches as needed, and have many packages built by Hydra with full ofBorg support.
### Tier 3 {#sec-platform-tier3}
@@ -22,25 +22,28 @@ Platform Tiers [4 through 7](https://github.com/NixOS/rfcs/blob/master/rfcs/0046
## Breakdown {#sec-platform-breakdown}
| Triple | Support Tier | Channel Blockers | Hydra Support | Security Support | Ofborg Support | Bootstrap Tarballs | Cross Compiling Support |
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
