| 19 Feb 2026 |
 Vladimír Čunát | We have basically all binaries already. | 10:40:40 |
| Vladimír Čunát | But the regressions are the issue now. | 10:40:48 |
| Vladimír Čunát | * We have basically all staging-next binaries already. | 10:41:09 |
 dramforever | how bad is pipewire anyway clicks the pr oh no | 10:42:09 |
 K900 | It's like, most of Qt, at the very least | 10:49:26 |
 emily | I can probably take a brief look at Darwin if there's anything particularly pertinent | 11:06:13 |
| Vladimír Čunát | This thing has many reverse dependencies:
https://github.com/NixOS/nixpkgs/pull/488406#issuecomment-3921541704 | 11:09:21 |
| Vladimír Čunát | Then twisted is at least very unreliable, but I think the worst cases were retried many times and succeeded in the end. | 11:10:19 |
| Vladimír Čunát | And qt6.qtbase is broken on darwin:
https://github.com/NixOS/nixpkgs/pull/486498#issuecomment-3913199483 | 11:10:44 |
| Vladimír Čunát | (Let me stop; I don't want to overload you.) | 11:11:07 |
| emily | taking a look | 11:35:27 |
| emily | qtbase is failing because libX11 is getting propagated in and turning on the XCB feature which results in it trying to compile the GNOME theme and stuff | 11:54:35 |
| emily | actually no, that feature is not listed as on in the config output | 11:54:55 |
| emily | qt_internal_extend_target(Gui CONDITION UNIX AND (((QT_FEATURE_xcb OR NOT MACOS) AND (QT_FEATURE_xcb OR NOT UIKIT)) OR QT_FEATURE_wayland)
so why is this check passing. cc K900?
| 11:55:08 |
| emily | oh | 11:55:40 |
| emily | it's getting Wayland?! | 11:55:43 |
| emily | it's listed as off in the config though… but it's definitely finding something | 11:55:58 |
| emily | cmake/QtProcessConfigureArgs.cmake sets set(QT_FIND_ALL_PACKAGES_ALWAYS ON) which disables the platform guards on looking for X11 and Wayland libs | 11:58:27 |
| emily | but I don't know if we end up using that file either :) | 11:58:59 |
| emily | anyway | 11:59:38 |
| emily | I believe https://github.com/NixOS/nixpkgs/pull/477359 was the culprit | 11:59:45 |
| emily | because withWayland ? lib.meta.availableOn stdenv.hostPlatform wayland, is now triggering | 12:00:07 |
| emily | we could presumably add an additional guard there but I am inclined to revert that PR for now because I'm not convinced we should be carrying a somewhat invasive downstream patch to libwayland anyway | 12:01:52 |
| emily | well. I suppose we can't revert because that would cause Linux rebuilds | 12:04:02 |
| emily | I take it a wayland rebuild is out of the question at this point? | 12:04:12 |
| Vladimír Čunát | So we override withWayland to false on darwin? | 12:05:01 |
| Vladimír Čunát | (Does wayland even make sense on darwin?) | 12:05:24 |
| emily | it's probably not a good thing if ~everything doing withWayland ? lib.meta.availableOn stdenv.hostPlatform wayland needs special-casing for Darwin because nothing expects Wayland on Darwin | 12:05:35 |
| Vladimír Čunát | * So we override withWayland to false on darwin, at least for now? | 12:05:38 |
| emily | shrug
This package is vital for macOS wayland compostors.
I am currently working on a wayland compositor for macOS, and this would help me reduce reliance on downstream custom derivations of libwayland.
X11 on macOS is a thing, Wayland on macOS could be too. in practice it is not
| 12:06:04 |
