| 18 May 2022 |
 Jane Jasperous | * i expected declare machines as server1 = inputs.nixpkgs-2205.lib.nixosSystem { (...) to work | 12:29:58 |
 phaer | In reply to @janejasperous:one.ems.host
i expected declare machines as server1 = inputs.nixpkgs-2205.lib.nixosSystem { (...) to work You don't need lib.nixosSystem for colmena, just the config | 15:01:51 |
| phaer | server1 = inputs.nixpkgs-2205.lib.nixosSystem { (...) }.config could also work, i think? But haven't tested this | 15:03:21 |
 CRTified | In reply to @phaer:matrix.org
server1 = inputs.nixpkgs-2205.lib.nixosSystem { (...) }.config could also work, i think? But haven't tested this Kind of - I'm using such a shim to use nixosConfigurations and colmena together: https://github.com/zhaofengli/colmena/issues/60#issuecomment-1047199551 | 15:04:14 |
| phaer | Ah, good to know. I personally just keep my stuff in the nixosModules output of my flake and can then put them into colmena configs for hosts I deploy with colmena or nixosConfigurations as needed | 15:05:44 |
| Jane Jasperous | Effectively im using colmena + nixos-rebuild | 19:57:00 |
| Jane Jasperous | In reply to @phaer:matrix.org
You don't need lib.nixosSystem for colmena, just the config ok that work locally with nixos-rebuild. This piece of code fails becuase overwrite nixpkgs-2205 for nixpkgs | 21:43:00 |
| Jane Jasperous | colmena = {
meta = {
nixpkgs = import nixpkgs { system = "x86_64-linux"; };
specialArgs = { inherit inputs; };
};
} // builtins.mapAttrs (name: value: {
nixpkgs.system = value.config.nixpkgs.system;
imports = value._module.args.modules;
}) (self.nixosConfigurations);
| 21:43:21 |
| Jane Jasperous | In reply to @phaer:matrix.org
You don't need lib.nixosSystem for colmena, just the config * ok that works locally with nixos-rebuild. This piece of code fails makes colmena overwrite nixpkgs-2205 for nixpkgs | 21:43:48 |
| Jane Jasperous | * ok server1 = inputs.nixpkgs-2205.lib.nixosSystem { (...) } that works locally with nixos-rebuild. This piece of code fails makes colmena overwrite nixpkgs-2205 for nixpkgs | 21:44:21 |
| Jane Jasperous | * ok server1 = inputs.nixpkgs-2205.lib.nixosSystem { (...) } works locally with nixos-rebuild. This piece of code fails makes colmena overwrite nixpkgs-2205 for nixpkgs | 21:44:30 |
| Jane Jasperous | * ok server1 = inputs.nixpkgs-2205.lib.nixosSystem { (...) } works locally with nixos-rebuild. This piece of code makes colmena overwrite nixpkgs-2205 for nixpkgs | 21:44:42 |
| CRTified | In reply to @janejasperous:one.ems.host
ok server1 = inputs.nixpkgs-2205.lib.nixosSystem { (...) } works locally with nixos-rebuild. This piece of code makes colmena overwrite nixpkgs-2205 for nixpkgs For that to work, you'll likely also need to use nodeNixpkgs as described in the colmena manual | 22:59:32 |
| 19 May 2022 |
| Jane Jasperous | In reply to @schnecfk:ruhr-uni-bochum.de
For that to work, you'll likely also need to use nodeNixpkgs as described in the colmena manual of course, that works. but duplicate code. Could be interesting colmena accepts nixosSystem.config as is | 08:39:52 |
| CRTified | Maybe I can change my shim a bit 🤔 Might be non-ideal. For example: nodeNixpkgs could probably be populated from nixosConfigurations.hostname.pkgs | 09:10:59 |
|  michaelpj joined the room. | 17:33:16 |
| 21 May 2022 |
|  hanemile joined the room. | 20:31:51 |
| 23 May 2022 |
 David Arnold (blaggacao) | How colmena would look like in a nushell:
colmena | where tag = oakland | each { |it| ^comena deploy ($it.fragment) }
| 05:17:05 |
| David Arnold (blaggacao) | * How colmena would look like in a nushell: (pseudo code)
```nu
colmena | where tag = oakland | each { |it| ^colmena deploy ($it.fragment) }
``` | 05:17:58 |
| 24 May 2022 |
 aanderse | any way to increase debug/error logging for the deployment.keys options? i'm not getting much and i don't know what i'm doing wrong | 20:27:15 |
| aanderse | using keyCommand, btw | 20:27:33 |
 Zhaofeng Li | -v is as far as it can get at the moment, and it should dump stderr from the keyCommand when it fails | 20:53:35 |
| aanderse | ok thanks
i haven't confirmed yet (and my rust-fu isn't good enough to tell simply by looking at the code) but there may be a tiny bug with deployments.keys.<name>.name when <name> and name don't match in the chown
relevant snippets: https://github.com/zhaofengli/colmena/blob/429a0f5aa1d1bac06234e2f0c02d5b63a850d940/src/nix/host/ssh.rs#L289 and https://github.com/zhaofengli/colmena/blob/abb74b9f495a218824c415a7d7cfca88a6c54e7b/src/nix/host/key_uploader.template.sh#L19
feel free to ignore this so i'm forced to level up my rust game and verify+fix this myself
| 20:58:23 |
| Zhaofeng Li | The %DESTINATION% here is templated with key.path() which is generated from the modules which should only care about the latter name | 21:19:08 |
| 26 May 2022 |
|  bl1nk joined the room. | 10:27:32 |
| David Arnold (blaggacao) | Thanks for merging #73 | 19:04:15 |
| David Arnold (blaggacao) | std is still mandating a swappable eval 🙃
I wonder how we can settle this...
Maybe I can convince you avout the nix bundler pattern that does drv -> drv through an official nix CLI interface.
A swappable eval is sort of a contextual move towards a bundler pattern. | 19:06:24 |
| David Arnold (blaggacao) | For example, what I did in std is just attach the tooling meta directly to drv or drv.meta upon which a bundler then can do fantastic stuff through a clean interface. | 19:07:36 |
| David Arnold (blaggacao) | For example, to build a DAG of std targets: drv // { after = [ "othertarget" ]; } | 19:09:27 |
| David Arnold (blaggacao) | Iiirc, the bundler interface, in reality is any -> drv. drv -> drv just being the "common" case | 19:11:28 |
