[00:26] mlankhorst: Hey, what's the expectation of buffer lifecycle vis-a-vis dma-buf? It's entirely up to us, isn't it? [00:27] rsalveti: ricmm: I have roughly zero ideas :( [00:28] afk for a little bit soon [00:28] why can qtubuntu [00:28] link succesfully against papi mirclient? [00:29] if the gstreamer codec cant [01:16] rsalveti: possibly also worth noting that the cross-compiler in saucy hasn't been updated since July... [01:35] well but even natively exhibited the issue [01:35] sorry, building natively by hand didnt show the issue [01:35] building with dpkg did, and I do see a couple differences [01:35] racarr: still there? when building the deb pkg it uses -DBoost_COMPILER=-gcc [01:36] robert_ancell: I assume you didn't want a chat yesterday? [01:36] duflu, nope, I'm good if you've got nothing [01:36] The usual... [01:37] Which is nothing not already mentioned on Wed [01:46] ricmm: so by hand vs. packaging could be gcc-4.7 vs. gcc-4.8; and native vs. cross, the cross-compiler for gcc-4.7 actually hasn't been updated since April, even. I'm going to try updating it now. [01:48] for the 4.8 cross-compiler, I was mistaken, it is up-to-date wrt the native compiler [02:05] ricmm: Still around [02:06] yea [02:06] hmm I remember that flag used to be necessary to build on android [02:06] asking me? or answering [02:06] but don't know the etymology [02:06] more answering [02:06] than asking :p [02:06] right [02:10] racarr: alright so I see the issue, not sure how to fix it [02:11] src/client/mir_client_library.cpp has a global std::unordered_set MirConnection::valid_connections; [02:11] but thats a static member var of MirConnection [02:12] when building Debug (unoptimized), the internal unordered_set's Hashtable has a correct address (_M_buckets) [02:12] when release, the address is set to the next field's value (bucket_count), both to 0x17/23 [02:13] obv when it goes to clear it in the destructor and it memsets at 0x17 it goes boom [02:13] it feels like a compiler bug [02:14] ricmm: Maybe break during initialization and set [02:14] a watch on the pointer [02:14] to see if it gets overwritten due to memory corruption [02:14] or if it really is a compiler bug [02:17] well you don't even need a watch right? I guess just [02:17] is it set incorrectly at initialization [02:17] yea trying to get there [02:17] its just templates and templates [02:17] sec [02:21] so you think the miscompile is in libmirclient, not in platform-api? [02:33] wtf ! [02:33] racarr: ping [02:33] http://paste.ubuntu.com/6220619/ [02:34] _M_buckets is changing [02:34] and whatever is doing it is happening in mirclient p-api [02:34] sigh [02:34] * ricmm rebuilds papi with symbols [02:35] hey, do you guys know if steam os is going to run mir? [02:37] ricmm: What is your test case? I mean [02:37] opening a connection [02:37] oh well I guess it shouldnt change the address [02:38] theres no test case [02:38] loading the library is enough, as it creates the static set of MirConnection* [02:38] oh its literally just an empty program? [02:38] yea [02:39] racarr: https://launchpad.net/bugs/1238312 [02:39] Ubuntu bug 1238312 in mir (Ubuntu) "Segfault when closing apps that link against ubuntu_application_api_mirclient" [Critical,Confirmed] [02:40] the empty example is there [02:40] ok well hopefully papi debug symbols should be enlightening === chihchun is now known as chihchun_afk [02:48] poor gdb [02:48] not easy to watch for expressions ina c++ heavy stack [02:50] nvm its stuck [02:50] sigh [02:50] oh no its not, just taking 100x times to run [02:52] racarr: http://paste.ubuntu.com/6220667/ [02:53] looks like when error_connections is created, valid_connections goes to hell [02:56] ricmm: Hrm :/ [02:58] it smells like compiler bug, but compiler bug smells like...probably not :p [02:58] ricmm: So wait why does qtubuntu work [02:58] I just built everything on device today, and clients seem fine, ran a bunch of autopilot tests, etc [02:59] it works when we use the library [02:59] at which point valid_connections will grow [02:59] and it will most likely fix itself [03:00] lol [03:00] mm [03:04] ricmm: so it only happens when you link to ubuntu-application-api-mirclient [03:04] which also pulls in hybris [03:05] I wonder if its some sort of hybris wizardry gone wrong [03:05] seems as likely as a compiler bug [03:05] seriously doubti ts hybris [03:05] we are nowhere near nadroid at that point [03:06] but hybris has some [03:06] pthread [03:06] wizardy right [03:06] and the valid connections set is [03:06] potentially right next to a mutex [03:06] hmm which one? [03:06] std::mutex MirConnection::connection_guard [03:07] oh that one of course [03:07] lol [03:07] thats not a bad guess [03:08] I could get a dbg hybris and check if we are hitting something weird [03:08] Seems worth figuring out [03:08] Dinner just showed up and I will be finished soon and start working more focused on this too... [03:08] now I am puzzled XD [03:12] ricmm: Err so [03:12] I'm gonna move that thing to be initialized *after* error_connections [03:12] and see what happens [03:12] heh [03:12] on my phone, which...I flashed this afternoon, latest image I believe, then proceeded to build mir, platform-api (mirclient+mirserver), qtubuntu and unity-mir on [03:13] the test program doesnt segfault? [03:13] how did you build mir [03:13] Debug or Release? [03:13] Ah [03:13] it has to be optimized [03:13] otherwise it works [03:14] ok rebuilding [03:17] sigh... [03:18] racarr: swapping order of init with the mutex fixes it [03:18] perhaps you are right with hybris and the mutex [03:23] duflu, what does "this is the one" mean? [03:23] robert_ancell: As in the rules don't allow us to roll any more...? [03:23] the one for? [03:23] i.e. the final version for saucy? [03:23] robert_ancell: Yes. Unless we have exceptions? [03:24] racarr: I dont like it at all :) [03:25] racarr: im gonna eat and stuff its kinda late here maybe ill sleep [03:25] I'll work early tomorrow to look at hybris and whats going on there [03:25] for the time being.... [03:25] racarr: https://code.launchpad.net/~ricmm/mir/lp-1238312/+merge/190524 [03:25] robert_ancell: I suspect we had an exception since everything against phone-v1-freeze hasn't hit lp:mir or the archive yet [03:25] duflu, in a perfect world, but we might have things due to 1) or 2) in https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-October/001064.html [03:26] duflu, I believe the plan is for the phone to switch straight to t-series, so new work will go in there [03:26] robert_ancell: Yeah of course. I'm just curious where saucy maintenance branches from. Looks like lp:mir r1096 [03:27] duflu, that seems likely [03:28] duflu, your email lacks a little context there :) [03:28] robert_ancell: The point is Mir got released, or soon will be. One of them [03:28] brb [03:30] ricmm: Ok so the risk is [03:30] if its not a compiler bug and something really is overwriting the mutex [03:31] then moving it [03:31] just defers [03:31] issues [03:31] I know [03:31] dont happrove that just leave it there sitting for now [03:31] and im the morning ill look into hybris and pthread mutexes [03:31] mm [03:32] ill give it some look over night [03:32] alright [03:32] Thanks for digging :D [03:42] racarr: this is not something with hybris [03:42] otherwise it'd not even work with the O0 version [03:43] hybris just maps function calls, don't change the program stack :-) [04:00] RAOF, there's no way to tell XMir to look for "no Mir socket" right? I think that's the last piece to fix bug 1211141 [04:00] bug 1211141 in Unity System Compositor "Unity system compositor allows connections from any Mir client" [Critical,In progress] https://launchpad.net/bugs/1211141 [04:01] robert_ancell: How do we tell normal clients to do so? XMir does have a -mirSocket option. [04:01] RAOF, yeah, but I don't set that anymore and it defaults to /tmp/mir_socket [04:01] the only way it doesn't use /tmp/mir_socket is if I give it something [04:02] but in this case there is no socket [04:02] I think we can just drop the default and set it to NULL now [04:02] We didn't use URI specifiers for the bare-fd case? [04:03] RAOF, I guess that might work, but I'd kind of like to just use the environment variable [04:03] I'll try that [04:04] Yeah, looks like you could send -mirSocket fd://4 [04:04] (For example) [04:07] robert_ancell: Looks like the XMir in the archive will pass NULL through to mir_connect if you don't explicitly pass mirSocket; that presumably does what you want. [04:07] RAOF, I read that it won't due to: [04:07] robert_ancell: Or, rather, if libmirclient treats NULL as ‘look in an environment variable’, then that'll do what you want ;) [04:08] yes mirclient does the right thing, but I think it's impossible for XMir to send NULL [04:08] due to: [04:08] if (mirSocket != NULL) [04:08] socket = mirSocket; [04:08] That's not in the current code. [04:09] ah [04:09] RAOF, what is the correct branch? [04:11] brb [04:11] bottom approved https://code.launchpad.net/~ricmm/mir/lp-1238312/+merge/190524 as well [04:13] RAOF, hmm, that didn't work either. [04:14] [ 1247.459] (EE) Failed to connect to Mir: connect not called [04:15] have to solve that one another time, bye all [04:16] robert_ancell: Please leave the door open for running native Mir clients in USC. It's frequently a critical way to triage bugs... [04:16] duflu, it's just a flag that's passed to u-s-c (--no-file) [04:17] robert_ancell: Yeah OK. Optional is good [04:17] I would make it the default but mir is a pita in allowing changes like that [04:30] Harumph. [04:40] RAOF: no idea [04:52] mlankhorst: Ok. I think I was mistaken, and they're per-drm-fd, which makes the point moot. === chihchun_afk is now known as chihchun [05:45] duflu, resubmitted [05:45] tvoss: Already reapproved [05:45] duflu, thx [06:35] RAOF: ;D [06:38] mlankhorst: It's a little odd that gem handles are the only thing that *aren't* refcounted, but that's ok :) [06:45] alf_, ping [06:46] tvoss: pong [07:32] RAOF: the fd isn't either [08:40] alan_g, alf_ I would appreciate if the both of you can make yourself familiar with https://code.launchpad.net/~kdub/mir/android-buffer-syncfence [08:41] alan_g, alf_ it tackles the performance issues on mako and maguro. It's on hold, but I would like to see it in Monday the latest [08:41] tvoss_: Rats. Just when I cleared interruptions and got back to "very important" [08:42] alan_g, sorry :) that's life :) [08:43] * alan_g wonder when he'll be allowed to fix the shutdown/restart cycle [08:44] tvoss_: Does this branch actually fix the issue, or does it prepare the ground for the real fix? According to the description it does the latter, but perhaps I have misunderstood. [08:44] alf_, it actually fixes the issue [08:56] alf_, alan_g also https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238287 [08:56] Ubuntu bug 1238287 in unity8 (Ubuntu) "unity8 crashed with SIGABRT in raise()" [High,Confirmed] [08:56] alf_, alan_g Saviq is working to get us a better stacktrace [08:57] tvoss_: alan_g: ok, I will pick that up when I am done with the first pass of kdub's MP [08:58] alf_, thx [09:13] mlankhorst, hi [09:13] could you get a look at this: https://code.launchpad.net/~hikiko/mir/mir.fix-in-session-leader/+merge/190353 if you have a moment? [09:28] RAOF: oh btw I patched mir a little too while I was debugging [09:28] http://paste.debian.net/55897/ [09:29] in nested mode mir shouldn't claim a vt [09:30] hikiko: actually there was a thing about that.. [09:30] :) what thing? [09:31] oh fine just keep it like that if it fixes it :P [09:32] yeah should be ok [09:33] it fixes it, my only obsession was that there might be a case where a session leader has a controlling terminal, but since in the next line you do: openvt it should be fine isnt it? vt == new controlling terminal [09:33] could you approve it? [09:34] sec [09:36] hikiko: meh obscure posix stuff, I need a moment to read up again.. [09:36] Do we still not have CI running tests on Android? [09:37] sure mlankhorst no prob :) [09:37] hikiko: does being a sesion leader imply we own a process group too? [09:38] hm I guess [09:39] when you become a session leader you also become the leader of a new process group [09:40] * duflu used to know what that meant, but forgot [09:40] and you cant become the session leader if you are a pg leader so that's why you break the group there I guess [09:41] I think what you do is similar to the double fork trick that leaves one process without controlling terminal [09:43] because you want to assign the vt as controlling terminal when you call openvt [09:45] well good enough, I don't want to worry about it too much [09:46] yes, it's a minor change it just fixes the tests [09:47] * mlankhorst instantly forgets everything about posix sessions again [09:47] could you approve it so that we merge it? [09:47] lol [09:48] mlankhorst: hikiko: The question is: what's the purpose of the code there. To claim a new controlling terminal, or to ensure we have none? [09:49] alf_, since mir usually starts from a tty without being a session leader [09:49] it might have a controlling terminal [09:49] to claim the controlling terminal, but in some circumstances I guess we already own it [09:49] meh lets see [09:49] what we want is that it leaves the terminal and gets the vt [09:49] we should be session leader to intercept SIGHUP and SIGCONT [09:50] mlankhorst: hikiko: if the purpose is to be able to claim a new controlling terminal, the code is fine. If it is to ensure we have none, then it is not. [09:50] then it's fine [09:50] alf_, the open vt command right after the if(..) [09:51] assigns a controlling terminal (the vt) to the session leader [09:51] so we do have a controlling terminal :) [09:52] hikiko: ok then, approved [09:53] thanx [09:53] * alan_g is about to debug stuff that tends to break the graphics stack when it goes wrong === alan_g is now known as alan_g|vt === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === hikiko is now known as hikiko|lunch === chihchun is now known as chihchun_afk === hikiko|lunch is now known as hikiko [12:48] hey folks, any idea about bug #1238645 ? [12:48] bug 1238645 in Unity 8 "Shell does not get autopilot keyboard input if maliit isn't running" [Undecided,New] https://launchpad.net/bugs/1238645 [12:53] Saviq, why would you stop maliit-server ? [12:53] Saviq, it is tied to the shell through an upstart job [12:53] ogra_, it's "simulating" a crash [12:53] Saviq, to guarantee that it is always up [12:53] ogra_, doesn't seem to be in some of our autopilot test [12:54] s [12:54] Saviq, right, the last fix for the upstart job went just in [12:54] ogra_, but it should work regardless [12:54] how would it work ? [12:54] ogra_, it works through uinput [12:54] if a test tries to use the not running OSK [12:54] Saviq, might well be that /dev/uinput is left with weird permission/weird state when maliit crashes [12:54] ogra_, not through maliit [12:54] ah [12:55] tvoss_, maliit uses /dev/uinput? [12:55] tvoss_, maliit isn't a standard input device is it? [12:57] definitely not [12:57] hmm, though we ship it by default [12:57] root@ubuntu-phablet:/# ls -l /dev/uinput [12:57] crw-rw---- 1 root autopilot 10, 223 Oct 11 14:35 /dev/uinput [12:58] with proper permissions even [12:58] Saviq, check the permissions during and after the run [12:58] probably autopilot breaks them [12:59] ogra_, ah interesting [12:59] crw-rw---- 1 system bluetooth 10, 223 Oct 11 10:44 /dev/uinput [12:59] hah ;) [12:59] lol [13:00] so just get a BT keyboatd for your test [13:00] *keyboard [13:00] and you will be fine [13:00] the interesting thing is that it works [13:00] (well, you might also need a robot to punch the keys ... but thats a minor detail) [13:01] ogra_, would like to see the branches linked to the bug report for building the robot [13:01] ;) [13:01] haha [13:01] Saviq, so find out what mangles the permissions [13:01] ogra_, tvoss_, chowning :autopilot doesn't matter [13:01] nothing in AP should touch them [13:01] ogra_, nothing now ;) [13:02] ogra_, they're at autopilot now [13:02] ? [13:02] who is they [13:02] ogra_, I've chmod'ed :autopilot [13:02] the permissions are set by udev rules [13:02] ah [13:02] ogra_, and it's still working / not changing [13:02] :( [13:02] ogra_, and anyway ap wouldn't be able to chmod it would it [13:02] ogra_, running as phablet [13:03] hmm [13:03] or chown [13:03] try to chgrp it to android_input [13:03] phablet is in that group [13:05] ogra_, but it *does* work when maliit is running [13:05] ogra_, and perms don't change [13:05] ogra_, I doubt it's so low level an issue [13:07] Saviq, is qt expecting an input method to run to process key events? [13:08] Saviq, at least on mobile platforms? [13:15] tvoss_, no, I can use python + autopilot to type in there [13:15] tvoss_, when maliit isn't running [13:15] tvoss_, just it doesn't happen when ran through tests [13:16] Saviq, so what is the actual problem then? [13:16] Saviq, ah [13:16] :) [13:16] tvoss_, so we need someone to track where the events get lost [13:16] tvoss_, and/or if they're even delivered at all [13:16] asac, ^ we might need someone from your team here [13:16] tvoss_, reproducible locally as the bug describes [13:16] tvoss_, so someone just needs to look at the events from autopilot all the way up to unity8 [13:17] tvoss_, to see where they disappear [13:18] wait [13:18] Saviq: thats the problem? group getting changed on /dev/uinput? [13:18] no [13:19] tvoss_, asac, it's nothing infrastructural [13:19] Saviq, okay [13:19] tvoss_, the events just don't get through the whole stack [13:19] Saviq, but you can manually send events from autopilot? [13:19] tvoss_, yes, with autopilot.input.Keyboard - yes [13:20] ok let me know if it turns out a premission problem on /dev/uinput in the end [13:20] asac, can someone from your team look if autopilot is having issues during the test run? [13:20] tvoss_, tried under different scenarios of maliit stopping after / before autopilot creates the Keyboard object [13:21] but everything worked fine no matter what I tried [13:21] during which test run? [13:21] sorry i lack context [13:22] asac, https://launchpad.net/bugs/1238645 [13:22] Ubuntu bug 1238645 in Unity 8 "Shell does not get autopilot keyboard input if maliit isn't running" [Undecided,New] [13:25] tvoss_: and you guys say you cant reproduce it? [13:25] e.g. its always working for you? :) [13:25] asac, it's reproducible every time. However, when running autopilot manually and injecting key events, everything works === jhodapp|afk is now known as jhodapp [13:45] guys, seen anything like https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1236251 already? [13:45] Ubuntu bug 1236251 in ubuntu-system-settings (Ubuntu) "system-settings crashed with SIGABRT in raise()" [High,Confirmed] [13:45] let me upload a better .crash [13:46] since lp/apport decided to drop everything, 'cause it's a duplicate of a private bug :P [13:46] Saviq, those Mir guys are mean to system settings [13:46] seb128, yeah, can you access https://bugs.launchpad.net/bugs/1234930 ? [13:46] Error: ubuntu bug 1234930 not found [13:46] * Saviq hates private crashers [13:46] Saviq, yes, make it public for you [13:46] seb128, thanks [13:46] not that it's useful... [13:47] useless [13:47] ok /me uploads a better crash === dandrader_ is now known as dandrader [14:29] alf_, where is alan_g? [14:30] tvoss_: I don't know, last I saw was "* alan_g is about to debug stuff that tends to break the graphics stack when it goes wrong" === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === chihchun_afk is now known as chihchun [15:39] tvoss_: didrocks: please ensure that lp:mir and lp:development-branch stay in sync, i.e. commit to development-branch first and then merge into lp:mir manually, even when in a hurry [15:39] alf_: we discussed that with duflu, the dev branch should contains it as well [15:41] didrocks: it doesn't and tracking changes can get confusing, as I am sure you know [15:44] didrocks: hmm, sorry it does, but that shows that these back and forth merges are difficult to track... [15:45] alf_: I don't understand why your team recreated trunk somewhere else [15:45] but that's another discussion I can't tackle now [15:49] hey guys, I have the new mir-enabled builds for the phone, how can I take a screenshot now? [15:49] /system/bin/screencap doesn't work anymore [15:49] mhall119, i don't know that there's a way at the moment [15:50] :( that will put a serious dent in my Google+ postings === chihchun is now known as chihchun_afk === om26er is now known as om26er|food [15:57] didrocks: tvoss_: fixed typo and synchronized lp:mir and development-branch [15:58] alf_: thanks! [15:59] alf_, thanks === jfunk is now known as jfunk-afk [16:25] is there a way to run mir headless? like Xvfb does? [16:31] mhall119: you might want to try this for screencap with mir http://people.canonical.com/~j-lallement/touch/mirfbdump [16:31] robotfuel: thanks, balloons gave me that and it works perfectly === dandrader is now known as dandrader|lunch === om26er|food is now known as om27er === om27er is now known as om26er [17:15] Saviq: WSeems like probably there is a switch [17:15] errr [17:15] ...whoops. IRC was stuck about 2 pages up === dandrader|lunch is now known as dandrader [18:30] kdub: no pressure - just curious....when do you think you might MP the "Ricky Bobby" patch [18:31] kgunn, working on it right, now, i'm hoping by eod [18:32] kdub: cool...i was just asking that way if you did...i could queue it up for Monday [18:52] * greyback eod [19:44] unit tests are... 103mb [19:45] does anyone knows why the autobuilder is not producing armhf binaries? [19:45] looking at https://code.launchpad.net/~kdub/mir/android-buffer-syncfence/+merge/189717 [19:45] seems it's not even building for armhf [19:46] i think we had some trouble with jenkins? [19:46] something i heard from alf_ during the daily mir standup [19:47] hm, ok [20:01] kgunn: https://bugs.launchpad.net/ubuntu-clock-app/+bug/1238798 [20:01] Ubuntu bug 1238798 in Ubuntu Clock App "Clock app doesn't work on mir on maguro" [High,Confirmed] [20:01] clock core app renders black under mir, fine in sf [20:02] popey: huh...which image [20:02] I'm using 93 [20:02] popey: any other apps doing that ? [20:03] popey: and specifically on 93, you deleted .display-mir and it worked ? [20:03] lemme try that to confirm [20:05] kgunn: sorry, stand down - black on sf too [20:05] popey: ;) === jfunk-afk is now known as jfunk [21:56] popey, I wonder if that is related to https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1229287 [21:56] Ubuntu bug 1229287 in Ubuntu UI Toolkit "Drawing apps show only a black screen where drawable component should be" [High,Confirmed] [21:59] jono: its new, sergio was looking at it in -touch [22:00] popey, aha! === jhodapp is now known as jhodapp|afk