| 27 Jun 2025 |
 emily | pretty non actionable until we can get a bisection going on an affected machine | 18:21:11 |
| emily | since I'm assuming it does not reproduce on Hydra or the community builders? | 18:21:26 |
| emily | ideally someone experiencing it will give SSH access to someone with experience bisecting staging | 18:21:58 |
| emily | was the GCC minor bump that cycle? | 18:22:52 |
| emily | would be pretty funny if GCC 14 betrayed us again | 18:23:01 |
 Tristan Ross | There is a GCC bump | 18:23:23 |
| Tristan Ross | I have a Threadripper Pro 7995wx available currently, I have plenty of compute to (hopefully) bisect this. If someone provides a very reproducible runner, I can give it a try. Currently, the machine runs 25.05 and its fine. | 18:24:29 |
| Tristan Ross | There's also an LLVM bump in that cycle | 18:25:19 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @rosscomputerguy:matrix.org
There's also an LLVM bump in that cycle llvm is probably unrelated as nix has a problem too, and it's not involving aws-sdk-cpp | 18:28:09 |
| Tristan Ross | Yeah, I was thinking about that as well after I mentioned it | 18:28:49 |
| Tristan Ross | I saw there's some cc-wrapper changes but they look harmless enough, it probably is GCC like emily mentioned. | 18:29:20 |
 sielicki | stupid question: is there a reason that stdenvNoCC.fetchurl cannot assume builtins.fetchurl here? | 19:44:01 |
| emily | I believe https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/fetchurl/boot.nix is used for the boostrap | 19:45:37 |
| sielicki | nix-repl> :e <nix/fetchurl.nix>
error: cannot open '<nix/fetchurl.nix>' in an editor because it has no physical path
i do not understand what this is
| 19:50:16 |
| sielicki | is <nix/*> special? | 19:50:43 |
| emily | yes, it's magic builtin stuff | 19:51:13 |
| emily | I think builtins.fetchurl is a wrapper around it or something (probably newer than <nix/fetchurl.nix>?) | 19:51:23 |
| emily | or vice versa | 19:51:24 |
| sielicki | nix-repl> builtins.findFile builtins.nixPath "nix/fetchurl.nix"
<nix/fetchurl.nix>
turtles all the way down
| 19:51:40 |
| sielicki | okay, yes, it's right in the root of libexpr | 19:52:25 |
| emily | actually I think the difference is that <nix/fetchurl.nix> produces an actual FOD | 19:52:41 |
| emily | whereas builtins.fetchurl is a bulitin fetcher that runs at eval time | 19:52:48 |
| emily | but don't quote me on that | 19:52:49 |
| sielicki | it's a shame that this is so difficult to touch without catastrophic levels of rebuilds | 20:00:24 |
| emily | you can override stdenv for individual packages though of course for bootstrap that does not help | 20:01:38 |
| emily | but for anything early in bootstrap you can just build early bootstrap stuff when iterating since ideally it gets "washed out" past a certain point anyway | 20:02:12 |
| sielicki | with the current stdenv, my main complaint is that it's imprecise with respect to the languages supported. ie: there's no stdenv.cxx/stdenv.fc/stdenv.objcc/stdenv.objcxx/stdenv.nvcc/stdenv.hipcc | 20:04:36 |
| sielicki | there's really no good reason that a C compiler implies a C++ compiler or vice versa. I'm looking at this in the context of generating cmake toolchains from stdenvs | 20:05:14 |
| emily | in an ideal world stdenvNoCC would be the default and C toolchains would be added explicitly as dependencies | 20:13:49 |
| emily | I doubt we'd realistically decouple C and C++ though | 20:14:00 |
