[06:38] <RAOF> Hm. Well, apart from the bit where it doesn't apply the display config, and that clone mode is fighting over textures in interesting ways, that worked first time :)
[06:43] <Saviq> I've hit a snag with multi-arch glvnd/mesa snaps: https://bugs.launchpad.net/snapcraft/+bug/2009278
[06:43] <Saviq> Currently can't see a way to build the x86 one from the same YAML as the other ones…
[06:44] <RAOF> Bah.
[06:45] <RAOF> The x86_64/i386 one works, though, right?
[06:45] <RAOF> That seemed to work for me?
[06:56] <Saviq> Yeah, when you build on amd64 it's fine, but outside of that, it's failing to load i386 from ports.ubuntu.com
[07:05] <Saviq> And well, that makes sense (we're adding i386 on a system where ports are the default repos), but it making sense does not help us :)
[07:46] <Saviq> Wop! Found a workaround. Because the alphabet is great.
[14:57] <alan_g[m]> Saviq should we drop the "round robin" output assignment logic? Or is it worth preserving?
[14:57] <Saviq> alan_g[m]: I think it a better default than overlay, but only if it's easy to keep
[14:57] -GitHub[m]:#mir-server- **[MirServer/ubuntu-frame]** AlanGriffiths marked [pull request #129](https://github.com/MirServer/ubuntu-frame/pull/129): Allow configuration to assign applications to outputs as ready for review
[14:57] <alan_g[m]> Well, it doesn't "play nice" with display-layout changes. Nor apps that choose their own output (like Kodi). So I anticipate it being a source of issues. (And remember the default is overlaying everything anyway)
[14:57] <alan_g[m]> But it isn't actually in the way of anythinb
[14:57] <alan_g[m]> *anything
[14:57] <alan_g[m]> I'm just thinking we now have a better solution to any problems it solved. (Inconsistent/non-deterministic features are always problematic when real users encounter them)
[14:57] <alan_g[m]> Saviq you OK with the key names `snap-name` and `surface-title`? Or still thinking?
[14:57] <Saviq> Personally I'd keep it, but will not counter dropping it in favour of more consistency and determinism
[14:57] <Saviq> +1, likely the only reason for keeping it would be backwards compatibility. And people relying on it may be surprised when the order their app launches changes
[14:57] <Saviq> So +1 on removing it