| 20 Jan 2024 |
 Lily Foster | yeah, it should be rebuilding that | 15:10:10 |
 cole-h | It's just the same "too many statuses on a given context / SHA" error from GH :(
I opened https://github.com/NixOS/nixpkgs/pull/282387 to simulate another ofborg run that hopefully doesn't run into the same issue | 18:07:34 |
| cole-h | (FWIW, "ofborg-internal-error" label pretty much always means "GitHub sent us an error for something we do in normal operation that prevents further processing", and not "build did something super funky") | 18:10:04 |
 7c6f434c | So, it's basically github-being-flaky label in practice? | 18:22:59 |
| cole-h | Well, I think historically it's more like "GitHub was flaky earlier and now we're paying the price" | 18:26:45 |
| 21 Jan 2024 |
 ris_ | right, problem is it's infinitely recursing into pkgsExtraHardening | 11:10:54 |
| ris_ | aha excluded-toplevel-attrs = { | 11:14:21 |
| ris_ | successful eval! | 12:39:24 |
| 25 Jan 2024 |
|  sheep_empress joined the room. | 19:12:21 |
| sheep_empress | hi! i've been sent here from the nixpkgs group because i'm having a problem with ofborg that i can't replicate on my machine. i'm trying to package a program called autobrr. it's written in go with a web interface built in pnpm+vite+esbuild. i use a derivation to note what version of esbuild i need to grab, and this works on my machine, but ofborg says that it can't build my pr because it thinks this derivation is empty. | 19:24:41 |
| sheep_empress | could somebody help me out? my pull request is here, and the ofborg log that i'm referencing is here. | 19:26:15 |
| cole-h | One issue is that you're using import-from-derivation, which is not allowed in Nixpkgs (so as not to blow up the time it takes to evaluate) | 19:29:38 |
| cole-h | (If you run your build with --option allow-import-from-derivation false, you can see this happening) | 19:30:06 |
| sheep_empress | Ok, thanks, that's good to know that I can't use readFile to get anything from a nix store in nixpkgs. | 19:39:18 |
 K900 | Not "anything" | 19:40:07 |
| K900 | But only outputs of other derivations | 19:40:11 |
| sheep_empress | Am I able to use it to read from the same derivation I'm currently in? | 19:40:50 |
| K900 | No | 19:41:53 |
| K900 | Because you're not in a derivation | 19:41:58 |
| K900 | You're in eval | 19:42:02 |
| sheep_empress | Could you explain what you mean by that? | 19:43:54 |
| K900 | builtins.readFile happens at eval time | 19:44:51 |
| K900 | Nix computes a build plan first, then executes it | 19:45:03 |
| K900 | IFD is bad because you have to compute some build plan, then execute it, then use the output from that to compute more build plan | 19:45:19 |
| K900 | Which is slow and means you can't have a full build plan ahead of time | 19:45:28 |
| sheep_empress | I think part of the problem I'm having might be because I really don't know the full build plan ahead of time. I don't know what version of esbuild the build needs until I've run pnpm | 19:48:18 |
| K900 | Then you need to hardcode it in nixpkgs | 19:48:28 |
| K900 | And update it manually when updating the package | 19:48:34 |
| K900 | Because nixpkgs tooling does need to know the full build plan ahead of time | 19:48:42 |
| sheep_empress | Was worried that was going to be the answer. Thanks for all your help | 19:49:58 |
