| 8 Jan 2026 |
 kdn | why are the $KEYS in linux-builder fed through the store? | 16:16:26 |
| kdn | where do I find SSHD logs on MacOS? is there anyting more than /usr/bin/log show --predicate 'process == "sshd"' --info --debug --last 2m? I'm just seeing this error there: [com.apple.network.libinfo:si_destination_compare] send failed: Invalid argument | 20:20:17 |
| kdn | * where do I find SSHD logs on MacOS? is there anyting more than /usr/bin/log show --predicate 'process == "sshd"' --info --debug --last 2m? I'm just seeing this error there: [com.apple.network.libinfo:si_destination_compare] send failed: Invalid argument
on the client side I get permission denied
| 20:30:46 |
| kdn | I can login to my primary user, but not to the additional user | 20:34:54 |
| kdn | I cannot force the password authentication for that user either | 20:40:17 |
| kdn | FYI: /usr/sbin/sshd -ddd -p 2222 was quite helpful, turned out SSHD didn't like the /nix/store permissions, I changed it to this copying and referencing static path:
system.activationScripts.preActivation.text = ''
cp -a ${pkgs.writeShellScript "cat-nofail" ''/bin/cat "$@" || :''} /etc/ssh/authorized-keys-command
'';
| 21:23:12 |
| kdn | is there any way to connect directly to the linux-builder's serial console? | 22:20:13 |
| kdn | FYI: I found it:
virtualisation.qemu.options = [
# socat - UNIX-CONNECT:/run/org.nixos.linux-builder/qemu-serial.sock
# minicom -D 'unix#/run/org.nixos.linux-builder/qemu-serial.sock'
''-serial unix:"$TMPDIR/qemu-serial.sock",server,nowait''
];
| 23:23:37 |
| 9 Jan 2026 |
 Randy Eckenrode |
[1/2] /nix/store/jk2r3w2q06vh7hkfxrw74ckrlrppm6gz-swiftc-6.2.3/bin/swiftc -j 16 -num-threads 16 -c -module-name cmTC_a937f -target arm64-apple-macosx14.0 -sdk /nix/store/i6yfk1parrl2f2m>
FAILED: [code=1] CMakeFiles/cmTC_a937f.dir/main.swift.o
/nix/store/jk2r3w2q06vh7hkfxrw74ckrlrppm6gz-swiftc-6.2.3/bin/swiftc -j 16 -num-threads 16 -c -module-name cmTC_a937f -target arm64-apple-macosx14.0 -sdk /nix/store/i6yfk1parrl2f2mhj96x5>
<unknown>:0: warning: using (deprecated) legacy driver, Swift installation does not contain swift-driver at: '/nix/store/jk2r3w2q06vh7hkfxrw74ckrlrppm6gz-swiftc-6.2.3/bin/swift-driver-new'
<unknown>:0: warning: option '-incremental' is only supported in swift-driver
/nix/store/i6yfk1parrl2f2mhj96x565ijc3lg7xv-apple-sdk-26.0/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/swift/Swift.swiftmodule/arm64e-apple-macos.swiftinterface:5:8: error>
3 | // swift-module-flags: -target arm64e-apple-macosx26.0 -target-variant arm64e-apple-ios26.0-macabi -enable-objc-interop -enable-library-evolution -module-link-name swiftCore -pars>
4 | // swift-module-flags-ignorable: -enable-lexical-lifetimes=false -enable-ossa-modules -strict-memory-safety -formal-cxx-interoperability-mode=off -interface-compiler-version 6.2
5 | import SwiftShims
| `- error: no such module 'SwiftShims'
6 | @inlinable public func min<T>(_ x: T, _ y: T) -> T where T : Swift.Comparable {
7 |
/nix/store/i6yfk1parrl2f2mhj96x565ijc3lg7xv-apple-sdk-26.0/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/swift/Swift.swiftmodule/arm64e-apple-macos.swiftinterface:1:1: error>
1 | // swift-interface-format-version: 1.0
| `- error: failed to build module 'Swift'; this SDK is not supported by the compiler (the SDK is built with 'Apple Swift version 6.2 effective-5.10 (swiftlang-6.2.0.17.14 clang-170>
2 | // swift-compiler-version: Apple Swift version 6.2 effective-5.10 (swiftlang-6.2.0.17.14 clang-1700.3.17.1)
3 | // swift-module-flags: -target arm64e-apple-macosx26.0 -target-variant arm64e-apple-ios26.0-macabi -enable-objc-interop -enable-library-evolution -module-link-name swiftCore -pars>
ninja: build stopped: subcommand failed.
| 01:52:13 |
| Randy Eckenrode | That’s with the separate stdlib. I think I’m going to have to do some patching to make it aware of both the dev and lib outputs in the stdlib package. | 01:52:46 |
| Randy Eckenrode | Yeah. I need to revisit the separate lib patch. I don’t think patching the compiler lookup is the right approach. It’s changing the semantics of the search. I should be augmenting the path. | 02:27:53 |
| Randy Eckenrode | * Yeah. I need to revisit the separate lib patch. I don’t think patching the compiler lookup is the right approach. It’s changing the semantics of the search. I should be augmenting the paths in updateRuntimeLibraryPaths. | 02:28:10 |
|  Ivy joined the room. | 05:49:09 |
