| 26 Apr 2026 |
 emily | wasn't this discussed and you were encouraged to work with libwayland and Qt upstream because it broke packages? | 16:40:25 |
| emily | 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 |
| emily | so adding support for Darwin to libwayland with the bitrot-prone downstream patch broke Qt even without trying to use qtwayland | 16:41:11 |
 spewdins | oh is that why qtwayland | 16:41:14 |
| spewdins | ugh there's so much work | 16:41:17 |
| spewdins | alright it makes sense but holy | 16:41:29 |
| spewdins | I wish I had some help | 16:41:50 |
 Randy Eckenrode | 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 |
| emily | 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 |
| spewdins | I was also wondering about the macOS nix store optimization. it's no longer a randomized func correct? | 16:42:23 |
| spewdins | ya, I forgot that is an upstream problem with libwayland | 16:42:51 |
| spewdins | thank you for the tips | 16:43:50 |
| emily | basically it seems like the things that are breaking are things that
- use
AM_ICONV;
- don't declare their dependency on
AM_ICONV (by mentioning gettext in their configure.ac) in a way that autoreconf can recognize;
- and that we then
autoreconfHook
so there's actually an upstreamable fix in ~all(?) of these cases by addressing #2 and then stuff will just pick up our gettext package which knows that we told it iconv works
| 16:44:04 |
| emily | 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 |
| emily | oh yeah… | 16:45:17 |
| emily | cdrdao> autoreconf: running: autopoint --force
cdrdao> Copying file ABOUT-NLS
cdrdao> Copying file config.rpath
cdrdao> Copying file m4/build-to-host.m4
cdrdao> Copying file m4/gettext.m4
| 16:45:20 |
| emily | * cdrdao> autoreconf: running: autopoint --force
cdrdao> Copying file ABOUT-NLS
cdrdao> Copying file config.rpath
cdrdao> Copying file m4/build-to-host.m4
cdrdao> Copying file m4/gettext.m4
cdrdao> Copying file m4/iconv.m4
| 16:45:32 |
| emily | so what's actually happening here is, it's installing an AM_ICONV that works, correctly | 16:45:52 |
| emily | but the configure.ac is just not picking up iconv.m4 from there?! | 16:46:10 |
| emily | well, whatever. kind of a mess :) | 16:46:27 |
| emily | 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 |
| emily | the race condition is meant to be solved in the latest versions of both Lix and Nix to my knowledge | 16:48:04 |
| spewdins | exciting. I've had that disabled in my config for years | 16:49:16 |
| 27 Apr 2026 |
| spewdins | 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 |
 samasaur | perhaps https://github.com/NixOS/nixpkgs/issues/513543 ? | 01:11:22 |
| spewdins | seems about right | 01:11:51 |
| 19 May 2021 |
|  @grahamc:nixos.org set the history visibility to "world_readable". | 19:22:35 |
| @grahamc:nixos.org changed the room name to "" from "". | 19:22:35 |
|  [0x4A6F] joined the room. | 19:23:06 |
|  nazarii joined the room. | 19:24:29 |
