Nix on macOS | 1205 Members | |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 202 Servers |
| Sender | Message | Time |
|---|---|---|
| 26 Apr 2026 | ||
| wasn't this discussed and you were encouraged to work with libwayland and Qt upstream because it broke packages? | 16:40:25 | |
| IIRC Qt's build system assumes that if libwayland is present then there's other Linux-y/XCB-y stuff it can use. | 16:40:54 | |
| so adding support for Darwin to libwayland with the bitrot-prone downstream patch broke Qt even without trying to use qtwayland | 16:41:11 | |
| oh is that why qtwayland | 16:41:14 | |
| ugh there's so much work | 16:41:17 | |
| alright it makes sense but holy | 16:41:29 | |
| I wish I had some help | 16:41:50 | |
| Yeah. I ran into something similar with Clang 18. What’s really annoying is you can’t just patch the latest gettext. You have to patch every version of gettext because it ships them in a tarball and will use them if a project declares a dependency on that version. That’s the reason for https://github.com/NixOS/nixpkgs/blob/b93797898e1b6582c374a2903fc68dfe36fb7d52/pkgs/development/libraries/gettext/default.nix#L49-L62. | 16:41:54 | |
| if libwayland merges Darwin support and Qt fixes their build system then we can have it enabled no problem. (probably we could even just patch the Qt build system ourselves if libwayland merges it, since at that point it'd be obviously a Qt bug rather than a correct assumption that libwayland implies certain things about the platform) | 16:42:19 | |
| I was also wondering about the macOS nix store optimization. it's no longer a randomized func correct? | 16:42:23 | |
| ya, I forgot that is an upstream problem with libwayland | 16:42:51 | |
| thank you for the tips | 16:43:50 | |
| basically it seems like the things that are breaking are things that
so there's actually an upstreamable fix in ~all(?) of these cases by addressing #2 and then stuff will just pick up our | 16:44:04 | |
| so that's not too bad, it doesn't mean we have to convince upstreams to accept Darwin-specific hacks or anything at least | 16:44:18 | |
| oh yeah… | 16:45:17 | |
| 16:45:20 | |
*
| 16:45:32 | |
so what's actually happening here is, it's installing an AM_ICONV that works, correctly | 16:45:52 | |
but the configure.ac is just not picking up iconv.m4 from there?! | 16:46:10 | |
| well, whatever. kind of a mess :) | 16:46:27 | |
but it at least doesn't seem like "sky is falling, anything using autotools will never accept Darwin libiconv" levels of bad. just "sometimes a configure.ac is organized in a way that means autoreconf doesn't quite do the right thing out of the box and it's an upstream issue when that's the case" | 16:47:41 | |
| the race condition is meant to be solved in the latest versions of both Lix and Nix to my knowledge | 16:48:04 | |
| exciting. I've had that disabled in my config for years | 16:49:16 | |
| 27 Apr 2026 | ||
| nixpkgs's zsh 5.9 takes a very long time (or just straight up hangs) when I try using nixpkgs zsh on macOS | 01:10:46 | |
| perhaps https://github.com/NixOS/nixpkgs/issues/513543 ? | 01:11:22 | |
| seems about right | 01:11:51 | |
| I'm using brew with
| 09:38:55 | |
| 19 May 2021 | ||
| 19:22:35 | ||
| 19:22:35 | ||
| 19:23:06 | ||