| 19 Jan 2026 |
|  Sapphire changed their profile picture. | 20:16:19 |
| 20 Jan 2026 |
 Randy Eckenrode | And thank you for the groundwork you did. | 01:38:48 |
| Randy Eckenrode | sigtool’s main issue is lacking certain features, which won’t be coming. I don’t think we want to maintain our own implementation long term. The way forward is likely a codesign-compatible CLI to rcodesign. | 01:39:53 |
| Randy Eckenrode | It supports the needed features (particularly bundle signing and setting the linker-signed flag), but it has its own CLI. | 01:40:36 |
| Randy Eckenrode | * sigtool’s main issue is lacking certain features. I don’t think we want to maintain our own implementation long term, so we probably don’t want to do that ourselves. The way forward is likely a codesign-compatible CLI to rcodesign. | 01:43:29 |
 emily | FWIW I think Nixpkgs is no longer the world's biggest sigtool consumer at this point 😅 | 01:49:51 |
| Randy Eckenrode | Is Conda using it? | 18:37:11 |
| emily | isn't cctools-port? | 19:40:11 |
| emily | I think that gets a fair bit of use. | 19:40:17 |
| 21 Jan 2026 |
| Randy Eckenrode | Yeah, for code-signing. | 11:34:23 |
| 22 Jan 2026 |
|  crazychaoz joined the room. | 10:43:06 |
| crazychaoz | so i am trying to get a amd64 -> arch64 rust cross build bit-for-bit equal to the emulated version, but (aside from other issues) i cannot get the symbols in the same order
aarch64 native and aarch64 emulated on arm64 already produce the same binary (to be expected tbh)
does anybody here know why or knows a resource (aside from reading rustc source) on ironing out my build ? | 13:08:28 |
 K900 | Honestly I don't think that's a realistic expectation | 13:09:37 |
| K900 | It's very likely your linker and not rustc, if you want to go down that rabbit hole | 13:09:49 |
| K900 | But in general, cross is its own thing and you shouldn't be expecting fully identical behavior | 13:10:17 |
| crazychaoz | ack, but it feels soooo close | 13:14:23 |
 Grimmauld (any/all) | it would be cool, because you could then more easily mix cross and native builds for the same target | 13:14:50 |
| crazychaoz | yeah
and in my case: cross compiling aarch64 is soo much faster than emu or native on a raspi, but only emu or native produce the "expected" result | 13:17:24 |
| crazychaoz | 
Download image.png | 13:20:17 |
| crazychaoz | guess the emu: | 13:20:21 |
|  Moved to: @astro:c3d2.de changed their display name from Astro to Moved to: @astro:c3d2.de. | 21:39:12 |
| 23 Jan 2026 |
|  blitz joined the room. | 14:11:57 |
| blitz | Hey cross-compilation gurus! :) Does anyone have a minute to look at this: https://github.com/NixOS/nixpkgs/issues/482970 | 14:12:35 |
| blitz | I really wonder why building the python bcrypt package fails in this scenario, because it should "just" be the x86 package (which works fine) | 14:13:02 |
| 24 Jan 2026 |
|  ShamrockLee (Yueh-Shun Li) joined the room. | 15:40:48 |
| 25 Jan 2026 |
 matthewcroughan @fosdem | Anyone know how to fix this? | 13:07:24 |
| matthewcroughan @fosdem | aarch64-unknown-linux-musl-clang -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"aarch64"' -DCONF_OSTYPE='"linux-musl"' -DCONF_MACHTYPE='"aarch64-unknown-linux-musl"' -DCONF_VENDOR='"unknown"' -DLOCALEDIR='"/nix/store/n0ydjr92z0vxkhvyyimljsgawbfjfs0k-bash-aarch64-unknown-linux-musl-5.3p9/share/locale"' -DPACKAGE='"bash"' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -Wno-parenth>
In file included from mkbuiltins.c:46:
../bashansi.h:44:23: error: 'bool' cannot be defined via 'typedef'
44 | typedef unsigned char bool;
| ^~~~
../bashansi.h:44:23: note: 'bool' is a keyword with '-std=c23' onwards
../bashansi.h:44:1: warning: useless type name in empty declaration
44 | typedef unsigned char bool;
| ^~~~~~~
make[1]: *** [Makefile:231: mkbuiltins.o] Error 1
make[1]: Leaving directory '/build/bash-5.3/builtins'
make: *** [Makefile:822: builtins/builtext.h] Error 1
make: *** Waiting for unfinished jobs....
| 13:07:28 |
| matthewcroughan @fosdem | It happens on staging-next and master, probably because of https://github.com/NixOS/nixpkgs/commit/6a6c4961a243439257f1293f3cfa3ac886bfe74e | 13:07:55 |
| matthewcroughan @fosdem | This is gnu-llvm-musl | 13:08:13 |
 nim65s | looks like a GCC upgrade to 15 broke that | 13:08:38 |
