<clever>
-rw-r--r-- 1 cachecache nogroup 125051132 Nov 13 21:01 0aw447l5f2zwf9lx23mq0vcaxmwscjah1l1hg277s6avmnjqqpln.nar.xz
<clever>
definitely seems like the remote end is giving up
<clever>
oh, maybe nix is downloading it too slowly...., wget is too fast to reproduce
<clever>
yep, not a nix problem, `wget --rate-limit=500k` reproduces the issue (also, wget doesnt notice it was a partial dl!)
orivej has joined #nixos-dev
<aminechikhaoui>
samueldr is it possible to cherry-pick https://github.com/NixOS/nixpkgs/pull/50338 once it's merged ? not sure what's the rule to cherry-pick updates, only security updates?
<samueldr>
(also good to know, editing a comment with a command will re-launch that command)
tomberek has joined #nixos-dev
<samueldr>
ekleog: I see you near the words "refactor" and splitting stuff in the git log for <nixos/tests>... looks like they don't work in restricted eval
<tomberek>
hey, i've been noticing something with nix-shell, very many child processes. `strace -e read,open,clone -f -tt nix-shell -p bash --run "exit"`
<clever>
tomberek: but very few execve's
<samueldr>
(continuing in #50233 which introduced the breaking changes, will be easier keep track of since I'm about to go)
<tomberek>
clever: thanks, still seems like a lot of child processes, i haven't been able to track this down. But I'd like to see nix-shell getting closer to "bash -c" in term of human-perceivable delay to allow me to use it for arbitrary scripts, at the moment it lags a bit too much
<tomberek>
`strace -e signals=none -e write,read,open -f -tt nix-shell -p bash --run "exit" 2>&1 | grep attached | wc -l` shows 514 while the equivalent with "bash -i -c" is only 162, not sure if this is what causes the delay, but it might be a start
<{^_^}>
#50186 (by dingxiangfei2009, 3 days ago, merged): Allow cloud-init to support creating btrfs partitions
<ekleog>
I don't really get how it fails on one and doesn't on the other
<ekleog>
ie. building nixos/test/env.nix doesn't fail but release.nix -A tests.env does, in restricted mode, while from my reading the imported nixpkgs should be the same :/
<samueldr>
smells like IFD
<ekleog>
yeah, but I don't get from where it arises :/
<ekleog>
like, it appears to pull in nixpkgs in the store… but at the same time it already did before, with the implicit argument to `nixos/tests/env.nix` that was defined in `make-test.nix`
<ekleog>
and it also appears not to fail on hydra, if I look at the most recent evals, which is maybe the weirdest part of all (otherwise it'd already have been backed out I think)
<samueldr>
I didn't find my way to a test on hydra to confirm or deny :/
<ekleog>
… oh wait. does hydra report eval failures?
<ekleog>
actually tab-constituents -> 83951686 -> click on the commit IDs for nixpkgs -> all commits from nov 11
<ekleog>
so I guess either we understand a way to fix this really soon(tm) or we just back the PR out and try again once it's figured out :D
<ekleog>
(third time lucky, as the saying goes)
<ekleog>
I… what? with `discoverTests = val: mapAttrs (n: s: {}) val;`, if I have `handleTest = path: args: discoverTests {};` then the restrict-eval build fails, but if I have `handleTest = path: args: {};`, then the restrict-eval build no longer does (well, it doesn't find the test as expected, but it's not the restrict-eval error)
<ekleog>
that kind of smells like a nix bug, though it'd be weird :/ (and I have to go for the time being, will be back soon trying to get to the bottom of it, feel free to backout if you think there won't be an easy uncontroversial fix soon enough so that hydra flows again)
orivej has quit [Ping timeout: 268 seconds]
<ekleog>
nvm @ nix bug : it was actually just that mapAttrs is pulled from `pkgs`, and forcing `pkgs` appears to be what triggers the issue
* ekleog
wonders whether it's time to laugh
<ekleog>
the `nixpkgs` argument to `release.nix` defaults to `cleanSource ./..`
<ekleog>
which… I guess, is IFD
<ekleog>
and given our tests never actually used it, we never noticed
<ekleog>
roberth: the problem appears to come from 209f8b1acd4c
<ekleog>
… is there an eval-time way to know whether we're currently evaluating in restrict-mode?
* ekleog
can't find better than builtins.pathExists "/"
jtojnar has joined #nixos-dev
<clever>
ekleog: getEnv will always return an empty string if your in restricted mode
<clever>
ekleog: so you could maybe try:
<clever>
> (builtins.getEnv "HOME") == ""
<{^_^}>
true
<clever>
note, the bot is also in restricted mode, to prevent abuse
<clever>
and if any user has $HOME unset, its their own fault, and all software should be failing hard :P
<{^_^}>
#49742 (by FRidh, 1 week ago, open): Staging next
<qyliss^work>
Staging isn't directly merged to master - staging-next is branched off staging, every so often, then it's fixed up until it's considered okay for master.
<asymmetric>
yeah, i was asking cause the RFC seems to give an estimate
pie_ has joined #nixos-dev
<infinisil>
I'll just go ahead and merge #50183 myself, I doubt anybody has anything against it
<{^_^}>
#50270 (by hlolli, 2 days ago, merged): use newer clj2nix which passes pkgs as an argument to deps.nix
<infinisil>
Assuming this is the cause, this has been fixed, and evaluating again should get rid of the error
hedning has quit [Ping timeout: 272 seconds]
<colemickens>
I see. I was thinking of places where there are import = [ <nixpkgs...> ], but I'm realizing now that that might just be something the installer does (or whatever spits out the hardware config)
<colemickens>
I guess this file winds up in /etc/nixos though and can't make assumptions about the relative path to nixpkgs. I guess <nixpkgs> is basically required there
<colemickens>
anyway, thanks for the link clever, somehow I'd assumed there was more magic to it all.
<samueldr>
#50342 was opened to (hopefully) fix that