| 26 Sep 2025 |
 Alyssa Ross | That's true but often there's something I'd do slightly differently, and given I have to test it anyway... | 19:11:23 |
 @ghpzin:envs.net | does it include llvmPackages_{18,19} build fixes ?
(provided I don't know if Darwin even builds them with gcc) | 19:27:42 |
 emily | we don't try to of course | 19:30:48 |
| emily | Darwin is LLVM-native | 19:30:51 |
| emily | and GCC has poor support on Darwin in general | 19:31:03 |
| emily | it's only really load-bearing via GFortran, and frankly we should move to Flang for that anyway | 19:31:12 |
| emily | but GFortran is load-bearing, so we do need to keep it working | 19:31:21 |
| emily | we compile GCC with LLVM | 19:31:29 |
| emily | I wouldn't be surprised if building LLVM with GCC on Darwin is broken already :) so that's mostly relevant for Linux | 19:32:03 |
| @ghpzin:envs.net | Then I guess I will try to PR tomorrow, because llvmPackages_{18,19}.mlir and llvmPackages_18.{lldb,llvm} do not build with gcc15.
I tried to make patches sane, but upstream not backporting and changing include lines between versions made it harder. | 19:36:54 |
| @ghpzin:envs.net | Then I guess I will try to PR tomorrow, because llvmPackages_{18,19}.mlir and llvmPackages_18.{lldb,llvm} do not build with gcc15.
I tried to make patches sane, but upstream not backporting and changing include lines between versions made it harder.
My favorite is that one commit that would apply cleanly if only author did not bundle some bazel file change into same commit with it. | 19:39:41 |
| @ghpzin:envs.net | Then I guess I will try to PR tomorrow, because llvmPackages_{18,19}.mlir and llvmPackages_18.{lldb,llvm} do not build with gcc15.
I tried to make patches sane, but upstream not backporting and changing include lines between versions made it harder.
My favorite is that one patch that would apply cleanly if only author did not bundle some bazel file change into same commit with it. | 19:40:05 |
 Grimmauld (migrated to @grimmauld:m.grimmauld.de) | fetchpatch2 { excludes = [ "<bazel file>" ]; } | 19:44:33 |
| emily | (fetchpatch over fetchpatch2 please) | 19:45:06 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | fetchpatch doesn't do excludes though, right? | 19:45:21 |
| emily | (ough, need to revert that docs change once I have more than 0 slack…) | 19:45:23 |
| emily | it does. | 19:45:25 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | HUH# | 19:45:29 |
| emily | fetchpatch does basically everything except renames. | 19:45:30 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | okay then | 19:45:50 |
 samasaur | what is the difference between these two. i've been defaulting to fetchpatch2 (higher number is clearly better) | 19:45:52 |
| emily | it was meant to be better :( | 19:45:58 |
| emily | fetchpatch2 uses a newer version of the patch-munging program | 19:46:04 |
| emily | it handles renames | 19:46:08 |
| Grimmauld (migrated to @grimmauld:m.grimmauld.de) | fetchpatch2 bad, use fetchpatch if possible | 19:46:13 |
| emily | unfortunately, it does not strip the index … Git lines containing truncated commit hashes | 19:46:15 |
| emily | and those change, as repos get bigger | 19:46:19 |
| emily | you need ?full_index=1 to use fetchpatch2 safely with GitHub patches | 19:46:28 |
| emily | and some forges don't have an option for it at all | 19:46:33 |
| emily | so unfortunately fetchpatch is usually the better option | 19:46:39 |
