[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://<IP_ADDRESS>: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://<IP_ADDRESS>: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.  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


[06:46] <pitti> Good morning
[11:08] <davmor2> Morning all
[11:12] <elfy> morning davmor2
[14:16] <tom_af> hi should i report a failing package mirror for Amazon EC2 here?
[14:37] <balloons> tom_af: #ubuntu-server is also a good spot
[14:37] <balloons> err.. hmm
[14:38] <elfy> definitely probably somewhere else as well then
[14:40] <tom_af> I'm getting:
[14:40] <tom_af> Failed to fetch http://ap-southeast-1.ec2.archive.ubuntu.com/ubuntu/pool/universe/v/varnish/libvarnishapi1_3.0.4-1_amd64.deb  403  Forbidden
[14:40] <tom_af> also on varnish
[14:40] <tom_af> changing to ftp doesn't help
[14:44] <knome> tom_af, i would try http://archive...
[14:46] <tom_af> i.e. without the subdomains?
[14:48] <knome> tom_af, yep, that should try to get from the main mirror
[14:49] <knome> tom_af, if the problem persists there as well, it's not a server-related issue
[14:49] <knome> tom_af, if not, then you should be in touch with the server admins
[14:50] <tom_af> for whatever reason when I change it to a non-ec2-specific server it just can't find the package
[14:51] <tom_af> so who should i mention this to?
[14:53] <tom_af> ok. no problem. I needed to apt-get update
[14:53] <knome> yep
[14:54] <knome> was thinking that, there's a newer version in the archive
[14:54] <knome> so looks like it's specific for the ec2 server
[14:54] <tom_af> yeah
[14:54] <knome> maybe just not propagated the changes
[14:54] <knome> i'd wait some hours
[14:54] <knome> and try again
[14:54] <tom_af> ok thanks for your help
[14:54] <balloons> http://mirrors.kernel.org/ubuntu/pool/universe/v/varnish/libvarnishapi1_3.0.4-1ubuntu2_amd64.deb is current
[14:54] <balloons> https://launchpad.net/ubuntu/+archivemirrors
[15:42] <senan> Good Evening All
[15:42] <senan> DanChapman, Hello
[15:43] <alex-abreu> jibel, can you paste me just the error w/ the "requires...: false" missing
[15:44] <jibel> alex-abreu, http://paste.ubuntu.com/6885528/
[16:02] <senan> DanChapman, In path bar, the selected directory is not displayed..
[16:04] <alex-abreu> jibel, yeah the package unity-webapps-qml should be released ...
[16:05] <jibel> alex-abreu, Good, thanks!
[16:05] <jibel> alex-abreu, I'll review the autopkgtest again once the test passes then it can be released too
[16:06] <alex-abreu> jibel, ok thx
[16:07] <AlbertoSN> Hello!
[16:07] <AlbertoSN> I wanted to talk about the Ubuntu Bug Week.
[16:08] <AlbertoSN> Are you reading this?
[16:09] <elfy> who?
[16:10] <elfy> people will :)
[16:10] <balloons> AlbertoSN: allo
[16:10] <AlbertoSN> Specially Balloons, because he has been the one suggesting me to pospone the Bug Week
[16:10] <AlbertoSN> Ou
[16:10] <AlbertoSN> Hallo
[16:11] <AlbertoSN> ; )
[16:11] <AlbertoSN> Well, this is what I wanted to say:
[16:12] <AlbertoSN> Next week I'll be out on Friday afternoon and on Saturday the hole day, so if the event is postoned I wont be able to manage it half the time.
[16:13] <balloons> ahh, that's no good
[16:14] <balloons> AlbertoSN: I think it would be good to properly announce and set it up
[16:14] <balloons> we'd get much more press, etc
[16:16] <balloons> we could delay an additional week
[16:16] <balloons> it would still be before beta
[16:17] <DanChapman> senan hey if you select the pathbar then select all the labels 'home' will be at index 1, it's hidden by default but it is there :-) if you click the little arrow on the left of the pathbar it will appear.
[16:19] <senan> DanCHapman, but the label is always showing as home
[16:20] <AlbertoSN> I'm unsure. I think we can get much more press if we wait one week; on the other hand, it appears to me the further the event is from beta the best. This is because setting bug importances appears to the most important task on the week, and every bug discovered as important in this list will need extra time to be fixed.
[16:21] <senan> DanChapman,GtkLabel is showing home even if I select some othe directory
[16:23] <AlbertoSN> Balloons, what do you think it will be a proper announce?
[16:23] <balloons> AlbertoSN: no worries. how do you plan to track it?
[16:24] <balloons> AlbertoSN: I want to make sure everything is setup is all.. I'm new to the idea of a bugweek, so it might be second nature to you
[16:24] <balloons> but, others on the team are like me, and it would be good to have a good first impression
[16:27] <DanChapman> senan only if your in the home directory. So to be sure we are currently in home and not one of its sub dirs (Docs, DOwnloads etc), there should only be three labels in the path bar. The HDD stock icon at index 0, 'home' at index1 and current username at index 2, we cant use the username label as that is environment specific. So if there is more labels say at index 3/4/5 etc we are not in the root home directory but probably a sub dir
[16:27] <AlbertoSN> I have a draft in "https://wiki.ubuntu.com/Bugs/Ubuntu%20Bug%20Week". It just needs a list of participants and some graphs like these in "https://wiki.ubuntu.com/One%20Hundred%20Papercuts/".
[16:28] <AlbertoSN> Which I will do now.
[16:28] <AlbertoSN> Any other idea?
[16:29] <AlbertoSN> Ah, yes...
[16:29] <AlbertoSN> How I will track user contribution
[16:30] <AlbertoSN> Users will put in a list in which bugs they have worked on
[16:30] <AlbertoSN> And after the bug week, we will check for errors
[16:31]  * DanChapman waves to balloons
[16:31] <AlbertoSN> Any error will count, for example, as having managed -5 bugs
[16:31] <balloons> hey DanChapman :-)
[16:33] <DanChapman> balloons, how's the sprint been going?
[16:33] <balloons> AlbertoSN: i think this should be written up and communicated. I believe there are tools to check bug counts by user.. Bug hug days used to be run this way
[16:34] <balloons> DanChapman: quite well. I haven't spent time with my team in a long time, maybe a year
[16:35] <AlbertoSN> Okay: I'm writing it up for review, asking for tools, and posponing it to next week. Okay?
[16:37] <AlbertoSN> Or perhaps I can postpone it one day, and having it two days.
[16:37] <AlbertoSN> So tomorrow is for review.
[16:38] <balloons> AlbertoSN: :-) I know you really want to get this out there.
[16:39] <AlbertoSN> What I want is Ubuntu Quality  : D
[16:39] <AlbertoSN> Jajaja
[16:40] <AlbertoSN> Or Quality in Ubuntu
[16:40] <balloons> AlbertoSN: I agree. I want to make sure there is a good turnout
[16:41] <balloons> hence my feedback for you
[16:41] <jibel> roadmr, Hey, someone added a header "XS-Testsuite: autopkgtest" to checkbox in trusty-proposed but there is no dep8 test (no debian/tests at all) which means that this package will stay in -proposed forever
[16:41] <balloons> AlbertoSN: I'm sure you can run more than one over the cycle :-)
[16:41] <roadmr> jibel: yes! I saw that :( it's on my list of stuff to fix today
[16:41] <roadmr> jibel: to confirm, is it valid to just remove that if I have no valid dep8 tests?
[16:41] <balloons> jibel: roadmr, a subtle hint for someone perhaps to add it?
[16:42] <roadmr> balloons, jibel : we do have some autopkgtests but I need to ensure they're relevant to the binaries being built by that package
[16:42] <jibel> roadmr, yes, tell me or pitti once you removed the header so we'll remove the test from jenkins
[16:43] <AlbertoSN> Okay, so I'm going to work. And thank you ; )
[16:43] <roadmr> jibel: ok, I'll do that. Alternatively, if I add some dep8 tests, what would I need to do? just upload a new package (0.17.4ubuntu2) or does it need manual intervention?
[16:43] <balloons> AlbertoSN: sounds fine. Don't let me change your plans
[16:43] <jibel> roadmr, better solution :) no manual intervention, just upload a new version
[16:43] <balloons> AlbertoSN: I will add it to the calendar for you when you send the date
[16:43] <senan> DanChapman,Now I got it
[16:44] <roadmr> jibel: OK, let me try that, if I get stuck I'll send a plea for help :D
[16:44] <roadmr> jibel: thanks for letting me know, I was wondering how that had happened
[16:47] <AlbertoSN> The date: Saturday and Sunday!
[16:48] <AlbertoSN> (time zone sensitive)
[16:55] <pitti> roadmr, jibel: hm, I already removed it once, why does it keep coming back? :-)
[16:59] <roadmr> pitti, jibel : hey, I'll just upload without the autopkgtest and add that later, once I'm sure it's working. I've never used that before and I fear I'll break something else in the process :(
[16:59] <pitti> thanks
[17:03] <senan> DanChapman, How do I assert the path label ?
[17:16] <roadmr> pitti: hey, I just uploaded checkbox_0.17.4ubuntu2 fixing the autopkgtest stuff (just removed XS-Testsuite from debian/control). Do you need to change something now, or only after it builds?
[17:17] <pitti> roadmr: yes, but I can't do it right now yet, but in an hour or tomorrow morning; I'll deal with it
[17:17] <pitti> roadmr: thanks
[17:17] <roadmr> pitti: ok, I'm in no rush. Thank you and jibel, and apologies for creating extra work for you folks :(
[17:17] <pitti> no worries
[18:21]  * elopio exits. bbl.
[19:58] <balloons> om26er: do you understand cmake?
[19:59] <om26er> balloons, no, not really. unless i get myself to a situation where i can only progress by touching cmake only then i play with it
[21:12] <Letozaf_> balloons, hi
[21:17] <balloons> Letozaf_: hello
[21:18] <balloons> how's things?
[21:18] <Letozaf_> balloons, I think I have fixed bug 1272996
[21:18] <Letozaf_> balloons, I have tested several times on my device and had no failures, so I proposed a merge.
[21:18] <balloons> Letozaf_: wonderful!
[21:19] <balloons> Letozaf_: where is the latest code for reminders from you?
[21:19] <Letozaf_> balloons, https://code.launchpad.net/~carla-sella/reminders-app/new-reminders-app-tests
[21:20] <balloons> Letozaf_: elopio has added a textfield emulator to the toolkit, I think you could convert the test to using that as well if desired
[21:20] <balloons> Letozaf_: ok, so I've got the proper branch, perfect
[21:21] <Letozaf_> balloons, how does that work ? the textfield emulator..
[21:23] <elopio> balloons: Letozaf_: it's not yet released.
[21:23] <Letozaf_> elopio, oh! :D
[21:24] <balloons> elopio: I wasn't sure.. I was building from trunk :-) Regardless I didn't mean you should change your mp
[21:24] <balloons> Letozaf_: ^^
[21:24] <balloons> brb
[21:24] <elopio> Letozaf_: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/autopilot/ubuntuuitoolkit/tests/test_emulators.py#L918
[21:24] <elopio> you just call the write method, and it does all the magic.
[21:25] <Letozaf_> elopio, sound wonderful
[21:25] <Letozaf_> sounds
[21:26] <Letozaf_> elopio, can't wait to try it out


