| 15 Jan 2022 |
 angerman | * NIX_PATH=nixpkgs=https://github.com/NixOs/nixpkgs/archive/65c9cc79f1d179713c227bf447fb0dac384cdcda.tar.gz:colmena=https://github.com/zhaofengli/colmena/archive/main.tar.gz nix-instantiate -E 'let eval = import <colmena/src/nix/hive/eval.nix>; hive = eval { rawHive = import ./hive.nix; }; in hive.nodes.helios64.config.system.build.toplevel' keeps segfaulting | 13:40:41 |
| angerman | last thing it prints prior to segfaulting is evaluating file '/nix/store/0gqvlf61cyjavvalfql96jxykrf0q0nb-source/pkgs/build-support/kernel/modules-closure.nix'. | 13:41:03 |
| angerman | GC_DONT_GC... | 13:41:51 |
| angerman | god i hate this nix binary. | 13:41:55 |
 Zhaofeng Li | In reply to @angerman:matrix.org
meta.nixpkgs = import (fetchTarball { ... }); With this there <nixpkgs> in NIX_PATH shouldn't have matterered, but apparently something in the config is trying to use <nixpkgs>. But I think that's a red herring | 13:41:57 |
| angerman | GC_DONT_GC=1 NIX_PATH=nixpkgs=https://github.com/NixOs/nixpkgs/archive/65c9cc79f1d179713c227bf447fb0dac384cdcda.tar.gz:colmena=https://github.com/zhaofengli/colmena/archive/main.tar.gz nix-instantiate -E 'let eval = import <colmena/src/nix/hive/eval.nix>; hive = eval { rawHive = import ./hive.nix; }; in hive.nodes.helios64.config.system.build.toplevel'
trace: warning: The following Nixpkgs configuration keys set in meta.nixpkgs will be ignored: allowBroken allowUnsupportedSystem
warning: you did not specify '--add-root'; the result might be removed by the garbage collector
/nix/store/jaccla0pvhfr9wy5vf4l0kdd1qdr7a26-nixos-system-nixos-20.09pre-git.drv
| 13:42:16 |
| Zhaofeng Li | In reply to @angerman:matrix.org
NIX_PATH=nixpkgs=https://github.com/NixOs/nixpkgs/archive/65c9cc79f1d179713c227bf447fb0dac384cdcda.tar.gz:colmena=https://github.com/zhaofengli/colmena/archive/main.tar.gz nix-instantiate -E 'let eval = import <colmena/src/nix/hive/eval.nix>; hive = eval { rawHive = import ./hive.nix; }; in hive.nodes.helios64.config.system.build.toplevel' keeps segfaulting If you can get a backtrace, that may be valuable in submitting an issue upstream to Nix | 13:42:17 |
| angerman | nix (Nix) 2.5pre20211007_844dd90 | 13:42:41 |
| angerman | I guess I could break out my debugger now, and figure out why the GC keeps failing... or I'll just use GC_DONT_GC for now, and ignore the failure. | 13:43:12 |
| Zhaofeng Li | In reply to @angerman:matrix.org
GC_DONT_GC... Ah, I didn't know about https://github.com/NixOS/nix/issues/4893 | 13:44:03 |
| Zhaofeng Li | Yeah, that is indeed pretty annoying 🙁 | 13:44:28 |
| Zhaofeng Li | But it should be fixed in the release version of 2.5 I guess | 13:44:48 |
| angerman | in this case it does help; I just hate this nix binary for the amount of issues I have with it too much. | 13:44:56 |
| angerman | and for its slowness. | 13:45:22 |
| Zhaofeng Li | Slightly tangential, but 2.5 also has another regression that has yet to be fixed: https://github.com/NixOS/nix/issues/5816 | 13:47:16 |
| angerman | great. and now it fails to find my build... | 13:53:18 |
| angerman | * great. and now it fails to find my builders... | 13:53:21 |
| Zhaofeng Li | It should use whatever is configured in nix.conf, or you can also set it in your config with meta.machinesFile: https://zhaofengli.github.io/colmena/unstable/features/remote-builds.html | 13:55:32 |
| Zhaofeng Li | You can also use deployment.buildOnTarget to have it build on the remote node directly, but if IFD is in play you still need to set builders for evaluation | 13:56:40 |
| angerman | whee, I got it to build. Let's see if it applies. | 14:28:22 |
| angerman | Zhaofeng Li: sorry for the trouble that wasn't even yours really. | 14:28:40 |
| Zhaofeng Li | No worries. I'm always happy to help 🙂 | 14:29:21 |
| angerman | dealing with these kinds of indirect errors is tough. | 14:31:12 |
| Zhaofeng Li | Yeah, especially for segfaults with no immediate cause in sight | 14:35:30 |
| angerman | If you detect a segv from nix, maybe suggest to rerun the command with GC_DONT_GC :-) | 15:02:32 |
| 16 Jan 2022 |
|  kraem set a profile picture. | 09:54:22 |
| 20 Jan 2022 |
|  andi- left the room. | 00:09:12 |
| 22 Jan 2022 |
 @github:maunium.net | [zhaofengli/colmena] CRTified opened
issue
#48: Add `${name}-key.service` unit files for `deployment.keys` entries
This is relevant for nixops-compability, as nixops uses these unit files as an indicator for other services that the key is available.
It's also helpful to prevent services from starting if the key is not available, e.g. in the case of unexpected (or in general external) reboots.
The definition in nixops uses inotifywait, but a path unit might be the more elegant way to solve this.
| 00:24:52 |
|  phaer joined the room. | 09:03:13 |
| phaer | In reply to @buckley310:matrix.org
So I'm curious. In my setup my servers all exist inside of my flake outputs.nixosConfigurations, and my outputs.colmena is just a stub that consumes nixosConfigurations and emits a colmena configuration. Is anyone else doing it this way, or just me? I really like the portability of keeping my hosts in nixosConfigurations I am doing pretty much the same! While I like how you just do inherit (config.sconfig) deployment; to add deployment options, I wonder whether the colmena flake could expose a nixos module which includes the types of all deployment options, so that we could use nixosConfigurations for colmena.$host options directly, without getting an error that deployment options are undefined? | 09:10:26 |
