[11:03] <mlankhorst> hah, looks like I can use the drm EGL platform in standalone Xmir instead of the Mir EGL platform. :P
[11:05] <mlankhorst> at least that one cleans up correctly..
[11:09] <mlankhorst> RAOF: should I file a bug for eglTerminate not cleaing up correctly with Mir?
[11:18] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1414999
[14:02] <alan_g> alf_: you should mention your suspicions of cloud-worker-13 on #ubuntu-ci-eng
[14:19] <alf_> alan_g: Have we had an other strange failure? I think I want to wait for one more data point at least.
[14:20] <alan_g> alf_: Ack. (I've not been counting.)
[15:49] <mpt> I’m working on the surface management spec, and I have a question about the minimized state
[15:49] <mpt> Does/Should an app know, and be able to change, whether each of its windows is minimized?
[15:50] <mpt> If it could, it could suspend decoding/display of video, pause games, etc, saving battery
[15:51] <alan_g> the client API allows an app to query the state, get updates when the state changes and to request a state change.
[15:51] <mpt> Ok :-) thanks
[19:06] <kgunn> AlbertA: you around?
[19:07] <kgunn> AlbertA: camako: so will mir permit clients to pass in a preference of positioning ?
[19:09] <AlbertA> kgunn: we don't have that in the api yet...but there's a question for base windows on
[19:09] <AlbertA> what would the coordinate system be
[19:10] <AlbertA> but I see it as an optional field in MirSurfaceSpec
[19:11] <kgunn> AlbertA: so was just chatting with mzanetti, and he was saying this is important for the "memory" aspect
[19:11] <kgunn> that when you flip between mobile and desktop
[19:12] <kgunn> desktop just ends up with all the windows in the same spot...even if you previously spread them all out
[19:12] <kgunn> whereas, the desire would be for it to recall where they were and put them back into position
[19:12] <AlbertA> kgunn: I would have thought this would be part of the "cookie" stuff
[19:12] <AlbertA> which would be used by a shell to save/restore window information on the server side...
[19:14] <kgunn> oh look...already a bug
[19:14] <kgunn> https://bugs.launchpad.net/qtmir/+bug/1415161
[19:15] <kgunn> AlbertA: true, shell could do the tracking in the near term
[19:16] <AlbertA> kgunn: at first glance I put it in the same bucket as restoring window positions when an application starts again from scratch which is the
[19:17] <greyback> so I'm in 2 minds about Mir saving window state/position. Since we have 2 distinct view states (desktop/tablet) that would imply there's 2 separate state/position settings to track for each surface
[19:17] <greyback> -surface+window
[19:17] <greyback> should Mir have to support that?
[19:17] <AlbertA> cookie thing racarr/chris have mentioned in the past
[19:18] <AlbertA> I would imagine something like
[19:18] <AlbertA> the client requests a unique cookie from the server
[19:18] <AlbertA> and gets associated with session/surface maybe
[19:19] <AlbertA> then a server side interface just asks a helper
[19:19] <AlbertA> to store/retrieve info, given that cookie - the shell implementation would then
[19:19] <AlbertA> save whatever pertinent information it wants (like desktop/tablet mode, last known position etc...)
[19:20] <AlbertA> and likewise, mir server would ask the same helper, given that cookie to retrieve stored state...
[19:22] <AlbertA> the alternative is the client specifying initial positions....
[19:22] <AlbertA> but then we have to agree on what type of coordinate system to use...
[19:23] <AlbertA> it would probably have to be something normalized to the current view coordinate system
[19:24] <kgunn> AlbertA: right, and we want to avoid absolute positioning iirc
[19:27] <greyback> yeah that's fair, let the shell save what it needs
[19:30] <kgunn> AlbertA: client cookie only good for child surface tho right?
[19:31] <kgunn> e.g. topmost parent isn't going to know it's position right ?
[19:43] <kgunn> camako: just wondering, looks like racarr addressed alan's comment, we can ta ?
[19:43] <kgunn> https://code.launchpad.net/~mir-team/mir/add-non-input-event-ctors-and-port-event-sinks/+merge/247084
[20:01] <camako> kgunn, done
[20:01] <kgunn> camako: no prob...was just askin' really
[20:01] <camako> sure
[20:02] <kgunn> camako: i'm kinda cross referencing backlog and branches....seeing where we're really at
[20:02] <camako> kgunn, need help?
[20:02] <kgunn> camako: i might ping you as i go...and you might wanna skim it after i finish
[20:02] <camako> kgunn, sure
[20:27] <AlbertA> kgunn: cookie is more anything I think, basically to persist data and give it a unique id
[20:28] <kgunn> AlbertA: thanks...i did find it in the backlog "MirCookie/MirReference support (focus grant, cross-session/client parenting/referencing)"
[20:28] <AlbertA> kgunn: oh...yeah that maybe a bit different, that's more about cross-process ids
[20:29] <AlbertA> kgunn: but could be related...I have not given it deep thought :)
[21:23] <kgunn> camako: this feels like we should approve, fixes a bug as well...
[21:23] <kgunn> https://code.launchpad.net/~vanvugt/mir/fix-buffers_ready_for_compositor/+merge/247124
[21:24] <kgunn> altho if you want to review first, i'd understand
[21:24] <camako> kgunn, I looked at it.. yeah it looks reasonable
[21:24] <camako> was going to take a deeper look
[21:27] <kgunn> camako: and is jenkins still being a punk ?
[21:27] <kgunn> https://code.launchpad.net/~mir-team/mir/add-dispatchable-interface/+merge/246372
[21:28] <kgunn> ah...nope seems he's gotta conflict
[21:28] <camako> kgunn, alf noticed some failures but thought they were contained or due to one specific server
[21:29] <camako> kgunn, yes that particular one need TLC from RAOF
[22:12] <kgunn> RAOF: you on?
[22:12] <RAOF> kgunn: Indeed I am
[22:12] <kgunn> so i was trying to help :)
[22:13] <kgunn> RAOF: and i goofed, but already figured out how to do it right...but
[22:13] <kgunn> don't know how to undo one particular thing
[22:13] <kgunn> so i was addressign the conflict on
[22:13] <kgunn> lp:~mir-team/mir/add-dispatchable-interface
[22:14] <kgunn> and thot i addressed the right --take but i didn't
[22:14] <kgunn> shoulda done by hand
[22:14] <RAOF> Heh.
[22:14] <kgunn> ...and pushed, only to realize the goof
[22:14] <kgunn> so how does one "revert" the push
[22:15] <RAOF> Either by adding an extra commit, or by push --overwrite.
[22:15] <kgunn> cause if you uncommit/revert...then push, it says "you've diverged you fool"
[22:15] <kgunn> so opportunity to learn for me as well
[22:15] <kgunn> RAOF: what's the penalty if any of --overwrite ?
[22:15] <RAOF> Yeah, “push --overwrite” is what you want in that circumstance.
[22:16] <kgunn> or does it simply obliterate that last commit
[22:16] <RAOF> It obliterates what's currently in the branch and replaces it with what you push.
[22:16] <kgunn> (e.g. does it negate your approve votes or do some weird history loss thing)
[22:16] <kgunn> ok...will do that
[22:16] <RAOF> No, nothing like that.
[22:17] <RAOF> Some tools can get a bit confused because they expect the contents of a revision to be immutable (ie: rev 2278 has one contents now and will have a different contents after --overwrite)
[22:17] <RAOF> But it's all fairly harmless.
[22:41] <kgunn> RAOF: ok, that seemed to work...took a while to make sure i did it correct...of course, i only touch ./tests/CMakeLists.txt
[22:41] <kgunn> but after...now it's complaining about others
[22:41] <kgunn> https://code.launchpad.net/~mir-team/mir/add-dispatchable-interface/+merge/246372
[22:41] <kgunn> is that common ?
[22:43] <RAOF> No. That would suggest that there are other conflicts introduced.
[22:44] <kgunn> RAOF:  i suppose i should have done merge lp:mir ...vs lp:mir/tests/CMakeLists.txt
[22:44] <kgunn> ?
[22:44] <RAOF> I'm not sure what lp:mir/tests/CMakeLists.txt would do?
[22:44] <kgunn> it only merges that file
[22:44] <RAOF> I didn't know you could do that :)
[22:44] <kgunn> hehe
[22:45] <RAOF> I'd probably just do “bzr merge lp:mir” and check that everything's ok.
[22:45] <kgunn> ok...merging the entire tree
[22:45] <kgunn> woa... 5 conflicts encountered
[22:46] <kgunn> and lots of stuff moved about
[22:46] <RAOF> Yeah, the ABI things now conflict.
[22:46] <kgunn> yep
[22:46] <kgunn> Text conflict in common-ABI-sha1sums
[22:46] <kgunn> Text conflict in platform-ABI-sha1sums
[22:46] <kgunn> Text conflict in server-ABI-sha1sums
[22:46] <kgunn> Text conflict in src/common/symbols.map
[22:46] <kgunn> Text conflict in tests/CMakeLists.txt
[22:46] <kgunn> RAOF: i assume the map gets taken care as part of the sha1sum updates
[22:46] <kgunn> ?
[22:47] <RAOF> symbols.map? No, that needs manual merging.
[22:48] <kgunn> RAOF: how does one resolve the sha1sums ? script ?
[22:48] <RAOF> You need to manually edit it to resolve the conflict.
[22:48] <kgunn> k
[23:09] <kgunn> RAOF: ok...doing the symbols.map last, and it looks like an hour ago robert added a 3.2
[23:09] <kgunn> http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/2267
[23:09] <kgunn> does that mean
[23:10] <kgunn> i need to mannually add a 3.3 for your adds ? ...or just merge them under 3.2 since we haven't release yet ?
[23:11] <RAOF> Can probably merge them under 3.2
[23:11] <kgunn> RAOF: does order matter ?
[23:11] <RAOF> No
[23:15] <kgunn> RAOF: one last one... on your add of 3.2 your close brace has MIR_COMMON_3.1; whereas sir robert's has MIR_COMMON_3;
[23:16] <kgunn> i see 3.1 closed with MIR_COMMON_3 as well...
[23:16] <kgunn> what would be the correct convention
[23:16] <RAOF> It doesn't _really_ matter; 3.1 would be slightly more correcct.
[23:17] <RAOF> Indeed, you can leave out the base-revision entirely. It's basically just saying “These symbols comprise MIR_COMMON_3.2, and require MIR_COMMON_3.1”
[23:19] <kgunn> that was my guess
[23:20] <kgunn> RAOF: thanks for letting me do, learned a little....pushed
[23:20] <kgunn> gonna kick jenkins, if it passes we should top approve
[23:26] <RAOF> And I'll merge that through all the dependent branches. Thanks!
[23:26] <RAOF> Soooo.
[23:27] <RAOF> For those playing at home, Grim Fandango remastered is available on Linux.
[23:33] <racarr> On by default the last timeI used it
[23:33] <racarr> ...
[23:33] <racarr> lol
[23:33] <racarr> up + enter mishap
[23:36] <racarr> qtmir -> event 2.0 port finished...of coursemuch manual testing required
[23:37] <RAOF> Woot!
[23:37] <RAOF> racarr: Remember to buy Grim Fandango for the plane trip to Brussels :)
[23:38] <racarr> I've never played it actually...
[23:39] <RAOF> Yeah, that's what I though.
[23:39] <RAOF> t
[23:39] <RAOF> It might have been a bit before your time :P
[23:39] <RAOF> Which is why you should buy it, silly!
[23:41] <kgunn> who doesn't love mexican skull art really
[23:41] <kgunn> in a video game no less
[23:41] <racarr> oh that is kind of my jam
[23:41] <kgunn> never heard of this...but now i am totally intrigued
[23:41] <RAOF> OH MAN!
[23:41] <RAOF> You're a travel agent in the land of the dead!
[23:43] <RAOF> Starting on the day of the dead!
[23:44] <RAOF> Intrigue! Mystery! Skeletal pigeon eggs!
[23:44] <kgunn> hehe