[12:07] <snap-l> Good morning
[12:08] <rick_h> morning
[12:13] <rick_h> upvote! http://www.reddit.com/r/Python/comments/1hjl1v/a_practical_guide_to_using_alembic/
[12:14] <snap-l> /url 1
[12:14] <snap-l> Yeah, i read that last night. It's like the scales fell off
[12:15] <brousch> There is only one true Python ORM, and it uses South
[12:21]  * rick_h warms up the particle cannons and gets coordinates for brousch's house...
[12:21] <brousch> Ha, I am at work!
[12:21] <rick_h> curses!
[12:41] <snap-l> brousch: I think rick_h is OK with a few extra casualties for your statement
[12:41] <snap-l> I just hope Amway is collateral damage. ;)
[12:42] <brousch> Unlikely
[12:43] <rick_h> like a cockroach
[12:43] <rick_h> I remember when my parents did amway for 2months back when I was in the single digits
[12:43] <rick_h> crazy to think that stuff is still going on
[12:45] <brousch> Huge in Asia
[12:45] <brousch> They do more in China than US now, I've heard
[13:02]  * snap-l <3 the bouncy ball chair with Kraftwerk music playing
[13:02] <snap-l> bopping
[13:02] <snap-l> Probably doing unspeakable things to my back, but I don't care.
[13:14] <rick_h> I won't be happy until I get a tron trail! http://www.monkeylectric.com/
[13:19] <snap-l> I have never ever wanted to ride a bike more in my life
[13:19] <brousch> But you can't even see it if you're the rider
[13:20] <snap-l> Wow, that's pretty steep.
[13:21] <rick_h> http://www.amazon.com/s/?_encoding=UTF8&camp=1789&creative=390957&field-brandtextbin=MonkeyLectric&linkCode=ur2&node=3375251&tag=monkey0c-20 but it's prime!!!
[13:22] <snap-l> I meant for the pro
[13:22] <rick_h> oh yea, well...
[13:23] <rick_h> http://www.kickstarter.com/projects/minimonkey/monkey-light-pro-bicycle-wheel-display-system yea those are some damn cool ideas
[13:24] <jrwren> greg-g: happy birthday.
[13:24] <jrwren> greg-g: organic beer?!?!
[13:24] <jrwren> greg-g: i can get organic malt, but I've never seen organic hops
[15:28] <greg-g> jrwren: well, I assume all ingredients were organic, or I guess >70% is what the law is, but yeah. Thirsty Bear, which is a block away from the WMF office
[15:29] <greg-g> a block-ish away from the Moscone Center if you're ever in town for a conference that is too big
[15:49] <jrwren> nice. I don't like to travel :)
[15:49] <jrwren> i suppose organic principles are another good reason to grow my own hops
[15:53] <greg-g> jrwren: def
[16:10] <_stink_> greg-g: i'll be there in mid-November
[16:10] <_stink_> at Dreamforce :/
[16:10] <_stink_> so if you haven't moved away yet, it'd be fun to catch up with you
[16:11] <greg-g> :) definitely
[16:11] <greg-g> _stink_: november is unknown territory for us. That has a non-zero chance of being after we move :)
[16:12] <_stink_> it appears that moving would serve you well, so i hope you manage it.
[16:13] <greg-g> :) yeah, moving is never fun
[16:14] <_stink_> but if away from SF...?
[16:14] <greg-g> back towards the middle of the country (not much west of us ;) )
[16:18] <snap-l> Dreamforce?
[16:18] <snap-l> Oh God, Salesforce
[16:18] <dzho> heh
[16:19]  * dzho and snap-l hit the search at about the same time
[16:19] <dzho> alternately, I think I will continue to believe that Dreamforce is like a paramilitary version of the Dream Police
[16:20] <snap-l> It's spelled "Dreamforce" but it sounds like throwing up in your mouth a bi
[16:20] <snap-l> bit
[16:20] <dzho> they get inside of your head, but more . . . vigorously
[16:22] <snap-l> greg-g: moving to Michigan? :)
[16:22] <snap-l> (one can hope, but I'm sure the answer is no)
[16:22] <jrwren> greg-g: ann arbor is calling you
[16:23] <snap-l> All the hippie, none of the douche
[16:23] <greg-g> ann arbor (well, somewhere near-ish) wouldn't be the worst idea, but maybe not the best either
[16:23] <snap-l> Royal Oak: All of the douche, some hippie required.
[16:25] <_stink_> heh, yes
[16:25] <_stink_> what was that pure michigan spoof on royal oak again?
[16:26] <snap-l> Douchebags. Pure Michigan
[16:26] <_stink_> lulz
[16:27] <_stink_> dzho: haha.  i might steal that idea.
[16:27] <snap-l> _stink_: http://www.youtube.com/watch?v=TEcjUE6XDeY
[16:28] <snap-l> http://www.youtube.com/watch?v=YPDRl1Wwl2o <- better version
[16:28] <dzho> _stink_: if it makes you feel more edgy, you can say you stole it ;-)
[16:28] <dzho> otherwise, just take it
[16:29] <_stink_> heh
[16:29] <snap-l> (Wow, that video is terrible)
[16:30] <_stink_> i love the drummer surrounded by fire
[16:30] <jrwren> its Dokken, terrible comes with it.
[16:30] <snap-l> Years from now Dokken will be a synonym for cheese
[16:31] <snap-l> Along with Winger.
[16:31] <jrwren> they aren't already?
[16:31] <snap-l> http://www.youtube.com/watch?v=GlN3oEjMpUQ
[16:32] <snap-l> (Rod Morgenstein is one of my favorite drummers, but this song is pure 80's cheese)
[16:34] <snap-l> The part around 2:30 is awesome.


[10:53] <sil2100> @pilot in
[10:53] <sil2100> o/
[11:59]  * ogra buckles up
[14:45] <tumbleweed> sil2100: https://bugs.launchpad.net/ubuntu/+source/python-acme/+bug/2018252 is still waiting to be released for focal, but SRU team unsubscribed?
[14:45] -ubottu:#ubuntu-devel- Launchpad bug 2018252 in python-acme (Ubuntu Focal) "[SRU] Fix invalid CSR version in python-acme" [Undecided, Fix Committed]
[14:45] <sil2100> humm
[14:46] <sil2100> tumbleweed: ah, I see that the .changes for focal had 2 SRU bugs and one is unverified
[14:46] <sil2100> tumbleweed: https://bugs.launchpad.net/ubuntu/+source/python-acme/+bug/1876929
[14:46] -ubottu:#ubuntu-devel- Launchpad bug 1876929 in python-acme (Ubuntu Focal) "FTBFS in focal: unsatisfiable b-d on python3-idna" [Undecided, Fix Committed]
[14:46] <tumbleweed> ah, right!
[14:47] <sil2100> So I didn't release it as I only look at those uploads that have all the bugs verified, otherwise it would take ages to go through the -proposed uploads!
[14:47] <tumbleweed> yeah, of course
[14:47] <tumbleweed> that bug was about an FTBFS due to B-Ds, so I can trivially verify it
[14:49] <sil2100> \o/
[14:52] <rbasak> tumbleweed: FWIW SRU team bug subscriptions aren't used in our process any more. We look at https://ubuntu-archive-team.ubuntu.com/pending-sru.html instead.
[14:59] <sil2100> @pilot out
[14:59] <sil2100> o/
[14:59]  * ogra buckles off
[15:02] <tumbleweed> rbasak: ack
[16:17] <enr0n> Can a core dev please trigger these baseline tests for hg-git on kinetic: retry-autopkgtest-regressions --no-proposed --blocks openssh -s kinetic | grep package=hg-git? This package is currently blocking openssh, and I did a local baseline test of hg-git and got the same failure. I also believe this failure is flaky and needs another retry: retry-autopkgtest-regressions --blocks openssh -s kinetic |
[16:17] <enr0n> grep package=gvfs
[16:21] <vorlon> enr0n: done
[16:21] <enr0n> vorlon: thanks!
[16:59] <bryceh> @pilot in
[17:54] <enr0n> I am looking for a core dev to review and sponsor a merge (bug 2023077). TIA!
[17:54] -ubottu:#ubuntu-devel- Bug 2023077 in cron (Ubuntu) "Please merge cron 3.0pl1-162 from Debian unstable" [Undecided, In Progress] https://launchpad.net/bugs/2023077
[17:55] <bryceh> @enr0n, got it
[17:55] <enr0n> bryceh: thanks!
[18:11] <bryceh> @enr0n, can you add a review slot for 'ubuntu-sponsors' to your MP?
[18:28] <enr0n> bryceh: sorry just saw this, but I see you already added it
[18:31] <bryceh> @enr0n, oh great, but it wasn't me :-)
[18:32] <enr0n> bryceh: oh, alright then :D
[19:06] <bryceh> @enr0n, reply on the mp - the autopkgtest hit an error
[19:10] <enr0n> bryceh: thanks for the review! I just pushed an update that I think will resolve the autopkgtest failure on the other arches, so I will request another round of tests once that has re-built
[19:10] <bryceh> sounds good
[20:18] <enr0n> bryceh: cron 3.0pl1-162ubuntu1~ppa3 has been published in my PPA. Can you please trigger the tests again?
[20:18] <bryceh> sure
[20:18] <bryceh> done
[20:19] <enr0n> thanks!
[20:43] <enr0n> vorlon: I see your debootstrap fix has landed in Kinetic. Can you please retry the sbuild/piuparts tests blocking openssh? retry-autopkgtest-regressions --blocks openssh -s kinetic
[20:50] <vorlon> enr0n: done
[20:50] <enr0n> vorlon: thanks!
[21:00] <bryceh> @pilot out


[01:12] <micahg> Can Ubuntu work with any cell phones yet?
[08:09] <siji> orga, u there
[16:21] <ogra> NCommander, so http://people.canonical.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu-dove/20090825/livecd-20090825-armel.out dies with "E: Couldn't find package linux-dove"
[16:46] <lool> ogra: So you merged the debian-cd changes already?
[16:47] <ogra> lool, nope
[16:47] <ogra> lool, but when i did my last liveimage build for imx51 i added dove to the arch call so we could see if a livefs comes out
[16:48] <ogra> since i do them manually anyway, helps to see issues before we have debian-cd support in
[16:48] <lool> Oh the livefs one, that's a good idea
[16:48] <lool> ogra: So we're lacking linux-dove?
[16:50] <ogra> lool, yep, looks like
[16:50] <ogra> NCommander mumbled something about promotion stuff or so ... before
[16:50] <lool> I see a linux-dove in debian/control of linux-meta-mvl-dove
[16:50] <lool> Checking archive status
[16:51] <lool> It's in NEW
[16:51] <ogra> ah
[16:51] <lool> Binaries awaiting acceptance:
[16:51] <lool> * linux-dove <IP_ADDRESS>.2 * linux-dove-z0 <IP_ADDRESS>.2 * linux-headers-dove <IP_ADDRESS>.2 * linux-headers-dove-z0 <IP_ADDRESS>.2 * linux-image-dove <IP_ADDRESS>.2 * linux-image-dove-z0 <IP_ADDRESS>.2
[16:51] <ogra> binary i guess though
[16:51] <ogra> how silly
[16:51] <lool> That all looks good
[16:51] <ogra> who did add the z0 ?
[16:51] <ogra> it just throws us back
[16:52] <lool> ogra: poked pitti
[16:52] <lool> ogra: No -z0 is fine
[16:52] <ogra> they were all approved any everything already :/
[16:52] <bjf> ogra, I added Z0, it's all I have
[16:52] <lool> was discussed on kernel-team list
[16:52] <ogra> lool, well it costs us a publisher run and the time of them sitting in NEW
[16:52] <lool> ogra: dove remains the main image we're focusing on and support Y0 and will support Y1; Z0 is just a convenience for people with the older boards
[16:52] <lool> ogra: It's unrelated; the other binaries were also in NEW
[16:52] <ogra> i'd really prefer people wouldnt play around with package changes in the kernels before A5
[16:53] <ogra> lool, right, but totally unneeded for A5
[16:53] <ogra> and costs us time
[16:53] <lool> Lets not bitch about that
[16:53] <lool> There are more critical issues  :)
[16:53] <ogra> last nights build would have produced a proper livefs and we could have moved on already
[16:53] <lool> Pinged pitti, he's having a look
[16:54] <lool> ogra: Done is done
[16:54] <lool> dove is dove
[16:54] <lool> z0 is z
[16:54] <lool> z0
[16:54] <ogra> and feature freeze is on a thursday :P
[16:55] <ogra> are you getting philosophical today ? :)
[16:56] <ogra> meh, usb-creator definately doesnt work for my .img file
[17:00]  * ogra goes back to good ol' dd
[17:01] <ogra> NCommander, we can spin a new squashfs once the meta files are in the archive, yes
[17:02] <lool> ogra: Could you poke evand on usb-creator if it's broken?
[17:02] <ogra> lool, i discussed with him the last 20min :)
[17:02] <ogra> he is in the middle of a hal->devicekit transition
[17:03] <ogra> will upload a new version tomorrow i can test
[17:03] <lool> Cool
[17:10]  * ogra sighs
[17:11] <ogra> dd to SD + my laptop = megasnail !
[17:20] <ogra> amitk, very bad news
[17:24] <ogra> lool, i guess we need to re-milestone bug 418265
[17:24] <ubot4> Launchpad bug 418265 in linux-fsl-imx51 "Warning in ehci-hcd.c:911 on kernel 2.6.31-5-imx51" [High,Confirmed] https://launchpad.net/bugs/418265
[17:24] <ogra> no input devices at all
[17:26] <ogra> lool, what doi we do with that ?
[17:26] <ogra> seems like a showstopper for A5
[17:27] <ogra> oh !
[17:28] <ogra> very intresting, if i dont have the USB NIC connected i get HID
[17:28] <ogra> GrueMaster, ^^^
[18:17] <ogra> NCommander, your kernels were totally messed up, -dove-z0 ended up in main, while the rest of -dove was in universe
[18:17]  * ogra thought jdstrand had promoted -dove already
[18:24] <lool> ogra: Is all the dove stuff in main now?
[18:24] <lool> c
[18:24] <ogra> lool, apart from -z0
[18:24] <ogra> everything wer need for images is
[18:25] <ogra> s/wer/we/
[18:26] <lool> Ok
[18:27] <lool> We dont strictly need z0 indeed
[18:27]  * ogra fires off a new livefs build, now with the *right* livecd-rootfs on clementine
[18:27] <ogra> i wonder why my world is so messed up all over all the time
[18:28] <ogra> and i usually only recognize if i have fallen in the pit already :P
[18:35] <ian_brasil> ogra, http://mtabini.blogspot.com/2009/08/importance-of-failure.html
[19:34] <rjune__> ogra: thanks for going where others fear to tread, and letting us see where you fall down so we can avoid it.
[19:35] <ogra> haha
[19:57] <NCommander> ogra, it still seems that way
[19:57] <NCommander> ogra, I'm looking at LP, the binaries are still in universe
[21:21] <ogra> NCommander, so did the publisher run and all ? can i kick off a build for you ?
[21:21]  * ogra tries tzo find out why he didnt get images, the livefs at least worked
[21:21] <NCommander> ogra, yeah, for some reason, the dove kernels didn't move into main on the second to previous run, but it should work now
[21:22] <NCommander> maybe
[21:22] <ogra> fired the build off
[21:23] <rjune__> ogra: they got you working US time?
[21:23] <ogra> no
[21:24] <ogra> pre freeze stress
[21:24] <NCommander> rjune__, more specifically, we're working off Release Standard Time
[21:24] <rjune__> which allows for approximately 1 hour sleep / day?
[21:24] <NCommander> rjune__, only once you file an open bug on it
[21:25] <rjune__> bug on sleep?
[21:25] <rjune__> anything I can help with?
[21:25] <NCommander> rjune__, not really :-/
[21:26] <rjune__> unfortunate.
[21:28] <ogra> RAAAAH !
[21:28]  * ogra freaks out
[21:28] <rjune__> ?
[21:28] <NCommander> ogra, what broke now :-/
[21:28] <ogra> its the tenth night i spend on that goddamned freaking kernelö naming shit !
[21:28] <NCommander> ogra, WTF? I thought we finally nipped that in the f***ing bud
[21:28] <ogra> NCommander, nothing abart from the fack that half ofg the files are still called -babbage
[21:29] <rjune__> ogra: calm down, you're dropping umlauts.
[21:29] <NCommander> ogra, where'd this one slip by?
[21:30] <ogra> NCommander, no idea, and i'm working since 8am (its 10:30pm now), i dont think i want to resarch it now
[21:31] <NCommander> *arghs*
[21:31] <NCommander> E: Couldn't find package linux-dove
[21:31] <NCommander> WHHHHHHHHHHHY
[21:32] <ogra> no kernel on antimony
[21:33] <NCommander> this package seems to have *#$@!ing disappeared
[21:34] <ogra> NCommander, ogra@dove:~$ apt-cache show linux-dove|grep Filename
[21:34] <ogra> Filename: pool/universe/l/linux-meta-mvl-dove/linux-dove_<IP_ADDRESS>.2_armel.deb
[21:34] <ogra> still in universe
[21:34] <NCommander> ogra, I saw that, but its been overridden to main
[21:34] <NCommander> Twice now!
[21:34] <NCommander> (LP says it should be in main and published)
[21:35] <ogra> http://clementine.buildd/~buildd/LiveCD/karmic/ubuntu-imx51/current/livecd.ubuntu-imx51.kernel-babbage:
[21:35] <ogra> 19:56:36 ERROR 404: Not Found.
[21:35] <ogra> http://clementine.buildd/~buildd/LiveCD/karmic/ubuntu-imx51/current/livecd.ubuntu-imx51.initrd-babbage:
[21:35] <ogra> 19:56:36 ERROR 404: Not Found.
[21:35]  * ogra goes mad
[21:35] <ogra> NCommander, well, your livefs build is still running, thats not a bad sign though
[21:36] <NCommander> ogra, its going to fail
[21:36] <ogra> i dont think so
[21:36] <NCommander> ogra, I rebuilt my dove a few hours ago, and been running livecd.sh every hour
[21:36] <NCommander> ogra, not unless the line to keep looking at universe is still there
[21:36] <ogra> clementine still has livecd-rootfs 0.92
[21:36] <NCommander> Oh
[21:36] <ogra> right
[21:36] <NCommander> Then it *might* work
[21:36] <ogra> so you should at least have a livefs
[21:37] <NCommander> Until the daily crontab causes a new livecd-rootfs to swoop in
[21:37] <NCommander> ogra, can you just do me a quick favor and see if mkimage is on antimony?
[21:37] <NCommander> ogra, thunderbird is lagging searching my inbox for the rt ticket to see if it got fullfilled
[21:37] <ogra> ogra@antimony:~/branches/cdimage.ubuntu.com$ grep -r babbage *
[21:37] <ogra> bin/find-live-filesystem:						FLAVOURS=babbage
[21:37]  * ogra bangs head against something very very hard
[21:37] <ogra> sigh
[21:37] <NCommander> That needs to become FLAVOURS="dove babbage"
[21:37] <ogra> no
[21:37] <NCommander> ?
[21:38]  * rjune__ gives ogra some booze.
[21:38]  * NCommander gives ogra some happy pills
[21:38] <ogra> that needs to be FLAVOURS="dove IMX51!!!!!!"
[21:38] <NCommander> oh wow
[21:38] <NCommander> shoot me
[21:38] <ogra> who ever invented the name -babbage needs to be ...
[21:38] <ogra> damned
[21:39] <ogra> ogra@antimony:~/branches/cdimage.ubuntu.com$ which mkimage
[21:39] <ogra> /usr/bin/mkimage
[21:39] <ogra> there you go
[21:39] <NCommander> ogra, thanks, that means I just need my d-cd branch to be merged, and the private branch hit hard enough
[21:41] <ogra> live build still running
[21:41] <ogra> i'm 90% sure it will finish successfully
[21:41] <ogra> if something is wrong it usually returns after 5min
[21:41] <ogra> (talking about dove here)
[22:00] <Madsy> Where is the frame pointer structure explained? I can't find it mentioned in the ARM AAPCS document.
[22:29] <NCommander> ogra, thanks


