| 17 Aug 2023 |
 @infinisil:matrix.org | Hmm my initial guess is just more | 23:16:09 |
 cole-h | If you remind me tomorrow (well, my tomorrow) I can pull out the bisect log I did a month or two ago | 23:16:34 |
 Lily Foster | In reply to @lily:lily.flowers
(and like 64G of memory!) (I can't even test the outpaths on any system I have access to aside from the aarch64-linux community builder. Which I'm not entirely convinced isn't due to something about how outpaths.nix is structured, but I haven't dove into it) | 23:16:42 |
| cole-h | But meta checks are expensive these days | 23:16:59 |
| @infinisil:matrix.org | Ooof.. https://github.com/NixOS/nixpkgs/pull/177272 | 23:17:18 |
| cole-h | Yes that one, I think that was one of the larger bumps | 23:17:45 |
| @infinisil:matrix.org | (that one isn't merged but it adds more meta checks) | 23:17:59 |
| cole-h | Oh then there was another one x) | 23:18:14 |
| cole-h | I saw check-meta and jumped haha | 23:18:24 |
 piegames | We need more meta checks, not less | 23:23:30 |
| piegames | In reply to @infinisil:matrix.org
Ooof.. https://github.com/NixOS/nixpkgs/pull/177272 But review form the OfBorg side on this one would still be appreciated, because it modifies stuff with a "keep in sync with stuff hard-coded in OfBorg" comment above it. Although I couldn't find anything relevant in the OfBorg code base | 23:24:49 |
| piegames | * <mx-reply><blockquote><a href="https://matrix.to/#/!sBfrWMVsLoSyFTCkNv:nixos.org/$kuAqGSPeZHdC_oU4pviRsMgTrwxHrqfdN5BpdK-1nOs?via=matrix.org&via=nixos.dev&via=nixos.org">In reply to</a> <a href="https://matrix.to/#/@infinisil:matrix.org">@infinisil:matrix.org</a><br />Ooof.. https://github.com/NixOS/nixpkgs/pull/177272</blockquote></mx-reply> But review form the OfBorg side on this one would still be appreciated, because it modifies stuff with a "keep in sync with stuff hard-coded in OfBorg" comment above it. Although I couldn't find anything related in the OfBorg code base | 23:25:20 |
| piegames | * But review form the OfBorg side on this one would still be appreciated, because it modifies stuff with a "keep in sync with stuff hard-coded in OfBorg" comment above it. Although I couldn't find anything related in the OfBorg code base | 23:26:11 |
| @infinisil:matrix.org | Btw I really said oof for that one because I still had it in mind that it enabled meta checks for all packages. But for one, it doesn't anymore, and for another, ofborg does meta checks anyways even if it's off by default | 23:26:12 |
| @infinisil:matrix.org | I don't think it's that problematic, it just adds a bit more meta checks | 23:26:34 |
| @infinisil:matrix.org | Maybe a permanent fix should be a way to only evaluate what changed for a PR | 23:29:27 |
| piegames | Not sure to which extent this is feasible, given the spooky-action-at-a-distance nature of Nixpkgs fix points | 23:30:27 |
| @infinisil:matrix.org | Nix does know which files get accessed underneath, see nix-build '<nixpkgs>' -A hello -v | 23:31:14 |
| Lily Foster | In reply to @infinisil:matrix.org
Maybe a permanent fix should be a way to only evaluate what changed for a PR So like only doing meta checks for outpaths that's changed, or something else? If so, meta could still be changed without outpath changing | 23:31:19 |
| @infinisil:matrix.org | In reply to @infinisil:matrix.org
Nix does know which files get accessed underneath, see nix-build '<nixpkgs>' -A hello -v Do this for each attribute once, then for each commit/PR, only re-evaluate it if the commit changed any of those paths | 23:31:57 |
| Lily Foster | In reply to @infinisil:matrix.org
Nix does know which files get accessed underneath, see nix-build '<nixpkgs>' -A hello -v Ah so which files Nix touches at all. That could maybe be done, but I'm not sure it would be faster.... | 23:32:21 |
| @infinisil:matrix.org | This should definitely be faster! | 23:33:03 |
| piegames | My gut feeling says one could still come up with edge cases where this does not work | 23:33:06 |
| @infinisil:matrix.org | Changing files only leaf packages need will only cause those leaf packages to need re-evaluation | 23:33:16 |
| @infinisil:matrix.org | In reply to @piegames:matrix.org
My gut feeling says one could still come up with edge cases where this does not work Same, but I imagine we could implement a more resilient thing rather than nix-build -v :P | 23:33:40 |
| Lily Foster | In reply to @infinisil:matrix.org
This should definitely be faster! Okay I'll trust your claim then, I'm admittedly a bit tired and distracted right now and not fully grasping what you are suggesting 😅 | 23:33:52 |
| @infinisil:matrix.org | Like, I know you can detect filesystem access with inotifywait or similar tools | 23:33:52 |
| @infinisil:matrix.org | fuse filesystems work too | 23:34:01 |
| @infinisil:matrix.org | I could probably come up with a hacky but reliable way to do that in a day | 23:34:30 |
| piegames | This should be a proper Nix eval API instead then | 23:35:25 |
