| 26 Sep 2025 |
 @ghpzin:envs.net | Could you ref gcc15 PR, so people know there is a fix for pkgsCross/pkgsStatic
(kind of hard to find these, already had rebase of that patch in my fork) | 13:36:12 |
| @ghpzin:envs.net | Could you ref gcc15 PR (https://github.com/NixOS/nixpkgs/pull/440456), so people know there is a fix for pkgsCross/pkgsStatic
(kind of hard to find these, already had rebase of that patch in my fork) | 13:36:51 |
 Marie | sure | 13:38:50 |
| @ghpzin:envs.net | Maybe somebody already made PR to update musl bootstrap files, but it is also impossible to find. | 13:55:23 |
| @ghpzin:envs.net | Maybe somebody already made PR to update musl bootstrap files (to fix pkgsMusl), but it is also impossible to find. | 14:00:17 |
 emily | GCC 15 also needs some Darwin stuff I have locally | 18:31:27 |
| emily | probably 26.05 makes the most senes at this point | 18:31:34 |
| emily | 💜 to ghpzin for all the fix PRs though | 18:31:39 |
 Sami Liedes | Ah, I may have found the room! I've been patching a bit stuff in nixpkgs which I think probably also applies to gcc 15. (Specifically what I've been fixing is packages building with GCC 14 and -D_GLIBCXX_DEBUG, which requires things that declare themselves as random access iterators to have operator<=; but I read in some bug report that gcc 15 is also similarly picky about some iterator operators.)
Is there a branch somewhere where the proposed gcc 15 patches are collected? I could switch to that and start fixing for it with -D_GLIBCXX_DEBUG, so I would likely at the same time fix them for gcc 15.
| 18:32:26 |
| emily | those fixes can go to master just fine | 18:34:43 |
| 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: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 |
