| 29 Aug 2025 |
K900 | Not much written down | 21:08:42 |
K900 | But basically bootstrap-files goes into gcc goes into stdenv goes into everything else | 21:08:58 |
dish [Fox/It/She] | gotcha | 21:14:07 |
emily | I think replacing the bootstrap tarballs derivation with one that contains a bunch of symlinks to the final steps of the minimal bootstrap would probably be the most expedient integration point | 21:19:25 |
| 30 Aug 2025 |
dish [Fox/It/She] | okay my first step atm is updating the bootstrap chain, we're on stage0-posix 1.6.0 atm, and we can go to 1.9.1 which requires a bunch of dependency upgrades so I'm working through those. Once that's finished, then I want to try and replace bootstrap-files and see what blows up | 00:45:05 |
dish [Fox/It/She] | should probably make a public page or something but for now im just tracking it locally | 00:45:35 |
dish [Fox/It/She] | * should probably make a public page or something but for now im just tracking it locally in my notes app | 00:45:38 |
dish [Fox/It/She] | * should probably make a public tracking page or issue or something but for now im just tracking it locally in my notes app | 00:47:25 |
dish [Fox/It/She] | also gonna make notes as I go, so that folks can hopefully understand the bootstrap chain more in-depth in the future. Guix makes it a priority to have the bootstrap code be as readable as possible(relatively speaking), and currently nix's is nothing like that, while the code in any one file is fairly easy to read, figuring out the chain of dependencies and where something comes from is difficult to do without referencing a lot of external documentation. I want to get to having graphs and such(as embedded mermaid diagrams) showing the high-level organization of dependencies, also linking back to other external documentation as needed. | 04:14:17 |
Randy Eckenrode | It would be nice if the bootstrap could use the cross-compilation machinery instead of having to manually set up each stage and its overrides. | 11:10:20 |
dish [Fox/It/She] | that is something I'm gonna look at, but might be a future improvement once its actually our bootstrap root | 14:05:00 |
dish [Fox/It/She] | since right now my priority is updating everything to work with stage0-posix 1.9.1 and then making this our actual bootstrap root | 14:09:13 |
Sandro 🐧 | I would need some help with https://github.com/NixOS/nixpkgs/pull/438709 | 19:52:54 |
| 2 Sep 2025 |
dish [Fox/It/She] | doing bootstrap stuff and GODS i hate repo.or.cz its just so slow | 00:04:33 |
dish [Fox/It/She] | timeout reached every damn time 😭 | 00:04:39 |
siraben | https://github.com/NixOS/nixpkgs/pull/439351 | 03:19:24 |
siraben | uutils coreutils PR, rebased and targeting staging | 03:19:41 |
| winston joined the room. | 12:45:16 |
| @wolfgangwalther:matrix.org joined the room. | 14:11:50 |
| 3 Sep 2025 |
| ghpzin joined the room. | 07:30:19 |
| Winter joined the room. | 15:13:01 |
Winter | i'm attempting to make a stdenv that uses an old (incompatible with our bootstrap tools) glibc -- i've tried to do things like "fake" cross to work around the issue, but always get stuck in some bootstrapping stage (either 3 or 4 depending on the strategy) because binutils from the previous stage still depends on new glibc. is my best bet for now to maybe create a custom stdenv that somehow bootstraps binutils from newer glibc -> older glibc? i can compile old glibc with new glibc but binutils is where it gets fun :/ | 15:15:39 |
Winter | * i'm attempting to make a stdenv that uses an old (incompatible with our bootstrap tools) glibc -- i've tried to do things like "fake" cross to work around the issue, but always get stuck in some bootstrapping stage (either 3 or 4 depending on the strategy) because binutils from the previous stage still depends on new glibc, so e.g. expand-response-param can never get compiled. is my best bet for now to maybe create a custom stdenv that somehow bootstraps binutils from newer glibc -> older glibc? i can compile old glibc with new glibc but binutils is where it gets fun :/ | 15:16:53 |
Winter | obviously the easiest route may be to just make bootstrap tools, but that'll require me downgrading to a nixpkgs rev and then probably get stuck in a bootstrapping-induced loop | 15:22:51 |
Winter | not sure if i can even do this in one stage but replaceStdenv only lets me use one stage :-/ | 15:37:06 |
Winter | guess i can make it let me use multiple | 15:37:13 |
Winter | i suppose the ~nicest?? way to do it will be to modify stage1 (or add a stage between 0 and 1) to rebuild binutils | 15:48:53 |
Winter | * i suppose the ~nicest?? way to do it will be to modify stage2 | 15:52:02 |
Winter | but then you get stuck in another loop because xgcc is incompatible with old glibc... so then you can't even build another gcc or another xgcc | 19:01:56 |
Winter | tried doing the cursed thing of:
build old glibc in stage2 build new xgcc in a subsequent stage, using the old xgcc's stdenv, but pointing to the old glibc as build sysroot use that xgcc like nothing has changed
but that also blows up, i guess expectedly | 19:46:01 |