Upstream tracking - #165
Draft
grahamc wants to merge 4240 commits into
Draft
Conversation
…tenance [Backport 2.35-maintenance] Convert stdenv.isLinux to stdenv.hostPlatform.isLinux
This was introduced by a bad merge. Fixes #591.
Fix forwarding netrc-file to the daemon
sentry_init() spawns worker threads. When it ran before initNix() (and thus before startSignalHandlerThread() blocks SIGINT etc. in the calling thread), those threads inherited a signal mask with SIGINT unblocked, so the kernel could deliver a Ctrl-C's SIGINT to one of them. Its default disposition then killed the process immediately, without printing "error: interrupted by the user" or restoring the terminal cursor hidden by the progress bar. Initializing Sentry after initNix() makes its threads inherit the blocked mask, so SIGINT is only received by the signal handler thread via sigwait(), as intended. The SIGQUIT reset that undoes Sentry's crash handler for it moves along, since it must run after sentry_init(). Assisted-by: Claude Fable 5 <noreply@anthropic.com>
Sync with upstream 2.35-maintenance
Fix Ctrl-C handling when Sentry is enabled
The in-memory cached value was created with an empty context `{}` instead
of copying the actual context from the value. This caused string contexts
to be lost even though they were correctly written to the database.
When setAttrs "seals" an attrset (transitions from Placeholder to FullAttrs), the previous INSERT OR REPLACE would delete and recreate the row with a new rowid. This orphaned any children cached under the old rowid, causing cache misses on subsequent builds. This explains the "third time's a charm" behavior: on the 2nd build, orphaned children are re-cached under the new parent rowid. With deeper nesting, even more evaluations could be required as each level of sealing orphans the next level's children. Fix by using INSERT ... ON CONFLICT DO UPDATE (upsert) to preserve the rowid, and INSERT OR IGNORE for children to preserve existing cached values. Also delete redundant Missing entries since we now know the complete set. This requires SQLite >= 3.35 for the RETURNING clause, now declared as an explicit dependency of libexpr.
Verify that evaluation caching works on the second build by checking that builtins.trace output only appears on the first evaluation.
Eval cache: make the second evaluation hit the cache
Fixes #589. Assisted-by: Claude Fable 5 <noreply@anthropic.com>
doc: mention that flake metadata's `Path` field is absent with lazy-trees
With duplicate installables (e.g. 'nix build nixpkgs#hello nixpkgs#hello nixpkgs#hello'), Installable::build2() pushed the same DerivedPath into pathsToBuild once per installable, while also recording each installable in backmap. Since buildPathsWithResults() returns one result per request, fanning each of the n results out to all n backmap entries produced n² results — printing every output path n² times with --print-out-paths, and likewise duplicating --json entries and --out-link symlinks. Instead, record all requests in a vector in command-line order and deduplicate pathsToBuild separately, then produce results by looking up each request's build result. This yields exactly one result per installable while preserving command-line order even when duplicates are interleaved (e.g. 'nix build A B A' yields results for A, B, A rather than grouping the duplicates). Assisted-by: Claude Fable 5 <noreply@anthropic.com>
Deduplicate `nix build --print-out-paths` output
Flake lock file updates:
• Updated input 'nix':
'path:../..'
→ 'path:../..'
• Updated input 'nix/nixpkgs':
'https://api.flakehub.com/f/pinned/DeterminateSystems/secure-packages-26.05/0.1.1013487%2Brev-01649628bfcaf28024737daec63d559fe0463e6c/01a04eb4-9c90-76b3-a3fb-a92559e04618/source.tar.gz' (2026-08-29)
→ 'https://api.flakehub.com/f/pinned/DeterminateSystems/secure-packages-26.05/0.1.1013502%2Brev-88369aab48f8d2b0f69126d306c5af06e997849b/01a05deb-f862-7c32-a065-599b037b2e53/source.tar.gz' (2026-09-01)
Also drop the Nix version number down to 2.35.2 since there is no 2.35.3 yet.
…155-5448-44f2-91c4-896668aef46a Release v3.22.3
The crashpad handler writes a crash's minidump by ptrace-attaching to the crashing process. With kernel.yama.ptrace_scope >= 2 ptrace is reserved for CAP_SYS_PTRACE, which an unprivileged test run does not have (PR_SET_PTRACER only helps at scope 1), so no dump can ever be captured and every crash type fails with 'No crash dump found'. Skip the test on such kernels, matching the existing per-platform skips. Observed as a deterministic nix-functional-tests:sentry failure when building determinate-nix inside an unprivileged CI sandbox on a hardened host (Talos Linux, ptrace_scope=2), while the same derivation builds clean on a workstation with ptrace_scope=1.
…der-yama tests/functional: skip the sentry test when Yama restricts ptrace
Tested against the interface from libgit2/libgit2#7337. Also adds a configuration for clang-tidy to disable formatting on just a single line, because if doesn't really format nicely with arguments which need a comma in an ifdef. Co-authored-by: John Ericson <git@JohnEricson.me> (cherry picked from commit 08fdb6e)
See the comment for reasoning. Re-validiating all objects we read is probably out of scope for nix, just to catch occasional odb corruption. (cherry picked from commit d690cbf)
…ache This is by far the most expensive part of unpacking now: 49.35% nix libgit2.so.2.0.0 [.] git_delta_create_from_index 8.56% nix libgit2.so.2.0.0 [.] sha1_compression_states 5.89% nix libz.so.1.3.2 [.] longest_match 5.24% nix libz.so.1.3.2 [.] inflate_fast 4.80% nix libz.so.1.3.2 [.] deflate_slow 4.44% nix libgit2.so.2.0.0 [.] ubc_check 1.78% nix libz.so.1.3.2 [.] pqdownheap.constprop.0 1.53% nix libz.so.1.3.2 [.] compress_block 1.27% nix libgit2.so.2.0.0 [.] git_delta_index_init (cherry picked from commit 52bff94)
(cherry picked from commit 36bdf2a)
Flake lock file updates:
• Updated input 'nix/nixpkgs':
'https://api.flakehub.com/f/pinned/DeterminateSystems/secure-packages-26.05/0.1.1013502%2Brev-88369aab48f8d2b0f69126d306c5af06e997849b/01a05deb-f862-7c32-a065-599b037b2e53/source.tar.gz' (2026-09-01)
→ 'https://api.flakehub.com/f/pinned/DeterminateSystems/secure-packages-26.05/0.1.1013551%2Brev-07b3c48788b0deb9ee48c40ed5ff1dff7f4643e7/01a08dbc-1a6d-7e60-8dd0-bc2bf8ecb4fb/source.tar.gz' (2026-09-10)
Nixpkgs derives libgit2's `meta.changelog` from `src.tag`, which is null for our override since we fetch an untagged 2.0.0-rc.1 commit. This was harmless with upstream nixpkgs, but nixpkgs variants with provenance support (`derivationWithMeta`) force `meta.changelog` at instantiation time, causing error: cannot coerce null to a string: null when evaluating packaging/secure-packages. Assisted-by: Claude Fable 5.1 <noreply@anthropic.com>
Tarball cache performance improvements
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Not intended to be merged directly. This PR is a convenience to show the diff between upstream Nix and Determinate Nix (the
mainbranch).Continuation of #4.