| 4 Aug 2025 |
jonhermansen | Ah, colmena.cli.rs is back! | 15:53:14 |
dantefromhell | In reply to @zsuper:matrix.org and disko will still take care of formatting for you right? because thats the main part about minimal installers that im still uncomfortable with yes. you can force this using nixos-anywheres --phases parameter. also rly helpful for testing 👍 | 18:46:43 |
| 5 Aug 2025 |
| sinan changed their profile picture. | 03:58:54 |
| sinan | 03:58:56 |
| 6 Aug 2025 |
@freexploit:trafkin.com | Redacted or Malformed Event | 14:38:37 |
zsuper | actually yeah, im wondering the same thing. im using deploy-rs right now, but i like that colmena directly exposes the nixosConfigurations so i can debug them, unlike deploy-rs. however, i do really like the canary feature of deploy-rs, where it will magic rollback if the target becomes unreachable | 18:25:27 |
zsuper | * actually yeah, im wondering the same thing. im using deploy-rs right now, but i like that colmena directly exposes the nixosConfigurations so i can debug them, unlike deploy-rs. however, i do really like the canary feature of deploy-rs, where it will magic rollback if the target becomes unreachable. does colmena have something similar? | 18:25:40 |
| 7 Aug 2025 |
zsuper | im thinking of making the switch to colmena soon, but seeing the use of the function colmena.lib.mkHive worries me. will i still be able to access the raw nixosConfiguration closure in the flake's outputs?
the reason i ask is because nixos-anywhere reads nixosConfigurations.<name> when remote installing to a new machine, and id like to write the spec for each node/machine once in the flake and then have its NixOS configuration attribute set accessible
| 06:15:10 |
zsuper | for example, with deploy-rs right now, i managed to write a helper function that allows me to define nodes like:
{
deploy = {
user = "root";
sshUser = "root";
nodes = self.armada.mkNodes {
thinkpad = {
hostname = "10.0.0.162";
system = "x86_64-linux";
modules = [
./modules/mc-server-host
./modules/cluster-server
./modules/starfish
];
};
t5 = {
hostname = "10.0.0.249";
system = "x86_64-linux";
modules = [
./modules/cluster-agent
./modules/adguardhome
];
};
t4 = {
hostname = "10.0.0.23";
system = "x86_64-linux";
modules = [
./modules/cluster-agent
];
};
};
};
but this simply passes the inner arguments to lib.nixosSystem, which in turn gets passed to deploy.nodes.<name>.profiles.system.path. So this means I cannot access the "config" of thinkpad, for example
| 06:17:39 |
zsuper | ooh wait, colmena does have this exact feature! | 07:04:59 |
zsuper | RTFM moment 😔 | 07:05:09 |
| 8 Aug 2025 |
| problems changed their profile picture. | 02:30:14 |
| sinan changed their profile picture. | 06:11:32 |
| 0x4A6F joined the room. | 07:00:51 |
| 9 Aug 2025 |
| seapat set a profile picture. | 14:23:49 |
| 10 Aug 2025 |
Bonus | I'm having trouble deploying from amd64 to an arm64 machine. Seems like colmena build --on kaldir --build-on-target ignores both --build-on-target and colmena.kaldir.deployment.buildOnTarget properties. Any hints what could cause this?
error: a 'aarch64-linux' with features {} is required to build '/nix/store/7qk9db8vr6hkav0q3hkdbd742dz70zd3-cabal2nix-arion-compose.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test, uid-range} | 20:23:29 |
Zhaofeng Li | arion probably uses import-from-derivation (IFD), meaning that it triggers a build during evaluation | 20:25:43 |
Zhaofeng Li | and --build-on-target only sends the derivation to the remote machine after evaluation | 20:26:22 |
Bonus | ah, seems correct. nix flake check also fails now. | 20:27:02 |
| 12 Aug 2025 |
seaweed salad | Any tips getting --show-trace to work? | 20:06:47 |
seaweed salad | sudo nix run "github:zhaofengli/colmena" -- --show-trace apply-local --show-trace build - v is the most recent version I've tried. Obviously tried it once in both positions too. | 20:08:42 |
Zhaofeng Li | Hmm, it should work. What are you getting right now? | 20:22:58 |
seaweed salad | I get the rest of the build output (from verbose), just none of the nix trace showing exactly why stylix isn't working | 20:42:54 |
seaweed salad | Sorry only have matrix on mobile right now so limited on what I can paste. | 20:43:36 |
seaweed salad | Either way just figured out the module that was breaking so its kind of a moot point (for now). Stylix is a persistent headache when updating nixos versions. | 20:46:14 |
seaweed salad | Still trying to make it to 25.05. Here's two runs with/without traces they are the same https://plik.kernelpanic.cafe/#/?id=vWIBIUqJmF1Wbbb2 | 23:32:00 |
| 13 Aug 2025 |
Zhaofeng Li | Ah, it's a build-time error and --show-trace won't give you more information | 00:46:37 |
Zhaofeng Li | In this case, it actually looks like the nix store is corrupted: | 00:46:51 |
Zhaofeng Li | desk | /nix/store/xlrkz8l95f4vw9ahn0q47cz35mm4jpc1-shared-mime-info-2.4/bin/update-mime-database: error while loading shared libraries: /nix/store/y3nxdc2x8hwivppzgx5hkrhacsh87l21-glib-2.84.3/lib/libglib-2.0.so.0: file too short
| 00:47:02 |
Zhaofeng Li | try sudo nix-store --verify --check-contents --repair | 00:47:52 |