[03:26] <robert_ancell> RAOF, did you look at https://code.launchpad.net/~vanvugt/mir/super-simple-connect/+merge/153307?
[03:29] <RAOF> I had not; looking.
[05:48] <RAOF> Google Mock: Fuzzing g++ since 2012
[06:24] <RAOF> Bah! The android build is broken?
[07:43] <RAOF> kdub: I'm having problems with the android build. Here?
[09:51] <alan_g> alf_: have you looked into the trunk failure to build for android?
[14:19] <mmrazik> hello
[14:19] <mmrazik> are you guys aware mir fails to build in PPA?
[14:19] <mmrazik> https://launchpadlibrarian.net/134529318/buildlog_ubuntu-quantal-amd64.mir_0.0.2bzr507quantal0_FAILEDTOBUILD.txt.gz
[14:19] <mmrazik> I don't quite see why it was ok in jenkins :-/
[14:20] <mmrazik> it looks like r505 is the first one that started to fail
[14:26] <alan_g> mmrazik: that's https://code.launchpad.net/~alan-griffiths/mir/fix-bug-1156543/+merge/153740
[14:27] <mmrazik> great
[14:27] <alan_g> mmrazik: it was OK as we build with input in CI and without for PPA
[14:28] <mmrazik> I see
[14:28] <mmrazik> should we just add a build without input as well?
[14:28] <alan_g> There are too many options that we don't test - is on my TODO list (but low down)
[14:28] <alan_g> mmrazik: Please feel free
[14:28] <mmrazik> alan_g: ok
[14:29] <alan_g> mmrazik: we break the android target even more often
[14:30] <mmrazik> alan_g: yeah... android is on my list. I can add the crosscompile easily (like in 5 minutes). I'm having some troubles with running the tests on the phone
[14:30] <mmrazik> I'll just add the compile
[14:30] <mmrazik> better than nothing
[14:30] <alan_g> mmrazik: even if it didn't run (oh you said that)
[14:49] <mmrazik> alan_g: I was overly optimistic with those 5 mins :-/ It used to work last week but there is a new dependency (glog) and jenkins is unable to find it. Need to ping kdub later where am I supposed to get it
[14:50] <alan_g> mmrazik: the glog dependency shouldn't have landed
[14:50] <mmrazik> alan_g: its in kdub's ndk script
[14:50] <mmrazik> alan_g: which is called from the cross-compile script
[14:51] <alan_g> mmrazik: I see. (I fixed glog for raring+armhf - not sure where we are on quantal)
[14:52] <mmrazik> alan_g: so maybe all we need to do is to remove the dep from lp:~kdub/mir/ndk-rewrite for now
[14:53] <alan_g> mmrazik: I'd guess so. kdub will know what the current status is
[14:53] <mmrazik> ack
[14:59] <kdub> good morning
[15:00] <racarr> Morning
[15:04] <kdub> mmrazik, the line that has glog for me in my sources is "deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports/ raring main restricted universe multiverse"
[15:04] <mmrazik> kdub: so its not supposed to build on quantal?
[15:05]  * mmrazik tries with raring
[15:05] <kdub> mmrazik, good point... i haven't sorted out where the quantal package is
[15:06] <kdub> mmrazik, we should only build for quantal because thats the only environment we have to run on
[15:06] <kdub> mmrazik, would it ease what you're doing if i roll back that change?
[15:06] <mmrazik> kdub: I'm trying to add android build (using the cross-compile script) to the ci/autolanding process
[15:07] <kdub> yay
[15:07] <mmrazik> I don't really mind if it is running on raring or quantal
[15:07] <mmrazik> kdub: if quantal makes more sense then we need to resolve the dependency somehow (possibly reverting it)
[15:08] <mmrazik> kdub: the compilation started on raring
[15:08] <mmrazik> so it seems to be fine there
[15:08] <kdub> mmrazik, it should build on both... we just don't have a raring phablet image to test the result on
[15:09] <mmrazik> kdub: I'm struggling with the phone anyway :-/ So let me add the raring build (without tests) for now
[15:09] <alan_g> racarr: kdub could someone look at  https://code.launchpad.net/~alan-griffiths/mir/fix-bug-1156543/+merge/153740 ASAP
[15:10] <kdub> mmrazik, sounds good, getting the raring build (minus tests) under ci is a good first step
[15:11] <racarr> alan_g: approved
[15:12] <alan_g> racarr: ta
[15:28] <kdub> oh, standup today: working on unblocking the glog branch, hope to mp my branch for android display construction
[15:28] <kdub> will get my nex7 working again too
[15:33] <racarr> hrm "        the_frontend_shell() override
[15:33] <racarr> " ?
[15:33] <racarr> test_focus_management_api.cpp
[15:33] <racarr> this doesn't work with my GCC
[15:34] <alan_g> racarr: are you still using 4.6?
[15:34] <racarr> 4.7.2
[15:34] <alan_g> racarr: I don't believe you
[15:35] <racarr> this is an old branch so maybe the build directory is so old its on 4.6
[15:35] <racarr> I will try that
[15:35] <racarr> I believe me though I have tried to add
[15:35] <racarr> override in the past to
[15:35] <racarr> testing server configuration overrides
[15:35] <racarr> but my GCC never supported it
[15:35] <alan_g> 4.7 does
[15:36] <racarr> ok yep it was an old build directory is all :)
[15:40] <racarr> alan_g: Fixed header installation in prepare-for-inprocess-egl (r508)
[15:41] <alan_g> racarr: ack, just finishing off some renaming changes and will look
[15:42] <racarr> alf_: ^
[15:42] <racarr> You still have a dissaprove on prepare-for-inprocess-egl
[15:42] <racarr> if you can take a look
[15:42] <racarr> needs fixing*
[15:59] <kdub> hello philipballew
[16:00] <philipballew> hey kdub
[16:01] <philipballew> be back, reboot time
[16:21] <racarr> alan_g: Updated prepare-for-inprocess-egl-clients again to fix android build
[16:21] <racarr> was just some unmerged test structure reorg
[16:21] <racarr> havent tested myself yet though chroot is still updating
[16:22] <kdub> alan_g, with the google log package, armhf/quantal seems to be broken https://launchpad.net/ubuntu/+source/google-glog
[16:22] <kdub> alan_g, would you know who to ping about that?
[16:22] <alan_g> racarr: Just offered up the refactoring we discussed Friday - https://code.launchpad.net/~alan-griffiths/mir/refactor-shell-cleaner-Surface-class/+merge/153851
[16:23] <alan_g> kdub: looking...
[16:23] <kdub> maybe seb128 ?
[16:25] <racarr> alan_g: Looking
[16:25] <alan_g> kdub: seb128
[16:25] <seb128> kdub, can't you use the raring version?
[16:25] <seb128> quantal is "stable", e.g not an active serie
[16:25] <seb128> work is not happening on it
[16:26] <seb128> we could SRU a fix if really needed though...
[16:26] <kdub> seb128, the phablet builds are still quantal
[16:27] <kdub> makes installing/compiling mir on quantal easier
[16:27] <kdub> but i don't know how much effort an sru is though
[16:28] <seb128> I don't think that deb has lot of depends, just wget and dpkg -i it on quantal if needed
[16:29] <seb128> sru ... needs the fix to be uploaded, reviewed, validated, stay a week in staging for verification and then hit -updates
[16:29] <seb128> it's not a ton of work but we try to not spent time on quantal at this point
[16:30] <kdub> seb128, yes, it looks like the download/dpkg -i is the easier route to go
[16:50] <racarr> err. looking for real now
[17:00] <dank101> Hola
[17:00] <UbuPhillup_> dank101: hallo
[17:11] <racarr> alan_g: Ok got comically distracted but just now went through refactor-shell-cleaner-surface-class
[17:11] <alan_g> racarr: amusing
[17:12] <racarr> it looks good and clears up the tests...it took me a few reads though...I think the naming SurfaceSource/SurfaceBuilder
[17:13] <racarr> is kind of unclear
[17:13] <racarr> and I wasn't sure what to expect from the types
[17:13] <alan_g> racarr: any help with the names gratefully received
[17:13] <racarr> I wonder if SurfaceBuilder is 'SurfaceOwner'
[17:13] <racarr> that is how It hink of it
[17:14] <racarr> Really its like a SurfaceOwnerController but that's unhelpfully verbose
[17:16] <racarr> it's also very much like a SurfaceManager ;)
[17:17] <kgunn> racarr: surfaceCoordinator?
[17:17] <racarr> I am not sure. Don't want to block on it I think but wanted to see if we could come up with an idea because while I think SurfaceBuilder provides a good description
[17:17] <alan_g> racarr: I'm not sure that really helps (but open to persuasion). At least part of the problem is that surfaces::Surface and shell::Surface are confusing names
[17:17] <racarr> of what the class does within shell:: it doesn't clarify the relationship between surfaces and shell and the ownership model (which is the primary purpose of this class)
[17:18] <racarr> so I think between the controller, source, and builder there is a lot of ambiguity of responsibility
[17:18] <racarr> kgunn: Maybe...that's sort of what the object is but not necessarily what it exposes to shell::
[17:18] <racarr> alan_g: shell::Window
[17:19] <alan_g> racarr: as alf keeps pointing out the design talks about surfaces
[17:19] <racarr> a window is a surface with a certain ownership model, an input channel, window management metadata (state...) etc.
[17:19] <racarr> hmm
[17:20] <alan_g> Maybe we can edit the design?
[17:20] <racarr> I think
[17:20] <alan_g> I am
[17:20] <racarr> the distinctin between surface and window is a useful one to make
[17:21] <alan_g> racarr: Sure
[17:21] <racarr> because...hmm...haven't made this concrete yet
[17:21] <racarr> but I am imagining the shell might wnat to create surfaces for certain effects or components
[17:21] <racarr> that are nothing like windows
[17:21] <racarr> and should be a surfaces::Surface and in the surface stack
[17:21] <racarr> but are not a shell::Window
[17:23] <racarr> is it
[17:23] <racarr> a SurfaceArbitrator?
[17:24] <racarr> I think that's my last idea.
[17:24] <alan_g> racarr: who do we ask why the design talks about *surfaces*? Is that just an assumption about implementation?
[17:25] <racarr> Hmm. I dunno. I will try and find out
[17:25] <racarr> katie: ^
[17:26] <racarr> alan_g: My impression, is even as an assumption about implementation, it doesn't really assume much right?
[17:26] <alan_g> racarr: Because if we can line up the terminology as "windows" it reduces the overloading.
[17:26] <racarr> what is a surface ;) how is it different from a layer? how is it different from a window?
[17:26] <katie> racarr, alan_g, i used surfaces because we wanted to move away from assuming things were windows
[17:27] <racarr> I think surface is just a word we
[17:27] <racarr> like
[17:27] <racarr> katie: We own the definition of window though
[17:27] <katie> i think that it helped us iearly on to move away from our old way of thinking
[17:27] <katie> early
[17:27] <alan_g> Hmm, so maybe surfaces::Surface is the one with a wrong name
[17:27] <katie> racarr, i don't know what you mean
[17:28] <racarr> katie: I mean, there is nothing we have to
[17:28] <racarr> assume by calling things windows
[17:28] <racarr> because we are defining that word by behavior
[17:29] <racarr> katie: the context, btw is about windows being a kind of surface.
[17:29] <racarr> alan_g: Hehe. I like
[17:29] <alan_g> katie: We'd like to get clear terminology and at the moment we've two meanings for "surface" within mir
[17:29] <racarr> layers::Layer, but I think that's
[17:29] <racarr> just because I like the word layer
[17:31] <alan_g> racarr: I don't think layer does it - too much baggage
[17:31] <racarr> mm.
[17:31] <alan_g> racarr: tile has a different sort of baggage
[17:32] <racarr> scenegraph::?
[17:32] <racarr> surfaces is like a scene graph, shell is the controller and compositor is the view
[17:33] <racarr> but
[17:33] <racarr> it's shell that cares about words like
[17:33] <katie> alan_g, racarr , from my point of view surface implies something more generic than a window
[17:33] <racarr> "Surface" or "Window" 'sufaces/scene gaph'
[17:33] <katie> but I did not assume any particular implementation :)
[17:33] <racarr> only cares about what appears on the screen
[17:34] <racarr> <not convinced....brainstorm>
[17:34] <racarr> katie: One of the thoughts is everything an application makes is a window whereas
[17:34] <racarr> the shell may want to create more general surfaces
[17:35] <alan_g> katie: agreed
[17:35] <racarr> I could be
[17:36] <racarr> I dunno
[17:37] <racarr> I tend to think of surface as a more generic window too but
[17:37] <racarr> I could be just as easily convinced that a surface was a subregion of a window or something else
[17:37] <alan_g> racarr: we rename "surfaces" to "scenegraph" and "surfaces::Surface" to "surfaces::Page"?
[17:37] <alan_g> racarr: we rename "surfaces" to "scenegraph" and "surfaces::Surface" to "scenegraph::Page"?
[17:37] <racarr> which makes me think that the words really aren't that useful
[17:38] <racarr> alan_g: Hmm...I dunno about page...why page?
[17:38] <alan_g> racarr: don't like "surface", "layer", "tile", tried something else...
[17:39] <racarr> :)
[17:39] <racarr> scenegraph::Node is a little jarring at first when you think about
[17:39] <racarr> the shell/surfaces interaction as it is written now
[17:39] <racarr> but maybe it makes sense, a
[17:40] <alan_g> I think Node is a bit too general
[17:40] <racarr> shell::Surface is a scenegraph node with certain behavior
[17:40] <racarr> mm
[17:40] <racarr> because in particular it's
[17:40] <racarr> a renderable target or something
[17:40] <racarr> to that effect.
 as now written shell::Surface has a surfaces::Surface
