[13:05] <WaVeR> Tribaal> They extended the deadline.  at leat no stress in this events period
[13:08] <Tribaal> WaVeR: ack


[00:15] <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.
[01:24] <smspillaz> RAOF: heh, I'm just thinking about how well the multithreaded callbacks would interact with the GIL
[01:25] <RAOF> Easily! You marshal everything into a single thread!
[01:25] <smspillaz> RAOF: of course. But ideally you'd probably want to do that in a separate library and then bind to that
[01:26] <smspillaz> since otherwise you'd have crazy locking overhead
[01:26] <smspillaz> (*based on a vast oversimplication of the GIL)
[01:27] <smspillaz> RAOF: I remember it was quite surreal when racarr was explaining that to me while we managed to get lost on the bart
[01:27] <RAOF> Heh
[01:29] <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
[01:31] <duflu> RAOF: Hmm, there's no /Mir/ in any live images yet, right?
[01:32] <duflu> smspillaz: Also, if you're receiving non-input surface events, that's a different thread again :)
[01:33] <duflu> I mean :S
[01:33] <smspillaz> duflu: yeah, iirc it was one thread for surface events and one thread for input events
[01:33] <duflu> smspillaz: https://bugs.launchpad.net/mir/+bug/1194384
[01:34] <smspillaz> duflu: I don't think the threading is a problem, rather - the whole MirEvent is just awkward
[01:34] <smspillaz> *MirEvent thing
[01:34] <smspillaz> I much prefer the wayland approach -> every unique event happens in its own callback
[01:35] <duflu> smspillaz: Can you elaborate?
[01:35] <duflu> Because technically all events have their own callbacks
[01:35] <duflu> Or you mean callback type?
[01:36] <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
[01:36] <smspillaz> (afaict)
[01:36] <smspillaz> duflu: callback type
[01:36] <duflu> I see
[01:36] <smspillaz> duflu: unions are a kinda sucky way of representing data like this
[01:36] <smspillaz> see XEvent
[01:36] <duflu> It is nice to be able to take shortcuts and sometimes handle different even types in a single callback
[01:37] <duflu> Not to mention, nice to avoid the user learning many callback prototypes
[01:37] <smspillaz> and then you end up with a thousand-line long "Event" callback
[01:37] <smspillaz> which is made worse by the fact that it may be called in multiple threads simultaneously
[01:38] <smspillaz> and the only real way to fix that would be to dispatch the potentially giant switch statement into separate functions
[01:38] <smspillaz> ... which might as well be done at the client library level
[01:39] <smspillaz> see for instance: https://github.com/smspillaz/xbmc/commit/ddab367b4928bc50f168d157b6b4939f3062402a#L2R78
[01:40] <smspillaz> (ah, my bad, wayland does actually give you the surface the event happened on)
[01:41] <duflu> smspillaz: Fair point. I would then say... use a single callback prototype demultiplexed at registration:    set_event_handler(filter, callback)
[01:41] <smspillaz> duflu: eg - wl_pointer_add_listener :)
[01:43] <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 ....)
[01:44] <smspillaz> but eg: https://github.com/smspillaz/xbmc/commit/ddab367b4928bc50f168d157b6b4939f3062402a#L2R36
[01:49] <duflu> smspillaz: BTW pointer events are meant to be surface-relative in Mir too. It's just not implemented yet
[01:50] <duflu> -pointer +motion
[02:24] <duflu> That's odd. My Mir performance dropped about 5% over the weekend (after updates)
[02:26] <duflu> But it's only compositing performance that dropped. Bypass results are unchanged
[02:33] <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.
[02:33] <duflu> TheDrums: Ah thanks. That explains the new bug reports from Xubuntu users against Mir
[02:34] <TheDrums> Yes, seems while several of the Mir devs were sent the message, you were not one of them.
[02:36] <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.
[02:36] <skellat> Unless we were running exterior serial consoles, we wouldn't have had a way to recover such.
[02:38] <TheDrums> duflu<EMAIL_ADDRESS>is the message.
[02:41] <duflu> skellat, I know that now. About to fix it
[03:22] <RAOF> ♪ And on that farm he had a laptop ♫
[03:30] <duflu> RAOF: Awesome! (?)
[03:31] <RAOF> Yes.
[03:32] <duflu> RAOF: Quad core IPS SSD goodness?
[03:32] <RAOF> Correct
[03:33]  * duflu gives all builds to RAOF
[03:44] <duflu> RAOF: What's the key "depth" like?
[03:45] <RAOF> It's pretty shallow, but typable.
[03:47] <RAOF> Luncheon.
[05:16] <tvoss_> good morning :)
[05:17] <tvoss_> RAOF, ping
[05:17] <tvoss_> duflu, ping
[05:18] <RAOF> tvoss_: Pong
[05:20] <tvoss_> duflu, ping
[05:43] <duflu> tvoss_: pong
[06:00] <tvoss_> alf__, duflu could you guys please sync up on the multi-monitor and switch-branch integration? A summary by mail would be great!
[06:01] <alf__> tvoss_: duflu: sure
[06:03] <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...
[06:06] <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.
[06:07] <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")
[06:08] <duflu> -called +acquired
[06:11] <duflu> alf__: I mean, a nicer solution would be to keep that multi-monitor logic closer to the multi-monitor compositing.
[06:11] <duflu> I was only suggesting the timing workaround as a quick solution which requires no effort on your part
[06:12] <duflu> Unless there are other "simple" ways to semi-synchronize the compositing threads without actually synchronizing them
[06:13] <duflu> And without breaking bypass requirements
[06:13] <tvoss_> duflu, are you loosing the z character?
[06:14] <duflu> tvoss_ ?
[06:14] <tvoss_> duflu, my xchat eats away certain characters :)
[06:14] <duflu> tvoss_: No, it's just you... ?
[06:14] <tvoss_> duflu, damn :)
[06:14] <alf__> duflu: how would that work in the (DisplayBuffer)Compositor?
[06:15] <duflu> alf__: You mean timing workaround?
[06:15] <alf__> duflu: yes
[06:15] <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
[06:16] <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
[06:17] <duflu> It actually feels close to the "right solution", just maybe in the wrong place
[06:18] <duflu> And bonus: That won't break bypass.
[06:20] <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.
[06:21] <alf__> (from lp:mir)
[06:21] <duflu> alf__: Cool thanks
[06:22] <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)
[06:22] <duflu> -be +me
[06:23] <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_ :/
[06:23] <alf__> duflu: isn't this fixed by https://code.launchpad.net/~vanvugt/mir/fix-1199450/+merge/178236 ?
[06:24] <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
[06:26] <alf__> duflu: do we always use triple buffering or only for framedropping and bypass?
[06:27] <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
[06:28] <duflu> The lazy allocation is generalized... it keeps the number of real buffers low until more are required
[06:29] <alf__> duflu: sounds good
[06:30]  * duflu shuffles monitors
[06:33] <alf__> duflu: hmm, how do you stop a client that is (or rather wants to be) double-buffered from acquiring the third buffer?
[06:37] <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 :/
[06:37] <duflu> -expend +expand
[06:37] <duflu> That might need revisiting. I can add dynamic resizing without much fuss
[06:50] <duflu> alf__: Multi-monitor just works, nice. If only I had a GUI to set the layout :)
[06:51] <duflu> Or a language... like "DVI1 leftof VGA1"
[07:22] <RAOF> didrocks: Have we won a Mir promotion to Main?
[07:23] <didrocks> RAOF: it was too late on Friday and risky, so we pinned to proposed. The promotion/publication is now in progress
[07:23] <RAOF> didrocks: Cool. Sorry about that delay.
[07:24] <didrocks> RAOF: no worry ;)
[07:32] <dholbach> good morning
[07:43] <RAOF> Hm. Zoë bath time!
[08:17] <duflu> alf__: Just a minor speedhump: https://bugs.launchpad.net/mir/+bug/1208354
[08:18] <alf__> duflu: ahh, yes this is fixed by lp:~afrantzis/mir/multimonitor-misc-fixes ⇒ lp:mir (will hopefully land soon)
[08:18] <duflu> alf__: Very nice, thanks
[08:32] <didrocks> RAOF: still around?
[08:39] <RAOF> didrocks: Yeah.
[08:40] <didrocks> RAOF: see #ubuntu-devel please :)
[08:40] <RAOF> didrocks: Ah, I see #ubuntu-devel.
[08:40] <didrocks> heh ;)
[08:40] <seb128> can we just drop ppc? :p
[08:41] <didrocks> +1000 :p
[09:51] <duflu> alf__: I will have most of your requests resolved tonight but not all... At least multi-monitor is fixed, without breaking bypass \o/
[09:52] <alf__> duflu: great!
[09:58] <tvoss_> duflu, \o/
[10:24] <doko> Saviq, ping
[10:26] <Saviq> doko, pong
[11:05] <alan_g> hikiko: how's it going?
[11:18] <hikiko> alan_g, I started from create display
[11:18] <hikiko> and now I am writing a NestedDisplay class
[11:19] <hikiko> do you think I should do something else first
[11:19] <hikiko> ?
[11:20] <alan_g> hikiko: that sounds a sensible approach
[14:15] <racarr> Morning
[14:29] <greyback> racarr: morning!
[14:29] <alan_g> Afternoon
[14:30] <racarr> greyback: Morning! welcome back
[14:30] <greyback> racarr: thanks :)
[14:32] <racarr> greyback: I'm sure you are still catching up but maybe we should do a catch up soon?
[14:32] <racarr> I was kind of doing other stuff last weekly so expect for some stuff for OSK mostly not on unity
[14:32] <greyback> racarr: certainly. Whenever you're ready
[14:32] <racarr> so kind of lost track of exact status
[14:32] <greyback> Yep I'd like to know where the OSK work is at
[14:32] <racarr> greyback: Ok after the 8:00 mir stand up maybe?
[14:32] <greyback> Daniel is away, so I need to at least know what it's status is
[14:32] <greyback> racarr: perfect
[14:46] <kgunn> greyback: racarr can i lurk on your sync?
[14:46] <greyback> kgunn: sure
[14:50] <racarr> kgunn: Eh...
[14:50] <racarr> it's kind of "cool crowd only"...so I dunno
[14:50] <racarr> :p
[14:51] <racarr> I am just teasing. Have a good time in IoM?
[14:52] <kgunn> racarr: consider we were the only people at that hotel under 60.... :-/
[14:54] <kgunn> racarr: we did gointo town one night...me ancell, didier & michal... food was sooo good & company was good :)
[14:59] <racarr> kgunn: Aha. that must have been a little strange (hotel situation)
[14:59] <kgunn> didrocks: just checking in...did RAOF overcome the alioth issue
[14:59] <didrocks> hey!
[14:59] <kgunn> racarr: it was bizzare
[14:59] <didrocks> kgunn: he did, and so we have everything uploaded
[14:59] <didrocks> promoted some components to Main
[14:59] <didrocks> howerver, multiples upload from him and I to ignore properly powerpc
[15:00] <didrocks> however, on two components
[15:00] <didrocks> we still try to build with mir for the -ati and -nouveau driver
[15:00] <didrocks> so this one should be fixed, RAOF assume this wasn't needed (but it wasn't built) when I asked him
[15:01] <didrocks> we can:
[15:01] <didrocks> - either do a bad/ugly #ifdef
[15:01] <didrocks> - let RAOF fix it more properly (I would be more in favor of that)
[15:01] <didrocks> the second point is that unity-system-compositor don't enable accceleration anymore on the intel or ati machine
[15:01] <didrocks> so even unity doesn't start
[15:02] <kgunn> didrocks: good ol' powerpc :)....ok, that stinks  about new prob
[15:02] <kgunn> didrocks: did you really mean intel ? or nvidia rather
[15:03] <didrocks> nvidia, sorry :)
[15:03] <didrocks> I can't even use jetlag as an excuse
[15:03] <didrocks> kgunn: for powerpc, I'll be in favor of guns if this continues that road ;)
[15:04] <kgunn> :))
[15:04] <didrocks> I'll send an email with you/RAOF/robert
[15:25] <racarr> greyback: Sync up?
[15:25] <racarr> kgunn: ^
[15:25] <greyback> racarr: ok
[15:26] <kgunn> racarr: gotta link ?
[15:27] <racarr> making one
[15:27] <racarr> https://plus.google.com/hangouts/_/a38f0a95d50f766f61f95dd52ef79056c74c360c?authuser=1&hl=en
[15:27] <racarr> kgunn: greyback: ^
[15:28] <kgunn> ricmm: ^
[15:56] <kgunn> racarr: were you going to refactor down to singled method interface first ? or try chasing some approval on the current mp ?
[15:56] <kgunn> regarding...https://code.launchpad.net/~robertcarr/mir/surface-configuration-interface--for-shell/+merge/177055
[16:05] <racarr> kgunn: i am not sure
[16:06] <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
[16:08] <racarr> The single method variant is awkward, because like in the comment I just left
[16:08] <racarr> you end up applying the surface state changes, etc, before you actually update the member variable tracking the state
[16:10] <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
[16:11] <racarr> but both of these just mean, instead of an interface with two roles it's now a method with two roles.
[16:12] <racarr> so I am not sure this makes sense.
[16:13] <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
[16:13] <racarr> they will always be passed around in a pair in the server
[16:14] <racarr> so pattern is to pass them as a composite type i.e. some AttributeStuff, which has ethods like decider() and applier()
[16:14] <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
[16:17] <racarr> I think it's probably somewhat more of an indication tht the way we are handling state of msh::Surface is bad
[16:18] <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
[16:24] <racarr> alan_g: A completely different proposal for surace-configuration-interface
[16:24] <racarr> alan_g: msh::Surface loses the state, type, etc member variables
[16:24] <alan_g> racarr: sorry, my head is full of ~vanvugt/mir/switch/+merge/178527
[16:24] <racarr> that's ok :)
[16:25] <alan_g> But that sounds interesting
[16:26] <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
[16:26] <racarr> but it's not too much hassle so maybe I will just try and implement it and you can check it out later :)
[16:26] <racarr> switch branch scares me ;)
[16:29] <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
[16:29] <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.
[16:29] <racarr> it needs GC though so it's not for us. it's just really interesting
[16:29] <alan_g> racarr: I'll take a raincheck
[16:30] <racarr> XD
[16:30] <racarr> yeah, I understand that bit sort of
[16:31] <kgunn> racarr: maybe kdub can take a peek this afternoon
[16:32] <racarr> Yeah. I'll harass him ;)
[16:33] <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
[16:34] <racarr> which could also be implemented by
[16:34] <racarr> super scene graph model 2.0 :p
[16:34] <alan_g> racarr: I know I need to get back on that hobbyhorse
[16:34] <alan_g> And actually propose something concrete.
[16:35] <racarr> alan_g: Ok. That would be good
[16:35] <alan_g> If only folks would stop with the big complicated MPs
[16:35] <racarr> I haven't been able to get to anything concrete on that
[16:35] <alan_g> ... ;)
[16:35] <racarr> and I am worried that we are
[16:35] <racarr> approaching feature freeze
[16:37] <racarr> alan_g: I.e. feature freeze is august 29th
[16:37] <kdub> racarr, peek at notify focus? or switch
[16:38] <racarr> kdub: Err, the surface-configuration-interface
[16:38] <racarr> it doesn't exactly need review, just ideas I guess
[16:38] <kdub> racarr, i'll refill my coffee and take a look now
[16:39] <racarr> kdub: Ah. excellent. Thanks :)
[16:42] <kgunn> bschaefer: are you free-ish today ?
[16:42] <bschaefer> kgunn, a bit more ibus stuff to do, but after that I should be
[16:42] <bschaefer> kgunn, still trying to get my desktop back up and working :(
[16:43] <kgunn> bschaefer: oh crap
[16:43] <kgunn> bschaefer: but ok...i'll loop you in
[16:43] <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!
[16:43] <bschaefer> kgunn, sounds good!
[16:46] <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
[16:47]  * racarr takes one of the little pills labelled "Up"
[16:47] <racarr> :p
[16:53] <racarr> Another option for client-focus-notifications
[16:54] <racarr> surface loses surface_state_focused/unfocused. introduce an interface msh::Focus with one method Focus::give(std::shared_ptr<msh::Surface>)
[16:55] <racarr> this obect tracks the current focus, so it can do unfocused notifications
[16:55] <racarr> it also needs to know to give the focus to the next surface if
[16:55] <racarr> the focused surface is destroyed, so I think msh::Surface also gains a method like
[16:55] <kdub> racarr, the cloggable event sink
[16:56] <kdub> i still feel like i'm missing the big picture on the 'why'
[16:56] <racarr> msh::Surface::take_focus(std::unique_ptr<FocusToken>)
[16:56] <racarr> with a d'tor that knows what to do
[16:56] <racarr> kdub: Basically the idea is inbetween the call to create_surface
[16:56] <racarr> and sending a response to the client
[16:57] <racarr> we may generate surface configuration events
[16:57] <racarr> i.e. surface id 7 took focus
[16:57] <racarr> but if we send this to the client before it's been told what surface id 7 is
[16:57] <racarr> it can't interpret it
[16:58] <kdub> ah, gotcha
[16:58] <racarr> so we have to ensure the wire events are sent after the create_surface response
[16:58] <racarr> kdub: it's a little sketchy actually because it relies
[16:58] <racarr> on the fact that invoking the Done callback from create_surface
[16:58] <racarr> synchronously writes the message.
[17:00] <kdub> seems like the object with the best information to control that timing is the msh::Surface
[17:00] <kdub> perhaps the SessionManager as well
[17:00] <racarr> hmm, not as it stands now, because even after SessionManager::create_surface_for
[17:00] <racarr> returns
[17:00] <racarr> the SessionManager can't know if things have been sent over the wire yet
[17:01] <kdub> right, so it seems the shell has a false idea about when a surface is up and running
[17:02] <kdub> maybe msh::Surface should have the same lifetime as the client surface on the other side of the ipc barrier?
[17:03] <kdub> that way a focus event could block there until we know the client is ready
[17:03] <racarr> maybe
[17:04] <kdub> alternatively, we could just have more complex logic client side
[17:04] <racarr> I think you can always end up with
[17:04] <racarr> situations where the client can't decide? Maybe not.
[17:05] <racarr> well
[17:05] <racarr> if the client buffers the events and waits until the surface appears
[17:05] <racarr> then it can't really detect events which are actually malformed/in error
[17:06] <racarr> kdub: The lifetime idea is kind of nice but I'm not sure how it would be implemented
[17:06] <kdub> i guess we have two responses now to that rpc call
[17:07] <kdub> 'you are focused' or 'you are not focused'
[17:07] <kdub> that would take care of it too :)
[17:07] <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
[17:07] <racarr> kdub: Not quite because a surface may open and not necessarily receive focus
[17:07] <racarr> or maybe it opens and the shell restores it's state to maximized
[17:08] <racarr> because that's how it was last run
[17:08] <racarr> so there could be many responses I think
[17:08] <kdub> right, the surface opens and is not focused
[17:08] <kdub> at the time the surface is created, we should be able to know the state of the surface
[17:08] <kdub> seems that should be sent as the initial state in the return of the rpc message
[17:09] <racarr> hmm
[17:09] <racarr> ok, so the current model is kind of like, the initial state is defaulted
[17:09] <racarr> i.e. your state is restored, your surface type is normal, you do not have focus
[17:09] <kdub> right
[17:09] <racarr> and you will be notified of anything else
[17:10] <racarr> so we could extend create surface to return like
[17:10] <racarr> surface_id, state, type, focus
[17:10] <racarr> but then wont e still need a proxy event sink?
[17:10] <racarr> Because we have to ensure that later when these change
[17:10] <kdub> that seems like a separate issue
[17:10] <racarr> we still send notification
[17:11] <kdub> the event sink still has to be accessible to the shell surface, yes
[17:11] <racarr> but that we don't send notification on this first call
[17:11] <racarr> but I mean, the surface will still be created in the default state
[17:12] <racarr> so what makes the first change to 'focused' occur as part of the create_surface reply
[17:12] <racarr> and not as an event over the wire
[17:12] <kdub> the shell decides the initial state when the surface is created
[17:12] <kdub> or :) it should be
[17:13] <kdub> that gets sent in the reply, and afterwards, any updates to the state are sent via the event sink
[17:14] <racarr> kdub: I think it's hairy for the shell to decide that way
[17:14] <racarr> because now essentially any interface like
[17:15] <racarr> kdub: Ok, I was thinking
[17:15] <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? :)
[17:15] <racarr> it had to happen before surface construction, but actually it could happen
[17:16] <racarr> kdub: Well my concern s that doing it before surface construction was difficult because then the shell will have methods like
[17:16] <racarr> decide_state_for_surface_creation_params and decide_state_for_surface
[17:16] <kdub> right, not before
[17:17] <racarr> kdub: But actually, the surface could use the SurfaceConfigurator from the other branch (XD)
[17:17] <racarr> er welll I still cant quite figure it out but will go on
[17:17] <racarr> then in it's constructor it calls like
[17:17] <kdub> ipc request comes in, we ask the shell to create a surface, we read the created surface, and then we run done
[17:17] <racarr> state = select_attribute_value(surface_state)
[17:17] <racarr> type = select_attribute_value(type) focus = select_attribute_value(focused)
[17:18] <racarr> and it doesn't go over the event sink because there was no call through to msh::Surface::configure
[17:19] <kdub> sounds better
[17:20] <racarr> kdub: Ok so.I think this makes sense, but now I am having a little difficulty figuring out how the mechanism happens
[17:21] <racarr> kdub: i.e. the surface is being constructed
[17:21] <kdub> i think we need some extra fields in protobuf's Surface
[17:21] <racarr> so the shell gets select_focused(msh::Surface &)
[17:21] <racarr> and says, hey this is a new surface, so it says yes, focused
[17:21] <racarr> but now what actually sets
[17:21] <racarr> the input focus to
[17:21] <racarr> that surface
[17:21] <racarr> I'm not sure if it makes sense for
[17:22] <racarr> it to be select_focused because
[17:22] <racarr> the surface isn't even initialized at that point.
[17:23] <kdub> we need to ban the use of the word 'surface' :)
[17:24] <kdub> it isn't initialized where?
[17:24] <kdub> client side?
[17:24] <racarr> no, I meant, on the server, if we use some interface like
[17:24] <racarr> select_attribute_value(focused) that is called during the constructor
[17:24] <racarr> and no one is notified of this
[17:24] <racarr> then what actually sets the input focus
[17:27] <kdub> from the frontend, i see this
[17:27] <kdub> http://pastebin.com/vD7UCRUs
[17:29] <racarr> kdub: Ok.
[17:29] <racarr> kdub: trying to reword the last concern.
[17:29] <racarr> the thing is, right now the FocusMechanism, sets the focused attribute on the surface
[17:29] <kdub> okay, yeah. i sorta detected we were talking about two different parts of code
[17:30] <racarr> after, applying the mechanism of the focus of the surface. i.e. making sure it's on top and giving it key focus
[17:30] <racarr> so, if the surface instead takes the focused attribute itself during creation
[17:31] <racarr> then what actually
[17:31] <racarr> does this giving key focus, etc step.
[17:34] <kdub> racarr, don't know where that question ended :)
[17:34] <racarr> err, sorry
[17:34] <racarr> I mean which component, or hwere in this flow
[17:34] <racarr> do we actually set the key focus
[17:35] <racarr> because there is no
[17:35] <kdub> been reading through a bit of the code more
[17:35] <racarr> msh::FocusSetter::set_focus_to(msh::Surface) now
[17:35] <racarr> as the only entry point for focus changing
[17:35] <racarr> (when I say now, I mean, in this select_attribute_value model)
[17:35] <kdub> and really, i think in msh::SessionManager::create_surface_for, it calling set_focus_to is probably in the wrong place
[17:36] <kdub> my head's currently exploding with 'hey, a std::future seems perfect for this sort of thing' :)
[17:36] <kdub> but
[17:37] <racarr> mm
[17:37] <racarr> the call to set_focus_to is wrong I agree
[17:37] <racarr> that should be entirely shell policy it's just there so we could have focus before we had a shell or example servers
[17:37] <kdub> a notification after SessionMediator::create_surface's done->Run() to the focus setter seems appropriate sorta
[17:38] <racarr> I was thinking about that, or even right before i.e. say
[17:38] <kdub> with the idea, 'hey Focus stuff, time to reconsider who has focus'
[17:38] <racarr> SessionManager::create_surface_for(...
[17:38] <racarr> surface = create_surface()
[17:38] <racarr> and then like
[17:38] <racarr> apply_surface_attributes(surface)
[17:39] <racarr> then it returns to the SessionMediator (not sure it needs to happen after done->Run())
[17:39] <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)
[17:39] <kdub> might not be, just musing a bit
[17:39] <racarr> and is it supposed to be written like
[17:40] <racarr> switch (surface_state): case maximized: unity_maximize_surface(), .... swtich(surface_focused): case focused...
[17:40] <racarr> etc...
[17:44] <racarr> kdub: Yes. thanks for the musings :) this is helpful
[17:47] <kdub> racarr, no problem :)
[17:48] <racarr> kdub: The CloggableEventSink solves another problem too
[17:49] <racarr> which is, say we have sorted out this focus stuff by setting it as part of construction, or even without client-focus-notifications
[17:49] <racarr> So, the SessionMediator invokes create_surface, then before calling done->Run()
[17:49] <racarr> the thread yields
[17:50] <kdub> right, and then the shell changes focus
[17:50] <kdub> in the time period, or something
[17:50] <racarr> yeah or maximizes the surface or whatever
[17:50] <kdub> EventSink, primarily, is not an interface which has any synchronization guarantees, its purpose is to send messages
[17:51] <kdub> i think a richer synchronization
[17:51] <kdub> even 'client ready for events' on msh::Surface, that is invoked after done->Run makes a bit more sense
[17:51] <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
[17:52] <racarr> it's only the SessionMediator that knows about the synchronization
[17:52] <racarr> but hmm, yeah
[17:52] <kdub> right, so why not synchronize between SessionMediator and SessionManager then
[17:52] <kdub> instead of synchronizing between SessionMediator and EventSink, so that SessionManager can sync with Event sink too later :)
[17:53] <racarr> hmm, how
[17:54] <racarr> I guess I see two ideas, one could be maybe msh::Surface contains some attribute
[17:54] <racarr> client_ready_for_events
[17:55] <racarr> and it buffers the configuration events itself (i.e. like the cloggable event sink does now)
[17:55] <racarr> this was my original idea actually, but I was worried that this
[17:56] <racarr> distributes frontend state in to shell, i.e. msh::Surface doesn't really care what state the socket is in
[17:56] <racarr> so I thought maybe the SessionMediator should be responsible for
[17:56] <kdub> well, msh::Surface cares that a surface has been created
[17:56] <racarr> mediating the IPC synchronization requirements, with the msh::Surface interface. if that makes any sense.
[17:56] <racarr> Mm
[17:56] <racarr> I like the idea of
[17:57] <racarr> not creating the msh::Surface
[17:57] <racarr> until we have sent the response, i.e. like
[17:57] <racarr> SessionMediator::create_surface(params)
[17:57] <racarr> auto params_attributes_and_id = SessionManager::create_surface_for(session, params)
[17:57] <racarr> pack_response(); done->Run()
[17:58] <kdub> right, i just considered the id as part of the parameters above :)
[17:58] <racarr> SessionManager::...actualize_surface(id)
[17:58] <racarr> or something?
[17:58] <racarr> which creates the actual msh::Surface
[17:58] <kdub> haha, self_actualize(), reduce_karma(), balance_chi()
[17:58] <kdub> alan would love those names ;)
[17:58] <racarr> haha.
[17:59] <racarr> mir::shell::SurfaceEnlightener ;)
[17:59] <racarr> hmm ok. So I actually like this a fair amount my main concern is like
[17:59] <racarr> when are the other resources initialized, and such i.e.
[17:59] <racarr> in particular in error cases
[18:00] <racarr> i.e. what if we fail to allocate the buffers
[18:00] <racarr> it seems strange that we have already told the client they have received a surface
[18:02] <racarr> and im not entirely sure how we report the error
[18:02] <racarr> but that's probably sortable
[18:05] <racarr> I still don't know how to make the focus mechanism work in this model though...
[18:05] <racarr> also there is daniel's need fixing on not using attributes at all for focus :p
[18:05] <racarr> but even if that becomes something entirely seperate from EventSink
[18:05] <racarr> whatever this thing is will still need synchronization
[18:18] <kdub> racarr, if you take a look at the way i'm sending display info
[18:18] <kdub> (my MP up for review)
[18:18] <kdub> we can send things via protobuf a bit easier
[18:22] <racarr> kdub: ok ill check it out after lunch
[18:22] <racarr> lunch nowww
[19:10] <racarr> back
[19:13] <bschaefer> kgunn, hey, soo I saw that email, so ati, and nvidia are having problems starting up
[19:13] <kgunn> yes...so it seems
[19:13] <bschaefer> robotfuel, are there any machines that I would be able to ssh into?
[19:14] <bschaefer> strange indeed...and it looks like compiz is hanging on loading opengl...
[19:17] <robotfuel> bschaefer: it looks like ps-radeon-hd6870-he is open
[19:17] <bschaefer> robotfuel, awesome, thanks!
[19:18] <robotfuel> bschaefer: ps-nvidia-gs8400-le is also open with xmir on it
[19:18] <bschaefer> perfect, now hopefully I can figure something out :)
[19:21] <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.
[19:21] <bschaefer> robotfuel, its fine to install u-s-c on the radeon one right?
[19:21]  * bschaefer checks if its running or not
[19:22] <bschaefer> robotfuel, hmm the radeon machine appears to be working
[19:22]  * bschaefer reboots just to check
[19:22] <robotfuel> bschaefer: I don't think the radeon machine has xmir on it, but it passed some phoronix tests this morning
[19:22] <bschaefer> robotfuel, whats the utah death test do?
[19:23] <bschaefer> robotfuel, well it had the mir serve rrunning in the background...
[19:23] <robotfuel> bschaefer: it tries to kill utah
[19:24] <bschaefer> hmm yeah:  /usr/sbin/unity-system-compositor --enable-input=false --from-dm-fd 9 --to-dm-fd 13 --vt 7
[19:24]  * bschaefer double checks the x log
[19:25] <bschaefer> yup so, the redeon machine appears to be working
[19:25] <bschaefer> and its using the u-s-c testing ppa
[19:25] <bschaefer> kgunn, ^
[19:26]  * bschaefer looks at nvidia
[19:28] <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. :)
[19:29] <bschaefer> robotfuel, cool :), well im also going to go and make sure things are updated as well
[19:33] <kgunn> bschaefer: ? now i wonder what didrocks might have seen....whether or not it was on these machines....or some others
[19:33] <bschaefer> kgunn, well it seems like there are some updates...
[19:34] <kgunn> bschaefer: so it healed itself ?
[19:34] <bschaefer> kgunn, well im not sure, these updates could throw it all off :)
[19:35] <bschaefer> it would be strange if it did though
[19:37] <bschaefer> kgunn, hmm well the nvidia gs8400 seems to be fine, now to go update the radeon one...
[19:37] <bschaefer> I hope they don't just heal them selfs though...as when things do that they usually break again
[19:38] <olli__> hiho
[19:38] <olli__> in which BP is the bypass work captured?
[19:38] <olli> kgunn, kdub ^
[19:39]  * kgunn digging
[19:39] <kdub> https://code.launchpad.net/~vanvugt/mir/switch/+merge/178527
[19:39] <kgunn> https://blueprints.launchpad.net/ubuntu/+spec/client-1310-mir-xmir
[19:39] <olli> https://blueprints.launchpad.net/ubuntu/+spec/client-1310-mir-xmir
[19:39] <olli> heh
[19:39] <kdub> oh, blueprint, not mp :)
[19:39] <olli> thx guys
[19:45] <bschaefer> kgunn, robotfuel and updated radeon is working as well...
[19:45] <bschaefer> hmm possibly didrocks was running into something that was fixed already?
[19:46] <kgunn> weird
[19:47] <bschaefer> yes indeed...
[19:49] <kgunn> robotfuel: so you got the standalone X runs of phoronix across all the new platforms ?
[19:50] <kgunn> brb guys...
[19:51] <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.
[19:51] <tvoss> ffs
[20:33] <kgunn> robotfuel: do you mean 100 utah death test runs
[20:35] <robotfuel> kgunn: yes, we are at 28 of 100 now. so we can start the X testing tomorrow if we have utah stable.
[20:46] <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?
[20:46] <olli> and I admittedly only looked into the July archives ;)
[20:46] <robert_ancell> olli, otp, be back in 5
[20:47] <olli> robert_ancell, ack
[20:56] <kdub> yay, found a spare monitor in the garage
[21:04] <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"
[21:05] <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
[21:05] <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
[21:06] <robert_ancell> olli, yep, will ask him when he comes online
[21:07] <olli> robert_ancell, you should have received a ggdoc mail with the doc
[21:07] <robert_ancell> olli, looking..
[21:08] <olli> robert_ancell, thx
[21:50] <kdub> whoohoo, display resize requests are working reasonably well... few dings to hammer out
[21:50] <kgunn> kdub: that's great....feeling better about multimon by the moment
[23:21] <RAOF> olli: Nouveau will be easy, once the Xserver patches land; we only need to satisfy mlankhorst there ☺
[23:22] <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!).
[23:30] <robert_ancell> RAOF, hey, does XMir need any updating to work with the display configuration changes in mir r925?
[23:31] <RAOF> robert_ancell: Shouldn't, but we should now be able to actually do RANDR.
[23:32] <kdub> no, not yet :)
[23:32] <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
[23:32] <robert_ancell> i.e. black screen
[23:32] <RAOF> kdub: I think there's enough there to do the read-only bit of RANDR, at least.
[23:32] <kdub> that just gets across the ipc barrier, still working on the server-side display configuration (focus based)
[23:33] <kdub> not all the bits are hooked up serverside, should be soon though
[23:34] <RAOF> robert_ancell: I'll have a look.
[23:34] <robert_ancell> I'm just recompiling X here just to double check
[23:35] <RAOF> I did fix a problem where libmirclient would segv, but you're obviously not seeing that.
[23:36] <robert_ancell> no
[23:40] <bschaefer> robert_ancell, what card are you on? As I tested out ati/nvidia today and both were working
[23:40] <bschaefer> though there were some reports of black screening from didrocks...
[23:40] <robert_ancell> bschaefer, intel
[23:40] <bschaefer> hmm well hopefully rebuilding X fixes that :)
[23:41]  * kdub tried intel today, at least the basic mir test programs seemed ok


