| 26 Sep 2025 |
 Alyssa Ross | In reply to @emilazy:matrix.org
we prefer backported patches already applied upstream, then patches from other distros / unmerged patches already sent upstream by others, then patches we write and submit upstream ourselves, and only then patches that only live in Nixpkgs nit: I'd prefer patches we write and submit upstream ourselves over patches from other distros that they didn't submit | 18:55:18 |
 emily | fair enough | 19:04:02 |
| Alyssa Ross | (Sometimes I find non-upstream patches from other distros but decide to write and submit my own anyway) | 19:06:08 |
| emily | the distro patches are that bad? :) | 19:07:47 |
| Alyssa Ross | Well if they didn't upstream it, and we don't upstream it, how are we going to ever get rid of it? | 19:09:43 |
| emily | you could always upstream another distro's patch (licence questions aside I suppose) | 19:10:31 |
| 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 | 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 | 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 | 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 | 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 (any/all) | fetchpatch2 { excludes = [ "<bazel file>" ]; } | 19:44:33 |
| emily | (fetchpatch over fetchpatch2 please) | 19:45:06 |
| Grimmauld (any/all) | 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 (any/all) | HUH# | 19:45:29 |
| emily | fetchpatch does basically everything except renames. | 19:45:30 |
| Grimmauld (any/all) | 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 |
