| 22 Jan 2026 |
 Ivy | but it requires compilation of shaders | 11:32:10 |
 Randy Eckenrode | Signing with a developer cert isn’t really supported. | 11:40:59 |
| Randy Eckenrode | Disable pre-compilation or compile them offline and vendor the resulting files. | 11:41:39 |
|  @enzime:nixos.dev left the room. | 15:02:09 |
| 23 Jan 2026 |
| Randy Eckenrode | My current thinking on handling the stdlib is to make Swift first look for an environment variable NIX_STDLIB_RUNTIME_${swift_tuple} then fall back to looking by path. However, I need to dig into the Swift code to make sure that is possible. If so, it would allow for multiple, target-dependent stdlibs to Just Work™. | 01:11:17 |
| Randy Eckenrode | * My current thinking on handling the stdlib is to make Swift first look for an environment variable NIX_SWIFT_STDLIB_RUNTIME_${swift_tuple} then fall back to looking by path. However, I need to dig into the Swift code to make sure that is possible. If so, it would allow for multiple, target-dependent stdlibs to Just Work™. | 01:11:37 |
| Randy Eckenrode | Note: No NIX_SWIFT_STDLIB_RUNTIME_FOR_BUILD or FOR_TARGET stuff. The tuple will be a platform property that the stdlib’s hook will use to set the variable. | 01:12:13 |
| Randy Eckenrode | That should allow me to avoid wrappers and allow the same swiftc to support multiple -target platforms. | 01:12:37 |
| Randy Eckenrode | It would be nice if we can set those up like the SDK, but I’m skeptical, and it doesn’t work right for Darwin due to having multiple SDKs (the Swift stdlib and the standard, Apple one). | 01:13:18 |
| Randy Eckenrode | * My current thinking on handling the stdlib is to make Swift first look for an environment variable NIX_SWIFT_STDLIB_RUNTIME_${swift_triple} then fall back to looking by path. However, I need to dig into the Swift code to make sure that is possible. If so, it would allow for multiple, target-dependent stdlibs to Just Work™. | 01:51:34 |
| Randy Eckenrode | I am going to explore SDKs though. There is some neat stuff with toolchains, but will it work? | 01:51:46 |
| Randy Eckenrode | For some reason, swift build is only using the linker in my toolset configuration. | 03:11:23 |
| Randy Eckenrode | That’s not very helpful. | 03:11:35 |
| Ivy | like link them into zig cache? | 03:12:46 |
| Randy Eckenrode | No idea for Zig. https://github.com/NixOS/nixpkgs/blob/b494a615768aac2f4b0e2839fd23ec02236368fa/pkgs/tools/security/pinentry/mac.nix is an example of a package that does it for .nib files with xcbuild to avoid depending on ibtool. I assume something could be done similarly for Zig. | 03:19:22 |
| Randy Eckenrode | After messing with it for a bit, I don’t think Swift SDKs are going to do what we need. Swift doesn’t pick up the toolchain stuff from it. We’d have to merge the Swift stdlib and Darwin SDK to make it work on Darwin. It also seems to get funny ideas about triples and deployment targets. | 03:44:31 |
|  @buttergrillcorn:matrix.org left the room. | 17:42:13 |
 Sarah Clark | Heads-up: with the latest staging merge into master, nix-manual only builds on Darwin with the sandbox off.
> error: filesystem error: in posix_stat: failed to determine attributes for the specified path: Operation not permitted ["/nix/var/nix/profiles/per-user/root/channels/nixpkgs"]
>
> [9/148] Generating source/command-ref/experimental-features-shortlist.md with a custom command (wrapped by meson to set env, to capture output)
> [10/148] Generating source/store/types with a custom command (wrapped by meson to set env)
> [11/148] Generating source/command-ref/conf-file.body.md with a custom command (wrapped by meson to set env, to capture output)
> [12/148] Generating source/command-ref/new-cli with a custom command (wrapped by meson to set env)
> ninja: build stopped: subcommand failed.
For full logs, run 'nix log /nix/store/9n8f9fa8ifdjpqxfj0wqc6hdwms1fchw-nix-manual-2.31.3.drv'.
| 18:26:21 |
|  vczf changed their profile picture. | 18:47:01 |
| 24 Jan 2026 |
|  kra3 joined the room. | 14:06:38 |
| 25 Jan 2026 |
|  kfiz left the room. | 07:00:06 |
| kfiz joined the room. | 07:00:25 |
|  Contact @rappet:rappet.xyz instead (I will not respond here) changed their display name from Contact @rappet:rappet.xyz instead to Contact @rappet:rappet.xyz instead (I will not respond here). | 21:01:06 |
| 26 Jan 2026 |
 debtquity | swift-5.10.1 no longer compiling for me on unstable. related issue - https://github.com/NixOS/nixpkgs/issues/483584
pinning nixpkgs to 70801e06d9730c4f1704fbd3bbf5b8e11c03a2a7 seems to do the trick [1]
[1] https://github.com/NixOS/nixpkgs/issues/483584#issuecomment-3796732786
| 09:08:25 |
 alexfmpe | yeah it kind of looks like that's what's happening | 09:52:54 |
| alexfmpe | the include chain goes through gcc, sdk and then back again | 09:55:32 |
| alexfmpe | In file included from /nix/store/8pk2m0fn7z5dlb86z5qlv1pxa8w68idx-apple-sdk-14.4/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/secure/_stdio.h:31,
from /nix/store/nvx5zr97w93krpl08x796sqai7z43smi-gcc-15.2.0/lib/gcc/arm64-apple-darwin/15.2.0/include-fixed/stdio.h:423,
from lib/stdio.h:55,
from lib/error.h:47,
from src/hello.c:21:
lib/string.h:754:20: error: expected declaration specifiers or '...' before '__builtin_object_size'
754 | _GL_EXTERN_C void *memcpy (void *__dest, const void *__src, size_t __n)
|
| 09:55:48 |
| alexfmpe | these top-level lib/ come bundled with gnu hello for whatever reason and then it does a tour
gnu -> gcc -> sdk -> gnu | 10:01:47 |
| alexfmpe | what fresh hell is this
/* Declarations for ISO C N3322. */
#if defined __GNUC__ && __GNUC__ >= 15 && !defined __clang__
_GL_EXTERN_C void *memcpy (void *__dest, const void *__src, size_t __n)
_GL_ATTRIBUTE_NONNULL_IF_NONZERO (1, 3)
_GL_ATTRIBUTE_NONNULL_IF_NONZERO (2, 3);
_GL_EXTERN_C void *memccpy (void *__dest, const void *__src, int __c, size_t __n)
_GL_ATTRIBUTE_NONNULL_IF_NONZERO (1, 4)
_GL_ATTRIBUTE_NONNULL_IF_NONZERO (2, 4);
| 10:02:45 |
| alexfmpe | tempted to file this under "gnu hello's problem" | 10:03:14 |
