[11:20] <alf_> alan_g: perhaps we should go with different executables in the existing (acceptance/integration/unit) directories, e.g., acceptance-tests(-main), acceptance-tests-c89, acceptance-tests-symbol-resolution ...
[11:20] <alf_> alan_g: unit-tests, unit-tests-umockdev etc
[11:21] <alan_g> alf_: maybe (although needing umockdev seems more integration/acceptance-test to me)
[11:23] <alf_> alan_g: yeah, link-time seams blur the test category lines
[11:25] <alan_g> alf_: maybe that's the key idea: "MIR_ENABLE_SPECIAL_LINKAGE_TESTS"?
[11:27] <alf_> alan_g: that would leave out the c89 tests, MIR_ENABLE_SPECIAL_BUILD_TESTS?
[11:28] <alan_g> alf_: do we need to include the c89 test in this category?
[11:28]  * alan_g doesn't think we even need to link c89 test - it should be compile time
[11:31] <alf_> alan_g: No, we don't need to include it really, but we need to enable it by default somehow. I guess we can start with SPECIAL_LINKAGE + separate c89 and reconsider if new "special" tests arrive.
[11:32] <alf_> alan_g: hmm, or is c89 already built?
[11:32] <alan_g> alf_: I thought it was on by default (but haven't looked recently)
[11:33] <alf_> alan_g: ok, it is still there, so yes, SPECIAL_LINKAGE is good enough for now if we want to go the separate category path
[11:33] <alan_g> And using link seams does interfere with other tests, so they do make a coherent category of sorts.
[14:29] <FunnyLookinHat> Anyone here privy to the details on why Software Center is going away after 14.04? https://docs.google.com/spreadsheet/ccc?key=0AiT4gOXSkmapdGdFejk0MjFydUlNMDVoMXNRdGdkbFE#gid=1
[14:29] <FunnyLookinHat> Not sure where to ask - but trying to track down the story on this one - I presume click packages will be a replacement or something?
[14:34] <davmor2> FunnyLookinHat: the applications lens is replacing it.  On desktop that will mean support for debian and click backends aiui, best place is possibly #ubuntuone though as it controls development of software-center now
[14:34] <FunnyLookinHat> davmor2, Cool thanks!
[16:04] <olli> kgunn, Saviq http://paste.ubuntu.com/6474449/
[16:05] <olli> I followed the instructions in the unity8 wiki and am stuck at this stage
[16:05] <olli> I feel like I am missing like 1 package but can't see it straight
[16:06] <olli> kgunn, Saviq stderr is misisng, working on it
[16:06] <kgunn> olli: watch out for ancient ppa's.....i had some really old qt edger ppas that hosed me
[16:06] <olli> kgunn, this is a virign install on my new laptop
[16:06] <olli> :)
[16:07] <kgunn> olli: oh...nvmd
[16:10] <Saviq> olli, it's possible, we're in transition between in-built shell-facing scopes api and a package outside
[16:11] <Saviq> olli, not everything got released yet
[16:15] <Saviq> kgunn, ↑↑
[16:30] <alf_> kdub: are you happy with the shm-buffers-part1 MP? If you also prefer base_ptr() instead of map() it's an easy change...
[16:30] <kdub> alf_, yeah, was just reviewing
[16:31] <alf_> kdub: (I will probably need to resync with trunk anyway)
[16:31] <alf_> kdub: s/trunk/development-branch/
[16:31]  * kdub always calls development-branch trunk too
[16:36] <truebattleaxe> is anyone having any issues with the display settings after installing mir?
[16:43] <racarr> morning
[16:56] <truebattleaxe> hey
[17:42] <kdub> alan_g, with more-cleanup-of-ownership-of-client-buffers, the changes to buffer ownership will probably trickle into mc::SwitchingBundle, right?
[17:43] <alan_g> kdub: yes.
[17:43] <kdub> i'm finding some of the composition changes for overlay are tied to that class
[17:43] <kdub> trying to anticipate how we'll change
[17:43] <alan_g> kdub: I don't have anything in flight right now - so you can sneak in ahead of me
[17:44] <kdub> i don't really want to wade into it if i can help it, but it might be necessary
[17:45]  * kdub keeps looking
[17:56] <alan_g> kdub: I don't anticipate changing the logic - just the way buffers are handed out for clients. (Still playing with raw pointer vs unique handle). So I don't anticipate any conflicts with overlays
[17:59] <kdub> alan_g, okay. at the moment, i'm considering burying the 'frameno' logic back inside of mc::SwitchingBundle
[18:02] <alan_g> kdub: is that feasible? Surely there needs to be some logic associated with the (possibly concurrent) compositors?
[18:03]  * alan_g decides it is too late in the day to worry
[18:08] <kdub> the logic is needed, it just seems to me that the buffer tracker is the best place to keep it
[18:09] <kdub> instead of splitting responsibility out to the compositor and the buffer tracker
[18:09] <kdub> i'll see if its cleaner or not :)
[18:28] <Saviq> hey folks, since the recent mir release, unity8 is crashing on shutdown
[18:29] <Saviq> could you please have a look https://bugs.launchpad.net/mir/+bug/1253685
[18:29] <Saviq> from what I can see surface is deleted (surface=0x0) in inputarea.cpp
[18:30] <Saviq> greyback, fyi ↑
[18:31] <Saviq> racarr, could you have a look at this over our night ↑?
[18:31] <greyback> Saviq: hmm, ok will have a look in a bit
[18:31] <Saviq> greyback, well, it's EOD for you
[18:31] <greyback> kinda
[18:31] <greyback> did start late tho
[18:31] <Saviq> greyback, your call
[18:31] <Saviq> racarr, greyback it's very easy to reproduce - just Ctrl+C after running unity8 on the console
[18:32] <greyback> so I've another 30 mins
[18:32] <Saviq> (stop unity8 before that)
[18:32]  * Saviq puts steps to repro
[18:42] <Saviq> greyback, please try and find someone to continue past your EOD, though
[18:43] <Saviq> unless you fix it, obviously
[18:43] <greyback> Saviq: ok
[18:44] <didrocks> also, if you see it's fixed in latest Mir release, maybe we can just go ahead
[18:44] <didrocks> (with latest mir + unity-mir + platform-api)
[18:44] <didrocks> and we release that
[18:45]  * didrocks would appreciate an email about it in the morning, even if there is no progress
[18:45] <racarr> Saviq: Ok
[19:14] <greyback> racarr: if you're looking, I suspect this is the line causing the crash: line 90 of inputarea.cpp in unity-mir
[19:15] <greyback> racarr: probably that the InputArea has been destroyed before the MirSurface is
[19:26] <greyback> racarr: I've to run unfortunately, will be back in 4 hours
[19:53] <kdub> how extensively is DepthID used anymore?
[19:53] <kdub> also, recursive mutex, sad
[20:17] <racarr> greyback: Oi thanks
[20:17] <racarr> kdub: Still used to keep theshell surface on top
[20:33] <kdub> racarr, ah, okay... i can look past it for now :)
[20:34] <kdub> was just bemoaning our locking situation in surfacestack
[21:10] <kdub> the new mc::DefaultDisplayBufferCompositor::composite is beautiful