| 15 Nov 2022 |
 @linus:schreibt.jetzt | (not sure if he's published it) | 10:59:44 |
| @linus:schreibt.jetzt | hm, it doesn't support adding users to projects though | 11:00:50 |
 aciceri | uhhh interesting, we use terraform actually without terranix) but our Hydra installation is very customized, not sure it's worth using like this but thank for the information 😀 | 11:01:14 |
| aciceri | * uhhh interesting, we use terraform actually (without terranix) but our Hydra installation is very customized, not sure it's worth using like this but thank for the information 😀 | 11:01:25 |
| @linus:schreibt.jetzt | though I'm not sure if Hydra even exposes an API endpoint for it? | 11:01:34 |
 ma27 | In reply to @linus:schreibt.jetzt
as for declarative management of a hydra instance, may I suggest the terraform provider (maintained by my employer but I've been using it since before I worked there :D ) iirc I even advertised it to you although I'm not affiliated with detsys :D | 11:01:54 |
| @linus:schreibt.jetzt | yeah only seems to be in the schema, no controller for it | 11:01:57 |
| ma27 | In reply to @linus:schreibt.jetzt
ma27 has some nice wrapping code that makes it more pleasant to use with terranix not yet but I guess I should... | 11:02:11 |
| @linus:schreibt.jetzt | stick it in a gist, then people won't be able to file issues and PRs so it's less extra work :D | 11:02:46 |
| aciceri | Changing topic. any news about this? https://github.com/NixOS/hydra/pull/1228 | 11:04:33 |
| aciceri | * Changing topic: any news about this? https://github.com/NixOS/hydra/pull/1228 | 11:04:42 |
| aciceri | Perhaps next week I'll be able to spend some hours rebasing it and trying to fix one problem it had | 11:05:46 |
| aciceri | Related: someone here will be at the ocean sprint next week? | 11:07:16 |
|  vdot0x23 joined the room. | 18:52:26 |
| 16 Nov 2022 |
|  @omlet:matrix.org joined the room. | 20:35:36 |
|  @thobys:inpt.fr joined the room. | 22:34:06 |
| 17 Nov 2022 |
|  search-sense joined the room. | 09:18:07 |
| 18 Nov 2022 |
|  @rimuru:gentoo.chat changed their profile picture. | 22:07:41 |
| 25 Nov 2022 |
 terwiz | Just noticed this in Hydra manual: "At the moment, Hydra runs only on GNU/Linux (i686-linux and x86_64_linux)."
So, is it futile attempt to run a hydra slave on an arm server? | 14:44:51 |
| @linus:schreibt.jetzt | terwiz: I've been running it on my (aarch64) honeycomb lx2 for half a year now :) | 14:45:48 |
| @linus:schreibt.jetzt | since https://github.com/NixOS/hydra/pull/1262 merged it's also being built and tested on aarch64 as well | 14:46:04 |
 Rick (Mindavi) | Lol, my hack still going strong 😜 | 14:48:02 |
| terwiz | Ok, thanks | 14:48:20 |
 ajs124 | In reply to @terwiz:matrix.org
Just noticed this in Hydra manual: "At the moment, Hydra runs only on GNU/Linux (i686-linux and x86_64_linux)."
So, is it futile attempt to run a hydra slave on an arm server? slave as in build machine? those can have basically any architecture afaik | 16:12:51 |
| @linus:schreibt.jetzt | Oh yeah missed that. Indeed, if Nix runs on it you're good | 16:17:45 |
|  @tired:fairydust.space joined the room. | 22:04:40 |
| 26 Nov 2022 |
|  @/yvan:matrix.org joined the room. | 18:09:39 |
 magic_rb |
is there any way to deal with hydra eating upwards of 8GB of memory when evaluating my flake? I would like it to build all my systems but 8GB of memory is way too much for that, I think the issue Nix not really GCing that well if I try to `nix eval` all the systems at once, one by one when they're perfectly fine though… | 19:10:42 |
| @linus:schreibt.jetzt | magic_rb: add some swap. Most of that memory isn't actually being used most of the time so it can be swapped out. | 19:15:40 |
| magic_rb |
won't help in my case as cgroup still count it towards the overall usage and it'll get killed anyway, if i increase the limit for the whole container i would then run the risk of OOMing my system due to a really memory intensive build that does actually need the ram actively | 19:16:55 |
