Hydra | 376 Members | |
| 109 Servers |
| Sender | Message | Time |
|---|---|---|
| 15 Oct 2023 | ||
| Well, kinda | 11:56:12 | |
| But we don't need it on the hot path | 11:56:17 | |
In reply to @k900:0upti.meBut who will do that | 16:27:04 | |
| Like, who will actually write the code? | 16:27:28 | |
| Or what part of Hydra will do that thing | 16:27:35 | |
In reply to @k900:0upti.meYes | 16:27:53 | |
| Yeah that's kind of the problem with everything | 16:28:07 | |
| Apart from performance i would (ftom my perspective) focus rather on robustness. I am sure som current issues might just be craft issues. | 17:43:35 | |
| * Apart from performance i would (from my perspective) focus rather on robustness. I am sure some current issues might just be craft issues. | 17:43:59 | |
In reply to @k900:0upti.meEspecially with proposals like rewrite from scratch to make it better (ideally in a different language). | 17:48:55 | |
In reply to @woobilicious:matrix.orgWhat you are probably missing in the discussion is that we also need people to understand and read the code, so we use a Haskell web framework, who are the people who are committing to work on this and teach people on how to work on this? I don't believe it's a good strategy from a maintenance standpoint, we are trying to get out of Perl, I don't think going into Haskell will do any good | 23:41:58 | |
| And I+1 the discussion on who will do that | 23:42:39 | |
| And I think the key to "who will do that" is to not rewrite from scratch to make it better and reuse the existing stuff and rewrite it slowly while being compatible to make it easier to hack on, which is usually a task that people doesn't like to do but is unfortunately necessary | 23:43:06 | |
| Rust is probably a programming language that Nix community is close to, which can handle the web workload, has sane things in a lot of areas and we can interop with Nix quite easily with it given the current advances on the C FFI | 23:44:00 | |
| I also don't care if this is Python | 23:44:08 | |
| 16 Oct 2023 | ||
| Is there a way to increase build timeouts globally? Our build server emulates x86_64 on AArch64 and large packages like OpenCV with CUDA can take around two days to build. It'd be great if there was a way to tell Hydra to scale up timeouts by 3x. | 22:40:33 | |
| The first thing that comes to mind is something like this
| 23:01:23 | |
| * The first thing that comes to mind is something like this
| 23:01:32 | |
| 17 Oct 2023 | ||
| In some use cases it might be easy to add meta attributes everywhere on the nix side. | 10:39:48 | |
Say, if we modified stdenv.mkDerivation in nixpkgs, it would cover basically all the builds, but there are other ways, too. | 10:41:13 | |
* Say, if we modified stdenv.mkDerivation in nixpkgs, it would cover basically all the builds, but there are other nix-expression ways, too. | 10:41:30 | |
| 13:17:23 | ||
| 13:19:44 | ||
| 21:51:26 | ||
| 19 Oct 2023 | ||
In reply to @vcunat:matrix.orgYep, but I don't want this to apply to any Hydra instance - just our slow one. | 22:53:05 | |
| 21 Oct 2023 | ||
did hydra get the feature where i could --reference-lock-file? or still not | 14:37:02 | |
| answering for myself, no it didnt | 14:46:57 | |
| 14:49:03 | ||
| 22 Oct 2023 | ||
| 20:01:29 | ||
| 23 Oct 2023 | ||
| 09:50:17 | ||