[01:22] <RAOF1> I am sooooo terrible at writing shaders.
[01:50] <duflu> Hmm, problem... zesty's libmiral requires Mir 0.26.0 and not 0.26.1
[01:50] <duflu> So you need both installed
[01:51] <duflu> robert_ancell, RAOF: Could we spin a rebuild of libmiral against the new Mir that's in proposed?
[01:51] <duflu> We'll need to very soon
[01:51] <robert_ancell> sounds like a job for RAOF or RAOF1
[01:55] <duflu> RAOF, RAOF1, camako: https://bugs.launchpad.net/ubuntu/+source/miral/+bug/1664791
[02:09] <RAOF> Hm. That goes through bilito?
[02:20]  * duflu shrugs
[02:33] <RAOF> I mean, I can trivially upload a no-change rebuild, but that's going to mess other things up.
[02:38] <duflu> It seems like the kind of atomic ABI shift that silos are for
[02:45] <duflu> RAOF: Don't we just need a new build of libmiral in proposed, and then promote both at once?
[02:46] <RAOF> It won't migrate out of proposed until it's installable.
[02:46] <RAOF> If this *wasn't* using bileto I'd know precisely what to do, and would already have done it :)
[02:48] <duflu> At least it seems like miral is what's holding the old libmirplatform14
[02:48] <duflu> I can't see anything else
[02:49] <duflu> Hmm...
[02:49] <RAOF> This is not an urgent problem at all, is it?
[02:50] <duflu> RAOF: It will be. This will block the release of 0.26.1
[02:50] <RAOF> Oh? Why?
[02:51] <duflu> RAOF: Because zesty's miral depends on a package that only exists in 0.26.0
[02:51] <duflu> Because we corrected an ABI break, mid-series :P
[02:52] <RAOF> Why does that block the 0.26.1 release?
[02:52] <duflu> RAOF: I think because this makes it impossible to build an ISO
[02:52] <RAOF> That package will still exist in zesty?
[02:52] <duflu> RAOF: No it won't
[02:53] <RAOF> Yes it will.
[02:53] <RAOF> Packages aren't removed from the archive until they have no reverse-dependencies.
[02:53] <duflu> RAOF: OK, I won't argue with a positive outlook. But we need to rebuild soon
[02:53] <RAOF> It won't be built from *source* in the archive, but it'll exist.
[02:53] <RAOF> Yeah.
[02:54] <duflu> We really need to get automated ABI checking back in action
[02:55] <duflu> Since not having it and discovering breaks manually is one of the main things slowing down the release of 0.26.1
[02:55] <duflu> Also not terribly accurate and reliable
[02:55] <RAOF> If it were urgent I could just upload a no-change rebuild manually and fix whatever that breaks in bileto. But since it shouldn't block 0.26.1, we can probably wait for someone who knows how bileto releases go.
[03:14] <RAOF> Grumble grumble stringly typed code.
[03:15] <duflu> Stringly typed as in Perl? :)
[03:16] <RAOF> No, more “I'm not experienced at writing shader code and having the compile step be at runtime on a different VT is quite annoying”.
[03:17] <duflu> RAOF: I recommend developing via ssh. Then the window never goes away :)
[03:18] <duflu> Although annoying that you really need ethernet to avoid lag when typing over wifi
[03:18] <duflu> Or at least 802.11ac
[04:45] <RAOF> Aaargh.
[04:45] <RAOF> Now it's throwing no errors, just failing to copy anything.
[04:45] <RAOF> Bah.
[05:54] <RAOF> Bah!
[05:54] <RAOF> There's *another* error eliminated that still doesn't result in rendering appearing :(
[06:05] <duflu> RAOF: Speaking of graphics issues, I found that glmark2 fullscreen in Xmir is outputting incomplete geometry (the GPU hasn't filled in all the triangles)
[06:06] <duflu> Which is interesting, and somewhat familiar
[06:06] <duflu> I had similar bugs during the development of bypass
[06:06] <RAOF> Well, we are blithely assuming that the GPU is going to synchronise for us.
[06:06] <RAOF> We don't glFinish() before sending buffers ;)
[06:06] <duflu> Fair point
[06:07] <duflu> Or perhaps we're showing the backbuffer
[06:07] <duflu> Which would explain other apps flickering black
[06:07] <duflu> On that note, there's another bug I forgot to log...
[06:14] <TheKit> does hardware OpenGL work in Xmir on Android?
[06:15] <RAOF> No
[06:16] <duflu> TheKit: No, but it will try. Mesa is used, with software rendering, and wrong colours (because Mesa and Android are not yet fully compatible)
[06:17] <duflu> So OpenGL in Xmir on Android will indeed put pixels on screen, slowly and with red/blue swapped