| 23 Jan 2022 |
Zhaofeng Li | Basic support for nix-eval-jobs has landed in the main development branch, enabling true parallel evaluation that is also memory efficient. You can give it a try by passing --evaluator streaming and nix-eval-jobs will be used as the evaluator, spawning separate workers to evaluate nodes at the same time. | 02:15:07 |
Zhaofeng Li | So far the biggest issues I see with nix-eval-jobs mainly have to do with IFD. Builds triggered by IFDs cannot be easily cancelled, and there is no support for remote builders with IFD. | 02:15:19 |
@github:maunium.net | [zhaofengli/colmena] phaer synchronize
pull request
#49: eval.nix: expose nixosModules.deploymentOptions | 09:01:18 |
| Linux Hackerman is moving: @linus:schreibt.jetzt joined the room. | 14:38:08 |
@github:maunium.net | [zhaofengli/colmena] lheckemann approved
pull request
#49: eval.nix: expose nixosModules.deploymentOptions | 14:41:42 |
@github:maunium.net | [zhaofengli/colmena] zhaofengli merged
pull request
#49: eval.nix: expose nixosModules.deploymentOptions | 18:06:42 |
Linux Hackerman is moving: @linus:schreibt.jetzt | Is there a way to override an input flake like with the --override-flake nix option? | 19:03:09 |
Zhaofeng Li | Currently no, but we can add one. Looks like the argument is part of the common eval args in Nix, and accepted by both nix-instantiate and nix-eval-jobs | 19:06:24 |
Linux Hackerman is moving: @linus:schreibt.jetzt | er, I think I meant --override-input not --override-flake | 19:15:14 |
Zhaofeng Li | Looks like I got them mixed up as well. --override-input is the useful one and it's not available in nix-instantiate or nix-eval-jobs. For flakes mode we could look into using nix eval --apply to evaluate, though I doubt our current setup would work in the pure evaluation mode. | 19:19:05 |
| 25 Jan 2022 |
@github:maunium.net | [zhaofengli/colmena] JCapucho opened
issue
#50: Nixpkgs fails to build on unstable
Hi, I'm using colmena with a flake to build a node that uses the nixos-unstable branch of nixpkgs (commit is https://github.com/NixOS/nixpkgs/commit/689b76bcf36055afdeb2e9852f5ecdd2bf483f87), but it's failing to build.
In the start of the log I see a warning with
capucho-nixos | trace: warning: The following Nixpkgs configuration keys set in meta.nixpkgs will be ignored: path
Which leads me to believe that the issue might be caused by ignoring the path attribute introduced in https://github.com/NixOS/nixpkgs/pull/153594
Here's the log of running colmena build --show-trace --verbose
log.txt
| 13:54:48 |
Linux Hackerman is moving: @linus:schreibt.jetzt | Is there a way to pass the flake inputs on to all machine configs? I'd like to do things like imports = [ "${inputs.nixos-mailserver}/default.nix" ]; in my machine configs. | 15:39:18 |
Linux Hackerman is moving: @linus:schreibt.jetzt | Additionally I'd like to be able to access the flakeInfo of the nixpkgs used to build the individual machine. I currently have the problem that the system version metadata is basically useless (nixos-version says 21.11pre-git and nixos-version --hash doesn't know anything). | 15:41:47 |
Buckley | could be done with an overlay | 15:42:26 |
Buckley | In reply to @buckley310:matrix.org
the stub:
colmena =
{ meta.nixpkgs = nixpkgs.legacyPackages."x86_64-linux"; } //
builtins.mapAttrs
(name: value: {
nixpkgs.system = value.config.nixpkgs.system;
imports = value.extraArgs.modules ++ [
({ config, ... }: { inherit (config.sconfig) deployment; })
];
})
(nixosConfigurations);
FWIW, my colmena machines have the correct nixpkgs info instead of the pre-git thing, because i build them in nixosConfigurations and then shim them into colmena | 15:45:59 |
Buckley | $ nixos-version
21.11.20211229.8588b14 (Porcupine)
| 15:46:43 |
Linux Hackerman is moving: @linus:schreibt.jetzt | In reply to @buckley310:matrix.org
the stub:
colmena =
{ meta.nixpkgs = nixpkgs.legacyPackages."x86_64-linux"; } //
builtins.mapAttrs
(name: value: {
nixpkgs.system = value.config.nixpkgs.system;
imports = value.extraArgs.modules ++ [
({ config, ... }: { inherit (config.sconfig) deployment; })
];
})
(nixosConfigurations);
hm, why do you set nixpkgs.system again? Shouldn't imports already take care of that? | 17:41:43 |
Buckley | i originally thought so, but if i remove that line my pi doesnt deploy right | 17:42:22 |
Linux Hackerman is moving: @linus:schreibt.jetzt | I also don't see how that will play along with use of meta.nodeNixpkgs | 17:42:25 |
Linux Hackerman is moving: @linus:schreibt.jetzt | that is, if I use meta.nodeNixpkgs it will deploy using the nixpkgs I want it to, but have an incorrect version string | 17:44:49 |
[0x4A6F] | Linux Hackerman: something along this in flake outputs?
colmena.defaults = {
system.nixos.version = "nixos-${nixpkgs.shortRev}";
};
| 17:45:10 |
Linux Hackerman is moving: @linus:schreibt.jetzt | In reply to @linus.heckemann:matrix.mayflower.de that is, if I use meta.nodeNixpkgs it will deploy using the nixpkgs I want it to, but have an incorrect version string [0x4A6F]: that also has ^ this problem | 17:45:36 |
Buckley | In reply to @linus.heckemann:matrix.mayflower.de that is, if I use meta.nodeNixpkgs it will deploy using the nixpkgs I want it to, but have an incorrect version string not sure. i dont use meta.nodePackages. | 17:46:04 |
Buckley | In reply to @linus.heckemann:matrix.mayflower.de that is, if I use meta.nodeNixpkgs it will deploy using the nixpkgs I want it to, but have an incorrect version string * not sure. i dont use meta.nodeNixpkgs | 17:46:42 |
Zhaofeng Li | In reply to @linus.heckemann:matrix.mayflower.de that is, if I use meta.nodeNixpkgs it will deploy using the nixpkgs I want it to, but have an incorrect version string Hmm, interesting. Do you have a minimal repro? Or I can try doing it sometime today | 18:26:09 |
Zhaofeng Li | In reply to @linus.heckemann:matrix.mayflower.de Is there a way to pass the flake inputs on to all machine configs? I'd like to do things like imports = [ "${inputs.nixos-mailserver}/default.nix" ]; in my machine configs. You can pass the inputs using either meta.specialArgs.inputs = inputs; or _module.args.inputs = inputs; in a node config | 18:27:23 |
Zhaofeng Li | Then inputs will be available as a NixOS module parameter. You can also go the overlays way, though. | 18:28:09 |
Linux Hackerman is moving: @linus:schreibt.jetzt | In reply to @zhaofeng:zhaofeng.li You can pass the inputs using either meta.specialArgs.inputs = inputs; or _module.args.inputs = inputs; in a node config I tried the latter, it resulted in infinite recursion in combination with imports = [ inputs.nixos-mailserver ]; | 19:36:43 |
Linux Hackerman is moving: @linus:schreibt.jetzt | maybe specialArgs doesn't have that problem though? I'll give it a try | 19:36:59 |
Linux Hackerman is moving: @linus:schreibt.jetzt | also, a feature I'd like in colmena: the ability to pass in nixos evaluations rather than nixos configs. That would open up a lot of possibilities, including a nixus-like system where the whole deployment can be made of nixos modules too. Not sure if that goes within the "vision" of colmena though, and if not that's fine --- I don't want colmena to succumb to feature creep either :) | 19:48:12 |