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