| 5 Apr 2026 |
 Randy Eckenrode | * I plan to add the following packages to the source release list. They will be consumed for their source. Their versions will be from the 14.4 releases to avoid rebuilds. Eventually, I want to build their private headers for use by the other source releases, but they will initially be marked as broken because I do not want to spend any time on that right now. Once it’s done, that will greatly reduce the private header hackery currently required to build source releases.
- CommonCrypto
- configd
- dyld
- IOKitUser
- launchd
- Libc
- libdispatch
- Libinfo
- libmalloc
- Libnotify
- libplatform
- libpthread
- OpenDirectory
- xnu
| 13:16:33 |
| Randy Eckenrode | * I plan to add the following packages to the source release list. They will be consumed for their source. Their versions will be from the 14.4 releases to avoid rebuilds. Eventually, I want to build their private headers for use by the other source releases, but they will initially be marked as broken because I do not want to spend any time on that right now. Once it’s done, that will greatly reduce the private header hackery currently required to build source releases.
- CommonCrypto
- configd
- dyld
- IOKitUser
- launchd
- Libc
- libdispatch
- Libinfo
- libmalloc
- Libnotify
- libplatform
- libpthread
- OpenDirectory
- xnu
| 13:16:43 |
| Randy Eckenrode | What I would like to do is not expose them outside the darwin package set, but I don’t want it to be a hassle. I don’t think there’s a good way to do that right now. (I know I can do it with makeScopeWithSplicing’ by adding them to extra, but darwin is not set up to do that in a nice way right now. | 13:18:46 |
 viraptor | Trying to understand the private headers part. Right now they're copied from the private directory to the normal install, like https://github.com/NixOS/nixpkgs/blob/518150a17e5f9505ce45e295d7ce1efc8e69f9ae/pkgs/os-specific/darwin/apple-source-releases/dyld/package.nix#L53
Would they get a separate dev-like package after the change that can be referenced between the built source releases? Or did I misunderstand? | 13:55:55 |
| Randy Eckenrode | That’s it (more or less). XNU, for example, has a build process to produce the headers. | 14:14:42 |
| Randy Eckenrode | Looks like I got it to work without rebuilds. I also switched Darwin to use by-name in its packages hierarchy. | 20:39:45 |
| 6 Apr 2026 |
| Randy Eckenrode | I forgot to create the PR for this. https://github.com/NixOS/nixpkgs/pull/507114 fixes the sigtool build on Linux. | 00:06:53 |
| Randy Eckenrode | https://github.com/NixOS/nixpkgs/pull/507136 migrates darwin to by-name. | 01:34:42 |
| Randy Eckenrode | Does anyone know what the purpose of ghc-standalone-archive is? It was introduced in https://github.com/NixOS/nixpkgs/commit/4f9f00fcc9ba5fce1bf476bf3e3200bdbed00f48, but it doesn’t appear to be used anywhere. | 01:51:07 |
| Randy Eckenrode | It’s making nixpkgs-vet unhappy. | 01:51:31 |
| Randy Eckenrode | I inlined it into all-packages.nix. All checks pass now for https://github.com/NixOS/nixpkgs/pull/507136. No rebuilds. | 02:02:03 |
| Randy Eckenrode | I also successfully moved the source releases, but they’ll be done in a follow-up PR. | 02:24:39 |
 toonn | Anyone asked in the Haskell room about ghc-standalone-archive? | 09:51:33 |
|  @goldone:nope.chat left the room. | 11:32:26 |
 alexfmpe | In reply to @toonn:matrix.org
Anyone asked in the Haskell room about ghc-standalone-archive? did just now | 11:34:05 |
 hexa | ok, I've asked for M4 Pro 14C, 24GB, 512GB | 14:36:30 |
| hexa | Redacted or Malformed Event | 14:36:33 |
| hexa | hope everybody here is fine with the CPU/memory trade-off | 14:37:07 |
| alexfmpe | Redacted or Malformed Event | 17:47:43 |
| hexa | https://photon.codes/blog/we-found-a-ticking-time-bomb-in-macos-tcp-networking | 22:27:49 |
| Randy Eckenrode | Wow. They said on HN that they reported it to Apple. I’m sure a fix will be forthcoming. | 22:37:57 |
| 7 Apr 2026 |
| Randy Eckenrode | system_cmds doesn’t really need libdispatch’s private headers. The APIs it uses are actually in the public headers. I’ll have to vendor the header for now to make this a no-rebuild transition (to separate the source releases from the SDK). | 02:07:32 |
 EsperLily [she/her] | does using a newer apple-sdk package require actually being on that OS to build? the nixpkgs darwin docs don't actually say (and I'm already on macOS 26 or I'd just test) | 02:56:09 |
| Randy Eckenrode | It shouldn’t as long as you don’t increase the default deployment target. Clang is set up by default to error when APIs are used from a newer deployment target without putting them in an availability check. | 03:01:58 |
| EsperLily [she/her] | ok so why do we default to an older SDK then? | 03:07:26 |
| Randy Eckenrode | The Clang change is a trial run for having only the latest SDK. | 04:08:03 |
| Randy Eckenrode | There are some other concerns (building Swift, source incompatibility in newer SDKs, etc), but availability checks were the big one. We currently default to the 14.4 SDK with a 14.0 deployment target. It seems okay so far. | 04:11:04 |
|  insipx joined the room. | 14:21:41 |
| viraptor | This is not Mac specific, but clang will hit us way more often with this. Somehow I ran into two packages now which use -fmodules which causes writes to $home/.cache
I wonder if that would warrant a fix in some generic builder to set CLANG_MODULE_CACHE_PATH to a different path. We're only going to hit that one more often in the future. | 15:55:55 |
 emily | yes, I think we should likely set that in stdenv | 15:58:50 |
