[00:01] kdub: are you tip ? or at the rev of the 0.1.6 tag ? [00:02] the tag [00:04] USC should have which branches? i see a few likely candidates [00:15] here's what I see http://pastebin.ubuntu.com/7041505/ [00:19] https://code.launchpad.net/~robertcarr/unity-mir/update-to-not-use-configure-output/+merge/209565 [00:19] more build fixing [00:19] https://code.launchpad.net/~robertcarr/unity-mir/usleep-include/+merge/209564 [00:20] not sure why this only appears on my system... [00:22] which branch fixes the [00:22] frontend detail link errors [00:22] or is this new [00:24] racarr_, that one is new to me [00:25] racarr_, with usleep, AlbertA has https://code.launchpad.net/~albaguirre/unity-mir/remove-usleep-call [00:48] kdub: Ah. thanks [00:51] racarr_: Have you made any progress on multihead inprocess eglL [00:51] L [00:51] ? [01:04] RAOF: Nooo [01:04] you need a nested qualifier too :p [01:04] but still no [01:04] racarr_: True. [01:04] Ok. I'll do more diving today then. [01:10] RAOF: Thanks === duflu_ is now known as duflu [02:07] racarr_: That was a purdy video of Chromium you made... and with the fix landed this week it no longer needs to be maximized ;)\ [02:19] duflu: Credit to olli :D [02:19] I made a really ugly video [02:19] referred to as the blair witch project of web browser demos actually [02:20] it kind of caught on in the film festival scene but [02:20] :p [02:20] Hah. Yeah it's probably a job requirement that olli can do videos with flair [05:03] Woot! That's why everything's getting wedged! [05:05] racarr_: So you know how src/server/frontend/surface.cpp::swap_buffers_blocking assumes that the callback to swap_buffers() will always get called? There's absolutely no guarantee of that. [05:06] racarr_: Although it might be a little bit to late for you, I guess ;) [05:20] RAOF: wouldn't the only time that happens is if the gpu crashes ? [05:21] or locks up [05:21] Apparently not. [05:22] Specifically: with the non-blocking client_acquire thingy, if there isn't a free buffer then client_acquire returns without calling the callback. [05:22] Now, compositor_release *should* call the callback once its been called, but does not appear to be doing so. [05:24] also...blocking on swapbuffer swaps doesn't sound good in general (e.g. just wasting time for a buffer to be free...not good use of time) [05:25] The other option is to have a buffer-available signal? [05:26] If you set swap interval 0 then we don't block(ish), and always return a buffer. [05:27] Blocking SwapBuffers until you've got a back buffer seems like a reasonable (and reasonably standard) thing to do? [05:49] kgunn: Blocking in general is bad. But for swapbuffers, that's what throttles client rendering to the same rate as the compositor consumes frames [05:50] So in places, very important to block [05:52] duflu: are you saying you actually block clients renders (_even_ when they have a free buffer) ...if the compositor is "busy" and doesn't have a free buffer (e.g. double buffered system its easier to do) [05:53] that would seem to preclude clients from making a decision to just render if they want to... [05:53] seems cheeky [05:55] kgunn: Clients never have such a thing as a "free" buffer (that's bug 1253868). But they do always have a buffer to render to when not blocking inside SwapBuffers. SwapBuffers for the client will only block for one frame (16ms). Unless the screen is asleep, in which case we block everyone to avoid wasting power. [05:55] bug 1253868 in Mir "[enhancement] Mir protocol design prevents clients from ever being more than double-buffered" [High,Triaged] https://launchpad.net/bugs/1253868 [05:56] No, that's not right. Clients' SwapBuffers will return ASAP, on a maximum period of the maximum monitor refresh rate [05:57] Unless they have explicitly disabled blocking with eglSwapInterval(0), but that's a bad idea usually [05:58] right...ok...video mode panels would likely be 16ms...but command modes don't have a vsynch...its realy an in determinant frequency [05:58] Yay! Hypothesis! [06:00] kgunn: Yeah, indeterminant. But holistically your commands need to complete within that frame time, one way or another, to keep up 60Hz (or whatever) [06:01] usually faster if possible... [06:01] Well the good news is that since Mir 0.1.5 we have maximized the rendering time available [06:01] On desktop anyway. I'm not as familiar with Android [06:02] Nested creates 1 surface per output, even if the underlying system is cloned (which is pointless, but not super wrong). These surfaces get placed one above the other, meaning that one is completely obscured, meaning that its swaps never complete, and then everything falls in a heap. [06:03] But! Lunch time. [06:03] * duflu assumes other people understand whatever bug that is [06:04] duflu: https://bugs.launchpad.net/mir/+bug/1287282 [06:04] Ubuntu bug 1287282 in Mir "Nested server may hang with multimonitor and internal clients (Mesa)." [Undecided,New] [06:04] That sounds unpleasant [06:05] Yeah. You should really replace the “may” with ‘will definitely’. And the “mesa” with “but we don't have dual-head support on android, so can't expose this bug there” :) [06:06] RAOF: Please do [06:07] RAOF: On another note... I almost forgot. We can now implement xrandr rotation against XMir [06:07] For fun. Not because anyone *needs* it [06:07] Woot! [06:07] Anyway, really lunch time. [06:11] Hmm, apparently I had been running Mir on multiple monitors for weeks without knowing (half are off). And didn't notice any slowdown [06:11] Is it a good idea to automatically use monitors that are off from the beginning? [06:19] duflu: We can't tell that they're off. [06:19] Oh. That would do it [06:20] Except with DisplayPort and *some* HDMI. [06:47] RAOF: Oh...good catch :D I forgot [06:47] we had implemented the obscuring logic... [06:47] I should have figured out thats what it was when [06:47] moving the top nested window [06:47] unblocked them lol [06:47] I also should have remembered to mention that to you [06:47] I should have tried it sooner :) [06:47] :D [06:47] ITERATEEEEE [06:48] So, shall I fix that FIXME in nested_output.cpp? :) [06:48] Whee, bisection without the ability to build old revisions [06:49] Oh, why not? [06:49] RAOF: The glm package update from trusty, remember? [06:49] Oh, right. Buh! [06:51] Fortunately the offending use case is pretty uncommon right now [06:51] RAOF: Would be excellent or if you are busy I can do it in the morning [06:52] I am now, not busy! (I am sure that statement will be corrected when kgunn wakes up :p) [06:52] racarr_: i have so much planned for you [06:52] mmwwwhahhahahah [06:52] go to sleep or you arent going to grow up to be tall. [06:53] too late for that [06:53] :p [06:53] probably causses gray hair too [06:53] i so heart this landing process [06:54] http://memegenerator.net/instance/46502261 [06:54] What happened? It seems like everything is in a jumble [06:54] and im missing the root cause of the chaos [06:54] duflu: Lol I see So you do window management [06:54] is the new team meme [06:56] This is really annoying. SwitchingBundle reports multi-monitor frame sync working perfectly. But my eyes disagree [06:57] Maybe the parallelized page flipped has somehow found a way to go a double speed? [07:00] Bah! Any ideas what the hell is going wrong on the CI hardware? https://code.launchpad.net/~raof/mir/udevify-eventhub/+merge/206659 passes the (memcheck) tests on my desktop *and* my Nexus 4, but fails without any useful info on the build boxes. [07:01] ok sorry australia friends but the more you say the less sleepy I feel :p and thats the wrong direction [07:01] goood night! [07:02] racarr_: Night [07:02] RAOF: I was wondering... do we need to give CI new instructions as to how to successfully run the tests on armhf? [07:02] Cos I assume the old method will fail now (since that branch) [07:03] duflu: No, the old method works fine. [07:04] The failures look udev/syscall specific. So possibly actually related to the code changes [07:04] What failures are you looking at? [07:05] RAOF: A couple of them https://code.launchpad.net/~raof/mir/udevify-eventhub/+merge/206659 [07:05] Which log result? [07:06] This is a fun one: [07:06] [----------] 2 tests from UdevWrapperDeathTest [07:06] [ RUN ] UdevWrapperDeathTest.DereferencingEndReturnsInvalidObject [07:06] ==10840== [07:06] ==10840== Process terminating with default action of signal 11 (SIGSEGV) [07:06] ==10840== Bad permissions for mapped region at address 0x1884DB8 [07:06] ==10840== at 0x1884DB8: ??? [07:06] ==10840== [07:07] That's entirely expected. [07:07] The test is checking that SIGSEGV is raised, so valgrind picking that up is pretty normal :) [07:07] Well it can't pass with it either, can it? [07:07] Oh, those are passing!? [07:08] I was trying to write an acceptance test today [07:08] that, a client will block on swap buffers. [07:08] duflu: Yup, those are passing. [07:08] and swap buffers will not turn the display back on [07:08] RAOF: A memcheck failure doesn't always mean the test failed. It can just mean non-zero errors reported by valgrind (which there are) [07:08] if its another client thats requested turning the display off [07:09] but its hard to write these tests, i.e. check that like [07:09] swap buffers blocks. when do you time out? [07:09] A second, maybe 2. [07:10] But, if 1, we add some symbolic kind of names to threads, i.e. a thread registers itself I am a compositor thread, etc. [07:10] RAOF: Sanity check with some trivial proposals and see if they can land? [07:10] and then use a custom mutex implementaion with a simple...graph traversal kind of thing [07:10] you can write tests like... [07:11] EXPECT_THAT(RPCThreadFor(session, BlocksOn(CompositorThread)) [07:11] and then just quit the test [07:11] [07:11] racarr_: If this is you sleeping, may I suggest finding new ways to wind-down evenings? :) [07:11] lol [07:12] i just wanted to put it somewhere because I knew I would forget [07:14] racarr_: And archived for you: http://irclogs.ubuntu.com/2014/03/06/%23ubuntu-mir.html [09:18] racarr_: Enjoy https://code.launchpad.net/~raof/mir/nested-one-surface-per-crtc/+merge/209615 [09:23] alan_g: Any chance you could look into https://bugs.launchpad.net/bugs/1288570 some time? [09:23] Ubuntu bug 1288570 in Mir "[regression] Multi-monitor frame sync no longer works (not synchronized)" [Medium,Triaged] [09:24] duflu: sure - although you mentioned something about just using a different approach in comments? [09:24] alan_g: That was really only relevant when I thought I caused it. I'm not sure how much that rewrite idea would help now [09:24] ok [09:31] alan_g: In fact, it's not just rendering faster, but looks like it's alternating forwards/backwards in time so juddering [09:31] Not sure [09:36] http://paste.ubuntu.com/7043201/ I will make an MP out of that - but I still get a fancy off by one error for a rectangle (2x6) placed at (10,10) and rotated by 90 degrees. but only in x direction [09:37] i expected the rectangle to go from 8 to 13, but it starts at 9.. [09:38] duflu: it is a big shame we don't have an acceptance test covering it. [09:38] * alan_g wishes for a software backend once again [09:38] alan_g: Yeah I went back and looked at the tests I wrote for that. They seemed OK [09:41] Of course, you can't write tests for *everything* you haven't thought of yet [09:42] However we broke it, I didn't foresee as possible [09:43] duflu: don't let it spoil your evening [09:44] alan_g: It won't. I was happy to just complete the bisection [12:20] alf_: so greyback is ahead of me and tested silo a bit...any reason mir on android might be looking for mesa & trying to open vts ? (...thinking of the recent backend loading changes) [12:21] kgunn: Is this during the build in the silo, or when using the built packages on a phone? Do we have any logs? [12:22] alf_: using build packages from the silo. I just flashed my tablet & installed the silo's ppa and updated [12:23] ah not again, think latest adbd broken on manta [12:26] Setting up libmirclientplatform-mesa:armhf (0.1.6+14.04.20140306-0ubuntu1) ... [12:26] update-alternatives: using /usr/lib/arm-linux-gnueabihf/mir/clientplatform/mesa/ld.so.conf to provide /etc/ld.so.conf.d/arm-linux-gnueabihf_mirclientplatform.conf (arm-linux-gnueabihf_mirclientplatform_conf) in auto mode [12:26] greyback, working on that (well, trying to, my manta misbehaves) [12:27] ogra: Great, thanks. It started working again after reboot. But I was struggling with it this morning, had to reflash [12:27] oh ? i wonder why it started working ... theoretically it shouldnt :P [12:27] lol [12:28] i'm trying on a N4 [12:28] ogra: any logs useful for you, while it is magically working? [12:28] alf_: what should i look for as this thing attempts to boot...log ? or output ? [12:29] no, i'm just surprised it started to work [12:31] greyback: kgunn: hmm, we shouldn't be installing the mesa packages on phone/tablet. Probably something in our package upgrade dependencies/replaces. In any case, just remove the -mesa packages (and install the -android packages if not already there) and everything should work. [12:32] greyback: kgunn: I don't think this is a problem with images, since the proper packages should be seeded for them. [12:32] alf_: confirmed that works [12:32] i just got the vt err on unity8 manual attempt [12:33] kgunn: sudo apt-get install libmirclientplatform-android libmirserverplatform-android && sudo apt-get purge libmirclientplatform-mesa:armhf libmirplatformgraphics-mesa:armhf [12:33] that should help [12:34] greyback: kgunn: I think the problem is that both libmirclientplatform-mesa libmirclientplatform-android replace libmirclientplatform, but I am not sure if there is a way around that [12:36] greyback: kgunn: anyway, this should only be a problem when upgrading in a system that already has libmirclientplatform. Future images won't have it, so problem solved :) [12:36] lol [12:37] nice try [12:37] alf_: how is mesa/android decided by Mir? At runtime? [12:38] greyback: dpkg-alternatives set a system-wide default, but you can also override the exact library to use with environment variables [12:38] greyback: magic [12:39] alf_: I just don't want someone to accidentally install -android packages on their desktop and break it. [12:40] ogra: sanity restored: rebooted manta again, no adb [12:40] heh [12:41] greyback, feel free to roll back manually http://launchpadlibrarian.net/168424245/android-tools_4.2.2%2Bgit20130218-3ubuntu19_4.2.2%2Bgit20130218-3ubuntu20.diff.gz [12:41] greyback: nor do I, so I made sure that can't happen :) The -mesa and -android packages have the same alternatives priority, so any existing packages (e.g. mesa) are not overriden by newly installed ones. You need to change the alterntives by hand [12:41] (but you will get the annoying disconnects) [12:44] ogra: you're fixing the disconnects, wonderful! You'll single handedly lower my blood pressure and extend my life span with that fix [12:44] one nit for anyone reading scrollback its "sudo apt-get install libmirclientplatform-android libmirplatformgraphics-android && sudo apt-get purge libmirclientplatform-mesa:armhf libmirplatformgraphics-mesa:armhf" [12:44] well it doesnt seemt o work on manta ... [12:44] trying to find a proper fix ... but since i use my manta only once a month the battery went completely dead [12:45] ogra: well if you need tester, let me know [12:45] will do [12:46] kgunn: with that change, things seem to work. Any idea how the crash is reproduced? [12:46] greyback: mterry & kdub were saying it was on startup [12:47] what's strange is kdub could launch unity8 manually... [12:47] and it would work [12:47] greyback: one note...they were building tip mir dev...and not sure about the other components.... [12:48] meaning...its not precisely whats in silo3 [12:48] kgunn: which means I don't care...yet [12:48] let's see if silo3 has that issue [12:48] greyback: right if silo 3 works... [12:49] alf_: greyback ...however, i just removed the mir mesa packages & installed the android ones....and rebooted, stuck at google splash screen [12:50] manual attempt resulted in: Failed to load platform plugin "ubuntumirserver" [12:50] kgunn: is qtubuntu-android:armhf installed? [12:51] just trying that now [12:51] ooo....broken packages [12:52] kgunn: broken, like broken? (or broken as you didn't upgrade everything needed?) [12:53] didrocks: just to make sure...i added the ppa(slio3) did a apt-get update, followed by a dist-upgrade [12:53] yeah, that should be right [12:54] https://pastebin.canonical.com/106009/ [12:54] did you change the packaging more than usual? [12:54] hum [12:54] nope...only thing i did was the removal of "mesa" and install of "android" discussed for the 2 pkgs above [12:55] kgunn: ok, I can extract the packaging diff as a first look (cheating and sshing on citrain machine) [12:55] just to see if there is any crazyness in packaging changes first ;) [12:55] didrocks: if its important to know...i started with a channel devel-proposed image like 30 min ago [12:55] yeah, sounds perfect [12:55] didrocks: hey thanks... [12:55] let me reflash cleanly my phone at the same time [12:55] didrocks: yeah...weird greyback says its ok with manta (i'm on mako)..but greyback did you have an "older image" ? [12:56] yeah, the device shouldn't come into play for deps issues [12:56] apart from a "non cleaned image" [12:56] kgunn: ooh wow I did, from Feb20: http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/current/ [12:56] ok guys...i gotta step away for monring duties...bbian [12:57] bbiab [12:57] greyback: you lazy bastard :) [12:57] jk...lol [12:57] I've excuses, but anyway... [12:58] - android-headers (>=4.2.2) [armhf], [12:58] + android-headers (>=4.2.2) [i386 amd64 armhf], [12:58] that's a little bit weird, but not the issue per say [12:59] hum [12:59] + libmirplatformgraphics-mesa (= ${binary:Version}) | [12:59] + libmirplatformgraphics-android (= ${binary:Version}), [12:59] greyback: do you know about that? ^ [13:00] kgunn: description of the binary packages aren't good btw (shouldn't be NEWed that way) [13:01] alf_: might know about that didrocks [13:01] didrocks: I do now [13:02] but alf_ is the author [13:03] didrocks: ? === alan_g is now known as alan_g|lunch [13:06] alf_: the short description needs to be different between packages [13:06] alf_: both reference the same [13:06] (also, not really sure the per-arch will please everyone ;)) [13:06] so, from what I understand, on dist-upgrade, we need to install the -android mir and client packages, right? [13:10] didrocks: either the -mesa or -android packages, depending on which platform we are on (and x86 no longer means mesa, nor armhf means android necessarily) [13:10] alf_: right, the thing is that we don't build even -mesa on all platform [13:10] didrocks: e.g. on the x86 phone emulator we would need android [13:11] didrocks: which platforms are these? [13:12] alf_: powerpc and ppcel64 [13:13] didrocks: we aren't building any mir package on these platforms AFAICT [13:13] alf_: yeah, I mean, it's something that will need to be looked at some point (especially as being in main intend more or less that) [13:13] * didrocks wonders why he can't download from the ppa on the phone :/ [13:13] oh I know [13:14] alf_: however, we still need to have different short descriptions between binary packages (which was the start of the discussion) [13:15] didrocks: ok, I will take care of that [13:15] I'll be happy to not block on this for NEWing if there are new packages, if there is a MP for that :) [13:15] thanks [13:15] ok, so, let me try to apt-get install + dist-upgrade [13:16] alf_: so, with that change, I guess we need to seed libmir*android on Touch? [13:18] didrocks: Right. If you just upgrade in an older image you will get the mesa packages, which is wrong (greyback had that problem), but I am not aware of a way around this transition glitch. [13:18] yep [13:18] that should be noted in the silo line (kgunn) [13:19] ok, so libmirplatformgraphics-android : Depends: libmirplatform (= 0.1.6+14.04.20140306-0ubuntu1) but 0.1.5+14.04.20140212-0ubuntu1 is to be installed [13:19] interesting, let's see why apt-get doesn't want to upgrade it [13:19] I guess we just need them to be listed explicitely as libmirserver15 will be removed [13:20] The following packages will be REMOVED: [13:20] libmirserver15 [13:21] The following NEW packages will be installed: [13:21] libmirclientplatform-android libmirplatformgraphics-android libmirserver16 [13:21] The following packages will be upgraded: [13:21] libmirclient7 libmirplatform libmirprotobuf0 [13:21] libubuntu-application-api-mirserver1 libunity-mir1 mir-test-tools [13:21] unity-system-compositor [13:21] alf_: I'm missing no package here, right? ^ [13:21] didrocks: looks good [13:21] * didrocks reboot the phone [13:24] kgunn: ok, all good here. As the transition is more complex than usual (new packages that you need to set explictely) and some packages need to be removed, you need to help apt. "sudo apt-get install libmirplatformgraphics-android libmirclientplatform-android libmirplatform" should do it [13:25] kgunn: can you please add something along the line "need to seed libmirplatformgraphics-android and libmirclientplatform-android" in the comment of your landing request please? (and set that to red) [13:28] kgunn: didrocks: https://code.launchpad.net/~afrantzis/mir/packaging-fixes/+merge/209676 , do you want an MP for urgent inclusion into lp:mir too ? [13:29] kgunn: alf_: if you don't have any other reason to rebuild Mir for other fixes, don't worry about it as long as it's merged in next release [13:30] alf_: but you will get bonus point if you can fix tabs vs spaces :p [13:30] which are in debian/control, rules, the new postinst scripts as well IIRC [13:32] didrocks: I can only see spaces (except the make rules that need tab indentation) [13:33] alf_: let me grab you some of the stuff I'm seeing (space and misalignement) [13:34] alf_: oh, maybe you did that on purpose? [13:35] + libmirplatformgraphics-mesa (= ${binary:Version}) | [13:35] + libmirplatformgraphics-android (= ${binary:Version}), [13:35] (same on client) [13:35] and yeah, in rules: [13:35] + -DMIR_RUN_ACCEPTANCE_TESTS=OFF -DMIR_RUN_INTEGRATION_TESTS=OFF \ [13:35] + -DMIR_PLATFORM=android\;mesa [13:38] didrocks: @control, yeah that's on purpose, @rules, we don't have that text in debian/rules, at least not in mir/devel [13:39] alf_: it's in the one which was generated on trunk, starting to get anxious if you have such diff there [13:39] alf_: do you mind checking once that's landed? maybe you do have trunk/devel diff with changes only in trunk [13:42] didrocks: it's going to be taken care of by https://code.launchpad.net/~mir-team/mir/trunk-0.1.6/+merge/208717 , I think that kgunn is testing this branch in the silo before merging into trunk, so we can fix the big issues before landing [13:43] alf_: yeah, the diff I showed you is the result of that branch [13:45] didrocks: ok, thanks for pointing it out === dandrader is now known as dandrader|afk === alan_g|lunch is now known as alan_g [14:06] alf_: didrocks ...the rules file needs to suppress the android integ tests b/c the silos != our "ci" builders....meaning, anything requiring access to arm gl drivers fails on silo but passes on dev branch "ci" [14:07] i say "ci" in quotes since i was corrected that its all CI...but you know what i mean :) [14:07] alf_: and thanks... [14:13] alf_: i'll just make those updates manually [14:13] to the branch for lp:~mir-team/mir/trunk-0.1.6 [14:17] kgunn: ok, in that case perhaps also fix the indentation noted by didrocks in debian/rules (-DMIR_RUN_ACCEPTANCE_TESTS=OFF -DMIR_RUN_INTEGRATION_TESTS=OFF \) [14:19] kgunn: actually the next line (-DMIR_PLATFORM=android\;mesa) [14:20] alf_: what's wrong with it ? [14:20] didrocks: you also need to change the seeds with latest mir [14:20] guess you're just landing that together with the mir silo [14:20] kgunn: nothing functionally, just one space more indented than it should be [14:21] rsalveti: yeah, I pinged kgunn to add a note for that [14:21] cool [14:21] rsalveti: not sure we can land that together, the packages are NEW to the archive [14:22] oh, that's true [14:22] rsalveti: something I've speced for the airline and we'll need to change our tooling, but for now, let's do it in a 2 steps process [14:22] (and not kick an image in between :p) [14:23] didrocks: i should rebuild ? or ?.....i just updated the branch for mir0.1.6 that would be merged post landing... [14:23] didrocks: sure :-) [14:23] kgunn: what branches? only the typo ones? [14:23] kgunn: actually it's a matter of tabs vs spaces (but not a big deal, we can fix it later) === dandrader|afk is now known as dandrader [14:24] yeah, don't rebuild just for that [14:24] get that in the next batch [14:24] didrocks: yeah, the description: in control & spacing for rules [14:24] ok [14:24] off to test then.... [14:24] kgunn: don't bother to put into the current one :) [14:24] as long as it's not lost, it's fine :) [14:30] didrocks: curious...what was the deal with broken packages ? was that me ? [14:30] its working now [14:30] kgunn: did you see my apt-get install line? [14:30] ...well qtubuntu-android installed... [14:31] didrocks: you had no trouble ? [14:31] 14:24:16 didrocks | kgunn: ok, all good here. As the transition is more complex than usual (new packages that you need to set explictely) and some packages need to be removed, you need to help [14:31] | apt. "sudo apt-get install libmirplatformgraphics-android libmirclientplatform-android libmirplatform" should do it [14:31] kgunn: ^ === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g === dandrader is now known as dandrader|lunch [16:27] kdub: mterry...so if either of you try silo 3 just be aware don't sudo dist-upgrade the ppa...you have to specifically sudo apt-get install libmirplatformgraphics-android libmirclientplatform-android libmirplatform [16:27] kgunn, yeah I meant to ask [16:27] in order to avoid loading platform obj's for mesa.... [16:27] kgunn, I can't have the mesa variants I suppose? [16:28] kgunn, that's what was causing my crashes we're guessing? [16:28] otherwise mir will think its mesa and try to open vt's and stuff [16:28] mterry: it would depend on how you loaded it [16:28] kgunn, normal everyday booting into unity8 [16:28] ...if you by chance installed mesa platform packages for mir then yes [16:29] kgunn, I bet I did dpkg -i ../libmir*.deb [16:29] without realizing we got new mesa things [16:29] yeah...that'd do it [16:29] kgunn, stop making it a pain to dpkg a new mir! [16:29] :) [16:34] * alan_g goes looking for yet another monitor to add to his laptop [16:38] i must have missed some email somewhere, but when we say silo... where is that? [16:40] where the train parks :) [16:41] kdub: https://launchpad.net/~ci-train-ppa-service/+archive/landing-003/ is the one I was referring to [16:42] thanks greyback [16:43] greyback, fyi, adbd should behave a lot better with my recent upload ... (i'm not completely done yet on the mtp side though) [16:43] ogra: cool, thanks === dandrader|lunch is now known as dandrader === alan_g is now known as alan_g|EOW [19:13] kgunn, so theoretically removing those two -mesa packages would fix the unity8 problems? didn't seem to work for me [19:14] mterry: well...did you purge ? [19:14] btw...in the end, i had to reflash & reinstall....the simple uninstall/install only android didn't work for me [19:15] only greyback claimed success [19:15] andhe was on an ancient image [19:15] ancient == 2 week old [19:16] kgunn, ok, will do the cycle [19:16] mterry: sorry...sucks i know [19:17] kgunn, if this is indeed necessary (instead of some weird other problem), seems like bad packaging...? [19:18] alf_ changed packaging names....and according to didrocks if you dist-upgrade you get the mesa, but if you do the specific install like so [19:18] sudo apt-get install libmirplatformgraphics-android libmirclientplatform-android libmirplatform [19:18] then it all just works [19:19] and according to didrocks...that'll be fixed when it lands for real [20:43] kgunn: yes, that should indeed work [20:43] kgunn: are you having issues with it? [20:43] I can give it a try [20:44] i just reflashed and it worked [20:44] awesome [20:50] kgunn: any other issue blocking that silo? [20:50] just to know if we'll be able to land that today still [20:50] rsalveti: i found a gnarly manual test that revealed a problem with OSK....note AP test for OSK passed 100% [20:51] oh, ok [21:40] mterry: Want to test a branch for your screen turning on issue? [21:42] racarr_, sure... Can I apply it to 0.1.5 easily enough? [21:42] mterry: Yes unity-mir only [21:43] mterry: lp:~robertcarr/unity-mir/greeter-configuration-for-mterry [21:43] then in your unity8 branch, where main.cpp calls [21:43] runQMirServerWithClient [21:43] call runQMirServerWithGreeterClient [21:43] if you are um... [21:43] the greeter [21:46] racarr_, huh, k [21:49] racarr_, your branch makes me feel so special :) [21:53] mterry: Oh no, thats an abbreviation for Mir Thread Enhancing RAII Refactoring (from) Yesterday. [21:54] racarr_, lol' [21:55] alf_: how to run glmark2 with mir? also, can we update the package available in ubuntu to also bring support for mir by default? [21:55] it seems the package is really old [21:55] alf_: I can sponsor the upload if you need any help [22:22] racarr_, I must have screwed something up, unity8 is crashing [22:22]