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