[01:28] <RAOF> Note to self: don't run xorg integration tests while performing tasks you care about.
[01:40] <duflu> That's odd. My main machine can't run GL clients any more. And I upgraded _nothing_ since yesterday
[01:44] <duflu> Back in a minute
[01:44] <duflu> I hope
[01:51] <duflu> Woo, it's not PPA problems this time. We landed something in multi-monitor which makes half the example clients crash
[01:56] <duflu> ping kduv
[01:56] <duflu> ping kdub
[01:59] <RAOF> Hurray!
[02:01] <duflu> Yeah, right, hurray
[03:15]  * RAOF is off for lunch
[07:03] <duflu> alf__: out->used implies out->connected right?
[07:03] <duflu> Actually, it doesn't have to... but used is still more important I guess
[07:04] <alf__> duflu: As things are now (and I don't really expect this to change) out->used implies all of out->connected, has valid mode etc
[07:05] <duflu> alf__: What about when an output is in use, but suddenly disconnected? Does the server reconfigure or would that make used && !connected ?
[07:06] <duflu> I'm guessing an output could be "used" but possibly not "connected". That's an error to log, but theoretically possible
[07:08] <alf__> duflu: the new configuration that reaches the client should have an updated used field (i.e. not used) if an output is not connected
[07:08] <duflu> alf__: Sounds reasonable. But I will check all conditions for now...
[07:08] <alf__> duflu: but I guess it doesn't hurt to sanity check all the relevant fields
[07:08] <alf__> duflu: ok
[07:18] <dholbach> good morning
[07:37] <didrocks> RAOF: good evening!
[07:37] <RAOF> didrocks: Aloha!
[07:37] <didrocks> how's life in the winterish side of the world? :)
[07:38] <RAOF> Dark, now :)
[07:38] <didrocks> but but… you're not in the IoM!
[07:38] <didrocks> did you see my emails about xmir and so on?
[07:38] <didrocks> email*
[07:38] <didrocks> even
[07:39] <RAOF> didrocks: I did indeed. The XMir stack is preparing for an upload.
[07:40] <didrocks> excellent! so still on track for today?
[07:40] <RAOF> It might even include an autopkgtest for X, depending on how ambitious I am.
[07:40] <didrocks> \o/
[07:40] <didrocks> maybe let's try to have a first upload, and then adding it :p
[07:40] <didrocks> not adding a potential last minute "zomg"
[07:40] <RAOF> I should be able to finish it this evening.
[07:41] <didrocks> excellent, do you mind poking/sending me a quick shotout?
[07:41] <didrocks> so that I promote stuff in main in proposed
[07:42] <RAOF> didrocks: Sure.
[07:42] <duflu> Ugg. bzr tells me there's nothing to merge, but also my diff is 10kloc. It's not.
[07:43] <didrocks> RAOF: excellent! thanks a lot. Let's cross fingers
[07:43] <didrocks> nothing to merge, 10kloc? hum…
[07:43] <didrocks> are you in a case with \r\n eventually?
[07:43] <didrocks> I've already been trapped by that
[07:47] <duflu> didrocks: bzr was confused by me merging branches, reverting, and then trying to merge again. The diff remained but there was "nothing to merge"
[07:47] <duflu> Fixed now
[07:47] <didrocks> ah, but the revert was
[07:47] <didrocks> bzr merge . -r -1..-2, right?
[07:47] <didrocks> so you have a commit
[07:47] <didrocks> then, merging a revert
[07:48] <didrocks> and committing, right?
[07:48] <duflu> didrocks: Yes I think I did that. Because I'd already backed it up offsite. So didn't want to uncommit
[07:48] <didrocks> ok, so that makes sense, not bzr being confused :)
[07:48] <didrocks> basically the revert is "new code" more advanced than your merge itself
[07:49] <didrocks> (there is no marker that this commit is a revert of this one, and should be considered again then)
[07:49] <duflu> didrocks: Yes it looks like bzr is trying to mark branches as merged, even when they differ
[07:51] <didrocks> right, because the commit id is already in
[07:51] <didrocks> basically, you have to bzr branch trunk, then, creating a manual diff (from your commit change) and reapplying it :(
[07:51] <kgunn> duflu: hey...tvoss keen to push for your switch branch because it fixes some issues....but
[07:51] <kgunn> i remembered kdub had found a perf hit on android
[07:51] <duflu> kgunn: Fixed AFAIK
[07:52] <kgunn> just curious if you had a chance to investigate
[07:52] <kgunn> oh swet
[07:52] <duflu> He was testing it too early
[07:52] <kgunn> ...or sweet even
[07:52] <duflu> kgunn: Nexus4 gives 60FPS on everything
[07:52] <kgunn> kdub: ^ wanna give another go ?
[07:52] <kgunn> duflu: is it switching or bypass branch ?
[07:52] <duflu> kgunn: switch
[07:53] <kgunn> duflu: awesome
[07:53] <duflu> kgunn: I will still ask kdub to re-test though
[07:55] <kgunn> duflu: think you'll be able to mp next week ?
[07:55] <duflu> kgunn: I was aiming for today. Fingers crossed
[07:55] <duflu> kgunn: That's "switch", not "bypass"
[07:56] <kgunn> duflu: right...still lot's of effort...great
[08:02] <duflu> kgunn: Incidentally, I suspect the fix I did for the Android frame rate might resolve some of greyback's concerns about Mir's swapbuffers being slow for Qt
[08:02] <duflu> Maybe
[08:16] <duflu> Does anyone have operator permission to ban morphis?
[08:17] <seb128> !ops
[08:17] <ubot5> Help! Channel emergency! (ONLY use this trigger in emergencies) - elky, Madpilot, tritium, Nalioth, tonyyarusso, PriceChild, Amaranth, jrib, Myrtti, mneptok, Pici,  jpds,  gnomefreak, bazhang,  Flannel, ikonia, maco, h00k, IdleOne, bkerensa, nhandler, Jordan_U, DJones or k1l!
[08:18] <duflu> Not big deal. Wait and see if the noise stops I guess
[08:20] <seb128> duflu, I'm asking on #ubuntu-devel, that's actually happening on -devel and -touch as well and is quite annoying
[08:29] <duflu> kgunn: Regarding 30FPS on Android... I just discovered that can happen if you accidentally have multiple Mir servers running. It actually works, at half framerate
[08:29] <kgunn> :)
[08:29] <kgunn> makes sense
[08:29] <kgunn> duflu:
[08:39] <duflu> alf__: Would this be multimonitor? https://bugs.launchpad.net/mir/+bug/1207226
[08:39] <ubot5> Launchpad bug 1207226 in Mir "[regression] Synchronous clients become asynchronous framedropping clients after a VT switch" [Undecided,New]
[09:01] <alf__> duflu: I can't reproduce this. Is this with lp:mir? What's your monitor setup exactly, and what commands are you running running?
[09:02] <duflu> alf__: Yes plain old lp:mir. One monitor connected (but three supported). Just run any client and it happens
[09:02] <alf__> duflu: which server?
[09:02] <duflu> alf__: demo_server_shell at least. Let me test demo_server
[09:03] <duflu> alf__: If you can't reproduce it, I will debug tomorrow
[09:03] <alf__> duflu: could it be that you have left-over processes?
[09:03] <duflu> alf__: No, I've rebuilt and retested several times
[09:04] <duflu> Actually it's probably just the compositor losing vsync on VT switch
[09:15] <alan_g> duflu: alf__ - anyone need to review https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/166440 again - or shall I top-approve to get it off the review queue?
[09:16] <duflu> alan_g: Yes I need to
[09:16] <duflu> Or at least verify my previous concerns were addressed
[09:19] <alan_g> np
[09:21] <duflu> alf__: Apologies. I thought I had tested with trunk, twice. Now only happens in my own branch :)
[09:24] <alf__> duflu: no worries
[09:24] <duflu> Too many machines/branches going at once
[09:25] <duflu> I did have the forethought to test trunk. And yet I messed that up somehow
[09:25] <alan_g> duflu: time for rest
[09:26] <alan_g> RAOF: got time to fix https://code.launchpad.net/~mir-team/mir/expose-debug-buffer-id-to-client/+merge/176843 so that we can land it?
[09:44] <duflu> alan_g: I won't get to that review today. But I would like to tomorrow....
[09:45] <alan_g> duflu: that's OK, I'm just keen to reduce the review backlog (but only where possible)
[09:48] <RAOF> alan_g: Not today; barring firefighting, tomorrow.
[09:54] <alf__> RAOF: alan_g: could we change it to WIP then?
[09:55] <RAOF> alf__: Done.
[09:55] <alf__> RAOF: great thanks
[09:55] <alf__> RAOF: let's see how light we can make our MP list :)
[09:58] <didrocks> RAOF: can I help you in any way?
[09:59] <RAOF> didrocks: Not really; I'm just preparing the packages, testing them, and then I'll upload them. In a bunch.
[10:00] <duflu> It's a bad sign that I read "barring firefighting, tomorrow" as "barfighting tomorrow"
[10:00] <alf__> duflu: :D
[10:02] <didrocks> RAOF: good luck! :)
[10:37] <RAOF> didrocks: Hm. This might not all be ready and sufficiently tested for me to upload tonight. Is it urgent that I push through, or is your late today/early morning your time ok?
[10:37] <didrocks> RAOF: I prefer we push safe things, just be aware that as I have then to promote build-deps in main, it will take time
[10:38] <didrocks> RAOF: I wanted to ensure that today's Mir + u-s-c worked TBH (and be done with this)
[10:38] <didrocks> but again, better to be on the safe side of things :)
[10:39] <kgunn> robert_ancell: i was gonna test lankhorst's mp....unless, you tell me you're already doing it
[10:39] <RAOF> didrocks: I probably _could_ get it done today, but it'd be late.
[10:40] <didrocks> RAOF: that would be better, but I don't want you having to overwork for it :)
[10:40] <didrocks> RAOF: just keep me posted, we'll see
[10:46] <alan_g> hikiko: BTW your work got a mention: http://www.phoronix.com/scan.php?page=news_item&px=MTQyNTI
[10:49] <hikiko> haha :)
[10:50] <hikiko> that's only an option
[10:51] <hikiko> anyway, I wope we have the full mir on mir soon
[10:51] <hikiko> :s/wope/hope
[10:56] <robert_ancell> kgunn, testing it now
[11:09] <hikiko> alan_g, I have a question
[11:10] <hikiko> I added a check that the host socket and the socket that is used by the nested mir to accept connections is not the same
[11:10] <RAOF> Grah. Stupid alioth!
[11:10] <hikiko> and if it
[11:10] <hikiko> s the same I just throw an exception
[11:11] <hikiko> but I wonder if it's better to rename the socket myself px add a 0 at the end
[11:11] <hikiko> eg /tmp/mir_socket for host /tmp/mir_socket0 for nest
[11:11] <alan_g> hikiko: no. it is better to report the problem than hide it
[11:12] <hikiko> cool :)
[11:12] <alan_g> hikiko: Use AbnormalExit to give a nice explanation
[11:13] <hikiko> ok!
[11:19] <RAOF> didrocks: Grr. Alioth seems to be down again; I won't have the full stack ready tonight.
=== hikiko is now known as hikiko|lunch
[11:40] <didrocks> RAOF: don't worry then, thanks for trying :)
=== alan_g is now known as alan_g|lunch
[11:47] <xnox> hikiko|lunch: so can I run and test it yet? =)
[11:52] <hikiko|lunch> xnox, not yet I am afraid :) sorry eating! brb in a while
=== dholbach_ is now known as dholbach
=== hikiko|lunch is now known as hikiko
[12:31] <thomi> robert_ancell: https://bugs.launchpad.net/mir/+bug/1207312
[12:31] <ubot5> Launchpad bug 1207312 in Mir "Need the ability to record video of the screen " [Undecided,New]
=== alan_g|lunch is now known as alan_g
[13:29] <robert_ancell> alf__, regarding https://code.launchpad.net/~robert-ancell/mir/alt-ctrl-backspace/+merge/178036 - do you want to merge your common code in now and I'll rebase on it, or do the rebase yourself when merging it in?
[13:31] <alf__> robert_ancell: Let's get the common code in first, and I will give rebasing a try. I will let you know if there are any issues. BTW, we also need VT switching code.
[13:31] <alan_g> hikiko: I've made a second review comment - after more thought than the first.
[13:32] <robert_ancell> alf__, I have the VT switching code done
[13:32] <robert_ancell> in lp:~robert-ancell/mir/setsid-alt-ctrl-Fn
[13:33] <robert_ancell> tvoss_, what was the problem we had in the system compositor that we turned the input off for? We need to re-enable the input for mlankhorst patch to go through
[13:34] <alf__> robert_ancell: ok, if the common code (multimonitor-examples) lands early enough today I will take your branches, rebase them and MP them. Otherwise whoever gets to it first can do it.
[13:34] <tvoss_> robert_ancell, it makes the ati tests fail when trying to allocate a bo for the hw cursor
[13:34] <robert_ancell> tvoss_, right, so we just need to disable the cursor then
[13:34] <tvoss_> robert_ancell, right
[13:35] <hikiko> alan_g, I saw it thanks, just a question: it's not possible at all that we release the connection before deleting the platform? I mean
[13:35] <hikiko> we are sure that nested mir will never be disconnected before the exit?
[13:36] <alan_g> hikiko: we don't need it (yet)
[13:37] <alan_g> so don't make anything more complicated to allow it.
[13:37] <robert_ancell> racarr, are you awake?
[13:38] <alan_g> hikiko: http://en.wikipedia.org/wiki/You_aren't_gonna_need_it
[13:39] <hikiko> ok alan_g one more question:
[13:39] <hikiko> if I make mir connection const
[13:40] <hikiko> i wont be able to call is valid and get error and release
[13:40] <hikiko> whithout cast
[13:41] <hikiko> :s/without cast//
[13:41] <hikiko> :p
[13:41] <alan_g> hikiko: why do you think that?
[13:43] <hikiko> because they get char* not const char*
[13:43] <hikiko> eeh
[13:44] <hikiko> const MirConnection* :p
[13:44] <hikiko> and MirConnection*
[13:44] <alan_g> MirConnection* const connection;
[13:45] <alan_g> Make connection const, not what it points to
[13:46] <hikiko> this doesn't make it read-only?
[13:46] <hikiko> :s
[13:46] <hikiko> shall i make it mutable?
[13:50] <alan_g> What for?
[13:50] <hikiko>  I call mir_connect_sync in the constructor
[13:50] <hikiko> connection = mir_connect_sync
[13:51] <alan_g> But you shouldn't - call it in the initializer list
[13:51] <hikiko> then makes sense :D
[13:51] <hikiko> ok
[14:03] <robert_ancell> Can I get a second opinion on https://code.launchpad.net/~robertcarr/unity-system-compositor/disable-cursor/+merge/174006?
[14:07] <alan_g> robert_ancell: done
[14:07] <robert_ancell> alan_g, ta
[14:08] <robert_ancell> alan_g, feel like https://code.launchpad.net/~robert-ancell/unity-system-compositor/vt-switch/+merge/178072 too?
[14:09] <alan_g> what look at usc twice in one day?
[14:09] <robert_ancell> indeed
[14:09] <robert_ancell> a wild Thursday for all involved
[14:13] <alan_g> robert_ancell: is there a way to test it without forcing my system to reboot into usc world? (I never do that.)
[14:17] <robert_ancell> alan_g, not easily
[14:17] <robert_ancell> rather, no, you would have to go into u-s-c world
[14:17] <alan_g> I'll have to pass then
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
[14:52] <kgunn_> alf__ hey so that was it....
[14:52] <kgunn_> thnaks for the help
[14:53] <alf__> kgunn_: no problem, let me know how things go when you connect a second monitor
[14:53] <kgunn_> i'll probably demo tomorrow at wrap up....i still need to find an extra mon
[14:53] <kgunn_> you bet
[14:53] <kgunn_> exciting stuff
[14:54] <alf__> kgunn_: It would be great if you could find a monitor today and try it out, so we have more time in case of problems
[14:56] <kgunn_> yep...i think i may creep out of the meeting i'm in
=== sfeole` is now known as sfeole
[15:47] <robert_ancell> mlankhorst, around?
[15:52] <seb128> robert_ancell, he's off today
[15:52] <robert_ancell> seb128, ah, thanks
[15:52] <seb128> yw
[16:00] <jono> robert_ancell, would you mind responding to the post on mir-devel with the guy trying to get Mir running?
[16:00] <robert_ancell> jono, looking...
[16:01] <jono> thanks, pal
[16:10] <kgunn> racarr: ping
[16:43] <kgunn> robert_ancell: your answer on mir-devel....didn't i just prove you need the mesa bit
[16:44] <robert_ancell> kgunn, only if you're running a client right?
[16:44] <robert_ancell> which is the obvious next step
[16:44] <kgunn> yep
[16:44] <robert_ancell> I'll clarify
[16:46] <kgunn> cool...was just double checking, it sort of hit me since i just stumbled today
[16:46] <robert_ancell> kgunn, this problem will all disappear soon when the patch is in the archive
[16:47] <kgunn> ;)
[16:47] <kgunn> robert_ancell: that's what you say to all the girls
[16:48] <robert_ancell> kgunn, that's how you end up with two children
[16:48] <kgunn> :))
[16:58] <alan_g> alf__: happy with this version? https://code.launchpad.net/~alan-griffiths/mir/negate-negative-error-codes/+merge/178041
[17:05] <alf__> alan_g: yes, approved
[17:06] <alan_g> alf__: thanks
[17:06] <alan_g> Have a great evening
=== alan_g is now known as alan_g|EOD
[17:14] <robert_ancell> racarr, around?
[17:35] <om26er> how do I stop surfaceflinger ?
[17:38] <kdub_> om26er, 'stop'
[17:39] <om26er> kdub_, figured that, though I had to first 'android-chroot'
[17:39] <om26er> the doc probably needs to be updated
[17:42] <kdub_> om26er, would be an easy patch to make :) (docs are generated from mir source)
[17:42] <om26er> kdub_, sure, branching lp:mir :)
[17:47] <racarr> robotfuel: kgunn: Oi. sorry. family stuff
[17:47] <racarr> should have sent an email
[17:47] <racarr> err robotfuel sorry, tab completion error
[18:16] <racarr> https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/166440
[18:16] <racarr> can I top approve?
[18:22] <racarr> Let's land this too https://code.launchpad.net/~mterry/mir/session-for-surface/+merge/174406 as per the discussion at end?
[18:24] <kdub_> racarr, i suppose, i think we'll have to unwind it though eventually
[18:25] <racarr> kdub_: Yes definitely
[18:25] <racarr> I feel sort of like it doesn't make our unwinding much harder than it already is though
[18:25] <racarr> espescially as long as we don't use it internally and just let it be to unblock mterry
[18:26] <racarr> and I feel like we have blocked mterry for too long on something that should be trivial
[18:34] <kdub_> racarr, well, switched to abstain
[18:35] <racarr> kdub_: Ok. I think it conflicts with some stuff so I will merge it later once I have an idea of what all that is up conflicts
[18:48] <smintheu> hi all
[18:48] <smintheu> I just saw that a bunch of mir-related packages are in my dist-upgrade
[18:48] <smintheu> is there any way to check if i'm running mir now?
[18:50] <kdub_> smintheu, look for a unity-system-compositor executable with 'ps ax' is a good way
[18:50] <smintheu> from the documentation i read earlier a 'ps aux | grep unity' should show me that if unity-system-compositor is running, i'm running mir, is that right?
[18:50] <smintheu> kdub, it isn't
[18:50] <smintheu> after the update, is there anything I should do to 'activate' mir?
[20:23] <racarr> Can we try and land death-to-single-visibility today
[20:24] <racarr> would like to land that and no-input-for-hiddne-surfaces
[20:24] <racarr> so I can unjam test_client_input.cpp
[20:24] <racarr> and begin improving that
[22:53] <racarr> Taking off for a while. my entire family is in town for just the day so going to spend some time with them . I will come back for a while in the evening to iterate if anyone has time to do some reviews.