| 24 Jun 2022 |
 Linux Hackerman | Not sure a restart is even needed? | 11:04:59 |
 hexa | oh yeah, that sounds neat | 11:05:11 |
| Linux Hackerman | Or yeah a separate service could be cleaner. | 11:05:18 |
| hexa | I can't really be arsed to enumerate the repositories | 11:05:22 |
| hexa | * I can't really be arsed to enumerate the interfaces | 11:05:30 |
| Linux Hackerman | Just reconfigure then :D | 11:05:44 |
| hexa | well, now it feels obvious 😄 | 11:08:14 |
| hexa | I think I was stuck in my head somewhere | 11:08:21 |
| Linux Hackerman | Happens :D | 11:09:32 |
| hexa | ❯ colmena build
[INFO ] Using configuration: /home/hexa/git/hexa/nixos-servers/config/hive.nix
[INFO ] Enumerating nodes...
error: attribute 'type' missing
at /nix/store/agbalx3d9vi1sd132w5qs4p6i3brya1f-nixos-22.05-src/lib/modules.nix:615:26:
614| else if optionDecls != [] then
615| if all (x: x.options.type.name == "submodule") optionDecls
| ^
616| # Raw options can only be merged into submodules. Merging into
Did you mean _type?
(use '--show-trace' to show detailed location information)
[ERROR] -----
[ERROR] Operation failed with error: Child process exited with error code: 1
| 11:28:23 |
| hexa | this is a fun one. | 11:28:34 |
| hexa | because nowhere in the trace there is a reference to the module in question | 11:28:54 |
| hexa | do people tend to write scripts around colmena for:
- apply boot
- reboot
- unlock
- upload secrets
| 13:15:17 |
| hexa | with morph I could do morph deploy default.nix boot --reboot --upload-secrets | 13:15:32 |
| hexa | and colmena seems to upload secrets uploadAt=post-activation on applies with goal=boot directly after uploading the closure | 13:16:39 |
| hexa | which is quite pointless when the secrets are volatile | 13:16:49 |
| hexa | * and colmena seems to upload secrets with uploadAt=post-activation on applies with goal=boot directly after uploading the closure | 13:17:07 |
| hexa | ah, reboot handling is part of 0.4.0 | 13:22:30 |
| hexa | In reply to @linus:schreibt.jetzt
Just reconfigure then :D lol nope. can't reconfigure interfaces that don't exist, because of missing prerequisites | 15:10:01 |
| hexa | so restarting networkd it is | 15:10:05 |
 Zhaofeng Li | In reply to @hexa:lossy.network
and colmena seems to upload secrets with uploadAt=post-activation on applies with goal=boot directly after uploading the closure Yeah, the behavior of uploadAt=post-activation should probably be special-cased for --reboot | 18:06:02 |
| hexa | strictly speaking: activation happens at boot time for goal=boot | 19:18:46 |
| hexa | so don't upload secrets in that case unless --reboot is given | 19:19:14 |
| hexa | * so don't upload post-activiation secrets in that case unless --reboot is given | 19:19:22 |
| hexa | * so don't upload post-activiation secrets in that case unless --reboot is given and then post-reboot 😄 | 19:19:26 |
| 25 Jun 2022 |
 Winter (she/her) | So I'm trying to debug a weird issue.
home-manager revisions, for at least a few months now(???), have failed to build their nmd fetcher derivation when building for x86_64-linux with Colmena's build on target feature, when the system != x86_64-linux. The derivation in question is defined here.
HM commit e66f0ff69a6c0698b35034b842c4b68814440778 suddenly fixes the fetching of this derivation, by merely changing the commit hash. The diff between the failing and the succeeding derivations is just as you'd expect: just the hashes and revisions change, nothing else.
The error that's occurring with these faulty revisions are error: a 'x86_64-linux' with features {} is required to build '/nix/store/7fhf5jvnmz8wpy38v44j5cfn7mgxg7kj-nmd.drv', but I am a 'aarch64-darwin' with features {benchmark, big-parallel, nixos-test} (7f... is failing in the diff). They both have system = x86_64-linux in the derivation, so what's going on?
| 16:55:50 |
| Zhaofeng Li | Another person [encountered the same thing](https://matrix.to/#/!BgJZHVOYkwVcEKLAyM:nixos.org/$pYUmOSAIpDOIbLl4q2TMc-0iyKrimWZfnFQi4Fdm6RA?via=zhaofeng.li&via=matrix.org&via=matrix.eno.space) in the deployment channel. It's a bit weird that it worked before. | 20:58:32 |
| Zhaofeng Li | Is it possible that the original output was cached somehow? | 20:58:55 |
| Winter (she/her) | In reply to @zhaofeng:zhaofeng.li
Is it possible that the original output was cached somehow? That was my thought too, but then I GC'd my store and can still reliably reproduce this. | 21:47:06 |
| Winter (she/her) | In reply to @zhaofeng:zhaofeng.li
Is it possible that the original output was cached somehow? * That was my thought too. | 21:47:39 |
