| 19 Feb 2026 |
 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 |
| Vladimír Čunát | In that case we'd... remove darwin from wayland.meta.platforms probably | 12:06:08 |
| emily | so I'm not inclined to put much work into it to keep Darwin working. | 12:06:11 |
| emily | right, this PR was specifically meant to make it build on Darwin again. | 12:06:22 |
| Vladimír Čunát | That's one thing. | 12:06:41 |
| emily | https://github.com/NixOS/nixpkgs/pull/492078 | 12:10:33 |
| emily | haven't tested the qtbase build, but I'm pretty sure this is the root cause | 12:10:42 |
| emily | looking at scikit-build-core | 12:11:22 |
| emily | the issue with scikit-build-core isn't the presence or lack of lipo; it can handle that | 12:12:18 |
| emily | it's https://pytest-subprocess.readthedocs.io/en/1.4.0/usage.html#unregistered-commands, "By default, when the fake_process fixture is being used, any attempt to run subprocess that has not been registered will raise the ProcessNotRegisteredError exception." | 12:12:41 |
| emily | hexa: any recent changes to pytest stuff? | 12:12:48 |
| emily | uh whoops, I included my random testing of scikit-build-core in the Wayland commit :) | 12:13:14 |
