| 12 Dec 2025 |
 raboof | * no it's not just link ordering: when dependencies are not explicit, cmake will kick off the qml code generation for the 'depending' before processing the 'dependee' has finished, causing it to nondeterministically miss generating code that should come in via the 'dependee'. I'm not sure why that doesn't seem to cause more actually-observed issues, though. | 12:27:57 |
 K900 | That means we have to fix them one by one then | 12:28:01 |
| K900 | Is really what I meant | 12:28:07 |
| K900 | This sucks | 12:28:10 |
| K900 | (and it doesn't cause issues presumably because the cache is entirely optional and it will just JIT if something isn't cached) | 12:28:33 |
| raboof | right, ordering in time more than ordering in order. but yeah, each will need individual fixes sadly. in a perfect world of course the generator would somehow pick up on such missing dependencies, but I'm already in way over my head understanding as much/little of that build system as I do :) | 12:29:04 |
| K900 | Yeeeeeeeeeeeeeeeeeah | 12:29:16 |
| K900 | The thing is, missing dependencies are fine | 12:29:25 |
| K900 | In general | 12:29:26 |
| K900 | Because like pretty much every QML file ever depends on Qt.Quick | 12:29:40 |
| K900 | And you don't want to have that pulled into the cache for your app | 12:29:49 |
| K900 | You want to use the hopefully already existing cache in the system | 12:29:58 |
| K900 | So it's expected that it doesn't require full source for everything | 12:30:23 |
| K900 | Also qtdeclarative needs to go to staging now | 12:30:47 |
| K900 | It's too big | 12:30:49 |
| raboof | (yeah I expected as much but was waiting for nixpkgs-ci to tell me ;) - now rebased) | 12:31:58 |
| raboof | * (yeah I expected as much but was waiting for nixpkgs-ci to tell me ;) - now retargeted) | 12:32:09 |
| K900 | Need to rebase now :( | 12:33:08 |
| K900 | Cause I also merged another backport | 12:33:12 |
| K900 | A few days ago | 12:33:15 |
| raboof | unfortunately I also haven't quite figured out how to go from "these methods get inconsistently generated" to "this dependency is not declared" - so for powerdevil and libplasma I've opened upstream issues in kde with that pointer (which were 'confirmed' but no other action yet) | 12:54:56 |
| 14 Dec 2025 |
|  srounce joined the room. | 10:12:46 |
| srounce | Hey K900I made this PR to fix an issue in FreeCAD where it will crash under Gnome 49 whenever a file browser is opened, due to gtk3 gsettings-schema not being present. Would it be worth applying something like this to all Qt apps via wrapQtAppsHook as it seems many applications are affected. | 10:16:03 |
| K900 | No | 10:16:15 |
| K900 | This is the stupid thing again | 10:16:22 |
| K900 | We need some sort of global solution but slapping wrapGAppsHook on every Qt application is not it | 10:16:33 |
| srounce | Yes I was hoping you’d have a suggest for a better solution than that as it’s rather clumsy | 10:22:35 |
| K900 | Possibly we should just patch Qt to take the XDG portal path | 10:24:38 |
| srounce | aren’t all Qt applications using wrapQtAppsHook? | 10:29:16 |
| K900 | Yes, and some of them do Really Interesting Things | 10:29:34 |
