| 19 Mar 2024 |
 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 |
|  @lotte:chir.rs changed their profile picture. | 11:03:24 |
| 21 Mar 2024 |
|  NixOS Moderation Botchanged room power levels. | 18:02:54 |
|  @grahamc:nixos.org left the room. | 20:09:46 |
| 22 Mar 2024 |
| bumperboat changed their display name from bumperboat to bumperboat (UTC+8 when). | 13:27:55 |
| bumperboat changed their display name from bumperboat (UTC+8 when) to bumperboat (UTC+8). | 15:01:25 |
| 24 Mar 2024 |
|  @belak:matrix.org joined the room. | 18:24:50 |
 darkwater4213 | How feasible is self-hosting a Hydra instance? Say I want to deploy to a whole bunch of RISC-V thin clients... I already know what packages I want to be compiled, so is there a way to configure Hydra to only build and serve those? Or am I fundamentally messengering something about Hydra? | 21:51:50 |
| @casey:hubns.net | self hosting hydra is easy. it's probably over kill if you are only intending it to populate a binary cache though. | 23:15:35 |
| 25 Mar 2024 |
| darkwater4213 | For RISC-V? Does the main instance of Hydra compile for RISC-V? | 01:35:59 |
| darkwater4213 | Or ARM? | 01:36:08 |
