| 22 Jan 2026 |
 John Ericson | oh yeah hydar | 20:28:10 |
| John Ericson | github actions ain't worht shit | 20:28:15 |
| John Ericson | does your new source accessor need any more file-descriptor functions? | 20:28:41 |
| John Ericson | or was readLinkAt the last one? | 20:28:49 |
| John Ericson | Sergei Zimmerman (xokdvium): did you fix the freebsd 25.11 error btw? | 20:35:48 |
| John Ericson | because we could do that | 20:35:57 |
| 23 Jan 2026 |
 Robert Hensing (roberth) | Did anyone have a problem with mixed pipe operators being allowed, or hear anyone complain about it?
E.g. a |> b <| c or p <| q |> r for some expressions a, b, etc.
If not, I'll propose FCP as RFC 148 shepherd. | 00:17:10 |
|  Jeronimo changed their display name from Jeroen Jeurissen to Jeronimo. | 12:22:29 |
| John Ericson | fine with me! | 19:11:32 |
|  silent_water joined the room. | 19:12:41 |
|  fcainzos joined the room. | 21:57:24 |
| 24 Jan 2026 |
 faukah | What is the behavior of the --commit-lock-file flag? Does it only commit the change when the invoked command actually changes the flake.lock? Or is it sufficient to have a flake.lock file that is modified in the current git staging area? | 20:31:38 |
| 25 Jan 2026 |
 Mindavi | In reply to @faukah:faukah.com
What is the behavior of the --commit-lock-file flag? Does it only commit the change when the invoked command actually changes the flake.lock? Or is it sufficient to have a flake.lock file that is modified in the current git staging area? Pretty sure it only does something if the update command results in an update | 00:30:00 |
| Mindavi | But I think it should be fairly easy to try out to be sure | 00:30:40 |
|  larray joined the room. | 12:11:27 |
| larray set a profile picture. | 17:56:06 |
|  dadada changed their profile picture. | 20:34:11 |
| dadada changed their profile picture. | 20:39:12 |
| dadada changed their profile picture. | 21:17:48 |
| 26 Jan 2026 |
|  Jean š joined the room. | 01:46:56 |
 Sergei Zimmerman (xokdvium) | Noticed that some of the parser errors are cursed and there's a very easy way to fix it: https://github.com/NixOS/nix/pull/15092 | 23:32:55 |
| 27 Jan 2026 |
 eveeifyeve | 
Download ima_4713327.jpeg | 02:37:21 |
| eveeifyeve | I will be back after I eat.Theo Paris | 02:37:22 |
| eveeifyeve | * I will be back after I eat. Theo Paris | 02:37:23 |
| 28 Jan 2026 |
 SomeoneSerge (back on matrix) | Does computeFSClosure(basicDrv.inputSrcs) + {drvPath} equal computeFSClosure(basicDrv.inputSrcs+ {drvPath}),
where drvPath is that of basicDrv (I didn't yet check how to compute one from the other) | 00:10:43 |
|  GaƩtan Lepage joined the room. | 00:12:30 |
| GaƩtan Lepage | https://github.com/NixOS/hydra/pull/1565 | 00:12:35 |
| GaƩtan Lepage | * Context: https://github.com/NixOS/hydra/pull/1565 | 00:12:43 |
| SomeoneSerge (back on matrix) | * Does computeFSClosure(basicDrv.inputSrcs) + {drvPath} equal computeFSClosure(basicDrv.inputSrcs+ {drvPath}),
where drvPath is that of basicDrv (I didn't yet check how to compute one from the other)
EDIT: Specifically the edge case I'm interested in, is whether copyClosureTo(..., inputSrcs+{drvPath},...) equivalent to the original copyClosureTo(..., inputSrcs, ...) followed by exportPaths(..., {drvPath}), or does it potentially send more
| 00:42:51 |
|  stebalien joined the room. | 14:09:51 |
