Merged
Conversation
Without the change the build fails for me as:
../unix/file-descriptor.cc:404:70: error: 'RESOLVE_BENEATH' was not declared in this scope
404 | dirFd, path.rel_c_str(), flags, static_cast<uint64_t>(mode), RESOLVE_BENEATH | RESOLVE_NO_SYMLINKS);
| ^~~~~~~~~~~~~~~
This happens for 2 reasons:
1. `__NR_openat2` constant was not pulled in from the according headers
and as a result `<linux/openat2.h>` was not included.
2. `define HAVE_OPENAT2 0` build is broken: refers to missing
`RESOLVE_BENEATH` normally pulled in from `<linux/openat2.h>`
This changes fixes both.
(cherry picked from commit 3256aba)
…tenance [Backport 2.33-maintenance] libutil: fix `linux` build on fresh `glibc` and `gcc`
(cherry picked from commit 1555677)
…tenance [Backport 2.33-maintenance] ci: Bump magic-nix-cache to disable on 429
…requests Some S3-compatible services (like GCS) modify the Accept-Encoding header in transit, which breaks AWS SigV4 signature verification since curl's implementation signs all headers including Accept-Encoding. Fixes: NixOS#15019 (cherry picked from commit fcfa1dc)
…33-maintenance [Backport 2.33-maintenance] fix(libstore/filetransfer): skip Accept-Encoding header for S3 SigV4 requests
When an upload fails with a transient HTTP error (e.g., S3 rate limiting with HTTP 503), retries would fail with "curl error: Failed to open/read local data from file/application" because the upload source was already exhausted from the previous attempt. Restart the source in init() to ensure it's at the beginning for both first attempts (no-op) and retries (necessary fix). Fixes: NixOS#15023 (cherry picked from commit fbd787b)
…tenance [Backport 2.33-maintenance] fix(libstore/filetransfer): restart source before upload retries
We are now seeing. I guess we are out with the cache. When the API responds with 418 (I'm a teapot) it seems like the only reasonable solution is to oblige. error: unable to download 'http://127.0.0.1:37515/7ms9f25xyxavf32pvdc3vb28nzzmkbn3.narinfo': HTTP error 418 response body: GitHub API error: GitHub Actions Cache throttled Magic Nix Cache. Not trying to use it again on this run. (cherry picked from commit dae41e0)
…tenance [Backport 2.33-maintenance] ci: Drop magic-nix-cache
Add helpers to the base Goal class that set buildResult and call amDone, ensuring buildResult is always populated when a goal terminates. Derived class helpers now call the base class versions. This reorders operations: previously buildResult was set before bookkeeping (counter resets, worker stats), now it's set after. This is safe because the bookkeeping code (mcExpectedBuilds.reset(), worker.doneBuilds++, worker.updateProgress(), etc.) only accesses worker counters, not buildResult. (cherry picked from commit cb2ade2)
DerivationTrampolineGoal is the top-level goal whose buildResult is returned by buildPathsWithResults. When it failed without setting buildResult.inner, buildPathsWithResults would return failures with empty errorMsg, producing error messages like: error: failed to build attribute 'checks.x86_64-linux.foo', build of '/nix/store/...drv^*' failed: (note the empty message after "failed:") Use the new doneFailure helper to ensure buildResult is populated with meaningful error information. (cherry picked from commit 25eb07a)
When keepGoing=false and a build fails, other goals are cancelled. Previously, these cancelled goals were reported in the "build of ... failed" error message alongside actual failures. This was misleading since cancelled goals didn't actually fail - they were never tried. Update the test to expect only the actual failure (hash mismatch) to be reported, not the cancelled goals. (cherry picked from commit 3fd85c7)
When !keepGoing and a goal fails, other goals are cancelled and
remain with exitCode == ecBusy. These cancelled goals have a default
BuildResult::Failure{} with empty errorMsg.
Previously, buildPathsWithResults would return these cancelled goals,
and throwBuildErrors would report them as failures. When only one such
cancelled goal was present, it would throw an error with an empty
message like:
error: build of '/nix/store/...drv^*' failed:
Now we skip goals with ecBusy since their state is indeterminate.
Cancelled goals could be reported, but this keeps the output relevant.
Other indeterminate goal states were already not being reported, for
instance: derivations that weren't started for being blocked on a
concurrency limit, or blocked on a currently building dependency.
(cherry picked from commit 68f549d)
Change "cannot build missing derivation" to "failed to obtain derivation of" since the path (e.g. '...drv^out') is a derivation output, not a derivation. The message could be improved further to resolve ambiguity when multiple outputOf links are involved, but for now we err on the side of brevity since this message is already merged into larger error messages with other context from the Worker and CLI. (cherry picked from commit 3c3ceb1)
…tenance [Backport 2.33-maintenance] Fix concurrent builder failure empty message bugs
Don't add the whole store to sandbox-paths unconditionally. Exposing the entire store defeats the purpose of sandboxing, and when the test store is the same as the system store (NixOS VM), it causes an obscure "Permission denied" error. Only add sandbox-paths when not on NixOS, indicating a separate test store that needs access to system store build tools. (cherry picked from commit 7b4444f)
…tenance [Backport 2.33-maintenance] tests: fix sandbox-paths in cancelled-builds test
This unsures that we call the correct virtual functions when destroying a particular
DerivationBuilder.
Usually the order of destructors is in the reverse order of inheritance:
ChrootLinuxDerivationBuilder -> ChrootDerivationBuilder -> DerivationBuilderImpl
autoDelChroot was being destroyed before the DerivationBuilderImpl::killChild was
run and it would fail to clean up the chroot directory, since there were still processes
writing to it. Note that ChrootLinuxDerivationBuilder::killSandbox was never run in
the interrupted case at all, since virtual functions in destructors do not call derived class
methods.
I could reproduce the issue with the following derivation:
let
pkgs = import <nixpkgs> { };
in
pkgs.runCommand "chroot-cleanup-race" { } ''
mkdir -p $out
for i in $(seq 1 200); do
(
mkfifo $out/fifo$i
cat $out/fifo$i > /dev/null &
while true; do
: > $out/file$i
done
) &
done
sleep 0.05
echo done > $out/main
''
While interrupting it manually when it would hang.
Wrapping the unique pointer in a custom deleter function we can run all
of the necessary clean up code consistently and calling the right virtual
functions. Ideally we'd have a lint that bans the usage of virtual functions
in destructors completely.
(cherry picked from commit b752c5c)
…aintenance [Backport 2.33-maintenance] Fix destruction of DerivationBuilder implementations
This enables seamless AWS SSO authentication for S3 binary caches without requiring users to manually export credentials. This adds SSO support by calling aws_credentials_provider_new_sso() from the C library directly. It builds a custom credential chain: Env → SSO → Profile → IMDS The SSO provider requires a TLS context for HTTPS connections to SSO endpoints, which is created once and shared across all providers. (cherry picked from commit ec91479)
Add validation for TLS context and client bootstrap initialization, with appropriate error messages when these fail. The TLS context failure is now a warning that gracefully disables SSO, while bootstrap failure throws since it's required for all providers. (cherry picked from commit 3c8e45c)
The default (empty) profile case was using CreateCredentialsProviderChainDefault which didn't properly support role_arn/source_profile based role assumption via STS because TLS context wasn't being passed to the Profile provider. This change unifies the credential chain for all profiles (default and named), ensuring: - Consistent behavior between default and named profiles - Proper TLS context is passed for STS operations - SSO support works for both cases (cherry picked from commit 508d446)
(cherry picked from commit 128b2b5)
(cherry picked from commit 11f108d)
(cherry picked from commit 0595c5f)
(cherry picked from commit 71bdb33)
The SSO provider was unconditionally setting profile_name_override to the (potentially empty) profile string from the S3 URL. When profile was empty, this prevented the AWS CRT SDK from falling back to the AWS_PROFILE environment variable. Only set profile_name_override when a profile is explicitly specified in the URL, allowing the SDK's built-in AWS_PROFILE handling to work. (cherry picked from commit 453dbab)
…tenance [Backport 2.33-maintenance] feat(libstore): add AWS SSO support for S3 authentication
Previously AWS CRT logs went directly to stderr via ApiHandle::InitializeLogging, causing log spam that didn't respect Nix's verbosity settings. This implements a custom aws_logger using the aws-c-common C API that: - Routes all AWS logs through nix::logger - Maps AWS log levels conservatively (ERROR/WARN -> lvlInfo) since the SDK treats expected conditions like missing IMDS as errors - Prefixes messages with (aws) for clarity - Respects Nix's verbosity flags (-v, -vv, etc.) (cherry picked from commit 3b8b764)
As requested in review. (cherry picked from commit e3b788b)
…tenance [Backport 2.33-maintenance] feat(libstore/aws-creds): route AWS CRT logs through Nix logger
Tagging release 2.33.2
This reverts commit 09884e2. It breaks `buildPathsWithResults` returning cancelled builds, which is needed by `nix flake check` and `nix build` to report cancelled builds.
📝 WalkthroughWalkthroughThis PR introduces AWS credential provider chain integration with SSO and logging, refactors build goal completion paths to use structured success/failure handlers, establishes custom DerivationBuilder lifecycle management via a custom deleter, and extends AWS credential testing with profile-based authentication scenarios. Changes
Sequence DiagramsequenceDiagram
participant Goal as Build Goal
participant AwsCreds as AWS Credential Provider
participant Env as Environment Provider
participant SSO as SSO Provider
participant Profile as Profile Provider
participant IMDS as IMDS Provider
participant Logger as Nix Logger
Goal->>AwsCreds: Initialize credential chain
AwsCreds->>Logger: Initialize custom AWS logger
Logger-->>AwsCreds: Logger ready
AwsCreds->>Env: Try environment credentials
alt Environment vars set
Env-->>AwsCreds: Success with env creds
else No environment vars
Env-->>AwsCreds: Not available
AwsCreds->>SSO: Try SSO provider (if TLS context exists)
alt SSO configured
SSO-->>AwsCreds: SSO credentials obtained
else No SSO
SSO-->>AwsCreds: Not available
AwsCreds->>Profile: Try profile credentials
alt Profile found
Profile-->>AwsCreds: Profile credentials obtained
else No profile
Profile-->>AwsCreds: Not available
AwsCreds->>IMDS: Fall back to EC2 IMDS
IMDS-->>AwsCreds: IMDS credentials obtained
end
end
end
AwsCreds-->>Goal: Credential chain ready
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@src/libstore/meson.build`:
- Around line 170-171: The meson.build looks up aws-c-common and aws-c-auth when
s3-aws-auth is enabled but package.nix does not add them to buildInputs; update
src/libstore/package.nix to conditionally (when withAWS is true) include both
aws-c-common and aws-c-auth alongside the existing aws-crt-cpp dependency in the
buildInputs list so meson can find the libraries during configure/build.
In `@tests/functional/build.sh`:
- Around line 160-168: The test assumes x1 is the first failing goal; instead
make the assertion order-independent by checking for exactly one hash-mismatch
among the sibling goals x1/x2/x3: after capturing out/status (variable out and
status), replace the hardcoded checks that assert presence for x1 and exclude
x2/x3 with a single count/grepQuiet that matches "hash mismatch in fixed-output
derivation '.*-x[123]\\.drv'" and asserts that count equals 1 (or use grepQuiet
to ensure one match), keeping other checks (e.g., for x4) intact; update usages
of grepQuiet and the test on "$out" accordingly.
Comment on lines
+170
to
+171
| aws_c_auth = cxx.find_library('aws-c-auth', required : true) | ||
| deps_other += aws_c_auth |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
rg -n "aws-crt-cpp|aws-c-common|aws-c-auth"Repository: DeterminateSystems/nix-src
Length of output: 1193
🏁 Script executed:
sed -n '160,180p' src/libstore/meson.buildRepository: DeterminateSystems/nix-src
Length of output: 695
🏁 Script executed:
sed -n '1,90p' src/libstore/package.nix | grep -A5 -B5 "aws\|AWS"Repository: DeterminateSystems/nix-src
Length of output: 979
🏁 Script executed:
grep -n "aws-c-common\|aws-c-auth" src/libstore/package.nixRepository: DeterminateSystems/nix-src
Length of output: 52
🏁 Script executed:
cat -n src/libstore/package.nix | head -80Repository: DeterminateSystems/nix-src
Length of output: 2403
🏁 Script executed:
grep -rn "aws-c-common\|aws-c-auth" --include="*.nix" src/Repository: DeterminateSystems/nix-src
Length of output: 52
Add aws-c-common and aws-c-auth to buildInputs.
The meson.build file looks up aws-c-common and aws-c-auth when s3-aws-auth is enabled, but neither library is declared in src/libstore/package.nix. This will cause build failures. Both libraries must be added to the buildInputs in package.nix alongside the existing aws-crt-cpp dependency, conditional on withAWS.
🤖 Prompt for AI Agents
In `@src/libstore/meson.build` around lines 170 - 171, The meson.build looks up
aws-c-common and aws-c-auth when s3-aws-auth is enabled but package.nix does not
add them to buildInputs; update src/libstore/package.nix to conditionally (when
withAWS is true) include both aws-c-common and aws-c-auth alongside the existing
aws-crt-cpp dependency in the buildInputs list so meson can find the libraries
during configure/build.
Comment on lines
160
to
+168
| # --keep-going and FOD | ||
| out="$(nix build -f fod-failing.nix -L 2>&1)" && status=0 || status=$? | ||
| out="$(nix build -f fod-failing.nix -j1 -L 2>&1)" && status=0 || status=$? | ||
| test "$status" = 1 | ||
| # one "hash mismatch" error, one cancelled build | ||
| # Only the hash mismatch error for the first failing goal (x1). | ||
| # The other goals (x2, x3, x4) are cancelled and not reported as failures. | ||
| test "$(<<<"$out" grep -cE '^error:')" = 1 | ||
| test "$(<<<"$out" grep -cE '(cancelled)')" = 3 | ||
| <<<"$out" grepQuiet -E "hash mismatch in fixed-output derivation" | ||
| <<<"$out" grepQuiet -E "hash mismatch in fixed-output derivation '.*-x1\\.drv'" | ||
| <<<"$out" grepQuiet -vE "hash mismatch in fixed-output derivation '.*-x3\\.drv'" | ||
| <<<"$out" grepQuiet -vE "hash mismatch in fixed-output derivation '.*-x2\\.drv'" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's examine the test file around the mentioned lines
cd tests/functional
cat -n build.sh | sed -n '150,180p'Repository: DeterminateSystems/nix-src
Length of output: 1817
🏁 Script executed:
# Find and examine the fod-failing.nix file referenced in the test
find . -name "fod-failing.nix" -type fRepository: DeterminateSystems/nix-src
Length of output: 104
🏁 Script executed:
# Check if there are any ordering dependencies between x1, x2, x3 in the test setup
rg -A 5 -B 5 "fod-failing\.nix" tests/functional/build.shRepository: DeterminateSystems/nix-src
Length of output: 2124
🏁 Script executed:
# Examine the fod-failing.nix to understand the dependencies
cat -n tests/functional/fod-failing.nixRepository: DeterminateSystems/nix-src
Length of output: 1181
🏁 Script executed:
# Also check if there are any recent changes or comments about this test's purpose
git log --oneline -20 -- tests/functional/build.sh | head -10Repository: DeterminateSystems/nix-src
Length of output: 152
🏁 Script executed:
# Search for any documentation or comments about -j1 behavior in Nix
rg -i "keep-going.*-j1" --type shRepository: DeterminateSystems/nix-src
Length of output: 52
🏁 Script executed:
# Check the full context of the x4 test to understand when ordering is uncertain
cat -n tests/functional/build.sh | sed -n '178,195p'Repository: DeterminateSystems/nix-src
Length of output: 1064
🏁 Script executed:
# Look for any Nix documentation or code about attribute evaluation order
rg -i "evaluation order" --type nixRepository: DeterminateSystems/nix-src
Length of output: 52
🏁 Script executed:
# Check if there are any recent issues or discussions about this test
git log -p --all -S "fod-failing" -- tests/functional/build.sh | head -100Repository: DeterminateSystems/nix-src
Length of output: 52
🏁 Script executed:
# Verify if -j1 implies any ordering guarantees for independent derivations
rg -B 3 -A 3 "Either x2 or x3 could have failed" tests/functional/build.shRepository: DeterminateSystems/nix-src
Length of output: 413
🏁 Script executed:
# Check if there's documentation about attribute evaluation order in Nix
rg -i "attribute.*order|evaluation.*order" doc/ --type md | head -20Repository: DeterminateSystems/nix-src
Length of output: 1008
🏁 Script executed:
# Check the commit that introduced this test to understand the intention
git log --all --oneline -- tests/functional/build.sh | grep -i "fod\|keep-going" | head -5Repository: DeterminateSystems/nix-src
Length of output: 131
🏁 Script executed:
# Look at the specific commit that changed lines 160-168
git log -p --all -- tests/functional/build.sh | grep -B 10 -A 10 "keep-going and FOD" | head -50Repository: DeterminateSystems/nix-src
Length of output: 52
🏁 Script executed:
# Check the specific commit that introduced this test
git show 19720d733 -- tests/functional/build.sh | head -150Repository: DeterminateSystems/nix-src
Length of output: 3656
🏁 Script executed:
# Also check if there's any issue or PR discussion about this
git log --all --grep="fod" --oneline | head -10Repository: DeterminateSystems/nix-src
Length of output: 447
🏁 Script executed:
# Check what changed between the original test and current version
git log --oneline -p -- tests/functional/build.sh | grep -B 5 -A 15 "keep-going and FOD" | tail -60Repository: DeterminateSystems/nix-src
Length of output: 1245
🏁 Script executed:
# Check the revert commit to understand what changed
git show 5f96c8a65 -- tests/functional/build.sh | head -100Repository: DeterminateSystems/nix-src
Length of output: 3449
🏁 Script executed:
# Check if the current behavior shows x1 actually fails first, or if that varies
# Let's look at the comment more carefully - what does "cancelled and not reported as failures" mean?
git show 5f96c8a65 | grep -B 5 -A 20 "cancelled"Repository: DeterminateSystems/nix-src
Length of output: 9523
🏁 Script executed:
# Check the exact semantics: when -j1 is used with independent goals, which one gets scheduled first?
# Look for any scheduler comments in the codebase
rg -i "schedule.*job|goal.*order|evaluation.*order" src/libstore --type cc -A 2 | head -40Repository: DeterminateSystems/nix-src
Length of output: 96
🏁 Script executed:
# Let's understand better: with attributes x1, x2, x3, x4 in fod-failing.nix,
# when nix evaluates them, are they evaluated in definition order?
# Check if there's any definition-order guarantees in the Nix manual
rg -i "attribute.*order|definition.*order" doc/manual --type md | head -20Repository: DeterminateSystems/nix-src
Length of output: 834
🏁 Script executed:
# Check if there's any recent test failures or issues with this specific test
git log --all --oneline --grep="build.sh\|fod-failing" | head -10Repository: DeterminateSystems/nix-src
Length of output: 718
🏁 Script executed:
# Let's verify: in the current code, when building with -j1 and no explicit targets,
# does Nix evaluate all top-level attributes? And in what order?
rg -i "topgoal\|top.*goal" src/libstore/build --type cc | head -20Repository: DeterminateSystems/nix-src
Length of output: 96
🏁 Script executed:
# Check if there's any specification about which attribute is evaluated first
# when nix build is called without explicit targets on a set
rg -i "evaluate.*attribute\|attribute.*first" doc/manual --type md | head -10Repository: DeterminateSystems/nix-src
Length of output: 52
🏁 Script executed:
# Let's check what happens when we call nix build -f fod-failing.nix without targets
# Does it build all top-level attributes or just some?
cat -n tests/functional/build.sh | sed -n '160,177p'Repository: DeterminateSystems/nix-src
Length of output: 1187
🏁 Script executed:
# Let's check if there's any documentation about which attribute gets evaluated first
# when nix build is called on a set without explicit targets
cat tests/functional/fod-failing.nixRepository: DeterminateSystems/nix-src
Length of output: 936
🏁 Script executed:
# Check the original behavior before the revert - what did the test expect?
git show 19720d733:tests/functional/build.sh | grep -A 20 "keep-going and FOD"Repository: DeterminateSystems/nix-src
Length of output: 1376
Harden the test to avoid relying on evaluation order of independent derivations.
Lines 166-168 hardcode x1 as the first failure and exclude x2/x3. Since x1, x2, x3 are independent siblings with no dependencies enforcing their execution order, the test assumes a specific scheduling order that may not be guaranteed across Nix versions. The test at lines 190-191 already acknowledges this by using order-independent assertions for x2/x3.
Replace the hardcoded checks with an order-independent assertion:
Suggested fix
test "$(<<<"$out" grep -cE '^error:')" = 1
-<<<"$out" grepQuiet -E "hash mismatch in fixed-output derivation '.*-x1\\.drv'"
-<<<"$out" grepQuiet -vE "hash mismatch in fixed-output derivation '.*-x3\\.drv'"
-<<<"$out" grepQuiet -vE "hash mismatch in fixed-output derivation '.*-x2\\.drv'"
+# Exactly one FOD hash-mismatch should be reported; which derivation fails first is not guaranteed.
+test "$(<<<"$out" grep -cE "hash mismatch in fixed-output derivation")" = 1🤖 Prompt for AI Agents
In `@tests/functional/build.sh` around lines 160 - 168, The test assumes x1 is the
first failing goal; instead make the assertion order-independent by checking for
exactly one hash-mismatch among the sibling goals x1/x2/x3: after capturing
out/status (variable out and status), replace the hardcoded checks that assert
presence for x1 and exclude x2/x3 with a single count/grepQuiet that matches
"hash mismatch in fixed-output derivation '.*-x[123]\\.drv'" and asserts that
count equals 1 (or use grepQuiet to ensure one match), keeping other checks
(e.g., for x4) intact; update usages of grepQuiet and the test on "$out"
accordingly.
cole-h
approved these changes
Feb 3, 2026
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
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
Context
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Chores