[00:03] Today: [00:03] - Mostly dealing with bureaucratic stuff related to departure [06:06] Ah! Sweet. There's the single line of code I broke. [06:07] Hm. It might be nice if taking a screenshot didn't dump all the Renderer debug info into the log... [06:33] Oooooh. [06:38] Right. Always it is with the threading! [07:05] ? [07:05] Yo! [07:07] We should fix the history permissions so that #mir-server works properly on the [Matrix archive](https://archive.matrix.org/?search=%23mir&homeserver=matrix.org) [07:24] Lemme look. I'm not admin -- appservice is. [07:25] I think we'll need to get an Ubuntu IRC operator to op one of us so we get matrix-side permissions. [07:26] Ah that I should be able to get [07:27] Hm, although that might only bump you up to "moderator", which is insufficient. [07:27] I guess it's worth a try. Otherwise we need to get the appservice to grant admin permissions to one of us. [07:28] Yeah can't see how... https://matrix-org.github.io/matrix-appservice-irc/latest/introduction.html [07:36] "Yeah can't see how... https://..." <- > Bridged IRC rooms do not share history to Matrix users from before they have joined by default, but history visibility can be changed by users with the correct power level on Matrix. [07:41] Is there a way to make Appservice promote IRC mods to admin rather than moderator role? We'd like to change the (matrix-side) history settings of #mir-server:libera.chat, but Appservice is the only admin ? [07:41] Hm. That was less linky than I was hoping. How about this: https://matrix.to/#/!vjOdckstTLwMkKHIgz:libera.chat/$6eB8U_3kxnlCLm9E3YNZC4SfBAGi5faamulXYeL_Asg?via=matrix.org&via=libera.chat&via=mozilla.org [07:42] You'll have to copy-paste, as that channel seems to have the same problem :P [07:42] (no history for new members) [07:43] ??? [07:43] Is there a way to make Appservice promote IRC mods to admin rather than moderator role? We'd like to change the (matrix-side) history settings of #mir-server:libera.chat, but Appservice is the only admin ? [07:43] Ah you asked. ACK, will monitor :) [07:56] Hm. That GL error log should really be more prominent :) [08:05] Huh. Why did that work? [08:05] Sigh. [08:05] mutable global state ? [08:07] AKA: don't `foo = new_foo{}` where `new_foo` calls eglMakeCurrent(me) and `~foo()` calls eglMakeCurrent(none) :blobcat_angry: [08:12] But with that done...... (full message at ) [16:04] Today: [16:04] - got checkbox-mir to run on the Pi [16:04] - recorded half of the demo videos for the webinar [16:04] - found [an issue](https://github.com/MirServer/graphics-test-tools/pull/5) with graphics-test-tools [16:15] ? [16:52] Today: [16:52] - Looking into a failure on ARM systems: #2900 (would appear to be a race, but I've not quite solved it today) [18:02] "Today:..." <- Looking into a failure on ARM systems: #2900 (would appear to be a race, but I've not quite solved it today) [18:02] Naturally, having written that everything became clear and a fix is up for review [21:34] is there a way to get set_window_geometry or *offset* as its called in mir information with miral? [21:34] since we need that to place windows on lomiri/qtmir [21:45] maybe we are doing some wrong in qtmir, but how should we place windows when buffer/texture and window size is different [21:46] for example gtk creates shadows, with this there is a missmatch between buffer/texture and window size [21:47] so how do we get x/y for both the window and buffer/texture so we can place it correctly?