| 11 May 2025 |
 trofi | (like abandoned https://github.com/NixOS/nixpkgs/pull/181724) | 14:35:49 |
 Tristan Ross | In reply to @trofi:matrix.org
(like abandoned https://github.com/NixOS/nixpkgs/pull/181724) Rip yeah, imo we should be closing abandoned PR's because there's not really a point in leaving them open | 15:04:17 |
 Alyssa Ross | Is there a point in closing them? | 15:06:07 |
| Tristan Ross | Well if it's not going to be worked on anytime soon, why leave like a 2yo PR that has merge conflicts open? | 15:07:18 |
 emily | it was closed in 2022? | 15:07:48 |
| trofi | looking at the comment it broke meson-based builds on clang (and they used to work by accident by using a wrong compiler) | 15:08:53 |
 p14 | But is there a good reason to put the unwrapped CC in the path? I have dropped it without ill effect and it does fix things ion my case. | 17:17:03 |
| emily | we don't but we do want prefixed compilers | 17:18:55 |
| emily | so the prefixed ones should probably be wrapped | 17:19:10 |
| p14 | So, could https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/cc-wrapper/setup-hook.sh#L92-L94 and https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/bintools-wrapper/setup-hook.sh#L39-L41 be dropped.
In light of the commit message here https://github.com/NixOS/nixpkgs/pull/182385/commits/e682dd84cff5d2420fcc0a40508557477f6cc9d3 which comments that it was unknown why there were in the path (but the answer is linked above). Now it is found, can we delete it? :) | 18:42:09 |
| p14 | I'm thinking that essentially if there is some binary provided by the compiler and it's not symlinked into the wrapper, that is a bug. | 18:43:42 |
| p14 | While messing with the booting machinery I am hitting an odd thing where somehow a meson is creeping in which has an openmp dependency which creates an infinite cycle. Haven't debugged it yet. (clang -> tblgen -> cmake -> libarchive -> e2fsprogs -> fuse -> meson (from some other stage) -> openmp -> infinite cycle on clang). I guess I need to plug something into my stdenv overrides to prevent this. | 18:54:42 |
| trofi | e2fsprogs -> fuse can be broken by disabling withFuse = false; | 18:56:41 |
| p14 | Do you happen to know of any good ways to visualise the dependency graph across the stages? I've resorted to injecting names into derivations to indicate which stage they're in, which helps, but within a stage it can be helpful to understand the why-depends relationships of things without having to manually invoke it repeatedly. | 19:03:57 |
 Randy Eckenrode | https://github.com/NixOS/nixpkgs/blob/5d0f68d3c0af3ecd33697bccfba40f73c82526ca/pkgs/stdenv/linux/default.nix#L33-L55 | 19:12:34 |
| Randy Eckenrode | Should work for any stdenv that follows similar stage naming conventions. | 19:12:52 |
| Randy Eckenrode | (I’ve used it when working on Darwin’s.) | 19:13:00 |
| trofi | +1. Yeah, I usually use that with a bit of grep tweaks. | 19:25:18 |
| p14 | It'd be great if the stdenvs had differing names (I have given mine different names, but I'm also thinking of those appearing by use of overrideCC within llvm common. | 20:28:59 |
| Randy Eckenrode | Darwin’s stdenv is stdenv-darwin, and its bootstrap stages are suffixed with -stdenv-darwin, but they follow the same bootstrap-stageX convention that Linux does, so that grep works on Darwin. | 20:46:32 |
| Randy Eckenrode | * Darwin’s stdenv is stdenv-darwin, and its bootstrap stages are suffixed with -stdenv-darwin, but they follow the same bootstrap-stageX convention that Linux does, so that grep still works. | 20:46:42 |
| 16 May 2025 |
| Tristan Ross | NixOS 25.05 has branched off, if we're ready to bump LLVM then we can undraft https://github.com/NixOS/nixpkgs/pull/407738.
CC Randy Eckenrode emily
| 21:56:46 |
| emily | we should make sure Mesa + Firefox build on Linux, and both Darwin stdenvs bootstrap successfully | 21:58:39 |
| emily | other than that it should be good to go I think. should probably also bump Rust's LLVM | 21:58:49 |
| emily | (and commit message should be llvmPackages: llvmPackages_19 -> llvmPackages_20 according to conventions) | 21:59:02 |
| emily | also needs a release note :) | 21:59:08 |
| Tristan Ross | Will do, I'll build outside of staging since I don't want to waste compute heh. I'll check some pkgsLLVM things to see if they still work. | 21:59:55 |
