| 13 Feb 2025 |
emily | * /var is a symlink to /private/var. hmm, there was a recent bug with Nix pure/--impure evaluation and symlinks, I think | 16:56:26 |
emily | https://github.com/NixOS/nix/issues/12449 | 16:56:28 |
emily | probably not this I guess | 16:56:35 |
emily | (also /tmp → /private/tmp, /etc → /private/etc) | 16:56:53 |
adamcstephens | someone on discord reported:
I can replicate this locally on my mac by building the package with --option restrict-eval true, but I'm lost for what is going on.
| 16:57:02 |
emily | is it every single build or just some of them? | 16:59:21 |
adamcstephens | my spot checking earlier it was affecting all | 16:59:41 |
adamcstephens | e.g. here's a curl job https://github.com/NixOS/nixpkgs/pull/381673/checks?check_run_id=37148473245 | 17:00:02 |
emily | what changed? :) | 17:00:07 |
emily | Nix upgrade? OS upgrade? | 17:00:11 |
adamcstephens | 🤷♂️ | 17:00:19 |
adamcstephens | on the positive side, maybe we've caught the queue up? :) | 17:00:40 |
Lily Foster | (i mean something is trying to read /private during eval (readDir fuckery?) but not clear if anything changed in nixpkgs or in cppnix or in ofborg builder config for macs) | 17:12:43 |
emily | my guess is that the checkout is in /var/lib/nixpkgs or something. | 17:13:11 |
emily | and then the second part of my guess is Nix was upgraded and caught some version of this bug | 17:13:27 |
emily | but just a guess. | 17:13:32 |
Lily Foster | i mean that issue is that it stopped resolving symlinks on import, so wouldn't that make it less likely to trigger a bug like this?
also iirc (unless something's changed on the cppnix side), if it only says /private is forbidden in the error, then that was the full path that was attempted to be accessed (but /private could be a path after symlink resolution and if it's a line in nixpkgs then e.g. the actual import/readFile/etc call causing it may be to a symlink -- but cppnix bugs does smell likely given i can't come up with a reasonable scenario that /private would ever attempt to be imported/read)
| 17:21:27 |
emily | seems like figuring out what changes were made to ofborg's deployment between it working and breaking is the step 1 really | 17:22:05 |
Lily Foster | (update: i guess this isn't true at least for recent cppnix -- it does actually just show first path segment in certain scenarios) | 17:27:50 |
adamcstephens | a user's tmpdir is also in /private on mac | 17:28:23 |
adamcstephens | ➜ readlink -f $TMPDIR
/private/var/folders/y7/n0y6ndf91tn7q95rs70q2_9c0000gn/T
| 17:28:56 |
Lily Foster | (i doubt that's relevant for determining cause) | 17:39:19 |
Lily Foster | replicate via what command? | 17:39:31 |
Lily Foster | never mind, found the issue | 17:44:33 |
Lily Foster | (and yeah can also confirm the cppnix error message being misleading is a >2.18 regression) | 17:45:43 |
Lily Foster | this doesn't work on macOS because /var is a symlink: https://github.com/ofborg/ofborg-infrastructure/blob/13030f577a3d110d68edfc9416382c81a09fba46/non-critical-infra/modules/ofborg/ofborg-config.nix#L78 | 17:46:14 |
Lily Foster | tracing through the call points in the ofborg code | 17:46:27 |
Lily Foster | basically it sets ofborg-nixpkgs-pr=/var/lib/ofborg/checkout/... but when it cd's to /var/lib/ofborg/checkout/... and attempts to eval ./default.nix, cppnix sees it as as /private/var/lib/ofborg/checkout/.../default.nix, which causes evaluator to throw error since only /var/lib/ofborg/checkout is in NIX_PATH | 17:48:42 |
Lily Foster | yeah looks like cppnix does absPath on the file/dir to evaulate before sending it to evaluator: https://github.com/NixOS/nix/blob/693a38ae2e6d6bcbe39ec1d4034821d6f90cf9f5/src/nix-build/nix-build.cc#L355 | 17:54:31 |
Lily Foster | easiest "fix" to make it not explode in the case where it's configured to use a checkout dir that has a symlink in a path segment is probably to add a .canonicalize() to https://github.com/NixOS/ofborg/blob/cbf0c619db7750de1e7b575ade14d0ef35a1bde3/ofborg/src/checkout.rs#L17 | 17:57:19 |