| 4 Oct 2025 |
 dramforever | We build the bootstrap tools LLVM on aarch64-darwin for aarch64-apple-darwin but the real LLVM for arm64-apple-darwin. This is now a problem because LLVM 21 assumes that it should be arm64 in a test. This is now blocking the current staging-next -> master cycle. | 11:38:51 |
| dramforever | * We build the bootstrap tools LLVM on aarch64-darwin for aarch64-apple-darwin but the real LLVM for arm64-apple-darwin. aarch64 is now a problem because LLVM 21 assumes that it should be arm64 in a test. This is now blocking the current staging-next -> master cycle. | 11:38:59 |
| dramforever | I'm thinking of just changing it to arm64-apple-darwin, which should fix staging-next, but this means it requires special handling next time someone comes around to touching the bootstrap tarball | 11:39:55 |
| dramforever | I don't know if this is a good idea / who to tell about this. Any ideas? Thanks | 11:40:31 |
 Lun | wanted to take a look at your issue but fetching https://ftpmirror.gnu.org/patch/patch-2.5.9.tar.gz is failing, did you have to import any FODs from alternate sources to get that far? | 22:33:05 |
| Lun | something cursed is happening in gen-fib. if you run it redirecting to a file that file just gets /* This file generated by gen-fib.c - DO NOT EDIT. */ and no further lines.
probably the musl always-flush.patch you dropped was loadbearing | 23:28:08 |
| Lun | * something cursed is happening in gen-fib. if you run it redirecting to a file that file just gets /* This file generated by gen-fib.c - DO NOT EDIT. */ and no further lines, if you run it without a redirect it works.
probably the musl always-flush.patch you dropped was loadbearing | 23:28:27 |
| Lun | * wanted to take a look at your issue but fetching https://ftpmirror.gnu.org/patch/patch-2.5.9.tar.gz is failing, did you have to import any FODs from alternate sources to get that far? was intermittent, managed to fetch | 23:32:15 |
| Lun | yeah if you apply it again minimal-bootstrap.gcc46 builds, tested in https://github.com/NixOS/nixpkgs/commit/ecbb9bad38cf3d293943cb9cebb84dce1fd05698 | 23:39:06 |
| 5 Oct 2025 |
 dish [Fox/It/She] | fascinating as to why that's the case | 00:04:14 |
| dish [Fox/It/She] | thanks | 00:04:15 |
| dish [Fox/It/She] | strange, appreciate the help! | 00:04:30 |
| dish [Fox/It/She] | but also it does make sense | 00:05:45 |
| dish [Fox/It/She] | * but also it does make sense >.> | 00:05:49 |
| dish [Fox/It/She] | Okay, confirmed that the new bootstrap chain fully builds. I'm going to push my changes as they stand right now as a PR, and start a new branch rebasing emily's changes from #260193 to my branch. | 00:51:19 |
| dish [Fox/It/She] | https://github.com/nixos/nixpkgs/pull/448701 | 00:57:10 |
| dish [Fox/It/She] | Okay, confirmed that the updated bootstrap chain fully builds. I'm going to push my changes as they stand right now as a PR, and start a new branch rebasing emily's changes from #260193 to my branch. | 01:06:48 |
| Lun | gz on getting that to this point! | 01:07:31 |
| dish [Fox/It/She] | thank you! | 01:10:58 |
| dramforever | Lun: do you happen to know whom i should cc for those darwin bootstrap tools shenanigans | 01:13:15 |
| dramforever | like i fixed ... something, but as i've written it's going to be a problem next time someone goes to roll the bootstrap tarballs | 01:13:45 |
| Lun | reckenrode? | 01:13:55 |
| dish [Fox/It/She] | also I've just realized that my current strategy of picking individual commits(in sequence one at a time) from emily's branch is going to involve a lot of rebuilding the same stuff over and over(for instance pulling the static coreutils commit rebuilt everything up to musl 1.1, and then picking the static gnutar commit is doing that same build process again, which means I'm gonna be building several dozen GCCs by the end of this) , but I would rather do that then break something and not know where to start. Also this means that it something breaks i know where and when which will help me a lot. | 01:14:45 |
| dish [Fox/It/She] | * also I've just realized that my current strategy of picking individual commits(in sequence one at a time) from emily's branch is going to involve a lot of rebuilding the same stuff over and over(for instance pulling the static coreutils commit rebuilt everything up to musl 1.1, and then picking the static gnutar commit is doing that same build process again, which means I'm gonna be building several dozen GCCs by the end of this) , but I would rather do that then break something and not know where to start. This means that it something breaks i know where and when which will help me a lot. | 01:14:55 |
| dish [Fox/It/She] | * also I've just realized that my current strategy of picking individual commits(in sequence one at a time) from emily's branch is going to involve a lot of rebuilding the same stuff over and over(for instance pulling the static coreutils commit rebuilt everything up to musl 1.1, and then picking the static gnutar commit is doing that same build process again, which means I'm gonna be building several dozen GCCs by the end of this) , but I would rather do that then break something and not know where to start. This means that it something breaks i know where and when which will help me a lot while i cherry-pick these | 01:15:02 |
| dish [Fox/It/She] | each rebuild is like 20 minutes though so it's slow going | 01:15:10 |
| dish [Fox/It/She] | * each rebuild is like 20 minutes though so it's slow going, however its only like 20 commits and once I'm done then i can keep going more smoothly | 01:15:23 |
| dish [Fox/It/She] | * also I've just realized that my current strategy of picking individual commits(in sequence one at a time) from emily's branch is going to involve a lot of rebuilding the same stuff over and over(for instance pulling the static coreutils commit rebuilt everything up to musl 1.1, and then picking the static gnutar commit is doing that same build process again, which means I'm gonna be building several dozen GCCs(4.6.4 -> 4.6.4 with c++ -> 8.5.0 -> 13.2.0 before getting to static binaries, potentially every time) by the end of this) , but I would rather do that then break something and not know where to start. This means that it something breaks i know where and when which will help me a lot while i cherry-pick these | 01:16:53 |
| dramforever | is this like, automated | 01:17:02 |
| dramforever | i've done stuff like this just going git rebase -x 'do the thing' and went to get lunch or something, 20 minutes per commit is, a bit slow but not the worst | 01:18:06 |
