| 4 Jan 2026 |
 vcunat | Also, the machine did manage to succeed the whole build once during my debugging 😅 | 17:00:42 |
| vcunat | Could it be this log line?
XprotectService: [com.apple.xprotect:xprotect] File /nix/var/nix/builds/nix-46977-2307007369/man-db-2.13.1/src/.libs/whatis failed on loadCmd /nix/store/lkgb48k0pifhrknkmhgc1379i2aa8r9a-man-db-2.13.1/lib/man-db/libmandb-2.13.1.dylib (loadCmd resolved to: (path not found), bundleURL: (null))
| 17:12:55 |
 Randy Eckenrode | That seems like DYLD_LIBRARY_PATH isn’t working. | 17:14:40 |
| vcunat | At the very least it looks like the build system is trying to run some executables incorrectly wrapped. | 17:14:48 |
| vcunat | I see a few others like that. | 17:14:56 |
| vcunat | (and I wasn't doing anything else myself during that time) | 17:15:12 |
| vcunat | In general these path shenanigans are why I prefer to run most tests after the installation step (well, on Linux). | 17:16:40 |
| vcunat | There's still no explanation about the non-determinism of this. | 17:18:20 |
| 6 Jan 2026 |
 spewdins | Hi.
I need to use wayland on macOS.
I am building a wayland compositor for macOS.
Thus, I need libwayland, and wayland scanner, protocols. This pr I recently did should likely fix macOS builds of libwayland.
https://github.com/NixOS/nixpkgs/pull/477359/files#diff-cf867da35ed61431a969f5710278d34b932bd1d61ab9e52befae6ea0f69879be
but, I am not certain I've properly made the change as others might not like it.
Can somebody help me here? | 06:14:53 |
 emily | have you tried upstreaming it? | 06:29:50 |
| emily | we don't like to carry big/invasive patches downstream like this | 06:30:03 |
| emily | they inevitably bitrot and this sort of thing should really go through upstream code review | 06:30:20 |
| spewdins | uh well, the upstream mr from gitlab is what the darwin.patch is generated from
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/481/diffs | 06:50:18 |
| spewdins | so, it will be 1:1 if the mr is merged right now, to upstream wayland in its current state | 06:50:47 |
| spewdins | any other changes from mr481 could be generated again to replace darwin.patch with the updated mr changes from mr481.
and, if it does become merged, we could always just remove the patch anyway | 06:52:22 |
| spewdins | I guess, in this case, I'm fixing previous bitrot | 07:03:04 |
 raitobezarius | Is there macOS folks who could take a look at https://github.com/NixOS/nixpkgs/pull/476848 ? | 10:09:53 |
 Alyssa Ross | No it won't, it'll be 1:1 to an unmerged upstream PR | 16:05:29 |
| Alyssa Ross | The current situation is not really sustainable. Wayland is going to keep breaking on macOS. Somebody who wants it needs to actually work with upstream to figure out how to get that MR merged. | 16:06:01 |
| emily | yeah, macOS is only going to have a healthy Wayland ecosystem if libwayland upstream actually builds | 17:52:10 |
| emily | if it's important to you then it's better to be the maintainer of Darwin support in libwayland than the maintainer of Darwin support in libwayland in Nixpkgs | 17:52:32 |
| emily | even if we merged the patch, it'll inevitably break on updates, and people aren't going to want to block Linux on that | 17:52:55 |
| spewdins | Makes sense. I understand the reasoning there | 23:58:59 |
| 7 Jan 2026 |
| Randy Eckenrode | Does by-name require the pname to match the folder name? | 01:00:19 |
| Randy Eckenrode | A lot of Swift packages are named swift-foo. I’d like to put them in fo/foo because otherwise sw ends up very full. | 01:00:42 |
| Randy Eckenrode | Just answered my own question. The folder name becomes the package name in nixpkgs. | 01:02:31 |
| Randy Eckenrode | * | 01:02:42 |
| Randy Eckenrode | It appears that Swift SDKs are just a sysroot named foo.sdk. | 03:23:55 |
| emily | "New attribute names should be the same as the value in pname." | 04:56:18 |
| emily | (https://github.com/NixOS/nixpkgs/tree/master/pkgs) | 04:56:23 |
