[00:55] <RAOF> robert_ancell: Good morning. Or afternoon, depending.
[00:55] <robert_ancell> RAOF, hello
[00:56] <RAOF> Does lightdm have a tool to parse/modify lightdm.conf?
[00:57] <robert_ancell> RAOF, /usr/lib/lightdm/lightdm-set-defaults
[01:00] <RAOF> Sweet, thanks.
[01:01] <RAOF> Hm. Presumably that could be trivially extended to support changing the session type, right?
[01:01] <robert_ancell> RAOF, yes
[01:04] <RAOF> Excellent.
[01:05] <RAOF> Hurray for awesome upstreams.
[01:59] <thomi> RAOF: hey - it sounds like maybe no decision was reached last night regarding the client API fd issue?
[01:59] <thomi> at least, no message to the ML or merges to change anything.
[02:04] <RAOF> thomi: Oh, I'll prepare a merge nom
[02:05] <thomi> RAOF: cool - I wasn't sure what the final consensus was
[02:05] <thomi> RAOF: all I know is that IMO we're currently violating the "make it hard to use incorrectly" tenet of API design.
[02:05] <RAOF> Indeed.
[02:05]  * thomi likes being the bumbling idiot to find all the problems your *real* users will find in the future
[02:08] <thomi> robert_ancell: so, are you back at work, or just lurking?
[02:13] <thomi> just lurking I guess :)
[02:16] <thomi> RAOF: in the mean time, do you know off the top of your head what I need to do to close that FD?
[02:16] <RAOF> thomi: close(platform_package.fd[0]) should do it.
[02:18] <thomi> RAOF: I'd need to call mir_connection_get_platform(my_connection, &my_platform_package) first, to populate those FDs, right?
[02:18] <RAOF> Right
[02:18] <robert_ancell> thomi, back to work
[02:18] <robert_ancell> (I am)
[02:18] <thomi> robert_ancell: cool!
[04:20] <thomi> RAOF: what's the name members used for in MirSurfaceParameters?
[04:20] <thomi> does it have to be the same as the name passed to mir_connect?
[04:20] <RAOF> ...
[04:20] <thomi> and if so, why can't it just be copied from the connection?
[04:20] <RAOF> I was going to say the application's ID, but that's clearly not right :)
[04:21] <thomi> the examples just use the same string as the application name
[04:21] <thomi> (i.e.- __PRETTY_FUNCTION__)
[04:21] <RAOF> So, there's good reason to name surfaces; for example, the title bar.
[04:22] <RAOF> I don't know of anything that's using that information right now, though.
[04:23] <thomi> ok
[04:23] <thomi> RAOF: I think something useful I could be doing is adding to the doxygen documentation of these types, but I wonder if anyone would object?
[04:23] <RAOF> Why?
[04:24] <thomi> dunno - I assumed they were undocumented for a reason
[04:24] <RAOF> The reason is almost certainly “no one bothered documenting it”
[04:26] <thomi> ok, I might start documenting things as I go
[04:43] <thomi> hmmm, I seem to have broken something, such that now mir_connect_sync hangs forever
[04:43] <thomi> even after restarting mir_demo_server O.0
[07:30] <hikiko> alf_, are you busy?
[07:31] <alf_> hikiko: hi, what's up?
[07:34] <hikiko> I can't find the EGLNativeWindowType anywhere and I wonder what is it... I guess something like the EGLNativeDisplay, but I wonder why we use it
[07:35] <hikiko> (client/gbm/gbm_platform.h/cpp)
[07:37] <alf_> hikiko: EGLNativeWindowType is an EGL type. It is an opaque handle for the native window type.
[07:39] <alf_> hikiko: we give it to the client so they can use EGL functions to set up the rendering context
[07:40] <hikiko> which is the context we created in the server?
[07:42] <alf_> hikiko: no, a new rendering context they can use to draw on a MirSurface
[07:43] <hikiko> so this is a context created in the client
[07:43] <hikiko> by the client*
[07:44] <hikiko> and the NativeWindow is the pc/android window that the client "sees" in his screen?
[07:44] <hikiko> or something else?
[07:46] <hikiko> I am trying to understand if I need to create another context using sdl or I can use the egl functions as they are, but I am not sure I understood 100% what's going on in the client platform :S
[07:46] <alf_> hikiko: yes, window == visible surface (whatever that may mean for each windowing system)
[07:47] <hikiko> ok, so I forget about all this and I create an sdl window again in the platform part...
[07:47] <alf_> hikiko: no, when using mirclient, the native window is a MirSurface
[07:49] <alf_> hikiko: or to be more exact some representation of MirSurfaces that the EGL system can use
[07:50] <alf_> hikiko: why can't you just compile with the gbm backend for now, until the server part is finished, and then move to the client part?
[07:50] <hikiko> because
[07:50] <hikiko> you can't use the gbm as it is
[07:51] <hikiko> one sec I ll show you
[07:51] <hikiko> irPlatformType mclg::GBMClientPlatform::platform_type() const
[07:51] <hikiko> {
[07:51] <hikiko>     return mir_platform_type_gbm;
[07:51] <hikiko> }
[07:51] <hikiko> each client platform
[07:51] <hikiko> has this function
[07:51] <hikiko> android returns android, gbm returns gbm, I have to return sdl
[07:52] <hikiko> mmm
[07:52] <hikiko> if i use gbm as it is
[07:52] <alf_> hikiko: It doesn't matter for now, the first step is to get the server-side examples working. Sure, the client side won't work, but we can fix this later.
[07:53] <hikiko> yes that's what I am trying to do :s ok let me try something.. bbl (+thanks!)
[07:59] <hikiko> btw alf_ is there any way to exclude gmock... of the build?
[07:59] <hikiko> I get tones of errors there
[08:01] <tvoss> hikiko, what kinds of erros?
[08:02] <hikiko> tvoss, about wrong declarations, syntax errors in templates and I end up with:
[08:02] <hikiko> fatal error: too many errors emitted, stopping now [-ferror-limit=]
[08:02] <tvoss> hikiko, then it's highly likely that you have an error somewhere in your header files. GMock compiles just fine in general
[08:03]  * tvoss notes that almost always one's own code is wrong :)
[08:03] <hikiko> tvoss, I was getting errors even when I was compiling the trunk
[08:03] <hikiko> just now they become fatal
[08:03] <hikiko> so, it's not only my header files
[08:03] <tvoss> hikiko, compilation works fine in CI and autolanding
[08:03] <hikiko> ok, then I ll change my compile params...
[08:04] <hikiko> :D
[08:04] <tvoss> hikiko, why do you have custom compile params?
[08:05] <hikiko> well, I use clang because each time I have an error like: forgot to include a header file, I trigger a gcc internal compiler error
[08:05] <hikiko> it was faster to change the env var and use clang
[08:05] <hikiko> than compile the next gcc versions
[08:05] <tvoss> hikiko, which gcc version are you using?
[08:05] <tvoss> hikiko, saucy has gcc 4.8
[08:05] <hikiko> gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
[08:06] <hikiko> I am still using raring tvoss
[08:06] <hikiko> do you think I have to upgrade?
[08:06] <tvoss> hikiko, not sure, but gcc 4.7.3 is quite stable for me
[08:07] <hikiko> well in my case it was crashing all the time with internal compiler error and no clue about the problem it triggered it
[08:07] <hikiko> so I gave up and replaced it
[08:09] <alan_g> tvoss: ping
[08:09] <tvoss> hikiko, at any rate, you should not need to compile a toolchain on your own: see https://launchpad.net/~ubuntu-toolchain-r/+archive/test
[08:09] <tvoss> alan_g, pong
[08:10] <alan_g> tvoss:  did you see RAOF's email "Mir in Ubuntu"? IMO it raises some architectural issues...
[08:11] <tvoss> alan_g, yup, have seen it ... what are those issues?
[08:11] <alan_g> tvoss: we should have a plan for stabilizing ABI and comms protocol
[08:11] <tvoss> alan_g, yup, agreed
[08:11] <alan_g> Because it is starting to impact other components
[08:12] <alan_g> tvoss: is that something you should be driving? Or who?
[08:12] <tvoss> alan_g, I would think that the ABI stability is a requirements towards Mir and the team should just pick it up. But I'm happy to trigger the discussion
[08:14] <RAOF> I don't think comms protocol is particularly important to stabilise at this point - although backwards compatibility in comms protocol might be soon.
[08:14] <RAOF> But needing to rebuild unity-system-compositor for each Mir commit clearly won't scale to the distro.
[08:15] <tvoss> RAOF, fully agreed
[08:15] <alan_g> RAOF: ack (although I think we should prepare the way by adding version info to the protocol - even if we ignore it)
[08:16] <RAOF> alan_g: +1
[08:16] <RAOF> We should at least be able to return a sensible "whoops, this won't work" error.
[08:20] <alan_g> RAOF: We can return an error string containing "whoops, this won't work" - does that count? ;)
[08:20] <RAOF> alan_g: As long as it can be translated ☺
[09:35] <hikiko> alf_, what happened to the drm authenticator?
[09:36] <alf_> hikiko: it was removed, but it seems that we will need to reinstate it after all
[09:36] <hikiko> :S
[09:36] <hikiko> well without it my branch doesn't compile anymore
[09:37] <hikiko> I use the authenticator to register my drm device fd
[09:48] <alf_> hikiko: Why do you need to register a drm device fd?
[09:49] <hikiko> actually I have to tell the xserver
[09:49] <hikiko> which is my drm fd
[09:49] <alan_g> alf_: I'm not sure I've used it since rebuilding my system - is s-jenkins working for you?
[09:49] <tvoss> alan_g, it's down
[09:50] <alan_g> tvoss: ta
[09:51] <alf_> hikiko: Why is this needed for the SDLDisplay?
[09:51] <hikiko> if you want to create a gbm buffer
[09:51] <hikiko> you need the drm fd
[09:51] <hikiko> there's no other way
[09:52] <hikiko> but if you open a drm fd
[09:52] <hikiko> you need to authenticate
[09:52] <hikiko> tell the xserver that you will use this device
[09:52] <hikiko> otherwise you wont have permissions to do anything
[09:53] <alf_> hikiko: right, but my question still stands: why do you need to create a gbm buffer for the SDLDisplay (I mean that class in particular, not the sdl backend in general).
[09:54] <hikiko> because you use the gbm buffers in the ipc mechanism
[09:54] <hikiko> and you told me that there's no point to create my own type of buffers
[09:54] <hikiko> last month :s
[09:55] <hikiko> +the gbm buffer allocator is part of the gbm platform which is used in the display
[09:55] <hikiko> sorry
[09:55] <hikiko> you asked for the display ^^
[09:58] <alf_> hikiko: That's true, you don't need gbm buffers in the SDLDisplay class, you need them in the buffer allocator. My proposal for step 1 is to get SDLDisplay + render_to_fb to work, which doesn't involve the buffer allocator or any IPC/client code. I think that's the easiest way (step by step) to move forward, otherwise there are just too many things to take care of at once.
[09:59] <alf_> hikiko: then step 2 is getting the buffer allocator + render_surfaces to work, step 3 is IPC/client side rendering.
[10:05] <alf_> hikiko: that is, for step 1 you just need an SDLPlatform that returns a proper SDLDisplay and stub implementations for everything else
[12:55] <racarr> Good morning!
[13:26] <kgunn> racarr mornin'
[13:26] <kgunn> awfully early
[13:27] <alan_g> kgunn: racarr afternoon (not very early)
[13:27] <racarr> Morning all :)
[13:27] <kgunn> afternoon alan_g
[13:33] <racarr> alan_g: Can I explain "friend class SessionManager" from rebuild input targets
[13:33] <racarr> Am having trouble coming up with a better solution
[13:35] <alan_g> racarr: I guess you have the right. ;) (Although I've not tried for a deep understanding yet.)
[13:36] <racarr> I just meant I am asking for help :)
[13:36] <racarr> basically the problem is, now that ms::Surface is the input target
[13:36] <racarr> how can the shell with an msh::Surface give it keyboard focus (through the InputTargeter)
[13:37] <racarr> so I added msh::Surface::internal_surface, protected, and let the SessionManager use it -.-
[13:38] <racarr> it could also be InputTargeter instead of session manager.
[13:38] <racarr> or the even the InputRegistrar, could be the only one to use internal_surface, and it exposes like handle_for_surface(std::shared_ptr<msh::Surface>...) which the targeter uses
[13:38] <racarr> but I don't know. none of these (including friending the SessionManager)
[13:39] <racarr> are particularly compelling
[13:41] <alan_g> racarr: I've a feeling that the relationship between ms::Surface and msh::Surface is wrong. (And that things being modelled as attributes should be associations) Maybe this is part of the same issue.
[13:42] <racarr> alan_g: Hmm I think it is part of the same stickiness...what do you mean by attributes vs assosciations though?
[13:44] <alan_g> racarr: Let me try an example...
[13:45] <alan_g> A board game piece could have a "black" or "white" color attribute
[13:46] <alan_g> Or it could associated (e.g. in a set of) with "black pieces" or a with "white pieces"
[13:46] <racarr> vs some sort of external assosciation?
[13:46] <racarr> mm
[13:46] <racarr> I see
[13:47] <racarr> So you mean ::type/::state
[13:47] <racarr> give msh::Surface dual roles?
[13:47] <racarr> because without that it's just a resource managing class
[13:47] <racarr> (input did too, but now input is moved down)
[13:49] <alan_g> racarr: that's what I mean. Not sure my "unease" actually points to a solution.
[13:53] <racarr> alan_g: Hmm.
[13:53] <racarr> alan_g: Maybe the "solution" is to remove the friend/protected
[13:53] <racarr> resource managing classes typically expose something like that
[13:53] <racarr> and then aim at moving the state somewhere else
[13:55] <alan_g> racarr: certainly adding a friend to access a *protected* member seems odd
[13:56] <alan_g> racarr: and does internal_surface() need to be virtual?
[13:56] <racarr> No definitely not
[13:57] <racarr> it should probably return
[13:57] <racarr> weak_ptr?
[13:57] <racarr> as well
[13:58] <racarr> or throw an exception
[13:58] <alan_g> racarr: Possibly - or check the lock succeeds
[13:59] <racarr> alan_g: My current leading theory is remove the protected and friend class, remove the virtual, add an exception + tests for internal_surface
[14:01] <alan_g> racarr: actually, looking at where internal_surface() is used - could it be replaced by update_input_focus(InputTargetListener&) ?
[14:02] <racarr> It could.
[14:02] <racarr> hmm
[14:03] <racarr> well
[14:03] <racarr> except then InputTargetListener wants shared_ptr, which is maybe another bug?
[14:03] <racarr> I'm not sure that isn't more coupled though...im trying to think about how the tests would look
[14:06] <alan_g> racarr: is it more coupled? Then session manager doesn't need to know how the input target is moved (it doesn't need to get a ms::Surface from one place and pass it to another.
[14:07] <racarr> but the same way msh::Surface doesn't need to know about an InputTargetListener
[14:07] <racarr>  / how it receives focus
[14:07] <racarr> right now it doesnt even need to know if it has focus but eventually it will
[14:10] <racarr> I can see the appeal of update_input_focus
[14:11] <alan_g> "tell don't ask" ;)
[14:11] <racarr> it makes me uneasy though because I dont
[14:11] <racarr> think of focus as an attribute
[14:11] <racarr> of the surface.
[14:12] <racarr> though I guess it' clear with the InputTargetListener...
[14:12] <alan_g> "attribute" or "association"?
[14:12] <racarr> its
[14:12] <racarr> an assosciation
[14:13] <racarr> focus is assosciated with the surface (in the InputDispatcher as it stands)
[14:13] <racarr> but the surface isn't told, hey you got focus, hey you lost focus, etc.
[14:13] <alan_g> but that "surface" is the ms::Surface, not the msh::Surface
[14:14] <racarr> mm
[14:14] <racarr> Ugh
[14:14] <racarr> the reference issues
[14:14] <racarr> are difficult to solve :p
[14:14] <racarr> if you want to do it this way then InputTargetListener has to take
[14:15] <alan_g> a weak_ptr - or a proxy
[14:15] <alan_g> yep
[14:15] <racarr> ms::Surface&, so then the window handle repository has to take ms::Surface&
[14:15] <racarr> and
[14:15] <racarr> and so the surface stack :p
[14:15] <racarr> or a weak_ptr perhaps...?
[14:15] <racarr> thinkthink*
[14:16] <racarr> it's not that bad either way
[14:19] <alan_g> racarr: what isn't clear to me is what should happen to input if the focussed surface is zapped. (But I'll leave that as an exercise..."
[14:19] <alan_g> s/"/)
[14:19] <racarr> alan_g: Another possible way to solve this is with operator== overload
[14:20] <racarr> but it's kind of hairy
[14:20]  * alan_g headdesk
[14:20] <racarr> hmm, if the focused surface is zapped, then the InputDispatcher
[14:20] <racarr> will fail to promote the focused window handle
[14:20] <alan_g> http://arstechnica.com/information-technology/2013/05/why-arent-user-defined-operators-more-common/
[14:20] <racarr> and clear its focus
[14:21] <racarr> I know :p this seems like a pretty clear overload though
[14:22] <alan_g> racarr: that enough help for now?
[14:22] <racarr> Yes thanks. :)
[14:49] <racarr> coffee shop be back for meeting!
[15:01] <kdub> hello again folks, status, working on a swapping algorithm switcher
[15:10] <racarr> status: Updating rebuild-input-targeting. Then going to work on some lttng tracing for inpu
[15:10] <racarr> t
[15:15] <alan_g> racarr: you've a couple of other MPs in need of attention
[15:17] <racarr> alan_g: I will reject disable-sequences until later
[15:17] <racarr> alan_g: I can update depthify-stack but there is no point to land it without rebuild-input-targeting as input wont work in stacked scenarios
[15:18] <racarr> so have been waiting
[15:29] <alan_g> racarr: ok
[15:32] <racarr> oh wow...
[15:33] <racarr> alan_g: In that whole discusion before...I was wondering, how does msh::Surface then go on and pass itself to the InputTargeter from take_input_focus
[15:33] <racarr> now looking at the code...it needs to pass ms::Surface and it's all very obvious :p
[15:33] <racarr> I think I got crosswired because I am used to thinking that InputTarget=shell::Surface
[15:34] <alan_g> racarr: how very confusing
[15:35] <racarr> the msh::Surface/mf::Surface<->ms::Surface is so frustrating
[15:35] <racarr> maybe I will try and find a "once and for all" solution this week...I think its worth some thought
[15:38] <alan_g> racarr: good luck! (I keep being distracted by more urgent work.)
[15:38] <racarr> :)
[15:39] <alf_> status: BufferSwapperSpin and client::RpcReport MPs, with the next step being an lttng RpcReport implementation (and perhaps related client side improvements)
[15:39] <racarr> How come bypass comp?
[15:40] <alan_g> racarr: it is a maze of twisty little objects - I know what I want to happen, but untangling the bits I want to change is frustratingly slow.
[15:40] <racarr> mm :)
[15:41] <kdub> alan_g, anything I could help with?
[15:42] <alan_g> kdub: not right now, but once I get this first spike running I'll be grabbing you. (Hopefully tomorrow)
[15:46] <racarr> alan_g: Pushed updates to rebuild-input-targeting
[15:46] <racarr> let me know if I can help fit things together on review, etc...feel bad about dumping such a large branch but couldn't find any sensible way to split it up
[15:47] <alan_g> racarr: ack
[15:47] <racarr> I Guess I will write some doxygen too
[16:01] <racarr> alf_: I am looking at adding LTTNG for some interesting input statistics (just a few to start, such as received event from kernel, dispatched event, etc...)
[16:01] <racarr> alf_: Just want to make sure I have the idea right...
[16:02] <racarr> make a new report interface. Then provide lttng/logger implementations?
[16:02] <racarr> or are there other ways to use it
[16:04] <alf_> racarr: that's the recommended way, look at message_processor_report* in server/lttng/ as a template of how to do it
[16:08] <alf_> racarr: let me know if you have any questions
[16:08] <racarr> alf_: I think it makes sense. Thanks :)
[16:08] <alf_> racarr: yw
[16:08] <racarr> what I am wrestling with in my head...is...I guess I want a less explicit interface but
[16:08] <racarr> it's probably wrong?
[16:09] <racarr> the thing is. the way I imagine wanting to use tracing (espescially in parts like input) is to have...lots of trace points!
[16:09] <racarr> But if they are done through a report rather than explicitly they have a real cost
[16:10] <racarr> both runtime, and interface bloat
[16:10] <alf_> racarr: runtime=cost when using a null report?
[16:10] <alan_g> racarr: you were at the London sprint. We discussed the difference between reporting and tracing there
[16:11] <racarr> what you get through the report, is explicitness, and a contract.
[16:12] <racarr> alan_g: Mm
[16:12] <racarr> alf_: Well, it's still a virtual method invocation right. It's a hugely low cost I guess.
[16:12] <alan_g> racarr: is this the same discussion revisited?
[16:13] <racarr> mostly about interface bloat.
[16:13] <racarr> alan_g: sort of..
[16:13] <alf_> alan_g: racarr: hangout?
[16:13] <racarr> It's just there are some type of events...like say
[16:13] <racarr> "Couldn't load input device configuration file so falling back to generic"
[16:13] <racarr> that I am not sure are ever interesting as part of a report
[16:13] <racarr> and are so large
[16:14] <racarr> err, the space of possible events
[16:14] <racarr> but you would love to see them in a trace
[16:14] <racarr> *shrug*
[16:14] <racarr> alf_: We can. I don't want to distract everyone too much though
[16:14] <racarr> because I haven't spent much time thinking about this yet
[16:14] <alf_> racarr: ok
[16:15] <racarr> I think maybe I am getting ahead of myself anyway
[16:15] <racarr> as my initial goal was just to add tracing for a few interesting
[16:15] <racarr> occurences
[16:15] <racarr> not everything XD
[16:16] <racarr> lol at comments in android input stack
[16:16] <racarr> We hold a wake lock at all times except during epoll_wait().  This works due to some                                                                                                                                                                                              // subtle choreography
[16:17] <racarr> "Subtle choreography"
[16:23] <alan_g> racarr: alf_ - do we want to hangout now? Or after racarr has spent a day implementing something?
[16:25] <alf_> alan_g: racarr: let's leave it for after
[16:25] <racarr> I agree. I just got ahead of myself. The current interfaces are fine for all I want to do now.
[16:26] <racarr> in the past. I've found really detailed tracing as a more useful way to debug
[16:26] <racarr> multithreaded/multiprocess systems
[16:26] <racarr> and might want to enable that one day?
[16:26] <racarr> but. ONE STEP AT A TIME *hits self on head with one step at a time stick*
[16:27] <alf_> kdub: how about BufferSwapperSync, BufferSwapperAsync ?
[16:28] <alan_g> racarr: ok, but it is good to share ideas about the overall shape of things too. ;)
[16:28] <alf_> kdub: hmm, Async doesn't really tell the whole story
[16:28] <kdub> alf_, yeah, "synced to what?" was my first thought
[16:29] <racarr> alan_g: The one thing I do have open for this first step is
[16:29] <racarr> the existing "InputReport" stuff to redirect the android logging
[16:29] <racarr> is conflicting in name because I can't provide an LTTNG backing for that really
[16:31] <racarr> at least, the command line option is conflicting ;)
[16:31] <alan_g> racarr: you'd like to rename it "LegacyInputReport"? Fine by me - I just stopped it spewing over the console
[16:31] <racarr> Ok
[16:31] <racarr> yes. Much appreciated :)
[16:31] <alan_g> racarr: one day we can get rid of the legacy. ;)
[16:32] <kdub> alf_, maybe FrameDroppingSwapper and VsyncSwapper?
[16:33] <kdub> sort of tough to convey all the nuances of a buffer swapper in class name ;-)
[18:31] <racarr> so how do I use lttng -.-
[18:42] <racarr> hmm neither my new lttng or the old lttng following alfs instructions
[18:42] <racarr> works for me
[18:50] <racarr> Lunccccch!
[19:13] <greyback|away> racarr: small patch for lp:~robertcarr/platform-api/mir branch so it builds against latest mir: http://pastebin.ubuntu.com/5711198/
[19:14] <greyback|away> after merging trunk ofc
[19:24] <racarr> annd back
[19:25] <racarr> greyback|away: Ah! thanks will merge
[20:07] <kdub> swapperswappers are tricky
[20:17] <racarr> :(
[21:15] <thomi> morning folks
[21:24] <robert_ancell> thomi, hello
[21:24] <robert_ancell> thomi, hey, any update on autorebuilding lightdm against libmirserver?
[21:24] <thomi> robert_ancell: should be working now
[21:24] <robert_ancell> \o/
[21:24] <robert_ancell> thomi, also, we need to enable lightdm building on saucy
[21:25] <thomi> might be done already, let me check
[21:25] <robert_ancell> thomi, https://launchpad.net/~mir-team/+archive/staging/+packages shows lightdm being rebuilt 2 May - so it doesn't appear to be working?
[21:26] <thomi> robert_ancell: ok, saucy is already enabled. I have a call with francis in 4 minutes, so I'll ask him about it then
[21:26] <robert_ancell> ok, ta
[21:27] <thomi> robert_ancell: also, I have a 50 line c++ program that reliably hangs the mir server :(
[21:27] <thomi> about to file a bug...
[21:27] <robert_ancell> :(
[21:27] <thomi> I'm really glad we're doing these stress tests, we seem to be fixing a lot of problems
[21:27] <thomi> well, when I say "we"... I'm not fixing anything :P
[21:29] <kgunn> thomi: hey...somebody's gotta break it before you can fix it
[21:30] <thomi> I'm the annoying guy who comes along and pokes holes in your nice shiny new code :)
[21:31] <kgunn> i'm grateful...good stuff!
[21:43] <robotfuel> I get the following error message when trying to run mir_demo_server on the phone: http://pastebin.ubuntu.com/5711560/ has anyone else run across this?
[21:44] <greyback|away> robotfuel: I find a reboot can help that. I sometimes get it after a package update
[21:44] <greyback|away> robotfuel: oh actually, are you running on your desktop?
[21:45] <robotfuel> greyback|away: no the ubuntu-touch image on a galaxy nexus
[21:46] <thomi> robert_ancell: got a moment for a quick hangout with francis to discuss the lightdm issue?
[21:46] <greyback|away> robotfuel: ah, I see. You need to run it via "adb shell" - not as the root user
[21:46] <robert_ancell> thomi, sure
[21:46] <robotfuel> greyback|away: I am running it in the ubuntu_chroot
[21:46] <robotfuel> via adb shell
[21:46] <robert_ancell> thomi, what is the issue?
[21:47] <thomi> robert_ancell: just the lightdm being rebuilt after every mir
[21:47] <robert_ancell> ack
[21:47] <thomi> robert_ancell: actually, don't worry
[21:47] <robert_ancell> even better :)
[21:47] <thomi> I'll manage, and pull you in if needed
[21:47] <greyback|away> robotfuel: ok good. Did you stop surfaceflinger?
[21:48] <greyback|away> robotfuel: you can do this while not in the chroot, by running simply "stop"
[21:48] <robotfuel> greyback|away: yes I ran stop && ubuntu_chroot shell
[21:48] <greyback|away> robotfuel: in that case, I'm running low on ideas. What device have you?
[21:49] <greyback|away> oh oyu said, galaxy nexus
[21:49] <robotfuel> greyback|away: yes a gnex
[21:50] <thomi> robert_ancell: you want lp:~mir-team/lightdm/unity rebuilt, right? not lp:lightdm
[21:50] <robert_ancell> thomi, correct
[21:50] <greyback|away> robotfuel: give me a minute, I'll try it on mine
[21:50] <robotfuel> I have jenkins running a glmark job on the desktop, but it should be more interesting on a phone, because fps isn't tied to the refresh rate of the monitor
[21:51] <thomi> robert_ancell: ok, we had enabled the autorebuild for unity-system-compositor, but not for lightdm, that's being done now
[21:51] <kgunn> robotfuel: on a phone you're still going to be tied to vsync
[21:51] <kgunn> unless you do something to unhinge it
[21:52] <robert_ancell> thomi, so U-S-C shows it is 19 days old
[21:52] <robert_ancell> thomi, oh duh. I was getting mixed up. I think technically we don't need to rebuild lightdm on libmirserver changes, but it is a nice to have anyway
[21:53] <thomi> robert_ancell: ok, well.. that's going in now anyway :-/
[21:53] <robert_ancell> we do need lightdm on saucy though
[21:53] <thomi> everything should be being built on saucy already
[21:53] <robert_ancell> thomi, it might actually need to be rebuilt when u-s-c changes in the future, but I'll bug you then if it's a problem
[21:54]  * robert_ancell takes a week off and forgets everything
[21:54] <fginther> yo
[21:54] <thomi> robert_ancell: so after the rebuild the packages should be pushed to ppa:mir-team/staging, ight?
[21:54] <robert_ancell> thomi, yes
[21:55] <thomi> fginther: can we do that easily?
[21:55] <robert_ancell> thomi, how do you version them?
[21:55] <fginther> robert_ancell, we can do that..
[21:55] <robert_ancell> fginther, so it just overwrites the existing one?
[21:55] <fginther> the packages can be versioned with a monotonically increasing version number
[21:55] <fginther> yes, it will overwrite the last one
[21:56] <robert_ancell> fginther, will a user upgrade from version X to X (i.e. if the binary has changed)?
[21:56] <thomi> presumably the version number will be X -> X+1 or X.1
[21:56] <robert_ancell> I was hoping we could have 0.0.1brz25.3 for the third rebuild of bzr version 25
[21:57] <greyback> robotfuel: ok I got it working here. I made sure everything was up to date. Then reboot, adb root, adb shell, stop, ubuntu_chroot, mir_demo_server&, mir_demo_client_accelerated
[21:57] <fginther> robert_ancell, if the user does a dist-upgrade, they will get the lastest, but if a user does a install of just mir, it will not pull in the lightdm-mir
[21:57] <robotfuel> greyback: thanks, I didn't try the client part
[21:58] <greyback> robotfuel: if the server returns that error message you got, then the client will fail. Server needs to be running
[21:58] <greyback> before client can show anything
[21:58] <thomi> robert_ancell: latest mir bug I've found is posted at: https://bugs.launchpad.net/mir/+bug/1185183
[21:59] <kdub> i can try on my phone... see what happens
[21:59] <robotfuel> I am using image 132, maybe that image has an issue.
[22:00] <greyback> robotfuel: perhaps, that I cannot say. apt-get dist-upgrade all up to date?
[22:00] <fginther> robert_ancell, it is very difficult to get the version numbers to 'reset', so what happens is, you'll see a version ending in '0' when the package is built due to a source change, othewise, the version will end in X, where X is always greater then the last X
[22:01] <robert_ancell> fginther, ok
[22:20] <robotfuel> greyback:  distupgrade fixed the issue, thanks!
[22:20] <racarr> earrrly in. early out!
[22:20] <greyback> robotfuel: glad to hear it.
[22:30] <kgunn> cya racarr
[22:50] <thomi> robert_ancell: got a second?
[22:50] <robert_ancell> thomi, sure
[22:51] <thomi> robert_ancell: so the bug I reported above is blocking the stress tests moving much further. I wonder who I should bug about this? Or should I just leave it with you and work on something else today?
[22:52] <robert_ancell> thomi, I'll have a look at it
[22:53] <thomi> robert_ancell: thanks
[22:58] <robert_ancell> thomi, always exactly after 500 times?
[22:58] <thomi> robert_ancell: 501 actually, yeah
[22:58] <robert_ancell> weird
[22:59] <thomi> yeah. I wondered if the sevrer was leaking 2 file handle per connection
[22:59] <thomi> just a guess
[22:59] <robert_ancell> thomi, why does it close the fd?
[22:59] <thomi> robert_ancell: otherwise the client leaks them. see mail to ML
[22:59] <robert_ancell> ok, that's just a workaround
[22:59] <thomi> RAOF was going to fix that in the client API
[22:59] <thomi> yeah