[17:02] <seyDoggy> I installed 12.04 on an acer aspire one d270 netbook and all has gone very well except I can't adjust the screen res or brightness.
[17:12] <bregma> can you switch to a text console and adjust it there (ie. ctrl-alt-f3, adjust, ctrl-alt-f7)?
[17:16] <seyDoggy> bregma: sorry, not sure what you mean. assume I'm new.
[17:23] <seyDoggy> bregma: nm I googled it


[14:58] <sfeole> o/    hey all,   I was wondering if anyone knows when maas-images will produce the the latest Bionic point release images for bionic 18.04.4 ?
[14:58] <sfeole> the first release candidate is here: http://iso.qa.ubuntu.com/qatracker/milestones/410/builds
[16:01] <mup> Bug #1818703 changed: regiond stops listening on the API port 5240 until regiond is restarted (listening sockets are lost) after database failover <cpe-onsite> <MAAS:Triaged by ack> <https://launchpad.net/bugs/1818703>


[13:22] <BluesKaj> Hi all
[13:50] <RikMills[m]> https://invent.kde.org/plasma/plasma-welcome
[13:51] <RikMills[m]> https://mail.kde.org/pipermail/distributions/2022-September/thread.html
[13:51] <RikMills[m]> Eickmeyer: ^^
[13:51] <RikMills> mmikowski: ^^
[13:52] <RikMills> sorry if that was a 2nd ping. a IRC netsplit happened while I did the previous, so not sure you would see
[13:54] <Eickmeyer> Yeah, I have a response to Nate from an Ubuntu Studio perspective, i.e. it needs to be more modular and less hard-coded. I don't like the idea of having to fork it to make it work for my needs.
[13:57] <RikMills[m]> Great. I agree if we can provide one version in the archive and adjust with config, that would be ideal
 The following packages were automatically installed and are no longer required:
   kwin-wayland-backend-drm libkwinxrenderutils13
 Use 'sudo apt autoremove' to remove them.
 The following packages will be REMOVED:
   gnome-shell-extension-ubuntu-dock libkwineffects13 libkwinglutils13 ubuntu-desktop ubuntu-desktop-minimal
 The following NEW packages will be installed:
   libkpipewire5 libkpipewirerecord5 libkwineffects14 libkwinglutils14 libqt5webview5 qml-module-org-kde-pipewire
 https://irc-attachments.kde.org/6a99e28d/file_60131.webp
 need to be extra careful :)
