| 3 Oct 2025 |
dramforever | inputs -> nixpkgs says 4447b9d3e439b3c0e0b3f824a28025921797d179 | 14:43:33 |
Lun | i slept through getting to panic about this thanks for sorting it! | 14:43:35 |
dramforever | i do nix eval github:NixOS/nixpkgs/4447b9d3e439b3c0e0b3f824a28025921797d179#legacyPackages.aarch64-darwin.llvm.src.outPath and it's not that | 14:43:53 |
dramforever | is it somehow different if i eval on macos | 14:44:05 |
Grimmauld (any/all) | https://github.com/NixOS/nixpkgs/blob/cf9a3a11f8d3ac7b612774148560d91ea4e40ac5/pkgs/development/compilers/llvm/common/llvm/default.nix#L49
is this maybe interferring? | 14:44:49 |
dramforever | wtf | 14:45:18 |
Grimmauld (any/all) | no worries as long as you don't complain about my shoddy work XD | 14:46:22 |
Lun | iiuc bootstrap compilers being built with this flag basically doesn't matter because we have multiple stages and nothing should really survive from that to be used at runtime on a nixos system, so it would have been ok to flip it off for that.
i like the idea of having aslr for them just so everything's the same but i'm not sure what the threat model is where someone is relying on attacking some memory corruption issue in the bootstrap tools | 14:46:22 |
Lun | * iiuc bootstrap compilers being built with this flag basically doesn't matter because we have multiple stages and nothing should really survive from that to be used at runtime on a nixos system, so it would have been ok to flip it off for that.
i like the idea of having aslr for them just so everything's the same but i'm not sure what the threat model is where someone is relying on attacking some memory corruption issue in the bootstrap phases | 14:47:07 |
dramforever | i have no idea why the "arm64" in whatever thing isn't breaking anything else | 14:50:15 |
dramforever | i wonder if it's some lto test that only happens if some specific supported setup is created | 14:59:58 |
dramforever | like llvm_21-built-llvm_21 | 15:00:37 |
dramforever | i posted my stdenvBootstrapTools.x86_64-apple-darwin.test resource-dir fix here https://github.com/NixOS/nixpkgs/pull/444862#issuecomment-3366730973, idk if it's good but whoever has a x86_64-darwin can check it out | 18:21:30 |
| 4 Oct 2025 |
Grimmauld (any/all) | nixd is still failing to that meson bug. emily what was the fix again if llvm was not being found as part of runtime inputs? | 07:25:00 |
K900 | Ugh I need to do the qt thing | 07:25:25 |
K900 | That I completely forgor | 07:25:28 |
Grimmauld (any/all) | ah nvm found your old messages | 07:27:22 |
K900 | Actually | 07:28:31 |
K900 | @vcunat what do you think about eating a qtdeclarative rebuild on next | 07:28:39 |
K900 | It's something like 3k jobs | 07:28:43 |
K900 | (total) | 07:28:49 |
Grimmauld (any/all) | because darwin shenanigans? | 07:29:24 |
K900 | No | 07:29:43 |
K900 | Because there's an annoying crasher | 07:29:50 |
Grimmauld (any/all) | If we are considering eating rebuilds, we might also want to do https://github.com/NixOS/nixpkgs/pull/448259 Because it is now cached, but a source build fails. ~1.2k rebuilds. | 07:30:58 |
K900 | OK I guess scratch that | 07:40:28 |
K900 | The crasher fix does not apply cleanly to 6.9.2 | 07:40:34 |
Grimmauld (any/all) | Okay, three more fixes and i'll have a system running on -next | 08:27:22 |
Grimmauld (any/all) | 2/3 already done, leaves ghostscriptX | 08:27:52 |
Grimmauld (any/all) | which is cached but somehow i get a rebuild and that fails, so i am confused | 08:30:02 |