[09:57] <Laney> hi, wondering if anyone is looking at mir blocked in xenial-proposed?
[10:01] <Laney> (liburcu hangs on ppc64el)
[10:13] <alan_g> Laney: I'm not aware of it. But I don't see how Mir can impact liburcu?
[10:14] <Laney> it's one of Mir's dependencies
[10:14] <seb128> alan_g, it doesn't impact it directly, it's the other way around
[10:15] <seb128> MIR is blocked because one of the libs it's using needs to be fixed
[10:15] <alan_g> seb128: ah, at least that makes sense.
[10:19] <alan_g> So landing wouldn't break anything that isn't already broken?
[10:21] <seb128> that's not how it works
[10:21] <seb128> that library got an update
[10:21] <seb128> and the new mir built/got linked to that new version
[10:21] <seb128> so landing the mir update means landing the library update with it
[10:21] <seb128> so if the lib has a regression mir might have a regression as well
[10:22] <seb128> even if it's not mir's fault
[10:22] <seb128> or said differently the library you are using needs to be cleared out or it's going to block mir
[10:22] <Laney> And blocking mir means it blocks anything that depends on mir (in this case GTK)
[10:26] <alan_g> alf_: is it AlbertA trying to release Mir to xenial?
[10:27] <alan_g> seb128: I've no idea how to "clear out liburcu" - is this urgent? Or can it wait for the USA to wake up?
[10:27] <seb128> alan_g, it can wait for them to wake up
[10:28] <seb128> alan_g, the issue with liburcu is that the build/tests hang on ppc64el
[10:28] <seb128> so somebody needs to debug why
[10:28] <seb128> (likely an upstream issue, it's also happening in Debian)
[10:28] <alf_> alan_g: Yes, 0.17.1
[10:29] <alan_g> seb128: can't we just use the old version?
[10:30] <alf_> seb128: problem with ppc64el is that we have no reasonable way to replicate the problems locally
[10:30] <alan_g> Who can debug ppc64el?
[10:32] <seb128> alan_g, we would need to delete the update and rebuild mir
[10:32] <seb128> but that's not really constructive, we are going to need to update that lib one day
[10:32] <seb128> so better to fix the issue and move forward
[10:35] <alan_g> seb128: the first problem is the lack of any ppc64el kit on which to investigate.
[10:35] <seb128> Laney guessed that would be an issue :-/
[10:35] <Laney> there's the bos01 cloud
[10:36] <Laney> I would hope that it's possible to get access there
[10:37] <Laney> although... I just tested on an instance there (abusing my access through autopkgtest) and it actually built :(
[10:37] <Laney> one second
[10:38] <Laney> https://bugs.launchpad.net/ubuntu/+source/liburcu/+bug/1511458
[10:40] <Laney> seems it might be a cloud/kernel bug
[10:42]  * Laney asked
[14:09] <pandatrone> what happened to mir?last update is 2015-11-13
[14:09] <pandatrone> 5 days ago
[14:14] <alan_g> pandatrone: MP landings have been backing up because of trouble in CI. Hoping that is now resolved.
[14:14] <pandatrone> alan_g, phew :D thanks!
[14:17] <alan_g> were you waiting on something?
[14:20] <pandatrone> alan_g, nope. i just like to read the new mir updates :D
[14:23]  * alan_g resolves to write interesting commit comments.
[14:23] <pandatrone> :))
[14:54] <anpok_> alan_g: evemu-record worked for me when I dont send it to background
[14:54] <anpok_> but it just terminates otherwise
[14:55] <alan_g> OK, you need both devices at the same time?
[14:56] <anpok_> alan_g: hm I think so yes..
[14:57] <anpok_> but there is also a slight chance that this will be fixed by: https://code.launchpad.net/~andreas-pokorny/mir/use-one-cursor-position-per-seat/+merge/277843
[14:57] <anpok_> but I cannot remember the details
[15:00] <tsdgeos> guys, i need this https://code.launchpad.net/~aacid/mir/eintr_dispatch_loop/+merge/277847 otherwise my unity8 aborts, can anyone with more knowledge of the code have a look and decide if it makes any sense?
[15:06] <alan_g> anpok_: sent. I'll try your branch later
[15:07] <alan_g> tsdgeos: looks weird to me too. I think RAOF wrote most of that code
[15:10] <alan_g> Laney: is the problem with liburcu still needing help from Mir?
[15:26] <anpok_> alan_g: hm ok but you are pressing alt while moving the trackpoint?
[15:26] <alan_g> yes
[15:58] <Laney> alan_g: not right now, hopefully lp will fix it
[15:58] <Laney> https://portal.admin.canonical.com/85976 for those who can see that
[16:25] <alan_g> anpok_: which set of your branches should I merge to test laptop?
[16:46] <alan_g> anpok_: reapplied lp:~andreas-pokorny/mir/load-all-supported-input-platforms and lp:~andreas-pokorny/mir/use-one-cursor-position-per-seat - I still have a problem. The trackpoint controls the cursor unless the middle button is pressed. Alt+left button drags the triangle, Alt on its own or Alt+right just move the cursor. Just pressing the middle button (with or without Alt) and the cursor only responds to the touchpad (
[16:46] <alan_g> but that has never worked with the "mouse" buttons).
[16:58] <anpok_> oh
[16:58] <anpok_> we do not unify the mouse buttons
[16:59] <anpok_> for the input stack the trackpoint and the mouse buttons belong to one device and the touchpad is separate..
[17:00] <anpok_> that means touchpad movement + trackpoint buttons are two separate streams of events hence.. if someone checks for button state on motion events all will be released..
[17:00] <anpok_> but thats simple to combine .. just like we did with modifier..
[17:01] <alan_g> I just don't want to break something that is already working (trackpoint+middle button)
[17:02] <alan_g> I thought it might be diagnostic that the left and right buttons do work
[17:08] <anpok_> hmm yes that is strange
[17:13] <alan_g> is something misidentifying it as a *two* button mouse?
[17:17] <anpok_> oh I have to make sure the server sees the first events too otherwise it will miss the middle button down press
[17:18] <anpok_> yes I can reproduce .. it has nothing to do with any of my theories.
[17:21] <alan_g> anpok_: reproduction is the first step towards diagnosis
[17:29] <anpok_> hum.. and I believe we dont want to have a separate button state between pointing devices