[14:06] <nteodosio> Is there some Qt program available both as snap and deb? I want to test if a bug I see in a snap package is snap specific or not.
[14:06] <nteodosio> I'm searching, but asking here in case someone knows it off the top of his head.
 Not idea on the gnome things, but the kwin things to remove are very deliberate. KDE stopped shipping separate kwin wayland back libraries, so several packages became dunct (re @myfenris: The following packages were automatically installed and are no longer required:
   kwin-wayland-backend-drm libkwinxrenderutils13
 Use 'sudo apt autoremove' to remove them.
 The following packages will be REMOVED:
   gnome-shell-extension-ubuntu-dock libkwineffects13 libkwinglutils13 ubuntu-desktop ubuntu-desktop-minimal
 The following NEW packages will be installed:
   libkpipewire5 libkpipewirerecord5 libkwineffects14 libkwinglutils14 libqt5webview5 qml-module-org-kde-pipewire)
 Not idea on the gnome things, but the kwin things to remove are very deliberate. KDE stopped shipping separate kwin wayland back libraries, so several packages became defunct (re @myfenris: The following packages were automatically installed and are no longer required:
   kwin-wayland-backend-drm libkwinxrenderutils13
 Use 'sudo apt autoremove' to remove them.
 The following packages will be REMOVED:
   gnome-shell-extension-ubuntu-dock libkwineffects13 libkwinglutils13 ubuntu-desktop ubuntu-desktop-minimal
 The following NEW packages will be installed:
   libkpipewire5 libkpipewirerecord5 libkwineffects14 libkwinglutils14 libqt5webview5 qml-module-org-kde-pipewire)
 https://irc-attachments.kde.org/6e3892ff/file_60132.jpg
