| 28 Oct 2024 |
 Artturin | How about nix build --impure --expr '(import <nixpkgs> {}).runCommand "hi" {} "bash -c \"ulimit -a\"" | 00:09:32 |
| Artturin | * How about nix build --impure --expr '(import <nixpkgs> {}).runCommand "hi" {} "bash -c \"ulimit -a\""' | 00:09:55 |
 emily | same result. | 00:10:36 |
| emily | oh. | 00:10:48 |
| emily | I think I know what's going on. | 00:10:52 |
| emily | reno doesn't use nix-darwin, and maybe the Nix installation is old? | 00:10:59 |
| emily | no, wait, that doesn't explain it, since it used to be 4096 still. | 00:11:21 |
| Artturin | What if in one of the places that require the ulimit to be set you set it to the linux number instead of 4096 | 00:11:29 |
| emily | to check if too-high values are getting capped, or? | 00:12:44 |
| Artturin | If setting it above the limit is interpreted as 1 or something | 00:13:21 |
| Artturin | well it shouldn't be 1 because then all builds would fail | 00:13:43 |
| Artturin | hmm | 00:13:46 |
| Artturin | How does ulimit for you show the number above the limit | 00:14:10 |
 @paparodeo:matrix.org | nb -E '(import <nixpkgs>{}).runCommand "foo" {} "ulimit -n"'
this derivation will be built:
/nix/store/15zc62jpxd2sszpaidzcsfxs4clpf4jc-foo.drv
building '/nix/store/15zc62jpxd2sszpaidzcsfxs4clpf4jc-foo.drv'...
1048576
| 00:14:28 |
| emily | In reply to @artturin:matrix.org
How does ulimit for you show the number above the limit so ulimit -n 122881 actually works on macOS 15, I guess it changed since 10.12. and it's reported as 122881. but presumably capped as reno described seeing | 00:15:14 |
| emily | In reply to @paparodeo:matrix.org
nb -E '(import <nixpkgs>{}).runCommand "foo" {} "ulimit -n"'
this derivation will be built:
/nix/store/15zc62jpxd2sszpaidzcsfxs4clpf4jc-foo.drv
building '/nix/store/15zc62jpxd2sszpaidzcsfxs4clpf4jc-foo.drv'...
1048576
I take it you didn't observe black going from failing to reliably passing with your PR, right? I'm wondering if actually the problem is just that Hydra has a messed up setup. | 00:15:56 |
| Artturin | I didn't really look in to it or monitor it | 00:16:27 |
| @paparodeo:matrix.org | In reply to @emilazy:matrix.org
I take it you didn't observe black going from failing to reliably passing with your PR, right? I'm wondering if actually the problem is just that Hydra has a messed up setup. it never failed for me. | 00:16:31 |
| @paparodeo:matrix.org | In reply to @emilazy:matrix.org
I take it you didn't observe black going from failing to reliably passing with your PR, right? I'm wondering if actually the problem is just that Hydra has a messed up setup. * it never failed for me locally | 00:16:43 |
| @paparodeo:matrix.org | I had also assumed that the limit was 256 | 00:16:56 |
|  @janne.hess:helsinki-systems.de left the room. | 00:20:05 |
| emily | the good news is that the Go compiler derivation runs ulimit -a. | 00:20:06 |
| emily | https://hydra.nixos.org/build/274250874/nixlog/1 | 00:20:08 |
| emily | https://hydra.nixos.org/build/274236521/nixlog/1 | 00:20:12 |
| emily | it's a Hydra problem. | 00:20:14 |
| emily | we could fix it in stdenv still, but it seems like the wrong place if actually the daemon stuff works | 00:20:55 |
| emily | so → #infra:nixos.org | 00:21:00 |
| 31 Oct 2024 |
|  frontear joined the room. | 04:24:00 |
| 5 Nov 2024 |
 p14 | I was hoping replaceStdenv would act in a way to replace the stdenv; but not of buildPackages. What I see is that cmake appears to be built with my replacement stdenv, which is not quite what I expected. My next gambit was to use crossSystem but if I have localSystem == crossSystem, then buildPackages == pkgs and the cross machinery doesn’t kick in.
My next gambit was to use stdenvStages but it looks like replaceStdenv is already implemented in exactly the way I was thinking to add a build stage.
I would like a way to construct a package set with a custom compiler but to keep buildPackages as a standard set of packages. Is that doable somehow? | 14:18:45 |
| Artturin | In reply to @p14:matrix.org
I was hoping replaceStdenv would act in a way to replace the stdenv; but not of buildPackages. What I see is that cmake appears to be built with my replacement stdenv, which is not quite what I expected. My next gambit was to use crossSystem but if I have localSystem == crossSystem, then buildPackages == pkgs and the cross machinery doesn’t kick in.
My next gambit was to use stdenvStages but it looks like replaceStdenv is already implemented in exactly the way I was thinking to add a build stage.
I would like a way to construct a package set with a custom compiler but to keep buildPackages as a standard set of packages. Is that doable somehow? replaceCrossStdenv | 14:22:42 |