[19:30] <uleming> is it necessary to log into channel ?
[19:30] <uleming> i mean to register?
[19:47] <theneoindian> first time here , but i am late i guess ;)
[19:47] <zkriesse> theneoindian: for what?
[19:48] <theneoindian> sry , i thought training sessions are conducted here .. I'm new here , so forgive my ignorance ..
[19:57] <ddecator> theneoindian: there are sessions in here, just not all the time. we have Ubuntu User Days coming up with weekend though :)
[19:58] <pleia2> can check out the schedule here: http://people.ubuntu.com/~nhandler/classroom.html
[19:58] <pleia2> developer week is coming up too :)
[20:01] <theneoindian> thnx 4 the info ddecator n pleia2 . channel added to favourites ;)
[20:01] <ddecator> pleia2: thanks, i didn't have a chance to find the URL :p
[20:02] <pleia2> ddecator: hehe, I always just go to wiki.ubuntu.com/Classroom and follow the link
[20:04] <theneoindian> can i follow the calender ? i mean an alert on new events .. Google Calendar is the  only google pdt i've never used ;)
[20:07] <pleia2> theneoindian: if you have calendar software that can read .ics you can use<EMAIL_ADDRESS>[20:07] <pleia2> (evolution has a calendar, or you can add it to a google calendar if you have a google account)
[20:09] <pleia2> and http://ubuntuclassroom.wordpress.com/ also has posts about upcoming sessions
[20:11] <zkriesse> theneoindian: User Days will be awesome
[20:12] <theneoindian> Okey , i added it to my google calendar ..
[20:12] <theneoindian> zkriesse, when is the next User day ?
[20:13] <zkriesse> theneoindian: this Saturday July 10'th
[20:13] <zkriesse> the first session starts at 10:00 UTC
[20:14] <zkriesse> theneoindian: http://www.timeanddate.com/worldclock/fixedtime.html?month=7&day=10&year=2010&hour=10&min=0&sec=0&p1=0
[20:15] <theneoindian> k , i'll be present .. zkriesse , Google calendar converted the date for me ;)
[20:15] <zkriesse> theneoindian: Going to be able to attend the first session and all the others?!?!
[20:16] <theneoindian> What is the duration of each session ?
[20:17] <pleia2> 1 hour
[20:17] <pleia2> zkriesse: calm down :)
[20:21] <theneoindian> thank you guys for the info ... cya all on saturday .. good nite (to all under Indian ST) .. bye
[20:45] <zkriesse> pleia2: I'm calm...always calm
[20:45] <zkriesse> pleia2: unless i get a wiki project...then i get excited!
[22:37] <zkriesse> hello Navelate