#ubuntu-mir 2013-08-05
<RAOF> vibhav: What's your intended target for python-mir? Just binding the functions in the mirclient API would work, but depending on your target you might want to do something extra.
<smspillaz> RAOF: heh, I'm just thinking about how well the multithreaded callbacks would interact with the GIL
<RAOF> Easily! You marshal everything into a single thread!
<smspillaz> RAOF: of course. But ideally you'd probably want to do that in a separate library and then bind to that
<smspillaz> since otherwise you'd have crazy locking overhead
<smspillaz> (*based on a vast oversimplication of the GIL)
<smspillaz> RAOF: I remember it was quite surreal when racarr was explaining that to me while we managed to get lost on the bart
<RAOF> Heh
<smspillaz> RAOF: I actually kinda like the multithreaded callbacks approach, partially because it means Death to the Main Loop [tm]. The only downside is that integrating it with a main loop is a little awkward
<duflu> RAOF: Hmm, there's no /Mir/ in any live images yet, right?
<duflu> smspillaz: Also, if you're receiving non-input surface events, that's a different thread again :)
<duflu> I mean :S
<smspillaz> duflu: yeah, iirc it was one thread for surface events and one thread for input events
<duflu> smspillaz: https://bugs.launchpad.net/mir/+bug/1194384
<ubot5> Ubuntu bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Medium,Triaged]
<smspillaz> duflu: I don't think the threading is a problem, rather - the whole MirEvent is just awkward
<smspillaz> *MirEvent thing
<smspillaz> I much prefer the wayland approach -> every unique event happens in its own callback
<duflu> smspillaz: Can you elaborate?
<duflu> Because technically all events have their own callbacks
<duflu> Or you mean callback type?
<smspillaz> that being said - wayland screws up in one area: keyboard and mouse events are reported to you in surface relative co-ordinates but you can only have one handler per mouse or keyboard
<smspillaz> (afaict)
<smspillaz> duflu: callback type
<duflu> I see
<smspillaz> duflu: unions are a kinda sucky way of representing data like this
<smspillaz> see XEvent
<duflu> It is nice to be able to take shortcuts and sometimes handle different even types in a single callback
<duflu> Not to mention, nice to avoid the user learning many callback prototypes
<smspillaz> and then you end up with a thousand-line long "Event" callback
<smspillaz> which is made worse by the fact that it may be called in multiple threads simultaneously
<smspillaz> and the only real way to fix that would be to dispatch the potentially giant switch statement into separate functions
<smspillaz> ... which might as well be done at the client library level
<smspillaz> see for instance: https://github.com/smspillaz/xbmc/commit/ddab367b4928bc50f168d157b6b4939f3062402a#L2R78
<smspillaz> (ah, my bad, wayland does actually give you the surface the event happened on)
<duflu> smspillaz: Fair point. I would then say... use a single callback prototype demultiplexed at registration:    set_event_handler(filter, callback)
<smspillaz> duflu: eg - wl_pointer_add_listener :)
<smspillaz> (I would show you an example, but I can't because I have to dlopen libwayland-client.so and then use the protocol directly because things like wl_pointer_add_listener are all static inline functions ....)
<smspillaz> but eg: https://github.com/smspillaz/xbmc/commit/ddab367b4928bc50f168d157b6b4939f3062402a#L2R36
<duflu> smspillaz: BTW pointer events are meant to be surface-relative in Mir too. It's just not implemented yet
<duflu> -pointer +motion
<duflu> That's odd. My Mir performance dropped about 5% over the weekend (after updates)
<duflu> But it's only compositing performance that dropped. Bypass results are unchanged
<TheDrums> duflu: There are no *official* cdimages.ubuntu.com images, but the Xubuntu team did create one using the latest from the system-compositor-testing PPA for ease of testing.
<duflu> TheDrums: Ah thanks. That explains the new bug reports from Xubuntu users against Mir
<TheDrums> Yes, seems while several of the Mir devs were sent the message, you were not one of them.
<skellat> Marking the one report about complete screen corruption as incomplete was not a good thing as the only information that was recoverable was provided.  The logs are inaccessible.
<skellat> Unless we were running exterior serial consoles, we wouldn't have had a way to recover such.
<TheDrums> duflu: http://www.mail-archive.com/xubuntu-devel@lists.ubuntu.com/msg08905.html is the message.
<duflu> skellat, I know that now. About to fix it
<RAOF> âª And on that farm he had a laptop â«
<duflu> RAOF: Awesome! (?)
<RAOF> Yes.
<duflu> RAOF: Quad core IPS SSD goodness?
<RAOF> Correct
 * duflu gives all builds to RAOF
<duflu> RAOF: What's the key "depth" like?
<RAOF> It's pretty shallow, but typable.
<RAOF> Luncheon.
<tvoss_> good morning :)
<tvoss_> RAOF, ping
<tvoss_> duflu, ping
<RAOF> tvoss_: Pong
<tvoss_> duflu, ping
<duflu> tvoss_: pong
<tvoss_> alf__, duflu could you guys please sync up on the multi-monitor and switch-branch integration? A summary by mail would be great!
<alf__> tvoss_: duflu: sure
<duflu> alf__: I will try to do the timing workaround to solve non-cloned multi-output. Then "more robust solutions" are not on the critical path and blocking...
<alf__> duflu: The BackBufferStrategy mechanism was introduced as a way to inject policy for such situations (MultiAcquisition being one such policy). I think it is the right layer to put the policy into, vs the Compositor, which should not have to care about this at all.
<duflu> alf__: I think the strategy layer is a bit hackish. It exists to match the exact semantics in which buffers will be called/used. That would be better enforced where they are called and used (hence "more robust")
<duflu> -called +acquired
<duflu> alf__: I mean, a nicer solution would be to keep that multi-monitor logic closer to the multi-monitor compositing.
<duflu> I was only suggesting the timing workaround as a quick solution which requires no effort on your part
<duflu> Unless there are other "simple" ways to semi-synchronize the compositing threads without actually synchronizing them
<duflu> And without breaking bypass requirements
<tvoss_> duflu, are you loosing the z character?
<duflu> tvoss_ ?
<tvoss_> duflu, my xchat eats away certain characters :)
<duflu> tvoss_: No, it's just you... ?
<tvoss_> duflu, damn :)
<alf__> duflu: how would that work in the (DisplayBuffer)Compositor?
<duflu> alf__: You mean timing workaround?
<alf__> duflu: yes
<duflu> alf__: Actual comsumed compositor buffers get a timestamp. And new ones are not allowed to be consumed (hence get reused) for the next 10ms
<duflu> So multiple monitors with roughly the same refresh rates share the same compositor buffer. Or at least don't steal each other's or wake the client up any faster than one monitor would
<duflu> It actually feels close to the "right solution", just maybe in the wrong place
<duflu> And bonus: That won't break bypass.
<alf__> duflu: How does MultiAcquisition break bypass (I don't mind dropping it, I am just trying to undestand). In any case the ultimate benchmark for this is how much each policy affects visual fluidity. BTW, you can run mir_demo_server_shell --display-config=sidebyside (with two screens) and move clients between the outputs to test.
<alf__> (from lp:mir)
<duflu> alf__: Cool thanks
<duflu> alf__: The issue with multiacquisition, which had be stuck for weeks, was its assumptions about the exact ordering of compositor acquire/release calls. Bypass has two acquired simultaneously most of the time, but also requires that they're always different buffers (when available)
<duflu> -be +me
<duflu> alf__: Also, no one has pinpointed the first primary cause of the lag bug. Other than it was in the buffering code I replaced, _somewhere_ :/
<alf__> duflu: isn't this fixed by https://code.launchpad.net/~vanvugt/mir/fix-1199450/+merge/178236 ?
<duflu> alf__: The first cause is fixed by switch (prerequisite). But switch introduces triple buffering which would cause the same problem. So the fix- branch solves that too
<alf__> duflu: do we always use triple buffering or only for framedropping and bypass?
<duflu> alf__: It's always triple now, logically. But I defer allocating the third buffer until the client behaves in a way that uses 3 simultaneously
<duflu> The lazy allocation is generalized... it keeps the number of real buffers low until more are required
<alf__> duflu: sounds good
 * duflu shuffles monitors
<alf__> duflu: hmm, how do you stop a client that is (or rather wants to be) double-buffered from acquiring the third buffer?
<duflu> alf__: I just realized the primary thing keeping it at double was removed when I fixed those issues on Friday. Now it's only timing keeping it at double. If a client tries to render without using a timer (limited only by swapping) then it will expend to triple very quickly now :/
<duflu> -expend +expand
<duflu> That might need revisiting. I can add dynamic resizing without much fuss
<duflu> alf__: Multi-monitor just works, nice. If only I had a GUI to set the layout :)
<duflu> Or a language... like "DVI1 leftof VGA1"
<RAOF> didrocks: Have we won a Mir promotion to Main?
<didrocks> RAOF: it was too late on Friday and risky, so we pinned to proposed. The promotion/publication is now in progress
<RAOF> didrocks: Cool. Sorry about that delay.
<didrocks> RAOF: no worry ;)
<dholbach> good morning
<RAOF> Hm. ZoÃ« bath time!
<duflu> alf__: Just a minor speedhump: https://bugs.launchpad.net/mir/+bug/1208354
<ubot5> Ubuntu bug 1208354 in Mir "mir_demo_server_shell crashes with --display-config=sidebyside" [Undecided,New]
<alf__> duflu: ahh, yes this is fixed by lp:~afrantzis/mir/multimonitor-misc-fixes â lp:mir (will hopefully land soon)
<duflu> alf__: Very nice, thanks
<didrocks> RAOF: still around?
<RAOF> didrocks: Yeah.
<didrocks> RAOF: see #ubuntu-devel please :)
<RAOF> didrocks: Ah, I see #ubuntu-devel.
<didrocks> heh ;)
<seb128> can we just drop ppc? :p
<didrocks> +1000 :p
<duflu> alf__: I will have most of your requests resolved tonight but not all... At least multi-monitor is fixed, without breaking bypass \o/
<alf__> duflu: great!
<tvoss_> duflu, \o/
<doko> Saviq, ping
<Saviq> doko, pong
<alan_g> hikiko: how's it going?
<hikiko> alan_g, I started from create display
<hikiko> and now I am writing a NestedDisplay class
<hikiko> do you think I should do something else first
<hikiko> ?
<alan_g> hikiko: that sounds a sensible approach
<racarr> Morning
<greyback> racarr: morning!
<alan_g> Afternoon
<racarr> greyback: Morning! welcome back
<greyback> racarr: thanks :)
<racarr> greyback: I'm sure you are still catching up but maybe we should do a catch up soon?
<racarr> I was kind of doing other stuff last weekly so expect for some stuff for OSK mostly not on unity
<greyback> racarr: certainly. Whenever you're ready
<racarr> so kind of lost track of exact status
<greyback> Yep I'd like to know where the OSK work is at
<racarr> greyback: Ok after the 8:00 mir stand up maybe?
<greyback> Daniel is away, so I need to at least know what it's status is
<greyback> racarr: perfect
<kgunn> greyback: racarr can i lurk on your sync?
<greyback> kgunn: sure
<racarr> kgunn: Eh...
<racarr> it's kind of "cool crowd only"...so I dunno
<racarr> :p
<racarr> I am just teasing. Have a good time in IoM?
<kgunn> racarr: consider we were the only people at that hotel under 60.... :-/
<kgunn> racarr: we did gointo town one night...me ancell, didier & michal... food was sooo good & company was good :)
<racarr> kgunn: Aha. that must have been a little strange (hotel situation)
<kgunn> didrocks: just checking in...did RAOF overcome the alioth issue
<didrocks> hey!
<kgunn> racarr: it was bizzare
<didrocks> kgunn: he did, and so we have everything uploaded
<didrocks> promoted some components to Main
<didrocks> howerver, multiples upload from him and I to ignore properly powerpc
<didrocks> however, on two components
<didrocks> we still try to build with mir for the -ati and -nouveau driver
<didrocks> so this one should be fixed, RAOF assume this wasn't needed (but it wasn't built) when I asked him
<didrocks> we can:
<didrocks> - either do a bad/ugly #ifdef
<didrocks> - let RAOF fix it more properly (I would be more in favor of that)
<didrocks> the second point is that unity-system-compositor don't enable accceleration anymore on the intel or ati machine
<didrocks> so even unity doesn't start
<kgunn> didrocks: good ol' powerpc :)....ok, that stinks  about new prob
<kgunn> didrocks: did you really mean intel ? or nvidia rather
<didrocks> nvidia, sorry :)
<didrocks> I can't even use jetlag as an excuse
<didrocks> kgunn: for powerpc, I'll be in favor of guns if this continues that road ;)
<kgunn> :))
<didrocks> I'll send an email with you/RAOF/robert
<racarr> greyback: Sync up?
<racarr> kgunn: ^
<greyback> racarr: ok
<kgunn> racarr: gotta link ?
<racarr> making one
<racarr> https://plus.google.com/hangouts/_/a38f0a95d50f766f61f95dd52ef79056c74c360c?authuser=1&hl=en
<racarr> kgunn: greyback: ^
<kgunn> ricmm: ^
<kgunn> racarr: were you going to refactor down to singled method interface first ? or try chasing some approval on the current mp ?
<kgunn> regarding...https://code.launchpad.net/~robertcarr/mir/surface-configuration-interface--for-shell/+merge/177055
<racarr> kgunn: i am not sure
<racarr> I am not throwing up my hands (actively thinking about it) but am kind of at a loss on both branches as it stands
<racarr> The single method variant is awkward, because like in the comment I just left
<racarr> you end up applying the surface state changes, etc, before you actually update the member variable tracking the state
<racarr> and there are all sorts of ways around that (i.e. the function returns the new state, and an std::function to apply it which the surface then calls after updating the member variable. Or the configuration interface gets some object/function passed in that it uses to update the surface state in between the selection and application step
<racarr> but both of these just mean, instead of an interface with two roles it's now a method with two roles.
<racarr> so I am not sure this makes sense.
<racarr> I also can't make an argument that it makes sense to split each method in to a seperate interface, i.e. AttributeDecider and AttributeApplier because
<racarr> they will always be passed around in a pair in the server
<racarr> so pattern is to pass them as a composite type i.e. some AttributeStuff, which has ethods like decider() and applier()
<racarr> but then it's not clear why that method doesn't just have decide, and apply, like the configurator does now in the MP
<racarr> I think it's probably somewhat more of an indication tht the way we are handling state of msh::Surface is bad
<racarr> so I guess I am seeing if there is something I can do about that for the attribute stuff without taking more than a few days
<racarr> alan_g: A completely different proposal for surace-configuration-interface
<racarr> alan_g: msh::Surface loses the state, type, etc member variables
<alan_g> racarr: sorry, my head is full of ~vanvugt/mir/switch/+merge/178527
<racarr> that's ok :)
<alan_g> But that sounds interesting
<racarr> alan_g: Basically the thought is if mir is only passing these values through the shell and frontend perhaps it should be a shell component that stores them and mir just passes interfaces to this component for getting back out to frontend
<racarr> but it's not too much hassle so maybe I will just try and implement it and you can check it out later :)
<racarr> switch branch scares me ;)
<racarr> alan_g: btw if you are ever bored remind me to tell you about the craziest (most interesting ;) idea I have ever heard for handling mutable state in highly threaded C++ programs XD
<alan_g> racarr: The problem of where to store these values (and how to synchronize access to them) dates from the decision to hold them in the shell, and not in the model.
<racarr> it needs GC though so it's not for us. it's just really interesting
<alan_g> racarr: I'll take a raincheck
<racarr> XD
<racarr> yeah, I understand that bit sort of
<kgunn> racarr: maybe kdub can take a peek this afternoon
<racarr> Yeah. I'll harass him ;)
<racarr> alan_g: This might be a step in that direction, i.e. rather than the surface holding this state directly it gets it through some get_attribute and set_attribute interface to this SurfaceConfiguration from the shell
<racarr> which could also be implemented by
<racarr> super scene graph model 2.0 :p
<alan_g> racarr: I know I need to get back on that hobbyhorse
<alan_g> And actually propose something concrete.
<racarr> alan_g: Ok. That would be good
<alan_g> If only folks would stop with the big complicated MPs
<racarr> I haven't been able to get to anything concrete on that
<alan_g> ... ;)
<racarr> and I am worried that we are
<racarr> approaching feature freeze
<racarr> alan_g: I.e. feature freeze is august 29th
<kdub> racarr, peek at notify focus? or switch
<racarr> kdub: Err, the surface-configuration-interface
<racarr> it doesn't exactly need review, just ideas I guess
<kdub> racarr, i'll refill my coffee and take a look now
<racarr> kdub: Ah. excellent. Thanks :)
<kgunn> bschaefer: are you free-ish today ?
<bschaefer> kgunn, a bit more ibus stuff to do, but after that I should be
<bschaefer> kgunn, still trying to get my desktop back up and working :(
<kgunn> bschaefer: oh crap
<kgunn> bschaefer: but ok...i'll loop you in
<bschaefer> yeah, my HD decided to die and can no longer read/write to it...soo its toast :(, but i've to reinstall some new things to a new HD!
<bschaefer> kgunn, sounds good!
<kgunn> kdub: racarr ...yeah, hate to be the management ogre....but we really need to target gettting unity/mir onto touch trunk (w/ osk consideration) 10 days from now
 * racarr takes one of the little pills labelled "Up"
<racarr> :p
<racarr> Another option for client-focus-notifications
<racarr> surface loses surface_state_focused/unfocused. introduce an interface msh::Focus with one method Focus::give(std::shared_ptr<msh::Surface>)
<racarr> this obect tracks the current focus, so it can do unfocused notifications
<racarr> it also needs to know to give the focus to the next surface if
<racarr> the focused surface is destroyed, so I think msh::Surface also gains a method like
<kdub> racarr, the cloggable event sink
<kdub> i still feel like i'm missing the big picture on the 'why'
<racarr> msh::Surface::take_focus(std::unique_ptr<FocusToken>)
<racarr> with a d'tor that knows what to do
<racarr> kdub: Basically the idea is inbetween the call to create_surface
<racarr> and sending a response to the client
<racarr> we may generate surface configuration events
<racarr> i.e. surface id 7 took focus
<racarr> but if we send this to the client before it's been told what surface id 7 is
<racarr> it can't interpret it
<kdub> ah, gotcha
<racarr> so we have to ensure the wire events are sent after the create_surface response
<racarr> kdub: it's a little sketchy actually because it relies
<racarr> on the fact that invoking the Done callback from create_surface
<racarr> synchronously writes the message.
<kdub> seems like the object with the best information to control that timing is the msh::Surface
<kdub> perhaps the SessionManager as well
<racarr> hmm, not as it stands now, because even after SessionManager::create_surface_for
<racarr> returns
<racarr> the SessionManager can't know if things have been sent over the wire yet
<kdub> right, so it seems the shell has a false idea about when a surface is up and running
<kdub> maybe msh::Surface should have the same lifetime as the client surface on the other side of the ipc barrier?
<kdub> that way a focus event could block there until we know the client is ready
<racarr> maybe
<kdub> alternatively, we could just have more complex logic client side
<racarr> I think you can always end up with
<racarr> situations where the client can't decide? Maybe not.
<racarr> well
<racarr> if the client buffers the events and waits until the surface appears
<racarr> then it can't really detect events which are actually malformed/in error
<racarr> kdub: The lifetime idea is kind of nice but I'm not sure how it would be implemented
<kdub> i guess we have two responses now to that rpc call
<kdub> 'you are focused' or 'you are not focused'
<kdub> that would take care of it too :)
<racarr> i.e.  you construct all of the surface dependencies, allocate the id, make sure everything works, send the response and then allocate the msh::Surface
<racarr> kdub: Not quite because a surface may open and not necessarily receive focus
<racarr> or maybe it opens and the shell restores it's state to maximized
<racarr> because that's how it was last run
<racarr> so there could be many responses I think
<kdub> right, the surface opens and is not focused
<kdub> at the time the surface is created, we should be able to know the state of the surface
<kdub> seems that should be sent as the initial state in the return of the rpc message
<racarr> hmm
<racarr> ok, so the current model is kind of like, the initial state is defaulted
<racarr> i.e. your state is restored, your surface type is normal, you do not have focus
<kdub> right
<racarr> and you will be notified of anything else
<racarr> so we could extend create surface to return like
<racarr> surface_id, state, type, focus
<racarr> but then wont e still need a proxy event sink?
<racarr> Because we have to ensure that later when these change
<kdub> that seems like a separate issue
<racarr> we still send notification
<kdub> the event sink still has to be accessible to the shell surface, yes
<racarr> but that we don't send notification on this first call
<racarr> but I mean, the surface will still be created in the default state
<racarr> so what makes the first change to 'focused' occur as part of the create_surface reply
<racarr> and not as an event over the wire
<kdub> the shell decides the initial state when the surface is created
<kdub> or :) it should be
<kdub> that gets sent in the reply, and afterwards, any updates to the state are sent via the event sink
<racarr> kdub: I think it's hairy for the shell to decide that way
<racarr> because now essentially any interface like
<racarr> kdub: Ok, I was thinking
<kdub> as opposed to deciding state after creation, and imposing synchronization across/near the ipc boundary so the client can figure out what state its in? :)
<racarr> it had to happen before surface construction, but actually it could happen
<racarr> kdub: Well my concern s that doing it before surface construction was difficult because then the shell will have methods like
<racarr> decide_state_for_surface_creation_params and decide_state_for_surface
<kdub> right, not before
<racarr> kdub: But actually, the surface could use the SurfaceConfigurator from the other branch (XD)
<racarr> er welll I still cant quite figure it out but will go on
<racarr> then in it's constructor it calls like
<kdub> ipc request comes in, we ask the shell to create a surface, we read the created surface, and then we run done
<racarr> state = select_attribute_value(surface_state)
<racarr> type = select_attribute_value(type) focus = select_attribute_value(focused)
<racarr> and it doesn't go over the event sink because there was no call through to msh::Surface::configure
<kdub> sounds better
<racarr> kdub: Ok so.I think this makes sense, but now I am having a little difficulty figuring out how the mechanism happens
<racarr> kdub: i.e. the surface is being constructed
<kdub> i think we need some extra fields in protobuf's Surface
<racarr> so the shell gets select_focused(msh::Surface &)
<racarr> and says, hey this is a new surface, so it says yes, focused
<racarr> but now what actually sets
<racarr> the input focus to
<racarr> that surface
<racarr> I'm not sure if it makes sense for
<racarr> it to be select_focused because
<racarr> the surface isn't even initialized at that point.
<kdub> we need to ban the use of the word 'surface' :)
<kdub> it isn't initialized where?
<kdub> client side?
<racarr> no, I meant, on the server, if we use some interface like
<racarr> select_attribute_value(focused) that is called during the constructor
<racarr> and no one is notified of this
<racarr> then what actually sets the input focus
<kdub> from the frontend, i see this
<kdub> http://pastebin.com/vD7UCRUs
<racarr> kdub: Ok.
<racarr> kdub: trying to reword the last concern.
<racarr> the thing is, right now the FocusMechanism, sets the focused attribute on the surface
<kdub> okay, yeah. i sorta detected we were talking about two different parts of code
<racarr> after, applying the mechanism of the focus of the surface. i.e. making sure it's on top and giving it key focus
<racarr> so, if the surface instead takes the focused attribute itself during creation
<racarr> then what actually
<racarr> does this giving key focus, etc step.
<kdub> racarr, don't know where that question ended :)
<racarr> err, sorry
<racarr> I mean which component, or hwere in this flow
<racarr> do we actually set the key focus
<racarr> because there is no
<kdub> been reading through a bit of the code more
<racarr> msh::FocusSetter::set_focus_to(msh::Surface) now
<racarr> as the only entry point for focus changing
<racarr> (when I say now, I mean, in this select_attribute_value model)
<kdub> and really, i think in msh::SessionManager::create_surface_for, it calling set_focus_to is probably in the wrong place
<kdub> my head's currently exploding with 'hey, a std::future seems perfect for this sort of thing' :)
<kdub> but
<racarr> mm
<racarr> the call to set_focus_to is wrong I agree
<racarr> that should be entirely shell policy it's just there so we could have focus before we had a shell or example servers
<kdub> a notification after SessionMediator::create_surface's done->Run() to the focus setter seems appropriate sorta
<racarr> I was thinking about that, or even right before i.e. say
<kdub> with the idea, 'hey Focus stuff, time to reconsider who has focus'
<racarr> SessionManager::create_surface_for(...
<racarr> surface = create_surface()
<racarr> and then like
<racarr> apply_surface_attributes(surface)
<racarr> then it returns to the SessionMediator (not sure it needs to happen after done->Run())
<racarr> but, what does this function apply_surface_attributes look like? I mean it's not an interface because it's just...do_stuff(surface)
<kdub> might not be, just musing a bit
<racarr> and is it supposed to be written like
<racarr> switch (surface_state): case maximized: unity_maximize_surface(), .... swtich(surface_focused): case focused...
<racarr> etc...
<racarr> kdub: Yes. thanks for the musings :) this is helpful
<kdub> racarr, no problem :)
<racarr> kdub: The CloggableEventSink solves another problem too
<racarr> which is, say we have sorted out this focus stuff by setting it as part of construction, or even without client-focus-notifications
<racarr> So, the SessionMediator invokes create_surface, then before calling done->Run()
<racarr> the thread yields
<kdub> right, and then the shell changes focus
<kdub> in the time period, or something
<racarr> yeah or maximizes the surface or whatever
<kdub> EventSink, primarily, is not an interface which has any synchronization guarantees, its purpose is to send messages
<kdub> i think a richer synchronization
<kdub> even 'client ready for events' on msh::Surface, that is invoked after done->Run makes a bit more sense
<racarr> I think the CloggableEventSink keeps it that way though, it's still not providing any synchronization guarantees to the msh::Surface, it's just sending messages
<racarr> it's only the SessionMediator that knows about the synchronization
<racarr> but hmm, yeah
<kdub> right, so why not synchronize between SessionMediator and SessionManager then
<kdub> instead of synchronizing between SessionMediator and EventSink, so that SessionManager can sync with Event sink too later :)
<racarr> hmm, how
<racarr> I guess I see two ideas, one could be maybe msh::Surface contains some attribute
<racarr> client_ready_for_events
<racarr> and it buffers the configuration events itself (i.e. like the cloggable event sink does now)
<racarr> this was my original idea actually, but I was worried that this
<racarr> distributes frontend state in to shell, i.e. msh::Surface doesn't really care what state the socket is in
<racarr> so I thought maybe the SessionMediator should be responsible for
<kdub> well, msh::Surface cares that a surface has been created
<racarr> mediating the IPC synchronization requirements, with the msh::Surface interface. if that makes any sense.
<racarr> Mm
<racarr> I like the idea of
<racarr> not creating the msh::Surface
<racarr> until we have sent the response, i.e. like
<racarr> SessionMediator::create_surface(params)
<racarr> auto params_attributes_and_id = SessionManager::create_surface_for(session, params)
<racarr> pack_response(); done->Run()
<kdub> right, i just considered the id as part of the parameters above :)
<racarr> SessionManager::...actualize_surface(id)
<racarr> or something?
<racarr> which creates the actual msh::Surface
<kdub> haha, self_actualize(), reduce_karma(), balance_chi()
<kdub> alan would love those names ;)
<racarr> haha.
<racarr> mir::shell::SurfaceEnlightener ;)
<racarr> hmm ok. So I actually like this a fair amount my main concern is like
<racarr> when are the other resources initialized, and such i.e.
<racarr> in particular in error cases
<racarr> i.e. what if we fail to allocate the buffers
<racarr> it seems strange that we have already told the client they have received a surface
<racarr> and im not entirely sure how we report the error
<racarr> but that's probably sortable
<racarr> I still don't know how to make the focus mechanism work in this model though...
<racarr> also there is daniel's need fixing on not using attributes at all for focus :p
<racarr> but even if that becomes something entirely seperate from EventSink
<racarr> whatever this thing is will still need synchronization
<kdub> racarr, if you take a look at the way i'm sending display info
<kdub> (my MP up for review)
<kdub> we can send things via protobuf a bit easier
<racarr> kdub: ok ill check it out after lunch
<racarr> lunch nowww
<racarr> back
<bschaefer> kgunn, hey, soo I saw that email, so ati, and nvidia are having problems starting up
<kgunn> yes...so it seems
<bschaefer> robotfuel, are there any machines that I would be able to ssh into?
<bschaefer> strange indeed...and it looks like compiz is hanging on loading opengl...
<robotfuel> bschaefer: it looks like ps-radeon-hd6870-he is open
<bschaefer> robotfuel, awesome, thanks!
<robotfuel> bschaefer: ps-nvidia-gs8400-le is also open with xmir on it
<bschaefer> perfect, now hopefully I can figure something out :)
<robotfuel> bschaefer: that one seem to work with xmir, the nvidia-gt640  had a black screen last week, today it's been doing a utah death test.
<bschaefer> robotfuel, its fine to install u-s-c on the radeon one right?
 * bschaefer checks if its running or not
<bschaefer> robotfuel, hmm the radeon machine appears to be working
 * bschaefer reboots just to check
<robotfuel> bschaefer: I don't think the radeon machine has xmir on it, but it passed some phoronix tests this morning
<bschaefer> robotfuel, whats the utah death test do?
<bschaefer> robotfuel, well it had the mir serve rrunning in the background...
<robotfuel> bschaefer: it tries to kill utah
<bschaefer> hmm yeah:  /usr/sbin/unity-system-compositor --enable-input=false --from-dm-fd 9 --to-dm-fd 13 --vt 7
 * bschaefer double checks the x log
<bschaefer> yup so, the redeon machine appears to be working
<bschaefer> and its using the u-s-c testing ppa
<bschaefer> kgunn, ^
 * bschaefer looks at nvidia
<robotfuel> bschaefer: ok, I wasn't sure because of the last test run on that radeon machine, the non-xmir job ran after it and must have failed to provision the machine. but it's on an old jenkins server with known cobbler issues. The new jenkins machine has it's own cobbler server. :)
<bschaefer> robotfuel, cool :), well im also going to go and make sure things are updated as well
<kgunn> bschaefer: ? now i wonder what didrocks might have seen....whether or not it was on these machines....or some others
<bschaefer> kgunn, well it seems like there are some updates...
<kgunn> bschaefer: so it healed itself ?
<bschaefer> kgunn, well im not sure, these updates could throw it all off :)
<bschaefer> it would be strange if it did though
<bschaefer> kgunn, hmm well the nvidia gs8400 seems to be fine, now to go update the radeon one...
<bschaefer> I hope they don't just heal them selfs though...as when things do that they usually break again
<olli__> hiho
<olli__> in which BP is the bypass work captured?
<olli> kgunn, kdub ^
 * kgunn digging
<kdub> https://code.launchpad.net/~vanvugt/mir/switch/+merge/178527
<kgunn> https://blueprints.launchpad.net/ubuntu/+spec/client-1310-mir-xmir
<olli> https://blueprints.launchpad.net/ubuntu/+spec/client-1310-mir-xmir
<olli> heh
<kdub> oh, blueprint, not mp :)
<olli> thx guys
<bschaefer> kgunn, robotfuel and updated radeon is working as well...
<bschaefer> hmm possibly didrocks was running into something that was fixed already?
<kgunn> weird
<bschaefer> yes indeed...
<kgunn> robotfuel: so you got the standalone X runs of phoronix across all the new platforms ?
<kgunn> brb guys...
<robotfuel> kgunn: we are testing utah first to make sure it's stable. I setup all the machines on friday to do a death test on the utah and found we needed more loop devices on the new server, I want to get 100 test runs with the new server config before we move to start testing X.
<tvoss> ffs
<kgunn> robotfuel: do you mean 100 utah death test runs
<robotfuel> kgunn: yes, we are at 28 of 100 now. so we can start the X testing tomorrow if we have utah stable.
<olli> kgunn, robert_ancell, RAOF, what's the status of upstream acceptance? I see activity on all but nouveau and mesa, how far/close are we?
<olli> and I admittedly only looked into the July archives ;)
<robert_ancell> olli, otp, be back in 5
<olli> robert_ancell, ack
<kdub> yay, found a spare monitor in the garage
<robert_ancell> olli, RAOF is not online yet, but I think he said good progress on the X patches. I don't think any high level "would we accept this" has been done yet, more "does this work correctly"
<robert_ancell> olli, at least some of the patches are not complete enough for upstream to consider landing them, I think mesa was in that case
<olli> robert_ancell, mind following up when he is on and then either update me via mail or directly in a slide that I will ping you
<robert_ancell> olli, yep, will ask him when he comes online
<olli> robert_ancell, you should have received a ggdoc mail with the doc
<robert_ancell> olli, looking..
<olli> robert_ancell, thx
<kdub> whoohoo, display resize requests are working reasonably well... few dings to hammer out
<kgunn> kdub: that's great....feeling better about multimon by the moment
<RAOF> olli: Nouveau will be easy, once the Xserver patches land; we only need to satisfy mlankhorst there âº
<RAOF> olli: I need to give mesa a prod, but I'll do that once I can include radeon support in there - the dma-buf patch to make that work is now on the lists (*all* the lists!).
<robert_ancell> RAOF, hey, does XMir need any updating to work with the display configuration changes in mir r925?
<RAOF> robert_ancell: Shouldn't, but we should now be able to actually do RANDR.
<kdub> no, not yet :)
<robert_ancell> RAOF, I just tried the latest mir+u-s-c combination for the system-compositor-testing PPA, but X doesn't seem to complete starting up
<robert_ancell> i.e. black screen
<RAOF> kdub: I think there's enough there to do the read-only bit of RANDR, at least.
<kdub> that just gets across the ipc barrier, still working on the server-side display configuration (focus based)
<kdub> not all the bits are hooked up serverside, should be soon though
<RAOF> robert_ancell: I'll have a look.
<robert_ancell> I'm just recompiling X here just to double check
<RAOF> I did fix a problem where libmirclient would segv, but you're obviously not seeing that.
<robert_ancell> no
<bschaefer> robert_ancell, what card are you on? As I tested out ati/nvidia today and both were working
<bschaefer> though there were some reports of black screening from didrocks...
<robert_ancell> bschaefer, intel
<bschaefer> hmm well hopefully rebuilding X fixes that :)
 * kdub tried intel today, at least the basic mir test programs seemed ok
#ubuntu-mir 2013-08-06
<robert_ancell> RAOF, lightdm.log - http://paste.ubuntu.com/5953288/, X log - http://paste.ubuntu.com/5953289/. Tried with a rebuilt Xorg, but no change
<robert_ancell> RAOF, any ideas?
<robert_ancell> also, any thoughts on bug 1206744?
<ubot5> bug 1206744 in XMir "black screen on nvidia gt640 with system-compositor-testing ppa" [Critical,New] https://launchpad.net/bugs/1206744
<RAOF> Hm. My guess is that X is spinning in a loop somewhere; attaching gdb might be fruitful.
<RAOF> robert_ancell: Ah, I should respond on that bug, even though my current response is going to be "huh?"
<RAOF> robert_ancell: Oh - does XMir start against mir_demo_server_shell? That's easier to test while keeping an active session.
<robert_ancell> RAOF, I'll try that in a few mins
<RAOF> Hm. I'm not sure this powerpc build of xf86-video-ati is actually going to start.
<duflu> I assume it ignores the package name for starters ;)
<RAOF> What do you mean? There's plenty of PPC hardware with radeon chips.
<duflu> RAOF: "86"
<RAOF> Ah.
<RAOF> Yeah, that's been wrong since forever.
<robert_ancell> RAOF, yeah, so I can't run X in mir_demo_server - any debugging ideas? Can you reproduce?
<RAOF> robert_ancell: I couldn't on radeon; I'll try again on intel.
<RAOF> robert_ancell: There's a new set of drivers in ppa:mir-team/staging which you might want to try, too.
<robert_ancell> RAOF, I have the drivers from main, which seem to be the latest
<RAOF> Ah, yeah. For intel that's true.
<RAOF> Ah, yes. I really, truly, can't reproduce with current stuff on radeon.
 * RAOF reboots to turn on his intel card
<RAOF> Huh. I can't reproduce the hang, but I *can* reproduce a segfault
<robert_ancell> RAOF, in XMir?
<RAOF> In the intel driver.
<RAOF> Which you might not be hitting, because it's in the gen7 accel pathways.
<RAOF> Hm. Although that's clearly a bug in xmir's damage code *somewhere*
<RAOF> Huh. Yes, that might also be the cause of the unity blankness.
<robert_ancell> RAOF, so it's only in the new driver? Should I try the old one?
<RAOF> It looks like it might be an interaction of the new driver with the new xmir.
<RAOF> I'm just testing an xserver patch
<RAOF> Yup, that works for intel.
<robert_ancell> RAOF, the xserver patch? I downgraded the -intel driver and no change here
<RAOF> Yeah, xserver patch.
<robert_ancell> RAOF, so new xserver release needed?
<RAOF> Looks like it. Checking that it doesn't break !intel
<robert_ancell> RAOF, ok, I'll open a bug and file it to you. Should we file bugs against ubuntu/xorg-server or xmir?
<robert_ancell> (given we're now in main)
<RAOF> ubuntu/xorg-server
<RAOF> Feel free to tag with xmir.
<tvoss> good morning
<RAOF> Yo!
<tvoss> robert_ancell, RAOF I noticed yesterday that mir from the archive (usc rebuilt on top of it) fails to start with ^Flinker^@linker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found
<RAOF> This would be on the phone, right?
<robert_ancell> bbl
<tvoss> RAOF, nope, on the desktop :) a bit surprising, isn't it?
<tvoss> doko_, ping
<RAOF> Yes indeed.
<RAOF> Ah, yes. That does indeed break radeon.
<tvoss> RAOF, for me it happens on Intel
<RAOF> tvoss: Blank screen?
<tvoss> RAOF, no, fallback to X
<RAOF> Oh, the failure to start.
<RAOF> That's a super odd one; is your /etc/ld.conf correct?
<tvoss> RAOF, what am I looking for?
<RAOF> Should only contain a pointer to ld.so.conf.d/*; that should just contain obvious bits.
<tvoss> RAOF, /etc/ld.so.conf includes files from /etc/ld.so.conf.d
<RAOF> Particularly, should not contain /system/lib/* anywhere :)
<tvoss> RAOF, i386-linux-gnu_EGL.conf  i386-linux-gnu_GL.conf  i686-linux-gnu.conf  libc.conf  x86_64-linux-gnu.conf  x86_64-linux-gnu_EGL.conf  x86_64-linux-gnu_GL.conf
<tvoss> that's the ld.so.conf.d contents
<RAOF> All looks sane.
<RAOF> I need to help with ZoÃ« for five minutes; I'll think more.
<tvoss> RAOF, tried the mir_demo_server_shell, hangs my system
<duflu> tvoss: I don't think we support multiple simultaneous servers yet, so demo_server* won't work if you're running USC...
<tvoss> duflu, I'm _not_ running USC :)
<duflu> Ah
<tvoss_> RAOF, how do we release new xserver and drivers? Is that somehow guarded/gated or do we just push to the archive?
<RAOF> tvoss_: We just push to the archive.
<tvoss_> RAOF, I wonder if we should gate that, too. Especially as multiple people could push to the archive
<RAOF> Well, it's gated in -proposed.
<RAOF> Like everything else.
<tvoss_> RAOF, what tests are run in proposed?
<RAOF> On the Xserver? None at the moment.
<RAOF> But I think we run a full pass of every other component before promoting out of proposed.
<RAOF> Speak of the devil!
<RAOF> 'tis didrocks!
<tvoss_> didrocks, good morning :)
<didrocks> hey RAOF, tvoss_!
 * didrocks overslept, not sure if it's because of the UK delay
<didrocks> RAOF: thanks for -ati, -nouveau!
<didrocks> ok, the mirslave failed the same way apparently
<didrocks> now, we need to wait for all dailies to finish to be able to relaunch it
<didrocks> argh, ati machine down again
<RAOF> Aha! *That's* what was going wrong!
<didrocks> RAOF: what?
<didrocks> thomi: around?
<RAOF> Oh, just tracking down some damage stupidity in the xmir/xmir-ddxen.
<didrocks> RAOF: tvoss_: did you reproduce the issue I was mentionned with latest mir+xorg from distro and u-s-c from daily-build ppa?
<tvoss_> didrocks, yup, usc fails with  ^Flinker^@linker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found
<tvoss_> didrocks, on my laptop :)
<didrocks> interesting, should we blame RAOF and the mesa upload then? :)
<didrocks> or something else in the linking is looking for it somewhere else?
<didrocks> like a RPATH
<RAOF> That's a tremendously odd lib path.
<tvoss_> RAOF, which one?
<RAOF>  /system/lib/
<tvoss_> RAOF, indeed
<tvoss_> RAOF, seems like mir is compiled for armhf
<RAOF> Yeah, that's what it looks like.
<tvoss_> didrocks, ^
<didrocks> tvoss_: debian/rules still makes sense though
<tvoss_> didrocks, right. there is http://bazaar.launchpad.net/~mir-team/mir/trunk/revision/922 though, not sure, how that might interfere
<didrocks> it doesn't have the -D<â¦> specific to android
<didrocks> tvoss_: no, shouldn't
<tvoss_> didrocks, the one thing that is interesting: if I do an apt-get source on libmirserver0 and try to build locally, the build fails
<didrocks> $ ldd /usr/lib/x86_64-linux-gnu/libmirserver.so.0 | grep libGL
<didrocks> libGLESv2.so.2 => /usr/lib/x86_64-linux-gnu/libhybris-egl/libGLESv2.so.2 (0x00007f8e46144000)
<didrocks> here
<didrocks> after removing libhybris:
<didrocks> libGLESv2.so.2 => /usr/lib/x86_64-linux-gnu/mesa-egl/libGLESv2.so.2 (0x00007f080cd74000)
<didrocks> not sure you are seeing the same issue then
<RAOF> robert_ancell: There's a shiny new xserver in mir-team/staging.
<tvoss_> RAOF, how can we solve that ld issue?
<tvoss_> RAOF, can we dictate an order for resolving to the linker? seems to me it is alphabetical
<RAOF> Um. Why is libhybris installed at all?
<tvoss_> RAOF, it is installed by the platform api, checking why that is the case for non armhf targets
<RAOF> Right.\
<RAOF> So, the problem is that libhybris has claimed the EGL alternative.
<RAOF> Which is correct, actually; you *want* it to.
<RAOF> Except it makes no sense when not running on an android system.
<tvoss_> RAOF, right, and that's the case in the archive, too
<RAOF> So - is there any particular reason why libhybris should be built on any architecture other than armhf?
<RAOF> Because âapt-cache rdepends libhybrisâ shows there to be a large number of ways for me to accidentally break my system.
<tvoss_> RAOF, nope, looking at the same output
<tvoss_> RAOF, either we fix all of the rdepends, or we find a creative way to trick the alternatives mechanism in taking into account the platform it is running on
<RAOF> We fix all the rdepends, and not build libhybris on i386 and amd64
<tvoss_> RAOF, working on the platform api right now
<RAOF> Unless we're targetting some crazy i386 android hardware it is never correct to have libhybris installed on i386 or amd64.
<tvoss_> RAOF, right
 * RAOF heads to the shops to get dinnerables.
<doko> tvoss_, hi
<tvoss_> doko, hey there :) cancel that ping
<tvoss_> didrocks, can I filter rdepends by architecture?
<didrocks> tvoss_: not easily, it's better to apt-cache policy
<tvoss_> didrocks, ack ...
<dholbach> good morning
<RAOF> robert_ancell: Been able to test with that X server?
<robert_ancell> RAOF, I'll test nw
<RAOF> TA
<robert_ancell> RAOF, no, still spins at 100% CPU
<RAOF> Grr.
<RAOF> I'll check again locally.
<robert_ancell> RAOF, Does XMir show a background? Or is a black background what I'd expect to see on success?
<RAOF> If you pass -retro you'll get to party like it's 1989 to the eye-bending X root weave.
<RAOF> Otherwise, yeah. Black background with no cursor is your success criterion.
<robert_ancell> RAOF, ah, I still have the cursor so it must not work
<RAOF> Which cursor?
<robert_ancell> RAOF, the Mir cursor
<RAOF> Ah.
<robert_ancell> Tried with -retro, definitely no background
<RAOF> Grr. It all works just fine here. Could you run X from gdb and see where it's spinning?
<robert_ancell> RAOF, yep
<robert_ancell> RAOF, hmm, I seem to have stopped the X mouse working - any way to reset it?
<robert_ancell> i.e. my existing X session, so can't copy the output I want to show you :)
<robert_ancell> RAOF, Weirdly, when I run X from inside Unity it works, and not when I run it from a VT
<RAOF> That *is* weird.
<RAOF> robert_ancell: âsudo modprobe -r psmouse; sudo modprobe psmouseâ might work.
<RAOF> To get your mouse back :)
<robert_ancell> RAOF, nice!
<RAOF> When all else fails, remove the device and retrigger hotplug :)
<robert_ancell> (worked!)
<robert_ancell> RAOF, when running it inside Unity under gdb I got a segfault, but not sure if that
<robert_ancell> 's related
<robert_ancell> RAOF, http://paste.ubuntu.com/5954185/ is the backtrace
<robert_ancell> bug 1208715
<ubot5> bug 1208715 in xorg-server (Ubuntu) "XMir fails to start on intel" [Undecided,New] https://launchpad.net/bugs/1208715
<robert_ancell> RAOF, were you running X from a VT?
<RAOF> Yes
<robert_ancell> RAOF, so, when I run from a VT stopping X with ctrl+Z stops in a variety of places
<RAOF> I've never seen that crash before :)
<robert_ancell> RAOF, first one is main -> InitOutput -> xf86DeleteDriver
<RAOF> Urgh. Spinning in DeleteDriver again? But why doesn't that occur here?
<robert_ancell> RAOF, actually, always in InitOuput
<robert_ancell> Guessing that should have completed..
<RAOF> Correct, that should have completed.
<RAOF> Could you pastebin your xorg log?
<robert_ancell> RAOF, http://paste.ubuntu.com/5954194/
<RAOF> Urgh. It's going to be your crazy hybrid laptop again, isn't it.
<robert_ancell> RAOF, yep, haven't changed hardware here
<robert_ancell> At least I seem to hit these problems before other people ;)
<robert_ancell> didrocks, hey, the Mir daily landing automatically goes to main now right? I checked the job and it seemed to have gone through without a manual step
<robert_ancell> RAOF, anything else I can do from this end?
<RAOF> robert_ancell: Not unless you particularly feel like getting your elbows into xf86DeleteDriver
<robert_ancell> RAOF, not particularly, at least not at the end of a night :)
<didrocks> robert_ancell: there was a manual publication because of a packaging change today
<didrocks> robert_ancell: but yeah, otherwise, it goes straight to main
<robert_ancell> didrocks, ta
<didrocks> no u-s-c running successfully yet though :/
<didrocks> (see my emails)
<robert_ancell> didrocks, yeah, I checked the job there :(
<tvoss_> didrocks, in a *.install file, can I restrict installation of a file to an architecture?
<robert_ancell> tvoss_, sounds unlikely!
<didrocks> tvoss_: no, you need to play a silly dance like .install.in -> .install
<tvoss_> didrocks, do you have an example for that handy?
<RAOF> didrocks: Actually, you can have an install.$arch
<robert_ancell> ooh
<didrocks> RAOF: right, but you duplicate everything
<didrocks> tvoss_: depends on how long your list is ^
<RAOF> That is true
<robert_ancell> ok, gtg. Later all!
<tvoss_> RAOF, didrocks so I would have *.install for everything and a special *.install.armhf for armhf installs?
<tvoss_> robert_ancell, g'night
<didrocks> see you robert_ancell
<robert_ancell> RAOF, please update the bug if you find anything
<didrocks> tvoss_: no, .install will be used if it doesn't find a .install.armhf
<tvoss_> didrocks, okay, that's why the list length is important :)
<didrocks> so you need to cp .install .install.armhf
<didrocks> right ;)
<didrocks> think to symlink a .install.arm64 to .install.armhf as well
<didrocks> (as it's incoming)
<tvoss_> didrocks, alternatively: can I restrict a binary package in debian/control to an architecture?
<RAOF> Easily.
<didrocks> tvoss_: yeah, just change "any" in Architectures:
<didrocks> to "armhf amd64"
<didrocks> tvoss_: for hybris though, check with ricardo, IIRC, they wanted to build on i386/amd64 for some reason
<tvoss_> didrocks, arm64 it is, right?
<tvoss_> didrocks, sure, I'm taking care of that right now
 * RAOF hits ZoÃ« evening time
<didrocks> tvoss_: right, arm64
<tvoss_> RAOF, can you give me a quick handover when you are back?
<tvoss_> duflu, ping
<duflu> tvoss_, pong
<tvoss_> duflu, hey there. I was wondering if boost::circular_buffer might be of use to you
<duflu> tvoss_: Not sure. I would have to have a good reason to rewrite things and add more dependencies on boost tho
<duflu> Don't have any such reasons
<tvoss_> duflu, well, the best reason is that it is tested and in production for some years from my pov
<duflu> tvoss_: My current implementation without boost is much better tested than with boost. :)
<hikiko> hi
<alan_g> Good morning hikiko
<tvoss_> duflu, I don't want to discuss this to death, but my pov is that we shouldn't reimplement circular buffers on our own :)
<hikiko> when I build mir trunk I get this error: [ 29%] Building CXX object src/shared/input/CMakeFiles/mirsharedinput.dir/android/android_input_receiver.cpp.o
<hikiko> /usr/lib/i386-linux-gnu/libc_nonshared.a(stack_chk_fail_local.oS): In function `__stack_chk_fail_local':
<hikiko> (.text+0x10): undefined reference to `__stack_chk_fail' collect2: error: ld returned 1 exit status
<hikiko> any idea what I am missing? (sorry the paste was longer than I expected)
<alan_g> hikiko: You've probably got out-of-date binaries that make fails to rebuild
<duflu> tvoss_: The case used in my new code is quite different. It is a sequence of three queues in a single ring. Generic circular queues don't handle that
<tvoss_> duflu, that just depends on the template parameter then, right?
<alan_g> hikiko: first try: make clean&&!make
<duflu> tvoss_: No, regardless of parameter it's insuffucient. Boost assumes one head and tail. I need three
<hikiko> alan_g, it was in a fresh build, I am dist-upgrading to see if I still get it
<tvoss_> duflu, fair, just saying :)
<hikiko> alan_g, sorry I hadnt see the ! what does !make do?
<hikiko> it didn't fix it but it's the first time I see it :)
<alan_g> It runs your most recent command starting with "make"
<hikiko> interesting!
<alan_g> hikiko: second try: rm -rf * && cmake .. && make
<hikiko> alan_g, I tried but it didn't fix it... I am waiting dist-upgrade to finish because I might have outdated libraries used by mir :s
<hikiko> but it was compiling until yesterday
<alan_g> hikiko: in the same directory?
<hikiko> you mean to try cmake in the root dir?
<hikiko> alan_g, I did the same things I do everytime to compile mir
<alan_g> I mean was yesterday in the same directory as today?
<hikiko> no
<alan_g> Is today a fresh checkout>
<hikiko> yesterday it was on staging/mir today in staging/trunk
<hikiko> and the trunk is a fresh checkout
<alan_g> If you update to yesterday's revision does it still fail?
<hikiko> let me check
<hikiko> in 928 I get the same error trying 927 now
<tvoss_> didrocks, related question to *.install: can I have architecture specific symbol files?
<didrocks> tvoss_: yeah, same rule, *.symbol.armhf
<tvoss_> didrocks, thanks
<didrocks> yw ;)
<didrocks> it's a pain to update though, people needs to update both before merging
<tvoss_> didrocks, fair, but at least we force people to be conscious
<hikiko> alan_g, I don't get it in 925
<hikiko> but I get it in r 926-929
<alan_g> hikiko: so there's something about -c 926 that disagrees with your system?
<alan_g> Mine is happy, as are the CI platforms.
<alan_g> What does "uname -a" give?
<hikiko> Linux qubby 3.10.0-5-generic #15-Ubuntu SMP Wed Jul 24 19:44:23 UTC 2013 i686 i686 i686 GNU/Linux
<alan_g> you're 32bit?
<hikiko> yes
 * alan_g doesn't know why that would be a problem, but it is an obvious difference
<hikiko> :s
<hikiko> let's see what's the change in 926
<mlankhorst> any funny mir bugs for me to look at? :P
<hikiko> alan_g, do you think I have to fill a bug report?
<alan_g> hikiko: if you feel like it.
<hikiko> well if I don't find a way to fix it +send  a patch I will submit one :)
<alan_g> hikiko: OK. (I think I've got a 32bit VM set up - but it probably needs updating as I only use it for tax purposes)
<alan_g> alf__: can you have quick look over -c 926? hikiko finds it FTBS on her *32bit* system.
<alf__> alan_g: sure
<alan_g> Hmm, http[s] traffic is timing out. Is chat working?
<alf__> alan_g: I can read your message
 * alan_g decides to restart router before calling ISP
<alan_g> BRB
<hikiko> alan_g https://bugs.launchpad.net/mir/+bug/1208774
<ubot5> Ubuntu bug 1208774 in Mir "`__stack_chk_fail' error in 926 and later revisions (i386)" [Undecided,New]
<tvoss_> greyback, ping
<greyback> tvoss_: pong
<tvoss_> greyback, hey there :) quick question: which symbols from the platform api do you/unity-mir consume?
<alf__> hikiko: what does 'objdump -T /lib/i386-linux-gnu/libc.so.6 | grep __stack' say?
<hikiko> $ objdump -T /lib/i386-linux-gnu/libc.so.6 | grep __stack
<hikiko> 00106b70 g    DF .text	0000001a  GLIBC_2.4   __stack_chk_fail
<hikiko> outdated?
<hikiko> I ve seen the http://stackoverflow.com/questions/5090881/libgcc-s-so-undefined-reference-to-stack-chk-failglibc-2-4 as well
<greyback> tvoss_: from platform api, only ua_ui_mirserver_init & ua_ui_mirserver_finish
<tvoss_> greyback, ack
<greyback> that's all that unity-mir & unity8 needs. qtubuntu naturally uses more
<alf__> hikiko: can you pastebin flags.make and link.txt from build/src/shared/input/CMakeFiles/mirsharedinput.dir/
<alf__> hikiko: btw, are you building with make -jX ?
<hikiko> np
<hikiko> no
<alf__> hikiko: ok
<hikiko> just make or make all
<hikiko> http://pastebin.ubuntu.com/5954501/
<hikiko> http://pastebin.ubuntu.com/5954503/
<hikiko> alf__, ^
<alf__> hikiko: thanks
<hikiko> someone in stack overflow says that: add -fno-stack-protector when linking for a similar problem
<hikiko> but if that was the problem shouldn't we get the error in amd-64 as well?
 * alan_g is back via a mobile connection
<alf__> hikiko: the pastes look normal
<hikiko> :S
<alf__> hikiko: has dist-upgrade finished?
<hikiko> yes
<hikiko> before I build 925 and 926
<hikiko> let me reboot just in case
<smartboyhw> alf__, BTW I saw a cmake message
<smartboyhw> You have called ADD_LIBRARY for library 3rd_party without any source files. This typically indicates a problem with your CMakeLists.txt file
<hikiko> i rebooted and got  the error again
<alf__> smartboyhw: it's ok, just ignore this
<alan_g> hikiko: any progress?
<alf__> alan_g: hikiko: I have managed to reproduce this in a i686 chroot. I have found that explicitly linking against libc (-lc) fixes the build issue, but I haven't figured out why we need this.
<alan_g> alf__: thanks, I guess that's enough for hikiko to work around it?
<hikiko> alf__, thanks cool :D
<hikiko> could you pls submit the fix?
<alf__> hikiko: it's a workaround, feel free to use it until we figure why this happens, I don't think it should end up in trunk just yet
<alan_g> +1
<hikiko> ok so I just add a -lc in linker flags?
<alf__> hikiko: yes, in src/platform/graphics/CMakeLists.txt
<hikiko> thank you! :)
<alf__> hikiko: yw
<alan_g> alf__: My broadband is intermittent at best, so I'm working on laptop/mobile (so I don't want to download 32bit saucy just now). But if you want to assign me the bug I'll pursue it once service is resumed.
<alf__> alan_g: Sure, feel free to assign the bug to yourself when the networking issues are fixed. In the meantime I will continue investigation.
<duflu> alf__: How badly do we need to block on the lazy allocation optimization?  Reimplementing it has taken 10 hours of my time so far and still not quite done
<duflu> I mean, it's almost done, and I thought fully covered by tests, but I just discovered a strange bug where a client might get stuck at 40Hz. What is 40Hz?... :)
<duflu> Oh. 40Hz would be a problem with every third frame, of course
<tvoss_> duflu, which might hint to triple buffering ;)
<duflu> tvoss_: It is. I know
<mlankhorst> pushed a bugfix for the xf86DeleteDriver infinite loop
<alf__> duflu: I am OK with not blocking the current MP for it, as long as it's going to be done soon enough.
<duflu> alf__: That's good. I'm past thinking straight for today anyway
<alf__> duflu: although, if we don't have this, we can't really test how the new swapper/bundle behaves with double-buffering.
<duflu> alf__: What do you mean? The tests cover double buffering.
<alf__> duflu: I mean from a visual fluidity perspective, not so much from a correctness one
<duflu> alf__: Yes I know. I have some additional timing tests in mind to add
<alf__> duflu: e.g. will multi-monitor use cases continue to work as well with strict double-buffering?
<duflu> alf__: Should do...
<duflu> alf__: But again, I'm past thinking straight
<duflu> Later...
<alan_g> alf__: I spotted a mistake in -c 926 - can't see it causing the link problem, but mentioning it: lp:~alan-griffiths/mir/remove-spurious-link-options
<alf__> alan_g: ok, trying in the chroot
<alf__> alan_g|lunch: no difference
<chihchun> just wondering do we have a contributor agreement before submit?
<mlankhorst> how do I find matching versions of mir/usc/xorg-server ?
<mlankhorst> i seem to repeatedly get mismatched versions when trying
<hikiko> question:
<hikiko> I am writing the nested display and at some point I need to create a mir surface
<hikiko> In the examples we call: MirSurfaceParameters const request_params =
<hikiko>         {__PRETTY_FUNCTION__, 640, 480, pixel_format, mir_buffer_usage_hardware};
<hikiko> so, I wonder what size we need instead of 640, 480: the full virtual screen size, something else I have to get from the nested mir? 640, 480 for the moment?
<hikiko> from native mir*
<hikiko> alan_g, alf__ any ideas?
<alf__> hikiko: Ideally you would need one surface per output I think
<hikiko> which means?
<alf__> hikiko: that you should read the display configuration and create the surfaces accordingly
<hikiko> is it similar to what you do in the gbm display?
<alf__> hikiko: In its final form it should be something like that. Perhaps as a first step just support one surface covering the full virtual screen size as you mention.
<mpt> chihchun, the contributor agreement is linked from here. http://www.canonical.com/contributors
<kgunn> didrocks: just sanity check my thinking.....i should have everything i need in main except u-s-c
<kgunn> didrocks: so if i am up to date
<kgunn> i should just be able to rebuild local u-s-c- & install....
<kgunn> to test right ?
<alan_g> hikiko: you only need to create a surface when your client asks for one - doesn't that request supply everything?
<hikiko> alan_g, I am not talking about an egl surface but for the MirSurface I ve seen that we use in mir_demo_client_accelerated
<hikiko> I guess I have to create such a MirSurface at the nested_display initialization
<hikiko> isn't it?
<hikiko> and then initialize egl create the egl surface et c
<alan_g> hikiko: surely all you need to do is forward the requests coming from a client?
<alan_g> Doesn't the client do the rest?
<hikiko> yes sounds reasonable.. but I am a bit comfused I have to think it a bit more to clarify what is done in the client and what in the server
<alan_g> hikiko: Just fill in the unimplemented functions in NestedPlatform?
<hikiko> alan_g, that's what I started doing: I started from create_display and then added all the display functions to be able to call the constructor
<hikiko> but maybe it's better to just add an exception there
<hikiko> and move to the rest of the functions
<alan_g> An exception where?
<hikiko> in the NestedDisplay constructor
<hikiko> mm no
<hikiko> I have to finish with the display before filling the rest of the NestedPlatform functions
<alan_g> hikiko: Doesn't the NestedDisplay constructor just need to initialize a pointer to the NativeDisplay?
<alan_g> Why should it throw?
<hikiko> and do nothing more?
<hikiko> :s
<alan_g> What else does it need to do?
<hikiko> the nested display will just forward every request to the native display?
<alan_g> I don't know - I don't remember your spike well enough
<alan_g> But mostly, yes
<kgunn> didrocks: ping
<hikiko> alan_g, what does spike mean?
<alan_g> The version you wrote by changing the code at compile time
<hikiko> oh, there I used to initialize egl in the display constructor
<hikiko> because that's what every display was doing (and the clients were doing the same) and then yes I was using the native code for the rest
<hikiko> I was creating a full screen mirsurface
<alan_g> hikiko: I don't see a need to do anything (e.g. create a surface) that the client doesn't ask for.
 * alan_g doesn't know everything
<hikiko> :)
<hikiko> it sounds reasonable
<hikiko> I will try what you said
<hikiko> and if it doesn't work I'll check why initialize egl is necessary
<didrocks> kgunn: take drivers and Mir from distro
<didrocks> kgunn: and u-s-c from the daily-build ppa
<alf__> alan_g: hikiko: @creating a surface, I think hikiko is referring to the surface(s) acting as screen framebuffers, which the nested compositor needs to get from the system compositor
<kgunn> didrocks: but i still think u-s-c would need to be rebuilt
<didrocks> kgunn: rebuild from when?
<didrocks> kgunn: u-s-c is rebuilt everyday
<kgunn> didrocks: oh sorry....you said daily-build ppa
<didrocks> it was today at 5am utc
<kgunn> my bad
<didrocks> yep
<kgunn> didrocks:  still..i could rebuild....which is what i just tried....after all my updates....interesting it says
<kgunn> Package xserver-xorg-xmir is not installed
<kgunn> didrocks: ^
<didrocks> kgunn: TBH, let's try to tackle one thing at a time
<didrocks> so, as told in yesterday's email, let's use what we provide in the distro to users
<didrocks> which is right now, mir + xorg from distro
<didrocks> (which has xserver-xorg-xmir)
<didrocks> and the u-s-c from daily-build ppa
<kgunn> didrocks: please...its just a test
<didrocks> what do you want me to do?
<kgunn> didrocks: i am trying to understand if i purged/unpinned....updated/dist-upgraded....so i'm totally out of distro
<kgunn> didrocks: then i built u-s-c.....and it complains no xorg-xmir why ?
<didrocks> because you didn't install u-s-c build-deps?
<kgunn> didrocks: no, but i did
<didrocks> apt-cache policy libmirserver-dev
<kgunn> only deps were libboost-all-dev & libmirserver-dev
<kgunn> lemm check
<didrocks> kgunn: I'm interested in the version
<didrocks> xserver-xorg-xmir is a runtime dep, pulled by unity-system-compositor pacakge
<didrocks> it's not a build-dep
<kgunn>   Installed: 0.0.8+13.10.20130806-0ubuntu1
<kgunn>   Candidate: 0.0.8+13.10.20130806-0ubuntu1
<kgunn> didrocks: ^
<didrocks> ok, sounds good
<didrocks> so, what's your issue? if you install the unity-system-compositor package
<didrocks> (even the one built locally)
<didrocks> it should ask xserver-xorg-xmir as a runtime dep
<kgunn> didrocks: maybe my lack of experience...its complaining on dpkg -i u-s-c.deb about xorg-xmir ....but maybe it installed just fine ?
<didrocks> kgunn: it's normal, dpkg doesn't know about deps and how to install them
<didrocks> so either you install the dep manually
<didrocks> with apt-get install
<didrocks> or you add the daily-build ppa
<didrocks> and install u-s-c
<hikiko> alf__, I think so, those are the only surfaces I create (during the initialization) and then I leave the control to the native platform
<hikiko> do you think I should leave it as it is (I mean do the fixes but as a general design)
<hikiko> brb
<alan_g> alf__, hikiko : I see, that does make sense. Somehow (at least to me) "surface" meant something that the end client requested, not an FB. But I was wrong.
<kdub> racarr ping
<racarr> kdub: pong
<kdub> racarr, i'm finding i need to restructure the focus mechanism  a bit for having the display configuraiton follow the focus
<kdub> basically, i'm going to move all the focus logic out of SessionManager, and into DefaultFocusMechanism
<kdub> I /could/ use SessionListener... but that looks like something the shell ows/is using currently?
<kdub> *owns
<racarr> yeah
<kdub> like, i have this feeling that if i override SessionListener, i'll break shell things (or my features)
<kdub> so i'll try not to use that
<kdub> right
<racarr> yes. I think moving things out of
<racarr> session manager is the right idea though
<kdub> right, just wanted to run the plan by you make sure it makes sense :)
<bschaefer> kgunn, intel working for me, what version of xorg intel do you have?
<kgunn> bschaefer: lemme check
<bschaefer>   Installed: 2:2.21.9+xmir15871-2~saucy1
<kgunn> Installed: 2:2.21.12-1ubuntu1
<kgunn> bschaefer: are you on staging ppa ?
<bschaefer> hmm strange, thats the highest version you can get?
 * bschaefer double checks
<bschaefer> kdub, hmm no its all commented out
<kdub> kdub <-> kgunn confusion? :)
<kgunn> yeah :)
<bschaefer> opps
<bschaefer> yup!
<bschaefer> kgunn, have you pinned your ppa?
<racarr> kdub: Didn't you hear you are manager now
 * bschaefer shows that version you have is above mine
<kgunn> bschaefer: no, i'm unpinned
<racarr> you have a meeting from 10:30 to september 3rd.
<racarr> :p
<kdub> haha :P
<bschaefer> kgunn, should we have it pinned or not at this pont?
<bschaefer> point*
<bschaefer> racarr, thats a long meeting
<kgunn> bschaefer: my understanding is that our goal should be to "make it work" for the following....main mir+xorg-xmir along with u-s-c from dialy-next ppa
<kgunn> didrocks: ^ right ?
<didrocks> kgunn: right!
<bschaefer> kgunn, welll let me unpin, as this could be why things were working for me yesterday as the ppa was pinned in both the ati/nvidia machine...
<kgunn> in theory once we get this to boot & run on all hw (intel/nvidia/amd) then we turn on u-s-c (xmir basically)
<bschaefer> right, it everything should just work :)
<racarr> still stuck on surface-configurator. bler
<kgunn> bschaefer: right :)....so in order of desired "make it work"....its main mir+main xorg-xmir+usc from daily-next ppa....then any other use of staging is sort of secondary (e.g. it would only help in terms of bisecting to what the heck went wrong)
<bschaefer> sounds good!
 * bschaefer restarts lightdm
<bschaefer> kgunn, u-s-c was removed due to a dependency issue, needs libmirserver from the ppa, not main
<bschaefer> err
<bschaefer>  unity-system-compositor : Depends: libmirserver0 (= 0.0.8+13.10.20130730bzr898saucy0) but 0.0.8+13.10.20130806-0ubuntu1 is to be installed
<olli_> kgunn, do you have a link to the kernel patch we need for radeon support?
<olli_> kdub, you might know as well, hence ^
 * bschaefer downgrades libmirserver
<kgunn> bschaefer: so this was when you purged ?
<bschaefer> kgunn, hmm I just unpinned, I thought I was still using u-s-c but nope sorry
<kgunn> bschaefer: alternatively i think you can just rebuild u-s-c from trunk....
<kgunn> no matter what....from ppa or rebuild...you always have to install usc
<bschaefer> yup, ill purge the ppa and just use main
<kgunn> olli_: sorry...more context ?
<bschaefer> and install it u-s-c my self
<kgunn> bschaefer: i am slightly suspicious of u-s-c from daily-build-next...because mir is older in that ppa than it is in main
<kgunn> didrocks: ^ does my suspicion make any sense ?
<bschaefer> kgunn, well u-s-c isn't in main
<didrocks> kgunn: you shouldn't look at daily-build-next
<didrocks> you should look at daily-build
<bschaefer> but yeah, libmirserver in main is very new
<didrocks> you will see a build from Mir today
<didrocks> pushed to distro
<didrocks> and then, a build of u-s-c
<kgunn> didrocks: arrgggg.....i'm in ppa hell then...
<didrocks> build just after Mir
<didrocks> https://launchpad.net/~ubuntu-unity/+archive/daily-build
<bschaefer> cool, well ill just build u-s-c with main with no ppas
<didrocks> (remember my diagram daily-build-next -> next ; daily-build -> distro)
<bschaefer> didrocks, I wasn't sent a diagram!
<kgunn> olli_: ^ this is why we should avoid ppa propogation :)
<didrocks> kgunn: this isn't propagation
<didrocks> this is the base of daily release, there are 2 sets of ppa
<didrocks> remember what I drew at the IoM,
<didrocks> bschaefer: you weren't there :)
<bschaefer> haha :)
<kgunn> didrocks: sorry if i am particularly thick skulled....but why is xorg/xdrivers not also in the "daily-build" ppa ?
<didrocks> kgunn: because it's in distro and we don't daily-release them?
<seb128> kgunn, did I just read you want to become upstream and put those under tests and you daily release? ;-)
<seb128> kgunn, just sign there ->
<seb128> ;-)
<bschaefer> kgunn, fun no screen error
 * bschaefer attempts daily next ppa
<arsson> Does my saucy explode if i install usc from here https://launchpad.net/~ubuntu-unity/+archive/daily-build ? I don't have any other ppa.
<olli_> seb128, regarding kgunn's signature... we might have to do something like that though
<olli_> seb128, with my wicked view of the world, we just updated various bits and pieces of the stack and broke things
<olli_> and need to come up with something to avoid that
<olli_> I acknowledge that reality is more difficult & complex ;)
<bschaefer> kgunn, hey, sooo i get the no screen available error if I have uxa enabled, and with sna enabled intel crashes :(
<bschaefer> also with the daily build next ppa, I still get a dependency error when trying to install u-s-c
 * bschaefer downgrades libmirserver0
<kgunn> bschaefer: careful....daily-build not daily-build-next (https://launchpad.net/~ubuntu-unity/+archive/daily-build)
<bschaefer> kgunn, well that explains that :)
 * kgunn made the same mistake before lunch
<bschaefer> well hopefully this will lead to the correct packages
<seb128> olli_, well, as long as you do the work/have the resources to do it
<seb128> olli_, but e.g today issues were not due to that
<seb128> olli_, there are due to a non alignement of the priority/things you focus on and of what is happening outside for that group (e.g some people are so focussed on touch and the phone that they forget that we still support things out of that)
<racarr> Does anyone anticipate needing me for anything in the afternoon? If not I am going to swap 12-5 for 8-1 or so
<racarr> I don't think I am going to make any progress on surface-configuration-interface or client-focus-notifications until I can talk to australites  + europe
<kgunn> racarr: go for it....see you tonight (hopefully)
 * kgunn lost a lot of sleep on the IOM
<kdub> racarr, is focus per session or per surface?
<racarr> kdub: There is application focus and surface focus
<racarr> kdub: Believe it or not it's actually in design documents somewhere
<kdub> are they tied together always?
<racarr> yeah
<racarr> hmmm
<racarr> no ;) not necessarily
<racarr> they can be for now
<racarr> but for example, I guess if you are using some app
<racarr> and you pop up some sort of input utility indow
<racarr> then the input utility window should be a type of session that 'can't take application focus'
<racarr> and the app should keep it
<racarr> and things like the menu bar, etc
<racarr> should still reflect the focused app
<kdub> yeah, i think though right now, the two are tied together
<racarr> yeah the focused session is just the session of the focused surface
<racarr> the shell just needs to be able to see it somehow
<tvoss_> racarr, input methods are partly handled by the shell, the app can requeest one from mir
<tvoss_> that's it
<racarr> tvoss_: Ok
<racarr> at some points we have discussed, various sorts of utility windows from magnifying glasses to screen rulers to color palletes, etc
<racarr> so I am just imagining one of them might show up one day
<bschaefer> kgunn, so im getting a black screen, with the error that there are no screens detected
 * bschaefer checks lightdm logs
<bschaefer> [    25.733] (EE) intel(0): [drm] failed to set drm interface version.
<bschaefer> [    25.733] (EE) intel(0): Failed to become DRM master.
<bschaefer> kgunn, those are errors i've not seen before, also are you using SNA or UXA?
<racarr> ok, off for a while. back in ~8 hours
<kgunn> bschaefer: sna
<kgunn> bschaefer: i can try uxa in a bit
<bschaefer> kgunn, hmm sna causes my intel driver to die :(
 * bschaefer goes back to eating lunch
<kgunn> bschaefer: ok...gonna try uxa real quick
<kdub> racarr, i feel like all the focus problems are melting away
<racarr> kdub: :D well that's good
<tvoss_> bschaefer, what are you testing right now?
<bschaefer> tvoss_, im testing daily build ppa + u-s-c on intel
<bschaefer> tvoss_, get black screen, with:
<bschaefer> [    25.733] (EE) intel(0): [drm] failed to set drm interface version.
<bschaefer>  [    25.733] (EE) intel(0): Failed to become DRM master
<bschaefer> when using UXA, and with SNA i get an intel driver crash
<bschaefer> tvoss_, also with UXA, i get the screens found, but not one we can use kind of error
<kgunn> bschaefer: ...my uxa segfaulting as well
<bschaefer> kgunn, hmm segfaulting? My SNA is seg faulting, could you paste bin your x log?
<kgunn> https://pastebin.canonical.com/95525/
<kgunn> bschaefer: ^
<bschaefer> kgunn, awesome, thanks
<bschaefer> kgunn, weeird, thats the seg fault I get running SNA
<bschaefer> kgunn, and with SNA you get xmir working fine?
<kgunn> bschaefer: nope...i am segfaulting consistently with sna and uxa
<bschaefer> kgunn, hmm strange, well possibly this crash is the real problem
<bschaefer> as this is new to me in an intel crash:
<bschaefer> [    25.323] (EE) 5: /usr/lib/xorg/modules/extensions/libxmir.so (xmir_screen_for_each_damaged_window+0x3c) [0x7f495b3f7e9c]
<bschaefer> soo possibly  a new push to damage has caused a crash?
<bschaefer> tvoss_, also if you get a chance to look at the pastebin, this is the crash I was getting as well
<bschaefer> https://pastebin.canonical.com/95525/
<bschaefer> but its already 10:30 there! Geez, you can look at it tomorrow as well :)
 * bschaefer looks at libmir for new changes to damage windows
<kgunn> bschaefer: yeah...i had to double check a few times...i am certain i am  running the right config...and its damn reliable now....always the same segfault
<kgunn> bschaefer: good to know you see the same (at least on sna)
<bschaefer> kgunn, awesome, and I get that crash on SNA, I think my UXA might be config wrong? Or something strange is happening
<bschaefer> yup!
<bschaefer> soo ill look into the backtrace and see what that function is doing
<kgunn> bschaefer: disturbing is the "waitforsomething"
<bschaefer> kgunn, well its an abstract name :)
<bschaefer> but thats in X
<kgunn> :) i know....just the name makes me anxious
<bschaefer> haha yeah
<kgunn> wait for what ? "something"
<kgunn> very helpful
<bschaefer> it would be nice if it were WaitForEvent at lease, or something
<bschaefer> but it could block on any number of things...
 * bschaefer wonders if thats part of our xmir patches
<bschaefer> kgunn, robotfuel are we seeing this crash on an ati/nvidia machines?
<bschaefer> not the intel bit, but the damage screen in libxmir?
<bschaefer> if so, we'll at lease know its not the driver :)
<robotfuel> bschaefer: yes the gt640 on nvidia
<bschaefer> robotfuel, very strange!
<bschaefer> robotfuel, thanks
<bschaefer> hmm must be something in the xserver then (possibly?)
<kgunn> tvoss_: ^
<kgunn> oh sorry you were rebooting
<kgunn> tvoss_: https://pastebin.canonical.com/95525/
 * bschaefer wonders what xmir/xserver is doing that is causing different drives to seg fault
<tvoss> kgunn, I have got the crash too, even with the latest intel from mir-team staging
<kgunn> tvoss: same crash? (related to window damage)
<tvoss> kgunn, yeah
<bschaefer> strange, tvoss its also on a nvidia machine
<bschaefer> soo it looks like the problem is coming from xserver or libxmir
 * bschaefer thinks at lease
<tvoss> mlankhorst, there is an xserver in mir-team staging. Is that supposed to fix the crash with xmir?
<mlankhorst> meh I was working on some fixes, I'll push what I have so far :P
<tvoss> mlankhorst, ack and thx
<mlankhorst> there pushed a fix for hybrid shutdown in xmir4.
<mlankhorst> not 100% sure if the change for the -dbg is correct, too tired to check.
<mlankhorst> night
<kgunn> robert_ancell: hey morning!
<robert_ancell> kgunn, hello
<robert_ancell> no movement on the intel problem :(
<kgunn> well....after most of used the wrong ppa for u-s-c :)
<kgunn> and finally got it sorted
<kgunn> e.g. to use daily-build not daily-build-next
<kgunn> we do have very consistent segfault for everyone
<kgunn> https://pastebin.canonical.com/95525/
<robert_ancell> This is the segfault you mentioned in my bug?
<kgunn> ....repro'd by me, tvoss, bschaefer  using main mir, main xorg-xmir, main xorg-drivers + usc from diaaily-build ppa
<bschaefer> robert_ancell, also reports seeing it on a nvidia machine
<bschaefer> robert_ancell, robotfuel
 * bschaefer needs to dig those logs up though
<robert_ancell> kgunn, why using the PPA and not just main?
<bschaefer> u-s-c isn't in main yet
 * kgunn now gets to play like didrocks
<robert_ancell> oh, I see - just the u-s-c from main
<bschaefer> building u-s-c from trunk I was getting a no usable screen IIRC
<kgunn> dang it.. bschaefer beat me to it
<bschaefer> though I need to test that again :)
<robert_ancell> I think that's a different issue to the one I'm getting, but more severe
<bschaefer> well Im getting 2 different errors, when I enable UXA, I get [    25.733] (EE) intel(0): [drm] failed to set drm interface version.
<bschaefer> [    25.733] (EE) intel(0): Failed to become DRM master
<bschaefer> and the fact that no usable screen is found
 * bschaefer just pushes log to pastebin
<bschaefer> when im using SNA i get that damage seg fault
<robert_ancell> To clarify - this is xorg-server 1.14.2-0ubuntu8
<robert_ancell> ?
<bschaefer> hmm my policy is saying just xorg-xserver:   Installed: 1:7.7+1ubuntu5
<bschaefer> robert_ancell, but the mir one is: xorg-server-1.14.2$
<bschaefer> soo yeah
<robert_ancell> but is it -0ubuntu8 (the one from main) or -0ubuntu9 (the one from staging). RAOF made a change in the staging version for X damage which is mentioned in your stacktrace
<bschaefer> xserver-xorg-xmir:
<bschaefer>   Installed: 2:1.14.2-0ubuntu8
<robert_ancell> k
<bschaefer> hmm well I just pulled the source of it as well, and its in the deb patch
<robert_ancell> bschaefer, can you try -0ubuntu8 from staging?
<bschaefer> robert_ancell, sure
<robert_ancell> ubuntu9 rather
<robotfuel> this is what I get on ati on the s-c-t ppa, I am writing a bug now https://pastebin.canonical.com/95527/
<bschaefer> robotfuel, hmm that should have been fixed by disabling the input to u-s-c
<bschaefer> robotfuel, would you be able to look at /etc/lightdm/lightdm.conf.d/10*conf?
<bschaefer> err, well I suppose if it can't open the driver it can't open a GBM device
<kgunn> robert_ancell: how come staging is different than main ?...e.g.xorg version ubuntu8 vs ubuntu9
 * bschaefer would think things get pushed to staging first
<kgunn> shouldn't we only have main
<robert_ancell> kgunn, RAOF wanted to test the X damage patch first
<kgunn> ah
<robert_ancell> kgunn, since X is not managed by daily landing it's really the only way to test "trunk"
 * kgunn just wants less ppa's & variables
<robert_ancell> me too :)
<bschaefer> kgunn, i do as well
<robotfuel> bschaefer: that machine is running utah stress tests again, because of a new version of utah I'll download the package to check
<bschaefer> robotfuel, alright, well i don't think its the same problem...as it really should be able to load the radeon drivers :)
<bschaefer> (that seems like the real problem)
<bschaefer> robert_ancell, this is what I have in staging:      2:1.14.2-0ubuntu8+xmir3 0
 * bschaefer goes to install it
<bschaefer> it removes u-s-c though, but I suppose I can just compile that my self
<robert_ancell> bschaefer, oh, mlankhorst has overwritten -0ubuntu9
<robert_ancell> I'm not sure what his package contains
<robert_ancell> bschaefer, yes
<kgunn> robert_ancell: was curious about what brandon's testing....so what would be the right combo ?....mir main, xorg staging, local built usc ?
<bschaefer> robert_ancell, yeah, I think he just pushed xmir4?
<robert_ancell> says 16 mins ago
<bschaefer> well ill test xmir3 out first with SNA
<robert_ancell> kgunn, should be mir main, xorg main, local built usc
<robert_ancell> And usc main soon
<robert_ancell> Unless there's a specific version of X to test
<robert_ancell> mlankhorst, around?
<bschaefer> my libmirs had to be updated to install this ... sooo im no longer running main libmir
<bschaefer> robert_ancell, he just went to sleep
<bschaefer> ~5-10 min before you got on :(
<robert_ancell> bschaefer, you shouldn't need to change libmir - X just requires libmirclient and that's API/ABI stable
<robert_ancell> he must have known :)
<robert_ancell> I wonder why he didn't upload those changes to main
<bschaefer> right, i am still using main
 * bschaefer restarts lightdm
<bschaefer> robert_ancell, kgunn running xmir :)
<bschaefer> hmm
<robert_ancell> bschaefer, so mlankhorst's change seems to fix the bug?
<bschaefer> robert_ancell, well I don't think thats built yey?
<bschaefer> yet*
 * bschaefer double checks nothing else go upgraded to staging
<bschaefer> robert_ancell, hmm it looks like my libmirclient1 was updated to staging as well when upgrade xserver
 * bschaefer attempts a downgrade
<bschaefer> downgrading removes these:
<bschaefer>   libegl1-mesa-dev libegl1-mesa-drivers libgles2-mesa-dev libmirclient-dev unity-system-compositor xorg-dev xserver-xorg-dev xserver-xorg-xmir
<bschaefer> or will remove them hmm
 * bschaefer update/upgrades to the xmir4 xserver
<bschaefer> xmir4 is working as well...hmm
<bschaefer> robert_ancell, are we able to push these packages into main?
<robert_ancell> bschaefer, I'll ask RAOF when he comes online
<bschaefer> robert_ancell, cool, sounds good
<bschaefer> robert_ancell, also mlankhorst said this before leaving:
<bschaefer> <mlankhorst> there pushed a fix for hybrid shutdown in xmir4.
 * bschaefer also assumes there is a change log with that mentioned in there
<kgunn> robert_ancell: maybe one thing that would help....when RAOF (or you...whomever is last) end their day....could you send a mail out to the primary stakeholders on what your understanding of what's where....
<kgunn> just thinking....i never woulve thot xorg from staging was the key
<kgunn> and didrocks certainly didn;t know either
<robert_ancell> kgunn, ok
<kgunn> does it make sense? or am i insane ?
<robert_ancell> kgunn, do you have anyone in particular in mind?
<tvoss_> robert_ancell, perhaps just a handover mail to mircosmonauts would help
<kgunn> mlankhorst, bschaefer, me, tvoss_  etc
<robert_ancell> kgunn, An email to clarify where things come from is good
<kgunn> yeag
<robert_ancell> I don't think we need to wait for EOD for that, or are you referring to broken Xorg cases?
<kgunn> yeah...it will cut down on didrocks desire to murder someone
<robert_ancell> that would be... nice :)
<bschaefer> haha
<robert_ancell> kgunn, hey, just reading about xorg and armhf - we shouldn't be bringing in xserver-xorg-xmir in these cases as I understood it
<kgunn> robert_ancell: well...then i got an earful about how we support arm non-android forever...
<kgunn> but i think tvoss_ might have solved it with some help
<tvoss_> robert_ancell, rsalveti will split up hybris, and only the -egl portion of it will install the alternative
<robert_ancell> tvoss_, sounds good - but is there a widespread problem? libhybris only gets pulled in if you install libmirclient and that's only if you install xserver-xorg-xmir afaict
<robert_ancell> aha, it seems libhybris is a dependency on compiz-plugins
<robert_ancell> but only on armhf
<tvoss_> robert_ancell, right, but libmirclient depends on libhybris on armhf, as we take the architecture as trigger for: building for utouch (armhf + android bits)
<robert_ancell> seb128 said "installing xorg on armhf brings in libybris" which I think is untrue
<kgunn> robert_ancell: uh....so xorg ubuntu9 is only for raring in staging ?
<rsalveti> only if something depends on libmirclient
<robert_ancell> kgunn, mlankhorst overwrote the saucy version. I don't know why
<rsalveti> what I'm changing is creating a different libhardware package to be used instead
<robert_ancell> rsalveti, right, which is not xorg
<seb128> robert_ancell, installing xorg libs bring in libmirclient1 that brings in libhybris
<robert_ancell> seb128, only xserver-xorg-xmir depends on libmirclient
<seb128> robert_ancell, lie
<seb128> robert_ancell, http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.saucy/rdepends/mir/libmirclient1
<robert_ancell> seb128, ah, libegl1-mesa-dev depends on it..
<seb128> robert_ancell, yes ;-)
<robert_ancell> so mesa depends on libmirclient
<seb128> robert_ancell, which is a build-depends of qt stuff
<robert_ancell> and pretty much everything graphical
<seb128> indeed
<tvoss_> robert_ancell, ideally, we would adjust mesa to support multiple vendor-specific egl implementations installed at the same time (we need that anyway)
<robert_ancell> tvoss_, yeah
<tvoss_> but the hybris-fix is useful, too, and easier to do right now
<tvoss_> robert_ancell, egl_hybris would be just another vendor then :)
<tvoss_> robert_ancell, kgunn the xserver from staging really fixes the startup
<kgunn> cool...so we can actually update our system-compositor-testing ppa as well
<bschaefer> tvoss_, yup!
<kgunn> tvoss_: to be clear...was that with xorg ubuntu9 for saucy that just got overwritten :)
<bschaefer> tvoss_, the version before xmir4 was also working, xmir3
<tvoss_> bschaefer, kgunn it's the one from staging for saucy
<bschaefer> tvoss_, mir staging right?
<tvoss_> bschaefer, exactly
<bschaefer> tvoss_, yup, i was just mentioning that xmir3 was working before xmir4 was pushed ~1 hour ago
<tvoss_> bschaefer, ah
<tvoss_> so what is the difference to the archive then?
<tvoss_> robert_ancell, ^, can you check with RAOF?
<bschaefer> this is the real question :)
<bschaefer> to what was the problem...
<tvoss_> interestingly, the slowness is fixed for me with the new xserver :)
<robert_ancell> tvoss_, yes, we'
<robert_ancell> re waiting for RAOF and then he can upload changes if they're good
<tvoss_> or better: with the new versions
<tvoss_> robert_ancell, \o/
<robert_ancell> I imagine he'll be here in 45 mins
<tvoss_> robert_ancell, if we don't meet in the morning, please drop me an email :)
 * tvoss_ is hopefully asleep then :)
<robert_ancell> tvoss_, what do you want in the email?
<robert_ancell> i.e. why not just check the archive when you wake up?
<robert_ancell> or subscribe to the bug report?
<tvoss_> robert_ancell, if it's good, even better :) if not: open issues and what you want the europeans to do
<tvoss_> :)
<robert_ancell> see you guys in 8 hours :)
<robert_ancell> we have team meeting today
<tvoss_> robert_ancell, right, see you in a bit
<olli_> RAOF, ping
<olli_> or is it still too early?
 * olli_ needs a world clock applet
<tvoss_> robert_ancell, is vt switching supposed to work?
<robert_ancell> olli_, the clock indicator
<robert_ancell> tvoss_, yes
<robert_ancell> olli_, I think another 20 mins
<tvoss_> robert_ancell, not working here
<robert_ancell> tvoss_, locks up?
<tvoss_> robert_ancell, yeah, screen just stays as it is, cursor not moving anymore. Switching back to vt6 unfreezes
<tvoss_> robert_ancell, do I need input support in usc for vt switching?
<robert_ancell> tvoss_, oh, that is probably fixed by https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/177800
<tvoss_> robert_ancell, do you find time today to babysit those branches to trunk? I can do reviews tomorrow, too
<robert_ancell> tvoss_, that's what I'm doing :) The main one is getting the alt+ctrl+backspace fix in. Past all the arguing about how to make it perfect :)
<tvoss_> robert_ancell, great, I will catch up with the reviews and comments tomorrow my morning. I'm braindead right now
<robert_ancell> tvoss_, sleep!
<tvoss_> robert_ancell, ack ;)
<kdub> racarr, ping again :)
<racarr> kdub: pong
<kdub> racarr, so i'm sort of finding myself tempted to put the FocusSetter in the SessionMediator
<kdub> i think i'll resist htat though, keep SessionManager more of our generic 'handle all sessions' class
<kdub> is the shell team overriding the SessionManager?
<racarr> kdub: No. they aren't
<kdub> ah, good :)
<racarr> I don't think FocusSetter belongs in SessionMediator but I can understand the temptation
<racarr> but I think, some component in msh::/the shell, should see that a new surface has been created and contain the policy to focus a new surface on creation
<racarr> rather than that be part of the 'create surface' request from the frontend
<racarr> unity will have to customize the policy as things go on, i.e. for focus stealing prevention on desktop
<kdub> racarr, right... thats how I'm leaning too
<kdub> keep that out of the frontend so the behavior is more customizable
<thomi> racarr: any progress with the mir stress test failing bug?
<racarr> thomi: No. Kind of freaking out about feature work mostly :)
<thomi> racarr: OK, you should be aware that this will block XMir from being switched on by default in 13.10
<thomi> (if you weren't already)
<racarr> so will client-focus-notifications :(
<thomi> also, I'm about to start working on getting the stress tests to gate merges to trunk. I doubt it'll happeen in the next week or so, but when that lands no one will be able to merge anything to trunk unless that test passes, so...
<thomi> robert_ancell: perhaps we can shuffle some people around so this gets fixes?
<thomi> err, i mean "fixed"
<racarr> thomi: I understand
<robert_ancell> thomi, ah, I'll see if we have any shuffling space
<racarr> i am hoping to resolve the rest of my feature work or at least get a solid plan
<racarr> aroun the team meeting tonight
<racarr> so maybe I will be able to go back to
<racarr> the mir-stress bug soon if everything goes well
<racarr> though.
<racarr> I dunno
<racarr> we need to talk about some things in the meeting
<racarr> because the first part of the stress-test bug fix was rejected on the grounds that we should complete this 'scenegraph' etc
<racarr> but it feels to me like the odds of this happening before feature freeze are effectively
<racarr> zero
<thomi> right
<thomi> at this point in time, I'd recommend the pragmatic approach
<RAOF> olli_: 8:30 is sometimes too early, sometimes not :)
<olli_> RAOF, gm :)
<RAOF> And on a shiny new laptop, too!
<olli_> hey, hlh was curious whether the times you had provided us 2 weeks ago are still valid
<RAOF> olli_: Yup.
<olli_> the call didn't get scheduled so far and we just want to make sure it doesn't conflict with vacation or so
<olli_> RAOF, thx!
<kdub> RAOF, the multimonitor api for mir has landed...
<RAOF> olli_: Oh, I could additionally do the same times on Monday and Tuesday, if either of those is easier.
<kdub> still hooking up bits serverside, but if you want to get a head start on xmir multimonitor backend, shouldn't change much from this point out
<RAOF> kdub: Woot!
#ubuntu-mir 2013-08-07
<rsalveti> tvoss_: https://code.launchpad.net/~rsalveti/mir/fixing-libhybris-dependencies/+merge/178863
<robert_ancell> RAOF, do you know about mlankhorst's changed in -staging?
<RAOF> robert_ancell: I do not.
 * RAOF checks
<robert_ancell> RAOF, so he overwrote -0ubuntu9 for some reason. But others have said his changes fix a crash
<RAOF> I did tell him about your bug, and he seemed to have an idea of what was happening.
<robert_ancell> So not sure why they don't just go directly to main?
<kdub> rsalveti, speaking of our libhybris dependency :)
<robert_ancell> RAOF, I was looking at the Mir patch by the way. I notice it unloads drivers if they don't work with Mir, but doesn't check if the driver count is 0 afterwards. My logs do show three drivers being unloaded
<kdub> we keep hwcomposer.h in-tree... if libhybris maintained hwcomposer.h (like it does with gralloc.h), it would help mir's dependency situation
<kdub> just a 'wishlist' though
<rsalveti> kdub: sure, mind opening a bug against the libhybris package?
<kdub> sure
<rsalveti> also, if someone can help me understand such failures: https://code.launchpad.net/~rsalveti/mir/fixing-libhybris-dependencies/+merge/178863
<rsalveti> any idea why we don't have an armhf jenkins build job as well?
<rsalveti> just building for i386 and amd64
<rsalveti> or is it trying to cross build for armhf?
<kdub> rsalveti, yep
<rsalveti> right, then we might need some other changes as well...
<rsalveti> -- Could NOT find LIBHARDWARE (missing:  LIBHARDWARE_LIBRARY)
<rsalveti> when cross building
<rsalveti> package wasn't even installed
<kdub> there's a script in the top level directory (+ ./cross-compile-chroot.sh) that the builder is executing
<kdub> you can change the script if need be, but really its probably an issue of getting cmake to sort things out correctly
<rsalveti> right, it's only installing libhybris and libhybris-dev
<rsalveti> not necessarily all the dependencies
<rsalveti> let me check the script
<rsalveti> https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/462/console also failed
<rsalveti> but seems related with the test results
<rsalveti> not related with my change
<robert_ancell> kdub, does https://code.launchpad.net/~rsalveti/mir/fixing-libhybris-dependencies/+merge/178863 make sense?
<rsalveti> you shouldn't build-dep on libhybris-egl
<rsalveti> that's provided by mesa
<rsalveti> and you just need to install libhybris during runtime, as that will replace mesa's egl
<kdub> right, we shouldnt care at buildtime whether its the hybris or mesa
<robert_ancell> rsalveti, did you want a specific review from tvoss_ instead of just the mir team?
<rsalveti> no, just added him there because he asked me to
<robert_ancell> ok, kdubs review should be sufficient to land
<rsalveti> kdub: ok, changed the cross build script, will wait to see if that helps
<kdub> rsalveti, i reviewed with a +1, conditional on getting it past the builder
<rsalveti> kdub: any idea why it failed for amd64 though?
<kdub> rsalveti, no, that is a strange failure :/
<kgunn> robert_ancell: not that you needed another data point....but using staging xorg worked for me (+mir from main, +usc from daily-build)
<robert_ancell> RAOF, any update on that patch from mlankhorst?
<RAOF> robert_ancell: I'm hunting it down; it doesn't seem like he pushed that to git.
<RAOF> Ah, there it is.
<kgunn> RAOF: quick one...what did "mesa dependent on some radeon kernel patches" mean ? or how does it relate ?
<RAOF> kgunn: To be proper, the radeon mesa module needs to know the size of the buffer its importing; for dma-buf there's currently no way to get that, so I made a kernel patch.
<robert_ancell> kdub, rsalveti, so it looks like those memcheck failures are happening elsewhere https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/463/console
<RAOF> kgunn: We're doing sufficiently simple things that this shouldn't be a problem, but for upstream acceptance the general case is important :)
<rsalveti> robert_ancell: yeah, they are not related with packaging changes for arm :-)
<kdub> hmm
<RAOF> Ah. *There* we go. This laptop *does* have fans.
<RAOF> robert_ancell: New Xserver tested, fixes your bug, and uploaded.
<robert_ancell> RAOF, nice!
<RAOF> And with that, I think I'm no longer firefighing?
<RAOF> Maybe I can get some actual feature work done!
<RAOF> duflu: Good morning!
<duflu> RAOF: Morning!
 * duflu reserves judgement over good, for a while
<RAOF> Heh. How's Perth travelling?
<duflu> RAOF: It's basically spring. Been very warm lately
<duflu> RAOF: Laptop in action yet?
<RAOF> It is indeed.
<robert_ancell> duflu, can I get you to re-review https://code.launchpad.net/~robert-ancell/mir/alt-ctrl-backspace/+merge/178036?
<duflu> robert_ancell: Yes, can it wait for me to plough through email etc first?
<robert_ancell> duflu, sure
<RAOF> duflu: I'd still like to line up a bypass discussion at some point, too :)
<duflu> RAOF: I know. But I have significant "switch" issues to address first. It won't go away :/
<RAOF> duflu: ok.
<RAOF> There's plenty of xrandr to do :)
<duflu> RAOF: So don't expect today
<rsalveti> RAOF: did you like your new laptop? thinking about getting a similar one in a month
<RAOF> rsalveti: It's pretty nice.
<RAOF> It's particularly nice to have the system76 guys in the community - I'm half-way through setting up secure boot on this machine thanks to an out-of-band firmware update I got because I mentioned that I wanted to securebootify it.
<duflu> OK, I have now broken my VTs. Can't switch to any
<rsalveti> RAOF: yeah, that's nice, cool
<rsalveti> most reviews are saying good things about it as well, looking forward to move from my thinkpad t400 :-)
<rsalveti> 4 years old already
<RAOF> It's pleasantly light, and reasonably constructed.
<rsalveti> nice
<rsalveti> RAOF: running xmir on it already?
<RAOF> It's not quite at the build quality of my old x200s, but it's a cut above the old asus I had.
<RAOF> rsalveti: Not right at the moment; I like my VTs :)
<rsalveti> RAOF: haha, right :-)
<RAOF> It's easier to test in mir_demo_server_shell, anyway.
<RAOF> You don't have to blow away your existing session to test there :)
<rsalveti> right, indeed
<RAOF> The laptop is also nice and quiet. Idle I don't think the fans are on at all, and under moderate load they pick up to fairly quiet.
<rsalveti> awesome
<rsalveti> can't wait to get one as well
<duflu> Has anyone else noticed Mir servers crash when new clients start? Seems to be a new regression on trunk landing last night
 * duflu is trying to trace the problem without breaking his machines
<duflu> Rolling back to yesterday's branches work at least
<RAOF> Dear lord. Why doesn't bzr ship with bzr-pager?
<smspillaz> RAOF: hmm, never heard of it. What does it do?
<RAOF> smspillaz: Pipes everything bzr outputs through a pager.
<smspillaz> oh, I guess it automatically pipes to less
<RAOF> ie: git's default mode.
<smspillaz> heh
<RAOF> This is one of the rare cases where git's default is substantially saner than bzr's.
<smspillaz> RAOF: I dunno, I think the git branching model is saner than having to muck around with lightweight checkouts :)
<smspillaz> though I was very happy when I found out about lightweight checkouts
<smspillaz> unfortunately it was only after I had run out of disk space N times already
<RAOF> I don't bother with lightweight checkouts. A repository works fine.
<smspillaz> RAOF: repository?
<RAOF> Now, *this* is something bzr does terribly.
<RAOF> bzr init-repo .; will turn the current directory into a repository.
<smspillaz> RAOF: I don't see how that's different from bzr branch' default behaviour
<RAOF> Anything you branch into that directory will share the repository.
<RAOF> So you've got one copy of history + n-checkouts.
<RAOF> If your checkouts are what's pushing you over the space size, you've got problems :)
<smspillaz> RAOF: I used to always do bzr branch lp:foo foo.whatever and then have a million foo.* drs
<smspillaz> *dirs
<smspillaz> each with their own build/
<RAOF> Yeah, jml wrote a plugin to identify and remove those branches which had been merged.
<smspillaz> when you consider that a unity build got to about 3GB, it got big quick
<smspillaz> RAOF: yeah, I never was able to find that, but I have heard that such a thing existed
<smspillaz> in any case, git's behaviour in that area is much *much* nicer :)
<RAOF> lp:bzr-removable
 * duflu has wacky graphics corruption and can't see what he's typing. brb
<RAOF> Woot!
<smspillaz> duflu: you do a much better job at spelling correctly when you can't see what you're typing than me :)
 * smspillaz could never see what he was typing whenever using irssiconnectbot or whatever on android, hence all the spelling mistakes generally
<duflu> smspillaz: Well, that time I was looking at the keyboard
<smspillaz> heh
<robert_ancell> RAOF, I still have the X lockup, investigating more here
<duflu> It seems a Mir (heap corruption?) bug hit me in the middle of libgbm, which then corrupted X too
<RAOF> Huh. It fixed it here, damnit!
<robert_ancell> RAOF, I didn't think you'd reproduced it had you?
<RAOF> robert_ancell: You've got 0ubuntu9, from the archive?
<robert_ancell> RAOF, yes
<RAOF> robert_ancell: I managed to reproduce it on my hybrid system.
<robert_ancell> RAOF, what was the cause for you?
<RAOF> Spinning in deletedriver, because radeon was marked for deletion but wasn't getting deleted
<racarr> Back for the night shift
<duflu> robert_ancell: Not sure if you want to wait for someone to do a proper fix, but this is rather critical... https://code.launchpad.net/~vanvugt/mir/revert-r931/+merge/178877
<robert_ancell> duflu, I'm looking at it now. We should revert if it's causing problems.
<robert_ancell> duflu, can you note in the bug what you're doing to confirm it?
<robert_ancell> I assume this is mir_demo_server and mir_demo_client_*?
<RAOF> Huh. I tested that commit with mir_demo_server_shell and xmir.
<RAOF> Presumably I should also have done so with a native Mir client :)
<duflu> robert_ancell: Yes, I added a comment
<duflu> It would be nice to figure out how that got past all automated testing...
<RAOF> Ok, I can reproduce the crash with mir_demo_client_eglplasma.
<robert_ancell> duflu, did the whole video system lock up when testing the client?
<duflu> robert_ancell: It killed the Mir server, which does turn off the display. You need to switch to X to restore the state correctly (Ctrl+Alt+F7)
<duflu> robert_ancell: There's a separate bug for that :)
 * RAOF +1s the revert, then heads to lunch.
<robert_ancell> duflu, I'll just confirm your branch fixes it, then +1 from me too
<robert_ancell> argh. Stupid cmake
<robert_ancell> duflu, don't block on me
<duflu> robert_ancell: I will. I already blocked the morning for this :S
<duflu> Damn. I'm involved in too many reviews again
<robert_ancell> RAOF - https://code.launchpad.net/~mir-team/mir/expose-debug-buffer-id-to-client/+merge/176843 would break ABI/API
<duflu> robert_ancell: I will defer testing ctrl+alt+backspace till the regression is fixed. So I can test properly
<robert_ancell> rsalveti, have some associated packaging changes broken android builds? https://jenkins.qa.ubuntu.com/job/mir-android-saucy-i386-build/1622/console
<robert_ancell> duflu, hoping that android build failure is going to disappear?
<robert_ancell> RAOF, is there a reason you compact the driver list on deletion?
<duflu> robert_ancell: Yes hoping one way or the other
<tvoss_> good morning :)
<robert_ancell> RAOF, ah, so turned out I had the -0ubuntu9 from yesterday. The new -0ubuntu9 from main does fix the problem for me
<robert_ancell> bbl
<sam113101> HELLO
<sam113101> IÂ want to know what's the equivalent of a window manager (in the X world) with mir? is it the compositor?
<sam113101> the thing that draws the window borders, offers special effects, etc.
<duflu> sam113101: It's the "shell". And as yet there is no shell that does any window management really. But we're slowly building a demo in examples/demo-shell/. And later it will be done in the Unity8 project's shell.
<duflu> All you can do with demo-shell is Alt-Tab and move windows around (Alt+drag or three fingers)
 * duflu goes to lunch
<sam113101> IÂ don't know what's a shell, it's kind of confusing (at least to me)
<RAOF> sam113101: Yes. The compositor is the equivalent of a window manager; same as wayland.
<sam113101> RAOF: what's a shell, then?
<RAOF> sam113101: Think "desktop environment".
<RAOF> sam113101: It's the bit of the compositor that is the desktop environment.
<tvoss_> good morning again :)
<RAOF> Heeelo.
<sam113101> the shell is part of the compositor?
<RAOF> Yes
<robert_ancell> duflu, I think we have to land https://code.launchpad.net/~rsalveti/mir/fixing-libhybris-dependencies/+merge/178863 first to fix the android build errors
<sam113101> you're sure it's not the opposite?
<robert_ancell> sam113101, the shell *is* a compositor
<RAOF> Is a display server.
<robert_ancell> there's no special component called a compositor. There can be a number of compositors
<RAOF> Everything is rolled into one - display server, compositor, shell, window manager.
<alf__> RAOF: Does X/XRandR handle rotation internally? That is, for XMir does Mir need to provide some kind of rotation option when configuring the display?
<RAOF> It would be better if it did; let me check.
<sam113101> robert_ancell: there can be multiple compositors?
<robert_ancell> sam113101, yes, in the Ubuntu case we have Unity Shell as one compositor and Unity System Compositor switching between shells
<RAOF> alf__: I'd be better to handle it in Mir, but it's currently handled in the drivers.
<RAOF> alf__: So if it's hard for Mir to expose that, XMir can do that work.
<sam113101> is there a mir server a compositor talks to or is the compositor the server itself?
<smspillaz> sam113101: like wayland compositors, the clients connect to it directly
<RAOF> sam113101: The compositor is the server itself. Everything is in the one place; display server, compositor, shell, window manager.
<RAOF> Just like wayland.
<duflu> sam113101: I think you're used to the X/Compiz/WM way of doing (and naming) things. Mir is more like Gnome Shell, Windows or OSX in that the whole UI (shell) is one thing. And that thing does composition, window management, etc.
<sam113101> yeah I'm used to the old scenario
<alf__> RAOF: For now (due to time constraints), I'd rather if XMir handled it, if it is something that is ready.
<alf__> RAOF: What would X require from Mir in terms of rotation?
<sam113101> so there are only two things, a compositor (which uses the mir library) and clients (which also use the mir library to talk to the compositor), is that right?
<RAOF> alf__: Ideally it would take the buffer from XMir and rotate it during the composition phase based on what XMir asked.
<duflu> alf__: I was thinking about that. Rotation requires (1) Screen transformation, (2) Cursor transformation, (3) surface resize support as width becomes height etc
<RAOF> alf__: So XMir could set RotateClockwise90 on it's 1920x1080 window, and Mir would take the 1920x1080 buffer and rotate it through 90 degrees when compositing to the framebuffer
<duflu> ... in other words, Mir is not ready for that. Let XMir do it :)
<duflu> I suspect (3) resize support is the major blocker. That's probably quite non-trivial
<alf__> duflu: RAOF: right, at the same time the contents need to be transformed accordingly, e.g., X needs to know that this is now a 1080x1920 surface and draw accordingly, so XMir should be involved at some point?
<sam113101> IÂ think I'm going to write my own compositor some day, if IÂ ever get knowledgeable enough
<duflu> sam113101: We aim to provide examples that help people to do that. Just need time to make the examples more interesting
<sam113101> alright
<duflu> sam113101: You could start now by copying examples/demo-shell/ but the API is likely to change somewhat still
<tvoss_> RAOF, ping
<RAOF> tvoss_: Pong
<RAOF> alf__: No, X wants it to be a 1920x1080 surface always.
<alf__> RAOF: But in terms of content drawing it will treat it as a 1080x1920 surface, right?
<RAOF> I think the answer to that is "no"
<RAOF> But I need to trace further
<alf__> RAOF: in any case... we need to find out what more, if anything, XMir needs from Mir to support screen rotation
<RAOF> Yes
<alf__> RAOF: I would imagine that since XRandR uses KMS normally, that it can handle everything internally, and that Mir (for now) can just replace the functionality that KMS provides
<alf__> RAOF: so no rotations/transformations
<RAOF> Yeah.
<duflu> Ugg. My audio settings are broken again. Need to reboot to hangout
<kgunn> thomi: psychedelic !
<thomi> kgunn: I know, but watch this!
<kgunn> robert_ancell: weekly ?
<robert_ancell> kgunn, yes...
<thomi> ugh, hangout is broken all of a sudden
<thomi> hmm, can't log back in
<tvoss|test> hmmm, unity-system-compositor does not compile for me, failing with /usr/include/mirserver/mir/default_server_configuration.h:23:40: fatal error: mir/options/program_option.h: No such file or directory
<tvoss|test>  #include "mir/options/program_option.h"
<tvoss|test> looking into my include files, that include file is indeed missing
<robert_ancell> thomi, :(
<robert_ancell> thomi, it's coming up to your turn
<didrocks> tvoss|test: I confirm: https://launchpadlibrarian.net/146957401/buildlog_ubuntu-saucy-amd64.unity-system-compositor_0.0.1%2B13.10.20130807-0ubuntu1_FAILEDTOBUILD.txt.gz
<tvoss|test> robert_ancell, ^
<racarr> I am too tired to talk constructively about surface-configuration-interface/client-focus I think
<robert_ancell> tvoss|test, hrm. Looks like someone changed the API
<robert_ancell> racarr, :( Get some sleep!
<racarr> but would appreciate if people could try and think about them, and say...not tomorrow, but the next morning
<racarr> I will make it an extra early morning day and can sync up with everyone
<alf__> robert_ancell: Looking at your branch... I think I have a less intrusive way to do this (e.g. not needing to set the server explicitly)
<racarr> :)
<kgunn> robert_ancell: i'll let you decide ultimately....but if you're sway-able...i'd say update ppa asap since we;re still struggling ^
<tvoss|test> robert_ancell, it's not even that, the include file mentioned in default_server_configuration does not exist anymore
<robert_ancell> alf__, ok, please propose an alternative. We just need to get something landed
<alf__> robert_ancell: ok
<racarr> robert_ancell: My pleasure :D
<robert_ancell> kgunn, Do you think being unable to VT switch is a blocker?
<robert_ancell> I'm otherwise happy to update
<kgunn> robert_ancell: not a blocker imho
<robert_ancell> ok, will do
<kgunn> just a bug :)
<robert_ancell> and I'll point the complaints to you :)
<kgunn> certainly
 * kgunn goes to bed
<didrocks> tvoss|test: another day without u-s-c to distro I think :/
<robert_ancell> alf__, I'm about to EOD - lp:~robert-ancell/mir/vt-switch-keys is the VT switching branch (not working). If you want to fix/change that feel free
<alf__> robert_ancell: Do we want both quit and vt to live only in examples? Will u-s-c do its own thing separately?
<robert_ancell> RAOF, can you upload the recent X to the staging PPA so I can copy it to the s-c-t PPA?
<RAOF> robert_ancell: Is there any particular... oh, yeah. Pinning.
<robert_ancell> alf__, the VT switching is in DefaultServerConfiguration, the alt+ctrl+backspace just in DemoServerConfiguration
<robert_ancell> RAOF, yep
<alf__> robert_ancell: ok
<RAOF> Oh, I think it'll be rejected because it's not newer than the archive?
<RAOF> Let's find out!
<robert_ancell> alf__, I think that makes sense. It was kind of yuck to have the VT switching code separate from the GBM code, but I couldn't think of a way around it
<robert_ancell> RAOF, because of the obsolete -0ubuntu9?
<RAOF> robert_ancell: Yeah.
<RAOF> Other option is to delete the X server in s-c-t?
<RAOF> Then it'll drop out of pinning and they'll get the archive version.
<robert_ancell> RAOF, yeah, that might work
<robert_ancell> RAOF, we can drop xserver-xorg-video-* as well right?
<RAOF> robert_ancell: Yes
<robert_ancell> and libdrm and mesa?
<tvoss|test> robert_ancell, RAOF announcing that by mail might be a good idea. How can we test before removing it?
<RAOF> Yes.
<RAOF> alf__: Oh, another thing that Mir doesn't provide on the monitor-configuration front? Names for the outputs.
<RAOF> alf__: There's no way to distinguish between HDMI-1 and VGA-1 andâ¦
<RAOF> alf__: It doesn't need to be a string; you could also send an enum. But we do need some way to tell.
<alf__> RAOF: ok
<duflu> RAOF/alf__: I too vote for names/numbers/anything.
<duflu> Hmm, no wonder X is always confused. Xrandr says VGA is active even when the monitor is physically turned off
<alf__> duflu: RAOF: sure, probably both an enum with the type VGA/HDMI etc, and a unique name
<duflu> alf__: Also, in the absence of GUI's it would be awesome to be able to say "VGA1 rightof DVI1 align top" or similar
<duflu> alf__: I'd be happy to do such a text interface providing arbitrary placement is functional
<duflu> But obviously we have higher priorities right now...
<didrocks> kgunn: tvoss|test: FYI, I disable u-s-c tests and run for now
<didrocks> kgunn: tvoss|test: apparently, nobody is working on debugging it, and that's what which is screwing the -ati machine everyday
<duflu> Another option which doesn't even need names is to have special key combos which move the current monitor (with the cursor) relative to others
<didrocks> kgunn: tvoss|test: like nothing else is running after that when starting the session, I think the ati driver state isn't right then and we have to reboot it
<didrocks> jibel: FYI ^ let's do that
<didrocks> Mirv: so don't bother with mirslaves for now, as per ^
<didrocks> good to have a least a start of explanation why we got the -ati machine screwed everyday
<Mirv> didrocks: yeah I didn't already because you told me so on Monday
<RAOF> duflu: The DDC pins provide power for the EDID firmware; it's not possible to distinguish between an unpowered monitor connected to a VGA port and a fully armed and operation monitor plugged in to a VGA port.
<duflu> RAOF: OK, makes sense if your OS handles multi-monitor more reliably than this one :/
<duflu> But it will be super-psychic-always-right in Mir :)
<RAOF> Not really. It never really makes sense.
<RAOF> Fortunately, you *can* tell if a DisplayPort monitor is turned off, and it's also possible to detect some HDMI (but I'm not sure whether we do at the moment)
<RAOF> So once everyone's thrown away their current hardware this problem will go away!
<duflu> RAOF: Hmm, I will need a system with multiple digital outs and at least one new monitor first
<duflu> Wait, no. Just the former.
<dholbach> good morning
<tvoss|flaky> alan_g, ping
<alan_g> tvoss|flaky: ?
<tvoss|flaky> alan_g, good morning. your recent refactoring to the platform stuff breaks compiling unity-system-compositor as the options-headers are not installed
<alan_g> tvoss|flaky: https://code.launchpad.net/~robert-ancell/mir/mirplatform/+merge/178895
<tvoss|flaky> alan_g, does not pass CI due to the install directory directive not being correct
<tvoss|flaky> alan_g, do you have cycles available to take care of landing it?
<alan_g> tvoss|flaky: will do
<tvoss|flaky> alan_g, thx
<alan_g> tvoss_:  https://code.launchpad.net/~alan-griffiths/mir/mirplatform-install-headers/+merge/178909
<alan_g> alf__: any chance of a quick top-approve for https://code.launchpad.net/~alan-griffiths/mir/mirplatform-install-headers/+merge/178909
<alf__> alan_g: looking
<alf__> alan_g: are the headers included in some package?
<alan_g> alf__: Good point
<alan_g> tvoss_:  https://code.launchpad.net/~alan-griffiths/mir/mirplatform-install-headers/+merge/178909
<RAOF> alf__: Oh, and could we also grab the EDID?
<alf__> RAOF: I guess so, why do you need it?
<RAOF> Clients sometimes care about it.
<RAOF> You can grab useful information from it, like the name of the display etc.
<RAOF> Oh, and subpixel layout; likewise, clients can use it.
<alf__> RAOF: how does xrandr get edid now? Does KMS provide it, or does it grab it from /sys?
<RAOF> kms provides it.
<alf__> RAOF: can you point me to the function?
<tvoss_> alan_g, looking
<alf__> RAOF: is it a "property blob"?
<RAOF> alf__: extern drmModePropertyBlobPtr drmModeGetPropertyBlob(int fd, uint32_t blob_id); with blob_id ==... yeah
<RAOF> You need to grab the properties, iterate over them finding which one has name == "EDID", and then that's the blob to get.
<alf__> RAOF: thanks
<alf__> RAOF: ok, so to sum up: subpixel, edid, unique name
<RAOF> These are the things I've hit so far, yes :)
<RAOF> I think they cover the main bases.
<tvoss_> alan_g, building mir now, and usc subsequently
<tvoss_> katie, ping
<katie> tvoss_, ping pong
<alan_g> tvoss_: thanks
<RAOF> alf__: Whoops! subpixel, edid, type/name, *and* the number of independent outputs that can be driven.
<alf__> RAOF: ok
<alf__> RAOF: How blocking are these? Any preference about order of implementation?
<RAOF> I don't think any are totally blocking. count_crtcs would be my first preference, then EDID, then type/name, then subpixel.
<RAOF> Of those, if we shipped without subpixel it wouldn't be terrible. We *could* ship without EDID, it just makes my life easier. The type & count_crtcs are absolutely mandatory.
<alf__> RAOF: we will ship with all, mostly caring if any of these is blocking you in the short term
<alf__> duflu: FYI, https://code.launchpad.net/~afrantzis/mir/gbm-alloc-validate-buffer-format/+merge/178928
<duflu> alf__: Yeah saw it
<RAOF> Hah! alf__ - is the modes array sorted at all? If not, is there a way of getting the output's preferred mode?
<alan_g> tvoss_: does it work for you?
<tvoss_> alan_g, still compiling. had some hiccups as I have libhybris installed
<tvoss_> alan_g, compilation works fine here
<tvoss_> alan_g, approved :) alf__ would you mind taking a second look and top-approving?
<alan_g> tvoss_: great.
<tvoss_> alan_g, I haven't tried usc, though
<alan_g> tvoss_: but it builds?
<tvoss_> alan_g, ack
<alan_g> good enough for me
<alf__> RAOF: The modes are as KMS gives them back, so sorted from higher to lower resolutions. I haven't come across a situation where the preferred mode is not the first (but of course I haven't had the chance to try with a lot of outputs)
<alf__> tvoss_: which MP is that?
<tvoss_> alf__, https://code.launchpad.net/~alan-griffiths/mir/mirplatform-install-headers/+merge/178909
<alf__> tvoss_: alan_g: top approved
<tvoss_> alf__, \o/
<RAOF> alf__: Probably time to add preferred-mode to that to the list, then âº (or, at least, ensure preferred mode is the first in the array). I'm pretty sure CRTs will have a highest-resolution mode that's non-preferred.
<alf__> RAOF: ok
<alf__> RAOF: the list grows :) but thankfully all are simple additions
<RAOF> And now, sleep.
<greyback> alf__: hey, could I maybe add this bug to your list of things to do: https://bugs.launchpad.net/mir/+bug/1209216 - or please comment if I'm not using the API correctly
<ubot5> Launchpad bug 1209216 in Mir "Snapshot of non-fullscreen surface returns a fullscreen pixmap with white padding" [Undecided,New]
<alf__> greyback: will take a look
<tvoss_> didrocks, ping
<didrocks> tvoss_: pong
<greyback> alf__: if you'd like more info in that bug, do say. It is very textual :)
<alf__> greyback: could you point me to the code where the code is used
<alf__> ?
<tvoss_> didrocks, staging has got a new version of mir that has got all the headers installed
<tvoss_> didrocks, tested locally, can build usc against it
<greyback> alf__: http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/view/head:/src/modules/Unity/ApplicationManager/applicationscreenshotprovider.cpp#L46
<didrocks> tvoss_: ok, let me retry manually then, hoping that it won't screw up the ati machine again
<didrocks> first, building mir
<tvoss_> didrocks, ack
<alf__> greyback: I can't think a way for Mir to be getting this wrong (not that it's not possible0. Could the non-fullscreen surface be really implemented as a fullscreen surface with transparency on the top?
<greyback> alf__: hmm, that's a possibility. Let me look
<didrocks> tvoss_: cmake isn't available on all archs yet, it will take a little bit more time for armhf
<tvoss_> didrocks, cmake as in? sorry, ENOCONTEXT :)
<didrocks> tvoss_: cmake made Mir FTBFS (a new upload, arch mismatchs)
<didrocks> I'll retry Mir once cmake is published on armhf
<tvoss_> didrocks, okay
<alf__> greyback: btw, in the code I see that you are mirroring the image. Note, that I am mirroring too internally when transforming from texture (bottom-up) to byte data (top-down). Perhaps we can avoid both mirrorings.
<greyback> alf__: yes that would make sense
<greyback> alf__: you are correct, it appears every qtubuntu surface is actually fullscreen. It is using platform-api to move & resize the surface, but those a stubs. Qt itself I believe is drawing the white padding
<doko> didrocks, shouldn't happen anymore with the loosened dependency
<didrocks> doko: yeah, I hope so :) just retried armhf
<tvoss> didrocks, ping
<tvoss> alf__, alan_g what is the review status on duflu's switch branch?
<alan_g> tvoss: I started looking at it a couple of days ago. Then it went to WIP. I see it is now back again.
<didrocks> tvoss: pong
<alan_g> tvoss: It is a LOT of change to get one's head around and validate.
<tvoss> alan_g, I know, it still fixes the lag issue, though
<alf__> tvoss: alan_g: I haven't validated every line (nor I plan to), but it seems to work reasonably well last I checked. It effectively triple-buffers all the time, though, and what concerns me is that attempts to enforce double-buffering haven't been successful yet, which may indicate a more fundamental algorithmic issue. I am OK with getting this in without the enforced double-buffering, but we need to fix it soon, if only to prove that it is doa
<tvoss> alf__, ack
<kgunn> didrocks: ping
<didrocks> kgunn: pong
<kgunn> didrocks: hey read the scrollback...checked mails, so it seems the ati machine is the last hurdle ?
<didrocks> kgunn: hum, ati and intel
<didrocks> kgunn: the other issues isn't confirmed to be fixed AFAIK
<didrocks> (like no GL)
<didrocks> the additional input is that we have confirmation that it's that failing state which makes the ati machine irresponsive then
<didrocks> and we have to electrically reboot it
<kgunn> didrocks: i apologize for my questioning...just trying to help :)...but "other issues isn't comfirmed to be fixed" you are referring to intel xorg seq fault ?
<didrocks> kgunn: right, it was intel/ati (the symptoms looked the same), was that worked on? I didn't see any change on the bug I referred
<kgunn> didrocks: for sure intel "has a fix"....me, tvoss, bschafer all verified a fix
<kgunn> the magic combo was main-mir, xorg-staging, u-s-c-daily-build
<didrocks> kgunn: when was it committed? today?
<kgunn> didrocks: actually, that's what i have a difficult time with...backtracking code changes to xorg (lp so much easier in that regard :)
<tvoss> didrocks, it was working yesterday
<didrocks> ok, but then, we had the FTBFS on u-s-c
<tvoss> didrocks, is libhybris installed on the testing machine?
<didrocks> tvoss: I don't think so
<didrocks> let me confirm
<tvoss> didrocks, yeah, if that is the case, usc won't come up
<didrocks> tvoss: it wasn't installed
<tvoss> didrocks, okay, what is the usc log? or better: does it come up?
<didrocks> " More annoying, on both the intel and ati machines we currently use for testing (and no nvidia plugged in by QA yet :/), latest Mir with u-s-c hangs on boot. I can clearly see compiz hanging on the opengl driver loading. If I DISPLAY=:0 /usr/lib/nux/unity_support_test -p, it hangs forever (but not sure if this should work in the Mir world)."
<didrocks> tvoss: what I wrote on Monday in my email ^
<didrocks> tvoss: if needed, can rebuild (now that it builds, right?) latest u-s-c and put you on the machine
<tvoss> didrocks, unity_support_test should work ... but that's not on boot, right?
<didrocks> tvoss: it's run by unity on boot (but I guess not on the Mir case anymore)
<didrocks> tvoss: let see, I'm retrying a build of u-s-c now
<tvoss> didrocks, yeah, give that a spin please
<tvoss> didrocks, the new xserver fixed a bunch of spin issues, too
<didrocks> tvoss: ok, we have it (but not latest -ati driver from midday)
<tvoss> didrocks, okay
<tvoss> didrocks, to clarify: what are you doing now?
<didrocks> tvoss: rebuild u-s-c now that it shouldn't FTBFS and the tests will run again on both -ati and -intel
<didrocks> with latest snapshot of distro (taken at 9am UTC)
<tvoss> didrocks, thx
<mattld> tvoss: I have an easy question you could answer. Is xmir a fork of xwayland?
<tvoss> mattld, no, although it naturally takes a very similar approach
<mattld> tvoss: Thanks for the answer. I will use this to combat Reddit FUD.
<tvoss> mattld, thanks :)
<mattld> tvoss: Have an awesome day!
<tvoss> mattld, thank you, to you too! Let me know if you need any further information
<didrocks> tvoss: kgunn: intel passed now, ati is still stuck
<didrocks> http://10.97.0.1:8080/job/autopilot-saucy-daily_release/label=autopilot-ati/808/console
<kgunn> didrocks: so ati boots fine, just gets stuck on AP testing ?
<didrocks> kgunn: yeah, as you can see unity doesn't start
<didrocks> kgunn: compiz seems to hang on the opengl compiz init
 * kgunn looking at it right now
<kgunn> didrocks: so can we grab the /var/log/Xorg*'s
<didrocks> kgunn: doing right now
<didrocks> kgunn: Xorg.0.log: http://paste.ubuntu.com/5959227/
<didrocks> unity-system-compositor.log contains:
<didrocks> dm_connection_start
<didrocks> set_active_session '0'
<didrocks> set_active_session
<didrocks> and it's running
<didrocks> compiz is running as well
<didrocks> (but no plugin loaded after opengl as you can see)
<didrocks> kgunn: I'm closing the container so that you can download the tar
<jibel> kgunn, tvoss for what it's worth, here is the kernel trace when we try to restart an X session after running mirslave tests on radeon http://paste.ubuntu.com/5959277/
<kgunn> jibel: thanks...altho, a subsequent symptom of something nasty previous i think
<jibel> yes
<tvoss> mlankhorst, something for your interest :) http://paste.ubuntu.com/5959277/
<mlankhorst> tvoss: try again with PROVE_LOCKING :p
<tvoss> mlankhorst, is that really an env var?
<kgunn> bschaefer: we're back to ati hell
<bschaefer> kgunn, o no...
<mlankhorst> tvoss: no, it's a kernel option
<bschaefer> whats going on with ati?
<tvoss> mlankhorst, argh ...
<kgunn> bschaefer: so didrocks ati machine locks to the point of requiring hard reboot
<tvoss> mlankhorst, any gut feeling what kind of issue we are hitting?
<mlankhorst> it's quite obvious from the backtrace ;P
<bschaefer> kgunn, hmm thats not good...is there a bug out for it yet?
<kgunn> bschaefer: nope...i think didrocks was trying to get the xorg log for us, they did try to respawn x and kernel crashed (what voss and lankhorst are chatting about)
<kgunn> watchdog timer fired
<didrocks> kgunn: and there is no Xorg log
<didrocks> nor lightdm ones
<bschaefer> :( thats a bad crash then
<didrocks> on the respawn
<didrocks> (so after the first run)
<didrocks> kgunn: did you get the archive file?
<didrocks> (from the u-s-c run)
<kgunn> didrocks: if you mean ubuntu_13.10_saucy_salamander_alpha_i386_20130806.1375887034.otto....my browser just does the sit-n-spin....and it never downloads
<kgunn> lemme try again....
<didrocks> kgunn: hum, really?
<kgunn> didrocks: its going now...i prob was trying in midst of reboot or something
<didrocks> possible yeah
<tvoss> mlankhorst, mind enlightening me? :)
<bschaefer> i also get the sit-n-spin
<mlankhorst> tvoss: you're hitting a deadlock with w/e lock was being taken, and PROVE_LOCKING will tell you exactly what deadlock it is and how to cause it
<mlankhorst> prove_locking is awesome, it catches bugs before they deadlock :P
<bschaefer> kgunn, its working for me now
<bschaefer> (download)
<tvoss> mlankhorst, okay, thanks for the hints :)
<tvoss> bschaefer, kgunn, didrocks any chance we can have a kernel with that flag enabled on the machine?
<bschaefer> mlankhorst, thats awesome
<bschaefer> tvoss, hmm I don't see why not
<kgunn> that is awesome..but gotta rebuild kernel
<mlankhorst> I don't know if it's smart enough to catch THIS particular bug before it deadlocks, but it very well might be ;P
<bschaefer> hmm rebuilding the kernel sounds like fun
<kgunn> didrocks: bschaefer that archive file downloads ok...but fails to unzip for me (tried to redownload, same result)
<mlankhorst> and with that I mean it will probably have catched it at the point of deadlock, but if lucky it will warn way before that point already
<bschaefer> kgunn, o hmm
<didrocks> kgunn: did you try with tar xzf ?
<bschaefer> mlankhorst, well that is if it deadlocks again...and if its a dead lock
<kgunn> didrocks: gonna try
<mlankhorst> bschaefer: if it's a deadlock there's a fat chance lockdep will have complained long before the actual deadlock :D
<mlankhorst> and come on, it's an interrupt while holding a ton lof locks for committing new crtc state, of course it's very likely to be a deadlock..
 * bschaefer hasn't ever seen a deadlock :)
<bschaefer> i've learned about them...
<mlankhorst> it's spinning [21683.801142]  [<c16237f2>] _raw_spin_lock_irqsave+0x22/0x30
<bschaefer> mlankhorst, has lockdep complained
<mlankhorst> bschaefer: lockdep is not enabled by default, requires PROVE_LOCKING kernel :-)
<bschaefer> ooo, yeah now im on page :)
<mlankhorst> but it checks if a deadlock is theoretically possible between the lock classes
<mlankhorst> in some cases without ever being able to hit it, but there are workarounds if you believe lockdep is wrong. :P
<bschaefer> haha, I would like to believe in lockdep :)
<mlankhorst> I want to try the userspace version at one point :(
<bschaefer> kgunn, do we have a machine we can rebuild the kernel on?
<kgunn> bschaefer: yeah...this one, at least if didrocks says ok
<bschaefer> mlankhorst, isn't any deadlock detecting algorithm externally inefficient? Which is why its not enabled by default...
<didrocks> kgunn: we can't, we are starting 3h-daily releases now
<bschaefer> err
<bschaefer> extremely*
<didrocks> kgunn: as it was a strong upstream demand, we'll not be able to build/block the machine for anything anymore soon
<kgunn> bschaefer: do you have ati local ?
<bschaefer> kgunn, Ill have to try to installed ubuntu on it again, my hard drive seems to hate me
<kgunn> otherwise we may have to beg robotfuel to help us repro on his ati machine(s)
<bschaefer> kgunn, let me give that another go
<kgunn> bschaefer: talk nice to it
<robotfuel> bschaefer: you can use ps-radeon-hd6870-he
<didrocks> bschaefer: ensure you use radeon
<bschaefer> kgunn, its so easy not to though!
<kgunn> encourage the 1's and 0's to be in the right spot
<mlankhorst> bschaefer: sort of, it's better here
<mlankhorst> lockdep operates on classes of locks
<mlankhorst> not individual locks
<bschaefer> robotfuel, cool :)
<mlankhorst> and also checks for things like 'is this lock ever taken with irqs disabled' etc
<bschaefer> mlankhorst, ooo, thats interesting
<kgunn> didrocks: just to confirm....we're main for mir+xorg-xmir+xorg-radeon & u-s-c from daily-build ppa
<kgunn> right ?
<mlankhorst> see linux/Documentation/lockdep-design.txt
<kgunn> didrocks: for the sake of bschaefer ^
 * bschaefer looks
<didrocks> kgunn: exactly
<bschaefer> didrocks, yeah, I would like to make little errors like using the wrong ppa :)
<kgunn> cool
<bschaefer> like to not*
<bschaefer> mlankhorst, cool, that might be for out of work reading though...
<kgunn> bschaefer: the main thing is to avoid daily-build-next ppa :)
<bschaefer> haha
<mlankhorst> bschaefer: heh it saved my life dealing with the ttm reworking
<mlankhorst> and found quite a few 'almost impossible to hit' bugs :P
<bschaefer> mlankhorst, that sounds like very complicated/fun work!
<kgunn> bschaefer: whatever the fastest route is...local or in lexington....maybe lankhorst can help us out if we get debug info before his eod (whenever that may be)
 * bschaefer looks up ttm
<bschaefer> kgunn, yeah, well its also been a while since i've rebuilt the kernel, soo Ill have to spend sometime with that
<kgunn> bschaefer: understood...
<bschaefer> kgunn, but shouldn't be to hard
<kgunn> kernel builds are usually damn quick...take you longer to find the flag :
<kgunn> :)
<mlankhorst> technically it's already EOD, but I'm feeling generous
<kgunn> mlankhorst: we appreciate your generosity
<mlankhorst> might be because the weather is too horrible to do outdoors sports :P
<kgunn> mlankhorst: you're building you "i owe you a beer" backlog
<bschaefer> haha
 * kgunn hopes mlankhorst drinks beer
<bschaefer> kgunn, yeah, well then I should poke around with the qa machine first
<bschaefer> robotfuel, soo, ill use that machine! Ill try to remember to let you know when im done with it!
<mlankhorst> alcohol free only, sadly
<bschaefer> robotfuel, is there a quicker way of getting the ip of the machine then doing the kvm stuff?
 * bschaefer isn't sure where the list of IPs are
<robotfuel> bschaefer: the list is here https://wiki.canonical.com/UbuntuEngineering/QA/Lab
<bschaefer> robotfuel, i went there to go to the kvm to log into the machine to do ifconfig..geez
<bschaefer> robotfuel, thanks!
<kgunn> mlankhorst: than a good meal...
<kgunn> bschaefer: mlankhorst was able to pull the archive file from didier's machine....updated the bug here
<kgunn> https://bugs.launchpad.net/mir/+bug/1204939
<ubot5> Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (fails to find GL acceleration) (logind fails to track session?)" [Critical,Triaged]
<kgunn> brb
<bschaefer> kgunn, cool thanks
<mlankhorst> hm fun :P
<mlankhorst> a few wtf errors from compiz though
<mlankhorst> compiz (core) - Info: Unity is fully supported by your hardware.
<mlankhorst> compiz (core) - Info: Unity is not supported by your hardware. Enabling software rendering instead (slow).
<bschaefer> mlankhorst, usually means the driver didn't load hmm
<kgunn> racarr: any progress on surface-configurator for osk? (starting to build backpressure i think)
<kgunn> bschaefer: any luck repro'ing ?
<bschaefer> kgunn, just finished getting the kernel built and now I need to make sure I have the ppas set up
<kgunn> bschaefer: cool
<bschaefer> along with the setting that kernel option on the x86 defconf
<bschaefer> kgunn, soo hopefully soon :)
<kgunn> bschaefer: yeah...and you'll probably want to check that flag after you load it
 * kgunn remembers experiences of flag setting but it not really being set
<kgunn> flags on flags
<bschaefer> kgunn, i hope this doesn't happen to me...
<kgunn> :)) me too
<tvoss_> hello :)
<tvoss_> kgunn, bschaefer any new insights?
<bschaefer> tvoss_, getting the kernel setup right now
 * bschaefer got lost a bit in it
<tvoss_> bschaefer, ack
<bschaefer> I should have the flag set, and just need to update the kernel version, make sure im on the right ppas, then reboot and hope for the best
<tvoss_> bschaefer, okay, can you send a status mail to mircosmonauts when you eod?
<bschaefer> tvoss_, microsmonauts? And sure
<tvoss_> bschaefer, swap r and c
<bschaefer> tvoss_, im still not sure who that is :)
<tvoss_> bschaefer, some time back you looked into plain opengl support for raw-mir, right?
<bschaefer> tvoss_, right, and you can get an opengl context from egl
<bschaefer> which works
<bschaefer> tvoss_, tested with sdl1.2 and sdl2.0
<tvoss_> bschaefer, great, thank you
<bschaefer> tvoss_, np!
<tvoss_> bschaefer, is the code available somewhere?
<bschaefer> tvoss_, yup, its in the mir staging ppa :)
<bschaefer> tvoss_, hmm I wonder if any ABI has been broken though
<tvoss_> bschaefer, thx, mind pinging me the branches, too?
<bschaefer> tvoss_, will do
<racarr> qtubuntu uses a plain opengl context too on desktop
<robotfuel> I ran into this error again on intel using the s-c-t ppa (the in the unity-system-compositor.log) std::exception::what: Failed to set the current VT mode [boost::errinfo_errno_*] = 5, "Input/output error"
<tvoss_> kgunn, cross-check mir is in main?
<kgunn> tvoss_: yep
<tvoss_> kgunn, and usc is in universe?
<tvoss_> or not landed yet?
<kgunn> racarr: ooo, nice fun fact
<kgunn> tvoss_: u-s-c is only in daily-build ppa
<tvoss_> kgunn, ack
<robotfuel> reopening this bug https://bugs.launchpad.net/mir/+bug/1195509
<ubot5> Launchpad bug 1195509 in Unity System Compositor "System compositor fails to start - Failed to set the current VT mode: Input/output error (5)" [Critical,Confirmed]
<kgunn> robotfuel: best combo atm would be main (which has latest mir + xorg) & u-s-c from daily-build ppa
<robotfuel> kgunn: I'll test it with that. but we need it fixed in the s-c-t ppa for benchmarks
<kgunn> robotfuel: yes...i'm with you on the ppa being updated (thot it would be this morning ..but it wasn;t :-/)
<tvoss_> racarr, ping
<robotfuel> kgunn: will it be updated tomorrow? I really want to get those benchmarks up.
<kgunn> robotfuel: can we not go with main + u-s-c from daily-build ppa ?
<kgunn> the system-compositor-testing ppa will disappear as soon as we clear the ati bug
<kgunn> e.g....we'll be completely in main
<racarr> tvoss_: pong
<tvoss_> racarr, hey there :) can i ask you to write me a summary mail of your current design issue?
<robotfuel> kgunn: ok I'll use that for now.
<racarr> tvoss_: Yeah I've been thinking of asking you to talk about it actually...will write an email today
<tvoss_> racarr, yeah, let's just discuss it via mail. perhaps you can try to state the problem without class names first
<racarr> XD fun ok
<racarr> I don't feel as blocked on the existing two branches anymore but it's still a
<racarr> recurring problem I guess...
<racarr> we've started to have this "grand unified state problem" :p
<bschaefer> kgunn, hmm I still get a dependency problem from main xmir + u-s-c from daily build
 * bschaefer looks at downgrading
<bschaefer> kgunn, well looks like its using the libmir from daily-build
<kgunn> bschaefer: make sure your purged, unpinned, update/dist-upgraded....then you can rebuild u-s-c locally
<bschaefer> kgunn, yeah, I can do that as well, but im downgrading libmerserver0 to main from daily build so I can install u-s-c- from daily build
<bschaefer> *should* work
<kgunn> bschaefer: true...
<bschaefer> well still doesn't like it :), seems to want to upgrade the libmirserver0 anyway
 * bschaefer just builds u-s-c locally
<robotfuel> bschaefer: If I pin just the u-s-c package in the daily-build ppa, will xmir work? (after apt-get and dist-upgrade)
<kgunn> robotfuel: in theory
<robotfuel> ok I'll let you know how that goes
<bschaefer> robotfuel, it seems you'll have to build u-s-c your self...as Im getting a dependency error from daily-build
<bschaefer> for u-s-c
<bschaefer> on libmirserver0
 * bschaefer purges daily build and tries again
<kgunn> mlankhorst: tvoss_ ....to make sure i understand it all...is the xserver-xorg-video-ati that's in main coming from the source package located at https://code.launchpad.net/~mir-team/mir/xf86-video-ati-vladmir
<kgunn> ?
<tvoss_> kgunn, not sure, best to cross-check with bschaefer I would say
 * bschaefer looks
<bschaefer>   Installed: 1:7.1.0+git20130801.g2ae6bb1-0ubuntu4
<bschaefer> kgunn, I would like to think so, it says its stored on git
<bschaefer> kgunn, err...but thatbranch isn't on git hmm
<kgunn> bschaefer: right...its on lp/bzr...but i'm sure an upstream feeds it
<bschaefer> kgunn, yeah and this is what happens when i try to get source:
<bschaefer> http://paste.ubuntu.com/5960085/
<robotfuel> bschaefer: unity-system-compositor I want is  from the ppa:ubuntu-unity/daily-build-next?
<bschaefer> robotfuel, noo daily-build
<bschaefer> not next :)
<bschaefer> ppa:ubuntu-unity/daily-build
<bschaefer> so that ppa
<bschaefer> kgunn, i mean you should be able to pull the source with out a sudo :)
<bschaefer> opps
 * bschaefer was in a bad dir
<bschaefer> kgunn, it looks like it pulls the source from: git://git.debian.org/git/pkg-xorg/driver/xserver-xorg-video-ati
<kgunn> bschaefer: right...but there has to be an "xmir" patch on it
<bschaefer> kgunn, yeah with all this pretty xmir wrapping stuff
<kgunn> bschaefer: so  i did apt-cache policy which is i assume what you did ?
<kgunn> and it showed git likewise....
<bschaefer> yup, but is it the same as the launchpad branch?
<kgunn> however...if i do intel & nouveau...it doesn't have  git reference
<bschaefer> oo
<bschaefer> hmm I wonder if the ati wasn't moved?
<kgunn> wondering...are we chasing a packaging issue
<bschaefer> kgunn, that would be very awesome
<kgunn> bschaefer: can you double check apt-cache policy for intel/nouveau
<kgunn> and see what you think
<bschaefer> yup
<bschaefer> kgunn, yeah no git mention
<kgunn> tvoss_: if this is it ^ it deserves a "ffs"
 * bschaefer wishes didrocks, or some other packaging person worked during this time zone 
<kgunn> bschaefer: was just about to ask you ...who
<kgunn> :-/
<bschaefer> kgunn, yeeah, at this point hmm not sure :(
<kgunn> bschaefer: ok...first...can you repro the hang on "a" machine somewhere either local or in lexington ?
<bschaefer> kgunn, right, im trying one more time to get u-s-c from daily build if that fails ill just compile it my self
<bschaefer> reboot, confirm its hanging, then install my built kernel with this PROVE_LOCKING config enabled
<bschaefer> and try to get prove theres a deadlock
<kgunn> bschaefer: cool
<mlankhorst> kgunn: I'm using xserver-xorg-video-ati.git from debian
<kgunn> bschaefer: and secondary to that...i was thinking, pull video-ati debs from mir-team/staging....install those see what happens
<mlankhorst> oh pushed changes btw
<bschaefer> kgunn, good idea
<kgunn> AND/or rebuild from  https://code.launchpad.net/~mir-team/mir/xf86-video-ati-vladmir
<bschaefer> mlankhorst, but shouldn't it be using that launchpad branch?
<bschaefer> like intel/nouveau
<kgunn> mlankhorst: can you read our recent scrollback ?
<kgunn> we're suscpicious that what's in main doesn't have xmir patches ?
<mlankhorst> bschaefer: all packaging in the ubuntu archives are synced to ubuntu branch from debian git
<bschaefer> kgunn, that apt-get sources does in fact have the xmir patches
<bschaefer> mlankhorst, well shoot, still strange the intel/nouveau don't mention git
<mlankhorst> they do
<bschaefer> mlankhorst, when you apt-cache policy on them, its not pulling it from git
<bschaefer> the info
<bschaefer> the ones on main
<bschaefer> xserver-xorg-video-ati:
<bschaefer>   Installed: 1:7.1.0+git20130801.g2ae6bb1-0ubuntu4
<bschaefer> xserver-xorg-video-intel:
<bschaefer>   Installed: 2:2.21.12-1ubuntu1
<bschaefer> which is a bit strange why the atis name is so mangled
<mlankhorst> because it was a random snapshot of upstream git
<mlankhorst> if you enable saucy-proposed
<mlankhorst>      1:7.2.0-0ubuntu1 0
<mlankhorst>         500 http://archive.ubuntu.com/ubuntu/ saucy-proposed/main amd64 Packages
<mlankhorst>      1:7.1.0+git20130801.g2ae6bb1-0ubuntu4 0
<mlankhorst>         500 http://archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
<bschaefer> mlankhorst, which is the same package? ie. it wont fix anything using saucy-proposed...
<mlankhorst> I have no idea why xxv-ati is stuck in proposed atm
<bschaefer> hmm, but the one in main does have the xmir patch sooo I highly doubt its that package...just strange it was held back
<mlankhorst> ask in #ubuntu-devel I guess
<bschaefer> will do, thanks
<bschaefer> mlankhorst, soo also to enable that PROVE flag in the kernel, I added this in my kernel:
<bschaefer> linux-3.10.0/arch/x86/configs/x86_64_defconfig
<bschaefer> CONFIG_PROVE_LOCKING=y
<bschaefer> does that sounds about right to set that flag?
<mlankhorst> i dont know how the kernel team builds kernels and/or sets config parameters
<bschaefer> alright, just wanted to double check, cause hopefully I can test this out soon...
<kgunn> bschaefer: #ubuntu-kernel should know
<bschaefer> kgunn, I missed how you checked if it was hanging?
<bschaefer> kgunn, also: /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: xmir_get_drm_fd
<bschaefer> that sounds bad as well
<bschaefer> in lightdm/x-0.log
 * bschaefer checks didrocks bug
<kgunn> bschaefer: very
<bschaefer> kgunn, hmm but didrocks doesn't get that
<bschaefer> hmm I wonder if im doing something wrong? Im just using all main packages
<bschaefer> and u-s-c built from trunk
 * bschaefer wonders if thats a problem?
<bschaefer> hmm can't be u-s-c it was last updated with that disable input push...
<kgunn> bschaefer: i don't think so....but if you read the bug, seems RAOF and duflu elude failing to get a drm handle
<bschaefer>  hmm an undefined symbol is very strange to get all of sudden though...hmm
<bschaefer> and my Xorg.0.log is odd as well
 * bschaefer pastebins it
<bschaefer> hmm I also get this in it: [    12.731] (EE) Failed to load module "xmir" (module does not exist, 0)
<bschaefer> http://paste.ubuntu.com/5960193/
<bschaefer> kgunn, let me purge daily ppa
<bschaefer> possibly that could have caused an issue...
<kgunn> bschaefer: freaky enough...i had to load xorg-xmir yesterday
<kgunn> not completely sure why
<bschaefer> install it?
<kgunn> bschaefer: yep...meant install, apt-get install
<bschaefer> kgunn, o alright, I was thinking you could manually load it or something :)
<kgunn> bschaefer: yeah...strange...if you do apt-cache...it'll say candidate:blah...but installed:nothing
 * bschaefer is iinstalling xmir now
<bschaefer> strange
 * kgunn again wishes we had a north/south american version of didrocks
<bschaefer> kgunn, haha very true!
<bschaefer> kgunn, hmm from these logs atm the ati machine seems to be working? Wth...
 * bschaefer goes to log into the kvm
<bschaefer> urggg
<bschaefer> why do I see unity
<kgunn> bschaefer: are you local or lexington ?
<bschaefer> kgunn, lexington
<kgunn> bschaefer: can you verify ps aux | grep unity-system-comp
<kgunn> make sure you didn't fallback
<bschaefer> kgunn, forgot to do that :)
<bschaefer> its running :(
<kgunn> bschaefer: do we have any other radeon machines ?
<bschaefer> root       959  0.5  0.3 739224 30044 ?        Sl   20:24   0:00 /home/jenkins/staging/sbin/unity-system-compositor --enable-input=false --from-dm-fd 10 --to-dm-fd 13 --vt 7
<bschaefer> robotfuel, ^
<kgunn> bschaefer: if you want to try same config local before your EOD that would be interesting
<kgunn> ...so we got 3 data points
<bschaefer> kgunn, right, i still have 4-5 hours of my day :)
<kgunn> 1) didrocks otto machine 2) lexington machine#1 3) your local
<kgunn> it would be nice to have even more
<kgunn> all good data
<bschaefer> yes, I really really wished I could repro this
<kgunn> can you run glxinfo
<kgunn> and glxgears?
<bschaefer> kgunn, why does didrocks always get the bad machine?
<bschaefer> yup
<robotfuel> bschaefer: they are running tests right now, we have this one https://bugs.launchpad.net/xmir/+bug/1209000 that's trying the daily-build ppa now
<ubot5> Launchpad bug 1209000 in XMir "radeon hd7850 fails to load driver from system-compositor-testing ppa with gbm: failed to open any driver (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)failed to load driver: radeonsi" [Undecided,New]
<bschaefer> err let me run it
<bschaefer> robotfuel, alright, would we be able to switch machines at some point?
<bschaefer> when they finish?
<robotfuel> bschaefer: yes
<robotfuel> bschaefer: I'll let you know
<bschaefer> robotfuel, cool, as im done with that machine as it seems to be working ...
<bschaefer> kgunn, just to re-iterate
<bschaefer> kgunn, the problem occurs with libmirserver0 from main, and u-s-c built locally?
<kgunn> bschaefer: yep...please do
<bschaefer> on an ati machine?
<bschaefer> kgunn, as right now I have 0 ppas installed
<bschaefer> and xmir is working
<kgunn> bschaefer: good point....didrocks had all main + u-s-c from daily-build ppa
<kgunn> bschaefer: also we should not forget that you and i both had to install xorg-xmir
<bschaefer> kgunn, I couldn't install u-s-c from the daily-build ppa because of a dependency problem :(
<bschaefer> right that was strange as well...
<bschaefer> kgunn, but that could have come from doing the purge of u-s-c testing
<kgunn> bschaefer: jibel just joined...he might be able to get us onto the otto machine
 * bschaefer checks when u-s-c was rebuilt in daily-build
<bschaefer>  unity-system-compositor - 0.0.1+13.10.20130807.2-0ubuntu1 	(changes file) 	ps-jenkins (ps-jenkins: 235412) [ubuntu-bugcontrol] 	5 hours ago 	Published 	Saucy 	X11
<bschaefer> 5 hours ago hmm
<bschaefer> kgunn, i wonder if didrocks was able to use the version before? It shouldn't matter though... as u-s-c hasn't changed since 8-01
<bschaefer> hmm
 * bschaefer doesn't know how he got u-s-c to only install it self from daily-build ppa
<kgunn> bschaefer: ok...just now, updated to ensure..i'm using main + daily build ppa for usc....rebooting
<bschaefer> hmm u-s-c from daily build vs local build cannot be the problem...as trunk hasn't updated since last Thursday ...
<bschaefer> kgunn, the only thing that might be different, is if you hav ethe daily build ppa and upgrade some libmir packages...hmm
<kgunn> bschaefer: ok i rebooted just fine
<bschaefer> kgunn, you're on an ati?
<kgunn> bschaefer: no intel....but go no complaints about mismatch either
<bschaefer> kgunn, you were getting that before?
<kgunn> bschaefer: nope but thot you were
<bschaefer> kgunn, o that abi stuff went away ... when I installed xorg-xmir :)
<kgunn> bschaefer: for clarity sake...my steps purged/unpinned (days ago), apt-get update/dist-upgrade, then....i download the deb file from the ppa site....and do dpkg -i on unity-system-comp.deb
<bschaefer> and you can install u-s-c from daily build?
<bschaefer>  unity-system-compositor : Depends: libmirserver0 (= 0.0.8+13.10.20130807.2-0ubuntu1) but 0.0.8+13.10.20130807.1-0ubuntu1 is to be installed
<bschaefer> oo
<bschaefer> kgunn, see I was add-apt-repos on the ppa
<bschaefer> and tried to install unity-system-compositor
 * bschaefer purges daily build and tries that
<bschaefer> kgunn, so you do not have daily build ppa installed right?
<kgunn> bschaefer: right...i only cherry pick u-s-c off the daily-build ppa website
<bschaefer> kgunn, i didn't even know you could do that :)
 * bschaefer grabs is
<bschaefer> it*
 * kgunn been hanging out with shady folk like robert_ancell
<bschaefer> haha
<kgunn> bschaefer: do you know the command line to get the deb patch file applied to the source ?
<bschaefer> kgunn, still get a dependency error :(
<bschaefer> kgunn, well you should just be able to do a dget, and from the use dpkg-buildpackage -us -uc
<bschaefer> and then install the *.deb
<kgunn> bschaefer: when you dpkg -i install it'll gripe about runtime deps....it should be ok
<kgunn> not build time deps
<kgunn> what did it whine about ?
<bschaefer> o hmm
 * bschaefer pastebins
<bschaefer> http://paste.ubuntu.com/5960302/
<bschaefer> kgunn, it says its installed through though policy
 * bschaefer tries it out
<kgunn> bschaefer: hmmm...i get all the other whining except lines 7-14 in your pastebin
<kgunn> bschaefer: make sure you've purged, unpinned, updated, dist-upgraded, then dpkg install u-s-c
 * bschaefer goes to make sure
 * kgunn glad to see in pastebin someone else forgets sudo on dpkg install....
 * kgunn does it every _single_ time
<bschaefer> haha
<bschaefer> didn't mean to copy that much info!
<kgunn> robotfuel: wrt this bug https://bugs.launchpad.net/xmir/+bug/1209000
<ubot5> Launchpad bug 1209000 in XMir "radeon hd7850 fails to load driver from system-compositor-testing ppa with gbm: failed to open any driver (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)failed to load driver: radeonsi" [Undecided,New]
<kgunn> would you mind adding the /var/log/lightdm/* & /var/log/Xorg*
<kgunn> robotfuel: actually....only if you can run on main(mir/xorg) + daily-build(u-s-c) ....note not daily-build-next :)
<kgunn> jibel:
<robotfuel> kgunn: ok, main(mir/xorg) + daily-build(u-s-c) fails due to packaging
<kgunn> jibel: oops..meant to ask...could we get on otto ? or is it busy?
<robotfuel> kgunn: there is another issue with that system, without the xorg stuff it's super slow
<robotfuel> * 3d accel is slow
<kgunn> robotfuel: so it the machine suspect ?
<bschaefer> kgunn, hmm I also can't rebuild u-s-c when just using main
<robotfuel> kgunn: it seems like a bug in the driver
<bschaefer> http://paste.ubuntu.com/5960342/
<bschaefer> eek
<bschaefer> missing mirserver-dev
<robotfuel> kgunn: I am writing a bug now for the slowness in the regular xorg driver
<kgunn> bschaefer: ...yeah, i noticed that a couple of hours ago....don't know how daily-build built it 5 hours ago...nothing changed ?
<kgunn> bschaefer: ah
<bschaefer> kgunn, yeah...it causing fun problems for me :(
<bschaefer> http://paste.ubuntu.com/5960347/
<bschaefer> kgunn, which is what dpkg was complaining about
 * bschaefer wonders what else was rebuild in daily build
<bschaefer> kgunn,  mir - 0.0.8+13.10.20130807.3-0ubuntu1
<bschaefer> was rebuilt 4 hours ago
<bschaefer> and u-s-c was rebuilt 5 hours ago...soo u-s-c I think needs to be rebuilt...
<robert_ancell> bschaefer, bug 1209104. Fixed now
<ubot5> bug 1209104 in mir (Ubuntu) "libmirplatform headers not packaged" [Undecided,New] https://launchpad.net/bugs/1209104
<robert_ancell> brb
 * bschaefer guesses it hasen't made it to main yet...
<bschaefer> robert_ancell, well thats good, but im trying to cherry pick u-s-c from daily-build ppa to test out a very bad ati bug :(
<robert_ancell> bschaefer, I'm just updating the system-compositor-testing PPA right now, not sure if that helps (that bug was blocking it)
<bschaefer> robert_ancell, sadly it has to make it to main, as im trying to track down a possible deadlock in the kernel :(
<bschaefer> robert_ancell, and trying to follow how didrocks reproed it, and cant...
<bschaefer> kgunn, soo should I try using the daily build ppa for now to see if I can repro it?
<kgunn> bschaefer: do you mean
<kgunn> bschaefer:  main(mir/xorg) + daily-build(u-s-c)
<bschaefer> kgunn, can't get u-s-c to work with daily-build due to dependency problems
<bschaefer> but if I do daily build (mir/xorg) I can build u-s-c my self
<kgunn> bschaefer: so weird...i don't get that
<bschaefer> kgunn, as mir was rebuilt in daily build 4 hours ago, and u-s-c  was rebuilt 6 hours ago :(
 * bschaefer attempts to install it again
<robert_ancell> bschaefer, which bzr versions do you need to test?
<kgunn> bschaefer: yeah...but then you're combo would just need to be  main(mir/xorg) + "locally built"(u-s-c)
<bschaefer>  unity-system-compositor : Depends: libmirserver0 (= 0.0.8+13.10.20130807.2-0ubuntu1) but 0.0.8+13.10.20130807.1-0ubuntu1 is to be installed
<bschaefer> robert_ancell, hmm I need those mir header fixed so I build u-s-c locally, can I build those headers locally as well?
<bschaefer> or is that part of the libmirserver?
<robert_ancell> bschaefer, yes, part of libmirserver
<bschaefer> shoot, and at the point I would just be rebuilding libmirserver from trunk which we are trying to use it from main, for some reason?
<bschaefer> s/the/that
<robert_ancell> bschaefer, if you need both the latest of mir and u-s-c, you should be able to use the system-compositor-testing PPA, which is just updating now
<bschaefer> robert_ancell, hmm I should have gotten more info out of didrocks :)
<bschaefer> robert_ancell, ill give that a try when its finished
<bschaefer> kgunn, whats your version os libmirserver0?
<bschaefer> of*
<kgunn> Installed: 0.0.8+13.10.20130807.1-0ubuntu1
<bschaefer> strange...cause u-s-c seems to depend on:
<bschaefer>  unity-system-compositor : Depends: libmirserver0 (= 0.0.8+13.10.20130807.2-0ubuntu1) but 0.0.8+13.10.20130807.3-0ubuntu1 is to be installed
<bschaefer> the *7.2*
 * bschaefer is on the daily build ppa
<bschaefer> well I should at lease be able to build u-s-c from trunk, and give it another test
<kgunn> bschaefer: yep...gonna try to build now too
<bschaefer> dam my 10*.conf was removed...gotta remove it ..
<kgunn> robert_ancell: so when i try to build u-s-c it says "fatal error: mir/options/program_option.h: No such file or directory"
<robert_ancell> kgunn, right, that was broken in alan_g 's change to split out libraries
<robert_ancell> it's fixed now
<robert_ancell> see bug 1209104
<ubot5> bug 1209104 in mir (Ubuntu) "libmirplatform headers not packaged" [Undecided,New] https://launchpad.net/bugs/1209104
<bschaefer> kgunn, yup, but it hasn't made it into main
<bschaefer> and I don't think it will very shortly
<kgunn> roger tha
<kgunn> that
<bschaefer> kgunn, soo, im rebooting using daily build mir + local built u-s-c
 * bschaefer think u-s-c just needs to be rebuilt in daily build ppa
<bschaefer> robert_ancell, could we do that with out having to push a new package?
<robert_ancell> bschaefer, once it's built you have to upload a new one
<bschaefer> dang
<robert_ancell> oh, hang on, in jenkins?
<bschaefer> o well, locally built is no different then the ppa
<robert_ancell> I'm just having a look, but I don't know how to trigger rebuilds
<bschaefer> robert_ancell, i mean in the daily build ppa
<robert_ancell> thomi, do you know?
<thomi> otp, one minute
<robert_ancell> bschaefer, ppa:ubuntu-unity/daily-build?
<bschaefer> robert_ancell, yup
<kgunn> bschaefer: https://pastebin.canonical.com/95607/
<kgunn> just to be sure...that's what i get when i cherry pick...and it still seems to work
<bschaefer> soo daily build mir + locally built u-s-c works fine on ATI
<bschaefer> kgunn, why do we have to use main?
<bschaefer> isn't daily-build about to be pushed to main?
<kgunn> bschaefer: yes...you are right
<robert_ancell> bschaefer, kgunn, system-compositor-testing should now be up to date for amd64 and i386
<kgunn> robert_ancell: thanks
<bschaefer> robert_ancell, thanks, ill test that out now
<kgunn> w/ no vt switching ?
<bschaefer> kgunn, vt was broken yesterday as well :(
<bschaefer> I think duflu was looking into it but im not sure
<kgunn> bschaefer: yeah...there's like 4 MPs that all need to hit
<bschaefer> kgunn, cool, hmm soo off to test u-s-c
<kgunn> bschaefer: when you said "daily build mir + locally built u-s-c works fine on ATI"
<bschaefer> though I know didrocks isn't going to be happy we can't repro this, as he will be able to as soon as he wakes up
<robert_ancell> kgunn, just landed th efirst one
<kgunn> you meant the lexington machine ?
<bschaefer> kgunn, right
<bschaefer> kgunn, i still need to wipe my HD to install ubuntu
<bschaefer> its having problems partitioning it still
<kgunn> bschaefer: yeah...best bet to do that, another data point
<bschaefer> which I can do when I go eat lunch at some point
<bschaefer> kgunn, yup, let me test u-s-c out then go do that
<kgunn> robert_ancell: RAOF's got an ati card right ?
<robert_ancell> kgunn, yes
<kgunn> can you get him to test as well....
<kgunn> seems we may be back to didrock's "otto" machine
<kgunn> taking this all very personally :)
<bschaefer> kgunn, we should break didrocks machine, its the only one that gets angry!
<bschaefer> (joking)
<kgunn> robert_ancell: so if bschaefer can run on his local ati, and RAOF can run on his....can you please arrange something with didier to debug his morning (this may mean asking RAOF to stay late)....but i'm at a loss
<robert_ancell> kgunn, is this the existing bug?
<kgunn> https://bugs.launchpad.net/mir/+bug/1204939
<ubot5> Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (fails to find GL acceleration) (logind fails to track session?)" [Critical,Triaged]
<bschaefer> as soon as we can reproduce this, we still nee to recompile the kernel with the PROVE_LOCKING enabled
<bschaefer> just to see if its deadlocking or not
<kgunn> bschaefer: right....right now, we're hunting for reproduction
<kgunn> otherwise deadlock is only interesting on didrocks machine
<bschaefer> kgunn, yeeah, which sucks :(, I would love to try to actually solve the issue
<bschaefer> yeah
<robotfuel> robert_ancell: do you know who I can ping about this bug https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1209397? maybe it's the radeon driver doesn't support the 7850 card?
<ubot5> Launchpad bug 1209397 in xserver-xorg-video-ati (Ubuntu) "radeon hd7850 has no 3d acceleration" [Undecided,New]
<bschaefer> kgunn, also, where do you see the hanging problem?
<bschaefer> kgunn, with didrocks machine, his logs arne't showing much of an ERROR
<kgunn> bschaefer: correct...he was the one with the hang/only resulted in kernel panic when he tried to relaunch x
<robert_ancell> robotfuel, opt, be back in 5
<kgunn> robotfuel: that might be better for mlankhorst to help with
<bschaefer> kgunn, soo otherwise it works? ... hmm as im trying to see maybe iam getting the problem but i don't see it?
<bschaefer> as looking at his logs, xmir did start up (from what I can tell with out looking at a vm)
 * bschaefer assumed a deadlock would cause xmir to not start up at all
<bschaefer> well I have hardware acceleration sooo hmm
<bschaefer> and xmir is running ...
<bschaefer> robert_ancell, cool, and I can install u-s-c from the testing ppa
<robert_ancell> robotfuel, RAOF would know
<robotfuel> robert_ancell: he is in a  european timezone?
<robert_ancell> robotfuel, australian, he will be on in ~1:10
<robotfuel> robert_ancell: cool I will ask then :)
<bschaefer> kgunn, well im going to eat some lunch and reformat my ati machine to get ubuntu on it
<kgunn> cool
<bschaefer> u-s-c testing ppa is working with ATI card as well, and I have hardware acceleration
<bschaefer> same with daily build ppa
<bschaefer> soo so far ati is not having a problem loading GL acceleration that I see
<bschaefer> kgunn, whooa
<bschaefer> compiz (core) - Info: Unity is fully supported by your hardware.
<bschaefer> compiz (core) - Info: Unity is not supported by your hardware. Enabling software rendering instead (slow).
<bschaefer> kgunn, un my ~/.cache/upstart/gnome-session
<bschaefer> which is very strange, cause I m running opengl for sure, as things are getting blured (the dash/launcher/hud)
<bschaefer> kgunn, seems that has happened before* now its fine ... hmm wellim going to set up my ati machine and see what I can find
 * bschaefer goes to eat some food
<kgunn> bschaefer: sounds good
<robert_ancell> kgunn, can you also confirm the s-c-t PPA works for you?
<kgunn> robert_ancell: sure...lemme try now
<robert_ancell> brb
<kgunn> robert_ancell: good to go...s-c-t ppa worked for me
<robert_ancell> \o/
<robert_ancell> Now to fix VT switching..
<robotfuel> robert_ancell: the s-c-t worked for me openarena passed on it
<robotfuel> on a radeon 7450
<robert_ancell> robotfuel, is that the radeon that was having trouble?
<robotfuel> robert_ancell: no that was the 7850 that has problems, didrocks has a different version as well
<kgunn> robotfuel: right but your 7850 had problems with standalone X as well ??
<robotfuel> kgunn: yes, it has no 3d accel
<robotfuel> kgunn: will xmir work with the non-free ati drivers?
<robotfuel> catalyst driver
<kgunn> robotfuel: nope...only free drivers
<bschaefer> kgunn, sweet, it installed successfully this time, you were right about not yelling out it
 * bschaefer goes to update things
<RAOF> robotfuel: Yo?
<robotfuel> RAOF: I have this bug,  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1209397 I am thinking it might be the radeon driver doesn't support the 7850 card?
<ubot5> Launchpad bug 1209397 in xserver-xorg-video-ati (Ubuntu) "radeon hd7850 has no 3d acceleration" [Undecided,New]
<RAOF> robotfuel: Ah, yes. The 7850 is a southern islands card which requires glamor to do 2D acceleration and requires 2D acceleration to do 3D accel, and we don't currently build glamor.
<robert_ancell> robotfuel, so bug 1209000 is fixed or still occurring?
<ubot5> bug 1209000 in XMir "radeon hd7850 fails to load driver from system-compositor-testing ppa with gbm: failed to open any driver (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)failed to load driver: radeonsi" [Undecided,New] https://launchpad.net/bugs/1209000
<kgunn> bschaefer: good to hear...can't wait for the results
<robotfuel> robert_ancell: I haven't tried it with the newest s-c-t ppa, but I think it will fail because there is no 3d
<RAOF> Huh. I'm not sure why it's failing to find radeonsi?
<robotfuel> robert_ancell: I just kicked off a test run so we will know in about 10 minutes
<robert_ancell> robotfuel, nice
<bschaefer> RAOF, well does it exist in the path its looking for?
<robotfuel> robert_ancell: there is a new mir jenkins server here http://10.97.2.12:8080/
<bschaefer> kgunn, as am i...
<RAOF> bschaefer: On my system, yes.
<robert_ancell> robotfuel, that is running the tests on the new hardware?
<robotfuel> robert_ancell: yes, we are still waiting for 1 machine
<bschaefer> robotfuel, have you been able to check if the file is located on one of those paths?
<bschaefer> possibly it got installed to the wrong spot?
<robert_ancell> robotfuel, nice work! Loving it's mostly green :)
<robert_ancell> thomi, now we just need some nice graphs..
<thomi> robert_ancell: right. robert_ancell, I understand that there's work being merged into the dashboard to support that>?
<thomi> robert_ancell: BTW, I realise I never answered your question from before - is it still open?
<robotfuel> robert_ancell: thomi I have some older graphs here http://10.97.9.23:8002/graphics/
<robert_ancell> thomi, open? It seems to have rebuilt 4mins ago
<thomi> robert_ancell: ok, good
<thomi> robert_ancell: right, but we want it in the dashboard. I think Francis said there was work being merged to support that?>
<robotfuel> thomi: yes, I am working on that too
<thomi> robotfuel: I see now - that's the staging isntance?
<robotfuel> thomi: yes
<robotfuel> thomi: it doesn't have the stuff from the new jenkins server in it.
<thomi> yeah
<thomi> and we probably need to clean up the data a bit before publishing it
<thomi> but otherwise, it look sgood
<robert_ancell> robotfuel, oh, now I see why it's all green - the xmir jobs haven't completed :)
<robotfuel> robert_ancell: this is a bug again https://bugs.launchpad.net/mir/+bug/1195509
<ubot5> Launchpad bug 1195509 in Unity System Compositor "System compositor fails to start - Failed to set the current VT mode: Input/output error (5)" [Critical,Confirmed]
<robotfuel> it was fixed for a little while it seems
<robert_ancell> robotfuel, yes, we think it will be fixed with https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/177800, but we need to fix the VT switch keys first. That's the four MPs kgunn was talking about
<robert_ancell> kgunn, btw I just pushed the updated mir to main
<kgunn> robert_ancell: cool...sounds very powerful
<bschaefer> yay
<robert_ancell> ROAR!
 * racarr GONG
 * RAOF TING
<robert_ancell> racarr, did you talk to kdub? He was looking for you
<robert_ancell> mlankhorst, ping
<racarr> robert_ancell: Not yet :)
<racarr> kdub: I was just getting ready to digest how all your changes went
<racarr> and am now participating in leak testing because apparently the shop downstairs has water spots
<robotfuel> I am getting a new failure on the radeon hd7850 with xmir /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: exaGetPixmapDriverPrivate
<kdub> racarr, ah, ok. hopefully i have my focus changes out the door soon
<robert_ancell> racarr, that wasn't the leak testing I was expecting :)
<robert_ancell> RAOF, ^
<robotfuel> that's with the s-c-t ppa
<robotfuel> I'll have a bug up shortly
<RAOF> robotfuel: Well, that would be because it hasn't loaded the EXA module, which is perfectly reasonable :)
<kdub> racarr, pretty much, i've detangled create_surface_for (almost) which lets you control better when you get focused event
<RAOF> What's not reasonable is that it's trying to resolve EXA symbols.
 * RAOF notes that there isn't any X in s-c-t; it's all in the archive.
<racarr> kdub: Excellent.
<racarr> new MP today you are hoping?
<robotfuel> it's running in failsafe mode now, it tried starting X 2 times.
<RAOF> robotfuel: My expectation is that a 7850 would not work correctly with the free driver at the moment, XMir or not.
<robotfuel> RAOF: robert_ancell: do we want to make the radeon 7850 work? with xmir we can drop that hardware from the test plan, but also have document that the card doesn't work with bugs.
<RAOF> robotfuel: I think we should make the 7850 work; it' just not an xmir issue that it doesn't.
<robert_ancell> robotfuel, we just need to match the existing X behaviour. So if it doesn't work currently, then it should continue not to work.
<robert_ancell> robotfuel, in saying that - if we make it worse, we should blacklist that card and test it correctly falls back to non-xmir behaviour
<bschaefer> kgunn, soo, its working :)
<bschaefer> mir/xorg from main + cherry pick u-s-c from daily build
 * bschaefer digs through logs to make sure hard ware acceleration is on...but it seems to be
<bschaefer> kgunn, soo to sum up today...it appears to be working on 2 ati machines...
<bschaefer> RAOF, ping
<RAOF> bschaefer: Pong.
<bschaefer> RAOF, hello, did you still have your other ati machine up and running?
<RAOF> Yeah, my 4350.
<RAOF> XMir worked on that yesterday.
<bschaefer> RAOF, hmm well you already commented on the bug, the logind one
<bschaefer> https://bugs.launchpad.net/mir/+bug/1204939
<ubot5> Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (fails to find GL acceleration) (logind fails to track session?)" [Critical,Triaged]
<bschaefer> RAOF, i've been looking at it for the most the day, and both the ATI machines I've used have worked with xmir
<bschaefer> if you had a chance to test it out, didrocks was running a bad problem this morning, possibly a deadlock in the kernel
<bschaefer> running into*
#ubuntu-mir 2013-08-08
<RAOF> I'll fire up the ati system again.
<bschaefer> RAOF, thanks, kgunn just wanted another working xmir data point, so for 1 is failing and 2 are working
<bschaefer> s/for/far ... geez
<RAOF> Heh
 * robert_ancell -> lunch
<kdub> my 1tb harddrive is 80% full of compiled mir code... bzr -_-
<kgunn> RAOF: can you please ping didrocks when he comes online & try to help resolve his ati issue...its our last blocker
<RAOF> kgunn: Sure.
<RAOF> kdub: cd ~/.bazaar/plugins; bzr branch lp:bzr-removable ; cd ~/Devel/Mir ; for I in $(bzr removable trunk ) ; do rm -r $I ; done âº
<kdub> RAOF, hmm, might give it a try!
<RAOF> kdub: bzr-removable adds the "removable" command; in a repository, you give it a branch and it'll tell you all the branches in the repository which have been merged into that branch.
<kdub> ah, that would be useful
<RAOF> It also adds the "unremovable" command, which does the reverse, and tells you why it's not removable
 * RAOF might get around to adding a "-d" option to it, so that âbzr removable -d trunkâ would delete all the branches that have been merged into trunk
 * RAOF books travel to Boston
<RAOF> bschaefer: Yup; My ati box still works with unity-system-compositor
<bschaefer> RAOF, thanks
<RAOF> Now; does this XMir populate xrandr data?
<bschaefer> RAOF, where would one check for this data?
<bschaefer> i see this in my syslog: Aug  7 16:30:51 bschaefer-GA-870A-UD3 colord: Device added: xrandr-XMIR-1
<RAOF> bschaefer: Oh, your XMir definitely doesn't. I'm just hooking up the new Mir multi-head API.
<bschaefer> oo cool, though im not sure what that is :)
<RAOF> xrandr will report the full set of modes your outputs can do, rather than just the single mode Mir set on startup :)
<bschaefer> RAOF, oo nice, yeah, i've just been stealing mir_connection_get_display_info ... and using the width/height for what I think mir can display
<RAOF> Yeah. You'll need to switch to mir_connection_create_display_config() at some point âº
<bschaefer> sweet, yeah I saw that in the egl examples yesterday, now that makes much more sense :)
<RAOF> Yeah. Make sure you check the most recent egl examples; I fixed a thinko in them yesterday :)
<TheDrums> Sorry for the question, but are there any major changes since the last PPA build in this one?  Drivers, Mir, Xorg u-s-c?  And lastly, I'd guess 0.0.9 is still out several weeks?
<bschaefer> cool, yeah I need to go back and update some of my branches... I think the ABI might have changed as well
<RAOF> bschaefer: The client ABI shouldn't have changed. If it did, please hit us with a stick.
<RAOF> The server ABI is... not yet âº
<bschaefer> RAOF, haha, will do
<bschaefer> I think the last time was ... the swap buffers call
<bschaefer> it use to be mir_connection_next_buffer or something?
<bschaefer> but that was a while ago...
<RAOF> Ah, yes. We did change that.
<RAOF> That was a while ago.
<RAOF> Woot! We have xrandr info.
<bschaefer> yes it was, I just haven't re-compiled my branch in sometime :)
<bschaefer> :)
<RAOF> Although I should probably try it on something that isn't this laptop, as it only supports 1920x1080, which makes the mode list somewhat short!
<bschaefer> that could help haha
<robert_ancell> duflu, RAOF etc, can you review https://code.launchpad.net/~robert-ancell/mir/vt-switch-keys/+merge/179067?
<robert_ancell> would like to knock out the VT issues today
<RAOF> robert_ancell: Looks like you've still got some debug printfs in there?
<robert_ancell> RAOF, ah, missed one
<RAOF> Quite a few, it seems?
<RAOF> 51, 87, 126...
<robert_ancell> RAOF, ah, no I just didn't push the last commit
<robert_ancell> the "clean this up for merging" commit
<RAOF> :)
<RAOF> Also, what is KEY_L?
<duflu> robert_ancell, yep
<robert_ancell> RAOF, also debug and also removed
<RAOF> Good, good.
<robert_ancell> RAOF, I needed to check I wasn't hitting the existing alt+ctrl+Fn keys
<RAOF> Yeah, fair suck of the saz.
<RAOF> sav
<RAOF> robert_ancell: Hm. Why are you explicitly initialising a std::initialiser_list?
<robert_ancell> RAOF, because std::make_shared seems to get confused
<RAOF> Ah, if you just do ...({vt_filter})?
<robert_ancell> RAOF, because the it treats it as a std::initializer_list<std::shared_ptr<VTFilter>> not, std::initializer_list<std::shared_ptr<mi::EventFilter>>
<RAOF> Urgh.
<robert_ancell> yes
<robert_ancell> spent a lot of time trying to understand the error message
<RAOF> export CC=clang; export CXX=clang++ in ~/.bashrc makes that much easier :)
<duflu> Hey, Ctrl+Alt+Backspace is a much cleaner shutdown than Ctrl+C was. I wonder how much we should still worry about our signal handling...
<RAOF> robert_ancell: Hm. That doesn't VT switch correctly for me - or, at least, it does vt switch but then immediately switches back.
<RAOF> robert_ancell: Does it require https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/177800 ?
<robert_ancell> RAOF, yeah, I saw something similar. It goes away with setsid
<duflu> robert_ancell: I knew I would have to test with setsid. Does a prereq somewhere make sense?
<RAOF> Yes.
<robert_ancell> duflu, I don't think it's strictly required, though I would land it next
<duflu> robert_ancell: I'm finding similar issues with three of my branches right now... Behaviourally they are quite dependent, but diff-ly they are separate :/
<RAOF> As long as we land both at approximately the same time it's ok.
<RAOF> Ideally we'd land setsid and vt-switch-keys atomically, though.
<duflu> RAOF: Atomicity can only be guaranteed by telling people not to pull from trunk for a while, I guess
<RAOF> No, it can also be guaranteed by merging the two branches and landing them as one?
<duflu> RAOF: Other than that, which clearly we're trying to avoid
<duflu> That said, I'm already building/testing them together
<RAOF> It's not clear to me that we're trying to avoid that?
<RAOF> Anyway, +1 on vt-switch-keys and +1 on setsid.
<duflu> robert_ancell, hangout?
<robert_ancell> duflu, syre
<robert_ancell> thomi, weird thing - https://launchpadlibrarian.net/147042471/buildlog_ubuntu-saucy-i386.mir_0.0.8%2B13.10.20130807.3bzr943saucy0_FAILEDTOBUILD.txt.gz
<robert_ancell> Fails to build (I saw it locally too). But doesn't occur when the CI builds occur
<robert_ancell> And the error seems quite straight forward - just missing #import <iostream>
<thomi> hmmmm
<thomi> that is odd
<thomi> you'd expect them both to fail
<robert_ancell> yeah. When I build locally with ./native-compile.sh it works, but not when using debuild
<robert_ancell> Maybe debuild sets some cflags and normally it's just  a warning, but for debuild it's an error
<robert_ancell> -Wbe-pedantic-about-std-cerr
<thomi> robert_ancell: perhaps locally one of the other header files #include's iostream, but the version in the package build env is older, and doesn't?
<robert_ancell> hah, looks like I broke it in a previous merge. The CI just didn't pick it up
<robert_ancell> actually it was alf, when he finished off my alt+ctrl+backspace branch
<thomi> robert_ancell: should we add that flag to the builds?
<robert_ancell> thomi, We probably should if you can work it out.
<thomi> robert_ancell: or rather, can you add it to the standard compile flags?
<robert_ancell> thomi, don't the builds run debuild anyway?
<thomi> robert_ancell: yeah, I'm not sure what's going on
<thomi> hmmm.. perhaps the pkg builds override CXXFLAGS?
<robert_ancell> thomi, can you review https://code.launchpad.net/~robert-ancell/mir/missing-import/+merge/179092
 * robert_ancell shrugs
<thomi> sure
<robert_ancell> guess we wait until it happens a second time before spending too much time fixing it
<thomi> robert_ancell: BTW, did you want a copy of my travel plans for Boston -> AKL so you have a travelling companion on the way home?>
<thomi> or are you so sick of me now that you'd like my flight details so you can deliberately plan a different route? :P
<robert_ancell> heading out - be back in an hour
<robert_ancell> thomi, sure, forward them
<robert_ancell> ta
<thomi> robert_ancell: OK, jobs are all kicked off again for the next test run
<tvoss_> good morning :)
<thomi> hi tvoss_, how's life?
<tvoss_> thomi, pretty good :) how is life on your side?
<thomi> tvoss_: still getting over the jetlag, but otherwise good
<thomi> thinking about investing in a pottery wheel... ;)
<tvoss_> thomi, having a pottery wheel around is always a good idea
<tvoss_> ;)
<thomi> gotta get some practise in, before the international competition
<thomi> I gotta head out, will be back later for late calls.
<RAOF> Hm. There is no problem that can't be fixed with another layer of indirection!
<tvoss_> RAOF, for sure :)
<Mirv> hmm, I wonder if this https://launchpadlibrarian.net/147032204/buildlog_ubuntu-saucy-armhf.mir_0.0.8%2B13.10.20130808-0ubuntu1_FAILEDTOBUILD.txt.gz is something already taken care of?
<Mirv> demo_inprocess_surface_client.cpp:58:27: error: 'cerr' is not a member of 'std'
<RAOF> Mirv: robert_ancell was just talking about that
<Mirv> ah, I see
<Mirv> and approved, nice, I'll rerun the stack when it has been merged
<Mirv> ok, rerunning
<Mirv> well, unity got there first, might take some time..
<RAOF> thomi: Could you kindly turn off the autolanding for mesa into the staging ppa.
<RAOF> didrocks: Yo!
<didrocks> RAOF: hey!
<RAOF> didrocks: I understand you've got a kernel backtrace for the ati system of death?
<didrocks> RAOF: I don't have a kernel backtrace AFAIK. All the traces were pasted on IRC.
<tvoss_> didrocks, jibel pasted the original kernel tr
<tvoss_> bt
<tvoss_> didrocks, RAOF browser-history ftw: http://paste.ubuntu.com/5959277/
<RAOF> Hm. That's interesting.
<RAOF> didrocks, tvoss_: So, that backtrace has Xorg as the controlling process of the CPU that wedged; it's calling drm_mode_setcrtc, which means that it's not running under unity-system-compositor.
<tvoss_> RAOF, hah
<didrocks> RAOF: right, so we had one run with u-s-c
<didrocks> which starts, but compiz never finished its init
<didrocks> (blocked on opengl plugin)
<didrocks> then, we restart without u-s-c/Mir, under raw Xorg
<didrocks> and this is what happens ^
<tvoss_> didrocks, this is a very wild guess, but could we update the machine's bios?
<didrocks> tvoss_: that doesn't change that the previous run failed
<didrocks> the machine blocking is a consequence
<robert_ancell> could we accidentally drop that machine out the window?
<RAOF> didrocks: How do you restart without u-s-c? Is a reboot involved, or a tweak of lightdm.conf.d + a lightdm restart?
 * didrocks wants to accidentally drop doko out the window
<didrocks> RAOF: new install, other stack to tests
<RAOF> didrocks: So, a reboot?
<didrocks> RAOF: without any reboot
<didrocks> it's a lxc container
<RAOF> Ah, ok. Right.
<didrocks> so the previous run (with u-s-c failing) was ended
<didrocks> then, another one for another stack with regular Xorg
<RAOF> So that would mean the blocking problem is likely to be a failure to clean up u-s-c properly on lightdm shutdown.
<RAOF> And then there's the problem of u-s-c failing in the first place.
<didrocks> right
<didrocks> (only on ati)
<tvoss_> robert_ancell, +1
<didrocks> intel with the same packages works perfectly
<robert_ancell> RAOF, could I ask you a favour? I need to do family things before coming back tonight - can you watch https://launchpad.net/~mir-team/+archive/staging/+build/4859513 and when that completes copy (without rebuild) mir 0.0.8+13.10.20130807.3bzr944saucy0  from the staging PPA to the system-compositor-testing PPA?
<RAOF> robert_ancell: Ok.
<robert_ancell> Then follow up with u-s-c rev 40 when that autolands (with rebuild)
<RAOF> Sure.
<robert_ancell> I'm in fear that by the time I come back and new revision will have landed and wipe out the build :/
<RAOF> :)
<RAOF> didrocks: I don't suppose it's possible to log into that box while it's running the test?
<didrocks> RAOF: we can, just not now
<didrocks> doko broke Qt5â¦
<RAOF> K
<didrocks> need to fix that first
 * RAOF goes back to xrandr hotplug
<duflu> RAOF: I suspect I had the Xdamage/Compiz argument backwards. Some Compiz plugins actually expect and require that they be able to spuriously render outside the damage region, and that it only looks *right* if you show the damage region (hide overdraw).
<duflu> So that was mostly fixed when we enabled page flipping. And would be more fixed by using regional logic again
<RAOF> duflu: You mean they render *incorrectly* outside the damage region, and expect any rendering outside the damage region to be invisible?
<duflu> RAOF: Yes
<RAOF> That's messed up.
<duflu> RAOF: Most of the obvious occurrences were fixed last year, but not all
<duflu> RAOF: unityshell too :P
<RAOF> Also, XMir will display any rendering they do.
<RAOF> Because XMir sees the damage that *compiz* does.
<RAOF> Oh. I guess unless compiz does partial frontbuffer updates.
<duflu> RAOF: Yes, that's just a CCSM tickbox away
<RAOF> In which case XMir will just see the bits of the frontbuffer you updated.
<duflu> RAOF: Just untick everything except sync_to_vblank in CCSM>OpenGL
<RAOF> Frankly I'd prefer to just show the broken rendering and fix it.
<duflu> RAOF: I don't think you will see any bugs outside of obscure plugins
<dholbach> good morning
<RAOF> Wow, Mir takes a while to build on arm.
<ogra_> RAOF, locally ? or on the buildd
<RAOF> On the builld.
<ogra_> (we got new buildds yesterday ... )
<RAOF> I'm pretty sure I could have had this finished in a qemu schroot in the hour it's taken on the buildd, including the time taken to set up the armhf chroot :)
<ogra_> is that a distro buildd or PPA ?
<RAOF> PPA.
<ogra_> would be worrying if its distro
<ogra_> ah
<RAOF> I understand we have shiny new caldexa nodes for our distro buildds.
<RAOF> That do things like build Mir in less than an hour :)
<ogra_> on the distro buildera firefox build takes ~5h now ... was between 20 and 30 before
<mlankhorst> RAOF: ping
<mlankhorst> https://launchpadlibrarian.net/146986827/buildlog_ubuntu-saucy-powerpc.xserver-xorg-video-ati_1:7.2.0-0ubuntu1_FAILEDTOBUILD.txt.gz
<RAOF> mlankhorst: Pong.
<RAOF> Gah. Did I fail to push the fixed patch for that
<RAOF> +
<RAOF> ?
<mlankhorst> it has come to this
<RAOF> mlankhorst: I fixed that in one of the pre-7.2.0 uploads, but I may not have pushed all of those to alioth :(
<mlankhorst> hm reverse debdiff it? :P
<mlankhorst> seems you're right
<RAOF> git merge to the rescue.
<RAOF> robert_ancell: Whoops. Sorry - the armhf build didn't finish before the i386 & amd64 build for the *next* revision. No copy-with-binaries available for us!
<RAOF> mlankhorst: I'll fix that up, push to git, and upload.
<mlankhorst> git merge is awesome ;P
<mlankhorst> do you have dpkg-mergechangelogs set up for git merges too?
<RAOF> Indeed I do.
<didrocks> RAOF: ok, let me find an archive I can restore
<didrocks> are you free to debug Mir?
<RAOF> didrocks: Uuur, I'll be doing ZoÃ«'s bath in a 10 minutes or so.
<RAOF> I can be available later, or if the machine won't be free then I guess I could get Sam to handle ZoÃ«'s bath.
<alf__> RAOF: quick question: can an output have more than one preferred modes?
<RAOF> alf__: I don't believe that makes sense, no.
<didrocks> RAOF: should be freed, how long will that take you?
<didrocks> to know if I'm going out for exercise now or later
<didrocks> or just prepare and block the machine and ping you with the details
<RAOF> Probably prepare and block the machine & ping me with the details would be best for me.
<RAOF> I'll probably be ready to start debugging in ~1hr or so.
<didrocks> RAOF: ok, doing that
 * RAOF prepares to set up the VPN on his new laptop
<robert_ancell> RAOF, damn!
<thomi> RAOF: would you like it turned off forever?
<robert_ancell> And the reason mir rebuilt? - didrocks daily landing bumped debian/changelog :)
<didrocks> robert_ancell: sorry, was it a question? ;)
<robert_ancell> didrocks, :P
<thomi> RAOF: I disabled the jenkins job - let me know if/when you want it turned on again
<robert_ancell> duflu, have you given up with mir+raring? I want to disable all the raring packages from the staging PPA
<duflu> robert_ancell: No, still using it for now. But I know I lost that argument
<robert_ancell> duflu, well, it hasn't built for raring in some time, so you must only be building it locally right?
<duflu> robert_ancell: Yes, always locally. I guess I need the PPA only for the Mesa/Intel changes
<robert_ancell> thomi, can you disable mir and unity-system-compositor raring builds in the staging PPA? (no rush)
<robert_ancell> and unity-greeter too I guess
<thomi> robert_ancell: can get to that tomorrow, sure.
<thomi> robert_ancell: just raring, right>
<thomi> ?
<robert_ancell> yes
<thomi> ok, made a note. Will do that first thing tomorrow.
<duflu> ping alf__
<robert_ancell> make
<robert_ancell> cd
<robert_ancell> cd bzligd/sea
<robert_ancell> ls
<robert_ancell> jetessrter
<RAOF> didrocks: Ping? New laptop has a new ssh key :(
<seb128> RAOF, he went out for exercice, he should be back in half an hour
<RAOF> seb128: Ah. Are you able to shove another ssh key on the box we ssh into?
<seb128> robert_ancell, hey, if "jetessrter" is a password of yours, change it :p (you typed that and a bunch of commands in IRC)
<seb128> RAOF, I'm afraid I don't know how to do that, maybe jibel can help though
<seb128> jibel, ^
<jibel> RAOF, which box?
<RAOF> Whatever 10.97.0.1 is.
<RAOF> (In the QA lab, I think.)
<jibel> RAOF, you don't seem to have an account on this box, which user do you use?
<RAOF> desktop-team
<seb128> RAOF, how is your new laptop btw? you got one of the new system76 ones right? they look quite nice
<RAOF> seb128: They are quite nice.
<robert_ancell> seb128, heh, must fix that
<seb128> robert_ancell, ;-)
<RAOF> Not quite the same build quality as a high-end thinkpad, but servicable, with a nicer screen and cheaper :)
<seb128> RAOF, it's renewal time for me so I'm looking around, though I'm still happy with my 3 years old latitude ... I might go for an ultrabook (the xps13 looks nice, but glossy screen ...)
<RAOF> Matte screen on the galago :)
<jibel> RAOF, I re-imported your ssh keys, can you try again?
<RAOF> jibel: Works, thanks!
<jibel> yw
<RAOF> Oh, hello.
<RAOF> Why is mir_wait_for blocking indefinitely, I wonder?
<RAOF> Wow. unity-system-compositor has 17 threads.
<RAOF> duflu: You were playing around in the mir_wait_for pool before - any ideas why mir_wait_for would be blocking indefinitely?
<duflu> RAOF: Assuming you don't have a logic error, I do recall the design of mir_wait_for is actually not thread safe :/
<duflu> RAOF: Perhaps mir_wait_for_one() ... http://unity.ubuntu.com/mir/group__mir__toolkit.html#ga4f9ee1ace58423c5482e9b3018060252
<RAOF> Hm. That's probably not it, because we only mir_wait_for in the xserver mainloop
<alf__> duflu: pong, sorry lost in console land
<alf__> alan_g: @internal_surface, how come we can call as_internal_surface() without the namespace?
<duflu> alf__: I will defer bothering you while I suspect I might have caused the issue :)
<alf__> duflu: ok
<alan_g> alf__: ADL
<alf__> alan_g: ok
<RAOF> duflu: Why âwhile ((!expecting && !received) â in wait_for_all?
<RAOF> duflu: This seems to be a race condition?
<duflu> RAOF: Don't know. I thought that was well tested...
<duflu> RAOF: It's in a unique_lock, so can't race. Only be misused by callers...
<RAOF> It seems to me that if you call mir_wait_for(mir_connection_do_something()); and your timeslice runs out between mir_connection_do_something and mir_wait_for then it's possible for the request to be processed before mir_wait_for *acquires* that lock.
<duflu> RAOF: It looks like the kind of situation wait_for_one was invented to solve. The problem with wait_for is that it is unsafe to ever have more than one thread call it
<duflu> ... cos if you do, the first will win and starve subsequence threads
<RAOF> But this *does* only ever have one thread call it!
<duflu> RAOF: Is your received < expecting?
<duflu> What is expecting?
<RAOF> No; both are 0
<duflu> RAOF: That means no result_received yet
<RAOF> duflu: Surely it doesn't?
<duflu> RAOF: It's pretty clear in mir_wait_handle.cpp
<RAOF> I would have thought expecting > received was no result_received.
<RAOF> Oh, no; you're quite right.
<duflu> RAOF: Any result_received is a result. It's just a matter of how many you expect (are committed to wait for)
<RAOF> If it had been received then there'd be non-zero numbers there.
<duflu> RAOF: I'm not saying all uses of MirWaitHandle are bug-free, but it looks likely the class itself is.
<RAOF> Yeah.
<RAOF> Which suggests that the request just hasn't been processed.
<RAOF> didrocks: If you need that box back I've probably got enough to think about.
<didrocks> RAOF: ok, rebooting it to unscrew it now :)
<didrocks> thanks RAOF
<RAOF> Bah. Where was that bug again? I should update it.
<alf__> RAOF: it seems that KMS supports multiple preferred modes...
<RAOF> Huh. You live and learn.
<alf__> RAOF: but xrandr hides this, probably selects the first/highest preferred
<alf__> RAOF: I wonder how it gets this from EDID information, I thought it had only one preferred mode field?
<RAOF> I knew that I could technically set as many "preferred" modes as I liked; it's just a flag I can apply to a mode. I didn't think it would ever have more than one, though.
<RAOF> alf__: Likewise.
<RAOF> alf__: When you say kms supports multiple preferred modes, what do you mean?
<RAOF> Or, rather - have you seen it *return* multiple preferred modes?
<alf__> RAOF: I mean that on both my laptop and desktop I get multiple modes with the preferred flag set, yes
<RAOF> Oddness.
<RAOF> I'm surprised you get more than one mode *at all* on your laptop, frankly :)
<alf__> RAOF: actually you are right, lvds screen, gives me just one, it's the external screen that supports more there
<RAOF> Ok. It's not clear to me what the hell's happening there.
<RAOF> If anyone's got a few cycles spare to be perplexed, https://bugs.launchpad.net/mir/+bug/1204939 is really odd.
<ubot5> Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (fails to find GL acceleration) (logind fails to track session?)" [Critical,Triaged]
<tvoss> alan_g, ping
<alan_g> tvoss:
<alf__> mlankhorst: Hi! Any idea if it's normal for KMS to return multiple "preferred" modes (DRM_MODE_TYPE_PREFERRED set in mode->flags)? A quick survey of the drm kernel code (e.g. for radeon) indicates that this shouldn't happen (unless I missed something).
<mlankhorst> alf__: why do you ask?
<mlankhorst> first preferred mode would be the correct one, if there is more for the same connector it's probably a bug
<duflu> alan_g: The timing failure on N4, is that all the time or intermittent?
<alan_g> duflu: happened twice - am increasing sample size
<duflu> alan_g: OK, yeah. I think the test is more at fault than the code. I'm going to loosen the test today and work on improving it another day
<alan_g> duflu: failed 3 out of 10
<duflu> alan_g: What was the highest number reported of the 3?
<alan_g> duflu: all 1 vs 1
<duflu> alan_g: Right, so worst case was ~1% hiccups. That's the test being too strict, or not running long enough (since I shortened everything today)
<duflu> tvoss: Done, methinks
<duflu> At least that took long enough that the meat I was meant to cook is fully defrosted for sure
<alf__> mlankhorst: on both radeon and intel I get more than one preferred mode for outputs
 * alan_g wonders why http://unity.ubuntu.com/mir/using_mir_on_android.html still says "stop" - didn't duflu correct that?
<duflu> alan_g: Yes but I don't know how the web gets updated
<alan_g> duflu: it ought to be generated from trunk
<duflu> alan_g: Wait, no. That's a doc file I forgot to fix
<alan_g> Not sure how often
<alan_g> duflu: np - go eat
<alan_g> tvoss: How do we zap surface flinger in the current image?
<alan_g> NM I found https://wiki.ubuntu.com/Touch/Testing/Mir#Switch_from_SurfaceFlinger_to_Mir
<mlankhorst> hmz any open bugs I can look at?
<kgunn> mlankhorst: if you'd like to pick up where RAOF has left  off https://bugs.launchpad.net/mir/+bug/1204939
<ubot5> Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (hang in mir_wait_for())" [Critical,Triaged]
<didrocks> kgunn: I noticed that unity_support_test tool is stuck in fact
<didrocks> (it's launched by compiz)
<didrocks> so I guess it's the first gl app which is blocking
<mlankhorst> likely
<mlankhorst> kgunn: what is that machine btw?
<kgunn> mlankhorst: its "otto" which didrocks or jibel can help get you access
<mlankhorst> didrocks/jibel: ok, I have no idea what's going on from the logs so if I could get access^
<didrocks> mlankhorst: kgunn: the machines are under heavy use right now
<mlankhorst> ok
<didrocks> kgunn: once we'll have asac's 3h daily release, we won't be able to all to give back access
<didrocks> which we are going to plug soon
<didrocks> so it's the last calls, this time, please really looks at the logs, later will be too late :)
<didrocks> mlankhorst: in ~1h, I should be able to block it
<didrocks> will you be around?
<didrocks> mlankhorst: you have the VPN access right?
<mlankhorst> I'll be here in 1h, I'm on some vpn to qalab
<didrocks> mlankhorst: what's your ssh key I should import?
<mlankhorst> https://launchpad.net/~mlankhorst/+sshkeys
<kgunn> didrocks: understand....but, we've been runnning xmir fine on other ati machines so the problem seems specific to this one
<didrocks> kgunn: we know what happens with "specific to this one" which then happens to multiple configs, I'm not that idealist ;)
<didrocks> if on one of the 2 machines we have, it happens (and traditional Xorg is working with acceleration), there is probably something that can affect other
<kgunn> didrocks: we tried yesterday with 3 others with no problems
<kgunn> 3 other ati that is
<didrocks> kgunn: as Unity7, I never uploaded a Unity7 that was screwed on my machines at home
<didrocks> thenâ¦ you see that even testing on 4 with the 3 cards were not enough :p
<didrocks> so I wish we can settle that down
<seb128> didrocks, I don't think anyone is trying to deny there is an issue, it's just harder to debug when the hardware you have local access to doesn't reproduce the issue
<kgunn> didrocks: nvmd, our exchange doesn't seem helpful
<didrocks> seb128: that exactly why I'm proposing access for the past 2 weeks
<kgunn> didrocks: again not helpful
<seb128> kgunn, what would be helpful to debug, out of access to the machine we have which hit the issue?
<asac> kgunn: didrocks: i guess you might want to align the exact execution environment so you see the same thing
<kgunn> seb128: unfortunatley, we're spanning time zones (and we weren't helping ourselves with xorg churn...but we're past that)...so now we need to iterate
<kgunn> asac: we've verified multiple environ's on other machines....it could even be the specific card/family at this point
<asac> once you are sure you do the exact same thing, investigating difference in behavioru becomes relevant
<asac> kgunn: right it could. just want to ensure that we are sure its the different card/family
<asac> and not something else we do different still
<didrocks> asac: it's passing with the same packages and setup on the intel machine
<kgunn> asac: were you on this channel yesterday?
<asac> that doesnt mean you run stuff in the exact same way that kgunn is running them
<asac> kgunn: i was in this channel, but not following
<didrocks> kgunn: wasn't the same with the race issue? you never reproduce it before we spot it as dailies and after that we discovered that a lot of devs got it but juts reboot? (we had the same argument of "we never saw that, it's only you")
<didrocks> sorry for being extra cautious, but I think we should understand what's happen before pushing u-s-c
<kgunn> didrocks: ok, let's try it otherway around....would you mind setting up lexington machine via robotfuel to be exactly like otto ?
<kgunn> this way there is no more questions about setup ?
<kgunn> didrocks: that would be helpful....what do you think?
<kgunn> didrocks: to be clear...i am not asking you to push u-s-c....i am trying to repro the problem with ott
<didrocks> kgunn: first, as we still don't have those 3h-dailies, I'll be able to give access to mlankhorst  and block every stacks on this
<kgunn> otto
<didrocks> kgunn: I don't know if they have another ati machine with the same card?
<mlankhorst> what is that machine btw?
<kgunn> didrocks: got it...but i am anticipating we still won't have it solved
 * kgunn is a realist
<didrocks> mlankhorst: the one I pasted the other day, you will have access
<didrocks> kgunn: let's hope we know what happens first, RAOF spent more than 1h on it this morning
<robotfuel> kgunn: I don't think we have a system with the same card
<didrocks> kgunn: then, yeah, we need a more dynamic QA lab for stuff running on real hardware
<kgunn> didrocks robotfuel ....why not make sure the one in lexington lab has the same steup/run of a trademark didrocks run ??
<kgunn> who cares if the card is different....
<kgunn> this goes back to your post a moment ago about teams claiming that stuff isn't broken only to find out it is
<didrocks> jibel: can you install otto on that one? as it seems kgunn and asac may think otto is the cause of this?
<didrocks> kgunn: I just wonder as we would have the same issue with intel, or even unity won't even run on traditional Xorg on ati
<didrocks> which it does ~20 times a day for multiple hours for the past 5 months
<kgunn> didrocks: jibel .....i am more suspicious of it being a potential ati-issue
<didrocks> like that driver/card in particular? (completely possible)
<mlankhorst> my ati works just fine
<kgunn> didrocks: could be a combo - your specific setup + your specific test run + ati driver (general even)
<mlankhorst> oh wait PROVE_LOCKING is disabled due to some regression, grrr
<kgunn> mlankhorst: yeah...i'm just trying to nail the exact environ + test run eliciting the behavior
<didrocks> kgunn: no test are run at this point as the session never successfully fully comes up, but yeah, setup + ati driver
<jibel> didrocks, install otto on which one? if there is a box remotely accessible I can deploy the test setup on it of course
<didrocks> (knowing that it's working on Xorg + unity/compiz on that card)
<didrocks> robotfuel: ^
<mlankhorst> hmz :p
<mlankhorst>     drm: Don't pass negative delta to ktime_sub_ns()
<mlankhorst>     
<mlankhorst>     It takes an unsigned value. This happens not to blow up on 64-bit
<mlankhorst>     architectures, but it does on 32-bit, causing
<mlankhorst>     drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus
<mlankhorst>     timestamps for vblank events. Which in turn causes e.g. gnome-shell to
<mlankhorst>     hang after a DPMS off cycle with current xf86-video-ati Git.
<robotfuel> jibel: didrocks you can use ps-radeon-hd6870-he
<mlankhorst> makes me wonder if it only happens to blow up on i386 or not ;)
<alan_g> alf__: any ideas on how best to progress https://code.launchpad.net/~alan-griffiths/mir/fix-1208774/+merge/178925?
<alf__> alan_g: I would be good to find out what the problem is (probably just a linker bug), but I think the workaround is ok for now.
<kgunn> robotfuel: jibel didrocks mlankhorst ....the key is to setup & "start" the run on ps-radeon-hd6870-he in exactly the same manner
<kgunn> as otto
<alan_g> alf__: Feel like voting then?
<alf__> alan_g: sure
<jibel> kgunn, undertood
<mlankhorst> how do I connect to that one btw?
<kgunn> robotfuel: ^ ?
<robotfuel> mlankhorst: https://wiki.canonical.com/UbuntuEngineering/QA/Lab ctrl-f and search for ps-radeon-hd6870-he
<kgunn> jibel: mlankhorst robotfuel ...thanks for all this....heroes you are!
<kgunn> or will be :)
<mlankhorst> is something supposed to happen when i hit connect?
<mlankhorst> oh there we go
<mlankhorst> kgunn: hm default xmir works?
<kgunn> mlankhorst: ....can we ensure our boot and attempt to programatically run are the exact same to didrocks on otto, e.g. he ran unity_support_test
<didrocks> (compiz does in fact)
<didrocks> mlankhorst: the machine will be available in 5 minutes
<kgunn> didrocks: does it run that every boot regardless? (e.g. we don't need to enable any boot script or something)
<didrocks> kgunn: if you start an unity session, it's ran
<kgunn> didrocks: :-/....damn, back to otto
<kgunn> didrocks: what is the specific card on that again (i'll note it in the bug)
<didrocks> kgunn: one sec, launching the tests ASAP and noting it on the bug
<mlankhorst> curiously is otto a machine without its outputs connected to anything?
<mlankhorst> i suppose I could test that setup locally
<mlankhorst> hm my machine died without output connected
<tvoss> mlankhorst, kgunn, didrocks any more insight into the ati issue?
<mlankhorst> hah
<kgunn> tvoss: right now...suddenly seems to work....didrocks suspecting hybris
<kgunn> getting solved
<mlankhorst> <4>[   60.988003] other info that might help us debug this:
<mlankhorst> <4>[   60.988003]  Possible unsafe locking scenario:
<mlankhorst> <4>[   60.988003]
<mlankhorst> <4>[   60.988003]        CPU0
<mlankhorst> <4>[   60.988003]        ----
<mlankhorst> <4>[   60.988003]   lock(&mm->mmap_sem);
<mlankhorst> <4>[   60.988003]   <Interrupt>
<mlankhorst> <4>[   60.988003]     lock(&mm->mmap_sem);
<mlankhorst> <4>[   60.988003]
<mlankhorst> but no idea wtf is going on there
<kgunn> mlankhorst: did i speak too soon....is that otto or your local  ?
<mlankhorst> local
<didrocks> second run, worksâ¦
<didrocks> (well started)
<didrocks> the machine didn't die
<mlankhorst> no idea wtf is going on there
<kgunn> tvoss: then didrocks gonna check diff between yesterday & today
<kgunn> tvoss: ....enjoying your afternoon off :)
<mlankhorst> new mir patch for ati at least
<mlankhorst> meh list corruption in nfs here, grrr
<mlankhorst> why does nfs have to add a new corruption every time I update my kernel :/
<didrocks> kgunn: didn't yet look at it, before yesterday-today: http://paste.ubuntu.com/5962760/
<mlankhorst> didrocks: yeah ubuntu2 ati, might have been what fixed it
<didrocks> mlankhorst: interesting
<mlankhorst> but no idea really what was going on
<didrocks> can be that or Mir itself
<mlankhorst> hm fun, another crash at a random place in the kernel
<mlankhorst> I'm definitely hitting some nasty fd corruption on this linux/master + airlied/drm-fixes kernel
<mlankhorst> other machine is fine though :/
<didrocks> ok, so can't reproduce anymore
<didrocks> after 3 runs
<didrocks> and then one run to regular Xorg with another stack
<didrocks> no hang
<didrocks> no machine getting crazy
 * didrocks just removes a flacky test from the list and will push u-s-c to universe
<mlankhorst> ok I think it's radeon's fault on my machine at least, I swapped out the card for another one and that machine works
<kgunn> jibel: robotfuel didrocks mlankhorst ...thanks for all the help
<didrocks> kgunn: yw
 * kgunn 's beer/food list is getting long
<mlankhorst> my 6570 hangs really badly, 5570 works
<mlankhorst> getting really bad kernel memory corruption with the 6570, so I'll have to look at that later
<kgunn> mlankhorst: thanks...
<jibel> kgunn, yw, thanks to whoever fixed this crash
<kgunn> robotfuel: was there a Northern Islands (HD 6xxx) Series ati in lexington working ok ?....just tieing this back to mlankhorst complaint about 6570
<robotfuel> kgunn: we have a 6870, but it's not being used on the new server. openarena worked on it before with xmir
<mlankhorst> I'm close to upstream though, hm perhaps even ahead of upstream, I'll try without some patches :P
<robotfuel> kgunn: it's the one jibel is testing with
<mlankhorst> oh i was already testing without those
<kgunn> robotfuel: cool....yeah, that's definitely same family
<kgunn> seris
<kgunn> series
<mlankhorst> but in my case it's definitely a kernel corruption
<mlankhorst> no way userspace would screw up this badly :P
<smartboyhw> mlankhorst, in http://unity.ubuntu.com/mir/using_mir_on_pc.html it says in Running Mir Natively a "some-mir-client" command.
<smartboyhw> What does that mean?
<smartboyhw> olli_, ^
<olli_> smartboyhw, in a meeting, kgunn^
<kgunn> smartboyhw: like for instance mir_demo_client_egltriangle
<smartboyhw> kgunn, oK
<smartboyhw> mir_demo_client_egltriangle
<smartboyhw> kgunn, whoa nice!
<kgunn> smartboyhw: there's several there
<smartboyhw> kgunn, you should provide a list to us:P
<alan_g> smartboyhw: ls mir_demo_client*
<smartboyhw> alan_g, great, thanks
<kgunn> racarr: can you join us ??
<kgunn> racarr: ping
<kgunn> racarr: ping (sorry...i kept rebooting i know)
<racarr> kgunn: pongish
<racarr> Hey wait I'm supposed to be racarr|dentist
<racarr> what's up?
<kgunn> racarr: no worries...hopefully its a "good" dentist experience & not a "painful" one
<racarr> medium lol
<kgunn> racarr: was just curious...we were wondering on surface configurator if mir is to control the osk visibiltiy with the minimize attribute
<kgunn> ?
<racarr> kgunn: Yeah! I think that's the idea.
<racarr> we need to hook it up to qtubuntu
<kgunn> racarr: cool greyback|dinner ...dang he's at dinner ^
<racarr> but dandrader was telling me mallit just calls like QWindow show/hide
<racarr> so, the surface configurator actually does two things for the OSK:
<racarr> 1. Let's it recognize the overlay surface type (and approve/dissaprove setting this) with select_attribute_value
<racarr> 2. Implement minimize/restore with the attribute_set interface
<kgunn> racarr: that's perfect!
<kgunn> thanks for pushing that...
<racarr> :D
<racarr> I have to go again soon. I failed to bring proof of residence to the DMV yesterday so trying again today
<racarr> Drivers license expires tomorrow so if I don't do it today I have to take a driving test ><
<racarr> I think, based on kdubs branch though, I can submit a much simpler version of client-focus-notifications
<racarr> hopefully this evening or tomorrow
<greyback> kgunn: ack, all sounds good to me
<kgunn> bschaefer: thanks for the help yesterday!....glad it "resolved itself"
<bschaefer> kgunn, haha np, as I am...and I hope it stays that way
<bschaefer> and yay u-s-c is in main :)
<kgunn> bschaefer: i know....feels naughty!
<kdub> yay
<robert_ancell> thomi, hey, did you forward that itinery?
<racarr> next time you guys come to oakland I can not recommend the california DMV
<racarr> for a fun afternoon
<kdub> racarr, in lexington next month, i'll show you my license with my dmv picture
<kdub> pretty funny how evidently angry i am in it :P
<racarr> haha
<robert_ancell> kdub, ha!
<racarr> apparently when the person yesterday told me I needed a copy nof my birth certificate
<racarr> they meant in particular, the original copy
<thomi> robert_ancell: we're having trouble finding flights from bos -> SFO or LAX that don't involve a huge stopover. Should have final flights tomorrow
<robert_ancell> thomi, k
<robert_ancell> thomi, is it faster to go via NYC?
<thomi> robert_ancell: NYC is kind of in the wrong direction
<thomi> I have faith that BTS will sortit out. Worst case is 10 hours in SFO - maybe time to do a bit of sightseeing :)
<racarr> thomi: That's just long enough to get a drivers license at the DMV!
<racarr> :p
<thomi> racarr: I already ahve two drivers licenses, why would I want a third?
<racarr> thomi: :)
<jono> hey guys
<jono> FYI: to track flavor bugs I am going to ask flavors to tag their bugs with 'flavormirbug'
<jono> the resulting search with these bugs is at https://bugs.launchpad.net/bugs/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&fie
<jono> ld.tag=flavormirbug&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search
<jono> kgunn, ^
<jono> is there any chance we could get #1208250 on a priority list?
<thomi> haha, nice URL
<jono> oh, it is Critical
<jono> but seems not assigned
<jono> thomi, seriously
<robert_ancell> jono, cheers
<jono> robert_ancell, np
<jono> they are choosing whether to go with Mir on the 22nd
<jono> so I think if we can resolve most of their issues by then, it should encourage the Xubuntu community to ship Mir
<thomi> robert_ancell: robotfuel is still hitting this issue in the xmir tests: https://bugs.launchpad.net/xmir/+bug/1209000
<ubot5> Launchpad bug 1209000 in XMir "radeon hd7850 fails to load driver from system-compositor-testing ppa with gbm: failed to open any driver (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)failed to load driver: radeonsi" [Undecided,Fix released]
<robotfuel> thomi: I still need to check if that's the case with the new drivers,  this is the bug I was talking about https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1209397
<ubot5> Launchpad bug 1209397 in xserver-xorg-video-ati (Ubuntu) "[radeonsi] radeonhd "southern islands" 3d hardware acceleration" [Undecided,Confirmed]
<thomi> robotfuel: ahhh ok
<robotfuel> thomi: it looks like they are related
<thomi> robert_ancell: so that card is listed on the xmir go/no-go acceptance criteria
<thomi> robert_ancell: so it's needed before we turn xmir on for 13.10
<thomi> robert_ancell: I wonder if you can use your team-lead super powers to poke someone to fix this for us?
<robert_ancell> thomi, otp
<robotfuel> thomi: there is actually a new bug, x crashes now with /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: exaGetPixmapDriverPrivate
<thomi> robotfuel: OK, can you please make sure that all the relevant bugs are linked in the SS, so I can keep bugging people until they get fixed?
<robotfuel> thomi: yes everything but that bug is to date
<thomi> robotfuel: OK, so there's 3 issue, the two bugs in the SS (both linked above), and the third that you've just mentioned?
<robotfuel> the 1209000 isn't happening anymore,  now it's undefined symbol: exaGetPixmapDriverPrivate
<robotfuel> thomi: I'll ping you when apport is done uploading the bug
<thomi> sweet
<robert_ancell> thomi, robotfuel, ah, RAOF said that one looked like exa support wasn't loaded
<robert_ancell> please assign to RAOF for triaging once its up
<robert_ancell> What are the other two issues?
<racarr> kdub: Have been going through connect-display-request btw. I like it :)
<kdub> oh, great :)
<robotfuel> robert_ancell: it's one other issue not 2
<racarr> will rework client-focus-notifications on the refactoring there to get rid of the event sink changes
<robotfuel> robert_ancell: this is the other issue https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1209397
<ubot5> Launchpad bug 1209397 in xserver-xorg-video-ati (Ubuntu) "[radeonsi] radeonhd "southern islands" 3d hardware acceleration" [Undecided,Confirmed]
<racarr> I am starting to wonder though...
<racarr> (not for this branch, just in general)
<robert_ancell> robotfuel, that card has issues on traditional X right?
<racarr> perhaps SessionManager isn't mf::Shell
<robotfuel> robert_ancell: yes https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1209397 is a traditional x bug
<racarr> you know? There are kind of different roles between this handle_surface_created, and open_session type stuff
<racarr> and I'm more inclined to call the handle_surface_created, etc, the 'shell'
<kdub> racarr, yeah, should make picking out right where the focus occurred a bit easier
<kdub> and should also let you write an implementation of focus that depends on events
<kdub> so it can be like,  z-order based in a simple case, or as complicated a class you can think up
<racarr> mm
<kdub> being in this part of the system for a bit pointed out to me how the shell's grand data structure
<kdub> is the SessionContainer
<kdub> with mir's grand data structure being the SurfaceStack
<kdub> things are starting to shape up along those lines :)
<robotfuel> thomi: spreadsheet is up to date
<racarr> Alan thinks the session assosciation should be in the SurfaceStack (SceneGraph)
<racarr> and I'm not totally sure yet.
<thomi> yhanks
<thomi> thanks even
<racarr> on one hand it might make certain synchronization issues, and exposing stuff out to the shell, etc, easier and safer
<robert_ancell> thomi, did you disable the raring builds from the testing ppa?
<racarr> on the other hand 1. I'm not sure how to do it and 2. I kind of like the way that the shell functions as
<robotfuel> thomi: I am going to mark https://bugs.launchpad.net/xmir/+bug/1209000 fixed released because it's not happening anymore
<racarr> something on top of the SurfaceStack
<ubot5> Launchpad bug 1209000 in XMir "radeon hd7850 fails to load driver from system-compositor-testing ppa with gbm: failed to open any driver (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)failed to load driver: radeonsi" [Undecided,Fix released]
<robotfuel> heh it was already marked fixed release :P
<kdub> racarr, i'm not sure either about that, but thats an initial reaction
<racarr> kdub: Perhaps part of the session manager is really part of the session container
<racarr> and the rest is mf::Shell
<racarr> i.e.open_session/close_session anyway
<racarr> then the shell gets on_session_opened, on_session_closed sort of stuff
<kdub> well, the session manager is being reduced to the session factory
<kdub> create_surface_for can be eliminated if we have a "SessionMediator-like" class for our internal clients
<RAOF> Gah. Why is BTS 50% more expensive than flights I could book myself?
<robert_ancell> RAOF, yeah, I always get that too
<robert_ancell> RAOF, we really should have an Australasian travel agent
<RAOF> Yeah.
<RAOF> Also. UA - just say no.
<racarr> kdub: mm. maybe there is a SessionMediator that can work for internal and external client sort of object
<racarr> and the RPC also has a "socket mediator" or something
<robert_ancell> bbl
#ubuntu-mir 2013-08-09
<RAOF> kdub: Hey, is mir_connection_set_display_config_change_callback hooked up all the way through Mir?
<kdub> wellll :) after ~kdub/mir/connect-display-request it will be
<kdub> but it's not quite done yet, because the clients do not get the updated configuration after the display change yet
<kdub> like, you can request, and check the error code, and the display should be changed, but there's still some hooking up and testing left to be done
<RAOF> kdub: Ah, ok.
<RAOF> So I shouldn't be concerned when XMir's handler doesn't actually get called on hotplug events âº
<duflu> robert_ancell: Are PPAs still required for saucy at all?
<duflu> Given... https://launchpad.net/ubuntu/+source/mir
<robert_ancell> duflu, the staging PPA is handy as it contains a per commit build
<duflu> robert_ancell: So handy but not required?
<robert_ancell> the archive only contains per day builds, and only then if they pass integration tests
<robert_ancell> yes
<duflu> Kay
<robert_ancell> no reason to get rid of them
<duflu> Wow. What? How? It seems several times recently when I comment in LP, the email with my comment arrives in under 1 second later. That's incredible.
<racarr> duflu: My life: 1. Make comment on launchpad 2. Zone out 3. Wait half a second, computer dings for new email, remember that its me commenting on launchpad 4. Phone makes sound, check it, it's me commenting on launchpad 5. repeat
<duflu> racarr: Too many connected devices... You have a choice :)
<duflu> ... unless they're all Ubuntu in which case you *should* have more
<racarr> Haha
<racarr> and they should all sync up over networked dbus or ubuntu one or whatever
<racarr> so they realize not to notify me multiple times for the same event
<racarr> anyyy day now
<duflu> And have eye tracking to know which device you already saw it on
<racarr> duflu: They should transfer us to design
<duflu> I'm pretty sure we already have designers with big ideas.
<duflu> Also, I don't do scarves
<racarr> engineering it is then
<smartboyhw> Mir guys: HELP http://paste.ubuntu.com/5964829/
<smartboyhw> I know what sort of problem is it, but since I'm not in the Mir team I can't fix:P
<smartboyhw> mlankhorst, ^
<RAOF> Um, when did we bump mirserver ABI?
<RAOF> That's a filthy lie.
<RAOF> Gah.
<RAOF> smartboyhw: I'll fix it. You know how to work around that, right?
<duflu> RAOF: Because the switch branch landed. And accidentally using the old libmirserver would cause strange and hideous bugs
<RAOF> duflu: Ok. But libmirserver0 wasn't parallel-installable-ready.
<duflu> RAOF: Oh, that sucks. But I would still prefer error messages to strange bugs (and inexplicable test failures)
<RAOF> Well, if you're using the packages we had that covered already :)
<duflu> RAOF: I was using the packages. That's the problem... the ABI actually changed and it would pick up the old libs by mistake
<duflu> ... when building Mir locally
<RAOF> Right; only an issue then. :)
<smartboyhw> RAOF, I know the fix, I don't know the workaround:P
<RAOF> smartboyhw: Oh; dpkg --install --force-overwrite /var/cache/apt/archives/libmirserver1*.deb
<smartboyhw> RAOF, thanks
<RAOF> duflu: https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/179316 should fix that.
<duflu> RAOF, ta
<RAOF> Huh. No Robert.
<smspillaz> how long is
<smspillaz> MirWaitHandle!
<smspillaz> guarunteed to live for
<duflu> smspillaz: Depends on the class that gave it to you. Generally for as long as the object which gave it to you
<duflu> Which is annoying. It means to avoid leaks, some repeated operations always need to reuse the same handle.
<smspillaz> okay, so if I do mir_wait_for (surface_next_buffer_handle) and the surface already got its next buffer, it just waits for the next one correct?
<smspillaz> so I can atomically set it to NULL in the callback and know from the main thread that we already got our next buffer
<duflu> smspillaz, yeah it should recycle the same handle from inside the client surface object and always just wait for the next one
<smspillaz> excellent
<duflu> smspillaz: Of course, you're not meant to *know* each call returns the same handle
<smspillaz> duflu: it doesn't really matter in my case
<duflu> Sadly we can't even free a handle after it has been waited because (1) sometimes multiple threads will wait on one handle; and (2) the client API is designed such that waiting is optional and may never happen
<smspillaz> I just need to be able to set the wait handle to NULL in the callback thread atomically and then check it for NULL atomically in the main thread
<smspillaz> duflu: does mir_wait_for return after the callback in the other thread completes or before it completes?
<RAOF> After
<smspillaz> excellent
<RAOF> Yeah, it's sensible :)
<smspillaz> yeah I was a bit worried that I might have to lock the data I plan to modify during the callback while the main thread checks to see if it is pending or availaable
 * duflu hope that's true for all operations
<smspillaz> *available
<alf__> RAOF: @preferred mode, it turned out I was checking the wrong struct field, there is indeed only one preferred mode as expected
<RAOF> Ok. Let's see if this approach to one-window-per-output works...
<didrocks> RAOF: hey!
<didrocks> RAOF: are you as amazed than I am that the issue went away a little bit magically? (it's a good Friday news I guess at least ;))
<didrocks> RAOF: seems to be the -ati or hybris issue, I have the package versions diff, but still a little bit puzzled TBH :)
<tvoss> good morning :)
<didrocks> hey tvoss! how are you?
<RAOF> didrocks: Yes.
<RAOF> didrocks: Although given how odd the problem was, hybris seems a perfectly fitting cause :)
<didrocks> RAOF: yeah, but why intel is more resistant to that?
<RAOF> No idea.
<tvoss> didrocks, pretty good :) how are you?
<didrocks> tvoss: I'm thrilled to see the Mir issue on ati fixed for now :)
<tvoss> didrocks, \o/ what fixed the issue?
<RAOF> alf__: Oh, I do have another question for multi-monitor â how do I specify the output a surface is on?
<alf__> RAOF: you just place at the correct coordinates
<didrocks> tvoss: that's part of the mystery, from the installed packaged diff, there are two culpurits: the -ati driver (but the  diff seems thin) or the "hybris picked up by mesa" issue
<didrocks> tvoss: the second sounds more plausible, but it would mean that intel can cope with that, not the ati card
<RAOF> alf__: You do know that there's no way for a client to position a surface, right?
<alf__> RAOF: hmm, right, this is something we need to add...
<tvoss> alf__, absolute positioning is something we definitely want to avoid.
<RAOF> Well, except we don't really want to do that.
<tvoss> alf__, I would propose a surface_{move,associate}_to_output
<RAOF> I'd probably put it in the creation struct, but something like that, yes.
<RAOF> didrocks: Oh, you might want to look at https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/179316
<didrocks> #ubuntu-desktop
<alf__> tvoss: what are the semantics of surface_move_to_output?
<tvoss> alf__, move is the wrong verb, associate is a better term
<RAOF> Another option is surface_fullscreen_for_output
<alf__> tvoss: in a multimonitor scenarios, where surfaces can span outputs, even association is a bit fuzzy.
<RAOF> Which I think might make more sense again.
<alf__> RAOF: yes, I think that's better
<alf__> RAOF: tvoss: although, since we don't have resize support yet, it probably needs to be a creation option?
<RAOF> alf__: Oh, I'd prefer it as a creation option anyway :)
<RAOF> Which would have quite substantial semantics - can't be moved, will only be resized if the underlying output changes mode, is fullscreen.
<tvoss> RAOF, alf__ +1 on creation option
<alf__> RAOF: I am not sure how resizing, even in this scenario, will work yet. Perhaps for the time being you will need to destroy/recreate surfaces when the mode changes.
<RAOF> For now that's fine.
<alf__> RAOF: although it is a bit more complex than that... for example when two outputs are mirrored you don't need to create two surfaces, just one and place it appropriately.
<RAOF> alf__: Well, I'd just create a surface and associate it to one of the clones.
<alf__> RAOF: right
<alf__> RAOF: tvoss: Do we want surface_fullscreen_for_output to be an unprivileged operation?
<RAOF> I think so, yes.
<RAOF> It's something reasonable clients will want to do.
<RAOF> (Hello, presentation apps!)
<tvoss> alf__, yes, but the semantics might be a little more complex than just saying: go fullscreen. Ideally, I would want that call to return a FullscreenSession object
<tvoss> RAOF, or games
<alf__> tvoss: on the client side?
<tvoss> alf__, yup
<RAOF> tvoss: Isn't a "session" roughly the same as "a client connection"?
<alf__> tvoss: what will that FullscreenSession object do?
<RAOF> If so, we very much *don't* want this to imply a FullscreenSession, as having one fullscreen and one normal window will be a pretty common use-case.
<tvoss> RAOF, yes and no: in the general case, session is connection, yes. But in the special case of fullscreen, it is not equivalent
<tvoss> RAOF, obviously, an app can have more than one surface on one connection
<RAOF> I'm unclear as to what a FullscreenSession does, then.
<tvoss> alf__, RAOF my idea there is that the lifetime of the session marks fullscreen enter and leave, plus attributes. The attributes could contain information like associated output, requested resolution, whether apps allow shell chrome to be put on top etc.
<tvoss> alf__, RAOF the attributes would be passed when entering the fullscreen session, and some of them might be mutable during the fullscreen session
<tvoss> alf__, RAOF so bundling them makes a lot of sense
<tvoss> obviously from myp ov :)
<RAOF> They sound like attributes on the surface; I'm still not sure what the session abstraction is for?
<tvoss> RAOF, it accounts for: "fullscreen is a state with attributes, and the set of attributes can change per fullscreen session"
<RAOF> But we can already set attributes on surfaces?
<RAOF> duflu: Re: mir_wait_for_one - is there any guarantee that the "one" you're waiting for is the thing which triggers the unwait?
<duflu> RAOF: I would have to refresh my memory and read the docs to answer that
<RAOF> duflu: My recent reading of the code suggests "no", which makes it rather unuseful?
<tvoss> duflu, congrats on the switch branch being landed :)
<duflu> RAOF: I think wait_for_one returns as soon as there is any result. So no -- you can't know which thread's result you got a result for. In that case you should be using different MirWaitHandles
<duflu> tvoss: Thanks, I think.
<RAOF> I guess we do mostly allocate new MirWaitHandles for things that we might want to wait on.
<duflu> RAOF: I think this is another good case for MirWaitHandle being thread-aware. That would also eliminate the need for two wait functions.
<duflu> RAOF: Wait, no...
<duflu> RAOF: Because the "result" gets signalled in a different thread. You can't ever know which client thread is destined to handle it
<dholbach> good morning
<RAOF> duflu: But we *should* be able to guarantee that mir_wait_for(mir_do_something()); waits until this particular mir_do_something() request has been processed, regardless of what other threads are doing, right?
<RAOF> Or, to rephrase: we MUST be able to guarantee that...
<RAOF> Not that this affects me at the moment, as X is single-threaded.
<duflu> RAOF: It is guaranteed so long as only one thread ever sees that MirWaitHandle. Unfortunately our "reuse" of handles makes that tricky
<RAOF> Right; the extent to which this is not guaranteed is a bug.
<duflu> RAOF: It's a design bug. We would have to change the API to ever resolve it.
<duflu> the client API...
 * RAOF obviously thinks we should make that break
<RAOF> As it is we can't *actually* be used in multithreaded programs
<smspillaz> duflu: RAOF: can't this just be solved from the client side though?
<smspillaz> just atomically set the handle to NULL once the operation has completed
<RAOF> smspillaz: How do you know that the operation has completed?
<smspillaz> RAOF: mir_wait_for
<smspillaz> RAOF: so the pattern I'm doing at the moment is
<RAOF> Tells you that *all* the operations have completed, and isn't safe in the presence of multiple threads.
<smspillaz> if (atomic_pointer_get (&wait_handle))
<duflu> RAOF: To do everything properly, you would return a new MirWaitHandle on every call, and then unfortunately being C (no destructors) would have to make it the client's job to mir_free_wait_handle() every time, even when the client doesn't care about the handle
<smspillaz>   mir_wait_for(wait_handle)
<smspillaz> RAOF: erm ... mir_wait_for_one then ?
<RAOF> smspillaz: And that doesn't guarantee that the operation you meant to wait for has occurred.
<RAOF> That guarantees that *some* operation has occurred on the wait handle.
<RAOF> But if that handle is shared, thenâ¦
<smspillaz> RAOF: wait_handle is set to NULL once the operation completes
<RAOF> smspillaz: libmirclient will give you the same wait handle for some calls
<RAOF> eg: there's only one wait handle for mir_connection_drm_auth_magic, for example.
<smspillaz> RAOF: I know. The idea is that the client, inside the callback, sets the wait_handle to NULL atomically
<duflu> smspillaz: Your idea I guess
<smspillaz> RAOF: the pointers to the wait handles themselves become unique identifiers of completeness
<RAOF> Hm. Yeah, I think that works.
<smspillaz> so you can have struct MyOperationData { MirWaitHandle *handle; }
<duflu> So long as you keep in mind, the uniqueness is only unique to the tuple [connection, surface, operation]
<smspillaz> then opdata->handle = mir_do_whatever (callback, &opdata);
<RAOF> duflu: No, in this case it's unique to just operation.
<smspillaz> and then in the callback
<smspillaz> ... atomic_set (&opdata->handle, NULL);
<smspillaz> Yay client side everything!
<smspillaz> oh wait I forgot this isn't #wayland
<duflu> RAOF: I meant otherwise, but it depends how you define operation :)
<RAOF> smspillaz: Oh, but then you actually need to loop on mir_wait_for_one.
<smspillaz> RAOF: loop ?
<duflu> Yeah, loop if you expect a particular number. Otherwise mir_wait_for() to gobble all results in one go
<RAOF> smspillaz: You can't use mir_wait_for because only one thread will ever escape from that.
<RAOF> smspillaz: And mir_wait_for_one doesn't guarantee that your operation has completed.
<smspillaz> oh I see
<RAOF> smspillaz: So you need to while (atomic_pointer_get(&wait_handle)) mir_wait_for_one(wait_handle);
<smspillaz> while (atomic_pointer_get (&opdata->handle) { mir_wait_for_one(wait_handle); }
<duflu> RAOF: It does guarantee your operation has completed if you ensure [connection, surface, operation] are only used together in one known place, one thread
<smspillaz> beat me to it
<RAOF> duflu: Right. But the vast majority of clients will have exactly one connection, and not all operations operate on a surface; for those operations you're saying "make sure you only ever use one thread", which is not exactly the goal of a threadsafe API :)
<duflu> RAOF: You will get a unique wait handle for each unique pairing of [surface, operation]
<duflu> There is no confusion unless you do similar operations on a single surface from multiple threads
<RAOF> Right. As long as [operation] *operates* on a surface.
<RAOF> For operations which do *not* operate on surfaces you're restricted to one thread.
<duflu> RAOF: I think so yes. That limitation originates from racarr's original client API design
<duflu> See also https://bugs.launchpad.net/mir/+bug/1194384
<ubot5> Launchpad bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Medium,Triaged]
<RAOF> I suspect we might be in violent agreement.
<duflu> Yes, mediums such as this one often result that way
<duflu> media?
<RAOF> Indeed
<tsdgeos> Guys, can't install some mir stuff
<tsdgeos> http://paste.ubuntu.com/5965595/
<tsdgeos> any idea what's wrong?
<duflu> tsdgeos: The mirserver ABI bumped last night. I think a fix is landing soon
<tsdgeos> ok :-/ :-)
<tvoss> didrocks, ping
<didrocks> tvoss: pong
<tvoss> didrocks, hey :) I see libmirserver1 in the daily-build ppa, but not yet in the archive
<tvoss> didrocks, any idea when we will switch that over?
<didrocks> tvoss: right
<didrocks> tvoss: packaging issue
<didrocks> see latest MP
<tvoss> didrocks, ack
<didrocks> tvoss: will be rerun today
<tvoss> didrocks, is that the fix-mir_connection_get_display_info?
<didrocks> tvoss: https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/179316
<didrocks> tvoss: we need that one merged
<tvoss> didrocks, ack
<didrocks> seems it's not approved anymore though
<tvoss> alan_g can you give https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/179316 a review?
 * alan_g looks...
<tvoss> didrocks, want me to top-approve?
<didrocks> tvoss: please do
<tvoss> didrocks, done
<didrocks> thx
<duflu> Alright, I need to run momentarily. Any last requests for the week? :)
<alf__> duflu: enjoy your weekend!
<duflu> alf__: That request I can handle. Thanks, you too
<tvoss_> didrocks, when is the earliest that we can see libmirserver1 in the archive?
<didrocks> tvoss_: is it merged? I'm on 100 subjects again
<tvoss_> didrocks, nope, can you retrigger CI? seems like we have a flaky test
<didrocks> tvoss_: a link will help me with less context switch :)
<seb128> tvoss_, you can usually re-approve if that's a mr
<seb128> CI is going to be retried
<tvoss_> seb128, didrocks re-approved https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/179316
<seb128> tvoss_, great
<smspillaz> yay, garbage on the screen!
<smspillaz> next step: make it display not garbage
<smartboyhw> MIr developers: The thing I most want you to fix is typing:P
<tvoss> didrocks, http://bazaar.launchpad.net/~mir-team/mir/trunk/revision/950
<tvoss> didrocks, that is: packaging fix has landed
<NikTh> OK! Good news arriving ~ It seems like the major problem has been resolved, after the latest updates. A noticeable delay in typing, but this seems so small in front of a completely unusable desktop !!
<NikTh> https://bugs.launchpad.net/mir/+bug/1196355 (new logs added ~ you should examine them and change the state of the bug accordingly, because I'm not very sure)
<ubot5> Launchpad bug 1196355 in XMir "After the latest updates, no desktop session - Ubuntu 13.10 (2013/07/01) - XMir dies with signal 6" [High,Incomplete]
<NikTh> Keep Up the good work devs.. I trust you :-) Cheers !
<tvoss> NikTh, thanks :) a fix for the delay is on its way
<davmor2> hey guys I'm doing a saucy update this morning and got the following error paste.ubuntu.com/5966202  suado apt-get install -f doesn't correct it, is it just a case of remove libmirserver0 and install libmirserver1 ?  or is this a fix needed?
<davmor2> s/suado/sudo
<alan_g> davmor2: have you tried "dist-upgrade"?
<davmor2> alan_g: yeap no joy  I might give it half an hour and retry incase there is a package still uploading
<ogra_> looks like a missing conflicts/replaces in a transition
<didrocks> davmor2: you are using any ppa?
<alan_g> davmor2: are you using the current ppa? http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html
<didrocks> ogra_: yeah, typical things we protected by manual publication
<davmor2> didrocks: I am I have the mir and unity8 ppas
<didrocks> davmor2: that's why
<davmor2> didrocks: ah sorry no I think it is just mir let me double check that
<didrocks> it is Mir
<didrocks> distro is safe
<didrocks> not the mir ppa :)
<davmor2> didrocks: yeap so it's just mir ppa + pinning for it ala the instructions on the mir wiki page
<olli_> didrocks, ping
<olli_> kgunn, ping
<didrocks> olli_: pong
<olli_> kgunn, ping
<kgunn> olli_: pong
<kgunn> didrocks: so what's the configuration under retest ? update on main + u-s-c- from daily-build ppa ? (as usual)
<didrocks> kgunn: right
<didrocks> (with a packaging transition)
<kgunn> mlankhorst: ^ if you could on your local ati...could you run ?
<didrocks> libmirserver0 -> libmirserver1
<didrocks> kgunn: tests pass on intel/ati/nvidia
<kgunn> mlankhorst: just looking for more data points
<didrocks> (just one unity test failing on ati can be because Mir is slower or a flacky one)
<kgunn> bregma: ^ could you also run ?
<didrocks> not enough to stop everything :)
<kgunn> didrocks: yeah...its the perils of getting a moving train into archive :)
<kgunn> wrt mir server bump
<mlankhorst> kgunn: my ati is failing because of a nasty kernel corruption, so nothing in userspace would fix it
<didrocks> yeah, we just delayed a little bit to fix the packaging bits
<kgunn> alan_g: alf__ kdub racarr .....if any of you have spare machines it would be good to hear if you are able to boot/run unity7 as usual.....config is saucy main + u-s-c from daily-build ppa (or build it local from trunk)
<kgunn> https://launchpad.net/~ubuntu-unity/+archive/daily-build
<robotfuel> mir failed to start on my benchmark tests last night, u-s-c was installed from the s-c-t ppa, do I need to update a config file in lightdm now for xmir to run?
<kgunn> robotfuel: for s-c-t, i wouldn't think you needed to do anything....can you verify that the /etc/lightdm/lightdm.conf.d/10-unity-system-compositor has the type=unity commented in ?
<kgunn> robotfuel: can you paste bin /var/log/lightdm/lightdm.log & u-s-c.log
<robotfuel> kgunn: there is no u-s-c.log, I'll pastebin lightdm.log
<kgunn> robotfuel: did you sudo apt-get install u-s-c.....sounds like it wasn't there
<kgunn> ?
<robotfuel> kgunn: dpkg -l shows it's installed
<kgunn> also....check to see if xserver-xorg-xmir is installed
<robotfuel> kgunn: that looks like the issue: iU  xserver-xorg-xmir 2:1.14.2-0ubuntu9
<robotfuel> u in the second column is unpacked if I remember correctly, it will be i if it's installed
<kgunn> robotfuel: ok...the other day bschafer & i had to install....not sure why...but not ur problem obviously
<kgunn> robotfuel: lightdm log ?
<kgunn> robotfuel: also....xorg.0...old
<robotfuel> kgunn:  lightdm http://pastebin.ubuntu.com/5966452/
<kgunn> robotfuel: and the xorg log in /var/log
<robotfuel> http://pastebin.ubuntu.com/5966455/
<robotfuel> from /var/log http://pastebin.ubuntu.com/5966457/
<olli_> didrocks, kgunn, I am back
<olli_> :)
<olli_> kgunn, there is a certain input lag
<olli_> notable
<robotfuel> kgunn: it's a packaging problem unity-system-compositor : Depends: libmirserver1 (>= 0.0.8+13.10.20130808.2bzr948saucy0) but it is not going to be installed
<didrocks> olli_: at least, you're back :)
<kgunn> olli_: yeah...input lag is killing me!!!
<kgunn> robotfuel: maybe main would be better than s-c-t ppa :P
<robotfuel> kgunn: is u-s-c in main now?
<olli_> kgunn, is this a known issue?
<olli_> I thought that was fixed recently
<kgunn> robotfuel: no....you still have to pull it from https://launchpad.net/~ubuntu-unity/+archive/daily-build
<kgunn> olli_: nope....https://bugs.launchpad.net/mir/+bug/1199450
<ubot5> Launchpad bug 1199450 in Mir "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Critical,In progress]
<kgunn> olli_: duflu's switch branch is supposed to fix it according to tvoss.....which i approved yesterday...not sure if its in yet
<olli_> kgunn, ok
<olli_> my bad
<olli_> so, I have it back on xmir, no issues besides the lag
<kgunn> olli_: it should be the #1 now that we're getting in
<kgunn> #1 bug the lag that is
<olli_> didrocks, kgunn I won't be ready with the comms in time for the meeting in 30min
<olli_> didrocks, do you have some more time or are you headed towards weekend soonish?
<didrocks> olli_: that's fine, we can delay a little bit :)
<didrocks> (like 2h)
<bregma> well, an upgrade on my Intel test machine went smoothly, I now have both libmirserver0 and libmirserver1 installed (can't tell which one is in use), Unity 7 runs as well as yesterday (input still suxxors)
<kgunn> bregma: thanks....and no doubt....input enuf to drive you to  drink
<ogra_> dont drink and drive :)
<bregma> except I can't get the drink in because I move my hand one too many mouths to the left
<olli_> didrocks, shall we meet 15past?
<olli_> i.e. 5:15pm for you?
<didrocks> olli_: good to me :)
<didrocks> bregma: there is a missing conflicts in addition to the replaces
<didrocks> bregma: can wait but would be nice to fix :)
<didrocks> bregma: unity7 just passed tests btw (16 failures on each)
<bregma> 16 is about normal these days (at least 5 are known problems with fixes in the queue)
<robotfuel> kgunn: I pinned u-s-c from https://launchpad.net/~ubuntu-unity/+archive/daily-build and I still have conflicts, what other package should I pin from daily-build all of the xmir stuff that use to be in the s-c-t ppa?
<bregma> robotfuel, try not pinning anything
<robotfuel> bregma: is u-s-c in main now?
<bregma> no, so you need the daily-build PPA in your sources, but everything else is in main...  but if you pin the PPA you will know grief
<kgunn> robotfuel: sorry....racing against a clock on something....i'll come back and "play" in a bit :)
<didrocks> olli_: will be 5 minutes late
<olli_> me too
<olli_> didrocks, still writing the AC wiki
<didrocks> olli_: ok, ready, just ping me :)
<olli_> didrocks, kgunn, need 10 more min
<olli_> sorry
<didrocks> no worry
<olli_> didrocks, kgunn I am ready
<didrocks> olli_: any link?
<olli_> let me start a hangout
<kgunn> mlankhorst: any chance you could do a clean 13.10 xmir test (no kernel mods :).....just looking for another ati data point
<kgunn> bregma was yours ati ? or intel ?
<bregma> Intel
<mlankhorst> kgunn: just pretend it works on ati, my other ati cards worked
<kgunn> mlankhorst: :))
<kgunn> gee thanks....filled with confidence
<mlankhorst> hey I know the one ati fails because of a kernel corruption, th  other ones worked :P
<mlankhorst> and regardless of whether mir triggers it, it's a kernel bug causing the corruption.
<kgunn> mlankhorst: cool
<Debolaz> Is there an Ubuntu iso where xmir is used by default?
<ogra_> Debolaz, no, but the xubuntu community made a xubuntu mir image somewhere
<skellat> Debolas ogra_ : See: http://vanir.unit193.tk/mir/
<kdub> whats this? https://code.launchpad.net/~ps-jenkins/mir/latestsnapshot-0.0.8+13.10.20130809.4-0ubuntu1/+merge/179520
#ubuntu-mir 2013-08-10
<sam113101> HI GUYS
<xjunior> Good morning, guys! I have libmirserver0 marked to be removed, but it's also messing up the installation of libmirserver1. apt-get install -f doesn't solve the issue and manually remove libmirserver0 doesn't work. Is there another way of solving it?
<smartboyhw> xjunior, dpkg --install --force-overwrite /var/cache/apt/archives/libmirserver1*.deb
<smartboyhw> With sudo of course:P
<xjunior> that worked, smartboyhw   :)
<xjunior> have this happened to anyone else?
<smartboyhw> xjunior, me
<smartboyhw> :P
<xjunior> hahaha, gotcha
<xjunior> smartboyhw, is #ubuntu+1 somehow official for (currently) 13.10?
<smartboyhw> xjunior, yes
#ubuntu-mir 2013-08-11
<elfy> hi - not sure what to report this against, or even if it's been reported, a bit hard to tell from the bug list
<elfy> installed xorg-erver-mir and unity- system-compositor into an up to date saucy xubuntu - I'm finding it slow to keep up with scrolling of things like firefox tabs/xchat channel scrollback is particularly bad
<elfy> it's not the same as the typing slow in a terminal issue we saw - that appears to have gone
<Vitor> hello i need some help about graphical support for ubuntu
<smartboyhw> Vitor, you mean, Mir?
<Vitor> somehow yeah
<smartboyhw> Vitor, what's the problem?
<Vitor> i have some problems with all unix versions and i think i has something to do with the latest kernel and i would like to know if mir fix that
<smspillaz> elfy: I've noticed that the displayed frames don't always keep up with the surface submitted frames
<smspillaz> elfy: I think its a known issue?
<Vitor> the prob its that if i install any of the last unix versions like ubuntu 13.10 or mint 15  my screen foes black and i cant do anything...
<smartboyhw> Vitor, Ubuntu 13.10 is NOT recommended for end-users
<Vitor> soz my bad i mean 13.04
<Vitor> on installation i run the usb or cd and it goes all black
<smartboyhw> Vitor, Mir isn't available for 13.04...
<smartboyhw> And I don't think Mir can help you if you even can't install
<Vitor> yeah but do u know where can i have more details bout that my graphical problems on linux?
<smartboyhw> !xorg
<ubot5> The X Window system is the part of your system that's responsible for graphical output. To restart X, type 'sudo /etc/init.d/lightdm' on an ubuntu system. replace with kdm on Kubuntu. To fix screen resolution or other X problems: https://wiki.ubuntu.com/X/Config/Resolution . Also see !xorgconf
<smartboyhw> Vitor, I really don't know.. And to be honest, #ubuntu or ##linux might be a better idea
<Vitor> i tried ubuntu channel but noone ever answer ...
<smartboyhw> Vitor, try again tomorrow, there are less people answering on weekends
<smartboyhw> Try ##linux also
<elfy> smspillaz: sounds like the thing I've seen - unfrtunately  I'm not able to see if any of the existing bugs are this - I'll just try mir again sometime before Xubuntu need to make a decision
<elfy> thanks though:)
<smspillaz> elfy: I'm not entirely sure at the moment. The client I'm working on now I know has some issues to do with frames being submitted at the wrong time so I could just be that we're seeing different things
<smspillaz> *it could jsut be
<smspillaz> late-night typing is not working very well I see ...
<elfy> :)
<robert_ancell> RAOF, hey, why did we need to split out libmirplatform?
<robert_ancell> I thought we should, but I couldn't think of a reason why
<robert_ancell> thomi, btw, I arrive a day later to Lexington due to holiday and decided to go to NYC for the weekend so no flight overlap
<robert_ancell> Interestingly none of the options from the travel agent had bad layovers
<thomi> robert_ancell: you're hitting NYC on the way home?
<robert_ancell> thomi, yep
<thomi> cool :)
<thomi> maybe the flights from NYC are better somehow
<thomi> anyway, my layover isn't too bad I suppose
<robert_ancell> thomi, I also had the options for the Boston flights, and they weren't bad. Though they were flying on Friday and I asked for Saturday flights
<thomi> ahhh, that might be it - I needed Satureday flights
<robert_ancell> So maybe Sat is a bad day to fly
<thomi> yeah
<robert_ancell> grr, why did dufly arbitrarily bump the soname on libmirserver?
<robert_ancell> thomi, do you know if bug 1210811 is still applicable? Looks like some packages got temporarily out of syn
<robert_ancell> c
<ubot5> bug 1210811 in unity-system-compositor (Ubuntu) "/usr/sbin/unity-system-compositor: Symbol `_ZTVN3mir26DefaultServerConfigurationE' has different size in shared object, consider re-linking *** Error in `/usr/sbin/unity-system-compositor': malloc(): memory corruption: 0x0000000000b1c680 ***" [Undecided,New] https://launchpad.net/bugs/1210811
<thomi> robert_ancell: I don't know, I was going to ask you about that today
<thomi> robert_ancell: I can kick off the test jobs again, and try and go through the results again
<thomi> robert_ancell: however, it's worrying that this can get all the way into distro!
<thomi> hmmm, actually, maybe robotfuel is still using the ppa
<robert_ancell> thomi, ah, I see it
<thomi> oh?
<robert_ancell> libmirserver is one day ahead of u-s-c
<robert_ancell> Though, they should be versioned to make that impossible to install
<robert_ancell> hum, not sure,
<robert_ancell> u-s-c is 0.0.1+13.10.20130809.1-0ubuntu1
<robert_ancell> Dependencies.txt shows libmirserver1 0.0.8+13.10.20130810-0ubuntu1
<robert_ancell> Not sure if those match or not. Need to check with didrocks
<thomi> ok
<RAOF> robert_ancell: Because libmirserver is SOVERSIONED, but libmirplatform isn't. So when libmirserver bumps SONAME conflicts happen.
<robert_ancell> RAOF, conflicts between?
<robert_ancell> Oh, you can't have both packages installed?
<RAOF> Yah
<robert_ancell> bingo
<robert_ancell> RAOF, so debian/rules is now wrong right - it refers to libmirserver0
<robert_ancell> I think that's the cause of bug 1210811
<ubot5> bug 1210811 in unity-system-compositor (Ubuntu) "/usr/sbin/unity-system-compositor: Symbol `_ZTVN3mir26DefaultServerConfigurationE' has different size in shared object, consider re-linking *** Error in `/usr/sbin/unity-system-compositor': malloc(): memory corruption: 0x0000000000b1c680 ***" [High,Triaged] https://launchpad.net/bugs/1210811
<RAOF> Flying home via NYC?
<RAOF> Ah, yes. Balls
<robert_ancell> I'll fix it..
<robert_ancell> RAOF, can you review https://code.launchpad.net/~robert-ancell/mir/fix-exact-version-dependency/+merge/179619
<RAOF> Done and approved.
<RAOF> Are you guys flying in on Friday & Saturday? Why not Sunday?
<robert_ancell> RAOF, I'm flying in Monday night, because I have a long weekend booked
<RAOF> Heh. Well timed!
<robert_ancell> Good old timezones make it possible to arrive at a reasonable time
<robert_ancell> Should get there midnight
<RAOF> I should get there 9-10ish Sunday.
<robert_ancell> RAOF, do we have a catch-all comment for issues like bug 1210646?
<ubot5> bug 1210646 in Mir "XMir doesn't work with Nouveau" [Undecided,New] https://launchpad.net/bugs/1210646
<robert_ancell> Also, I love the me too comment. "I have exactly the same problem but I'll describe a different symptom and entirely different hardware"
<robert_ancell> By catch-all I mean a "Do steps x,y,z to give us enough info to diagnose video hardware problems"
<RAOF> )
<RAOF> :)
<RAOF> robert_ancell: I don't have a pre-canned resopnse.
#ubuntu-mir 2014-08-04
<duflu> RAOF: Got a fix for devel cooking?  https://bugs.launchpad.net/mir/+bug/1351133
<ubot5> Launchpad bug 1351133 in Mir "Incomplete removal of libmirprotobuf causes reverse dependencies to FTBFS" [High,Triaged]
<RAOF> duflu: Have I not proposed that?
 * duflu double checks
<duflu> Can't see it
<RAOF> Bah.
<RAOF> I did it first, but didn't push it.
<RAOF> duflu: Enjoy
 * duflu prefers other forms of enjoyment
<RAOF> https://code.launchpad.net/~raof/mir/finish-off-mirprotobuf-removal/+merge/229374
<duflu> RAOF: Glad to have a proposal to approve. ;)
<duflu> RAOF: Err we appear to have broken mirclient dependencies used by gtk-3.0 in the coming Mir 0.6.0 :(
<duflu> So things outside-the-silo (gtk 3) won't work any more
<RAOF> duflu: Really? What's the error?
<duflu> https://bugs.launchpad.net/mir/+bug/1352149
<ubot5> Launchpad bug 1352149 in Mir 0.6 "libmirclient.so.8 ABI broken but not incremented in Mir 0.6.0" [High,New]
<RAOF> No, that's ok.
<RAOF> Or, at least, it should be.
<duflu> RAOF: What? The old one can linger?
<RAOF> Absolutely.
<RAOF> It'll be NBS (not built from source), but it's not an ABI break.
 * duflu tries it
<seb128> RAOF, nbs means the new source is going to be blocker in proposed by britney (if I understand correctly what you are saying)
<seb128> blocked even
<RAOF> seb128: And so gtk3 gets a no-change rebuild, and we go back to base for debriefing and cocktails?
<seb128> yes
<seb128> just need that no change rebuild ;-)
<seb128> well, if it's really no change
<RAOF> It really is.
<seb128> wait
<seb128> you are dropping a .so from a binary without renaming it?
<RAOF> Yes.
<seb128> shrug
<RAOF> Dropping libmirprotobuf entirely.
<seb128> that's going to make gtk apps fail to start
<seb128> nothing is going to block mir to migrate in that context
<seb128> but gtk, until rebuild, is going to try to load that library and fail to load
<seb128> you can't do that
<RAOF> gtk will have a dependency on the libmirprotobuf package, right?
<seb128> is that a package
<RAOF> Yup.
<seb128> or is a .so in a binary that is not going away?
<RAOF> It's a .so in a package that *is* going away.
<seb128> oh, ok, it was properly split
<seb128> k, in this case all good
<seb128> thanks for replying, sorry for the noise
<RAOF> No problem :)
<RAOF> Good to have you in to UTC+lots :)
<duflu> seb128: I'm just checking that issue ;) https://bugs.launchpad.net/mir/+bug/1352149
<ubot5> Launchpad bug 1352149 in Mir 0.6 "libmirclient.so.8 ABI broken but not incremented in Mir 0.6.0" [High,Incomplete]
<duflu> RAOF: Do you remember the ldd equivalent command that doesn't list dependencies of dependencies?
<anpok_> objdump -p bin?
<duflu> anpok_: Ah yes, thanks
<duflu> Also: objdump -x /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 | grep NEEDED
<duflu> Oh, -p is shorter :)
<duflu> camako: Anything blocking 0.6.0 that needs my help today?
<camako> duflu, yeah there was yet another blocker
<camako> duflu, alan_g is working on it though
<duflu> camako: Awesome. Why haven't I seen it?
<duflu> OK
<camako> (or will work on it)
<camako> duflu, it was in the downstream libs
<duflu> camako: I'm accumulating branches that need a lot of fixing before reproposing them. Just checking on the state of things before I dive back into those large tasks
<camako> alan_g's branch is up but not finalized
<camako> duflu, understood. I think I might pick up the last couple of commits made on devel, too.
 * duflu looks
<camako> duflu, after I make sure they don't break downstream.
<camako> specifically, would be nice to pickup r1811
 * camako is not sure if downstream components were tested before r1811 was approved.
<duflu> camako: Best to keep 0.6 unmodified. I've started lining up items for 0.6.1 later (which is easier since there's no ABI break then)
<camako> duflu, yeah probably
<duflu> OK, I've now reached my code review argument limit for the day.
 * duflu goes to working on actual code
<duflu> RAOF: Can you attach any known branches to this? https://bugs.launchpad.net/mir/+bug/1293944
<ubot5> Launchpad bug 1293944 in Mir "Mir deb packages with versioned names cannot be installed simultaneously any more" [Medium,In progress]
<RAOF> duflu: WIP
<duflu> RAOF: OK, so long as no proposed ones should be there already
<RAOF> duflu: That was https://code.launchpad.net/~raof/mir/privatise-all-the-things/+merge/228796 , but it's WIP while I get proper platform probing going.
<alf_> RAOF: Hi! It turns out that we send a lifecycle connection lost event to ourselves when we release a client connection. Is this on purpose?
<RAOF> alf_: Yes
<RAOF> alf_: Because there didn't seem to be any reason not to, and this allows cleanup code to be in one place: the lifecycle event handler.
<alf_> RAOF: the only complication is that we send a SIGTERM in the default lifecycle handler (which wasn't working well before, but is fixed by https://code.launchpad.net/~afrantzis/mir/client-lifecycle-terminate-properly/+merge/229234)
<RAOF> Yeah, I noticed that. Why are we doing that, and why aren't we sending SIGQUIT?
<RAOF> I guess having it overridable is better than libX11's âI KILL YOU WITH A SWORDâ SIGPIPE, but...
<RAOF> alf_: Need me to do anything now? Otherwise I'll EOD.
<alf_> RAOF: No, thanks, just wanted to ensure we send the event on purpose.
<alf_> RAOF: Enjoy your day!
<bschaefer> racarr, hey, do you know that cursors: mir_omnidirectional_resize_cursor_name and mir_closed_hand_cursor_name are the same?
<bschaefer> also have you had the time to get a crosshair cursor landed :)?
<racarr> bschaefer: I think omnidirectional resize cursor
<racarr> and closed hand are only the same
<racarr> in the ubuntu theme
<racarr> but omnidirectional resize maps to "fleur"
<racarr> and closed hand maps to "grabhand" or something
<racarr> grabbing
<racarr> ill look in to crosshair I cant remember why I skipped it
<racarr> maybe ubuntu default them didnt have it...
<bschaefer> interesting, yeah x11 uses fleur in place of grab hand
 * bschaefer switches to omnidirection
<bschaefer> racarr, theres also the case of
<bschaefer> case SDL_SYSTEM_CURSOR_NO:        shape = XC_pirate; break;
<bschaefer> missing
<bschaefer> the CURSOR NO seems to be like an X marks the spot on a treasure map
<bschaefer> racarr, but cool, and thanks!
<racarr> cursor no lol...
<racarr> bschaefer: Maybe it's "disabled"
<racarr> not as in disabled cursor
<racarr> but
<racarr> disabled action
<racarr> like clicking here is not a valid
<racarr> action
<racarr> whioch I guess we dont have a cursor for either :)
<racarr> lol XC_pirate
<racarr> ...plus caret = "xterm", etc...
<racarr> its like someone was intentionally trying to be funny with the cursor names -.-
<RAOF> Bah.
<RAOF> Why is mir_discover_gtest_tests suddenly segfaulting during global construction?
 * RAOF tries a dist-upgrade.
<racarr> haha oh no...I have been all happy that my qtmir acceptance test is supposedly passing but just realized the client should actually get denied connection....
<RAOF> Hah
<RAOF> Ba baw!
<racarr> oh no I guess it shouldn't
<RAOF> Hm. libstdc++6 upgrade, you say?
<racarr> that logic is in the other part
<racarr> that may be related :p
<racarr> mir_discover_gtest_tests is not segfaulting for me
#ubuntu-mir 2014-08-05
<RAOF> So, now that I'm building clang, libstdc++6, *and* mir at the same time it's probably time to turn on the coffee machine.
<RAOF> Hm. We're not actually well set up for having platform plugins out of tree, are we :)
<RAOF> The MirPlatformType enum is particularly egregious.
<racarr> Yeah I was thinking about that today...restubbing
<racarr> the platform
<racarr> (for qtmir acceptance stuff...whether or not that should be done that way is another thing)
<RAOF> I think I'm about to introduce an honest-to-god stub platform.
<RAOF> But it's going to lie about being gbm.
<RAOF> And, obviously, if we got an nvidia or AMD or Qualcomm or whatever platform there's that fun.
<racarr> honest to god stub platform?
<racarr> in what senbse
<RAOF> In that it's got a client-platform-stub.so and a server-platform-stub.so that the regular platform loading machinery can deal with.
 * duflu wonders what happened to the header-only driver design. That was nice
<RAOF> We never had a header-only driver design, because that can't work?
<RAOF> I mean, if the driver is only a header, then it needs to be built in at library-build time?
<duflu> RAOF: I mean the only dependency pulled into driver code is a header. The driver provides the object code to fulfil the contract of the header
<RAOF> We still have that.
<RAOF> I think. I've obviously not tried recently :)
<RAOF> Certainly for the client platform that's true.
<duflu> RAOF: OK, that sounds nice. It would mean linking to libmirplatform is completely optional and unnecessary if you can provide your own logic
<duflu> Hence, no one can question the licensing
 * duflu wants to write drivers for Mir, just to get a feel for what it's like
<RAOF> You can easily question the licensing - the driver is being loaded into a GPLv3 process and will be using symbols from that process.
<duflu> RAOF: Not if it's *not* using symbols from that process. That's the point of a careful header design
<RAOF> Yeah, but that's basically impossible for C++.
<duflu> RAOF: Not sure if C++ makes it impossible, but C would be nice
<RAOF> Implementing the class requires symbols from the definition.
<RAOF> Heh, yeah. That does make it easier.
<duflu> RAOF: You're still thinking backwards. Drivers should (and can theoretically) use zero symbols from us
<duflu> Of course, I want to write a driver to get a feel for how hard it is right now
<RAOF> I'm pretty sure they can't use no symbols from us.
<RAOF> Certainly the client platform library cannot use no symbols from us, because it needs the symbols for the ClientContext* we pass it.
<seb128> hey there
<seb128> what's the difference between XMir and rootless X support in Mir?
<duflu> RAOF: I don't think declaring it impossible is helpful. Although I'll drop the topic for now because we're some way from that kind of license-independent architecture. Keep it for future-Mir
<RAOF> seb128: Nothing.
<seb128> looking at slides which have the first one for next cycle and the other one for the cycle after, are both solutions to allow running xapps/libreoffice/...?
<RAOF> seb128: Rootless X support (in XMir) is for seamlessly running X11 apps in a Unity8 session.
<duflu> seb128: XMir has a root window by default (always draws the whole screen), and so is not "rootless". Rootless lets you run X apps in someone else's shell
<seb128> so XMir = can run e.g libreoffice in fullscreen
<seb128> rootless = can run libreoffice as a window under Mir/unity8?
<RAOF> seb128: Yes, ish.
<seb128> thanks
<duflu> seb128: The app can be a window either way. Rootless just means you don't have the X desktop in the way
<RAOF> seb128: It's a little more like XMir (non-rootless) = X-under-a-system-compositor
<duflu> But who cares about X when the toolkits are native to Mir? (!) :)
<RAOF> duflu: And rooted means that you need to be running a Window manager in there :)
<duflu> Ugh, yeah that sucks resources. Then again X will suck resources either way
<seb128> lol
<seb128> thanks guys
<seb128> just reviewing slides
<seb128> have to go back in the part of the office where internet keeps dropping now, I might drop offline
<duflu> They have a Faraday cage?
<RAOF> And there we go. A proper stub platform passes the tests. Yay!
<RAOF> Well, most of them.
<RAOF> Those which aren't explicitly testing the android client platform apparently.
<duflu> Hah. The universe is determined to drive me insane today. Now the smoke alarm is beeping at me in case it wasn't working yet
<RAOF> And we (finally!) have a fully-passing test suite, bar the ABI checks.
<RAOF> HUZZAH!
<duflu> RAOF: W00t
<duflu> RAOF: The scripts to help with the ABI checks should land soon
<alan_g> camako: is there a qtmir branch corresponding to Mir-0.6? (The corrections to the .pro files don't work with Mir-0.5 as its .pc files are broken)
<alan_g> camako: https://code.launchpad.net/~alan-griffiths/mir/revisit-package-config/+merge/229414/comments/556881
 * camako looks
<camako> alan_g, thanks for fixing! But the fixes should really go into the devel-mir-next branches (for both u-s-c and qtmir). At least one of the fixes (new_ipc_...) has already been fixed in that branch (so this would conflict). We have the devel-mir-next branches in the silo also, which makes it convenient for the release..
<camako> http://bazaar.launchpad.net/~mir-team/qtmir/devel-mir-next/
<camako> http://bazaar.launchpad.net/~mir-team/unity-system-compositor/devel-mir-next/
<alan_g> camako: OK. I'll redo the MPs
<camako> alan_g, thanks and sorry for the double work - I shoulda told you earlier...
<alan_g> camako: done
<camako> alan_g, great thanks
<camako> alan_g, have you tried building unity-mir?
<camako> and papi?
<alan_g> camako: on my list (I thought we'd s/platform-api/qtmir/
<alan_g> )
<camako> alan_g, actually qtmir is supposed to replace unity-mir...
<alan_g> Sorry, thinko
<camako> alan_g, but unity-mir is in the silo as well for that new_ipc_.... fix
<camako> alan_g, please use the mir-next-devel branches for these as well
<camako> http://bazaar.launchpad.net/~mir-team/platform-api/devel-mir-next/
<camako> http://bazaar.launchpad.net/~mir-team/unity-mir/devel-mir-next/
<camako> alan_g, argh... have you seen the conflict on revisit-package-config?
<alan_g> camako: Another one?
<camako> alan_g, I think there was only one.. so you've seen it I guess..
<alan_g> camako: -c 1818
<camako> alan_g, yep I just saw that... Ok good..
<alan_g> camako: unity-mir builds against lp:~alan-griffiths/mir/revisit-package-config
<camako> alan_g, is that the devel-mir-next branch?
<alan_g> ak
<camako> great
<alan_g> camako: and platform-api/devel-mir-next/
<camako> alan_g, great
<anpok> hm i am to slow
<alf_> anpok: too slow for what?
<dandrader> alf_, hey, if a mir client dies but the compositor sill has hold of one of its surfaces, will the whole ring buffer be kept alive or just that specific surface that the compositor has?
<duflu> dandrader: The queue is removed immediately. Any buffer held by the compositor stays (refcounted) and is freed when the compositor is finished with it
<alf_> dandrader: duflu: hmm, on the contrary, I see that the queue stays alive until the compositor buffer is returned to it, but of course the mir surface itself is gone
<alf_> dandrader: how does this affect you?
<dandrader> alf_, I would just like to know. either behavior works for me. I was just wondering about the memory consumption during such a situation
<dandrader> ie, whole ring buffer in memory vs. just the single surface that comp has.
<dandrader> 'cause I'm changing unity8 to take a screenshot with half-resolution and release the surface in such situation. so I was wondering how much of an improvement to expect in memory consumption
<alf_> dandrader: OK, so as I said, my understanding is that the queue stays alive. The idea was that the compositor only holds buffers for a small amount of time (just the time it needs to render with). If a surface is released while it is being rendered, the rendering will finish (and all buffers destroyed then). Do you need to keep surface buffers for more than a frame?
<dandrader> alf_, currently if an app gets killed after being suspended (due to out of memory situations) it will remain in the spread and so unity8 (ie qtcomp) release the surface only once either the app "card" is manually closed by the user or it gets restarted
<dandrader> alf_, not saying it's the right thing to do. is just what's happening atm
<dandrader> working on fixing that currently
<alf_> dandrader: understood
<alan_g> greyback: any opinion? https://code.launchpad.net/~alan-griffiths/mir/command-line-handling/+merge/229255/comments/556930
<greyback> looking
<greyback> alan_g: not a major preference, I just voted to keep the argc/v pattern
<alan_g> greyback: thanks
<groot_> hello guys
<groot_> kdub: I'm still unable to boot :(. Maybe I'm looking at the wrong problem. So I thought of checking this from your perspective.
<groot_> I made a clean install and took logs. Can you check it? Maybe you'll discover something I didn't see.
<groot_> here are the logs. If you need any other logs, let me know.
<groot_> logcat: http://paste.ubuntu.com/7960829/
<groot_> kernel: http://paste.ubuntu.com/7960833/
<groot_> lightdm: http://paste.ubuntu.com/7960835/
<kdub> groot_, a clean install won't help, something needs changing in hybris or the mir code
<kdub> groot_, did you try those hybris tests?
<kdub> although, i guess if the backup is working, the gles/egl stuff is probably okay
<kdub> W/libc    ( 2117): pthread_create sched_setscheduler call failed: Operation not permitted
<kdub> a somewhat suspicious line
<kdub> but really, remember we determined that we weren't getting the function hooks out of hwc? thats still the main problem
<groot_> kdub, sorry, net problem :|. You're telling something about libc warning?
<kdub> groot_, its slightly suspicious, but I'd guess not the root cause
<kdub> but really, remember we determined that we weren't getting the function hooks out of hwc? thats still likely the main problem
<groot_> kdub, but we checked those using if condition, and the function was returning 0 as result. So, isn't this clear the hwcomposer.so of suspicion?
<kdub> well, we aren't getting the function hooks in mir still
<alf_> greyback: dandrader: with dash-as-app I noticed that I can't launch apps any more (but I can scroll). Is this a known issue?
<dandrader> alf_, you should be able to launch apps
<dandrader> alf_, you mean cannot launch from the dash but can scroll in the dash and switch scopes?
<groot_> kdub, I tried to use surfaceflinger by removing .display-mir and 30-no-surface-flinger file from ubuntu image. Then I got "no suitable eglconfig found" warning. Is this related also to mir.
<dandrader> alf_, can you launch from the launcher?
<alf_> dandrader: right, but I can launch from the launcher
<kdub> groot_, if you did that, then mir should not have been running, so that would be something funny with surfaceflinger? (i think that code path has bitrotted a bit, not sure of the sf output path anymore)
<greyback> kdub: unity8 does not support running under SF any more
<groot_> kdub, yes, only sf was running then. I meant, does mir use eglconfig too? Then maybe mir also can't find this config.
<kdub> groot_, mir does have to select a config, but we havent seen that problem
<kdub> also, since the fallback works, it does find a usable config
<groot_> kdub, the fallback graphics just shows the ubuntu logo. Nothing else. It just loops between logo and welcome screen, I can't use anything. Only power button works.
<alf_> dandrader: greyback: let me retry with latest image to ensure it's not a problem with my setup
<kdub> groot_, oh, so that sounds like a separate problem... you have the screen up and working
<dandrader> alf_, yeah, it really should be working
<kdub> groot_, ubuntu has 2 programs running... "USC" drives the framebuffer, and unity8 is a client of usc
<kdub> groot_, and the problem seems to be that unity8 isn't coming up
<kdub> groot_, try with the fresh install in backup mode, you might have broken abi between mir and unity8 in the mir experiments
<groot_> kdub, yes, I was so happy when I saw the welcome screen :). Hmm, I checked in /home/phablet, but there's no unity8.log there.
<dandrader> alf_, are you compiling the branches yourself (for dash-as-app)?
<kdub> groot_, /home/phablet/.cache/upstart/unity8.log ?
<groot_> kdub, yes. There's not even .cache folder.
<groot_> kdub, so try without the hwcomposer.so? I did that and it just loops like I said. But threre was unity8.log file. Also, in logcat there was error like "EGL_BAD_MATCH". Would you like to see ?
<alf_> dandrader: no, installing from landing-007 ppa
<kdub> groot_, may as well
<groot_> kdub, here's the log. Logcat: http://paste.ubuntu.com/7961110/
<groot_> kernel: http://paste.ubuntu.com/7961118/
<groot_> unity8 only shows this http://paste.ubuntu.com/7961119/
<alf_> dandrader: is there a recommended way to install from the ppa or is: add-apt-repository, apt-get update, apt-get dist-upgrade ok?
<dandrader> alf_, sounds right
<dandrader> alf_, having problems?
<alf_> dandrader: no, I just noticed I will install some other updates too (language packs) with dist-upgrade
<dandrader> alf_, it shouldn't be a problem now that qtcomp has landed. there won't be conflicting packages or anything
<dandrader> alf_, so those recommendations from the old qtcomp silo no longer apply
<kdub> groot_, so the unity8 isn't connecting to the system compositor, why... I don't know
<kdub> but we know the system compositor is up and the spinner app has connected to it
<groot_> kdub, hmm it even shows introduction page sometimes (like swipe to right, left). But then again goes back to logo :(
<alf_> dandrader: ok, thanks... so everything seems to be working with r172 + ppa, so probably false alarm
<groot_> kdub, it seems at first boot there's only welcome screen. If I boot second time, it goes to intro screen and more logs are available in unity8.log.
<dandrader> alf_, phew...
<groot_> Here it is http://paste.ubuntu.com/7961246/
<alf_> dandrader: perhaps it was a temporarily glitch in r171, who knows... I'll keep my eyes open for it 8)
<kdub> groot_, not sure what could be the root cause, might make sense to file a bug
<dandrader> alf_, fwiw there's a know bug (not sure if reported) that when you go back to the dash it's still showing the previous frame, so when you tap on it immediately after getting back to it you might hit an icon different from what you're seeing
<dandrader> then if you scroll it a bit to force redraws you get to see the current frames
<dandrader> qtmir (qtcomp) flaw
<groot_> kdub, but this only happens if I remove hwcomposer. Should I file a bug about this or about the issue when hwcomposer is present ?
<greyback> dandrader: we need to figure that out. It could be USC bug more that qtmir
<kdub> groot_, may as well for both. i can comment on what I know on the hwcomposer one
<kdub> the other one I'm not so sure what your device might be doing differently
<groot_> kdub, all right. BTW, our device use hwcomposer version 0.3 which is very old. Google removed support for it long ago, but we added it back in source. Will mir have a problem with this?
<kdub> oh yeah, a big problem :) mir supports the backup mode and hwc 1.0 and newer
<groot_> kdub, damn it. I knew I should've told you about this before. So what happens now? We can't run UT?? :(
<kdub> well, you can run using the backup mode
<kdub> the problem up in unity8 seems to be something different
<groot_> kdub, so there's no way to run UT with hwcomposer? I've to look for fix in backup mode ?
<kdub> groot_, by removing the hwcomposer.so, mir is forced to use the backup mode
<groot_> kdub, looks like I've no other option. I'll try to boot with backup mode. Do you guys have any plans to add support for older version of hwcomposer in future ?
<kdub> groot_, no plans, although the version is nicely abstracted from the other versions that are supported
<groot_> kdub, so adding support for any version wouldn't be difficult? I'll try with backup mode for now, if it boots then probably someone from our device section can help with integrating 0.3 support.
<kdub> groot_, lets just say "its not impossible"
<alf_> Saviq: FYI, unity-dash still consuming a constant 5%-8% CPU when doing nothing (even when screen is off), probably something scope related, https://bugs.launchpad.net/unity8/+bug/1339883
<ubot5> Launchpad bug 1339883 in Unity 8 "unity8 on the phone has unreasonable CPU usage when system is idle with screen off" [High,New]
<Saviq> alf_, will get suspended with dash-as-app soon ;)
<Saviq> alf_, you can try with silo 7 :)
<groot_> kdub, ok :). I'll probably be disturbing you with backup mode from now :P
<anpok> groot_: what kind of device is that?
<groot_> anpok, Sony Xperia U
<groot_> first series from sony
<alf_> Saviq: I am using dash-as-app, dash still consuming CPU long after screen has been turned off...
<alf_> Saviq: but we should make it not consume CPU regardless of suspending :)
<Saviq> alf_, sure ;)
<Saviq> alf_, do we have a bug for this?
<alf_> Saviq: https://bugs.launchpad.net/unity8/+bug/1339883 is the bug I filed before dash-as-app, noted in the comment that it still applies for dash as app (of course the htop traces will not be exactly the same)
<ubot5> Launchpad bug 1339883 in Unity 8 "unity8 on the phone has unreasonable CPU usage when system is idle with screen off" [High,New]
<Saviq> alf_, thanks
<alf_> Saviq: np, hopefully the battery will last a bit longer when we fix this :)
<qengho> Hi all. I'm on 14.04 still, and trying mir in X for testing some client. It looks like keyboard events are delayed because of buffering or maybe some key-combo scheme. I press 'x' in a terminal, and it doesn't go to the client until I press the next key or some amount of time passes, about 0.75 second.  Typing 'asdf' sends 'asd' then... 'f'.
<qengho> Though, right now, I had to change the quoted 'asdf'. I hit arrow keys to move the cursor. I heard the GUI bell signal immediately, but the cursor still didn't move until the second elapsed.
<tvoss> qengho, hey there :)
<tvoss> qengho, trying to clarify on your setup: you are running X on Mir, or Mir on X? :)
<qengho> Hah.  Er, mir on X, I think. ps  =>  /usr/bin/X -core :1 -seat seat0 -auth /var/run/lightdm/root/:1 -mir x-1 -mirSocket /tmp/mir_socket -nolisten tcp
<tvoss> qengho, ah, that's X running against, or as we call it: XMir. So I remember the event delay issue with XMir, but I remember that we fixed it. May I ask you for the specific version of Mir that you are running?
<qengho> mir tools and libraries 0.1.8+14.04.20140411-0ubuntu1
<qengho> xserver-xorg-xmir 2:1.15.1-0ubuntu2
<qengho> I have not flipped to Utopic on this machine.
<tvoss> qengho, ah, thanks for the information. That might be the issue then. kgunn, could you take a look here ^?
<tvoss> qengho, I'm pretty sure the bug is fixed, but not necessarily available in trusty, yet
<tvoss> qengho, searching for the bug number
<tvoss> qengho, https://bugs.launchpad.net/mir/+bug/1199450
<ubot5> Launchpad bug 1199450 in mir (Ubuntu) "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Critical,Fix released]
<kgunn> yeah, and i've even seen a delay show up in straight x every now and then
<qengho> tvoss: it says Merged into lp:ubuntu/saucy/mir, so I would expect T to be fixed too, but it is not.
<tvoss> qengho, you are running on Intel?
<qengho> The immediate Bell suggests it is that a final frame not rendered. I realize now that the delay is indeed fixed at the next cursor blink.
<qengho> tvoss: Yes. Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09)
 * qengho avoids the problem by opening a terminal and "while sleep 0.05; do date; done", to force buffer churn.
<qengho> Is environment variable "MIR_SERVER_NAME" the preferred way to have my client test whether to use its mir output?
<qengho> Is there an x2mir yet?  This is killing my multi-machine one-keyboard setup. ;(
<kdub> if x2mir is the inverse of xmir, there are some emulators, but I don't know of a 'native x2mir'
<Saviq> camako, something went wrong with your qtmir devel-mir-next branch, the changelog entry moved below the currently released one
<Saviq> camako, FWIW there's no need for you to put the changelog entry there manually - just write stuff in the MP commit message and the train will convert that into a proper changelog entry
<Saviq> kgunn, shall we drop unity-mir from silo 7? we should drop it from distro anyway?
<racarr> Going to land this unless anyone objects soon https://code.launchpad.net/~mir-team/mir/touchspot-visualizer/+merge/228903
<racarr> so hopefully can land the renderables tomorrow or some such
<racarr> I think daniel had abstained in the previous submission and kdub had approved
<kgunn> Saviq: let's touch base on that tomorrow
<racarr> oO
<racarr> the sudo password on my emulator image
<racarr> is not phablet...
<racarr> and adb shell to root + passwd phablet
<racarr> gives a bad authentication token
<racarr> I seem to be unable to get root on my own emulator image
<racarr> anyone know anything about the password
<racarr> changing?
#ubuntu-mir 2014-08-06
<duflu> Eeek. Involved in too many code reviews again.
<duflu> It keeps happening
<RAOF> :P
<RAOF> You could quickly approve https://code.launchpad.net/~raof/mir/pkgconfig-harder/+merge/229719 :)
<RAOF> It'd be difficult to get examples/ to build using the pkg-config files, as they get generated at build time.
<duflu> RAOF: Yeah I know. But it's a worthy goal to be able to test for basic linkage mistakes in *.pc
<alan_g> alf_: quick check - are you happy with the latest mods? https://code.launchpad.net/~alan-griffiths/mir/command-line-handling/+merge/229255
<alf_> alan_g: sure, whatever our users need :)
<Saviq> greyback_, camako, tvoss, we got three almost-ready silos for qtmir, what order do we want to land those in/
<tvoss> Saviq, I would really appreciate silo 10 going in asap
<Saviq> tvoss, you should stop rebuilding it all over again ;)
<greyback_> Saviq: I need to test silo2, it's not massively urgent though
<Saviq> kk
<Saviq> so 10, 7, 2
<tvoss> Saviq, well, all platforms need to be green :)
<Saviq> tvoss, well they're not gonna be https://launchpadlibrarian.net/181653818/buildlog_ubuntu-utopic-ppc64el.trust-store_1.0.0%2B14.10.20140806.5-0ubuntu1_FAILEDTOBUILD.txt.gz
<tvoss> Saviq, yup
<camako> Saviq, our testing just started and we _are_ seeing problems... so I'd say don't wait for 7 if you have others ready..
<Saviq> camako, noted
<alan_g> alf_: I know how little you love spelunking through debian/control and .pc files. But you've done it recently enough to remember could you take a look over this? https://code.launchpad.net/~alan-griffiths/mir/versioning-libmirplatform/+merge/229488
<alf_> alan_g: sure
<tedg> Just to be curious, why isn't Mir on powerpc and ppc64el ?
<tvoss> tedg, some missing build-dep
<alan_g> tedg: IIRC there was some dependency that wasn't available. (I don't remember what it was, so I can't check if that is still true.)
<tedg> Ah, okay. Don't like seeing errors now that I depend on libmir-client :-)
 * kdub sees
<kdub> Unknown command line options: --vt 1
<kdub> and unity8 startup i get
<kdub> complaints about not finding libmircommon
<rsalveti> kdub: is AlbertA off?
<kdub> rsalveti, yes, until monday
<rsalveti> thanks, will open a bug then :-)
 * kdub will watch for it
<rsalveti> kdub: basically https://bugs.launchpad.net/ubuntu/+source/powerd/+bug/1353647
<ubot5> Launchpad bug 1353647 in unity-system-compositor (Ubuntu) "No powerd suspend blocker after boot (just after first screen off/on cycle)" [Undecided,New]
<rsalveti> wanted to ping him because he is the one that did that piece mostly
<kdub> ah, yeah
<bschaefer> hey, have dialog windows been implemented in mir? Or rather, im seeing The system has encountered an error dialog box when starting unity8 on the desktop
<bschaefer> but theres no x server running...
<racarr> unless someone did it secretly I am not aware of dialogs in unity/mir
<bschaefer> racarr, turns out im getting a crash?
<bschaefer> http://pastebin.ubuntu.com/7973040/
<bschaefer> but i still dont know how those dialogs were appearing
<bschaefer> racarr, this could be my fault with using trunk mir as well....
<bschaefer> err devel
<racarr> anyone know how to build qtubuntu package with debug symbols...
<racarr> I thought it was just qmake CONFIG+=debug but I put CONFIG+=debug in the root .pro file
<racarr> and didnt end up with debug symbols
<racarr> printf will do fine I guess
<racarr> oh gr...
<racarr> how to build qtubuntu-android i386 packages
<racarr> (thats right lol)
#ubuntu-mir 2014-08-07
<RAOF> I guess it's too soon to be passing --std=c++1y? :)
<duflu> Wait, what? I was utterly convinced today was Wednesday
<RAOF> Oh, it's not!
<RAOF> ...
<RAOF> And you somehow made me think it was Tuesday!
<duflu> That is honestly shocking. I do recall several very long work days. No wonder the fridge is quite empty
<RAOF_> Hah!
<RAOF> Conflicts in since lunch. Yay!
<duflu> RAOF: Sorry, I think. It's a problem we all suffer from occasionally
<RAOF> Eh. Very simple conflicts.
<RAOF> Hah. Whoops.
<RAOF> I've tested all the things except actually wiring up the probe in the DefaultServerConfiguration! :)
<RAOF> Ok. I think I'll call that EOD.
 * duflu waves to RAOF
<duflu> alf_: Do you have a fix in mind for bug 1353867? If not I would just propose a revert of the offending change. As crashing is more helpful than an infinite loop
<ubot5> bug 1353867 in Mir "[regression] Nexus4: Mir client gets caught in an infinite exception loop if the server crashes ("Caught exception at Mir/EGL driver boundary")" [High,Triaged] https://launchpad.net/bugs/1353867
<alan_g> duflu: are your concerns addressed? https://code.launchpad.net/~alan-griffiths/mir/versioning-libmirplatform/+merge/229488
<duflu> alan_g: Sorry, distracted. I'll check this arvo
<alf_> duflu: Yes, I have a fix, I am just waiting for https://code.launchpad.net/~afrantzis/mir/better-client-api-override/+merge/229479 to land to propose
<duflu> alan_g: One of those days where I just don't get on top of everything. Checking it now...
<alan_g> duflu: np - it happens to us all
<racarr_> Is anyone else having...entire system randomly freezes in utopic kind of issues (with alarming frequency)
<racarr_> I feel like maybe alf was or something?
<kdub> like, the desktop?
<racarr_> yeah
<racarr_> freeze/unfreeze sort of stuff lol
<racarr_> its been a few weeks now and is really starting to push my patience so starting to feel like I should dig in to cause
<racarr_> and thought I remembered alf was having something like this
<racarr_> on radeon evergreen as well
<racarr_> android...build...so long.
<racarr_> RAOF: p.s. what were you saying about an honest to god stub platform
<racarr_> I had to make, another one for https://code.launchpad.net/~mir-team/qtmir/server-client-acceptance/+merge/230018 and now to add more tests I have to make it better (or perhaps just end up copying the one from mtf...)
<racarr_> ...still...building...android
<RAOF> racarr_: https://code.launchpad.net/~raof/mir/privatise-all-the-things/+merge/228796 has some of an honest-to-god stub platform.
<RAOF> racarr_: At least, it has platform-graphics-dummy.so and client-platform-dummy.so.
<racarr_> RAOF: How did it end up there?
<RAOF> racarr_: Because I needed some dummies to test.
<racarr_> ah
<racarr_> hmm 6 hours is a long time even for jenkins ;) (want to see a + 1 on touchspot-renderable before EOD)
#ubuntu-mir 2014-08-08
<racarr_> back in a few hours
<RAOF> Bah. We have two nearly identical places where we probe the graphics platform.
<RAOF> I always forget to update one :*
<RAOF> Bah, cmake.
<RAOF> Why can't you pkgconfig correctly?
<alf_> racarr_: yes, at some point when heavy rendering is going on the whole system freezes for some time and then continues normally, I "solved" it by going back to the latest 3.15 kernel. Perhaps an early 3.16 kernel will do but I haven't had the time to bisect.
<alf_> RAOF: duflu: Hi! Any idea about http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2347/console ?
<alf_> (see failure at end of log)
<RAOF> alf_: Yup:  Package libboost-program-options-dev is not installed.
<RAOF> Not using apt + a repository strikes again!
<duflu> alf_: It seems build-deps are prepared based on the system installation. And those are wrong for the new tree being built. Someone needs to kick in the new package ... libmirplatform-dev:armhf depends on libboost-program-options-dev; however:
<duflu>   Package libboost-program-options-dev is not installed.
<duflu> So.. it's only CI that's broken :/
<duflu> ... or our x-compile scripts. I thought Alberto made them smart and this should happen automatically
<duflu> ... assuming CI uses our scripts
<RAOF> duflu: Incorrect!
<RAOF> :)
<duflu> RAOF: OK *shrug*. I care not for new problems this week :/
<duflu> There's plenty of old problems still
<RAOF> alf_: Want to try with /~raof/+junk/testrunner-testing/? :)
<duflu> alf_: I stole your bug BTW ... bug 1340510
<ubot5> bug 1340510 in Mir "session screen seen upon quick power key strike" [Medium,In progress] https://launchpad.net/bugs/1340510
<alf_> duflu: Ah, good, thanks. I wanted to unassign myself since I got caught up with other things, but forgot.
<alf_> RAOF: sure, how do I try that?
<RAOF> alf_: I've already started - http://s-jenkins.ubuntu-ci:8080/view/mediumtests/job/mir-mediumtests-runner-mako/2348/console
<alf_> RAOF: great, thanks
<RAOF> Faster, silly device!
<RAOF> Bah. Stupid thing.
<RAOF> alf_: Died with a transient unrelated error, so I've started it again.
<RAOF> Sweet.
<RAOF> Looks like that's working.
<RAOF> alf_: That looks like it's good; feel free to push that branch to the main testrunner bit.
<RAOF> EOW for me!
<alf_> RAOF: Thanks! Enjoy you weekend!
<alan_g> alf_: is "libmirplatform:armhf to be configured is 0.5.1+14.10.20140728-0ubuntu1" being addressed or should I jump on it?
<alf_> alan_g: RAOF's update to the test runner fixes this /~raof/+junk/testrunner-testing/, I will merge into our "upstream" testrunner branch
<alan_g> Excellent
 * alan_g goes off to play with parsing our code with libclang
<greyback> alf_: hey, I've not dug yet, but I fear our "last frame not drawn" bug has appeared again https://bugs.launchpad.net/unity8/+bug/1354407 - it may be qtmir, and it may be mir. Just an FYI as yet
<ubot5> Ubuntu bug 1354407 in Unity 8 "last frame not being drawn - left edge swipe reveals old frame of dash, need to interact with it to refresh it" [Undecided,New]
<alf_> greyback: ack
<racarr> Morning.
<racarr> late psuedo standup: Still working on emulator bug...have something to test now but not 100% sure how to build an appropriate image (modified the emulator target egl impl)
<racarr> proposed a qtmir test skeleton
<racarr> sigh touchspot renderables failed
<racarr> the sha1sum check again due to other stuff landing
<kdub> groan
<racarr> I'm considering making an mp that deletes it and adds a file like
<racarr> README-release.txt
<racarr> that has a checklist which includes
<racarr> 1. Have any headers in include/ changed
<racarr> which is just as easy to tell from the diff
<racarr> as looking at the sha1sum file
<kdub> yeah, I think part of the problem too is we need to firm up the interfaces
<kdub> like look at how the downstreams are using the interfaces
<kdub> and then bury the stuff they arent using
<racarr> mm
<kdub> and make sure those that are used are sensible
<kdub> thats not quite the immediate problem, but along the same tangent and important
<racarr> my guess is there is a bunch of stuff that could be hidden at this point but not sure
<kdub> yeah, and even more if you take the set of stuff that is only used by the demo shell
<alan_g> We don't want to be quite that strict - there's likely stuff we should expose that hasn't been used for the phone
<kdub> yeah, agreed
<kdub> I guess my main point is that an audit of the interfaces would help
<tedg> Can I turn on the Mir LTTng tracepoints with an env var, or is it something I need to compile in?
<racarr> env variable!
<racarr> tedg: see doc/component_reports.md
<racarr> http://unity.ubuntu.com/mir/component_reports.html
<racarr> so e.g. MIR_SERVER_INPUT_REPORT=lttng
<racarr> I doubt that list of reports is up to date
<racarr> lol
<tedg> Ah, cool.
<tedg> So I guess that needs to go in the session startup script
<tedg> I'd like to get a report on when surfaces are allocated and displayed
<tedg> Looking at app startup
<tedg> Which would be helpful? :-)
<racarr> tedg: You could get that from the session mediator report which logs IPC calls I guess
<racarr> i.e. create_surface
<tedg> racarr, Cool, thanks!
<racarr> :) np
<racarr> rsalveti: Ping?
<racarr> I am trying to test changes to the emulator libEGL...and having some difficulty understanding exactly how the emulator images are assembled
<rsalveti> racarr: https://wiki.ubuntu.com/Touch/Emulator
<racarr> rsalveti: So I see on one hand there is the -system parameter to the emulator binary and then also
<racarr> the system.img is copied in to the
<racarr>  /var/lib/lxc...etc and mounted at boot
<racarr> what is the deal with that?
<racarr> Having to deviate from the instructions slightly for various reasons so trying to understnad what is happening
<racarr> rsalveti: also having terouble understanding the raw disk vs ...non raw distinction
<racarr> also what is the ubuntu-*system.img vs just
<racarr> system.img
<racarr> sorry...im really unknowledgeable about the whole image business I guess :)
<racarr> haha...ok now I tried using raw disks, so now I can mount my new ubuntu-system.img and found
<racarr> a libEGL with a new md5sum so I guess that worked
<racarr> well
<racarr> nvm lets see what happens when I replace system.img with ubuntu-*system.img
<racarr> actually lets have lunch
<racarr> brb
<racarr> ohhhh
<racarr> theres a system.img
<racarr> inside the system.img
<racarr> ...
<racarr> grr
<racarr> Yay it works
<racarr> it turns out the system.img that building the android source package produces is the system.img inside the system.img inside the sdcard.img that creating an emulator instance
<racarr> creates
<racarr> and the third system.img is just a decoy
<racarr> (the one outside the sdcard.img)
<racarr> lol
<racarr> how does something like that happen
<rsalveti> racarr: yeah, it's horrible
<rsalveti> we're fixing that soon
<rsalveti> really confusing atm
<racarr> rsalveti: :D
<qengho> racarr: Hi hi.  I tried to convert your Chromium ozone-mir branch into a distro patch for current stable Chromium -- really the only way I can use it -- and I had some trouble.  Do you have some time to help me debug it?
<qengho> As I understand it, we would like to avoid code duplication with ozone-wayland, so we try to extend it, overriding where we need to.
#ubuntu-mir 2014-08-09
<racarr> qengho: Hi I have some time but not that much focus left on this friday :)
<racarr> that is correct, wrt to ozone-wayland...though...there is more code duplicated than there used to be already because of
<racarr> uh...philosophical differences or whatever :p
<qengho> racarr: I'm trying to figure out the compile flags. ozone_platform_wayland=0  leaves symbols undefined, and yet defining it seems to try to initialize two different schemes at run time.
<racarr> qengho: You mean use_ozone_platform_wayland?
<racarr> The last time I built was with use_ozone_platform_wayland=0...which symbols are undefined?
<racarr> have yuo also applied the patches in the patches folder in ozone mir?
<racarr> qengho: Anyway I need to go eat, but please mail me the symbol failure and I will try and help
<qengho> racarr: I put the tiny script I wrote on chinstrap:~cmiller/chromium-mir-apply-patch . It extracts code from your branch, "cp" and "patch", and produces a distro patch. There's some preamble on running that should help explain what and why.
#ubuntu-mir 2015-08-03
<RAOF> Oh, damnit.
<RAOF> Who thought calling alarm->cancel() from an alarm's callback was a sensible thing to do?!
<guest42345> !seen mir 0.15
<ubot5> I have no seen command
<guest42345> sudo apt-get remove ubot5
#ubuntu-mir 2015-08-04
<duflu> RAOF: Can you check and confirm Mesa is fixable, and not intrinsically doing the right thing already?... https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1480755/comments/5
<ubot5> Ubuntu bug 1480755 in Mir "[regression] Some Mir EGL demos don't get bypassed any more in fullscreen" [Medium,In progress]
<RAOF> Checking...
<RAOF> Oh, damn.
<RAOF> *Of course* it passes under ThreadSanitizer and normally but not under valgrind.
<RAOF> *Of course* it passes under ThreadSanitizer and normally but not under valgrind.
<RAOF> ...but only when tracking fds?
<RAOF> No?
<RAOF> Oh, right. --trace-children
<duflu> RAOF: Yeah that's a gotcha from binary wrapping. I sent out an email but we've all forgotten now.
<duflu> RAOF: P.S. I'm using this tag for the pixel format related issues (and more?): https://bugs.launchpad.net/ubuntu/+source/mesa/+bugs?field.tag=egl-platform-mir
<RAOF> Hurray for valgrind accidentally finding race conditions.
<RAOF> Also, it'd be *really* nice if we could move into our lambdas.
<duflu> RAOF: shared/unique_ptr should do
<RAOF> Well, unique_ptr clearly doesn't, because you can't move it into a lambda :)
<duflu> RAOF: Parameter by value?
<duflu> Or capture
<RAOF> Can't by value; it's not copyable.
<RAOF> I can emulate what I want with a shared_ptr, but it'd be cleaner without.
<duflu> Sweet. In other news, switching my new monitor to DP 1.2 mode Mir now sees 4 DP outputs (multi-stream)
<RAOF> Superb
<duflu> Still max 3 simultaneous outputs??
<duflu> Not sure about that
<duflu> Hmm, or was it just a kernel upgrade and I haven't looked in a while
<duflu> ?
<duflu> RAOF: Yeah confirmed putting the monitor in DP1.2 mode is what gives me twice the outputs available. Unfortunately DP1.2 mode is not understood by the Linux framebuffer and it (along with Plymouth) is in a low-res BIOS mode
<duflu> X and Mir both handle it well tho
<duflu> I would have thought kernel 4.1 would be more current than that
<RAOF> Time for kmscon!
<duflu> !
<RAOF> I am apparently going to need to fix each and every race in Mir before I can land this thing...
<duflu> anpok_...?
<duflu> anpok_ ?
<anpok_> duflu: tuesday!
<anpok> AlbertA: should we land your fix or cherry pick christophers?
<AlbertA> anpok: heh I'm about to push the cherry picked solution from Chris
<anpok> +1
<camako> https://code.launchpad.net/~cemil-azizoglu/mir/add-packaging-for-mir-on-x/+merge/266915/comments/670098
<camako> vogons, ^^ known failure?
<kdub> not known to me at least
<anpok> camako: a fix is about to land
<AlbertA> camako: yes: https://code.launchpad.net/~albaguirre/mir/fix-1481034/+merge/266781
<anpok> this the shutdown race during the synthetic exception in the input thread
<camako> ok thanks... I remember seeing it on other MPs
<RAOF> GAH! Why does http://bazaar.launchpad.net/~albaguirre/mir/fix-1481034/revision/2808 compile?
<RAOF> Alternatively, why did my attempts to do the same fail to compile?
<RAOF> Oh! By moving the std::shared_ptr<promise> rather than the std::promise.
<RAOF> Yeah, that'd work âº
#ubuntu-mir 2015-08-05
<RAOF> Ok. *That* was a race in my code :)
 * RAOF heads due luncheon
<RAOF> Ok.
<RAOF> Ok.
<RAOF> OK.
<RAOF> That *should* fix all the races in https://code.launchpad.net/~raof/mir/fix-deadlock-in-glib-alarm/+merge/266682
<ogra_> poor duflu ... seems i actually stirred up something with my input delay bu
<ogra_> *bug
<duflu> ogra_: The earlier we know about them the better. You're doing us a great service :)
<ogra_> (looks like you are getting from one rabbithole into the next all the time)
<duflu> ogra_: Yeah sometimes you just need to stop looking
 * duflu -> EOD
<ogra_> heh
<ogra_> enjoy
<alan_g> greyback: When you have a moment, could you have a look. (I can't imagine my qtmir changes caused it but it is worrying). https://jenkins.qa.ubuntu.com/job/qtmir-wily-amd64-ci/73/console
<greyback> looking
<greyback> alan_g: doubt it's your fault, looks like the dbus test harness is failing
<greyback> pete-woods: hey, any ideas how we can debug that ^^
<greyback> it's using dbusmock, and failing with C++ exception with description "Process [python3] for service [com.canonical.powerd] failed to appear on bus" thrown in the test fixture's constructor.
<alan_g> greyback: thanks
<pete-woods> greyback: looking
<pete-woods> (sorry, was having lunch)
<pete-woods> greyback: does this happen if you do a debuild locally?
<pete-woods> this can happen if the build server is super heavily loaded
<pete-woods> it waits 5 seconds for the python process to start
<pete-woods> that's probably not enough, actually
<greyback> pete-woods: not happening locally for me anyway
<pete-woods> (it uses QSignalSpy::wait)
<pete-woods> which has a default timeout of 5 seconds
<pete-woods> this should maybe be upped to 30 seconds
<greyback> you'd think 5 secondsis enough to bring up python. But if you've seen it randomly on servers, it'll do no harm to bump it
<pete-woods> as starting a new python process can take quite a while on a low memory / loaded system
<greyback> alan_g|lunch: could you retry the build, just to see
<alan_g> greyback: ack
#ubuntu-mir 2015-08-06
<RAOF> duflu: Do you have a working mako handy?
<RAOF> duflu: Mine is in flat-battery purgatory for the moment, and I was wondering if you could try running https://code.launchpad.net/~raof/mir/fix-deadlock-in-glib-alarm/+merge/266682 on it locally to see if you can reproduce the crash in CI?
<duflu> RAOF: Yes and no. My mako is heavily hacked and I'm not wanting to change anything until I finish my performance work on it. Although I could run local builds...
<RAOF> duflu: That's fine. I'll try building in a vivid chroot and deploying...
<shengchieh> hi, guys. I met a mir exception error(0.12.1) when bootup on a arm device. so i try to rebuild mir with ./cross-sompile-chroot.sh but the built library can not be lunched functional on arm target. Does any one has the same experience and know how to solve it?
<duflu> shengchieh: Got a log of what the exception says?
<duflu> shengchieh: Also, feel free to log bugs and any issues you have can be discussed and resolved offline: https://bugs.launchpad.net/mir/+filebug
<shengchieh> the log is : $/usr/share/ubuntu-touch-session/usc-wrapper --file'/run/mir_socket' --from-dm-fd 9 --to-dm-fd 13 --vt 1
<shengchieh> Warning:ignoring unrecognised arguments: --vt 1
<shengchieh> [527.561310]Server: Starting
<shengchieh> [527.562040]Loader: Loading modules from: /usr/lib/arm-linux-gnueabihf/mir/server-platform
<shengchieh> [527.562228]Loader: Loading module:/usr/lib/arm-linux-gnueabihf/mir/server-platform/graphics-mesa.so.1
<shengchieh> [527.567219]Loader: Loading module:/usr/lib/arm-linux-gnueabihf/mir/server-platform/graphics-dummy.so
<shengchieh> [527.576294]Loader: Loading module:/usr/lib/arm-linux-gnueabihf/mir/server-platform/graphics-android.so.1
<shengchieh> [527.578435]Platform Loader: Selected driver: android (version 0.11.0)
<shengchieh> Killed
<duflu> shengchieh: It sounds like you have built Mir 0.12 but have 0.11 installed on the system. That's OK, but if you're running a binary from 0.12 then it needs to find the drivers for 0.12 and not the system ones. Try setting environment MIR_SERVER_PLATFORM_PATH=(path to server-modules/) and MIR_CLIENT_PLATFORM_PATH=(path to client-modules/)
<duflu> Also, Mir 0.14 is released. We recommend using that.
<shengchieh> Hi duflu,  thanks for your suggestion, but we overwirte the previous .so files and use the same folder.
<duflu> shengchieh: Then you also need to overwrite /usr/lib/arm-linux-gnueabihf/mir/... with your newly built drivers
<duflu> Although other parts of the phone will then fail (broken ABIs)
<shengchieh> We can not use Ubuntu's mir, because we have an integration issue with our devices.... Our EGL query an information which mir does not support
<shengchieh> That's what we need to modify somethin in mir to fit our egl
<shengchieh> Here comes original error log: [157678.315339] <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in query): /build/buildd/mir-0.12.1+15.04.20150324/src/platforms/android/server/server_render_window.cpp(90): Throw in function virtual int mir::graphics::android::ServerRenderWindow::driver_requests_info(int) const
<shengchieh> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
<shengchieh> std::exception::what: driver requests info we dont provide. key: 10
<shengchieh> So, we need to build a modified graphics-android.so.1 for our devices.
<duflu> shengchieh: Good news: grapphics-android.so is not device specific. It's just Mir-version-specific
<duflu> shengchieh: It appears your problem is that mir-team broke the ABI of graphics-android.so.1 between releases 0.11 and 0.12 but failed to bump the ABI number. So that's a problem. Although overwriting the binary using your 0.12 build is probably the only option
<shengchieh> So, should I use mir 0.11 and have a build to  test it again?  I want to make sure the so files can be executed successfuly first.
<shengchieh> But I am confused about my mir version, becase based on the log, it looks like 0.12
<shengchieh>  /build/buildd/mir-0.12.1+15.04.20150324/src/platforms/android/server/server_render_window.cpp
<duflu> shengchieh: Yes, a recent Ubuntu Touch installation should have no Mir version older than 0.12 on it. The 0.11 issue sounds like it's from a stale package. Try uninstalling the driver package that is versioned 0.11* and replace it with the 0.12 driver package
<duflu> It should be called mir-platform-graphics-android1
<shengchieh> Sorry, I am newbie for ubuntu touch, can I knnow how to uninstall the driver? thanks.
<duflu> shengchieh: Or download the latest 0.12 packages for armhf here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-013/+build/7105384
<duflu> shengchieh: Make sure you have a working internet connection on the device, then: sudo mount -o remount,rw / ; sudo apt-get update ; sudo apt-get dist-upgrade
<duflu> Should fix it completely actually
<alan_g> greyback: just a FYI - I've pushed my WIP on window management to lp. There's a bunch of prerequisites already queued but you've seen most of them. https://code.launchpad.net/~alan-griffiths/qtmir/window-management/+merge/267181
<greyback> alan_g: many thanks, shall have a loo
<greyback> k
<dandrader> anpok_, ping
<kenvandine> greyback, http://paste.ubuntu.com/12013841/
<greyback> kenvandine: why is mouse-primary-button-enum != primary-button-enum ?
<kenvandine> whoops
<kenvandine> i think that was a mistake
<kenvandine> greyback, http://bazaar.launchpad.net/~ken-vandine/unity8/mouse_touchpad_schema/view/head:/data/com.canonical.Unity8.gschema.xml
<greyback> kenvandine: ok, looks reasonable, now need to see what mir supports!
<kenvandine> greyback, great, thanks
<greyback> anpok_: hey, you've knowledge of the input stack, can you have a look at Ken's xml file above and see if Mir would have any built-in support for those settings?
<alan_g> camako: can you confirm whether this is OK with your Mir-on-X work? https://code.launchpad.net/~andreas-pokorny/mir/disable-android-input-stack-when-platform-available/+merge/267022
<camako> alan_g, will do
<AlbertA> cool a short example exhibits the same GCC5 armhf bug...
<AlbertA> http://pastebin.ubuntu.com/12014642/
<AlbertA> now to report the issue...
<alan_g> AlbertA: it /could/ be simpler. Vis: "int main()"
<alan_g> thanks for tracking it down
<AlbertA> alan_g: heh true...force of habit
<greyback> AlbertA: hey, could I get you to rebase lp:~albaguirre/qtubuntu/use-mir-surface-apis on top of lp:~dandrader/qtubuntu/busySwap-lp1473720. I want to land both, but they conflict
<AlbertA> greyback: np
<greyback> ta
<bschaefer> AlbertA, nice find!
<AlbertA> greyback: ok I merged daniel's branch into https://code.launchpad.net/~albaguirre/qtubuntu/use-mir-surface-apis/+merge/262257
<greyback> AlbertA: could you please re-propose the MR, with daniel's branch as a prereq. Just to keep reviews clear
<AlbertA> greyback: done
<greyback> thank you
<anpok_> greyback: will take a look
<greyback> anpok_: thanks. I know libinput probably has support for more bits, but we're stuck with android input on phone, yeah?
<anpok_> nope..
<anpok_> we can settle with one
<anpok_> interesting part is.. we might have to apply that per session..
<greyback> eh? use-case?
<greyback> we don't want clients of unity8 to have their own input config
<anpok_> and thus either expose the settings to usc, and let usc apply it... or apply those settings within nested mir...
<greyback> I vote for USC
<anpok_> just a matter of where to put the code.. and when to switch settings
<greyback> or make a special mir_client interface for neste servers, which adds bits like this
<anpok_> exposing the setting to usc.. might mean that there is client api for config.. yes..
<anpok_> greyback: how are those speed settings defined?
<anpok_> i mean... are there more detailed descriptions available or is this just a list of required settings and we shall figure out which ranges are reasonable?
<greyback> anpok_: it's just a list of required settings really
#ubuntu-mir 2015-08-07
<RAOF> Alright!
<RAOF> We've gone from mako: unresponsive to mako: angry red flashing light!
<RAOF> Progress!
<duflu> RAOF: Woo! Mine went to warranty repair several times for non-charging issues. Glad yours is back
<RAOF> Yeeeees!
<RAOF> We have a bootloader!
<ljp> always a good sign
<bschaefer> duflu, yeah bregma was saying there is a circuit issue where it needs power to charge haha
<bschaefer> soo if it dies, it cant charge
<bschaefer> s
<bschaefer> opps
<columbobaas> Mir, when will it be stable?
<alan_g> columbobaas: what does stable mean to you?
<columbobaas> Usefull as daily driver
 * ogra_ uses his phone all day since over a year ... definitely fine as daily driver 
<alan_g> At least a year ago
<columbobaas> and on desktop?
<alan_g> That's more dependant on other parts of the stack than Mir.
<ogra_> mir is surely ready for the desktop too ... the desktop just isnt yet ;)
<alan_g> There was a Unity7 on Xmir stack around a while back. And there's a Unity8 stack in development.
<alan_g> But if someone were to write a shell with it Mir would work fine.
<columbobaas> Will Ubuntu 15.10 use it you think?
<alan_g> not as default
<ogra_> 16.10 will use Mir as default
<columbobaas> a long time to go
<columbobaas> and until then ubuntu will use unity 7?
<ogra_> yes, there will be an ubuntu personal image in parallel, based on snappy ... that will be released alongside withh the unity7 16.04 release
<ogra_> so you can choose ... the default 16.04 will use unity7 though
<columbobaas> and is there something to change with compiz? Because the desktop of a friend doen't support that well
<greyback_> columbobaas: compiz is for X only. Mir completely replaces it
<columbobaas> Ow, very interesting
<greyback_> kdub: hey, you got some time?
<greyback_> I'm getting USC crashing when plugging in the slimport cable on N7
<greyback_> http://pastebin.ubuntu.com/12021098/
<greyback_> this is with silo0
<greyback_> not crshing with mir_proving_server tho
<ogra_> greyback_, davmor2 just said in another channel that silo0 isnt ready for use yet ... you might have half built stuff there
<ogra_> (it is in the middle of a rebuild)
<greyback_> ogra_: correct, but in this case, I'm the reason it's not ready :)
<ogra_> lol
<ogra_> k
<ogra_> :)
<greyback_> thanks tho
<greyback_> kdub: nor is it crashing with USC alone, it appears to be a consequence of the WindowManagement code
<kdub> greyback_, I can check if lp:mir works
<greyback_> kdub: if you can, it would be a start, thanks
<kdub> i thought silo 0 was a n4-only one though
 * kdub tried to get n7+silo0 working this week, but couldn't find a friendly image for silo0
<greyback_> kdub: n7 should work too, at least it used to
<greyback_> kdub: it should go on top of devel-proposed
<greyback_> use the citrain script to add the silo, so the correct packages are installed (and pinned)
<kdub> greyback_, i can poke around today, might not be able to switch 100%
<kdub> greyback_, takes a while to get set up... stacktrace in the meantime?
<kdub> (mostly from dead batteries)
<greyback_> kdub: this of use: http://pastebin.ubuntu.com/12021098/
<kdub> greyback_, thanks
<greyback_> kdub: another BT, almost exacty the same: http://pastebin.ubuntu.com/12021321/
 * kdub knows that alf fixed some stuff
<kdub> recently... the mir fix for the circa-monday deadlock was actually a backport
#ubuntu-mir 2016-08-08
<duflu> robert_ancell: Hey just FYI, that scrolling speed problem with Xmir, while it has a fix may not get Fix Released as quickly as Xmir itself. We might end up with more people seeing the problem for a while till the next Unity8 update
<robert_ancell> duflu, is that going to affect the SRU to Xenial?
<duflu> robert_ancell: Yes, probably. But only for users of X apps in Unity8 on xenial. I'm not sure that's a major audience
<robert_ancell> duflu, probably not
<duflu> I'm just warning everyone so they expect the duplicate bug reports when they happen
<duflu> It is however a bug that already has a fix
<alan_g> greyback: do the #pragmas have a purpose? g++-6 rightly rejects them, and I don't find a need anywhere. https://code.launchpad.net/~alan-griffiths/miral/compatibility-with-mir-trunk/+merge/302137
<greyback> alan_g: it used to silence compiler warnings due to the UAL header files
<greyback> which made compilation with -Werror fail
<greyback> that situation may have been fixed now
<greyback> though probably not for the qt private header
<alan_g> Where should I compile to check? V+O and yakkety desktop build clean
<greyback> alan_g: yep, v+o most likely culprit
<alan_g> So they're just obsolete.
<greyback> quite probably
<aquarius_> Phone question: how can I launch an application on the phone if Unity 8 isn't running?
<aquarius_> Unity 8 does some jiggery-pokery with setting up its own mir sockets and so on, as far as I can tell...
<alan_g> aquarius_: what are you using as a shell if you're not using U8?
<aquarius_> alan_g: at the moment, assume nothing and that I'm launching apps from the command line. (I'm exploring the idea of a different shell, but the first part is to have some way I can launch apps at all without unity around :))
<alan_g> well, if you mean phone apps (not command line programs) they need a shell/mir server to talk to
<alan_g> It would be like launching an X app without an X server
<alan_g> Doomed
<aquarius_> ya, graphical apps -- qml, whathaveyou. So, question: an app can't launch and talk to mir itself? That's not how Mir works, I take it; something needs to be the "display server", and that's Unity 8?
<anpok> you can launch unity-system-compositor
<aquarius_> so if I don't have unity running, I need to write a separate "dummy window manager" to act as a shell?
<anpok> or you might have it still running..
<alan_g> U8 is the Mir server
<aquarius_> ah! unity-system-compositor is an alternative mir server?
<anpok> u-s-c owns the screen and unity8 connects as a fullscreen client to it
<alan_g> aquarius_: you might find lp:miral a good starting point for an alternative server
<anpok> but in general it seems that you should write an alternative server
<anpok> u-s-c could serve as an intermediate replacement but it only accepts full screen clients
<alan_g> But IIUC you can find what you need in the "running the software" bit of this: http://www.octopull.co.uk/sw-dev/WorkingOnAPhone.html
<aquarius_> full screen clients are fine for my use case (which is very simple at the moment! It might get more complex later, but i'm just exploring)
<anpok> so you are better of launching miral-shell from lp:miral as a client to u-s-c or as a u-s-c replacement.
<aquarius_> so, if I have u-s-c running, I should be able to launch (for example) qmlscene and it should work?
<alan_g> No
<aquarius_> ah, so I still need miral-shell or similar running as well?
<alan_g> USC is very fussy about what connects to it.
<alan_g> aquarius_: have a skim through the above article - you don't need to build things, but it also covers getting control of the screen
<aquarius_> am indeed reading it as we speak :)
<ogra_> wasnt there a tiling WM demo in the mir code somewhere ?
<ogra_> you might be able to spawn that and run your app in it
<alan_g> ogra_: there is, there's also a non tiling one. (But the one in MirAL is a better starting point)
<aquarius_> alan_g: that demo isn't on the phone already, I imagine?
<aquarius_> Certainly I'll take a look at miral, which seems like the right thing to do
<aquarius_> I've just gotta set up a build environment and whatnot to play around with that :)
<alan_g> aquarius_: is isn't installed by default. But if you've e.g. a chroot set up you can install it
<aquarius_> kk
<aquarius_> that makes sense
<aquarius_> I was just sneaily hoping to avoid work ;)
<alan_g> Or if you've made thing RW you can just use apt
 * alan_g doesn't recommend doing that though
<aquarius_> yeah. As it happens I have made this RW so I can experiment with things, but I don't really want to install loads of mad stuff and break the system images just yet
<alan_g> aquarius_: in that case installing mir-demos shouldn't do much harm. And gives you example servers and apps to play with
<aquarius_> oh really? that sounds useful
<alan_g> $ mir_demo_server --test-client mir_demo_client_egltriangle
<alan_g> But to get serious set up a chroot
<aquarius_> certainly I will do when I get serious :)
<ogra_> when will *that* ever happen ?
<aquarius_> ha! shush, ogra ;)
<ogra_> :)
<alan_g> when the first phone bricks
<aquarius_> hm, mir-demos isn't available in the repos. do I need to have a different archive enabled?
<aquarius_> the phone points at vivid stuff
<alan_g> oh, I guess that's in universe
<aquarius_> it is. bah :)
<aquarius_> and vivid stuff isn't available in the archives any more. Can I use the wily version, or does it change in lockstep with newer mir?
<aquarius_> huh. libmirclient9 on the phone is the version from yakkety. So mir stuff is more up to date than it pointing at "vivid" archives would imply :)
<anpok> vivid stuff is in the stable-phone-overlay ppa
<anpok> and xenial stuff too..
<aquarius_> huh, darn. mir-demos 0.21 and 0.23 will both not install for dependency reasons
<aquarius_> I bet I have to be running rc-proposed on the phone to match the version of mir-demos in yakkety.
<alan_g> Don't mix with yakkety - the gcc isn't compatible
<alan_g> Add "universe" in /etc/apt/sources.list, apt update && apt-install mir-demos
<alan_g> Or is that too serious?
<aquarius_> I already have that, though
<aquarius_> deb http://ports.ubuntu.com/ubuntu-ports/ vivid universe
<alan_g> Shouldn't that be deb http://ports.ubuntu.com/ubuntu-ports vivid main universe
<aquarius_> deb http://ports.ubuntu.com/ubuntu-ports/ vivid-updates main restricted is in there too
 * alan_g is out of suggestions
<aquarius_> I suspect this is because mir-demos *was* in vivid universe, but vivid is out of support now :)
<aquarius_> (checks packages.gz file)
<aquarius_> hey! it's there.
<aquarius_> mir-demos, 0.12.1+15.04.20150324-0ubuntu1
<aquarius_> but apt-cache search doesn't find it. That's weird.
<alan_g> It ought to be in the stable-phone-overlay ppa
<alan_g> Probably 0.23
<aquarius_> hm, have I ever actually run apt update on this device?
<alan_g> that would help
<aquarius_> it would rather, wouldn't it :)
<aquarius_> and there it is. Good one, Langridge, you moron
<aquarius_> installed :)
<aquarius_> ERROR: Dynamic exception type: St12system_error
<aquarius_> std::exception::what: Enable multithreading to use std::thread: Operation not permitted
<aquarius_> https://bugs.launchpad.net/mir/+bug/1460868 seems relevant here
<ubot5> Launchpad bug 1460868 in unity8-desktop-session (Ubuntu) "[regression] Mir demo servers don't start at all in release 0.13.1 (mir-platform-graphics-* never installed)" [High,Fix released]
<alan_g> aquarius_: that's familiar (a bug - IIRC there's an LD_PRELOAD workaround)
<alan_g> not that bug
<aquarius_> the bug sorta suggests that i need a mir-graphics-drivers package installed, but I have mir-graphics-drivers-android
<alan_g> https://bugs.launchpad.net/mir/+bug/1577357/comments/5
<ubot5> Launchpad bug 1577357 in mir (Ubuntu) "package-built mir_demo_server does not start on device" [Undecided,New]
<aquarius_> aha!
<aquarius_> LD_PRELOAD=libpthread.so.0
<aquarius_> woo, spinning triangle :)
<aquarius_> very very flickery spinning triangle.
<alan_g> You "forgot" $ sudo stop lightdm
<aquarius_> ah, because unity-system-compositor is still running. I don't want that, right?
<alan_g> they fight
<aquarius_> if I stop lightdm entirely, then the screen goes black
<aquarius_> and running egltriangle doesn't show anything on screen
<alan_g> mirbacklight
<aquarius_> ah, as per the doc
<aquarius_> I did forget that this time :)
<aquarius_> winner!
<aquarius_> that works.
<alan_g> :)
<aquarius_> brill. Now to convince qmlscene to start up :)
<aquarius_> (thank you, alan_g, this is really helpful, btw!)
<alan_g> yw
<aquarius_> so the mir_demo_server is enough to run mir-understanding clients on top, excellent; is there a layer wich goes in between a "normal" app (say, qmlscene, or a compiled Qt app) and mir-demo-server, or does Qt know how to talk to Mir itself?
<anpok> aquarius_: QT_QPA_PLATFORM=ubuntumirclient needs to be set
<anpok> and the user needs to have read write access rights on the MIR_SOCKET opened by the server..
<alan_g> Or more generally: https://bazaar.launchpad.net/~mir-team/miral/trunk/view/head:/miral-shell/miral-run.sh
<anpok> or use the --launch-client <clientbinary> functionality of the various servers.. to avoid having a socket file
<aquarius_> I'm using --test-client
<alan_g> True. --launch-client also deals with the environment variables
<anpok> then qmlscene still needs QT_QPA_PLATFORM
<anpok> oh does it now?
<anpok> ok
<alan_g> That got added in 0.22
<aquarius_> progress!
<aquarius_> LD_PRELOAD=libpthread.so.0 mir_demo_server --launch-client simp.sh, where simp.sh is QT_QPA_PLATFORM=ubuntumirclient qmlscene /opt/click.ubuntu.com/org.kryogenix.fontbrowser/current/main.qml , gives me a tiny mouse pointer in the top left of the screen :)
<aquarius_> ah. org.freedesktop.DBus.Error.NoServer: Failed to connect to socket /tmp/dbus-DTpyAMgnHQ: Connection refused
<aquarius_> and indeed there is no dbus socket there
<aquarius_> although $DBUS_SESSION_BUS_ADDRESS is set. Interesting.
<alan_g> Prefix with dbus-run-session?
<aquarius_> ha haaaaaa!
<alan_g> Or, maybe, go for an app that doesn't use dbus?
<aquarius_> and I have an app running! with no unity 8 at all! score. :)
<aquarius_> brilliant.
<aquarius_> thank you very much alan_g and anpok
<aquarius_> it does still have a tiny mouse pointer :)
<anpok> and you dont want that?
<aquarius_> nope. this is on the phone
<alan_g> aquarius_: tough. This is an *example* of how to use the mir library, not a fully function mir server.
 * aquarius_ laughs
<aquarius_> it wasn't a complaint
<aquarius_> I have gone from zero to demonstrable in about fifteen minutes with your help, which was exactly what I wanted. Doing this properly needs more than just wiring together existing demos
<aquarius_> hence I shall look into miral and so on!
<alan_g> Good luck
<aquarius_> really helpful. Thank you, people.
<alan_g> anpok: that make me think MirAL ought to have a way to detect pointing devices and a way to disable the cursor.
<anpok> yes
<alan_g> anpok: https://code.launchpad.net/~alan-griffiths/miral/more-todo/+merge/302301
<anpok> alan_g: :)..
#ubuntu-mir 2016-08-09
<duflu> alf_: clang+yakkety is back and working today. And general cross compiling works too. Can we get the former at least in CI?
<duflu> That's one fewer jobs requiring +overlay
<alf_> duflu: yes, I will change it
<duflu> Cool thanks
<duflu> alf_: Technically xenial (without overlay) is also supported, and now buildable with the cross compile script if you're keen :)
 * duflu wonders if we need arm64 too
<duflu> or s390 or ppc64
<alan_g> alf_: when you have time: https://code.launchpad.net/~alan-griffiths/miral/debian-control-files/+merge/302274
<alf_> alan_g: I'll try for later today. I am currently looking into an urgent repowerd item.
<alan_g> alf_: np
<alan_g> Good luck with repowerd
#ubuntu-mir 2016-08-10
<alan_g> greyback: do you know the intended usage of mir/shell/persistent_surface_store.h? Or is that something for dandrader?
<greyback> alan_g: not exactly. I see it claims to enable surface position/size persistence across session lifetimes, so WM would find it handy
<alan_g> Note "todo Persistence across shell restarts is as-yet unimplemented."
<greyback> yeah. "claims" :)
<greyback> we're not using it in qtmir/unity8
<alan_g> Yeah, the server APIs are only published in Mir-0.24
<alan_g> So I'm a bit short of clues on what MiraAL should expose
<alan_g> IIRC the current intended usage is for identifying "foreign" surfaces for WM
<RAOF> alan_g: That was a happy accident.
<RAOF> Or, rather, a happy repurposing. It's intended to be the identifier that you use for persistence across restarts, indeed.
<RAOF> Since nothing's using it currently it's not something that'd be interesting to expose from MirAL ATM, and it might not want to be exposed at all (it seems to be something that MirAL could reasonably hide and just DTRT with)
<alan_g> RAOF: As dandrader published the headers I assume that he has plans to use them. (I'd be good with DTRT)
<alan_g> So you see no reason to land any version of https://code.launchpad.net/~alan-griffiths/miral/persistant-surface-store/+merge/302408?
<RAOF> I think you're correct, and WindowManagerTools::window_for_id() is likely to be the winner.
<RAOF> (Commented on the branch)
<alan_g> thanks
<greyback> alan_g: sorry, it is a bit of a monster, I'm unsure how I can break it up into more manageable chunks: https://code.launchpad.net/~gerboland/miral/add-interactivity-to-WM/+merge/302531
<alan_g> greyback: I understand the reasons.
<oSoMoN> does Mir have support for client-side decorations?
<alan_g> oSoMoN: no
<oSoMoN> alan_g, thanks. Are there any plans to support them in the future?
<alan_g> oSoMoN: bug 1398849 has probably the latest info
<ubot5> bug 1398849 in gtk+3.0 (Ubuntu) "Support client-side window decorations (I can see two title bars for GTK on Mir)" [Wishlist,Triaged] https://launchpad.net/bugs/1398849
<oSoMoN> thanks!
<alan_g> dandrader: do you agree with the last comment? https://code.launchpad.net/~alan-griffiths/miral/persistant-surface-store/+merge/302408
 * dandrader checks
<dandrader> alan_g, not familiar enough with miral context to give any useful opinion right now...
<alan_g> dandrader|afk: the basic question is whether we currently expect shells to want more than identifying a surface from an id
<dandrader> alan_g, any usecase in mind?
<alan_g> Oh. I thought you were the one that "published" the PSS headers in Mir. My mistake.
<alan_g> dednick: do you agree with the last comment? https://code.launchpad.net/~alan-griffiths/miral/persistant-surface-store/+merge/302408
<dednick> alan_g: looking
<dednick> alan_g: we need id_for_surface, so unless there's another way getting it...
<dednick> alan_g: i added that functionality in mir http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/3553
<dednick> for the application menus
<alan_g> dednick: presently not exposed through miral. What's the usecase?
<dednick> alan_g: application menus are exposed through dbus using persistent surface id. unity8 need to get the surface for those published ids.
<alan_g> That's "surface_for_id" not "id_for_surface"
<dednick> alan_g: no, unity8 gets the ids from dbus. need to get the surfaces for those ids.
<alan_g> @"<dednick> alan_g: we need id_for_surface," do you have a usecase for id_for_surface()?
<jounih_> hi, Iâm trying to run Unity8 on 16.04 in VMWare but getting a black screen after starting the unity8 session from the greeter. Any ideas?
<dednick> alan_g: huh?
<dednick> alan_g: i just gave you the use case for id_for_surface(). unity8 has the ids, but needs to get the surface. so uses "Id PersistentSurfaceStore::id_for_surface(std::shared_ptr<mir::scene::Surface> const& surface)
<alan_g> to get the surface you call "surface_for_id(the_id)" and get a surface
<dednick> alan_g: lol. of course you do! sorry. apparently my brain isnt working
<alan_g> jounih_: probably a problem with the VMware drivers
<jounih_> Is there a way to get it working?
<dednick> alan_g: in that case, no, there is no current usecase for id_for_surface
<jounih_> itâs the latest version of VMWare and instructions for installing Unity8 from here - http://mhall119.com/2016/05/dogfooding-unity-8/
<dednick> alan_g: in the server. only in the client
<jounih_> I can put logs on gist if anyone wants to have a look?
<jounih_> https://gist.github.com/jounih/96cae2256280f298dfb3f27f922d04c2
<alan_g> jounih_: https://bugs.launchpad.net/mir/+filebug
<greyback> jounih_: it's crashing, someone needs to investigate why
<jounih_> ok I filed a bug
<jounih_> https://bugs.launchpad.net/mir/+bug/1611804
<ubot5> Launchpad bug 1611804 in Mir "Unity8 session is crashing in VMWare" [Undecided,New]
<alan_g> jounih_: thanks!
<mhall119> jounih_: give willcooke a ping, we talked to him yesterday about having a vm or live iso for testing unity 8 and he was going to look into that
<jounih_> I did, he is here
<jounih_> he pointed me to bregma who pointed me here
<bregma> jounih_, did you ever check for a unity8 crash log in /var/crash in your VM?
<jounih_> not yet, iâll atttach those to the bug now
<greyback> bregma: fyi: https://bugs.launchpad.net/mir/+bug/1611804/comments/1
<ubot5> Launchpad bug 1611804 in Mir "Unity8 session is crashing in VMWare" [Undecided,New]
#ubuntu-mir 2016-08-11
<oSoMoN> dandrader|afk, so it seems that calling destroy() in the onClosing handler of the window is what causes the crash, Iâm trying to work around the problem by ensuring that there are no references to the window that was closed left, and then calling the garbage collector with a delay, which works as expected on my unity7 desktop (the window gets destroyed when the GC kicks in), but not on my phone, any idea why?
<oSoMoN> oops, that message was meant to continue a discussion started on #ubuntu-unity, so much for contextâ¦ :/
#ubuntu-mir 2016-08-12
<alan_g> greyback_: your question answered? https://code.launchpad.net/~alan-griffiths/miral/first-cut-at-test-server/+merge/302677
<greyback_> alan_g: ok, yeah. The duplication was concerning me
<alan_g> I couldn't think of a better way that's compatible with existing Mir releases
<greyback_> alan_g: not related to that branch specifically, I am unable to compile miral with your tests enabled: http://pastebin.ubuntu.com/23049421/
<greyback_> missing a linker flag?
<alan_g> greyback_: that looks like lp:1583536
<alan_g> You need Mir-0.24+ (or backport a couple of fixes)
<greyback_> alan_g: ack
<kdub> which is siloed in 36
<kdub> greyback_,
<greyback_> kdub: ah handy. /me cnacels build
 * alan_g wonders what will stop 0.24 landing next
<alan_g> Should we decide it's an unlucky number and go for 0.25?
<kdub> have a fix for the current blocker, hopefully nothing
<kdub> eh, what did block 24 would have blocked 25 too
<alan_g> lp:1612256?
<kdub> alan_g, right https://code.launchpad.net/~kdub/mir/fix-1612256/+merge/302804
 * alan_g is looking
<alan_g> ...and wonders if that fixes a problem with toolkits ignoring the size of window when set by WM
<kdub> alan_g, yeah, it probably does
<alan_g> I'll test that and link as appropriate
<alan_g> Rats! I was sure I'd filed a bug for that.
<oSoMoN> dednick, regarding your request on bug #1596524 , IÂ found a reliable way of reproducing (although with a different, unmerged branch of webbrowser-app), IÂ could provide you test packages if youâre interested (and tbh your help would be welcome as Iâm stuck on that one)
<ubot5> bug 1596524 in Canonical System Image "/usr/bin/webbrowser-app:11:QScopedPointer:qGetPtrHelper:QOpenGLContext::d_func:QOpenGLContext::functions:QSGDefaultLayer::invalidated" [High,Confirmed] https://launchpad.net/bugs/1596524
<dednick> oSoMoN: give me a sec to refresh my brain :)
<oSoMoN> sure
<dednick> oSoMoN: i seem to remember figuring out this was a qt bug but i thought i logged the bug :/
<greyback_> alan_g: https://code.launchpad.net/~gerboland/miral/add-interactivity-to-WM/+merge/302531/comments/781063 - on your second comment, I had to cast as I need access to a few things Window didn't have, RenderableList, input bounds, orientation setter, keymap. That is the shopping list of things MirAL will need to provide so I don't use ms::Surface directly
<oSoMoN> dednick, in the upstream Qt bug tracker?
<alan_g> greyback_: you don't need the cast to construct. C.f. "share_ptr<Surface>{window};"
<greyback_> alan_g: sure. I just did it to be explicit about the conversion points, as I was unsure if miral was to wrap those things or not
<alan_g> Ok that answers the question.
<alan_g> As to MirAL wrapping things, I've not yet exposed anything for compositing.
<greyback_> I wasn't sure if you planned to
<dednick> oSoMoN: maybe not. i can't find anything.
<alan_g> Dunno yet. "Custom compositing" doesn't have quite the requirement you have (and hasn't been thought through). The alternative is to slice out a "QtCompositor" plugin.
<alan_g> But I think that's further than our current planning horizon.
<dednick> oSoMoN: test packages are welcome :)
<oSoMoN> dednick, will build them now and attach them to the bug report along with testing instructions, Iâll ping you when Iâm done
<oSoMoN> (in a meeting right now so it will need another 15min before I get to it)
<oSoMoN> dednick, https://bugreports.qt.io/browse/QTBUG-42213 looks like it might be related
<dednick> oSoMoN: most relevant comment. "Depending on desctruction order and previous GL function resolving, OpenGLContext::currentContext() can be 0"
<dednick> which is what is happening.
<dednick> i know i've seen it before but i can't find the use case...
<oSoMoN> yes
<dednick> greyback: do you remember me discussing this with you? crash when cleaning up scene nodes due to null opengl context.
<greyback> dednick: kinda. Something is deleting the context
<dednick> i think i must have 2 qt accounts. i'm sure i've logged this!
<oSoMoN> dednick, Iâve attached deb packages to reproduce the crash at https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1596524/comments/4
<ubot5> Launchpad bug 1596524 in Canonical System Image "/usr/bin/webbrowser-app:11:QScopedPointer:qGetPtrHelper:QOpenGLContext::d_func:QOpenGLContext::functions:QSGDefaultLayer::invalidated" [High,Confirmed]
<dednick> oSoMoN: ta
#ubuntu-mir 2017-08-07
<RAOF> xnox: Mind if I upload a util-linux patch to fix bug #1708635
<ubot5> bug 1708635 in util-linux (Ubuntu) "Valgrind reports " Uninitialised value was created by a stack allocation" in __uuid_generate_random" [Undecided,New] https://launchpad.net/bugs/1708635
<duflu> RAOF: So it was more random? :)
<RAOF> So it didn't reference uninitialised memory when getrandom() returns ENOSYS, such as on a CI machine running a 14.04 kernel.
<duflu> Oh, right. That's the Linux call and not the ANSI-C pseudorandom call guaranteed to work
<alan_g> RAOF: should we land the workaround for bug 1708635 to unblock, or is a fix immanent?
<ubot5> bug 1708635 in util-linux (Ubuntu) "Valgrind reports " Uninitialised value was created by a stack allocation" in __uuid_generate_random" [Undecided,New] https://launchpad.net/bugs/1708635
<RAOF> alan_g: I've uploaded a fix*
<RAOF> (I've obviously not tested it in CI, but I'm confident it's a fix)
<alan_g> The theory is CI should now work?
 * duflu senses deja vu
<alan_g> duflu: again?
<duflu> Indeed
<RAOF> Oh, woops.
<RAOF> Conflct with package already in proposed.
<duflu> Heh. Welcome to my world (as I was discussing last week)
 * alan_g muses: the other workaround would be to move CI to some builders with a recent kernel.
<ogra_> alan_g, mind taking a look at https://forum.snapcraft.io/t/pyqt5-on-raspberry-locale-problem/1574 ?
<alan_g> ogra_: ack
<ogra_> (not sure what the dbus issue there is, i helped as much as i could with the other bit)
<alan_g> ogra_: the dbus bit is a mystery to me too. I can guess that it relates to the qtubuntu project, and that it's something that broke when we dropped the overlay.
<ogra_> well, i guess the demo apps still work, dont they ? perhaps you can just point him to the source for ideas
<AdamH_> Good Afternoon Gents, perhaps a daft question but is mir-kiosk supported on Ubuntu Server 16.04 or Just on Core? I want to run a Qt app in a Kiosk type setting. Have it work on a RPi but we need more horsepower so think of using a desktop class machine with Ubuntu Server
<AdamH_> Or is there a better way to do this?
<ogra> the mir-kisok snap should surely also work on a classic (server) install
<ogra> *-kiosk
<ogra> (if not, that would be a bug i guess)
<AdamH_> ogra: Thanks I thought it should but can't get it to launch. Will keep troubleshooting in that case
<ogra> file a bug if you cant get it to run ... technically it shouldnt be any different to using it on core
<ogra> i.e. it should auto-start on boot
<ogra> but perhaps you need some additional libs installed that are guaranteed to be there on the core images
<AdamH_> Thanks, definitely not doing that but will make sure basics are covered first.
<ogra> journald (or syslog) should actually have some info ...
<ogra> (a snap always uses a systemd unit to auto-start ... so there should be some errors if that fails)
<AdamH_> Thank you, as a side note how would we change the screen orientation of the mir-kiosk-apps demo to be portrait?
<alan_g> AdamH_: the server image will be missing some part of the "desktop" graphics stack: mesa, mir-graphics-drivers-desktop. If they are in place it should work.
<AdamH_> alan_g: Thanks, mir-graphics-drivers-desktop is already installed, I can see it finds the driver in the syslog but can't start
<alan_g> Could you pastebin the log?
<AdamH_> Yes sure http://paste.ubuntu.com/25262948/
<alan_g> Thanks. The message "Unknown command line options: --vt 1" tells us indirectly that the mesa-kms driver isn't able to initialize (but not why).
<AdamH_> Ah thanks, I did not know that. I wonder if this is to do with me running in a VM
<alan_g> You installed mir-graphics-drivers-desktop from deb archive?
<alan_g> Perhaps it's worth trying the miral-examples deb and running "miral-desktop -kiosk"
<AdamH_> Yes installed from deb, will try the examples and see what happens
<AdamH_> hmmm... Unable to locate package miral-examples, is this available from a ppa?
<alan_g> which series are you on?
<AdamH_> I am using 16.04
<alan_g> /o\ sorry
<alan_g> There's a ppa (ppa:mir-team/staging), but that also has a newer mir in it.
<alan_g> I fear you're best building miral
 * alan_g makes a note that a 16.04 miral ppa would be useful.
<AdamH_> Thank you will give it a go
<alan_g> take lp:miral/release
<alan_g> That corresponds to the snap contents
<alan_g> This should help: https://bazaar.launchpad.net/~mir-team/miral/trunk/view/head:/getting_and_using_miral.md#L131
<AdamH_> alan_g: perfect thanks for that
<AdamH_> alan_g: don't seem to be able to get miral to build, any idea where to look?
<AdamH_> -- Checking for module 'mirclient>=0.26'
<AdamH_> --
<AdamH_> CMake Error at /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:367 (message):
<AdamH_>   A required package was not found
<AdamH_> Call Stack (most recent call first):
<AdamH_>   /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:532 (_pkg_check_modules_internal)
<AdamH_>   CMakeLists.txt:35 (pkg_check_modules)
<AdamH_> -- Configuring incomplete, errors occurred!
<AdamH_> See also "/home/adamheavens/miral/build/CMakeFiles/CMakeOutput.log".
<alan_g> AdamH_: in miral checkout dir: $ sudo mk-build-deps -i
<AdamH_> alan_g: Thank you
<alan_g> AdamH_: or even easier... ppa:alan-griffiths/miral-xenial
<AdamH_> Thank you sir!
#ubuntu-mir 2017-08-08
<alan_g> greyback: I see you looked at this a few months back, maybe you recall? Do we still care enough to keep the bug around? https://bugs.launchpad.net/mir/+bug/1553328
<ubot5> Ubuntu bug 1553328 in qtubuntu (Ubuntu) "Mir/Unity8/USC crashes/freezes on nouveau (nv50) in pushbuf_kref() especially with multiple monitors, webbrowser-app or system settings" [High,In progress]
<greyback> alan_g: I actually have a fix up for that, was due to Qt renderer using threaded GL by default
<greyback> alan_g: what I don't know is if Mir's default renderer would also exhibit the same issue
<greyback> Mir's does use a renderer thread per display, and thus do threaded GL of some form.
<alan_g> Oh, right. Well the default renderer runs a thread per display buffer, so that could indeed be a problem.
<greyback> but it's hard to know how Qt hit that nouveau bug. Perhaps Mir's simpler renderer wouldn't hit it
<alan_g> Maybe "incomplete" in Mir until we know.
<greyback> *nod*
#ubuntu-mir 2017-08-10
<RAOF> xnox: Re: bug# 1708635 - did you check out the util-linux PR I put up? Are you happy to cherry-pick the first commit of that onto util-linux/artful?
<RAOF> xnox: https://github.com/karelzak/util-linux/pull/492
