| 26 Sep 2025 |
 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 |
| emily | AIUI, they fixed this upstream, so we may be due for a fetchpatch3 that is strictly better than both | 19:46:51 |
| emily | but frankly… I am going to want a test suite | 19:46:59 |
| emily | since we have been bitten once already there | 19:47:10 |
| emily | btw did you know that patch can't handle the diffs that diff/git diff produce for filenames with spaces in them? :( | 19:50:08 |
| emily | and that Meson deliberately uses spaces in its source tree? | 19:50:23 |
| samasaur | okay I think I was doing this. is fetchpatch still better than fetchpatch2 with full_index=1? | 19:50:43 |
| emily | well, sometimes the patch is not on GitHub | 19:50:54 |
| emily | but they should be mostly equivalent I think, I forget if there are any other fetchpatch2 regressions | 19:51:03 |
