| 19 Mar 2024 |
 K900 | Somewhere | 17:07:42 |
 ElvishJerricco | it's just a GHC build so it's within what I find acceptable | 17:07:48 |
| ElvishJerricco | ugh this is the biggest problem with hydra. Zero documentation, even for basic shit like "how do I increase the size limit" | 17:08:47 |
| ElvishJerricco | after grepping some code, I think it's max_output_size in the config file | 17:14:22 |
| ElvishJerricco | nixos's infra is open source, isn't it? I'm guessing it sets max_output_size somewhere? | 17:18:23 |
 ma27 | https://github.com/NixOS/infra/blob/33c54eca931a3435776308f8117850dda5912b48/delft/hydra.nix#L58 | 17:18:56 |
| ElvishJerricco | huh, only 3GB | 17:19:41 |
 @casey:hubns.net | fwiw, these were my tunings back when i was using hydra and it was creating (larger) disk images:
462 max_output_size = ${builtins.toString (1024 * 1024 * 1024 * 16)}
463 #512 megs of logs
464 max_log_size = ${builtins.toString (1024 * 1024 * 512)}
465 #nar_buffer_size = ${builtins.toString (1024 * 1024 * 1024 * 6)}
| 17:19:43 |
| ElvishJerricco | so I guess GHC is really cutting it close | 17:19:46 |
| ElvishJerricco | cransom: What is nar_buffer_size? | 17:20:25 |
| ma27 | IIRC it was increased for ghc in the past already? | 17:20:36 |
| ElvishJerricco | * huh, only 3GiB | 17:20:48 |
| @casey:hubns.net | that's a good question. its commented out so it seems i didn't need it. | 17:20:49 |
| ElvishJerricco | it doesn't grep in the hydra repo so maybe it's an old thing that got removed | 17:21:19 |
| ElvishJerricco | In reply to @ma27:nicht-so.sexy
IIRC it was increased for ghc in the past already? oof | 17:21:29 |
| ElvishJerricco | actually... nix path-info -h -s says GHC is only 1.7G, which is below the default max_output_size | 17:23:32 |
| ElvishJerricco | so that's weird | 17:23:38 |
| ElvishJerricco | yea, even the build in my hydra is 1.6G, which is unexpectedly slightly smaller, but more importantly still below the default max_output_size of 2 << 30 | 17:27:43 |
| ElvishJerricco | I guess we'll see if increasing max_output_size to 16G does the trick | 17:29:09 |
| @casey:hubns.net | i also ran into hijinx with auto-optimise-store with reporting output sizes, if you have that enabled. though, iirc, that was with disk image projected size rather than general outputs. or if you might be running a compressed fs | 17:40:10 |
| ElvishJerricco | cransom: hm that might be confusing things | 17:52:26 |
| ElvishJerricco | hard to say | 17:52:30 |
| ElvishJerricco | dammit I still got the output limit error | 20:16:42 |
| ElvishJerricco | does it cache the error, regardless of if the conf conditions change? | 20:17:13 |
| ElvishJerricco | how could I fix that? | 20:17:18 |
| ElvishJerricco | fuck I'm going to build on staging aren't I | 20:17:54 |
| ma27 | aren't failures cached (as well as successes) in Hydra as long as the drv doesn't change?
not sure what you're up to, but the cheapest trick is probably to just add another env var to the drv to force a rebuild. | 21:06:18 |
 @linus:schreibt.jetzt | In reply to @ma27:nicht-so.sexy
IIRC it was increased for ghc in the past already? Specifically for GHC on ARM, if I'm remembering right, because it's much bigger for reasons | 21:50:02 |
|  bumperboat set a profile picture. | 22:20:52 |
| 20 Mar 2024 |
 @rick:matrix.ciphernetics.nl | https://github.com/NixOS/nixpkgs/pull/297392, would be great if someone could check what's going wrong here, haven't looked very deeply. But hydra seems to be running fine on my end with that change. | 09:24:50 |
