| 19 Sep 2025 |
 K900 | So I guess I'll do another build | 05:35:32 |
 Toma | I have an interesting situation:
the rPackages set is not crawled by hydra, so most packages from there are never cached.
However, packages depending on rPackages *are* built by hydra, thus the dependencies from rPackages are also cached.
There is a package that pulls in a lot of rPackages like this, however it had a build failure lately, so neither it nor its dependencies are cached now.
After fixing the build of the package, the uncached packages needed to be built again, which was around ~500 (and it included some larger builds)
I know nowadays 500 rebuilds could be acceptable into master.
However let's assume it's not acceptable.
Then, would me fixing this package be considered 1 rebuild or 500 rebuilds?
And also, which branch should it target.
(I'd say master would be fine, but I wanted to get your opinjon on this)
(Also, CI says it's 1 rebuild, cuz it probably just counts derivations changed) | 07:33:17 |
 Alyssa Ross | The impact on Hydra is the relevant thing | 07:37:44 |
 Wolfgang Walther |
(Also, CI says it's 1 rebuild, cuz it probably just counts derivations changed)
CI only counts exposed attributes that are explicitly build targets itself, but not "hidden dependencies". In this case the many rPackages are essentially hidden dependencies.
| 07:40:33 |
| Wolfgang Walther | From what I learned the last couple of days this should not be as bad for hydra as if all these 500 rPackages were explicit build targets.. because these 500 packages will only affect the builder, but not the queue-runner, right? And I heard that rPackages are fast to build anyway. So the impact on hydra might not be too bad? | 07:42:20 |
| Toma | Most were fast, yes,
There were a few that were quite intensive (had to get more swap memory)
but not a lot of those | 07:44:35 |
| K900 | OK I have all of kdePackages | 11:21:59 |
| K900 | @vcunat do you want to start staging-next in a couple hours | 11:24:12 |
 Vladimír Čunát | I wonder. | 11:25:49 |
| Vladimír Čunát | I'd probably merge staging-next-25.05 instead. | 11:26:00 |
| Vladimír Čunát | In that timeframe. | 11:26:10 |
| K900 | There's still 20k Darwin jobs | 11:26:11 |
| Vladimír Čunát | I know. | 11:26:16 |
| Vladimír Čunát | But the -darwin channel will just update in a few days when it's done 🤷 | 11:26:29 |
| K900 | I guess | 11:26:35 |
| Vladimír Čunát | In the meantime Hydra can chew through those cached jobs and prepare NixOS tests. | 11:26:46 |
| Vladimír Čunát | (and the linux channel won't be delayed by darwin) | 11:27:03 |
 Grimmauld (any/all) | we doing gcc 15 now? | 11:28:54 |
| Grimmauld (any/all) | or cmake 4? | 11:28:58 |
| Grimmauld (any/all) | systemd 258 probably won't be there in time | 11:29:11 |
| K900 | No GCC 15 yes cmake 4 | 11:30:11 |
| Vladimír Čunát | So you think staging already has everything wanted for the next iteration? | 11:43:20 |
| Vladimír Čunát | I believe it's most likely that this weekend we do start a new staging-next. | 11:46:13 |
| K900 | Not yet | 11:55:03 |
| K900 | I'll have cmake 4 in like an hour | 11:55:22 |
| K900 | OK maybe a bit mre | 11:56:58 |
| K900 | * OK maybe a bit more | 11:56:59 |
| K900 | There's more webkits | 11:57:09 |
| Grimmauld (any/all) | I'd also appreciate https://github.com/NixOS/nixpkgs/pull/444275, its just removing things we weren't using anyways. But i am a bit too scared to self-merge this without review | 11:59:00 |
| Vladimír Čunát | That's good to merge earlier than creating staging-next. Because darwin stdenvs will take lots of time to build (after changing cmake). | 11:59:06 |
