| 4 Nov 2025 |
 ivy | llvm is llvm and llvm.checks,
and all things that depend on llvm have a checks output that depends on llvms checks, so checks can be parrallelised? | 03:08:36 |
| ivy | instead of if a checkPhase fails on hydra it messes up the entire build process and shortcircuits all dependencies on it, | 03:09:35 |
| ivy | and also takes a long time | 03:09:42 |
| ivy | 
Download image.png | 03:15:37 |
| ivy | like this | 03:15:38 |
 Winter | can’t easily go from $out to a test-ready build env though | 03:17:30 |
| Winter | that’s the issue | 03:17:33 |
| Winter | lots of tests depend on the build environment being set up | 03:17:39 |
| Winter | and artifacts being already built etc… | 03:17:49 |
| ivy | can we make that build env passed into that check? | 03:19:23 |
| ivy | like the build env is copied into that new check env | 03:20:05 |
| ivy | 
Download image.png | 03:27:30 |
| ivy | this perhaps then | 03:27:30 |
| ivy | where mid-build-env contains the built artifacts minus the checkPhases | 03:28:12 |
| ivy | so it's more parallelised | 03:29:34 |
| ivy | Winter: thoughts? | 03:30:15 |
 dish [Fox/It/She] | In reply to @ivy:faggot.sh
llvm is llvm and llvm.checks,
and all things that depend on llvm have a checks output that depends on llvms checks, so checks can be parrallelised? i mean if llvm checks are failing i would want stuff to block on that | 03:46:57 |
| dish [Fox/It/She] | since compiler errors are not good | 03:47:06 |
| ivy | it would still block, just not block building them simultaneously | 03:47:49 |
| ivy | like stuff still builds while checks are going on | 03:48:05 |
| ivy | and also would be helpful for compiler understanding of why the test fails when dependencies fail | 03:48:46 |
| dish [Fox/It/She] | yeah what im saying is i'd rather block on checks succeeding for critical deps like compilers | 04:07:16 |
|  cafkafk changed their profile picture. | 08:22:56 |
|  plasmapower joined the room. | 20:22:34 |
| plasmapower | I've been looking into a timezone issue with a libstdc++ application. I think we need --with-libstdcxx-zoneinfo=${targetPackages.tzdata}/share/zoneinfo for gcc but don't have it (or maybe we need to set it to /etc/zoneinfo). Right now it seems to be looking in /usr/share/zoneinfo and /var/db/zoneinfo, as confirmed by both strace and running strings on libstdc++, but zoneinfo is in neither of those places on NixOS. Does this sound right? I can make the PR myself but I wanted to make sure this is reasonable before I spend a bunch of compute cycles testing this | 20:26:31 |
| plasmapower | * I've been looking into a timezone issue with a libstdc++ application. I think we need --with-libstdcxx-zoneinfo=${targetPackages.tzdata}/share/zoneinfo for gcc but don't have it (or maybe we need to set it to /etc/zoneinfo). Right now it seems to be looking in /usr/share/zoneinfo and /var/db/zoneinfo, as confirmed by both strace and running strings on libstdc++, but zoneinfo is in neither of those places on NixOS. Does this sound right? I can make the PR myself but I wanted to make sure this is reasonable before I spend a bunch of compute cycles testing this
Edit: seems like this isn't related to the issue I'm debugging, as the hardcoded tzdata in glibc is up-to-date. In theory it might be better to have the fs location correct but I don't think it matters here. | 20:51:11 |
|  zimward joined the room. | 22:40:45 |
| 5 Nov 2025 |
 Tristan Ross | https://github.com/NixOS/nixpkgs/pull/365057 3 months and no update on this | 15:55:03 |
| 6 Nov 2025 |
| dish [Fox/It/She] | Submitted #459002 as the 2nd part of my current minimal-bootstrap work, its the adaption of emilytrau's work to make it up-to-date with what we have now. Assistance with getting gcc for glibc and integrating into stdenv would be appreciated, as mentioned in the PR body. | 01:49:16 |
|  nhnn changed their profile picture. | 15:13:39 |
