[03:06] <anpok> RAOF: oh hm kernel 3.12
[03:07] <RAOF> anpok: Oh, yeah. Forgot about that. It'd be easy enough to provide a less-efficient work-around, though. (uinput via libevdev)
[03:08] <RAOF> Or maybe, just maybe, the phone platforms we need this on will use a kernel less than two years old!
[03:10] <anpok> seems simple to backport
[03:10] <RAOF> Also true.
[03:24] <RAOF> Now with bonus Xorg crash!
[06:27] <RAOF> Heh. I love the juxtaposition of https://code.launchpad.net/~alan-griffiths/mir/simplify-connect-code/+merge/268740/comments/675948 with https://code.launchpad.net/~vanvugt/mir/fix-1476201/+merge/268693/comments/675947 :)
[06:40] <guest42315> uu mir 0.15 in wily
[06:40] <guest42315> too bad wily is broken X-(
[06:48] <RAOF> Shouldn't be (anymore)
[07:02] <duflu> RAOF: Do as I say, not as I do
[07:03] <duflu> Generally I don't mean to me contradictory. It just sounds that way if I fail to communicate adequately
[07:04] <duflu> Woo, Mir 0.15.0 is done. Unfortunately even with that large bug count subtracted the backlog remains over 300 now
[07:12] <RAOF> duflu: Yeah; writing code that's readable for other people is hard (which is one reason why we have reviews ☺)
[07:13] <duflu> RAOF: I still wish we could get more reviewers. mir-team feels statistically not quite significant and we sway with confirmation bias (and mood) a lot
[07:15] <duflu> Or even better: testers(!)
[07:18] <RAOF> Eh, testers solve a different problem
[07:18] <duflu> RAOF: They would solve one problem, of reviewers approving things that actually don't work :)
[07:19] <RAOF> Well, reduce it :)
[07:22] <duflu> An interesting observation I made years ago (and continues to be true throughout the world) is that some projects without code review actually yield higher quality. It's a matter of being able to achieve a sufficiently high throughput that your average number of fixes significantly outweighs the regressions.
[07:23] <duflu> There is risk of course, but that can be mitigated with long release cycles and branching (which Ubuntu doesn't quite accommodate)
[07:34] <duflu> Although I only remember that working when there actually was a dedicated test team. And more full-time testers of the code than developers
[08:56] <duflu> Umm, Jenkins is over-eager now: https://code.launchpad.net/~vanvugt/mir/merge-distro-changelog-0.15.0/+merge/268884
[12:50] <alan_g> alf_: you're on wily - could you check which libmirclient .so is used by glmark2-es2-mir? (I'm at the pocketdesktop sprint with only vivid to hand)
[12:50] <alf_> alan_g: sure
[12:54] <attente> http://paste.ubuntu.com/12183271/ <- does anyone know what this error means? i can't seem to launch a u8 session
[12:54] <alf_> alan_g: libmirclient.so.9
[12:56] <zzarr> Hello!
[12:56] <zzarr> are there any nVidia Mir drivers yet?
[12:56] <alan_g> alf_: that's good, thanks. (Now I just have to double check overlay)
[12:57] <guest42315> zzarr, mir runs on nouveau
[12:59] <zzarr> okey, so they are not finished yet I guess
[13:01] <anpok> zzarr: yes.. time will tell if they will settle gbm ..
[13:01] <anpok> or they might continue with their own path.. and expose something along the lines of the egl streams extension
[13:02] <alf_> attente: what versions of mir packages do you have? (e.g. dpkg -l '*mir*' | grep '^ii' )
[13:03] <zzarr> anpok, thanks
[13:55] <kdub> vogons, reviews of https://code.launchpad.net/~kdub/mir/fix-1487967/+merge/268908 ?
[13:55] <alan_g> kdub: I'm trying to track down a CI problem on mako and am seeing "<ERROR> MirBufferStream: Error processing incoming buffer error registering graphics buffer for client use" in src/platforms/android/client/gralloc_registrar.cpp. (This is running glmark - which hangs.) Is this error likely to be significant?
[13:55] <alan_g> kdub: will look
[13:55] <kdub> alan_g, sounds like https://bugs.launchpad.net/mir/+bug/1441553
[13:56] <kdub> which happens when overallocation occurs, there's a quick fix in there to try out (increase mf::client_buffer_cache_size)
[13:57] <kdub> basically, the client and server don't agree on how many buffers are around, which android has a hard time with
[13:57] <alan_g> kdub: would that be causing a hang? https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/6354/console
[13:58] <kdub> I guess its not unfathomable that it could
[13:58] <alan_g> OK, what's a good size to try?
[13:59] <kdub> probably 4 (nbuffers + 1)
[14:17] <attente> alf_: thanks, i had two different versions installed
[14:17] <alf_> attente: np
[14:20] <alan_g> kdub: the "quick fix" seems to fix my problem locally. (I assume it isn't a good thing to add to my MP though.)
[14:22] <kdub> the bad side effect with the cache size being 4 is that we can potentially have 2 old buffers lingering on the client client side
[14:22] <kdub> and, its in progress because with nbs, the client and server agree on the buffer count
[14:25] <kdub> but, I guess the side effect is better than the symptoms
[14:25] <kdub> its not a regression, but a problem with the overallocation feature of BufferQueue... so reverting that is another solution
[14:27] <alan_g> OK, I'll add to the MP with a dirty great TODO and see if it also works in CI
[14:32] <kdub> alan_g, ack, sounds good
[14:42] <alan_g> kdub: Like this? LL90-93 https://code.launchpad.net/~alan-griffiths/mir/fix-1486496/+merge/268747
[17:23] <bschaefer> anpok, im not at the sprint :)
[17:24] <bschaefer> anpok, and yeah revoking the fds could be an issue ... as well as adding the changes in relative mouse... possibly RAOF has ideas on that?
[17:25] <anpok> bschaefer: RAOF pointed me to a ioctl in evdev to do that.. just read about it last night.. since kernel 3.12
[17:26] <anpok> so atm not available in touch kernels..
[17:26] <anpok> but it was made for us :) in an embarssing way
[17:26] <anpok> i am off for a moment
[17:26] <bschaefer> thats nice :)
[17:26] <bschaefer> anpok, are we still focusing on dbus as well?
[17:26] <bschaefer> then trying to implement the fd?
[17:26] <bschaefer> passing
[17:28] <anpok> yes usc-dbus interface .. and later a input configuration / introspection .. through mirclient
[17:28] <anpok> the chances for fd passing to happen have declined..
[17:28] <bschaefer> sweet
[17:28]  * bschaefer goes to figure out how dbus works
[17:28] <bschaefer> never actually used it for the most part :)