[14:11] <nteodosio> I found it myself: krop.
 @RikMills thanks for the info ...
 the gnome is spinning another build .. so i'll wait for a while then later i'll give a go
[19:31] <mmikowski> RikMills[m]: Thanks. cc @Eickmeyer.


[23:16] <rw> i'm having a problem here and am just wondering if it's worth to write a bug report:
[23:17] <rw> if i press my "hibernate-shortcut" - gnome tells me: "cannot hibernate"
[23:17] <colorlessprism> probably check to see if it exists first
[23:17] <colorlessprism> hibernate bugs are common
[23:17] <rw> colorlessprism: nope, didn't find it
[23:17] <colorlessprism> check wiki to see if your model has fix
[23:17] <rw> but if i check "/sys/power/state":
[23:17] <rw> # cat /sys/power/state
[23:17] <rw> mem disk
[23:18] <rw> upower on the other hand:
[23:18] <rw> # upower -d | grep hibernate
[23:18] <rw> can-hibernate    no
[23:18] <colorlessprism> hmm, what computer your using?
[23:19] <rw> Thinkpad T42
[23:19] <colorlessprism> and version of ubuntu?
[23:19] <rw> Lucid Beta 2
[23:19] <colorlessprism> UNE?Desktop?
[23:20] <rw> UNE? gnome
[23:20] <colorlessprism> is it a netbook  or standard desktop install?
[23:20] <rw> standard desktop
[23:21] <rw> (installed using PXE, but that shouldn't matter *g*)
[23:21] <colorlessprism> let me check somthing then, brb
[23:21] <rw> k
[23:23] <rw> btw.: hibernate using "s2disk" seems to work just fine
[23:23] <colorlessprism> have you tried hibernating another way (i.e power mangement)
[23:23] <colorlessprism> it may be your "function" key not working properly
[23:23] <rw> well, i get a "message" from gdm i guess:
[23:24] <rw> "Cannot hibernate" - which, i guess, just checks the "can-hibernate"-key of devkit
[23:24] <colorlessprism> by setting your powerbutton to hibernate will it hibernate correctly that way?
[23:25] <rw> i'll give it a shot - moment please
[23:26] <rw> i cannot event choose "hibernate" there
[23:26] <colorlessprism> Do you have S3 suspend set to "On" in your BIOS settings?
[23:26] <rw> brb :)
[23:31] <rw> looks like it's enabled
[23:32] <colorlessprism> ok i only have 2 more ideas...
[23:32] <rw> the question i ask myself: why does the kernel say that "suspend2disk" is available and devkit says it's not?
[23:32] <colorlessprism> check /etc/default/acpi-support and make sure "ACPI_SLEEP=true" is uncommented and true
[23:34] <colorlessprism> and then run the hibernate script "/etc/acpi/hibernate.sh"
[23:35] <rw> you probably mean: "ACPI_HIBERNATE"
[23:35] <rw> but both are true anyway
[23:36] <colorlessprism> did you call the hibernate script?
[23:37] <rw> the script works..
[23:38] <colorlessprism> you hibernated?
[23:40] <rw> yepp
[23:41] <colorlessprism> hmm so lets do
[23:41] <colorlessprism> /etc/acpi/events/ibm-hibernatebtn
[23:41] <colorlessprism>    event=ibm/hotkey HKEY 00000080 00001004
[23:41] <colorlessprism>    action=/etc/acpi/hibernate.sh
[23:42] <colorlessprism> and for sleep you can
[23:42] <colorlessprism> /etc/acpi/events/ibm-sleepbtn
[23:42] <colorlessprism>    event=ibm/hotkey HKEY 00000080 00001004
[23:42] <colorlessprism>    action=/etc/acpi/sleep.sh force
[23:46] <colorlessprism> this is a script someone on launchpad used in their autostart to get your keys going again http://launchpadlibrarian.net/24484539/softkeys.py
[23:46] <colorlessprism> It should not be limited to thinkpads but support all laptops that generate the corresponding key press events. Most functionality is accessed via dbus either using HAL or KDE services.It depends on python2.6 (could be easily backported to 2.5),
[23:46] <colorlessprism> python-dbus and python-xlib.
[23:48] <colorlessprism> did any of that get you going...lol, i should say sleeping?
[23:49] <rw> the keys are working just fine all the time
[23:50] <colorlessprism> ok so you can hibernate from keypresses now?
[23:50] <rw> the hibernate-keys starts an action, it just fails without doing hibernation
[23:50] <rw> i don't want a crappy workaround, i want devkit and stuff working as it should
[23:50] <rw> *shrug*
[23:51] <colorlessprism> im out of ideas then
[23:51] <colorlessprism> sorry man
[23:51] <colorlessprism> i would hate for my help to be crappy ;)
[23:51] <rw> the help is not - the workaround just is :)
[23:52] <rw> if i JUST wanted to hibernate i would call "s2disk" from terminal - but that's not what a GUI is for, IMHO
[23:52] <colorlessprism> well, i was checking a few things and thought id help, i gtg good luck oohh btw: https://wiki.ubuntu.com/DebuggingKernelSuspend, http://ubuntuforums.org/showthread.php?t=690933
[23:52] <colorlessprism> who needs a gui
[23:52] <colorlessprism> good luck
[23:53] <rw> right...


