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