| 28 Oct 2025 |
|  Jacky changed their display name from Jacky Jnirvana to Jacky. | 22:18:14 |
| 31 Oct 2025 |
|  connor (burnt/out) (UTC-8) changed their profile picture. | 03:16:09 |
| connor (burnt/out) (UTC-8) changed their display name from connor (he/him) (UTC-7) to connor (burnt/out) (UTC-7). | 03:16:42 |
| 2 Nov 2025 |
| connor (burnt/out) (UTC-8) changed their display name from connor (burnt/out) (UTC-7) to connor (burnt/out) (UTC-8). | 08:12:41 |
| 5 Nov 2025 |
| connor (burnt/out) (UTC-8) | Is there a room for nix-eval-jobs specifically or would questions about the way Hydra performs evaluation be okay here? | 18:22:54 |
 K900 | This room is fine probably | 18:23:19 |
| 6 Nov 2025 |
| connor (burnt/out) (UTC-8) | The constituents functionality only improves evaluation performance because it allows Hydra to release memory earlier, not because it enables caching of previously evaluated attributes in the job set, right? | 16:16:48 |
 vcunat | I don't expect its point is to improve either. | 16:26:16 |
| vcunat | At least for the hydra.nixos.org deployment, for which it was surely designed, the only point of the feature seems to have a single job to follow which shows green iff a particular bigger set of jobs shows green. | 16:27:21 |
 ma27 | if you use strings of hydra jobset names instead of derivations in the constituents list, it does though. | 16:27:59 |
| vcunat | Speaking of its performance, I'm still horrified that building that job implies copying closures of all constituents to a builders, which in our case can get really big. The only luck is that we have very few builders, so usually most of it is there already. | 16:29:42 |
| vcunat | * Speaking of its performance, I'm still horrified that building that job implies copying closures of all constituents to a builders, which in our case can get really big. The only luck is that we have very few (but powerful) builders for linux, so usually most of it is there already. | 16:29:55 |
| vcunat | * Speaking of its performance, I'm still horrified that building that job implies copying closures of all constituents to a builders, which in our case can get really big. The only luck is that we have very few (but powerful) builders for *-linux, so usually most of it is there already. | 16:29:59 |
| vcunat | * Speaking of its performance, I'm still horrified that building that job implies copying closures of all constituents to a builder, which in our case can get really big. The only luck is that we have very few (but powerful) builders for *-linux, so usually most of it is there already. | 16:30:15 |
| 9 Nov 2025 |
|  ghpzin (moved to @ghpzin:envs.net) changed their display name from ghpzin to ghpzin (moved to @ghpzin:envs.net). | 15:03:54 |
| 12 Nov 2025 |
|  Inayet changed their display name from inayet to Inayet. | 12:38:09 |
|  André Lima joined the room. | 19:58:30 |
| 13 Nov 2025 |
|  @wolfgangwalther:matrix.org left the room. | 08:31:18 |
|  eveeifyeve joined the room. | 15:18:44 |
| 16 Nov 2025 |
| eveeifyeve | Hey Hydra team, do you know the best way we can build tarballs for cgywin, we are successfully building it with GHA? Because that might be something that I want to work on for windows. | 17:20:16 |
| K900 | Tarballs of what? | 17:20:57 |
| eveeifyeve | Cygwin builds of nix. | 17:21:25 |
| K900 | And why do we need those on Hydra? | 17:21:43 |
| eveeifyeve | It's building fine on GHA although we are running into a limit of the hours on github. | 17:22:16 |
|  Corngood joined the room. | 17:22:29 |
| K900 | Who is "we"? | 17:23:00 |
| eveeifyeve | Both me and corngood. | 17:23:17 |
| eveeifyeve | https://github.com/corngood/nixpkgs/actions/workflows/cygwin.yml | 17:23:19 |
| Corngood | The tarballs will be for bootstrapping, like on other platforms. The real problem at the moment is not having a cache. | 17:25:34 |
| K900 | I don't have a nixpkgs core hat anymore | 17:26:19 |
