| 14 May 2024 |
leo60228 | annoyingly basically no compatible coolers exist, if you buy the motherboard together with a CPU it comes with a 2U passive cooler, alphacool makes a compatible waterblock, and noctua has two coolers listed on their website but just say to contact their b2b sales address if you want to buy one | 02:12:49 |
samrose | In reply to @darkkronicle:jpxs.io (Let me know if I should ask this question somewhere else). Is there a way to debug why Lix is building from source and not using the binary cache? It installs just fine, just wondering if it's on my end. I added the substituter to my substituter list and double checked the public key. (My current version is 2.90.0-beta.1-lixpre20240506-b6799ab). Each time it builds it gives me a different hash, so maybe I have a weird dependency issue? When I nix build -L in the root of the source repo, I just see the same version each time, and uses the build from cache (although I have not replaced nix with lix on the same machine I built it on) | 02:40:35 |
DarkKronicle | Maybe it's because I'm using nixpkgs unstable? | 02:42:16 |
samrose | are you installing lix from nixpkgs is that right? | 02:44:04 |
DarkKronicle | inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
lix = {
url = "git+https://git@git.lix.systems/lix-project/lix?ref=refs/tags/2.90-beta.1";;
flake = false;
};
lix-module = {
url = "git+https://git.lix.systems/lix-project/nixos-module";;
inputs.lix.follows = "lix";
inputs.nixpkgs.follows = "nixpkgs";
};
...
}
| 02:46:33 |
samrose | fwiw there is only one commit of lix in nixpkgs-unstable so I don't believe using nixpkgs-unstable is a factor https://github.com/NixOS/nixpkgs/commits/nixpkgs-unstable/pkgs/tools/package-management/lix/default.nix | 02:48:40 |
samrose | oh wait, you are sourcing lix from the upstream source ok | 02:49:18 |
DarkKronicle | ohhh I didn't realize it existed as a package on nixpkgs yet | 02:49:33 |
DarkKronicle | I'll probably just switch to that then :p | 02:49:43 |
samrose | someone mentioned earlier that the nixpkgs version may lag behind a bit | 02:50:24 |
DarkKronicle | Hmm ok. So the binary cache is built with the latest nixpkgs stable release then? | 02:51:18 |
samrose | https://matrix.to/#/!9IQChSjwSHXPPWTa:lix.systems/$V1dsy1Ni0XPj4DAz06RY8j3BcaEoJFBeERONLReRWEw?via=lix.systems&via=matrix.org&via=auxolotl.org | 02:51:20 |
samrose | In reply to @puck:puck.moe The version of Lix in nixpkgs will likely lag behind by a bit; and the dedicated overlay/module will build other packages that depend on Nix with Lix as well; which doesn't happen in nixpkgs. this message sorry ^^ | 02:52:31 |
samrose | but it may make it easier in the short term | 02:52:47 |
samrose | to use lix | 02:52:50 |
samrose | (installing from nixpkgs may make it easier I mean) | 02:54:14 |
DarkKronicle | That makes sense, I'll probably still use the module, but may switch to have it follow stable to be able to use the cache. Since this follows stable (https://git.lix.systems/lix-project/lix/src/branch/main/flake.nix#L5). Thanks for the help! Really looking forward to this project | 02:57:37 |
| easrng changed their profile picture. | 03:18:18 |
Qyriad | yeah Lix's own binary cache is very scuffed right now, largely because we don't have it in CI yet (working on it) | 05:10:36 |
Qyriad | thankfully Lix is not too terrible to build; it's not like building LLVM or even Python | 05:10:52 |
@drupol:matrix.org | Just so you know, yesterday I did a quick demo of Lix to the Nix Meetup in Brussels :) | 08:00:48 |
toastal-matrix-sucks | How does lix play with pkgs.nixVersion.*? | 08:41:48 |
toastal-matrix-sucks | * How does lix play with pkgs.nixVersions.*? | 08:42:05 |
Qyriad | the overlay sets stable and nix_2_18 to Lix | 08:55:31 |
| joegilkes joined the room. | 10:03:50 |
samrose | In reply to @raitobezarius:matrix.org It can be Nix scheduler, can be Hydra scheduler, there's multiple possible designs and paths I am exploring creating a replacement for nomad, vault, and consul with a combo of postgrest, and an elixir agent on machine + elixir middleware doing dynamic scheduling (targeting only microvm.nix ). I am actually prototyping it with supabase, but trying to make it so that it’ll just work with postgrest too. I am making temporal.io an optional component in this too (to handle complicated queue and workflow). Might not be useful for hydra ng but sharing in any case | 12:14:39 |
K900 | I don't think it's the kind of thing we need for Hydra | 12:17:26 |
K900 | But sounds interesting | 12:17:31 |
K900 | But Hydra is not a typical cluster workload because it's a huge DAG of batch jobs | 12:18:06 |
K900 | That have wildly different resource profiles | 12:18:36 |