 | Nixpkgs Stdenv | 218 Members |
| 69 Servers |
| Nixpkgs Stdenv | 218 Members |
| 69 Servers |
| Sender | Message | Time |
|---|---|---|
| 28 Oct 2024 | ||
 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 | | 00:14:28 |
| emily | In reply to @artturin:matrix.orgso 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.orgI 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.orgit never failed for me. | 00:16:31 |
| @paparodeo:matrix.org | In reply to @emilazy:matrix.org* 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.orgreplaceCrossStdenv | 14:22:42 |
| Artturin | 😄 | 14:22:52 |
| p14 | I tried using replaceCrossStdenv but as I tried to say above, it does not take effect when localsystem is crosssystem | 14:23:30 |
| p14 | So is there a way to use the cross system machinery when targeting local? | 14:23:41 |
| p14 | Ha. I just needed to make the systems not equal. So adding crossSystem.custom = true seems to be enough to trigger it. Maybe this will work! The rebuilt set of packages looks promising. | 14:27:14 |
| p14 | Annoyingly it looks like it is rebuilding gcc. | 14:27:41 |
| p14 | Right, looks like because the compiler package name gets annotated with the cross triple, even though it is redundant in this case. | 14:28:59 |
| p14 | Of course I can fix this up by making replaceCrossStdenv use the buildPackages compiler. Nice! Looks like I have what I want now… | 14:30:43 |
| p14 | Found a case where it borks, firefox refuses to eval with unsupported platforms in wasilibc, because it has meta platforms = wasm*. Odd. The non-cross version is fine as expected. | 14:38:00 |