| RAOF | So, now that I'm building clang, libstdc++6, *and* mir at the same time it's probably time to turn on the coffee machine. | 00:26 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| RAOF | Hm. We're not actually well set up for having platform plugins out of tree, are we :) | 03:45 |
| RAOF | The MirPlatformType enum is particularly egregious. | 03:46 |
| racarr | Yeah I was thinking about that today...restubbing | 03:47 |
| racarr | the platform | 03:47 |
| racarr | (for qtmir acceptance stuff...whether or not that should be done that way is another thing) | 03:48 |
| RAOF | I think I'm about to introduce an honest-to-god stub platform. | 03:49 |
| RAOF | But it's going to lie about being gbm. | 03:49 |
| RAOF | And, obviously, if we got an nvidia or AMD or Qualcomm or whatever platform there's that fun. | 03:49 |
| racarr | honest to god stub platform? | 03:51 |
| racarr | in what senbse | 03:51 |
| RAOF | In that it's got a client-platform-stub.so and a server-platform-stub.so that the regular platform loading machinery can deal with. | 03:52 |
| * duflu wonders what happened to the header-only driver design. That was nice | 03:52 | |
| RAOF | We never had a header-only driver design, because that can't work? | 03:53 |
| RAOF | I mean, if the driver is only a header, then it needs to be built in at library-build time? | 03:53 |
| duflu | RAOF: I mean the only dependency pulled into driver code is a header. The driver provides the object code to fulfil the contract of the header | 03:54 |
| RAOF | We still have that. | 03:54 |
| RAOF | I think. I've obviously not tried recently :) | 03:54 |
| RAOF | Certainly for the client platform that's true. | 03:54 |
| duflu | RAOF: OK, that sounds nice. It would mean linking to libmirplatform is completely optional and unnecessary if you can provide your own logic | 03:55 |
| duflu | Hence, no one can question the licensing | 03:55 |
| * duflu wants to write drivers for Mir, just to get a feel for what it's like | 03:56 | |
| RAOF | You can easily question the licensing - the driver is being loaded into a GPLv3 process and will be using symbols from that process. | 03:57 |
| duflu | RAOF: Not if it's *not* using symbols from that process. That's the point of a careful header design | 03:58 |
| RAOF | Yeah, but that's basically impossible for C++. | 03:58 |
| duflu | RAOF: Not sure if C++ makes it impossible, but C would be nice | 03:58 |
| RAOF | Implementing the class requires symbols from the definition. | 03:58 |
| RAOF | Heh, yeah. That does make it easier. | 03:59 |
| duflu | RAOF: You're still thinking backwards. Drivers should (and can theoretically) use zero symbols from us | 03:59 |
| duflu | Of course, I want to write a driver to get a feel for how hard it is right now | 03:59 |
| RAOF | I'm pretty sure they can't use no symbols from us. | 04:00 |
| RAOF | Certainly the client platform library cannot use no symbols from us, because it needs the symbols for the ClientContext* we pass it. | 04:01 |
| seb128 | hey there | 04:02 |
| seb128 | what's the difference between XMir and rootless X support in Mir? | 04:02 |
| duflu | RAOF: I don't think declaring it impossible is helpful. Although I'll drop the topic for now because we're some way from that kind of license-independent architecture. Keep it for future-Mir | 04:02 |
| RAOF | seb128: Nothing. | 04:03 |
| seb128 | looking at slides which have the first one for next cycle and the other one for the cycle after, are both solutions to allow running xapps/libreoffice/...? | 04:03 |
| RAOF | seb128: Rootless X support (in XMir) is for seamlessly running X11 apps in a Unity8 session. | 04:03 |
| duflu | seb128: XMir has a root window by default (always draws the whole screen), and so is not "rootless". Rootless lets you run X apps in someone else's shell | 04:03 |
| seb128 | so XMir = can run e.g libreoffice in fullscreen | 04:04 |
| seb128 | rootless = can run libreoffice as a window under Mir/unity8? | 04:04 |
| RAOF | seb128: Yes, ish. | 04:04 |
| seb128 | thanks | 04:04 |
| duflu | seb128: The app can be a window either way. Rootless just means you don't have the X desktop in the way | 04:05 |
| RAOF | seb128: It's a little more like XMir (non-rootless) = X-under-a-system-compositor | 04:05 |
| duflu | But who cares about X when the toolkits are native to Mir? (!) :) | 04:05 |
| RAOF | duflu: And rooted means that you need to be running a Window manager in there :) | 04:05 |
| duflu | Ugh, yeah that sucks resources. Then again X will suck resources either way | 04:06 |
| seb128 | lol | 04:06 |
| seb128 | thanks guys | 04:06 |
| seb128 | just reviewing slides | 04:06 |
| seb128 | have to go back in the part of the office where internet keeps dropping now, I might drop offline | 04:06 |
| duflu | They have a Faraday cage? | 04:08 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| RAOF | And there we go. A proper stub platform passes the tests. Yay! | 05:00 |
| RAOF | Well, most of them. | 05:05 |
| RAOF | Those which aren't explicitly testing the android client platform apparently. | 05:05 |
| duflu | Hah. The universe is determined to drive me insane today. Now the smoke alarm is beeping at me in case it wasn't working yet | 05:56 |
| === seb128_ is now known as seb128 | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| RAOF | And we (finally!) have a fully-passing test suite, bar the ABI checks. | 08:02 |
| RAOF | HUZZAH! | 08:02 |
| duflu | RAOF: W00t | 08:11 |
| duflu | RAOF: The scripts to help with the ABI checks should land soon | 08:12 |
| alan_g | camako: is there a qtmir branch corresponding to Mir-0.6? (The corrections to the .pro files don't work with Mir-0.5 as its .pc files are broken) | 09:26 |
| alan_g | camako: https://code.launchpad.net/~alan-griffiths/mir/revisit-package-config/+merge/229414/comments/556881 | 09:42 |
| * camako looks | 09:49 | |
| camako | alan_g, thanks for fixing! But the fixes should really go into the devel-mir-next branches (for both u-s-c and qtmir). At least one of the fixes (new_ipc_...) has already been fixed in that branch (so this would conflict). We have the devel-mir-next branches in the silo also, which makes it convenient for the release.. | 09:57 |
| camako | http://bazaar.launchpad.net/~mir-team/qtmir/devel-mir-next/ | 09:57 |
| camako | http://bazaar.launchpad.net/~mir-team/unity-system-compositor/devel-mir-next/ | 09:58 |
| alan_g | camako: OK. I'll redo the MPs | 09:58 |
| camako | alan_g, thanks and sorry for the double work - I shoulda told you earlier... | 09:59 |
| alan_g | camako: done | 10:08 |
| camako | alan_g, great thanks | 10:08 |
| camako | alan_g, have you tried building unity-mir? | 10:14 |
| camako | and papi? | 10:15 |
| alan_g | camako: on my list (I thought we'd s/platform-api/qtmir/ | 10:15 |
| alan_g | ) | 10:15 |
| camako | alan_g, actually qtmir is supposed to replace unity-mir... | 10:16 |
| alan_g | Sorry, thinko | 10:16 |
| camako | alan_g, but unity-mir is in the silo as well for that new_ipc_.... fix | 10:17 |
| camako | alan_g, please use the mir-next-devel branches for these as well | 10:18 |
| camako | http://bazaar.launchpad.net/~mir-team/platform-api/devel-mir-next/ | 10:18 |
| camako | http://bazaar.launchpad.net/~mir-team/unity-mir/devel-mir-next/ | 10:19 |
| camako | alan_g, argh... have you seen the conflict on revisit-package-config? | 10:24 |
| alan_g | camako: Another one? | 10:25 |
| camako | alan_g, I think there was only one.. so you've seen it I guess.. | 10:26 |
| alan_g | camako: -c 1818 | 10:27 |
| camako | alan_g, yep I just saw that... Ok good.. | 10:27 |
| === chihchun is now known as chihchun_afk | ||
| alan_g | camako: unity-mir builds against lp:~alan-griffiths/mir/revisit-package-config | 10:32 |
| camako | alan_g, is that the devel-mir-next branch? | 10:33 |
| alan_g | ak | 10:33 |
| camako | great | 10:33 |
| alan_g | camako: and platform-api/devel-mir-next/ | 10:35 |
| camako | alan_g, great | 10:35 |
| anpok | hm i am to slow | 10:52 |
| alf_ | anpok: too slow for what? | 10:53 |
| dandrader | alf_, hey, if a mir client dies but the compositor sill has hold of one of its surfaces, will the whole ring buffer be kept alive or just that specific surface that the compositor has? | 11:04 |
| duflu | dandrader: The queue is removed immediately. Any buffer held by the compositor stays (refcounted) and is freed when the compositor is finished with it | 11:07 |
| alf_ | dandrader: duflu: hmm, on the contrary, I see that the queue stays alive until the compositor buffer is returned to it, but of course the mir surface itself is gone | 11:10 |
| alf_ | dandrader: how does this affect you? | 11:10 |
| dandrader | alf_, I would just like to know. either behavior works for me. I was just wondering about the memory consumption during such a situation | 11:15 |
| dandrader | ie, whole ring buffer in memory vs. just the single surface that comp has. | 11:16 |
| dandrader | 'cause I'm changing unity8 to take a screenshot with half-resolution and release the surface in such situation. so I was wondering how much of an improvement to expect in memory consumption | 11:18 |
| alf_ | dandrader: OK, so as I said, my understanding is that the queue stays alive. The idea was that the compositor only holds buffers for a small amount of time (just the time it needs to render with). If a surface is released while it is being rendered, the rendering will finish (and all buffers destroyed then). Do you need to keep surface buffers for more than a frame? | 11:23 |
| dandrader | alf_, currently if an app gets killed after being suspended (due to out of memory situations) it will remain in the spread and so unity8 (ie qtcomp) release the surface only once either the app "card" is manually closed by the user or it gets restarted | 11:24 |
| dandrader | alf_, not saying it's the right thing to do. is just what's happening atm | 11:25 |
| dandrader | working on fixing that currently | 11:25 |
| alf_ | dandrader: understood | 11:25 |
| alan_g | greyback: any opinion? https://code.launchpad.net/~alan-griffiths/mir/command-line-handling/+merge/229255/comments/556930 | 11:51 |
| greyback | looking | 11:52 |
| greyback | alan_g: not a major preference, I just voted to keep the argc/v pattern | 11:58 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| alan_g | greyback: thanks | 12:00 |
| === alan_g is now known as alan_g|lunch | ||
| groot_ | hello guys | 12:39 |
| groot_ | kdub: I'm still unable to boot :(. Maybe I'm looking at the wrong problem. So I thought of checking this from your perspective. | 12:40 |
| groot_ | I made a clean install and took logs. Can you check it? Maybe you'll discover something I didn't see. | 12:41 |
| === alan_g|lunch is now known as alan_g | ||
| groot_ | here are the logs. If you need any other logs, let me know. | 12:46 |
| groot_ | logcat: http://paste.ubuntu.com/7960829/ | 12:46 |
| groot_ | kernel: http://paste.ubuntu.com/7960833/ | 12:46 |
| groot_ | lightdm: http://paste.ubuntu.com/7960835/ | 12:46 |
| === sil2100_ is now known as sil2100 | ||
| kdub | groot_, a clean install won't help, something needs changing in hybris or the mir code | 12:48 |
| kdub | groot_, did you try those hybris tests? | 12:48 |
| kdub | although, i guess if the backup is working, the gles/egl stuff is probably okay | 12:48 |
| kdub | W/libc ( 2117): pthread_create sched_setscheduler call failed: Operation not permitted | 12:49 |
| kdub | a somewhat suspicious line | 12:49 |
| kdub | but really, remember we determined that we weren't getting the function hooks out of hwc? thats still the main problem | 12:49 |
| groot_ | kdub, sorry, net problem :|. You're telling something about libc warning? | 13:01 |
| kdub | groot_, its slightly suspicious, but I'd guess not the root cause | 13:02 |
| kdub | but really, remember we determined that we weren't getting the function hooks out of hwc? thats still likely the main problem | 13:02 |
| === pete-woods is now known as pete-woods|lunch | ||
| groot_ | kdub, but we checked those using if condition, and the function was returning 0 as result. So, isn't this clear the hwcomposer.so of suspicion? | 13:04 |
| kdub | well, we aren't getting the function hooks in mir still | 13:05 |
| alf_ | greyback: dandrader: with dash-as-app I noticed that I can't launch apps any more (but I can scroll). Is this a known issue? | 13:05 |
| dandrader | alf_, you should be able to launch apps | 13:06 |
| dandrader | alf_, you mean cannot launch from the dash but can scroll in the dash and switch scopes? | 13:06 |
| groot_ | kdub, I tried to use surfaceflinger by removing .display-mir and 30-no-surface-flinger file from ubuntu image. Then I got "no suitable eglconfig found" warning. Is this related also to mir. | 13:06 |
| dandrader | alf_, can you launch from the launcher? | 13:07 |
| alf_ | dandrader: right, but I can launch from the launcher | 13:07 |
| kdub | groot_, if you did that, then mir should not have been running, so that would be something funny with surfaceflinger? (i think that code path has bitrotted a bit, not sure of the sf output path anymore) | 13:07 |
| greyback | kdub: unity8 does not support running under SF any more | 13:08 |
| groot_ | kdub, yes, only sf was running then. I meant, does mir use eglconfig too? Then maybe mir also can't find this config. | 13:09 |
| kdub | groot_, mir does have to select a config, but we havent seen that problem | 13:10 |
| kdub | also, since the fallback works, it does find a usable config | 13:10 |
| groot_ | kdub, the fallback graphics just shows the ubuntu logo. Nothing else. It just loops between logo and welcome screen, I can't use anything. Only power button works. | 13:11 |
| alf_ | dandrader: greyback: let me retry with latest image to ensure it's not a problem with my setup | 13:11 |
| kdub | groot_, oh, so that sounds like a separate problem... you have the screen up and working | 13:12 |
| dandrader | alf_, yeah, it really should be working | 13:12 |
| kdub | groot_, ubuntu has 2 programs running... "USC" drives the framebuffer, and unity8 is a client of usc | 13:12 |
| kdub | groot_, and the problem seems to be that unity8 isn't coming up | 13:12 |
| kdub | groot_, try with the fresh install in backup mode, you might have broken abi between mir and unity8 in the mir experiments | 13:13 |
| groot_ | kdub, yes, I was so happy when I saw the welcome screen :). Hmm, I checked in /home/phablet, but there's no unity8.log there. | 13:13 |
| dandrader | alf_, are you compiling the branches yourself (for dash-as-app)? | 13:14 |
| kdub | groot_, /home/phablet/.cache/upstart/unity8.log ? | 13:14 |
| groot_ | kdub, yes. There's not even .cache folder. | 13:15 |
| groot_ | kdub, so try without the hwcomposer.so? I did that and it just loops like I said. But threre was unity8.log file. Also, in logcat there was error like "EGL_BAD_MATCH". Would you like to see ? | 13:17 |
| alf_ | dandrader: no, installing from landing-007 ppa | 13:17 |
| kdub | groot_, may as well | 13:18 |
| groot_ | kdub, here's the log. Logcat: http://paste.ubuntu.com/7961110/ | 13:24 |
| groot_ | kernel: http://paste.ubuntu.com/7961118/ | 13:24 |
| groot_ | unity8 only shows this http://paste.ubuntu.com/7961119/ | 13:24 |
| alf_ | dandrader: is there a recommended way to install from the ppa or is: add-apt-repository, apt-get update, apt-get dist-upgrade ok? | 13:28 |
| dandrader | alf_, sounds right | 13:31 |
| dandrader | alf_, having problems? | 13:31 |
| alf_ | dandrader: no, I just noticed I will install some other updates too (language packs) with dist-upgrade | 13:33 |
| dandrader | alf_, it shouldn't be a problem now that qtcomp has landed. there won't be conflicting packages or anything | 13:33 |
| dandrader | alf_, so those recommendations from the old qtcomp silo no longer apply | 13:34 |
| kdub | groot_, so the unity8 isn't connecting to the system compositor, why... I don't know | 13:36 |
| kdub | but we know the system compositor is up and the spinner app has connected to it | 13:36 |
| groot_ | kdub, hmm it even shows introduction page sometimes (like swipe to right, left). But then again goes back to logo :( | 13:41 |
| alf_ | dandrader: ok, thanks... so everything seems to be working with r172 + ppa, so probably false alarm | 13:44 |
| groot_ | kdub, it seems at first boot there's only welcome screen. If I boot second time, it goes to intro screen and more logs are available in unity8.log. | 13:45 |
| dandrader | alf_, phew... | 13:45 |
| groot_ | Here it is http://paste.ubuntu.com/7961246/ | 13:45 |
| alf_ | dandrader: perhaps it was a temporarily glitch in r171, who knows... I'll keep my eyes open for it 8) | 13:46 |
| kdub | groot_, not sure what could be the root cause, might make sense to file a bug | 13:47 |
| dandrader | alf_, fwiw there's a know bug (not sure if reported) that when you go back to the dash it's still showing the previous frame, so when you tap on it immediately after getting back to it you might hit an icon different from what you're seeing | 13:48 |
| dandrader | then if you scroll it a bit to force redraws you get to see the current frames | 13:48 |
| dandrader | qtmir (qtcomp) flaw | 13:49 |
| groot_ | kdub, but this only happens if I remove hwcomposer. Should I file a bug about this or about the issue when hwcomposer is present ? | 13:51 |
| greyback | dandrader: we need to figure that out. It could be USC bug more that qtmir | 13:52 |
| kdub | groot_, may as well for both. i can comment on what I know on the hwcomposer one | 13:52 |
| === chihchun_afk is now known as chihchun | ||
| kdub | the other one I'm not so sure what your device might be doing differently | 13:52 |
| groot_ | kdub, all right. BTW, our device use hwcomposer version 0.3 which is very old. Google removed support for it long ago, but we added it back in source. Will mir have a problem with this? | 13:55 |
| kdub | oh yeah, a big problem :) mir supports the backup mode and hwc 1.0 and newer | 13:55 |
| groot_ | kdub, damn it. I knew I should've told you about this before. So what happens now? We can't run UT?? :( | 13:57 |
| kdub | well, you can run using the backup mode | 13:57 |
| kdub | the problem up in unity8 seems to be something different | 13:58 |
| groot_ | kdub, so there's no way to run UT with hwcomposer? I've to look for fix in backup mode ? | 14:01 |
| kdub | groot_, by removing the hwcomposer.so, mir is forced to use the backup mode | 14:01 |
| groot_ | kdub, looks like I've no other option. I'll try to boot with backup mode. Do you guys have any plans to add support for older version of hwcomposer in future ? | 14:05 |
| kdub | groot_, no plans, although the version is nicely abstracted from the other versions that are supported | 14:06 |
| groot_ | kdub, so adding support for any version wouldn't be difficult? I'll try with backup mode for now, if it boots then probably someone from our device section can help with integrating 0.3 support. | 14:10 |
| kdub | groot_, lets just say "its not impossible" | 14:11 |
| alf_ | Saviq: FYI, unity-dash still consuming a constant 5%-8% CPU when doing nothing (even when screen is off), probably something scope related, https://bugs.launchpad.net/unity8/+bug/1339883 | 14:12 |
| ubot5 | Launchpad bug 1339883 in Unity 8 "unity8 on the phone has unreasonable CPU usage when system is idle with screen off" [High,New] | 14:12 |
| Saviq | alf_, will get suspended with dash-as-app soon ;) | 14:12 |
| Saviq | alf_, you can try with silo 7 :) | 14:12 |
| groot_ | kdub, ok :). I'll probably be disturbing you with backup mode from now :P | 14:13 |
| anpok | groot_: what kind of device is that? | 14:13 |
| groot_ | anpok, Sony Xperia U | 14:13 |
| groot_ | first series from sony | 14:13 |
| alf_ | Saviq: I am using dash-as-app, dash still consuming CPU long after screen has been turned off... | 14:14 |
| alf_ | Saviq: but we should make it not consume CPU regardless of suspending :) | 14:15 |
| Saviq | alf_, sure ;) | 14:19 |
| Saviq | alf_, do we have a bug for this? | 14:19 |
| alf_ | Saviq: https://bugs.launchpad.net/unity8/+bug/1339883 is the bug I filed before dash-as-app, noted in the comment that it still applies for dash as app (of course the htop traces will not be exactly the same) | 14:20 |
| ubot5 | Launchpad bug 1339883 in Unity 8 "unity8 on the phone has unreasonable CPU usage when system is idle with screen off" [High,New] | 14:21 |
| Saviq | alf_, thanks | 14:22 |
| alf_ | Saviq: np, hopefully the battery will last a bit longer when we fix this :) | 14:23 |
| === pete-woods|lunch is now known as pete-woods | ||
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| === alan_g is now known as alan_g|EOD | ||
| qengho | Hi all. I'm on 14.04 still, and trying mir in X for testing some client. It looks like keyboard events are delayed because of buffering or maybe some key-combo scheme. I press 'x' in a terminal, and it doesn't go to the client until I press the next key or some amount of time passes, about 0.75 second. Typing 'asdf' sends 'asd' then... 'f'. | 18:26 |
| qengho | Though, right now, I had to change the quoted 'asdf'. I hit arrow keys to move the cursor. I heard the GUI bell signal immediately, but the cursor still didn't move until the second elapsed. | 18:27 |
| tvoss | qengho, hey there :) | 18:28 |
| tvoss | qengho, trying to clarify on your setup: you are running X on Mir, or Mir on X? :) | 18:28 |
| qengho | Hah. Er, mir on X, I think. ps => /usr/bin/X -core :1 -seat seat0 -auth /var/run/lightdm/root/:1 -mir x-1 -mirSocket /tmp/mir_socket -nolisten tcp | 18:29 |
| tvoss | qengho, ah, that's X running against, or as we call it: XMir. So I remember the event delay issue with XMir, but I remember that we fixed it. May I ask you for the specific version of Mir that you are running? | 18:30 |
| qengho | mir tools and libraries 0.1.8+14.04.20140411-0ubuntu1 | 18:31 |
| qengho | xserver-xorg-xmir 2:1.15.1-0ubuntu2 | 18:31 |
| qengho | I have not flipped to Utopic on this machine. | 18:32 |
| tvoss | qengho, ah, thanks for the information. That might be the issue then. kgunn, could you take a look here ^? | 18:34 |
| tvoss | qengho, I'm pretty sure the bug is fixed, but not necessarily available in trusty, yet | 18:34 |
| tvoss | qengho, searching for the bug number | 18:40 |
| tvoss | qengho, https://bugs.launchpad.net/mir/+bug/1199450 | 18:43 |
| ubot5 | Launchpad bug 1199450 in mir (Ubuntu) "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Critical,Fix released] | 18:43 |
| kgunn | yeah, and i've even seen a delay show up in straight x every now and then | 18:45 |
| qengho | tvoss: it says Merged into lp:ubuntu/saucy/mir, so I would expect T to be fixed too, but it is not. | 18:52 |
| tvoss | qengho, you are running on Intel? | 18:54 |
| qengho | The immediate Bell suggests it is that a final frame not rendered. I realize now that the delay is indeed fixed at the next cursor blink. | 18:55 |
| qengho | tvoss: Yes. Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) | 18:57 |
| * qengho avoids the problem by opening a terminal and "while sleep 0.05; do date; done", to force buffer churn. | 19:04 | |
| qengho | Is environment variable "MIR_SERVER_NAME" the preferred way to have my client test whether to use its mir output? | 19:08 |
| qengho | Is there an x2mir yet? This is killing my multi-machine one-keyboard setup. ;( | 19:11 |
| kdub | if x2mir is the inverse of xmir, there are some emulators, but I don't know of a 'native x2mir' | 19:22 |
| Saviq | camako, something went wrong with your qtmir devel-mir-next branch, the changelog entry moved below the currently released one | 21:22 |
| Saviq | camako, FWIW there's no need for you to put the changelog entry there manually - just write stuff in the MP commit message and the train will convert that into a proper changelog entry | 21:22 |
| Saviq | kgunn, shall we drop unity-mir from silo 7? we should drop it from distro anyway? | 21:28 |
| racarr | Going to land this unless anyone objects soon https://code.launchpad.net/~mir-team/mir/touchspot-visualizer/+merge/228903 | 22:02 |
| racarr | so hopefully can land the renderables tomorrow or some such | 22:02 |
| racarr | I think daniel had abstained in the previous submission and kdub had approved | 22:02 |
| kgunn | Saviq: let's touch base on that tomorrow | 23:31 |
| racarr | oO | 23:35 |
| racarr | the sudo password on my emulator image | 23:36 |
| racarr | is not phablet... | 23:36 |
| racarr | and adb shell to root + passwd phablet | 23:36 |
| racarr | gives a bad authentication token | 23:36 |
| racarr | I seem to be unable to get root on my own emulator image | 23:36 |
| racarr | anyone know anything about the password | 23:36 |
| racarr | changing? | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!