| 26 Sep 2025 |
 emily | 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 | 18:35:15 |
 Sami Liedes | Yes, that's understandable. My thought was it's easier to get farther faster if there's a working branch with temporary fixes even if they never get to master, because then you get to test also dependencies of what doesn't now build in master. | 18:36:25 |
| emily | usually we just maintain those locally and clean them up as we push them out | 18:38:18 |
| Sami Liedes | But obviously I can also maintain a personal branch for that :) | 18:38:22 |
| Sami Liedes | Yeah, that's what I've been doing. | 18:38:29 |
| emily | or just push them out as branches on a fork | 18:38:40 |
 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 |
