| 23 Nov 2025 |
 dotlambda | If this leads to a visibly broken iso people who review the 25.11 release will complain. So I'd say master unless we plan on merging staging-next-25.11 before the release | 21:27:53 |
 leona | IMO merge to master, and preferably today | 21:33:40 |
 K900 | I have not seen significant breakage | 21:28:19 |
 Vladimír Čunát | Probably. | 21:39:35 |
| Vladimír Čunát | It doesn't look like it will take Hydra lots of time. | 21:39:53 |
| K900 | Aight | 21:41:05 |
| K900 | Merged, evals started | 21:59:02 |
| Vladimír Čunát | Let's wait with trunk-combined eval, so that we don't have too many jobs queued at the same time. (and we haven't had big channel updates since the staging-next merge yet) | 23:44:13 |
| 24 Nov 2025 |
 uep | looks like that's getting close thoug | 01:08:07 |
| uep | * | 01:08:40 |
| uep | mongodb failed in configure phase in my build, haven't looked into why. the immediate error was failing to find libcrypto, but there were iffy looking errors before that about bad scons escapes too. | 01:11:01 |
| uep | meh, I was too tired to bother looking into it yesterday, and should stop kidding myself that I will be motivated to do so today.. filed. | 01:22:30 |
| uep | (just generall, I love that a staging merge results in fewer build failures. good job) | 01:24:46 |
| uep | * | 01:24:51 |
 Fabián Heredia | Hi, now that staging is unrestricted bumping the gcc: 14 → 15 PR: https://github.com/NixOS/nixpkgs/pull/440456
| 01:33:31 |
| K900 | Do we have a jobset for this? | 04:33:51 |
| Fabián Heredia | Not yet, with release close by hydra was a bit busy. Did make 2 requests in the past if my memory serves right | 04:43:30 |
| leona | from the release side, we would be fine with 25.05 next for the security updates. Maybe after that 25.11 would be good to get the python + llvm fixes | 06:55:50 |
| leona | For gcc15 I agree that a jobset would be good | 06:56:54 |
| Vladimír Čunát | Lots of wishes to build 😅 | 07:24:44 |
| leona | i know and i'm sorry :D | 07:28:23 |
| Vladimír Čunát | gcc15: I'll keep that in mind. We tend to get periods of 1-3 days when linux builders have significant free capacity (we wait for darwin to catch up), so that seems ideal for this purpose. | 08:18:26 |
 ghpzin | If it is to get list for broken things, db and ncompress would need fixes - most things would just not build without.
If it is to reuse builds after, then pkgsMusl fixes would need to merged too - there is at least 1 stdenv (or close to it stdenv rebuild. | 09:20:25 |
| ghpzin | If it is to get list for broken things, db and ncompress would need fixes - most things would just not build without.
If it is to reuse builds after, then pkgsMusl fixes would need to merged too - there is at least 1 stdenv (or close to it) rebuild. | 09:20:34 |
| ghpzin | If it is to get list for broken things, db and ncompress would need fixes - most things would just not build without.
~If it is to reuse builds after, then pkgsMusl fixes would need to merged too - there is at least 1 stdenv (or close to it) rebuild.~
Last part is probably not true, perl fix is in staging already.
| 09:26:00 |
| ghpzin | If it is to get list for broken things, db and ncompress would need fixes - most things would just not build without.
If it is to reuse builds after, then `pkgsMusl` fixes would need to merged too - there is at least 1 stdenv (or close to it) rebuild.
Last part is probably not true, perl fix is in staging already. | 09:26:12 |
| Vladimír Čunát | Current staging won't reach 25.11, though. | 09:29:00 |
| ghpzin | gcc15 by default won't either, right | 09:32:06 |
| ghpzin | * gcc15 by default won't either, right ? | 09:32:12 |
| Vladimír Čunát | Correct. It was purposefully delayed past the branching point. | 09:34:54 |