[05:43] <pitti> Good morning
[07:36] <nigelb> Morning pitti!
[10:02] <mvo> if someone could check/accept the release-upgrader-apt to lucid-proposed I will make the auto-upgrade-tester run against that to check that #927993 is really fixed with it. there should be no regression potential as by default we use the release-upgrader-apt in lucid-updates
[10:42] <infinity> mvo: I sure wish apt's build system could make the diffs between source versions even MORE unreadable. ;)
[10:42] <infinity> mvo: Looks good, though.  Accepting.
[10:47] <infinity> mvo: FTBFS.  You broke translations.
[10:51]  * infinity fixes.
[11:00] <infinity> mvo: Unless you're already fixing it, I'll fix your apt upload for you.
[12:03] <mvo> infinity: I haven't fixed it yet, sorry, was at lunch, I can do it (its trivial) but will be equally happy if you do it :)
[12:30] <mvo> infinity: I fixed it and re-uploaded, sorry for the trouble
[12:49] <infinity> mvo: Accepted.
[12:49] <mvo> ta!
[12:58] <mvo> infinity: yay! i386 build - now in binary NEW, I wasn't aware that proposed needs to go through both NEWs, I learn something new every day :)
[13:01] <cjwatson> -proposed isn't special regarding NEW
[13:09] <infinity> Although, it seems like a bug that -proposed doesn't check -updates for NEW status.
[13:10] <infinity> (I had to NEW the source too for the same reason, despite it already existing in updates)
[13:10] <mvo> hm, so https://launchpad.net/ubuntu/+source/release-upgrader-apt/0.8.16~exp12ubuntu1~upgrader3/+build/3260800 tells me that there are a a bunch of binaries in -proposed that need NEW)
[13:10] <infinity> I assume it's only comparing to the release pocket.
[13:10] <mvo> aha, that makes sense
[13:10] <infinity> mvo: Yeah, they'll get processes when all the builds are done.
[13:10] <infinity> processed too.
[13:11] <infinity> Err, crap, and I realised I NEWed it to universe, not main.  Will fix when I accept the binaries.
[13:16] <cjwatson> it's based on whatever LP considers the ancestry of the pocket to be
[13:16] <cjwatson> I kind of maybe agree that -proposed ought to include -updates in its ancestry.  I think.
[13:16] <infinity> You'd think.
[13:17] <infinity> It gets this right WRT which pockets are represented in sources.list, you'd think those same inheritance rules would only exist in one place (though obviously not).
[13:18] <infinity> ie: release < security < updates < proposed
[13:21] <cjwatson> Anyone have an opinion on whether bug 920545 needs a freeze exception?
[13:21] <ubot2`> Launchpad bug 920545 in ntfs-3g "[update request] NTFS-3G, new STABLE Version 2012.1.15 [Precise]" [Wishlist,Confirmed] https://launchpad.net/bugs/920545
[13:21] <cjwatson> We've tended to keep ntfs-3g pretty well up to date in the past.
[13:22] <infinity> I believe the argument in the past was always "ntfs drivers kinda suck, so any bugs fixed are a win".
[13:22] <infinity> I suspect that's still true.
[13:22] <cjwatson> There are some new features, but they mostly seem to be opt-in kind of things.
[13:23] <infinity> I see at least two fixes in there that fix real (visible to me) bugs.
[13:23] <cjwatson> The library has got itself multiarched, but AFAICT it's only really usable by the ntfs-3g package itself seeing as it's no longer a separate sonamed binary package.
[13:23] <infinity> So, I'd wave it through on the "can't be worse than it is" basis.
[13:23] <cjwatson> So I can't see how that would break anything.
[13:24] <Daviey> cjwatson: TBH, your opinion carries this.. it's only you that ever touches it.. so i guess you understand the issues more than the rest of us :)
[13:24] <cjwatson> infinity: which, out of interest?
[13:24] <infinity>     ntfs-3g: fixed endless recursion when MFT extents are described by themselves
[13:24] <infinity>     ntfs-3g: fixed truncation of DOS file names (12 ntfschars, not 12 utf8 chars)
[13:24] <infinity> Those two.
[13:24] <cjwatson> Daviey: with a clothes peg firmly on my nose, I should add
[13:24] <Daviey> heh
[13:24] <infinity> I've run into the former, and it's nasty.  And the latter is just cosmetically ugly.
[13:25] <Daviey> infinity: You sound like quite an ntfs user :)
[13:25] <infinity> I used to run NT on several machines.  I'm reformed.
[13:27] <Daviey> likely story..
[13:27] <infinity> I wonder if anyone's working on a decent Linux driver for the new Win8 filesystem, or if we have to go through another ten years of reverse engineering pain.
[13:27] <cjwatson> right, thanks all.  uploaded the merge.
[13:39] <infinity> mvo: Component fixed and binaries accepted to main, should publish in the :03 run.
[13:41] <mvo> awsome, thanks! I prepare the auto-upgrade-tester to use it instead of the -updates version
[14:45] <pitti> huh, why did ntfsprogs suddenly go to universe..
[14:45]  * pitti promotes it back to main
[14:46] <cjwatson> probably because ntfs-3g turned it into a transitional package
[14:52] <pitti> ah, so udisks' recommends need updating
[14:56] <davmor2> cjwatson: do you happen to have a system you can try a d-i install on that has a wireless card in it?  if I go on wlan0 as my main network interface, I get q1. as If you would like to use any available network, leave this field blank,  I do,  It does a search finds nothing,  q2to skip wireless config and continue leave this field blank I do again and then it goes on to ask me what network I want to use wep/ope
[14:56] <davmor2> n or wpa which to me isn't skipping
[14:57] <cjwatson> davmor2: not without losing my current working state
[14:57] <cjwatson> do an install with DEBCONF_DEBUG=developer in the boot parameters and extract syslog
[14:57] <cjwatson> making sure to go through that same UI flow
[14:58] <davmor2> cjwatson: I can on wednesday right now I need to get a system up and running for tomorrow I managed to kill my desktop magically
[15:04] <stgraber> davmor2: I should be able to test this fairly easily, will try to do later this morning
[15:05] <davmor2> stgraber: ah cool if you can't give me a ping I can do it on wednesday as I say
[15:06] <davmor2> stgraber: effectivly you leave the wifi questions blank both times ps the network I have is a wpa, there are no open or wep ones near by
[15:21] <infinity> pitti: Surely, ntfsprogs wants to stay in main until post-LTS?
[15:34] <nessita> ScottK: hi there! just saw you question in bug #945061 and since we're in a rush to have this landed today (and release to Ubuntu tomorrow, so strings are available ASAP), I'm letting you know that yes, we wrote the doc and translators lists (links to the email archive in the bug description)
[15:34] <ubot2`> Launchpad bug 945061 in ubuntu-sso-client "[UIFe] Qt UI: the "Login" and "Forgotten Password" pages don't have titles and subtitles" [Undecided,New] https://launchpad.net/bugs/945061
[15:34] <ScottK> nessita: Please say so in the bug.
[15:35] <nessita> ScottK: sure, thanks
[15:35] <nessita> done
[15:37] <ScottK> nessita: Approved.  Also 944982.
[15:37] <ScottK> nessita: Please get them uploaded quickly so the string changes will land soone.
[15:37] <ScottK> soon....
[15:37] <nessita> ScottK: sure I will, thanks a lot :-)
[15:37] <stgraber> any archive admin planning on going through the pending package removals soon? bug 931809 is causing some confusion at the moment because we have both the lttng 1 and lttng 2 stacks in the archive
[15:37] <ubot2`> Launchpad bug 931809 in ust "Please remove the old LTTng packages from the Ubuntu archive" [Undecided,New] https://launchpad.net/bugs/931809
[15:38]  * ScottK wishes he had powerz for removals.
[15:53] <pitti> infinity: yes, that too; but someone moved it to universe, and it showed up on c-m
[15:53] <infinity> pitti: Yeah, weird that it moved at all.
[15:55] <cjwatson> possibly a side-effect of changing source package, though still odd
[16:01] <infinity> Oh, not odd if it was removed and then NEWed.
[16:02] <infinity> But very odd (and potentially buggy) if it changed source packages and soyuz just decided to demote it willy-nilly.
[16:17] <ara> skaet, ping
[16:37] <skaet> hiya ara,  pong but otp...
[16:37] <stgraber> davmor2: ok, reproduce the bugs (first one is that it doesn't show any wireless, second one is that it doesn't skip with the essid field being empty)
[16:38] <stgraber> *reproduced
[16:39] <davmor2> stgraber: it's nice to know it's not just me for a change :)
[16:39] <davmor2> cjwatson: ^
[16:52] <cjwatson> stgraber: do you have a DEBCONF_DEBUG=developer log?
[16:52] <cjwatson> davmor2: bear in mind I just got back off leave and this isn't top of my list :-)
[16:53] <stgraber> cjwatson: yes, just need to get it off the test machine ;)
[16:53] <stgraber> cjwatson: I found the problem with the scanning though (at least I think)
[16:53] <cjwatson> ok
[16:53] <stgraber> netcfg brings the interface up/down every second during the scan instead of brining it up before the loop and bringing it down afterwards
[16:53] <davmor2> cjwatson: yeap noted
[16:54] <stgraber> so if the card takes > 1s to be ready to scan (as most cards seem to), then you won't get anything
[17:14] <cyphermox> davmor2: I was planning on checking out a d-i install with wireless very soon, I could get this done today if it helps. just let me know exactly what you're looking for, since i'm more trying to reproduce leftover configs from d-i that shouldn't be there after install (otherwise NM doesn't grab the wifi device)
[17:15] <cyphermox> nm, I didn't see some of the backlog
[18:04] <stgraber> can someone from the release have a quick look at bug 946861? it's a minor UI change in epoptes (Edubuntu only) and I confirmed it's not affecting any existing screenshot or documentation
[18:04] <ubot2`> Launchpad bug 946861 in epoptes "[UIFe] show real name menu entry" [Undecided,New] https://launchpad.net/bugs/946861
[19:14] <ScottK> stgraber: Go for it.
[19:15] <ScottK> Feel free to copy/paste that in the bug.
[19:15] <stgraber> ScottK: thanks


