 | Nix on macOS | 1202 Members |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 200 Servers |
| Nix on macOS | 1202 Members |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 200 Servers |
| Sender | Message | Time |
|---|---|---|
| 5 Apr 2026 | ||
 emily | * which I think can have a similar effect. (not saying hardening is necessarily done this way) | 02:40:22 |
| emily | looks like Gentoo specifically tries to inject them in spec files | 02:43:17 |
 EsperLily [she/her] | oooh no with just strictflexarrays1 building on aarch64-linux crashes with "buffer overflow detected" | 03:13:22 |
| EsperLily [she/her] | i wonder if it's worth trying to set the flag depending on which compiler is being used | 03:13:48 |
| EsperLily [she/her] | https://github.com/NixOS/nixpkgs/pull/506844 is the PR for macvim. https://github.com/NixOS/nixpkgs/pull/506853 is the PR for vim, which only changes the flags when using clang. If one PR gets merged, the other will need to be rebased and updated (not super important, but we want to ensure that overriding stdenv on macvim uses that same overridden stdenv for the clang check) | 03:41:03 |
 Randy Eckenrode | I plan to open a PR this week to split the source release sources out from the SDK. The goal is to have the 26.4 SDK in the next staging cycle. | 12:17:44 |
| Randy Eckenrode | After that, we should be able to do SDK updates day 1 once they are available. | 13:09:29 |
| 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.
| 13:16:14 |
| 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.
| 13:16:23 |
| 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.
| 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.
| 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.orgdid 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 |