[02:47] <duflu> Why is it every time I look, Ubuntu is using a kernel that upstream has end-of-life'd ? :)
[02:47] <duflu> https://www.kernel.org/
[02:48] <duflu> We never seem to be using the long term supported ones
[09:32] <greyback_> alan_g: network dropped, have you a link to the HO?
[09:32] <alan_g> https://plus.google.com/hangouts/_/canonical.com/mir-qtmir?authuser=0
[09:37] <alan_g> tvoss: ^
[09:37] <tvoss> alan_g, ack
[14:07] <kdub> its gotten tricky to be sure whats the source of a CI failure
[14:15] <kdub> hmm, anyone know anything about glmark breaking with abi changes? I've found https://bugs.launchpad.net/mir/+bug/1341490, but what I see seems slightly different
[14:15] <kdub> because i shouldnt be bumping or breaking anything in https://code.launchpad.net/~kdub/mir/multiple-bufferstream-api/+merge/261123
[14:28] <alan_g> kdub: the most recent problem with glmark was that the version of libmirclient8 from 0.12 loaded libmircommon3 but the 0.14 drivers that were loaded also loaded libmircommon4
[14:28] <alan_g> Once 0.13 hit archive that "went away"
[14:31] <kdub> hmm, dunno if thats what i'm hitting in this problem
[14:33] <alan_g> I doubt it.
[15:30] <AlbertA> kdub: another MP is also hitting the same glMark issue... https://code.launchpad.net/~raof/mir/input-methods-can-specify-foreign-parents/+merge/258001
[15:31] <kdub> AlbertA, right, and that one adds another function to the mir_surface api too....
[16:03] <kdub> so the glmark definitely is a loading mirclient8 when mirclient9 should be loaded
[16:03] <kdub> issue
[16:05] <AlbertA> kdub: oh is it loading libmirclient8 then using the built libmirprotobuf.so.0 from the cI build?
[16:06] <kdub> possibly, have been able to get a backtrace
[16:06] <kdub> http://pastebin.ubuntu.com/11690920/
[16:08] <AlbertA> kdub: but in any case, do we even want a libmirclient8 talking to a server released with libmirclient9?
[16:09] <kdub> probably not
[16:09] <kdub> maybe we need to bump the protobuf number?
[16:09] <AlbertA> kdub: seems like we need to disable glmark for now since we bumped client ABI until release...
[16:10] <kdub> AlbertA, because we don't build glmark against the code that's being landed?
[16:11] <AlbertA> kdub: right. it's just a package dep
[16:13] <AlbertA> kdub: or rather I guess it's just a package installed by the mir mako runner scripts
[16:23] <kdub> hmmm
[16:28] <AlbertA> kdub: so looking at RAOF's branch - protobuf seems like the only suspect to cause the glmark crash...
[16:30] <AlbertA> probably stack protobuf objects that are now a different size in the new libmirprotobuf.so.0....
[16:31] <AlbertA> do we have libmirprotobuf as an .so to share between client and server?
[16:32] <AlbertA> it does seem like we need to bump the protobuf ABI then....
[16:33] <AlbertA> or at least when we bump libmirclient ABI
[16:33] <AlbertA> and there's been a protobuf change
[16:46] <kdub> AlbertA, right, that seems sensible to me too
[17:16] <racarr> whee...all my tests passing now and working on device for touch stream rewriter...just code cleanup now.
[17:17] <alan_g> You enjoy cleaning up code?
[17:23] <racarr> alan_g: I feel like you are kind of pointlessly mean to me sometimes
[17:23] <racarr> (e.g. above)
[17:24] <racarr> sorry I'm sure you consider it as having intent
[17:24] <racarr> and are trying to communicate something to me
[17:24] <alan_g> racarr: actually I'm glad you are not tempted to skip the "clean up" bit.
[17:24] <racarr> but I don't really appreciate it when it's phrased like that
[17:25] <alan_g> I was just amused by your phrasing
[17:25] <alan_g> Sorry that it read differently
[17:25] <racarr> lol I understand sorry.....
[17:25] <racarr> no, my fault lol
[17:26] <conyoo> o_O
[17:28] <alan_g> no, no, my fault. I was careless in my phrasing.
[17:29] <racarr> such is our internet life.
[18:07] <bschaefer> mterry, would deb2snap work on armhf?
[18:07]  * bschaefer only saw x86/x64 libs on it
[18:08]  * bschaefer tests it out
[18:11] <mterry> bschaefer, heyo -- it would work, but you may have to do it inside an armhf machine
[18:11] <mterry> s/may//
[18:12] <bschaefer> mterry, right, its what i was thinking i would have to do
[18:12] <mterry> bschaefer, it *should* work
[18:12] <bschaefer> mterry, as it looks like it does some fun ldd work :)
[18:12] <bschaefer> haha yeah :)
[18:12] <bschaefer> *should* work is usually worth a try
[18:12] <bschaefer> mterry, thanks!
[19:48] <kgunn> mterry: hey before i let the day get away from me....again...i'm going through review comments on my attempt to upload mir snap to store
[19:48] <mterry> kgunn, oooh OK
[19:49] <kgunn> and one question was about the global socket vs user
[19:49] <kgunn> i mean on one hand i guess you could argue it doesn't matter for the type of device
[19:49] <kgunn> e.g. it's probably not gonna have multiple apps
[19:50] <kgunn> but just wondering, was there something troubling about using the var/run/user/*/mir_socket
[19:51] <kgunn> ?
[19:52] <kgunn> mterry: ^
[19:52] <kgunn> or is that just what mir_demos* use...
[19:52] <mterry> kgunn, didn't try it, but I thought compositors were expected to be per-device, not per-user
[19:53] <kgunn> mterry: i guess that is true for a "system compositor"
[19:54] <kgunn> altho in ubuntu touch i think u-s-c is actually per user....?
[19:54] <mterry> kgunn, no even there it's run as root for the whole system
[19:54] <mterry> kgunn, (otherwise it'd be hard to do the split greeter, which runs as a separate user)
[19:54] <mterry> kgunn, unity8 is its own compositor of course (for the user).  But u-s-c is system wide
[19:55] <kgunn> holy crap...just grabbed krillin, it's been on for 3 days idling hardly any battery gone...impressive
[19:55] <mterry> kgunn, I'm .. pleasantly shocked?   :)
[19:55] <kgunn> me too
[19:56] <kgunn> mterry: ok, thanks...i think i've got the ammo to argue that one away now
[19:59] <kgunn> mterry: one last one...i got dinged on confinement, so doing a lot of reading....is it just "work" ? or is there some mystery there....
[19:59] <kgunn> guessing you know from being a snappy dude now :)
[19:59] <mterry> kgunn, can you explain that a bit?
[19:59] <racarr> Lunch!
[20:00] <mterry> kgunn, I can explain the current Mir confinement a bit?  Or are you talking about something else?
[20:00] <kgunn> mterry:  security_template_valid (meta/system-compositor.apparmor)
[20:00] <kgunn> 	(MANUAL REVIEW) 'unconfined' not allowed
[20:00] <kgunn> Why is this running unconfined? Framework services and binaries should also all run under confinement.
[20:01] <mterry> kgunn, ah yes
[20:01] <mterry> kgunn, that was laziness on my part
[20:01] <mterry> kgunn, so just "work"
[20:01] <kgunn> you lazy so and so
[20:01] <mterry> kgunn, there needs to be some investigation on what exactly u-s-c needs
[20:01]  * kgunn keeps reading hoping for a payoff...
[20:01] <mterry> kgunn, so basically that's likely just running it confined and seeing what DENIED comments you get in syslog
[20:02] <mterry> kgunn, and then crafting an apparmor file with exceptions
[20:02] <mterry> kgunn, similar to the apparmor file for clients
[20:02] <kgunn> ok
[20:02] <mterry> kgunn, in meta/framework-policy/
[20:02] <kgunn> mterry: yep...i'm familiar :)
[20:02] <kgunn> i've already made some mods
[20:02] <mterry> kgunn, that one I did put some thought into and worked with jdstrand a bit to tighten it as possible
[20:02] <mterry> kgunn, oh good
[20:03] <mterry> kgunn, I figured it was more important to get that right than worry about the server side of things, which is something we wrote
[20:03] <mterry> kgunn, but I guess the store reviewers/admins didn't see it that way  ;)
[20:03] <kgunn> which btw, are you ok for me to just push changes to snappy-packaging ?....or, should i keep a seperate branch
[20:03] <mterry> kgunn, naw that's fine.  I put it under mir-team so that it could be edited as needed
[20:03]  * kgunn has been known to tear up steele balls with rubber hammers