[00:15] <rsalveti> kgunn: kdub: got unity8 running with mir on my n7
[00:15] <rsalveti> without the compositor
[00:16] <rsalveti> just had to fix a few permission errors
[00:16] <rsalveti> will be pushing this soon
[00:16] <kgunn> hey...that's awesome
[00:16] <kdub> yay :)
[00:16] <kdub> kgunn, we might want to add an option to override to fallback display mode
[00:17] <kgunn> kdub: sorry, context ?
[00:17] <kdub> oh, we had to force the n7 into the fallback by hiding files
[00:18] <kdub> would just be nicer if a command line switch would cause that operation mode
[00:20] <kgunn> robert_ancell: i was gonna step away for an extended period - if you would, ta that mp (if its correct) and then once it merges...queue a merge of dev-> trunk
[00:20] <kgunn> i'll be back later
[00:20] <robert_ancell> kgunn, ok, bye
[00:26] <rsalveti> kdub: yeah, a command line or similar would be nice indeed
[00:27] <rsalveti> or even if internally atm, by getting the property and not using it in case of grouper
[00:27] <rsalveti> would that be possible?
[00:29] <kdub> hmm, not without expanding our options to include the android properties
[00:29] <kdub> it is a good idea though
[01:52] <robert_ancell> kgunn, https://code.launchpad.net/~mir-team/mir/development-branch/+merge/190004
[02:02] <kgunn> robert_ancell: hey...back...uh-oh... duflu says there's conflicts
[02:03] <duflu> Yes, umm, chat amongst yourselves :/
[02:04] <robert_ancell> kgunn, duflu, that happened last time - it's just debian/changelog getting confused
[02:04] <robert_ancell> I've manually pushed a merge for that
[02:04] <robert_ancell> hmm, though LP says otherwise
[02:05] <robert_ancell> merges locally fine..
[02:06] <duflu> robert_ancell: If the conflicts aren't real then that just means its a metadata conflict. You need to merge the destination back into the source, commit it, and then propose merging the source back to destination.
[02:06] <robert_ancell> done it
[02:06] <duflu> This was bound to happen landing fixes in lp:mir directly
[02:06] <robert_ancell> waiting for LP to notice
[02:09] <robert_ancell> kgunn, duflu, https://code.launchpad.net/~mir-team/mir/development-branch/+merge/190008 seems ok now
[02:09] <kgunn> thanks robert_ancell
[02:15] <robert_ancell> kgunn, do you wait for didrocks to top approve mps like https://code.launchpad.net/~kgunn72/unity-system-compositor/bump-mir-dep14/+merge/190012?
[02:15] <kgunn> robert_ancell: yeah...well, that's what i've done the last 2 times...
[02:15] <kgunn> and it worked and no one got mad
[02:20] <kgunn> robert_ancell: duflu thanks guys...i'm gonna duck out at a decent time tonight...please keep an eye on that mp such that it merges
[02:20] <robert_ancell> kgunn, enjoy your evening!
[02:20] <robert_ancell> well, night
[02:21] <kgunn> thanks! (going to nurse my headache i developed)
[04:18] <robert_ancell> thomi, is the mir autolanding broken in the same was as lightdm was? We have https://code.launchpad.net/~mir-team/mir/development-branch/+merge/190008 but http://10.97.0.26:8080/job/mir-autolanding/? shows nothing building
[04:20] <thomi> robert_ancell: maybe they turned it off?
[04:20] <thomi> want me to trigger that manually for you now?
[04:21] <robert_ancell> thomi, yes please. I just asked in #ubunut-ci-eng if it's intentionally turned off but no response
[04:21] <robert_ancell> kgunn wanted that to land
[04:26] <thomi> robert_ancell: http://10.97.0.26:8080/job/mir-autolanding/709/console
[04:26] <robert_ancell> thomi, ta
[04:27] <robert_ancell> bbl
[04:35] <olli> thomi, we stopped the upstream merger
[04:35] <olli> not sure if related
[04:35] <thomi> olli: ahhh.. why's that?
[04:36] <olli> so we can land mir
[04:36] <olli> robert_ancell, was anounced on ue-leads and ubuntu-phone
[04:37] <thomi> OK... I don't understand why we need to turn it off to do that, but oK. I trust my triggering it manually for mir and lightdm hasn't caused any problems
[04:47] <olli> it might, dunno
[04:48] <olli> asac, will be able to tell when he is awake
[05:56] <duflu> Stupid audio settings...
[06:03] <RAOF> Hm.
[06:03] <RAOF> Apparently my internet is all screwy.
[06:05] <RAOF> That's not working very well at all, is it.
[06:38] <duflu> RAOF: Pretty-please; https://bugs.launchpad.net/xmir/+bug/1233044
[06:40] <RAOF> duflu: Ah. Had fixed that locally, but github didn't have it.
[06:41] <duflu> Figures. Otherwise it's obvious no one's looked at the code in a while...
[08:41] <alan_g> duflu: alf_ - @SIGPIPE can you agree on whether we should handle it?  FWIW it is "Term" (not "Core") in posix
[08:42] <duflu> alan_g: Yeah I meant it normally kills the server. Even if it doesn't cause a core by default
[08:42] <duflu> Hmm, I wonder if that's accurate. Otherwise we couldn't get any SIGPIPE crash reports
[08:43] <duflu> Oh, the crash is because we make it an exception?
[08:43] <alan_g> The crash is because we allow an exception to propagate off the end of the stack
[08:53] <alan_g> duflu: does the latest rev address your other comment? https://code.launchpad.net/~alan-griffiths/mir/remove-endpoint-first-when-shutting-down/+merge/189376
[08:54] <duflu> alan_g: Looks better but will take me some time to test it and verify core dumps and debugability
[08:56] <alan_g> duflu: I couldn't come up with a simple test for a core dump - given that valgrind doesn't produce a core named "core" - any ideas?
[08:57] <duflu> alan_g: Set up a pre-existing handler in the test and ensure the old handler gets called eventually?
[08:58] <alan_g> duflu: maybe, although that doesn't prove that a core is produced.
[08:59] <duflu> alan_g: No, it's possibly beyond the scope of in-process testing
[09:00] <cjwatson> Hey - just pushed up https://code.launchpad.net/~cjwatson/mir/arm64-no-valgrind/+merge/190051.  Any hope of getting that merged in time for saucy?  We're racing to get the new arm64 port as complete as possible, and of course there's a batch of stuff queued up behind mir now.
[09:00] <cjwatson> (I don't know for sure that this isn't going to run into https://bugs.launchpad.net/mir/+bug/1195590, but even if it does it's still an improvement)
[09:05] <alan_g> cjwatson: Approved - just waiting on CI
[09:06] <cjwatson> Great, thanks
[09:12] <pete-woods> tvoss: good morning! could you possibly have a look at a (hopefully trivial) MR for unity-mir (https://code.launchpad.net/~pete-woods/unity-mir/window-stack-get-property/+merge/189984)
[09:12] <alf_> duflu: alan_g: don't we get sigpipe ourselves when trying to write to closed socket? I think SIGPIPE is a recoverable error in general...
[09:12] <duflu> alf_: Yeah fair point
[09:13] <duflu> Although this is all about handling /unexpected/ signals
[09:13] <duflu> Which SIGPIPE could still be
[09:17] <alf_> duflu: The problem is that we don't have any control of the code that lives in the same process as us. Case in point is libcrypto, which uses SIGILL on ARM to check the presence of special instructions :/
[09:18] <duflu> That's a good reason to never use other peoples' code :)
[09:18] <duflu> But SIGPIPE is not important...
[09:19]  * alf_ is convinced and starts hacking on his own BIOS code :)
[09:37] <asac> do you guys have a way to work on the crashers/issues with mir image?
[09:37] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/
[09:38] <asac> i think its mostly maliit, unity8 and hud crashes that are coming in
[09:38] <asac> olli: ^^
[09:41] <duflu> asac: The methodology is log bugs against unity8 or mir, and they will be triaged accordingly.
[09:41] <duflu> Not sure what you mean though
[09:42] <asac> duflu: we have landed mir by default
[09:42] <asac> duflu: deal was that mir team would be all on fixing everything
[09:42] <asac> duflu: you guys should look and crunch out things
[09:42] <asac> without us filing bugs
[09:43] <asac> everything that isnt happening here: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/mako/88:20131009:20131008.2/4628/
[09:43] <asac> but that happens here:
[09:43] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/88:20131009:20131008.2/4626/
[09:43] <asac> is a mir regression
[09:43] <asac> duflu: ^^
[09:43] <duflu> asac: A bug does not exist unless it's a bug in LP. Please don't encourage people to track things entirely in IRC or elsewhere...
[09:43] <asac> its on you guys to file bugs etc.
[09:44] <duflu> And we do. Whenever we find one
[09:44] <asac> duflu: so are you working on unity8 and maliit and hud crahes?
[09:44] <asac> those are the ones we see all the time
[09:45] <duflu> asac: I can't because my phone is being repaired. But I am working on what I can with a PC
[09:45] <tvoss> asac, duflu is not, gusch is looking into maliit crashes, pete-woods is looking into hud crashes
[09:45] <asac> tvoss: well, i didnt ask him
[09:45] <tvoss> asac, ?
[09:45] <asac> he replied stating "dont care if there is no bug"
[09:46] <asac> http://paste.ubuntu.com/6213070/
[09:46] <asac> olli: ^^
[09:48] <asac> duflu: please spare your comments next time. All i asked about was trying to figure was if you guys are able to work with what we produced and crunch down bugs while we do a respin that makes mir the default proper
[09:51] <asac> tvoss: do you know who is looking at unity8 crashes?
[09:51] <asac> thostr?
[09:51] <tvoss> asac, I thought we agreed yesterday that we first tackle hud and osk crashes to eliminate variables?
[09:54] <asac> tvoss: depends. i think we see the crash, so if we have someone who is qualitied, we should avoid loosing time and have people look
[09:54] <asac> note: if we have someone who is qualitied.
[09:55] <asac> :)
[09:55] <tvoss> asac, I think with some people being at qtdevdays, we are using our available resource quite well right now
[09:56] <asac> and those guys cant come back to arms?
[09:57] <tvoss> asac, greyback is available in #phablet
[09:58] <asac> cool
[09:58] <greyback> tvoss: I'm still at a conference, so I'm not very available
[09:58] <greyback> asac: ^^
[09:58] <tvoss> greyback, ack, just saying: you are helping as much as possible
[09:58] <greyback> doing my best
[09:58] <asac> greyback: how long wil lthe conf go?
[09:58] <greyback> asac: today is the last day
[09:59] <asac> greyback: ok. dont know if a conference is more important than making mir-by-default shine, but...
[09:59] <asac> :)
[10:00] <asac> anyway. if you help as much as you can thats good enough i hope until the US wakes up
[10:54] <alf_> alan_g: ok to top-approve remove-endpoint-first-when-shutting-down ?
[10:54] <alan_g> alf_: If you're happy with the latest iteration
[10:56] <alf_> alan_g: hmm, "If the signal handler is called as a result of abort or raise, the behavior is undefined if any of the following requirements is not followed:
[10:57] <alf_> the signal handler calls raise.
[11:05] <alf_> alan_g: ignore ^^, it's only if we raise the signal ourselves in the first place
[11:10] <alf_> alan_g: ...but we are doing exactly that in the tests
[11:32] <lool> Folks, in case you were on #88 and thought it had Mir by default, update to #89 which does  ;-)
[11:33] <lool> (confirmed enabled in #89)
[12:16] <jibel> kgunn, FTR, I got bug 1236525
[12:16] <jibel> kgunn, FTR, I got bug 1236525 on 1rst boot after flashing #89
[12:43] <alf_> ricmm_: Could you please take a look at https://code.launchpad.net/~afrantzis/platform-api/fix-1236225/+merge/189954 ?
[12:44] <alf_> Saviq: Could you please take a look at https://code.launchpad.net/~afrantzis/qtubuntu/fix-1237052/+merge/190113 ?
[12:45] <Saviq> alf_, looking
[12:47] <Saviq> alf_, would that be https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1234609 ?
[12:50] <alf_> Saviq: no, 1234609 is a server side crash, and is solved by Robert's hold-surface-alive MP (plus the unity-mir fix-1236898 for leaks/memory errors)
[12:50] <alf_> Saviq: 190113 is a client-side crash
[12:50] <Saviq> alf_, ok, it looks good, any way to test the fix?
[12:51] <Saviq> alf_, ah well
[12:51] <Saviq> alf_, so it is that bug
[12:51] <Saviq> alf_, just that this part is client-side - the other is server side
[12:51] <Saviq> alf_, got it
[12:51] <alf_> Saviq: well, the cause is not the same though, just the trigger conditions (app closing itself)
[12:51] <Saviq> alf_, ok
[12:55] <alf_> Saviq: to manually test, check the instructions in https://bugs.launchpad.net/qtubuntu/+bug/1237052, we could probably make an automatic test for this using the close.qml. Does qtubuntu have automatic test infrastructure?
[12:56] <Saviq> alf_, not sure it does
[12:56] <Saviq> ricmm_, ↑ ?
[12:57] <Saviq> alf_, looks like manual tests only
[13:06] <kgunn> Saviq: do you have a sim ?
[13:06] <Saviq> kgunn, plenty
[13:06] <kgunn> Saviq: assuming you're on image88....
[13:07] <kgunn> Saviq: can you turn on mir with a locked sim ?
[13:07] <kgunn> Saviq: do you get a prompt
[13:07] <Saviq> kgunn, sounds like we dropped a ball there
[13:07] <kgunn> :)
[13:08] <Saviq> kgunn, I don't think anything is talking to ofono for SIM PIN yet
[13:08] <Saviq> kgunn, we support it in the shell
[13:08] <Saviq> kgunn, but indicator-network doesn't yet ask for it
[13:08] <Saviq> pete-woods, can you confirm ↑?
[13:08] <kgunn> Saviq: ah...so backend....so we flog ted :)
[13:09] <Saviq> kgunn, yeah, I don't think there's a backend for that indeed
[13:10] <kgunn> pete-woods: so getting the "hey this doesn't work on mir" noise....can you confirm whether or not there is something "on the way" ??
[13:10] <pete-woods> kgunn: https://bugs.launchpad.net/unity-mir/+bug/1233992
[13:10] <pete-woods> Saviq: https://code.launchpad.net/~nick-dedekind/indicator-network/simunlock.dialog/+merge/185810
[13:11] <pete-woods> Saviq: I'm guessing that work needs to be completed + merged
[13:12] <pete-woods> kgunn: the fix works now, but obviously it's being tested (and going through code review)
[13:12] <Saviq> pete-woods, right, so no one is looking at it yet...
[13:13] <pete-woods> Saviq: probably true
[13:13] <kgunn> lool: ^ to track it...those are the relevant links
[13:15] <tvoss> alf_, can I ask you to just refactor alan's branch to RAII?
[13:15] <tvoss> alf_, we would like to have something testable fast
[13:15] <alf_> tvoss: then I am OK with this as a quick fix
[13:16] <tvoss> alf_, ack
[13:16] <tvoss> alf_, just (h)approve then :)
[13:18] <lool> kgunn: ok
[13:19] <lool> tvoss: is the alan_g branch this one? https://code.launchpad.net/~alan-griffiths/mir/remove-endpoint-first-when-shutting-down/+merge/189376
[13:19] <tvoss> lool, https://code.launchpad.net/~alan-griffiths/mir/lock_guard-for-unique_lock/+merge/190101
[13:21] <lool> tvoss: do you know about the endpoint thing above?  seems to be devel branch only, not trunk
[13:21] <lool> kgunn: (note that we need these in trunk)
[13:22] <tvoss> lool, it's a cleanup measure
[13:22] <kgunn> lool: no no...its in mir trunk
[13:22] <kgunn> lool: please see https://code.launchpad.net/~mir-team/mir/development-branch/+merge/190008
[13:22] <lool> kgunn: yes, but couldn't find the remove-endpoint commit
[13:23] <lool> kgunn: rechekcing
[13:23] <kgunn> lool: sorry...i'm confusing....i mean for socket moving
[13:23] <kgunn> lool: for the cleanup stuff for osk, its only under test as an mp, not landed on dev or trunk yet
[13:24] <kgunn> lool: for the socket move, its listed as  Change default filesystem endpoint to $XDG_RUNTIME_DIR/mir_socket.
[13:24] <kgunn>   (LP: #1236912)
[13:24] <lool> kgunn: https://code.launchpad.net/~alan-griffiths/mir/remove-endpoint-first-when-shutting-down/+merge/189376 is in devel, not in trunk
[13:24] <lool> kgunn: Right, what I was saying earlier is let's try to land all the Mir branches in the pipe (approved or merged in devel) into trunk, then do the Mir upload
[13:25] <lool> kgunn: I understand the two missing from trunk right now are at least https://code.launchpad.net/~alan-griffiths/mir/remove-endpoint-first-when-shutting-down/+merge/189376 and https://code.launchpad.net/~alan-griffiths/mir/lock_guard-for-unique_lock/+merge/190101
[13:25] <lool> kgunn: thanks for the link to the sim card thing
[13:25] <mterry> if anyone has a few minutes, I'd love a review of the tiny https://code.launchpad.net/~mterry/unity-mir/permissions/+merge/189718
[13:25] <lool> pete-woods: Can we log a bug to add tests for sim unlock indicator and merge it?
[13:25] <kgunn> lool: ack
[13:25] <davmor2> kgunn: maguro is still hitting the issue that it clean locks up under mir, you can't get into the device via adb, if you are connected and it happen you are kicked from adb and can't get back in.  Next time it happens what useful stuf can I grab for you?
[13:26] <pete-woods> lool: I have no idea if it even works, I also have no intention of blocking that merge
[13:26] <pete-woods> it was just a random comment on it
[13:26] <lool> mterry: Looks good to me, but can't top approve it
[13:26] <lool> mterry: What is the symptom we were seeing before this change?
[13:26] <davmor2> kgunn: oh and you have to rip the battery out in order to get the phone back up
[13:26] <lool> pete-woods: Ok; I think you should file a bug because we wont revisit the merge once it has landed
[13:27] <lool> pete-woods: :-)
[13:27] <lool> pete-woods: Also, is someone testing that it works with a sim card?
[13:27] <kgunn> davmor2: grab var/crash of course, and all the logs from homet/phablet/.cache/upstart
[13:27] <pete-woods> lool: not that I'm aware of, it doesn't look like anyone is even looking at it, I just came across it
[13:27] <Saviq> alf_, after building / installing just qtubuntu, I'm still getting a crash - but that's probably the other one?
[13:28] <alf_> Saviq: probably so, I can tell you for sure if you can get a backtrace
[13:28] <mterry> lool, unity8 couldn't receive signals from non-root daemons because it owned com.canonical.Unity.Screen
[13:29] <mterry> lool, because of the deny send_dentination=com.canonical.Unity.Scren
[13:29] <lool> kgunn: Hmm can you gather the status from dednick in some way?
[13:30] <lool> what's his IRC nick?  is he on leave today?
[13:30] <kgunn> lool: about to have our standup
[13:30] <lool> mterry: what was failing that I could witness?
[13:30] <davmor2> kgunn: the crash files were useless last time I had iirc but I'll have another look.  I'll grab all the /home/phablet/.cache stuff though.  I'll do another fresh flash now and see if I can make some reproducible steps
[13:30] <lool> kgunn: great
[13:30] <lool> kgunn: thanks
[13:30] <mterry> lool, infographics couldn't be updated
[13:30] <lool> mterry: Ok; great
[13:30] <mterry> lool, (with mir
[13:31] <lool> pete-woods: can you review unity-mir changes?  would you mind reviewing https://code.launchpad.net/~mterry/unity-mir/permissions/+merge/189718?  trivial from what I can tell
[13:48] <pete-woods> lool: I've also approved, it's definitely sane
[13:49] <lool> pete-woods: thanks
[13:49] <lool> pete-woods: but not top approved?
[13:50] <pete-woods> lool: does top approve mean anything anymore?
[13:50] <pete-woods> (I've top approved now)
[13:54] <lool> pete-woods: Well you have a point there I guess  :-)
[13:54] <lool> pete-woods: Let's stick to top approving to mean it can go in though  :-)
[13:54] <lool> pete-woods: I've poked fginther to land it
[13:54] <pete-woods> :)
[13:59] <mterry> lool, pete-woods: what can I do to convince the powers that be that this fix is important enough to land before freeze?
[13:59] <mterry> And if that happens, do I manually merge it?
[14:00] <pete-woods> mterry: er, one of the front page features of ubuntu touch doesn't work without it? (the infographics)
[14:00] <pete-woods> surely that's reason enough
[14:00] <mterry> pete-woods, correct
[14:00] <mterry> I agree, but I have to convince someone first, I imagine, now that we disabled merging
[14:00] <pete-woods> mterry: see comment above from lool about pinging for merge
[14:01] <tvoss> lool, can you help mterry here?
[14:01] <mterry> oh I didn't see
[14:01] <mterry> Yeah, I must not have scrollback that far
[14:01] <pete-woods> what, 20 lines? :p
[14:02] <mterry> ah, "I've poked fginther to land it"
[14:02] <mterry> cool, thanks lool !
[14:02]  * mterry feels better about the phone already
[14:03] <lool> mterry: I've pinged to get it reviewed and landed already
[14:03] <lool> tvoss: I've done all things already!
[14:03] <tvoss> lool, awesome
[14:03] <mterry> lool, sorry  :)  I missed your comment about fginther originally
[14:03] <lool> Ok
[14:03] <kgunn> alan_g: so did either of the 2 mp's that just landed on dev branch break client api ?
[14:03] <lool> worst case we should hand merge it
[14:04] <alan_g> kgunn: looking
[14:04] <kgunn> alan_g: "they" haven't taken trunk w the server break/bump yet...so we could do one more merge and be ok (_if_ client is ok)
[14:04] <Saviq> alf_, ugh, I'm getting completely nothing in the backtrace...
[14:05] <alf_> Saviq: I guess the other way is to apply https://code.launchpad.net/~afrantzis/platform-api/fix-1236225/+merge/189954 and see if it fixes things
[14:06] <Saviq> alf_, trying that, then
[14:06] <alan_g> kgunn: "frontend: Remove the endpoint first when shutting down. Fixes: https://bugs.launchpad.net/bugs/1235159." and "Merge with trunk" should be fine
[14:12] <alan_g> kgunn: and we now have -r1120 "client: use lock_guard as it is simpler than unique_lock." - which is also safe
[14:12] <kgunn> alan_g: thanks...
[14:12] <kgunn> alan_g: i'll propose a dev branch merge to trunk
[14:12] <alan_g> kgunn: I'll drink to that. ;)
[14:13] <alan_g> kgunn: we should also merge trunk to dev. (C.f. https://code.launchpad.net/~cjwatson/mir/arm64-no-valgrind/+merge/190051)
[14:14] <kgunn> alan_g: should i do that first?
[14:14] <kgunn> or...guess it doesn't matter
[14:14] <kgunn> order
[14:14] <alan_g> Nope, it can wait
[14:15] <kgunn> alan_g: ok...ready i think https://code.launchpad.net/~mir-team/mir/development-branch/+merge/190142
[14:16] <alan_g> kgunn: approved
[14:19] <ricmm_> alf_: approved
[14:20] <alf_> ricmm_: thanks!
[14:20] <kgunn> lool: mir trunk  now has the 2 mp's on it (1 cleanup change to help osk and 2 the removing endpoint)
[14:21] <kgunn> lool: in the past, didrocks would approve the 3 mp's on unity-mir, u-s-c, platform-api....
[14:21] <kgunn> lool: in order to bump the api properly on the build
[14:22] <kgunn> lool: so am i ok to assume you will do the approval of those ? (i'll add you as specific reviewer)
[14:22] <alan_g> kgunn: I don't see that on trunk yet
[14:23]  * alan_g knows we're in different timezones but...
[14:24] <kgunn> alan_g: sorry...lool he is right...waiting on merger https://code.launchpad.net/~mir-team/mir/development-branch
[14:25] <alan_g> kgunn: if you're in a hurry we can merge "by hand"
[14:26] <Saviq> alf_, approved
[14:27] <alf_> Saviq: Great, thanks. I guess that applying the second patch fixed the issue then?
[14:27] <Saviq> alf_, no, but I just don't have all the bits - and the code makes sense
[14:28] <alf_> Saviq: no = it didn't fix it, or no = you didn't try?
[14:28] <Saviq> alf_, didn't fix, I'm trying one more thing, though
[14:28] <Saviq> alf_, with the platform-api and the qtubuntu fixes, it should not crash client-side?
[14:28] <Saviq> alf_, what about server-side?
[14:29] <alf_> Saviq: the server side is not (or rather, should not be) affected by these patches
[14:30] <Saviq> alf_, yeah, but that's the thing - if it crashes server-side anyway
[14:30] <Saviq> alf_, k, building packages from qtubuntu and platform-api again, then
[14:31] <alf_> Saviq: right, I am already using the server side fix locally...
[14:31] <Saviq> alf_, yeah - that's why I'm saying I'm missing the server-side piece
[14:31] <Saviq> alf_, let me get that, actually
[14:31] <alf_> Saviq: yeah, if the server crashes all bets are off...
[14:32] <Saviq> alf_, why is https://code.launchpad.net/~robertcarr/mir/hold-surface-alive/+merge/189400 not approved yet, btw?
[14:33] <alf_> Saviq: More information is need by some engineers about the why and how.
[14:33] <Saviq> alf_, k
[14:35] <alf_> Saviq: for the server side fix you also need the latest unity-mir trunk (actually r106)
[14:36] <Saviq> alf_, r106?
[14:36] <alf_> Saviq: I mean r106 contains the change we care about
[14:37] <Saviq> alf_, ah unity-mir
[14:37] <Saviq> alf_, sorry, read that as "mir"
[14:41] <lool> kgunn: I can approve the mps
[14:41] <lool> kgunn: which one do I need to approve still?
[14:54] <kgunn> lool: so when mir trunk is ready (e.g. this one is merged https://code.launchpad.net/~mir-team/mir/development-branch)
[14:55] <kgunn> lool: these will be the additional ones needed approval/merging
[14:55] <kgunn> unity-mir
[14:55] <kgunn> https://code.launchpad.net/~kgunn72/unity-mir/bump-mir-dep14/+merge/190010
[14:55] <kgunn> platform-api
[14:55] <kgunn> https://code.launchpad.net/~kgunn72/platform-api/bump-mir-dep14/+merge/190011
[14:55] <kgunn> unity-system-compositor
[14:55] <kgunn> https://code.launchpad.net/~kgunn72/unity-system-compositor/bump-mir-dep14/+merge/190012
[14:56] <rsalveti> kgunn: kdub_: with latest image on grouper you should have mir running by default
[14:56] <rsalveti> so people can still test mir related stuff with n7
[14:58] <kgunn> alan_g: can you manually merge - i believe autolanding is off
[14:58] <kgunn> brb
[14:59] <alan_g> kgunn: Sure
[15:00] <alf_> kgunn: and qtubuntu
[15:02] <dholbach> hiya
[15:02] <lool> kgunn: the three mps look good obviously
[15:02] <lool> kgunn: ping me when mir is merged
[15:03] <dholbach> I get quite a bit of flickering and slowness and almost freezing on grouper (r89) - is this a known issue? https://bugs.launchpad.net/mir/ and https://bugs.launchpad.net/unity-mir/ have a few critical issues, but none of them look like what I'm seeing
[15:03] <tvoss> dholbach, grouper is n7, right?
[15:03] <dholbach> yep
[15:05] <tvoss> dholbach, mir won't work correctly with the nvidia driver due to a hybris issue
[15:05] <ogra_> tvoss, thats fixed
[15:05] <tvoss> ogra_, really? well then it should work
[15:05] <ogra_> tvoss, 89 should work fine (despite BT eating your CPU)
[15:05] <tvoss> ogra_, how so?
[15:05] <ogra_> udev rule fixes afaik
[15:05] <ogra_> made Mir work
[15:06] <ogra_> ask rsalveti details, i only saw the upload pass by
[15:06] <tvoss> ogra_, would really surprise me
[15:06] <ogra_> permissions fo rteh graphics devices were all wrong
[15:07] <tvoss> ogra_, hmmm .. let's check with kdub
[15:07] <tvoss> kdub_, ping
[15:07] <alan_g> lool: kgunn mir has landed
[15:08] <rsalveti> tvoss: had to disable hwcomposer and fix a few deps
[15:08] <rsalveti> dholbach: that's because latest image is using mir
[15:08] <rsalveti> a lot slower when comparing to sf
[15:09] <rsalveti> and still having some crashes
[15:09] <dholbach> rsalveti, do you know if there's a bug for it?
[15:09] <tvoss> rsalveti, how did we solve the issue with the nvidia driver using shared mutexes on n7?
[15:09] <lool> pete-woods: can't top approve this one, would you do it for me please?
[15:10] <pete-woods> lool: which one?
[15:10] <rsalveti> tvoss: hwcomposer requires shared mutex, that's I had to disable it
[15:10] <kdub_> tvoss pong, but in a standup atm
[15:10] <rsalveti> dholbach: not that I know, we just enabled it
[15:10] <dholbach> rsalveti, ok I'll file a bug
[15:11] <rsalveti> dholbach: look for crashes at /var/crash as wlel
[15:11] <dholbach> is there any additional information I could put in there?
[15:11] <dholbach> like a log
[15:11] <lool> pete-woods: sorry EPASTE
[15:11] <lool> pete-woods: https://code.launchpad.net/~kgunn72/unity-mir/bump-mir-dep14/+merge/190010
[15:11] <pete-woods> EPASTE!
[15:12] <pete-woods> I dont know why that made me laugh
[15:12] <dholbach> rsalveti, doesn't look like it
[15:12] <rsalveti> dholbach: then just a bug with the behavior should be good
[15:13] <dholbach> yep
[15:17] <dholbach> popey, rsalveti, tvoss: I filed bug 1237465 about it
[15:20] <rsalveti> thanks
[15:22] <olli_> 105412
[15:22] <olli_> 453699
[15:23] <olli_> my daughter says hi, ignore
[15:23] <dholbach> :-)
[15:25] <dholbach> popey, does /usr/bin/brcm_patchram_plus use lots of CPU on your N7 too?
[15:26] <popey> dholbach:   702 1002      20   0  1192  256  176 R  98.9  0.0 124:18.24 brcm_patchram_p
[15:26] <popey> yes
[15:27] <dholbach> ah yes, ogra_ mentioned it above
[15:27] <dholbach> hum, you can't turn it off in the indicator
[15:28] <dholbach> and can't kill or stop it
[15:29] <lool> mir building in ubuntu-unity/daily-build PPA
[15:29] <kdub_> tvoss, re-pong (standup is over)
[15:35] <dholbach> popey, mhall119: maybe you can confirm bug https://bugs.launchpad.net/mir/+bug/1237465?
[15:41] <dholbach> ogra_, do we have a bug about BT using all CPU?
[15:41] <mhall119> dholbach: confirmed
[15:45] <dholbach> ah yes, bug 1217865
[15:47] <alf_> Saviq: Should I just merge the approved MPs myself into platform-api and qtubuntu, or do we need extra permission?
[15:49] <mhall119> tvoss: kgunn: what's going on with Mir and Unity 8?
[15:49] <tvoss> mhall119, not sure what you mean?
[15:54] <mhall119> tvoss: there seem to be a lot of problems for this late in the cycle
[15:54] <tvoss> mhall119, well, maguro and mako are our target devices, grouper only recently started to work
[15:54] <mhall119> is it still just integration issues, or something more fundamental
[15:55] <tvoss> mhall119, integration issues, and grouper is not a targeted device right now
[15:55] <mhall119> is it significantly better on mako?  Because I couldn't use it if it's anything like grouper
[15:55] <tvoss> mhall119, we pass a large chunk of autopilot tests and yes, it is significantly better on mako
[15:56] <mhall119> how about launching apps?  Right now a lot of them seem to crash on launch on grouper, is that device-specific too?.
[15:56] <Saviq> alf_, merge
[15:56] <alf_> Saviq: ok
[15:56] <tvoss> mhall119, sure
[15:57] <tvoss> unfortunately, but we need to workaround certain limitations of libhybris together with the nvidia driver and disable the hardware compositor there
[15:57] <mhall119> "there" meaning on grouper or on mako?
[15:57] <tvoss> on grouper
[15:58] <mhall119> ok
[15:58] <tvoss> mhall119, anything else I can help with?
[16:00] <mhall119> tvoss: is the latest mako build stable enough to be my daily-driver?
[16:00] <mhall119> assuming I'm okay with some amount of bugs which I will report
[16:02] <tvoss> mhall119, best to wait for an officially promoted image
[16:02] <mhall119> tvoss: are there people using the -proposed images to find and report bugs on them?
[16:02] <mhall119> using them on actual devices that is
[16:03] <tvoss> mhall119, for sure, the unity team and the phonedation team for sure
[16:04] <mhall119> ok
[16:04] <kgunn> alf_: since you were wondering what you might work on...
[16:04] <kgunn> alf_: curious...so, we have this stale socket issue with AP tests...sometimes unity8 will crash, but then orphan the mir_socket...then the whole stack fails to start
[16:05] <kgunn> alan_g: ^ is that actually corrected by the "delete endpoint" code change ?
[16:06] <alan_g> kgunn: Most cases, yes
[16:06] <tvoss> kgunn, we just need a post-stop script for the upstart job
[16:06] <kgunn> Saviq: ^
[16:06] <alan_g> tvoss: I'd recommend pre-start too
[16:06] <kgunn> alan_g: ; ) prestart way more effective
[16:06] <tvoss> alan_g, perfectly fine :)
[16:07] <Saviq> tvoss, we're not starting unity8 with upstart for ap tests
[16:08] <Saviq> tvoss, but yeah, that would fix the actual *run unity8* issue - assuming this will happen on restart too?
[16:08] <tvoss> Saviq, yup, you can fine-tune upstart in that respect quite heavily
[16:08] <Saviq> tvoss, *I* can't ;P
[16:08] <Saviq> tvoss, MIR_SOCKET, btw?
[16:09] <tvoss> Saviq, ENOCONTEXT
[16:09] <tvoss> Saviq, neither can I :) I'm just citing the manual here
[16:11] <Saviq> tvoss, the env var for the mir socket
[16:11] <Saviq> alan_g, MIR_SOCKET, right? ↑
[16:12] <alan_g> Saviq: If it's there, yes
[16:12] <Saviq> alan_g, yeah, and /tmp/mir_socket by default
[16:13] <alan_g> Saviq: until the next build lands.
[16:14] <Saviq> alan_g, will there be a default then?
[16:14] <alan_g> Saviq: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1236912
[16:14] <Saviq> alan_g, right, thanks
[16:18] <kgunn> Saviq:  and that is in the process of landing (like lool is literally trying to get it in archive now i believe)
[16:33] <alan_g> "Please import music and restart the app" - now how do I do that?
[16:45] <tvoss> alan_g, usually by attaching your phone via usb and just copying a song over
[16:45] <alan_g> tvoss: I managed it - just didn't feel it was a good user experience
[16:45] <tvoss> alan_g, true
[16:46] <tvoss> alan_g, let's tackle that after v1
[16:46] <alan_g> tvoss: what does "switch back to the music scope" mean?
[16:49] <alan_g> I can get a screen titled "Music" - but that doesn't show anything I dumped in "Music"
[17:04] <dandrader> kdub_, ping
[17:05] <kdub_> pong.
[17:05] <dandrader> kdub_, I get this regularly when I try to restart unity8 http://paste.ubuntu.com/6208867/
[17:06] <dandrader> kdub_, any ideas?
[17:06] <kdub_> which device?
[17:06] <dandrader> kdub_,  maguro (galaxy nexus)
[17:07] <kdub_> does it happen during a crash? iirc, that device has problems letting go of the framebuffer
[17:07] <kdub_> rather, does it happen on the restart right after a crash
[17:07] <dandrader> it always work when started durring boot up. but if I "stop unity8" and then try to start it from console later on there's a good change it will fail with that message
[17:09] <kdub_> dandrader, i'll see if i can repro, it seems like something that might happen, given the maguro hal
[17:09] <dandrader> kdub_, this time for instance. I did "stop unity8". and some 10 minutes later lanched my own "./unity8" from console. it worked. after some testing I killed it with ctrl+C
[17:09] <dandrader> kdub_, when I tried "./unity8" again I got the error
[17:09] <dandrader> and consistenly after that
[17:09] <kdub_> yeah, i think it just ignores my 'free the fb' request
[17:09] <kdub_> and something later on frees it
[17:10] <dandrader> kdub_, can I force it to be freed from command line?
[17:10] <kdub_> not any way i know of... i'll poke around
[17:10] <dandrader> :(
[17:10]  * dandrader reboots his device
[17:11] <dandrader> kdub_, is it worth filing a bug?
[17:11] <kdub_> dandrader, sure, we can file a bug
[17:11] <dandrader> kdub_, ok, will do so
[17:11]  * kdub_ flashes maguro
[17:28] <tvoss> kdub_, ping
[17:28] <kdub_> pong
[17:30] <kdub_> tvoss,
[17:30] <tvoss> kdub_, are you looking into https://launchpad.net/bugs/1235190
[17:30] <tvoss> ?
[17:30] <kdub_> there's quite a few issues today :) that's on the plate
[17:31] <kdub_> i'm not quite synced up to the latest on that one though, just trying to understand more about what's going on
[17:32] <tvoss> kdub_, ack, we bisected it to changes introduced on the 25th or 26th, which includes the mega revision 1083
[17:41] <kdub_> tvoss, reviewing
[17:41] <kdub_> i think that included turning default ipc thread pool count down
[17:42] <kgunn> racarr: ping
[17:42] <kdub_> tvoss, nevermind, made a bad diff
[17:42] <kdub_> one minute
[17:42] <kdub_> one day i'll learn how to use bzr
[17:44] <kgunn> racarr: so...what happens if this "hold surface alive" isn't landed for mir yet...but this has already landed https://code.launchpad.net/~afrantzis/unity-mir/fix-1236898/+merge/189894
[17:49] <kgunn> alf_: in case you're still on...do you  know the answer to my query ^
[18:01] <tvoss> kdub_, ?
[18:05] <kdub_> tvoss, i'm a bit confused which slowness this bug is about really
[18:06] <tvoss> kdub_, hmmm, can you reproduce the issue with image 89?
[18:08] <kdub_> i'll give it a try... i'm on 89
[18:08] <kdub_> but i've installed the latest unity/mir stuff by building it
[18:10] <tvoss> please reflash a clean 89 then
[18:10] <tvoss> kdub_, ^
[18:13] <kdub_> tvoss, i can do that, but i feel like there's some fundamental sync i missed out on with this bug
[18:14] <kdub_> the cpu performance stuff i mentioned in that bug, was that transferred to: https://bugs.launchpad.net/powerd/+bug/1233257
[18:14] <Saviq> tvoss, progress (?): only one unity8 test passes in each run, 'cause the next one loses input
[18:15] <Saviq> lool, ↑ but that means with the "remove socket" branch unity8's dashboard should look much better
[18:18] <Saviq> ricmm_, ↑
[18:18] <Saviq> ricmm_, remember those? ;)
[18:18] <Saviq> kgunn, ↑↑
[18:19] <ricmm_> next one loses input?
[18:25] <kgunn> Saviq: is that with image 89 + packages from ubuntu-unity/daily-build ?
[18:26] <Saviq> kgunn, no, think anything related got fixed?
[18:26] <kgunn> Saviq: well, at least, loic said the latest mir is in the dialy-build ppa
[18:26] <kgunn> so it would have alan_g's remove socket
[18:27] <kgunn> you'd have to pull....libmir*'s and unity-mir and platform-api
[18:28] <Saviq> kgunn, I'm building that stuff locally to have other fixes, so will know in a few
[18:34] <tvoss> Saviq, ack
[18:34] <tvoss> Saviq, could you check the webbrowser tests?
[18:34] <Saviq> tvoss, am building
[18:34] <Saviq> tvoss, it *really* takes some time
[18:34] <Saviq> tvoss, especially since unity-mir trunk requires mir > 0.14 now
[18:35] <Saviq> or something
[18:35] <tvoss> Saviq, ack
[18:35] <Saviq> so I need to build mir (I needed to anyway, to verify another fix)
[18:35] <Saviq> 80% there
[18:35]  * Saviq wants proper cross-build
[18:36] <racarr> kgunn: Probably alfs branch landing alone
[18:36] <racarr> improves things
[18:36] <racarr> but its hard to be sure
[18:36] <kgunn> racarr: so i guess...only thing
[18:36] <kgunn> racarr: only thing keeping yours from landing is
[18:36] <kgunn> racarr: a satisfactory answer to alan
[18:36] <kgunn> ?
[18:38] <racarr> maybe yeah
[18:38] <racarr> hmmm
[18:49] <racarr> kgunn: Tried to prod the conversation along
[18:52] <racarr> oh hey there is going to be
[18:52] <racarr> a qt developer days in San Francisco
[18:53] <kgunn> racarr: sure...qt dev days (as long as its after oct :)
[18:54] <kgunn> racarr: and you can get that mp landed (at least i am assuming it still fixes one of the crashes)
[18:54] <racarr> Yeah in november XD, its only two days
[18:55] <racarr> ill roll over and loudly make calls on my ubuntu phone
[18:55] <racarr> "HEY! YEAH. IM CALLING YOU FROM MY UBUNTU PHONE. IT'S A GREAT PLATFORM TO DEVELOP APPS IN QT YEAH"
[18:55] <racarr> :p um
[18:56] <kgunn> hey...so alan's comment "However, I've yet to convince myself that resources are released in a timely manner (i.e. shortly after the surface is destroyed by the client"
[18:56] <racarr> right so I am not
[18:56] <kgunn> seems crazy...surely we should "guarantee"
[18:56] <kgunn> not hope things happen timely enough ?
[18:56] <racarr> sure what exactly we mean
[18:56] <racarr> well ok, the previous model
[18:57] <racarr> is as soon as the client disconnects
[18:57] <racarr> the underlying surface resources are destroyed
[18:57] <kgunn> ok...makes sense so far
[18:57] <racarr> the wrapper object might stay around but it will throw exceptions when ever you use it
[18:58] <racarr> the new model, is
[18:58] <kgunn> who's using him in this "tranisiton state" of gone client/destroyed surfaces ?
[18:58] <kgunn> him=wrapperobj
[18:58] <racarr> Well, that's the problem, lots of people! in mir it's only the focus mechanism
[18:58] <racarr> but the shell has, std::shared_ptr<msh::Surface> in many places
[18:59] <racarr> or more correctly, std::weak_ptr<msh::Surface>
[18:59] <kgunn> ah..basically, shared buff/surf obj
[18:59] <racarr> and the problem is, it wants to promote them to shared_ptr<msh::Surface>
[18:59] <racarr> and then use it a little if the object is still around
[18:59] <racarr> the problem is, you promote it, then WHILE you are holding the shared_ptr, the underlying surface can be destroyed
[18:59] <racarr> the wrapper stays alive
[18:59] <racarr> you get exceptions
[19:00] <racarr> so the new model, is holding the shared_ptr to the shell surface actually keeps the
[19:00] <racarr> underlying surface alive
[19:00] <racarr> so, hypothetically some component grabbing on to the surface besides the client
[19:00] <racarr> could keep surfaces alive beyond hte client lifespan
[19:00] <racarr> actually I think this is behavior we need eventually, for some like shell animations, etc.
[19:00] <racarr> but mostly it's about very small races
[19:00] <racarr> I guess Alan is concerned
[19:00] <racarr> with a situation where
[19:01] <racarr> basically we just leak memory because
[19:01] <racarr> we end up holding the shared_ptrs indefinitely
[19:01] <racarr> but
[19:01] <racarr> hmm I don't think so
[19:01] <racarr> because we would have been leaking the
[19:01] <racarr> msh::Surface anyway before (just not the underlying resources)
[19:01] <racarr> so we would have gotten some valgrind
[19:01] <racarr> errors
[19:01] <racarr> alan may be conceerned about something else "released in a timely manner"
[19:01] <racarr> is a strange choice of words
[19:02] <kgunn> so what triggers the eventual release of these surfaces (if they're shared, and the traiditional owner...the client is gone...but they're alive)
[19:02] <kgunn> is there like a surface death pool
[19:02] <kgunn> like...this hasn't been used in a while...i should probably kill it?
[19:03] <kgunn> or...??
[19:03] <kgunn> i guess alan might rightly be worried this might depend on the shell behaving very hygenically
[19:04] <kgunn> racarr: ^
[19:04] <racarr> kgunn: I mean normally the release is immediate because the shell
[19:04] <racarr> shouldn't hold a shared_ptr
[19:05] <racarr> just the weak_ptr, which will allow the object to die
[19:05] <racarr> then it should promote it, and it might hold the object alive then for a little while
[19:05] <racarr> but when the last shared_ptr to it goes out of scope the surface is released
[19:06] <kgunn> racarr: ah, ok
[19:06] <racarr> unity-mir is actually doing something a little strange now...in that it IS holding a shared_ptr, but it is removing it
[19:06] <kgunn> racarr: but it does depend a litle on shell having good hygene
[19:06] <racarr> in the "surface destroyed" callback from
[19:06] <racarr> the session listener
[19:06] <racarr> yes
[19:06] <racarr> thats what alf went through and
[19:06] <racarr> found the one fix
[19:06] <kgunn> ok
[19:06] <racarr> and it seems fine now but its certainlly a concern
[19:07] <racarr> I think, I mean
[19:07] <kgunn> racarr: right concern in theory...but should be fixed
[19:07] <racarr> right and in theory
[19:07] <kgunn> racarr: and...your fixes squelches all the exception bitching it might do
[19:07] <racarr> well, the shell is always going to be
[19:07] <racarr> capable of leaking memory somehow
[19:07] <racarr> XD
[19:08] <kgunn> of course...ok.. racarr i have the feeling we should promote
[19:08] <racarr> eh, that's not really a useful thought. there is some case that we should make it really hard
[19:08] <racarr> but I think
[19:08] <racarr> weak_ptr does it
[19:08] <kgunn> or merge
[19:09] <racarr> kgunn: I think it's safe...but unless it's a race, lets wait an hour or two I started
[19:09] <kgunn> racarr: what are we waiting on  ?
[19:10] <racarr> I am thinking about
[19:10] <racarr> potential races
[19:10] <racarr> that could cause the surface to be held alive for a little while (thinking maybe thats what Alan was getting at)
[19:11] <kgunn> racarr: ok..i'll let you think...only reason i am pushing is lool is willing to pull this in (since we broke api anyway)
[19:11] <racarr> ok what is the timeline on that?
[19:11] <kgunn> altho..he will need to sleep eventually :)
[19:11] <tvoss> kgunn, 40 minutes until meeting
[19:11] <racarr> ok well I think we should just do it then
[19:11] <racarr> I mean I ran it for like
[19:11] <racarr> about 4-5 hours of actual
[19:12] <racarr> use
[19:12] <racarr> no crashes at all
[19:12] <racarr> I installed apps, and used them and everything
[19:12] <racarr> it was a whole phone experience
[19:12] <kgunn> racarr: ok, that makes me feel good
[19:12] <tvoss> racarr, go for it :) you will never find out otherwise
[19:12] <kgunn> i say let's do it and apologize to alan tomorrow :)
[19:12] <racarr> boom
[19:12] <kgunn> lool we're gonna go for it ^
[19:14] <racarr> alf_: What were the client side issues around destroying surfaces you mentioned finding
[19:14] <kgunn> racarr: can you do the manual merge on dev branch
[19:14] <racarr> alf_: I did some testing again a few days ago, and I think with hold-surface-alive, all the server side issues are fixed for mir-stress test
[19:14] <racarr> but the problem is 1 or 2 clients (out of say 10,000) dont end up seeing surface released responses
[19:14] <racarr> and hang
[19:14] <racarr> (ADD...just want to connect the dots while I remember)
[19:15] <racarr> kgunn: ...err like...
[19:15] <racarr> kgunn: What is our process there
[19:15] <racarr> merge branch, commit, push to dev branch
[19:15] <kgunn> racarr: yes...
[19:15] <kgunn> racarr: then...we mp to trunk...same thing, branch, merge, comit, push
[19:15] <racarr> oh man it's been a long time since I got to merge and push myself
[19:16] <racarr> the good old days, where if you were drunk at 2am and wanted to rewrite a compiz plugin there was no "Jenkins" to stop you.
[19:17] <lool> racarr: so this new branch, did we confirm the bug is fixed with it?
[19:17] <lool> IIRC, it was triggering rendering glitches and a crash
[19:17] <lool> could we reproduce and it's gone?
[19:17] <lool> I dont need the gory details of the bug, just confirmation it's doing what it's expected to do  :-)
[19:17] <lool> then we can land it in PPA, I can test Mir with it, and we can push to archive
[19:17] <kgunn> lool:  he ran for 5 hours, full phone experience, and didn;t get crashes
[19:18] <lool> cool, but did he get the crashes before?
[19:18] <racarr> Yes
[19:18] <racarr> but with
[19:18] <racarr> small scientific error :p
[19:18] <lool> Eh, what do you mean? :)
[19:18] <racarr> in that there is 1 day of commits, I guess everything that landed in the 24 hours prior to yesterday morning
[19:18] <racarr> which I did not reproduce the crashes on
[19:18] <racarr> so I haven't ruled out
[19:18] <racarr> that they are already all fixed
[19:18] <racarr> and the branch does nothing
[19:18] <kgunn> lool:  i thnk with all the effort to kill the crashes...its harder to repro
[19:19] <kgunn> lool: so its an "in theory" fix due to the stability that has recently gone in
[19:19] <racarr> well, no I mean
[19:20] <racarr> lol
[19:20] <racarr> science is hard. I think it fixes a few crashes :p
[19:20] <lool> so possibly the branch does nothing, but it's 100% sure it's not hurting either
[19:20] <lool> if you guys are more confortable fixing other things with ths in place, then let's go ofor it
[19:21] <kgunn> lool: yep...
[19:21] <lool> if you have merge proposals up, I can trigger ci runs or upstream merger depending on status
[19:21] <racarr> Oh right
[19:21] <racarr> *alt tabs back to terminal to push toi dev branch*
[19:21] <kgunn> lool: racarr is gonna manual merge onto dev...
[19:22] <kgunn> lool: then we can mp onto trunk...at that point, that'd be a good ci trigger
[19:22] <racarr> Ok pushed to dev branch
[19:23] <kgunn> racarr: ok...mp for trunk here... https://code.launchpad.net/~mir-team/mir/development-branch/+merge/190224
[19:24] <kgunn> can you approve
[19:24] <kgunn> then lool can you trigger a ci run on that ^
[19:25] <kgunn> lool: and note, it'll require rebuild of unity-mir, unity-system-compositor, platform-api again
[19:25] <kgunn> in your packages
[19:25] <racarr> kgunn: Approved? do I need to top approve?
[19:25] <lool> looking
[19:25] <kgunn> racarr: either...i can t.a.
[19:26] <kgunn> lool racarr ok...top approved
[19:26] <lool> running
[19:26] <lool> ci part
[19:26] <kgunn> (and no ones even drunk)
[19:26] <lool> speak for you young man!
[19:27] <kgunn> :)
[19:28] <racarr> lol
[19:28] <racarr> ok going to take a ten minute stroll to stretch my legs
[19:28] <racarr> will be back for hangout
[19:29] <kgunn> lool so as its running ci, will it autoland/jenkins merg too ? (or just spit results?..e.g. do we still have to manual merge)
[19:29] <lool> kgunn: that's another thing I need to run next
[19:29] <kgunn> ok
[19:29] <lool> kgunn: but I can also land it
[19:29] <lool> in theory
[19:31] <tvoss> Saviq, you still around?
[19:31] <Saviq> tvoss, yup
[19:32] <tvoss> Saviq, did your local build finish?
[19:32] <Saviq> tvoss, almost
[19:32] <Saviq> tvoss, building unity-mir now
[19:32] <Saviq> everything else is built, so will know soon
[19:43] <kgunn> lool its also worth pointing out...2 other trunks were updated with crash fixes...qtubuntu & unity-mir
[19:43] <tvoss> Saviq, ack
[19:43] <kgunn> lool: updating ask sheet now
[19:45] <lool> kgunn: I have one for unity-mir + hud that pete-woods prepared
[19:45] <lool> in plan
[19:46] <racarr> ...
[19:46] <racarr> for about five minutes I've been trying to figure out what is happening on my phone because it looks like the screen is kind of flickering in a weird really fast way
[19:47] <racarr> lightbulb is going out
[19:47] <racarr> lol
[19:47] <racarr> phone is fine :D
[19:47] <lool> kgunn: can we land qtubuntu standalone?
[19:47] <racarr> I think so
[19:47] <lool> kgunn: and where's the qtubuntu stuff?  I see one change in trunk
[19:48] <racarr> 186. By Alexandros Frantzis 3 hours ago
[19:48] <kgunn> lool: ^ that's the one
[19:48] <lool> Just FYI, device didn't come up after boot with the Mir packages in PPA
[19:49] <lool> or I can't unblank the screen
[19:49] <racarr> ...gulp
[19:49] <racarr> wait do you have
[19:49] <racarr> new unity-mir too?
[19:49] <lool> yes
[19:49] <lool> racarr: everything prior to your landing
[19:49] <lool> ah it fainlly turned up
[19:49] <racarr> new platform-api mirserver?
[19:49] <lool> basically I preseed power button
[19:49] <lool> screen went on but black
[19:50] <lool> remained so for ~1mn
[19:50] <lool> then unity8 came up
[19:50] <lool> I think it crashed
[19:50] <lool> now it's there
[19:50] <tvoss> lool, will be 5 minutes late to the hangout
[20:10] <robert_ancell> racarr, I remarked your surface alive branch as approved - heisen test failure
[20:27] <racarr> robert_ancell: We manually
[20:27] <racarr> merged it to dev branch
[20:27] <robert_ancell> oh, ok
[20:27] <racarr> thanks though :D
[20:33] <racarr> Lunch lunch
[20:59] <lool> kgunn, racarr: I was actually expecting a round of build-dep bumping for the second branch merge, but I guess you guys wanted me to rebuild everything against mir in PPA?
[20:59] <kgunn> lool: how do you want it done....if you rebuilt it'd be easier i would thikn....but let me know
[21:00] <kgunn> it'd take about 45 min to get the mp's all queued and mir trunk updated (at best)
[21:00] <lool> kgunn: I think it's less tracking if we dont rebump
[21:00] <lool> but I need to be careful in PPA
[21:00] <lool> I might have to force stuff in PPA, but I think I know the flag, just never used it so far
[21:00] <lool> will try that way, will see if I manage
[21:01] <kgunn> lool thanks and let me know if we need one
[21:02] <lool> ok
[21:08] <lool> racarr, kgunn: I tried qtubuntu-android from PPA with the Mir I had before the last racarr landing, but the test cases from alf crashes for me even after reboot
[21:08] <lool> Can you guys think of another change that would be needed?
[21:10] <lool> racarr: if you could confirm it also happens with your tip, that would also clarify whether we want the qtubuntu change or not
[21:10] <lool> well, I guess it's not a regression since it crashes before and after, still would like to know if it works  :-)
[21:11] <kgunn> lool: just to confirm...the only thing crashing is the standalone additino of qtubuntu ?
[21:12] <lool> kgunn: the bug has a testcase close.qml
[21:12] <lool> kgunn: this is supposed to fix a crash on the testcase
[21:12] <lool> kgunn: I get the crash with old and new qtubuntu
[21:13] <kgunn> lool: ah...so it was something already broken ?
[21:14] <kgunn> ah sorry...i'm loosing it
[21:14] <kgunn> i see...it doesn't fix what it says
[21:16] <lool> right
[21:21] <kgunn> lool: hmm, well....w/o alf_ we can't say for sure...up to you if you prefer to reject, team seemed confident it would help crashers
[21:32] <racarr> back nice and relaxed...lets see what can get me wound up again :p
[21:33] <racarr> lool: Hmm. What do you need me to test?
[21:33] <racarr> if this close.qml is crashing on the client side
[21:34] <racarr> hold-surface-alive, etc
[21:34] <racarr> wont help it
[21:34] <racarr> I think alf was speaking of both some qt ubuntu bugs and some interelated stuff perhaps in mir client
[21:34] <racarr> so this may just be a partial fix
[21:34] <lool> racarr: could you check with your latest packages, just to confirm?
[21:35] <racarr> lool: You mean trunk of everything
[21:35] <racarr> lool: XD...ok it will take a while though because I just wiped away my phone image with latest trunk of everything
[21:35] <racarr> to test the last image...
[21:36] <lool> well ok, I'll just punt it for now
[21:36] <lool> I'll see how the rest go
[21:36] <lool> it's easy to take it in
[21:36] <racarr> ok
[21:36] <racarr> I should be able to test within 1 hour
[21:37] <lool> or I can just suck it in, I mean it's not regressing more
[21:38] <lool> I'm pushing it
[21:38] <racarr> lool: I think thats what I would od, suck it in
[21:38] <racarr> the thing is it fixes some memory corruption
[21:38] <racarr> so even if that memory corruption is not the crash
[21:38] <racarr> it gives us a more stable playing field
[21:38] <racarr> to iterate on next time
[21:54] <lool> gosh, mir finally merged
[21:58] <racarr> :D
[22:02] <kgunn> bbiab
[22:20] <lool> racarr, kgunn: https://launchpadlibrarian.net/153261612/buildlog_ubuntu-saucy-amd64.mir_0.0.14%2B13.10.20131009.4-0ubuntu1_FAILEDTOBUILD.txt.gz
[22:20] <lool> FTBFS on amd64
[22:21] <lool> [  FAILED  ] 2 tests, listed below:
[22:21] <lool> [  FAILED  ] ServerShutdown/OnSignal.removes_endpoint_on_signal/0, where GetParam() = 3
[22:21] <lool> [  FAILED  ] ServerShutdown/OnSignal.removes_endpoint_on_signal/1, where GetParam() = 6
[22:23] <bschaefer> does mir handle clipboards? (cut/copy/paste?) As I don't see it mentioned in the api anywhere :)
[22:23] <kdub_> not that i know
[22:23] <bschaefer> thanks
[22:24] <RAOF> bschaefer: No; one of the things for a (hopefully upcoming?) architecture sprint :)
[22:24] <bschaefer> that would be nice :)
[22:27] <racarr> lool: Looking
[22:29] <racarr> lool: I can't derive anything useful from the log
[22:29] <racarr> its probably a test race
[22:29] <racarr> its a new test
[22:29] <racarr> so I dont know much about it
[22:29] <racarr> its probably only intermittent
[22:30] <lool> racarr: do you pass the tests on amd64?
[22:31] <racarr> lool: Let me do a clean build of tyrunk
[22:31] <racarr> almost got phoen ready to test too
[22:36] <kdub_> racarr, compile the world? :)
[22:38] <racarr> everyones FAVORITE GAME
[22:38] <racarr> ive gotten good at pipelining the network intensive cpu intensive and io intensive tasks though
[22:38] <racarr> definitely faster at it
[22:38] <racarr> lol
[22:38] <kdub_> haha
[22:45] <racarr> lool: ancdetotally startup seems faster...
[22:46] <racarr> close.qml is still segfaulting on close
[22:47] <racarr> lool: Where areall the keyboard changes...I need um
[22:47] <racarr> well I built mirserver, qtubuntu, unity-mir and platform API
[22:47] <racarr> but there is some keyboard weirdness
[22:47] <racarr> but guessing I just need dandraders patch
[22:48] <lool> racarr: ubuntu-keyboard is up in PPA
[22:51] <lool> racarr: rebuild worked for mir
[22:52] <racarr> lool: There is something wrong with this test though
[22:52] <racarr> I've been hung on it for like 1 minutes...
[22:53] <lool> racarr: could you log a bug on it?
[22:56] <racarr> lool: https://bugs.launchpad.net/mir/+bug/1237710
[22:57] <lool> thx
[23:00] <racarr> lool: I am looking at it...havent found out whats going on yet
[23:00] <racarr> but also seems pretty low risk
[23:00] <racarr> if anything real is broken, its just aboiut server shutdown (and potentially the server coming back up because the socket file might have been left creating problems)
[23:01] <racarr> but, it seems like it was already broken as well
[23:11] <lool> racarr: FIY https://launchpad.net/~lool/+archive/ppa/+build/5089424
[23:11] <lool> racarr: I'm not too worried about the test and code, it's more a pain to deal with when we're uploading stuff
[23:12] <racarr> lool: Ok just confirmed with new ubuntu-keyboard things are working better
[23:12] <racarr> also not getting an issueI was getting yesterday with
[23:13] <racarr> some keys giong through to the dash when using the search box :)
[23:13] <lool> cool
[23:13] <racarr> um ok ugh another failed build?
[23:13] <lool> racarr: it was a copy in my PPA to rebuild
[23:13] <lool> racarr: https://launchpad.net/~lool/+archive/ppa/+build/5089423 also has fails
[23:13] <lool> so very flaky tests
[23:14] <racarr> mm :/
[23:14] <racarr> the server shutdown tests are new and im not sure what's up
[23:21] <racarr> just fiddled with the build a bunch on my phone...lots of input quirks gone
[23:44] <lool> getting the dreaded   what():  Could not unblank display
[23:45] <lool> hmm I dont see the socket
[23:50] <kdub_> lool, push the power button and try again
[23:50] <lool> I did  :-/
[23:50] <lool> unity8 was restarting in a loop
[23:50] <lool> screen is on
[23:51] <lool> I pressed power, it retried but didn't come up
[23:51] <lool> I also tried powerd-cli display on
[23:51] <lool> now I've rebooted and it's the same
[23:51] <lool> ah no it's starting still
[23:53] <lool> now it's looping
[23:53] <lool> but differently
[23:53] <lool> unity8 crashes on startup now
[23:54] <lool> ok, reflashing, taking just these
[23:59] <racarr> Got to run out for an hour