 | Nix on macOS | 1201 Members |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 201 Servers |
| Nix on macOS | 1201 Members |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 201 Servers |
| Sender | Message | Time |
|---|---|---|
| 5 Apr 2026 | ||
 EsperLily [she/her] | yeah ok fair enough. i guess i'll submit two patches, one which switches macvim to using the common hardeningDisable flags and the other which changes that common definition to strictflexarrays1 and let anyone who cares weigh in on it there | 02:31:07 |
| EsperLily [she/her] | i am a little nervous about the comment in the configure script that says that _FORTIFY_SOURCE=2 crashes in gcc 4.0, macvim's been running with fortify but that's always been clang and i don't know if clang vs gcc matters for this today | 02:34:32 |
 emily | I think the fortify behaviour is pretty uniform. but I could be wrong. | 02:37:03 |
| emily | at the time GCC 4.0 was released, Vim was presumably full of exploitable memory safety bugs… | 02:37:18 |
| emily | I imagine a lot more people are running it with hardening flags these days | 02:37:35 |
| emily | would rather have an abort than a 2005-vintage buffer overflow… | 02:38:47 |
| emily | those 2020s commits did imply actual ASAN testing was done at some point at least | 02:38:55 |
| emily | ah, they ASAN in CI even. | 02:39:17 |
| EsperLily [she/her] | the configure script tries to strip any _FORTIFY_SOURCE definition already provided, so anyone who sets it through the environment or CLI will be overridden by vim. nixpkgs handles this inside of cc-wrapper but i assume most distributions don't inject flags by wrapping the compiler in a script | 02:39:30 |
| emily | well, some distros do stuff like patching GCC spec files | 02:40:02 |
| emily | which I think can have a similar effect. (not saying hardening is necessarily done this way0 | 02:40:20 |
| 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 |