[01:31] <lazyPower> any jack audio wizards in here? i've got a working audio routing setup - but the sound i'm getting on the other end is really distorted and sounds ... just... "wrong" is the only way i can describe it
[02:47] <holstein> lazyPower: you can take a picture of your connections
[02:47] <holstein> lazyPower: sound to me like, you have wet and dry linked in somewhere, or something introducing phase
[02:47] <holstein> i would press play, and listen, and try and mess with the route.. try and isolate what is happening
[02:48] <holstein> try *just* a known good audio file, in audacious routed in jack, so you know if its your jack config, or your routing/one of the applications
[02:48] <lazyPower> its the routing
[02:49] <lazyPower> of that much I know
[02:49] <holstein> if something sounds "wrong", that you *know* should sound right, and its only going from that player (audacious) to jack, then, its in the routing
[02:49] <holstein> i mean, its in the jack config, and not the routing ^
[02:49] <lazyPower> i was trying to get funky and i think the issue with the sampling from a pulseaudio-sink connection
[02:49] <lazyPower> to double the trouble - i'm attempting to run zita-a2j to capture a usb soundcard and add it as an output source - no joy whatsoever.
[02:50] <lazyPower> it only shows up with capture devices, no output devices
[02:50] <lazyPower> there are days that make me wonder why i try to be smarter than the tools i'm given.
[02:50] <lazyPower> brb
[02:55] <lazyPower> holstein: thanks for the info though
[02:55] <holstein> sure.. just try and get down through al the layers, and see what you are doing that is causing the "noise"
[02:56] <holstein> i mean, if you want to "capture" from a usb device, it should be class compliant.. but, i would want it to be the only device
[02:56] <holstein> also, try disabling the pulse to jack dbus, and removing it from the equation, at least to test
[02:56] <holstein> its in the "misc" tab in qjackctl under setup.. the "dbus" tickbox
[03:12] <lazyPower> holstein: i still see a pulse audio jack sink after unchecking the dbus tickbox
[03:13] <holstein> lazyPower: did you restart jack?
[03:13] <lazyPower> sure did
[03:13] <holstein> lazyPower: you'll have to stop jack and restart it
[03:13] <holstein> well, i wouldnt overthink that.. just move on to isolating something else
[03:18] <lazyPower> holstein: http://i.imgur.com/7qOkaKx.png
[03:19] <holstein> lazyPower: you have "audio playback" 1 2 3 4 in "bridge" hooked to the card
[03:19] <holstein> why?
[03:19] <holstein> try just 1 and 2
[03:20] <lazyPower> well, "bridge" is a "room" i created in gladish
[03:20] <lazyPower> that apparently does nothing - i had zero audio
[03:20] <lazyPower> works when i link mixx directly into hardware playback
[03:20] <lazyPower> under playback_1 and _2
[03:20] <holstein> sure.. so, get rid of it, if its not in use
[03:20] <holstein> this is the kind of thing i suggest thinning out
[03:21] <holstein> if you are not using them, thin that out, and see what is causing the issue
[03:21] <lazyPower> these all sound fine at the moment
[03:21] <holstein> *great*! enjoy! ..feel free and try #opensourcemusicians
[08:40] <zgorbyo> hi all
[08:43] <zgorbyo> i have just finished installing ubuntu studio keeping my previous ubuntu installation and partitioning, but when i finished and restarted no way to access boot manager and select OS
[08:44] <zgorbyo> please anyone can help me?
[08:56] <zgorbyo> no clue'
[08:58] <vlt> zgorbyo: Try holding down the shift key while booting.
[08:59] <zgorbyo> ok, any way to set grub appear as default?
[09:01] <zgorbyo> ok i try it now
[09:01] <zgorbyo> thanks
[09:01] <zgorbyo> bye
[09:09] <zgorbyo> im back, holding shift hasnt worked, ubuntu booted automatically
[09:44] <zequence> zgorbyo: Check out the file /etc/default/grub
[09:56] <zgorbyo> http://paste.ubuntu.com/9454290/
[09:56] <zgorbyo> zequence: thanks for response
[10:14] <zequence> zgorbyo: Try adding a few seconds to "GRUB_HIDDEN_TIMEOUT=0"
[10:14] <zequence> make it say something like "GRUB_HIDDEN_TIMEOUT=5"
[10:15] <zequence> to edit, you can try: sudo gedit /etc/default/grub
[10:16] <zequence> zgorbyo: This might be helpful too https://launchpad.net/~danielrichter2007/+archive/ubuntu/grub-customizer
[10:16] <zequence> A simple application. No extra libraries in the PPA, so you only install the application itself
[10:17] <zgorbyo> hey here im
[10:18] <zgorbyo> no need for grub settings editing in this last solution?
[13:21] <zgorbyo> hi all
[13:21] <zgorbyo> can anybody help me to install and configure compiz and make it work properly in ubuntu studio?
[13:22] <zgorbyo> i had several tries but no success
[13:25] <zequence> zgorbyo: I've seen some people try that, and have problems. Don't think any of the devs do that. You might find more people who know about that at #xubuntu.
[13:25] <cfhowlett> zgorbyo, or #xfce
[13:25] <zgorbyo> i got into it in the past with suggestions from this channel
[13:26] <zgorbyo> it worked perfectly but i forgot
[13:26] <zgorbyo> maybe fond a good topic
[13:26] <Unit193> compiz --replace is all I can tell you.
[13:28] <zgorbyo> yes i know, but i lost winows decorations and couldn't take them back from compiz plugins
[13:29] <zgorbyo> i am reading that maybe it needs metacity in order to work properly
[13:30] <cfhowlett> zgorbyo, again:  interface issue, not ubuntustudio issue.   ask #xfce or #xubuntu
[13:31] <zgorbyo> ok t y
[13:31] <Unit193> Though #xubuntu doesn't support compiz.
[13:31] <zgorbyo> i alreadyy got it working perfectly in the past
[20:26] <delt> Hello
[20:27] <delt> is there any way to get jack to use more than one sound card?
[20:27] <delt> and route audio signal from one to the other?
[20:29] <delt> for example, i'd like skype to record from the microphone on my second sound card, and from pianoteq (using jack on first sound card) at the same time.
[20:30] <delt> Right now, i can choose one or the other, but is there a way to have jack mix both into a single signal and send it to jack-source?
[20:32] <delt> i would also like to route the line-in on the second sound card to be able to hear it in jack's main output, without using a physical cable to patch the signal through.
[20:32] <delt> Is there a way to do that?
[21:27] <lazyPower> delt: you can - you'll need to use pulse audio jack
[21:27] <lazyPower> oir use a line in input
[21:28] <lazyPower> delt: i just figured this out lastnight as a matter of fact, this diagram using gladish may help you, the pulse-jack-sink is how i'm piping skype/hangouts audio to my broadcast
[21:28] <lazyPower> delt: http://i.imgur.com/SqbevzX.png
[21:29] <delt> lazyPower: thanks very much for the info :D
[21:30] <delt> lazyPower: right now i have the whole pulseaudio system as a jack client using its "jack-sink" and "jack-source" plugins
[21:30] <lazyPower> delt: np, it took me a bit of jiggering to figure it out
[21:30] <lazyPower> delt: as the screenshot illustrates - that seems to be the trick. the dbus interface gives you enough flexibility to do it, but its an all or nothing with pulse sound source
[21:30] <lazyPower> so dont think you can isolate specific apps, you'll want to make sure you're not running system sounds or anything while you're doing the broadcast or you'll get additional noise
[21:31] <delt> yeah, that's what i suspected
[21:31] <lazyPower> delt: however - multiple soundcards can be troublesome as clock drift happens and you get audio artifacting - so ymmv there, i hd teh same goal in mind
[21:31] <lazyPower> i found that zeit-a2j and a2j apps are less than savvy in my case
[21:32] <delt> i use a2j for mapping my midi devices
[21:32] <delt> so that jack-midi-only programs can use them
[21:39] <delt> lazy: anyway, thanks very much for the info
[21:44] <lazyPower> np
[21:44] <lazyPower> best of luck to ya


