[00:00] Because there *has* to be something in the silo that depends on libmirserver28 [00:00] Or, rather, *unless* there's something in the silo that depends on libmirserver28 you're not testing the new Mir. [00:01] RAOF, correct, usc, qtmir are/were on the silo [00:01] And they were built against the correct version, presumably, and so had a dep on libmirserver28? [00:02] RAOF, yep they were changed to dep on libmirserver 0.10 [00:03] RAOF, but we don't necessarily bump their dep, we only do it unless downstreams must be changed as a result of changes in mir [00:04] Yeah, absolutely. [00:04] RAOF, but this time we did, because there were code changes [00:04] in downstreams [00:04] * greyback_ surprised qtmir built against mir0.1.0, as it failed for me until I changed post_update() to "gl_swap_buffers(); flip();" [00:05] greyback, I changed it in qtmir [00:05] camako: ah really? Ok, I didn't find that branch [00:06] camako: So, the interesting question is: “why were mir-utils, qtdeclarative5-qtmir-plugin, and qtmir-android held back”. [00:06] greyback : this was in the silo ---> https://code.launchpad.net/~mir-team/qtmir/devel-mir-next/+merge/245592 [00:07] camako: saw that, but has empty diff for me?! [00:07] as in, what LP shows me [00:07] ah, I see it now [00:08] greyback, ah yeah I noticed that too. it's lying [00:08] camako: ok well mystery solved [00:08] greyback, look at the commit # 269 here ---> https://code.launchpad.net/~mir-team/qtmir/devel-mir-next [00:08] thanks! [00:10] 269 == approved rev of the MP (but the diff shows empty :-) ) === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === alan_g is now known as alan_g|EOW [18:40] hello, is there some known issue with heavy screen flickering in mir_demo_server? running mir-demos 0.10.0+15.04.20150107.2-0ubuntu1, kernel is 3.19.0-031900rc3-generic [20:39] hi, has anyone experienced that problem recently? mir_demo_server is flickering heavily (it seems to happen after switching vt the second time) [21:31] attente_: new to me [21:32] can you file a bug? [21:32] racarr_: sure [21:32] this late on a friday its not going to get a lot of attention ;) but next week [21:32] racarr_: right ;) [21:32] :) Thanks [21:32] probably gonna be some sort of driver specific thing ;( [21:57] attente_: Saw the bug. Thanks :) [21:58] racarr_: np :) forgot to mention about the kernel update at first, hope that's not the cause