| 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 |
 vcunat |
there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
| 08:19:46 |
| vcunat | *
"Should": there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
| 08:20:04 |
| vcunat | I don't know. I'm just dropping the tests to unblock:
https://github.com/NixOS/nixpkgs/commit/1551a606a703 | 08:51:32 |
 kdn | FYI: I have recreated the VM (launchctl bootout ... && rm -r /shared/dir) and it seems to work just fine now | 12:11:30 |
 eveeifyeve | I can't believe the apple-sdk didn't have a license. | 13:49:38 |
| eveeifyeve | * I can't believe the apple-sdk didn't have a license I just made a pr that adds it. https://github.com/NixOS/nixpkgs/pull/477742 | 13:50:42 |
| emily | we only use API stubs and headers from the SDK | 14:01:43 |
| eveeifyeve | Would that still count tho? | 14:02:01 |
