[07:08] -GitHub[m]:#mir-server- **[MirServer/wlcs]** RAOF opened [pull request #250](https://github.com/MirServer/wlcs/pull/250): CI: Drive LXD directly, avoiding spread [08:39] Saviq: what do you think of dropping the use of spread for WLCS and just driving the tests directly? [08:41] I know why Ubuntu 22.10+ are failing, and could add another hack into spread to work around it, but it'd just be another hack, and we don't actually use most of the features of spread… [08:52] Oi! [08:54] RAOF (he/they) one reason why I like spread (at least for Mir) is that we (now, through LXD) can trivially reproduce the builds locally. What would the hack be? There is _some_ movement in spread upstream so we could try and move things there [09:00] Does it gain much over using LXC to set up a test environment locally? [09:02] With the breadth of configs, IMO it does, since any config is just a `spread lxd:…` away. Maintaining that set locally is possible, but by the time you actually need it, you're likely to need to update enough for it to be easier to start from scratch [09:03] While we could build a tool of our own around it, would it be better? [09:21] If we were doing it more often, I would care more. But it is an infrequent inconvenience [09:21] "it"? [09:22] testing some non-native environment locally [09:22] Right, but we'd have to maintain it for CI [09:23] And I currently doubt it would be less maintenance than our spread solution [09:31] That is a more convincing argument than "can trivially reproduce the builds locally" [09:51] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq assigned AlanGriffiths to [issue #2695](https://github.com/MirServer/mir/issues/2695): Miriway died upon disconnecting external screen [10:53] -GitHub[m]:#mir-server- **[MirServer/wlcs]** Saviq opened [issue #251](https://github.com/MirServer/wlcs/issues/251): Support for private tests... (full message at ) [11:27] @Saviq A fix (for now) for the spread failure-to-set-up-22.10+ images would be to delete `/etc/ssh/sshd_config.d/60-cloudimg-settings.conf` before restarting sshd in setup. [11:42] alan_g on display reconfiguration, if through a wayland extension, would it be possible to switch layouts without creating a surface? That's a limitation of the sleep inhibitor that we would want to do away with some time. [11:42] On that note, should sleep timeout maybe become part of the display layout? Sounds like something we may expose per display? [11:45] There's no requirement for a surface, just a connection on which globals can be published. But we'd obviously want to use `wl_output` [11:48] FWIW I believe there are two distinct features here - clients asking for a display configuration (that we don't want on Frame, by default), and switching between predefined display layouts. The latter is what we should focus on. [12:15] The sleep inhibitor protocol chooses to use a surface so that inhibition can be associated with surface visibility. You could have a different protocol that does things differently [12:16] Sure, just wanted to clarify what we're aiming for. Working with `wl_output` to select layouts sounds wrong to me when a layout describes more than one output [12:21] Thinking back to how mirclient managed display configurations we may want to allow a surface to be associated with a display configuration [12:23] Sure, for the general case, but Frame should not respect those requests by default. We have a static display config defined by the operator and we should never stray from it [13:03] We have enough control over publishing extensions for that [15:50] -GitHub[m]:#mir-server- **[MirServer/wlcs]** Saviq requested a review from RAOF for [pull request #252](https://github.com/MirServer/wlcs/pull/252): spread: use spread-mir-ci [15:50] -GitHub[m]:#mir-server- **[MirServer/wlcs]** Saviq opened [pull request #252](https://github.com/MirServer/wlcs/pull/252): spread: use spread-mir-ci... (full message at ) [16:17] > fix unqualified use of `std::move` [16:17] Why would that be needed? [16:18] https://github.com/MirServer/wlcs/actions/runs/3516098418/jobs/5892209519#step:5:1164 [16:29] "-Wunqualified-std-cast-call` wtf?! [17:54] Good night all o/ [18:13] o/