[00:55] <rsalveti> anyone from the mir team around still?
[00:55] <rsalveti> kgunn: ^
[00:55] <rsalveti> quite a lot of packaging changes landed with the new mir
[00:55] <rsalveti> breaking the vivid touch build as we're depending on a package that got renamed
[00:55] <rsalveti> just trying to understand the changes
[01:29] <racarr> rsalveti: Hi
[01:29] <racarr> rsalveti: I think im the only one around so ill give a best effort
[01:29] <racarr> rsalveti: Wait RAOF is around and he made the changes
[01:29] <racarr> RAOF: ^
[01:29] <racarr> err
[01:30] <rsalveti> he's not around
[01:30] <rsalveti> it seems the backend can be dynamically loaded now
[01:30] <racarr> rsalveti: He is hes just not in this channel I pinged him on mir
[01:30] <rsalveti> https://code.launchpad.net/~mir-team/mir/server-platform-probing/+merge/244982
[01:30] <tmpRAOF> rsalveti: Sure.
[01:30] <racarr> rsalveti: Yes but thats basically what is it so
[01:30] <rsalveti> tmpRAOF: hey :-)
[01:30] <racarr> yes so the soname version isnt required anymore
[01:30] <tmpRAOF> racarr: You need to highlight tmpRAOF now, as freenode ate my RAOF registration :)
[01:30] <racarr> and the libraries got renamed
[01:30] <rsalveti> tmpRAOF: our vivid build is broken because it is still depending on the older packages
[01:30] <racarr> is the summary of my understanding
[01:30] <racarr> tmpRAOF: :)
[01:31] <rsalveti> -		add_package install ubuntu-minimal mir-client-platform-android libmirplatform5driver-android ubuntu-touch
[01:31] <rsalveti> +		add_package install ubuntu-minimal mir-client-platform-android mir-platform-graphics-android ubuntu-touch
[01:31] <rsalveti> I changed this
[01:31] <rsalveti> but we also had the update-alternatives for it
[01:31] <rsalveti> and it seems it's not required anymore
[01:31] <tmpRAOF> Correct.
[01:31] <rsalveti> tmpRAOF: how is mir finding out the backend to load now?
[01:31] <tmpRAOF> By loading them all and finding the one that works.
[01:31] <tmpRAOF> The only reason not to have mir-graphics-drivers
[01:32] <tmpRAOF> The only reason not to have mir-graphics-drivers-mesa on the touch images is you'll waste some disc space.
[01:32] <rsalveti> tmpRAOF: right, that's something I'll check on the next build, in case we get that package installed for whatever reason
[01:32] <rsalveti> tmpRAOF: but in case both are installed at the same time, how to select which one to use?
[01:33] <rsalveti> not sure if mesa will indeed fail on touch
[01:33] <tmpRAOF> It will.
[01:33] <rsalveti> great, will remove the update-alternatives and trigger a new build then
[01:34] <tmpRAOF> Unless it can *actually* work, in which case it's fine to use :)
[01:34] <racarr> lol
[01:34] <racarr> in which it turns out mesa worked on nexus devices this whole time
[01:34] <rsalveti> :-)
[01:34] <racarr> ;)
[01:34] <rsalveti> well, it might work with software rendering
[01:34] <rsalveti> not sure how is the current support though
[01:35] <tmpRAOF> No, our mesa platform doesn't support software rendering.
[01:35] <tmpRAOF> Also, you'd need a kms driver.
[01:35] <racarr> Mm I think we are covered...because of the modesetting bit
[01:35] <racarr> and then even if one did appear the platforms get "priorities"
[01:35] <tmpRAOF> (And once we *do* support software rendering, the mesa platform will only load with software rendering if there's nothing better; android will be better in that case)
[01:36] <racarr> and if an android driver is available (dont remember exactly how it works, but something like...can we load libhardware and open gralloc or whatever)
[01:36] <rsalveti> right, awesome then
[01:36] <racarr> then it gets priority "Best"
[01:36] <tmpRAOF> rsalveti: So, the only package you should need is mir-graphics-drivers-android (conversely, mir-graphics-drivers-mesa for desktop).
[01:36] <rsalveti> right, that's already in our seeds
[01:37] <tmpRAOF> racarr: That's correct - android probes by trying to open gralloc.
[01:39] <racarr> interestingly (not to this conversation, just to people interested generically in EGL implementations) mesa provides a DRI based implementation of gralloc
[01:39] <racarr> for running android on intel free drivers
[01:39] <racarr> kdub and I discovered it before hybris appeared as a driver solution and it took an hour or so of like...does this do what we need? Wait no this is
[01:39] <racarr> the exact opposite...
[01:39] <tmpRAOF> rsalveti: So, you should be able to drop mir-client-platform-android and keep just mir-graphics-drivers-android. We guarantee not to rename that one, and it'll always depend on a full set of packages required to get a fully functional Mir drivers on android.
[01:39] <racarr> it took me an hour or so maybe kdub understood because he knew gralloc lol
[01:40] <rsalveti> tmpRAOF: yeah, that's the change I did
[01:40] <rsalveti> will trigger a new image in a few and let you konw
[01:41] <tmpRAOF> Sweet.
[02:36] <Trevinho> Mhmmh... I've just updated the gdk-GL mir backend to match upstream changes... and well, with then now after few seconds I run the test-gl I'm getting a kernel panic on MIR! :o
[02:40] <Trevinho> gdk changes are basically:
[02:40] <Trevinho> https://bugzilla.gnome.org/show_bug.cgi?id=741946 plus the relative changes to the mir backend...
[02:42] <Trevinho> basically things have been moved to gl 3.2 APIs by default... But Not sure how I can help to fix this... I'd say it's mostly a driver issue....
[03:01] <duflu_> Trevinho: What requires GL 3.2?
[03:01] <Trevinho> duflu_: gdkgl
[03:02] <duflu> That's unfortunate. We still have Ubuntu users limited to GL 1.x which I aim to support with Mir. It would be a pity if they just can't run GTK
[03:02] <Trevinho> duflu: they can run gtk, but not gtk-gl apps
[03:03] <duflu> Ah OK
[03:03] <Trevinho> duflu: they supported legacy gl till few days ago, then they removed that as it was overcomplicating stuff for them
[03:03] <duflu> Trevinho: P.S. Sleep
[03:04] <Trevinho> duflu: so basically now in gtk you can create a gl context inside your app and make it interact with the rest
[03:04] <duflu> Trevinho: I know. I've written toolkits with GLAreas :)
[03:04] <Trevinho> duflu: I was about to go, then I got a friendly ping :)
[03:04] <Trevinho> duflu: yeah, stuff like that... arrived just a little late...
[03:05] <Trevinho> I mean, instead of putting such the efforts in clutter, maybe....
[03:08] <tmpRAOF> Trevinho: Yeah, kernel panics are very much Not Our Fault™
[03:08] <Trevinho> yes, I was wondering that...
[03:09] <Trevinho> I've not them in X, but I guess it's due to the fact it's using a different driver
[03:10] <tmpRAOF> It's not really using a different driver. Unless you're using the nvidia binary drivers for X and nouveau for Mir (or fglrx/radeon)
[03:10] <Trevinho> mh, no I'm using radeon currently... But I thought it was using an egl driver at mesa level, isn't it?
[03:11] <tmpRAOF> Yeah; GTK doesn't use EGL on X as well?
[03:12] <Trevinho> glx
[03:12] <tmpRAOF> There certainly are differences in the uses, though. If you could capture the panic it might point to something we obviously do differently and possibly wrong.
[03:12] <tmpRAOF> Huh. Fair enough.
[03:12] <Trevinho> well, I currently I've no clue how to debug that kind of panic... 😢
[03:14] <Trevinho> probably I need to ping someone with hands at lower levels than me :)
[03:14]  * Trevinho also can't build current mir without http://pastebin.ubuntu.com/10182012/
[03:14] <tmpRAOF> Yeah, we've got some weirdness with our headers at the moment.
[03:15] <Trevinho> maybe it works with pre-compiled headers, but I guess I've disabled them
[04:48] <rsalveti> Get:335 http://ftpmaster.internal/ubuntu/ vivid/main mir-platform-graphics-mesa i386 0.11.0+15.04.20150209.1-0ubuntu1 [91.6 kB]
[04:48] <rsalveti> Get:336 http://ftpmaster.internal/ubuntu/ vivid/main mir-platform-graphics-android i386 0.11.0+15.04.20150209.1-0ubuntu1 [82.4 kB]
[04:48] <rsalveti> tmpRAOF: both were installed, will check the image in a few
[04:48] <rsalveti> not sure why we're still getting the mesa package
[04:49] <rsalveti> libmirserver29 depends on it
[04:49] <rsalveti> as it's |, it seems it will always get the first
[04:50] <rsalveti> even when my seeds is forcing the android one
[05:02] <tmpRAOF> rsalveti: Garh, sorry.
[05:03] <tmpRAOF> rsalveti: I fixed that for the client platform earlier, but at that point the server loading bit hadn't landed.
[05:03] <rsalveti> right
[05:07] <tmpRAOF> rsalveti: For what it's worth: https://code.launchpad.net/~mir-team/mir/server-doesnt-depend-on-drivers/+merge/249449
[05:09] <rsalveti> tmpRAOF: great, thanks
[06:03] <duflu> Trevinho: I just tried out building Mir on trusty. There are lots of hacks required. More than you suggest. How/where are you building mir?
[08:45] <Saviq> hey guys, could someone please have a look at bug #1417773 and see if the attached traces suggest a Mir thread blocked somewhere?
[09:49]  * duflu looks at the bug
[09:53] <duflu> Saviq: Fun. Looks like some kind of deadlock in Mir's GlibMainLoop with Mir's framedropping logic
[09:54] <Saviq> duflu, that sounds fun indeed
[09:54]  * duflu shies away from owning problems he violently tried to stop from us having
[09:54] <duflu> Also it's time to make dinner
[09:55] <duflu> from us? us from.
[09:57] <duflu> Saviq: I know we did try to decide both ends of that deadlock so that deadlocks can't happen. But sounds like we're not there yet
[09:58] <duflu> Saviq: RTM running Mir 0.10? That sounds odd given https://launchpad.net/ubuntu-rtm/+source/mir
[09:59] <duflu> Oh, also a stack from 0.11
[09:59] <Saviq> duflu, my gdb output was from vivid indeed
[10:00] <duflu> Saviq: Was the actual deadlock on vivid?
[10:00] <Saviq> duflu, yes, my gdb output was from vivid 0.10 and 0.11 today
[10:00] <tmpRAOF> I don't think that analysis is correct?
[10:00] <tmpRAOF> It looks more like RPC failure?
[10:00] <Saviq> duflu, might be I misattributed the lock incorrectly
[10:00] <duflu> Saviq: OK, that needs clarification. Deadlocked on Mir 0.8 but retraced using Mir 0.10/11 symbols?
[10:01] <tmpRAOF> (Note one of the threads has blocked in recvmsg)
[10:01] <Saviq> duflu, no no
[10:01] <Saviq> duflu, the original bug was from rtm
[10:01] <Saviq> duflu, and rsalveti's trace should be from there
[10:01] <Saviq> duflu, my deadlocks were both on vivid, and retraced then and there, while the device was deadlocked
[10:02] <duflu> Saviq: rsalveti's looks quite different (dbus deadlock instead)
[10:02] <duflu> Do we have two bugs in one?
[10:02] <Saviq> duflu, very much possible
[10:03] <Saviq> duflu, there was a bunch of random lockups reported
[10:04] <duflu> Saviq: That's a huge can of worms. Time to make dinner
[10:04] <Saviq> duflu, enjoy
[10:06] <tmpRAOF> Saviq: Did you break and then continue in this backtrace?
[10:06] <Saviq> tmpRAOF, I just attached gdb and got the trace there, didn't continue
[10:07] <tmpRAOF> Saviq: So, the fact that it was blocked in recvmsg suggests that something in the RPC stack was being bogus, and the deadlock was U8 waiting for some RPC to finish.
[10:08] <Saviq> tmpRAOF, if you have any pointers as to what else should I check (continue + break) the next time I see that, please comment on the bug
[10:08] <tmpRAOF> Saviq: It might be helpful to work out what unity-system-compositor is doing when this happens.
[16:32] <greyback_> AlbertA: hey, I've got QtCreator working reasonably well using this patch on top of your use-mir-surface-types: http://pastebin.ubuntu.com/10190374/
[16:33] <greyback_> thought I should share the changes I've made, in case it helps
[16:34] <AlbertA> greyback_: cool...I've changed the branch a bit too....
[16:34] <AlbertA> :)
[16:34] <greyback_> AlbertA: ack, will pull and see
[16:41] <greyback_> AlbertA: moveResize deletes & re-creates the mir surface?! Cheeky ;)
[16:42] <AlbertA> greyback_: works for menus lol
[16:48] <racarr> in which we become what we once hated :(
[16:48] <racarr> :p
[16:54] <greyback_> :)
[16:57] <AlbertA> racarr: that's why we are going to support client resize :) it's good for the mir team to feel the pain :)
[20:49] <mlankhorst> yeah no other way :P
[20:49] <mlankhorst> soon you'll find you want to support client hit testing for cursors too
[20:50] <mlankhorst> and  then realize you want to give sub windows a cursor to make it feel more responsive
[21:19] <adrian47> Hello is there anyone who can help with:  tiny.cc/i8lytx  (porting ubuntu touch)