[17:42] <racarr> hmm
[17:43] <racarr> I liked the idea of scenegraph...but now I am looking for a word for this "renderable target" concept, i.e. with swappable color buffers, etc
[17:43] <racarr> and the only convention really (from dri, etc)
[17:43] <alan_g> "image"
[17:43] <racarr> is "Surface"
[17:43] <racarr> i.e. this is the terminology in mesa etc
[17:43] <racarr> alan_g: It seems strange for an Image to have a buffer swapper
[17:43] <alan_g> ack
[17:44] <racarr> I think I like the most shell::Window and surfaces::Surface
[17:44] <racarr> I would be almost inclined to say scenegraph::Surface
[17:44] <racarr> because the shell, can then insert in to the scene graph say
[17:44] <racarr> a scenegraph::Image
[17:44] <racarr> as an overlay or some such
[17:45] <racarr> but
[17:45] <racarr> it's kind of an imagined case for now
[17:46] <racarr> a possible concrete example of
[17:46] <alan_g> racarr: should we land the current version and continue to think about names? (Because I don't think the latter is zeroing in yet.)
[17:46] <racarr> a non window surface, is a software cursor
[17:47] <racarr> it could either just be drawn by the compositor (through ijecting PointerController)
[17:47] <racarr> or it could actually be modelled in the scene graph as an element
[17:47] <racarr> I think this simplifies the model for implementing compositor:: but
[17:48] <racarr> it really depends, do we have a SurfaceStack or a SceneGraph?
[17:48] <racarr> alan_g: Hmm I think so
[17:49] <alan_g> I think we *should* have a scenegraph
[17:49] <racarr> me too :)
[17:49] <alan_g> (Relatively simple compared to those in gaming engines)
[17:49] <alan_g> "scenegraph::Facet"?
[17:50] <racarr> alan_g: For April fools I want to implement a mir compositor on the Unity3D game engine
[17:50] <racarr> just to really mess with people...
[17:50] <alan_g> racarr: you need to b e quick
[17:50] <racarr> maybe next year
[17:51] <racarr> Facet is kind of general
[17:51] <racarr> it sounds more like something the compositor sees
[17:51] <racarr> than the shell
[17:51] <racarr> i.e. something you look at but not touch
[17:52] <alan_g> racarr: the shell is mostly working with shell::Surface (which has a scenegraph::Facet)
[17:52]  * alan_g isn't really convinced
[17:52] <racarr> hmm. it's a good thought
[17:53] <racarr> does shell::Surface modify the scenegraph::Facet or is it all through a controller?
[17:53] <racarr> I think it doesn't capture the fact that it has
[17:54] <racarr> advance_bufer and get_buffer_ipc_package though
[17:54] <racarr> or perhaps once we redo the API it just has next_buffer
[17:54] <racarr> scenegraph::Buffers
[17:54] <racarr> scenegraph::AdvanceableBuffer
[17:55] <alan_g> racarr: I'm approaching EOD - so have to leave it to you for now.
[17:55] <alan_g> I think that tries to capture too mcu
[17:55] <racarr> hehe ok
[17:55] <racarr> thanks for chatting :)
[17:55] <alan_g> *much
[17:55] <racarr> mm...
[17:55] <racarr> Hopefully it will come to me
[17:55] <alan_g> racarr: it is good to talk. Maybe you can find someone else with the right idea in a different timezone.
[17:56] <racarr> Have a good evening
[17:56] <racarr> Mm
[17:56] <alan_g> Have a good day
[18:28] <racarr> kdub: Could your android bug you just filed be about the input stuff in frontend?
[18:29] <kdub> racarr, just updated with details
[18:29] <kdub> was just going to ping you to advise :) https://bugs.launchpad.net/mir/+bug/1156749
[18:36] <racarr> kdub: The problem is DummyInputManager server/server/input returns
[18:36] <racarr> null mi::InputChannel I guess
[18:36] <racarr> but hmm that should be fine...
[18:44] <racarr> kdub: I will look at it soon
[18:44] <racarr> zoned in atm
[18:49] <racarr> kdub: Unless it is blocking you :)
[18:50] <kdub> racarr, it will start generating a lot of question marks, so its best to fix asap
[19:11] <kdub> racarr, i mp-ed up a fix
[19:17] <racarr> kdub: Ah...actually
[19:17] <racarr> the code is in error...I guess a committ was lost
[19:17] <racarr> it should be if
[19:17] <racarr> surface->supports_input()
[19:17] <racarr> response->add_fd(surface->client_input_fd())
[19:18] <racarr> sorry to not look sooner...was unwinding a big "make this test compile list"
[19:18] <racarr> also branch contains extra commented out lines
[19:19] <kdub> racarr, ah ok... could you upload over? (i pushed to a team branch)
[19:27] <racarr> kdub: https://code.launchpad.net/~mir-team/mir/fix-surface-creation-when-input-disabled/+merge/153912
[19:28] <racarr> pushed changes and approved you should approve and change to approved
[19:28] <racarr> (How many approvables could an approver prove if an approver could approv approvables?)
[19:28] <racarr> We may never know
[19:28] <kgunn> racarr: same as licks on a tootsie-pop
[19:30] <kgunn> racarr: i just realized age gap on my comment http://www.youtube.com/watch?v=0UYvsk6_foc
[19:32] <racarr> I remember these commercials :)
[19:34] <kdub> racarr, i have a half written test for this condition, i'm going to finish that up and upload at the same time
[19:35] <racarr> kdub: Great!
[19:47] <kdub> racarr, pushed, but we'll wait for jenkins and another review
[19:48] <kdub> since we both have committed to the branch
[19:48] <racarr> since my dist upgrade yesterday
[19:48] <racarr> most shared_ptr errors generated internal compiler errors
[19:48] <racarr> rather than line numbers :(
[19:49] <racarr> line numbers were a crutch anyway
[19:58] <racarr> kdub: Test looks good
[19:58] <racarr> kdub: Though the name made me expect to see a test that
[19:58] <racarr> replicated the failure scenario
[19:59] <racarr> err hmm
[19:59] <racarr> nvm I had a backwards in my head
[19:59] <robert_ancell> RAOF, "Also unlike XCB and Xlib, it's programmatically generated from the protocol definition". I guess XCB sort of solved that problem by rewriting the spec in a programatic way
[20:11] <kdub> robert_ancell, quick review? https://code.launchpad.net/~mir-team/mir/fix-surface-creation-when-input-disabled/+merge/153912
[20:11] <robert_ancell> kdub, looking
[20:11] <kdub> thanks
[20:12] <robert_ancell> kdub, yeah, looks good to me
[20:12] <robert_ancell> kdub, you want me to set the master status?
[20:13] <kdub> robert_ancell, won't hurt, should be fixed in short order though
[20:40] <robert_ancell> tvoss, Was your issue in https://code.launchpad.net/~robert-ancell/mir/server-headers/+merge/153281 resolved?
[20:41] <robert_ancell> racarr, also ^
[20:45] <racarr> I hate it when tests pass and htey arent supposed to
[20:56] <robert_ancell> racarr, do you need to review this https://code.launchpad.net/~afrantzis/mir/multi-threaded-compositor-synced-with-trunk/+merge/153661? It says your review is "pending"
[21:00] <kgunn> robert_ancell: was just noticing the same ^
[21:06] <racarr> robert_ancell: I approved the old version...am just abstaining now...trying not to get distracted :)
[21:06] <racarr> I am happy for it to land I looked over the weekend briefly but didn't approve because it was brief
[21:07]  * kdub is still reviewing multithreaded compositor branch
[21:24] <racarr> brb lunch
[21:36] <robert_ancell> kgunnAFK, can you change the drafter on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-qt-mir-backend?
[21:37] <robert_ancell> alf_, can you change the drafter on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-glmark2 to mir-team?
[21:40] <robert_ancell> kgunnAFK,  and also https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-galaxynexus
[21:58] <kdub> i ticked multithreaded compositor to 'approved to land'
[22:03] <racarr> Back
[22:03] <racarr> send-clients-input is 16/19 todos finished XD
[22:03] <racarr> maybe its done growing...
[22:05] <RAOF> robert_ancell: Right. You write a machine-parsable version of the protocol for XCB, and then codegen from that.
[22:08] <robert_ancell> kdub, nice
[22:31] <kgunn> robert_ancell: ack will do
[22:37] <kgunn> robert_ancell: hey...more clean up, can you make me (or you) the "assignee" to https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-converged
[22:37] <robert_ancell> kgunn, I set the drafter to mir-team, does that work?
[22:38] <kgunn> robert_ancell: no, bill filler wanting a name there...just put me
[22:38] <kgunn> why i have no idea
[22:38] <robert_ancell> kgunn, can you do it now I changed the drafter?
[22:39] <kgunn> robert_ancell: real time/live race condition :)
[22:39] <kgunn> had to refresh page
[22:39] <robert_ancell> heh