[03:07] <karstensrage> any ubuntu-backport'ers in here?
[03:26] <micahg> yes
[03:31] <karstensrage> hi micahg are you a backporter?
[03:33] <micahg> yes :)
[03:33] <karstensrage> would you be willing to backport #1561837 and #1562434
[03:34] <micahg> karstensrage: I can, but likely not tonight, is this urgent?
[03:34] <karstensrage> no not at all
[03:34] <karstensrage> but anything i can do to help or assist
[03:35] <karstensrage> they both have been very well tested on trusty and precise
[03:35] <micahg> ok, I should have some time wed evening for backports, it looks like you did all the requisite testing for that, thanks!
[03:35] <micahg> if I forget, please ping me
[03:35] <karstensrage> all my initial launchpad efforts were with ppa installs and it was realy well tested
[03:35] <karstensrage> ok sure
[03:36] <karstensrage> thank you
[03:36] <karstensrage> is it evening now btw for you?
[03:41] <micahg> yes
[03:41] <micahg> and still working :(
[04:07] <Unit193> Fun...
[05:07] <karstensrage> im sorry, maybe some soothing music ?? https://soundcloud.com/whitemorning/eddies-song
[06:43] <dholbach> good morning
[11:28] <TRJD> hello
[11:29] <TRJD> where can I request a program to be added ?
[12:16] <Rhonda> I've uploaded irssi 0.8.19 to xenial, is there something more that I would/could/should need add somewhere so it helps to get it approved?  I have PPU for irssi, and 0.8.19 is a bugfix release for 0.8.18 currently in xenial.
[14:53] <jbayfield> Hi, I'm getting started with this whole MOTU business, I wanted to give back to the community. I was looking at working on a bug (In LP it's #1442873) and I wanted to ask a few questions. When working on a bug, do you carry out the fix on all of the separate branches (ie: Precise & Trusty) or am I overlooking something? The other thing is whether I should set myself as an assignee for the packages or something el
[14:54] <dholbach> welcome jbayfield - looks like your question got cut off
[14:54] <dholbach> if the fix is important enough, you might want to backport it
[14:54] <dholbach> http://wiki.ubuntu.com/StableReleaseUpdates has some guidance on that
[14:54] <jbayfield> Hi dholbach, sorry about that. Where did the question get cut off?
[14:54] <dholbach> "whether I should set myself as an assignee for the packages or something e..."
[14:55] <jbayfield> "The other thing is whether I should set myself as an assignee for the packages or something else.
[14:55] <dholbach> just assign the one bug to you
[14:55] <dholbach> no need to sign up for all the bugs of the given package
[14:55] <dholbach> and feel free to ask more questions
[14:55] <dholbach> they weren't stupid at all
[14:55] <jbayfield> Alright.
[14:57] <jbayfield> So you work on the particular bug one distro release at a time, and then create a separate merge proposal for each affected release?
[14:57] <dholbach> yes, if the bug is important enough
[14:58] <jbayfield> And how are bugs considered "important enough"? At what point does a bug go from "not important" to "important"?
[14:59] <dholbach> have a look at the link I posted earlier
[14:59] <dholbach> it has some decision making help
[14:59] <jbayfield> ah. Okay, thanks.
[15:39] <jbayfield> Thought I'd ask - am I meant to be working on the package in "trusty" or "trusty-proposed"?
[15:40] <jbayfield> Looks like trusty - sorry about that
[16:45] <jbayfield> Hello again - when running bzr lp-propose, what should be left in the text editor that opens? A changelog?
[16:49] <jbayfield> I'm hoping this is all correct: https://code.launchpad.net/~jbayfield/ubuntu/trusty/gnome-do-plugins/bug-1442873/+merge/290337
[16:58] <jbayfield> Looking at it, I think I might have issued a merge request to the wrong place
[17:00] <jbayfield> Is it supposed to merge into trusty-proposed or trusty?
[21:43] <sney> hexchat 2.12.0-1 ftbfs on xenial. using pbuilder with variant=buildd. http://paste.debian.net/422634/ error at line 104.
[21:44] <sney> it's fine on debian testing/sid and also on wily
[22:14] <sney> bah m4/glib-gettext.m4 isn't even in my source tree, the build system installs it and then gripes that it's trying to overwrite macros. explicitly delete it via d/rules and now we build normally.
[22:44] <Unit193> That sounds just fantastic...
[22:45] <sney> it is wonderful


[00:00]  * luk3yx does not know
[00:00] <wgrant> QwertyChouskie: That's not possible.
[00:00] <QwertyChouskie> :(
[00:00] <wgrant> In some cases you can ask LP to import the git repository into a bzr one, and then use that in a bzr recipe, though.
[00:01] <QwertyChouskie> The problem is that the git repo has gpgsig commits in it's history though
[00:01] <wgrant> Yeah, that's the case where you can't :(
[00:01] <QwertyChouskie> I'll just do it manually
[00:01] <QwertyChouskie> thanks
[19:04] <gsilvapt> Hello all. Can someone point to the support channel I should go to get help regarding Ubuntu's 2fa One login?


[06:42] <dpm> good morning all
[07:04] <AskUbuntu> Cross compile LibzDb fro ARM A9 based Micro processor | http://askubuntu.com/q/317664
[07:09] <dholbach> good morning
[07:09] <oSoMoN> good morning dholbach
[07:09] <dholbach> hey oSoMoN
[08:38] <devinceble> Does qtdeclarative5-hud1.0 library present on 13.04 or 13.10 only? I'm getting the library from a ppa right now ppa:ubuntu-unity/daily-build-next -> but its strange without the ubuntu developer sdk and tools installed friends-app beta is running but when i installed the tools it wont run because of hud1.0 cant be found
[08:40] <JamesTait> Oyez! Oyez! Good morning all and happy Town Crier Day! :-D
[09:54] <Mirv> alex-abreu: ubuntu-html5-theme was just accepted into saucy!
[09:54] <Mirv> alex-abreu: please check my latest changes, the autopilot tests are run in a firewalled environment so external content cannot be fetched
[09:55] <Mirv> alex-abreu: I believe a separate test html file is good and the normal index.html for when people want to test the app itself, but I had to disable that one test at least as long as no mockup content is provided (which seemed complicated)
[11:31] <Mirv> if anyone was using the Qt 5.1 beta1 packages from qt5-beta-proper PPA, I copied them now over to qt5-staging PPA (as a backup) and I'm starting Qt 5.1 final builds at qt5-beta-proper ASAP
[13:25] <Kaleo_> Laney: hey
[13:26] <Kaleo_> Laney: I answered in https://code.launchpad.net/~laney/ubuntu-ui-toolkit/crossfadeimage/+merge/170391
[13:26] <Laney> hey Kaleo_, thanks
[13:28] <Laney> Kaleo_: would you prefer I rename it back? I did that for consistency with animations but don't really mind
[13:29] <Kaleo_> Laney: yeah, I 'd rather
[13:29] <Laney> sure
[13:45] <Kaleo_> Laney: oh, and I just pushed another commit to that branch which fixes the FIXME
[13:45] <Laney> oh good!
[13:45] <Laney> These weird behaviours are quite confusing
[13:46] <Kaleo_> Laney: so if you merge that branch, fix 15) & 16) and I guess some unit tests failures, we are good :)
[13:46] <Kaleo_> Laney: this last behaviour is indeed a badie
[14:23] <oSoMoN> Kaleo_: hey, would you have a moment to review https://code.launchpad.net/~osomon/webbrowser-app/ubuntu-colors/+merge/173458 ?
[14:28] <Laney> Kaleo_: The unit tests are indeed broken now and I don't understand why. :)
[14:28] <Kaleo_> Laney: currentImage.status is not the actualy status
[14:29] <Kaleo_> Laney: since currentImage != nextImage
[14:29] <Kaleo_> Laney: even though it really is the nextImage that is loading
[14:29] <Kaleo_> Laney: (that was my intuition anyway)
[14:29] <Laney> it's the running property
[14:29] <Laney> the test_duration one
[14:31] <Kaleo_> oSoMoN: it's good to go; however once the theme color palette lands (tomorrow), we should use that whenever possible
[14:32] <oSoMoN> Kaleo_: yes, so when that lands I’ll do another pass and talk to design to use as many theme colors as possible
[14:32] <Kaleo_> oSoMoN: great
[15:01] <Laney> Kaleo_: what if I have the global status be set in onStatusChanged of both the Images?
[15:01] <Laney> so it becomes the most recent status to be updated
[15:01] <Kaleo_> Laney: not very pretty
[15:02] <Laney> I'm otherwise stuck with how to fix it
[15:02] <Laney> other than going back to what I had before there
[15:02] <Kaleo_> Laney: best would be to have currentImage really be the current image
[15:02] <Kaleo_> Laney: ok, I'll have a look
[15:02] <Kaleo_> Laney: everything else good?
[15:02] <Laney> seems so
[15:02] <Laney> I'll push
[15:03] <Kaleo_> Laney: thanks
[15:05] <Laney> done
[15:42] <nic-doffay> Kaleo_, or anyone else who has some investment in this. Would like to talk a bit about a component which handles scrolling for expanding SDK classes.
[17:47] <Kaleo_> [A
[22:23] <mhall119> l
[22:24] <odraencode> m
[22:34] <surgemcgee> Is there an official tools: format yet? I sont know which one to use.
[23:36] <xkernel> I installed the core apps  on Kubuntu, how to launch them?
[23:44] <mhall119> xkernel: you should get them in whatever menu/app launcher KDE has
[23:45] <xkernel> mhall119, nope can't find them
[23:45] <mhall119> doesn't KDE use /usr/share/applications/*.desktop to list installed apps?
[23:47] <mhall119> xkernel: which apps did you install?
[23:47] <xkernel> mhall119, I installed all as mentioned here: http://developer.ubuntu.com/2013/07/join-the-ubuntu-touch-core-apps-development-team/
[23:48] <mhall119> xkernel: and you installed them using apt-get
[23:48] <mhall119> ?
[23:48] <xkernel> yeah
[23:48] <mhall119> do you have /usr/share/applications/ubuntu-calculator-app.desktop ?
[23:49] <xkernel> yeah found it thanks :)
[23:49] <mhall119> huh, I wonder why it's not in KDE's menus then