[00:01] <kgunn> kdub: are you tip ? or at the rev of the 0.1.6 tag ?
[00:02] <kdub> the tag
[00:04] <kdub> USC should have which branches? i see a few likely candidates
[00:15] <kdub> here's what I see http://pastebin.ubuntu.com/7041505/
[00:19] <racarr_> https://code.launchpad.net/~robertcarr/unity-mir/update-to-not-use-configure-output/+merge/209565
[00:19] <racarr_> more build fixing
[00:19] <racarr_> https://code.launchpad.net/~robertcarr/unity-mir/usleep-include/+merge/209564
[00:20] <racarr_> not sure why this only appears on my system...
[00:22] <racarr_> which branch fixes the
[00:22] <racarr_> frontend detail link errors
[00:22] <racarr_> or is this new
[00:24] <kdub> racarr_, that one is new to me
[00:25] <kdub> racarr_, with usleep, AlbertA has https://code.launchpad.net/~albaguirre/unity-mir/remove-usleep-call
[00:48] <racarr_> kdub: Ah. thanks
[00:51] <RAOF> racarr_: Have you made any progress on multihead inprocess eglL
[00:51] <RAOF> L
[00:51] <RAOF> ?
[01:04] <racarr_> RAOF: Nooo
[01:04] <racarr_> you need a nested qualifier too :p
[01:04] <racarr_> but still no
[01:04] <RAOF> racarr_: True.
[01:04] <RAOF> Ok. I'll do more diving today then.
[01:10] <racarr_> RAOF: Thanks
[02:07] <duflu> 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] <racarr_> duflu: Credit to olli :D
[02:19] <racarr_> I made a really ugly video
[02:19] <racarr_> referred to as the blair witch project of web browser demos actually
[02:20] <racarr_> it kind of caught on in the film festival scene but
[02:20] <racarr_> :p
[02:20] <duflu> Hah. Yeah it's probably a job requirement that olli can do videos with flair
[05:03] <RAOF> Woot! That's why everything's getting wedged!
[05:05] <RAOF> 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] <RAOF> racarr_: Although it might be a little bit to late for you, I guess ;)
[05:20] <kgunn> RAOF: wouldn't the only time that happens is if the gpu crashes ?
[05:21] <kgunn> or locks up
[05:21] <RAOF> Apparently not.
[05:22] <RAOF> 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] <RAOF> Now, compositor_release *should* call the callback once its been called, but does not appear to be doing so.
[05:24] <kgunn> 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] <RAOF> The other option is to have a buffer-available signal?
[05:26] <RAOF> If you set swap interval 0 then we don't block(ish), and always return a buffer.
[05:27] <RAOF> Blocking SwapBuffers until you've got a back buffer seems like a reasonable (and reasonably standard) thing to do?
[05:49] <duflu> 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] <duflu> So in places, very important to block
[05:52] <kgunn> 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] <kgunn> that would seem to preclude clients from making a decision to just render if they want to...
[05:53] <kgunn> seems cheeky
[05:55] <duflu> 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:56] <duflu> No, that's not right. Clients' SwapBuffers will return ASAP, on a maximum period of the maximum monitor refresh rate
[05:57] <duflu> Unless they have explicitly disabled blocking with eglSwapInterval(0), but that's a bad idea usually
[05:58] <kgunn> 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] <RAOF> Yay! Hypothesis!
[06:00] <duflu> 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] <kgunn> usually faster if possible...
[06:01] <duflu> Well the good news is that since Mir 0.1.5 we have maximized the rendering time available
[06:01] <duflu> On desktop anyway. I'm not as familiar with Android
[06:02] <RAOF> 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] <RAOF> But! Lunch time.
[06:03]  * duflu assumes other people understand whatever bug that is
[06:04] <RAOF> duflu: https://bugs.launchpad.net/mir/+bug/1287282
[06:04] <duflu> That sounds unpleasant
[06:05] <RAOF> 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] <duflu> RAOF: Please do
[06:07] <duflu> RAOF: On another note... I almost forgot. We can now implement xrandr rotation against XMir
[06:07] <duflu> For fun. Not because anyone *needs* it
[06:07] <RAOF> Woot!
[06:07] <RAOF> Anyway, really lunch time.
[06:11] <duflu> 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] <duflu> Is it a good idea to automatically use monitors that are off from the beginning?
[06:19] <RAOF> duflu: We can't tell that they're off.
[06:19] <duflu> Oh. That would do it
[06:20] <RAOF> Except with DisplayPort and *some* HDMI.
[06:47] <racarr_> RAOF: Oh...good catch :D I forgot
[06:47] <racarr_> we had implemented the obscuring logic...
[06:47] <racarr_> I should have figured out thats what it was when
[06:47] <racarr_> moving the top nested window
[06:47] <racarr_> unblocked them lol
[06:47] <racarr_> I also should have remembered to mention that to you
[06:47] <RAOF> I should have tried it sooner :)
[06:47] <racarr_> :D
[06:47] <racarr_> ITERATEEEEE
[06:48] <RAOF> So, shall I fix that FIXME in nested_output.cpp? :)
[06:48] <duflu> Whee, bisection without the ability to build old revisions
[06:49] <RAOF> Oh, why not?
[06:49] <duflu> RAOF: The glm package update from trusty, remember?
[06:49] <RAOF> Oh, right. Buh!
[06:51] <duflu> Fortunately the offending use case is pretty uncommon right now
[06:51] <racarr_> RAOF: Would be excellent or if you are busy I can do it in the morning
[06:52] <racarr_> I am now, not busy! (I am sure that statement will be corrected when kgunn wakes up :p)
[06:52] <kgunn> racarr_: i have so much planned for you
[06:52] <kgunn> mmwwwhahhahahah
[06:52] <racarr_> go to sleep or you arent going to grow up to be tall.
[06:53] <kgunn> too late for that
[06:53] <racarr_> :p
[06:53] <kgunn> probably causses gray hair too
[06:53] <kgunn> i so heart this landing process
[06:54] <duflu> http://memegenerator.net/instance/46502261
[06:54] <racarr_> What happened? It seems like everything is in a jumble
[06:54] <racarr_> and im missing the root cause of the chaos
[06:54] <racarr_> duflu: Lol I see So you do window management
[06:54] <racarr_> is the new team meme
[06:56] <duflu> This is really annoying. SwitchingBundle reports multi-monitor frame sync working perfectly. But my eyes disagree
[06:57] <duflu> Maybe the parallelized page flipped has somehow found a way to go a double speed?
[07:00] <RAOF> 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] <racarr_> ok sorry australia friends but the more you say the less sleepy I feel :p and thats the wrong direction
[07:01] <racarr_> goood night!
[07:02] <duflu> racarr_: Night
[07:02] <duflu> RAOF: I was wondering... do we need to give CI new instructions as to how to successfully run the tests on armhf?
[07:02] <duflu> Cos I assume the old method will fail now (since that branch)
[07:03] <RAOF> duflu: No, the old method works fine.
[07:04] <duflu> The failures look udev/syscall specific. So possibly actually related to the code changes
[07:04] <RAOF> What failures are you looking at?
[07:05] <duflu> RAOF: A couple of them https://code.launchpad.net/~raof/mir/udevify-eventhub/+merge/206659
[07:05] <RAOF> Which log result?
[07:06] <duflu> This is a fun one:
[07:06] <duflu> [----------] 2 tests from UdevWrapperDeathTest
[07:06] <duflu> [ RUN      ] UdevWrapperDeathTest.DereferencingEndReturnsInvalidObject
[07:06] <duflu> ==10840==
[07:06] <duflu> ==10840== Process terminating with default action of signal 11 (SIGSEGV)
[07:06] <duflu> ==10840==  Bad permissions for mapped region at address 0x1884DB8
[07:06] <duflu> ==10840==    at 0x1884DB8: ???
[07:06] <duflu> ==10840==
[07:07] <RAOF> That's entirely expected.
[07:07] <RAOF> The test is checking that SIGSEGV is raised, so valgrind picking that up is pretty normal :)
[07:07] <duflu> Well it can't pass with it either, can it?
[07:07] <duflu> Oh, those are passing!?
[07:08] <racarr_> I was trying to write an acceptance test today
[07:08] <racarr_> that, a client will block on swap buffers.
[07:08] <RAOF> duflu: Yup, those are passing.
[07:08] <racarr_> and swap buffers will not turn the display back on
[07:08] <duflu> 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] <racarr_> if its another client thats requested turning the display off
[07:09] <racarr_> but its hard to write these tests, i.e. check that like
[07:09] <racarr_> swap buffers blocks. when do you time out?
[07:09] <RAOF> A second, maybe 2.
[07:10] <racarr_> 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] <duflu> RAOF: Sanity check with some trivial proposals and see if they can land?
[07:10] <racarr_> and then use a custom mutex implementaion with a simple...graph traversal kind of thing
[07:10] <racarr_> you can write tests like...
[07:11] <racarr_> EXPECT_THAT(RPCThreadFor(session, BlocksOn(CompositorThread))
[07:11] <racarr_> and then just quit the test

[07:11] <duflu> racarr_: If this is you sleeping, may I suggest finding new ways to wind-down evenings? :)
[07:11] <racarr_> lol
[07:12] <racarr_> i just wanted to put it somewhere because I knew I would forget
[07:14] <duflu> racarr_: And archived for you: http://irclogs.ubuntu.com/2014/03/06/%23ubuntu-mir.html
[09:18] <RAOF> racarr_: Enjoy https://code.launchpad.net/~raof/mir/nested-one-surface-per-crtc/+merge/209615
[09:23] <duflu> alan_g: Any chance you could look into https://bugs.launchpad.net/bugs/1288570 some time?
[09:24] <alan_g> duflu: sure - although you mentioned something about just using a different approach in comments?
[09:24] <duflu> 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] <alan_g> ok
[09:31] <duflu> alan_g: In fact, it's not just rendering faster, but looks like it's alternating forwards/backwards in time so juddering
[09:31] <duflu> Not sure
[09:36] <anpok_> 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] <anpok_> i expected the rectangle to go from 8 to 13, but it starts at 9..
[09:38] <alan_g> 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] <duflu> alan_g: Yeah I went back and looked at the tests I wrote for that. They seemed OK
[09:41] <duflu> Of course, you can't write tests for *everything* you haven't thought of yet
[09:42] <duflu> However we broke it, I didn't foresee as possible
[09:43] <alan_g> duflu: don't let it spoil your evening
[09:44] <duflu> alan_g: It won't. I was happy to just complete the bisection
[12:20] <kgunn> 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] <alf_> 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] <greyback> alf_: using build packages from the silo. I just flashed my tablet & installed the silo's ppa and updated
[12:23] <greyback> ah not again, think latest adbd broken on manta
[12:26] <greyback> Setting up libmirclientplatform-mesa:armhf (0.1.6+14.04.20140306-0ubuntu1) ...
[12:26] <greyback> 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] <ogra> greyback, working on that (well, trying to, my manta misbehaves)
[12:27] <greyback> ogra: Great, thanks. It started working again after reboot. But I was struggling with it this morning, had to reflash
[12:27] <ogra> oh ? i wonder why it started working ... theoretically it shouldnt :P
[12:27] <greyback> lol
[12:28] <kgunn> i'm trying on a N4
[12:28] <greyback> ogra: any logs useful for you, while it is magically working?
[12:28] <kgunn> alf_: what should i look for as this thing attempts to boot...log ? or output ?
[12:29] <ogra> no, i'm just surprised it started to work
[12:31] <alf_> 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] <alf_> greyback: kgunn: I don't think this is a problem with images, since the proper packages should be seeded for them.
[12:32] <greyback> alf_: confirmed that works
[12:32] <kgunn> i just got the vt err on unity8 manual attempt
[12:33] <greyback> kgunn: sudo apt-get install libmirclientplatform-android libmirserverplatform-android && sudo apt-get purge libmirclientplatform-mesa:armhf libmirplatformgraphics-mesa:armhf
[12:33] <greyback> that should help
[12:34] <alf_> 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] <alf_> 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] <kgunn> lol
[12:37] <kgunn> nice try
[12:37] <greyback> alf_: how is mesa/android decided by Mir? At runtime?
[12:38] <alf_> greyback: dpkg-alternatives set a system-wide default, but you can also override the exact library to use with environment variables
[12:38] <davmor2> greyback: magic
[12:39] <greyback> alf_: I just don't want someone to accidentally install -android packages on their desktop and break it.
[12:40] <greyback> ogra: sanity restored: rebooted manta again, no adb
[12:40] <ogra> heh
[12:41] <ogra> 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] <alf_> 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] <ogra> (but you will get the annoying disconnects)
[12:44] <greyback> 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] <kgunn> 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] <ogra> well it doesnt seemt o work on manta ...
[12:44] <ogra> trying to find a proper fix ... but since i use my manta only once a month the battery went completely dead
[12:45] <greyback> ogra: well if you need tester, let me know
[12:45] <ogra> will do
[12:46] <greyback> kgunn: with that change, things seem to work. Any idea how the crash is reproduced?
[12:46] <kgunn> greyback: mterry & kdub were saying it was on startup
[12:47] <kgunn> what's strange is kdub could launch unity8 manually...
[12:47] <kgunn> and it would work
[12:47] <kgunn> greyback: one note...they were building tip mir dev...and not sure about the other components....
[12:48] <kgunn> meaning...its not precisely whats in silo3
[12:48] <greyback> kgunn: which means I don't care...yet
[12:48] <greyback> let's see if silo3 has that issue
[12:48] <kgunn> greyback: right if silo 3 works...
[12:49] <kgunn> alf_: greyback ...however, i just removed the mir mesa packages & installed the android ones....and rebooted, stuck at google splash screen
[12:50] <kgunn> manual attempt resulted in: Failed to load platform plugin "ubuntumirserver"
[12:50] <greyback> kgunn: is qtubuntu-android:armhf installed?
[12:51] <kgunn> just trying that now
[12:51] <kgunn> ooo....broken packages
[12:52] <didrocks> kgunn: broken, like broken? (or broken as you didn't upgrade everything needed?)
[12:53] <kgunn> didrocks: just to make sure...i added the ppa(slio3) did a apt-get update, followed by a dist-upgrade
[12:53] <didrocks> yeah, that should be right
[12:54] <kgunn> https://pastebin.canonical.com/106009/
[12:54] <didrocks> did you change the packaging more than usual?
[12:54] <didrocks> hum
[12:54] <kgunn> nope...only thing i did was the removal of "mesa" and install of "android" discussed for the 2 pkgs above
[12:55] <didrocks> kgunn: ok, I can extract the packaging diff as a first look (cheating and sshing on citrain machine)
[12:55] <didrocks> just to see if there is any crazyness in packaging changes first ;)
[12:55] <kgunn> didrocks: if its important to know...i started with a channel devel-proposed image like 30 min ago
[12:55] <didrocks> yeah, sounds perfect
[12:55] <kgunn> didrocks: hey thanks...
[12:55] <didrocks> let me reflash cleanly my phone at the same time
[12:55] <kgunn> didrocks: yeah...weird greyback says its ok with manta (i'm on mako)..but greyback did you have an "older image" ?
[12:56] <didrocks> yeah, the device shouldn't come into play for deps issues
[12:56] <didrocks> apart from a "non cleaned image"
[12:56] <greyback> kgunn: ooh wow I did, from Feb20: http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/current/
[12:56] <kgunn> ok guys...i gotta step away for monring duties...bbian
[12:57] <kgunn> bbiab
[12:57] <kgunn> greyback: you lazy bastard :)
[12:57] <kgunn> jk...lol
[12:57] <greyback> I've excuses, but anyway...
[12:58] <didrocks> -               android-headers (>=4.2.2) [armhf],
[12:58] <didrocks> +               android-headers (>=4.2.2) [i386 amd64 armhf],
[12:58] <didrocks> that's a little bit weird, but not the issue per say
[12:59] <didrocks> hum
[12:59] <didrocks> +         libmirplatformgraphics-mesa (= ${binary:Version}) |
[12:59] <didrocks> +           libmirplatformgraphics-android (= ${binary:Version}),
[12:59] <didrocks> greyback: do you know about that? ^
[13:00] <didrocks> kgunn: description of the binary packages aren't good btw (shouldn't be NEWed that way)
[13:01] <kgunn> alf_: might know about that didrocks
[13:01] <greyback> didrocks: I do now
[13:02] <greyback> but alf_ is the author
[13:03] <alf_> didrocks: ?
[13:06] <didrocks> alf_: the short description needs to be different between packages
[13:06] <didrocks> alf_: both reference the same
[13:06] <didrocks> (also, not really sure the per-arch will please everyone ;))
[13:06] <didrocks> so, from what I understand, on dist-upgrade, we need to install the -android mir and client packages, right?
[13:10] <alf_> 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] <didrocks> alf_: right, the thing is that we don't build even -mesa on all platform
[13:10] <alf_> didrocks: e.g. on the x86 phone emulator we would need android
[13:11] <alf_> didrocks: which platforms are these?
[13:12] <didrocks> alf_: powerpc and ppcel64
[13:13] <alf_> didrocks: we aren't building any mir package on these platforms AFAICT
[13:13] <didrocks> 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] <didrocks> oh I know
[13:14] <didrocks> alf_: however, we still need to have different short descriptions between binary packages (which was the start of the discussion)
[13:15] <alf_> didrocks: ok, I will take care of that
[13:15] <didrocks> 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] <didrocks> thanks
[13:15] <didrocks> ok, so, let me try to apt-get install + dist-upgrade
[13:16] <didrocks> alf_: so, with that change, I guess we need to seed libmir*android on Touch?
[13:18] <alf_> 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] <didrocks> yep
[13:18] <didrocks> that should be noted in the silo line (kgunn)
[13:19] <didrocks> 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] <didrocks> interesting, let's see why apt-get doesn't want to upgrade it
[13:19] <didrocks> I guess we just need them to be listed explicitely as libmirserver15 will be removed
[13:20] <didrocks> The following packages will be REMOVED:
[13:20] <didrocks>   libmirserver15
[13:21] <didrocks> The following NEW packages will be installed:
[13:21] <didrocks>   libmirclientplatform-android libmirplatformgraphics-android libmirserver16
[13:21] <didrocks> The following packages will be upgraded:
[13:21] <didrocks>   libmirclient7 libmirplatform libmirprotobuf0
[13:21] <didrocks>   libubuntu-application-api-mirserver1 libunity-mir1 mir-test-tools
[13:21] <didrocks>   unity-system-compositor
[13:21] <didrocks> alf_: I'm missing no package here, right? ^
[13:21] <alf_> didrocks: looks good
[13:21]  * didrocks reboot the phone
[13:24] <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 apt. "sudo apt-get install libmirplatformgraphics-android libmirclientplatform-android libmirplatform" should do it
[13:25] <didrocks> 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] <alf_> 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] <didrocks> 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] <didrocks> alf_: but you will get bonus point if you can fix tabs vs spaces :p
[13:30] <didrocks> which are in debian/control, rules, the new postinst scripts as well IIRC
[13:32] <alf_> didrocks: I can only see spaces (except the make rules that need tab indentation)
[13:33] <didrocks> alf_: let me grab you some of the stuff I'm seeing (space and misalignement)
[13:34] <didrocks> alf_: oh, maybe you did that on purpose?
[13:35] <didrocks> +         libmirplatformgraphics-mesa (= ${binary:Version}) |
[13:35] <didrocks> +           libmirplatformgraphics-android (= ${binary:Version}),
[13:35] <didrocks> (same on client)
[13:35] <didrocks> and yeah, in rules:
[13:35] <didrocks> +         -DMIR_RUN_ACCEPTANCE_TESTS=OFF -DMIR_RUN_INTEGRATION_TESTS=OFF \
[13:35] <didrocks> +          -DMIR_PLATFORM=android\;mesa
[13:38] <alf_> 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] <didrocks> alf_: it's in the one which was generated on trunk, starting to get anxious if you have such diff there
[13:39] <didrocks> alf_: do you mind checking once that's landed? maybe you do have trunk/devel diff with changes only in trunk
[13:42] <alf_> 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] <didrocks> alf_: yeah, the diff I showed you is the result of that branch
[13:45] <alf_> didrocks: ok, thanks for pointing it out
[14:06] <kgunn> 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] <kgunn> i say "ci" in quotes since i was corrected that its all CI...but you know what i mean :)
[14:07] <kgunn> alf_: and thanks...
[14:13] <kgunn> alf_: i'll just make those updates manually
[14:13] <kgunn> to the branch for lp:~mir-team/mir/trunk-0.1.6
[14:17] <alf_> 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] <alf_> kgunn: actually the next line (-DMIR_PLATFORM=android\;mesa)
[14:20] <kgunn> alf_: what's wrong with it ?
[14:20] <rsalveti> didrocks: you also need to change the seeds with latest mir
[14:20] <rsalveti> guess you're just landing that together with the mir silo
[14:20] <alf_> kgunn: nothing functionally, just one space more indented than it should be
[14:21] <didrocks> rsalveti: yeah, I pinged kgunn to add a note for that
[14:21] <rsalveti> cool
[14:21] <didrocks> rsalveti: not sure we can land that together, the packages are NEW to the archive
[14:22] <rsalveti> oh, that's true
[14:22] <didrocks> 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] <didrocks> (and not kick an image in between :p)
[14:23] <kgunn> didrocks: i should rebuild ? or ?.....i just updated the branch for mir0.1.6 that would be merged post landing...
[14:23] <rsalveti> didrocks: sure :-)
[14:23] <didrocks> kgunn: what branches? only the typo ones?
[14:23] <alf_> kgunn: actually it's a matter of tabs vs spaces (but not a big deal, we can fix it later)
[14:24] <didrocks> yeah, don't rebuild just for that
[14:24] <didrocks> get that in the next batch
[14:24] <kgunn> didrocks: yeah, the description: in control & spacing for rules
[14:24] <kgunn> ok
[14:24] <kgunn> off to test then....
[14:24] <didrocks> kgunn: don't bother to put into the current one :)
[14:24] <didrocks> as long as it's not lost, it's fine :)
[14:30] <kgunn> didrocks: curious...what was the deal with broken packages ? was that me ?
[14:30] <kgunn> its working now
[14:30] <didrocks> kgunn: did you see my apt-get install line?
[14:30] <kgunn> ...well qtubuntu-android installed...
[14:31] <kgunn> didrocks: you had no trouble ?
[14:31] <didrocks> 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] <didrocks>                   | apt. "sudo apt-get install libmirplatformgraphics-android libmirclientplatform-android libmirplatform" should do it
[14:31] <didrocks> kgunn:  ^
[16:27] <kgunn> 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] <mterry> kgunn, yeah I meant to ask
[16:27] <kgunn> in order to avoid loading platform obj's for mesa....
[16:27] <mterry> kgunn, I can't have the mesa variants I suppose?
[16:28] <mterry> kgunn, that's what was causing my crashes we're guessing?
[16:28] <kgunn> otherwise mir will think its mesa and try to open vt's and stuff
[16:28] <kgunn> mterry: it would depend on how you loaded it
[16:28] <mterry> kgunn, normal everyday booting into unity8
[16:28] <kgunn> ...if you by chance installed mesa platform packages for mir then yes
[16:29] <mterry> kgunn, I bet I did dpkg -i ../libmir*.deb
[16:29] <mterry> without realizing we got new mesa things
[16:29] <kgunn> yeah...that'd do it
[16:29] <mterry> kgunn, stop making it a pain to dpkg a new mir!
[16:29] <mterry> :)
[16:34]  * alan_g goes looking for yet another monitor to add to his laptop
[16:38] <kdub> i must have missed some email somewhere, but when we say silo... where is that?
[16:40] <ogra> where the train parks :)
[16:41] <greyback> kdub: https://launchpad.net/~ci-train-ppa-service/+archive/landing-003/ is the one I was referring to
[16:42] <kdub> thanks greyback
[16:43] <ogra> 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] <greyback> ogra: cool, thanks
[19:13] <mterry> kgunn, so theoretically removing those two -mesa packages would fix the unity8 problems?  didn't seem to work for me
[19:14] <kgunn> mterry: well...did you purge ?
[19:14] <kgunn> btw...in the end, i had to reflash & reinstall....the simple uninstall/install only android didn't work for me
[19:15] <kgunn> only greyback claimed success
[19:15] <kgunn> andhe was on an ancient image
[19:15] <kgunn> ancient == 2 week old
[19:16] <mterry> kgunn, ok, will do the cycle
[19:16] <kgunn> mterry: sorry...sucks i know
[19:17] <mterry> kgunn, if this is indeed necessary (instead of some weird other problem), seems like bad packaging...?
[19:18] <kgunn> 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] <kgunn> sudo apt-get install libmirplatformgraphics-android libmirclientplatform-android libmirplatform
[19:18] <kgunn> then it all just works
[19:19] <kgunn> and according to didrocks...that'll be fixed when it lands for real
[20:43] <rsalveti> kgunn: yes, that should indeed work
[20:43] <rsalveti> kgunn: are you having issues with it?
[20:43] <rsalveti> I can give it a try
[20:44] <kgunn> i just reflashed and it worked
[20:44] <rsalveti> awesome
[20:50] <rsalveti> kgunn: any other issue blocking that silo?
[20:50] <rsalveti> just to know if we'll be able to land that today still
[20:50] <kgunn> rsalveti: i found a gnarly manual test that revealed a problem with OSK....note AP test for OSK passed 100%
[20:51] <rsalveti> oh, ok
[21:40] <racarr_> mterry: Want to test a branch for your screen turning on issue?
[21:42] <mterry> racarr_, sure...  Can I apply it to 0.1.5 easily enough?
[21:42] <racarr_> mterry: Yes unity-mir only
[21:43] <racarr_> mterry: lp:~robertcarr/unity-mir/greeter-configuration-for-mterry
[21:43] <racarr_> then in your unity8 branch, where main.cpp calls
[21:43] <racarr_> runQMirServerWithClient
[21:43] <racarr_> call runQMirServerWithGreeterClient
[21:43] <racarr_> if you are um...
[21:43] <racarr_> the greeter
[21:46] <mterry> racarr_, huh, k
[21:49] <mterry> racarr_, your branch makes me feel so special  :)
[21:53] <racarr_> mterry: Oh no, thats an abbreviation for Mir Thread Enhancing RAII Refactoring (from) Yesterday.
[21:54] <mterry> racarr_, lol'
[21:55] <rsalveti> 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] <rsalveti> it seems the package is really old
[21:55] <rsalveti> alf_: I can sponsor the upload if you need any help
[22:22] <mterry> racarr_, I must have screwed something up, unity8 is crashing
[22:22] <racarr_> mterry: Well. You mayt have not screwed anything up ;)
[22:23] <racarr_> can you get a basic backtrace + stdoutstderr etc if there is anything interesting
[22:23] <racarr_> and if its not obvious I will try and reproduce it locally
[22:23] <mterry> racarr_, I'm more inclined to think it's me right now, will try again.  But I didn't see anything interesting in stdout/stderr
[22:24] <racarr_> ok
[22:24] <racarr_> API/ABI issues are all over right now so
[22:24] <racarr_> one thing to check lol
[22:24] <mterry> racarr_, yar
[22:25] <mterry> racarr_, if I fail again, note that you can have split greeters too with lp:~mterry/unity8/split and lp:~mterry/unity-system-compositor/greeter-depth
[22:26] <racarr_> mterry: Im just trying to avoid setting it all up by hoping it will all work lol
[22:26] <racarr_> if you dont get anywhere pretty quick lemme know and ill build it all
[22:26] <mterry> racarr_, that's fair.  Don't do anything until I reconfirm my crash
[22:26]  * mterry is rebuilding unity-mir, I might have accidentally built your branch with bad ABI
[22:29] <racarr_> storrry of our lives
[22:29] <racarr_> I had this idea the other night that everything could be quote continuously integrated
[22:30] <racarr_> but I was probably just too drunk thats crazy talk
[22:30] <racarr_> :p
[22:39] <mterry> racarr_, ok.  Fixed crash by recompiling
[22:39] <mterry> racarr_, but now I don't see a change in behavior
[23:00] <racarr_> mterry: That is a crying shame
[23:00] <racarr_> mterry: Oh wait is this mir 0.1.5
[23:00] <mterry> racarr_, yes
[23:01] <racarr_> mterry: Ok sorry I got
[23:01] <racarr_> that whole part about not neeidng mir changes
[23:01] <racarr_> I made that up
[23:01] <racarr_> you need some revision from alan that does async swapping on the server side annnd
[23:01] <racarr_> mterry: and https://code.launchpad.net/~robertcarr/mir/remove-ensure-display-powered/+merge/209734
[23:02] <racarr_> so unless this is blocking anything I think the answer is try again next thursday because right now its
[23:02] <racarr_> not possible to build those combination of things against unity mir :p
[23:04] <mterry> racarr_, I just want lp:mir/devel and all extant branches to land in trusty right now
[23:05] <racarr_> ok well hopefully things will land then we will revisit htis next week
[23:08] <mterry> hmm
[23:09] <mterry> Maybe I need to try to rebuild Mir world again
[23:09] <racarr_> unity-mir wont build against
[23:09] <racarr_> mir never than 0.15
[23:09] <racarr_> newer
[23:09] <mterry> racarr_, there aren't branches for it?
[23:09] <racarr_> uh there seem to be branches for
[23:09] <racarr_> 0.1.6
[23:09] <racarr_> but not for devel
[23:09] <racarr_> 0.1.6 + my branch
[23:09] <racarr_> might get you what you need
[23:10] <kdub> and... lp:mir/devel has broken api with 0.1.6
[23:10] <racarr_> right
[23:10] <racarr_> devel + unity mir is no go
[23:11]  * mterry gets grumpy
[23:11] <racarr_> mterry: XD me too
[23:11] <racarr_> which is why I forgot that you needed mir changes too
[23:11] <racarr_> because I couldnt get unity-mir to build to make the changes then was like
[23:11] <racarr_> oh I can just use 0.1.5
[23:12] <racarr_> then forgot that we actually need to run them too
[23:12] <racarr_> 21:27 < kgunn> racarr: for unity-mir against dev branch tip it'd be
[23:12] <racarr_> 21:28 < kgunn> basically every mp "ready to land" here https://code.launchpad.net/unity-mir/+activereviews
[23:12] <racarr_> 21:28 < kgunn> in specific order its
[23:12] <racarr_> 21:29 < kgunn> https://code.launchpad.net/~albaguirre/unity-mir/cross-compile-link-fix/+merge/205690
[23:12] <racarr_> 21:29 < kgunn> https://code.launchpad.net/~albaguirre/unity-mir/add-cross-compile-scripts/+merge/206058
[23:12] <racarr_> 21:29 < kgunn> https://code.launchpad.net/~andreas-pokorny/unity-mir/fix-1240400/+merge/207302
[23:12] <racarr_> 21:29 < kgunn> https://code.launchpad.net/~andreas-pokorny/unity-mir/fix-1281075/+merge/207375
[23:12] <racarr_> 21:29 < kgunn> https://code.launchpad.net/~mterry/unity-mir/drop-dbusscreen/+merge/202236
[23:12] <racarr_> 21:29 < kgunn> https://code.launchpad.net/~mzanetti/unity-mir/expose-appimage-sourceSize/+merge/207626
[23:12] <racarr_> 21:29 < kgunn> https://code.launchpad.net/~gerboland/unity-mir/namespace-to-prevent-collision/+merge/208645
[23:12] <racarr_> 21:29 < kgunn> https://code.launchpad.net/~kgunn72/unity-mir/um-mir-0.1.6/+merge/208819
[23:12] <racarr_> this wont work against dev branch tip lol
[23:12]  * kdub gets grumpy too
[23:13] <racarr_> but should against 0.1.6
[23:13] <racarr_> ...lol yeah
[23:13] <racarr_> Why did unity-mir ABI updates start landing
[23:13] <racarr_> out of sync with
[23:13] <racarr_> mir changes
[23:13] <kgunn> racarr_: what do you mean ?
[23:14] <kgunn> because we have a dev-branch for mir
[23:14] <kgunn> but things w/o a dev branch cannot merge stuff that doesn't get to archive
[23:14] <kgunn> make sense ?
[23:14] <racarr_> maybe we should have a dev branch
[23:14] <racarr_> for unity-mir too
[23:14] <kgunn> agreed
[23:14] <racarr_> that is always in sync with mir/devel
[23:14] <racarr_> I was thinking about this last night
[23:15] <kgunn> cause afaik you're missing one MP
[23:15] <racarr_> and then again with glmark 2
[23:15] <racarr_> today
[23:15]  * kdub likes that idea
[23:15] <racarr_> and we should have a list of projects that depend on mirclient/mirserver ABI
[23:15] <racarr_> and they should all always have a branch that builds against devel
[23:15] <racarr_> and if you submit a mir branch or example
[23:15] <racarr_> that breaks unity-mir build
[23:15] <racarr_> you have to point the mir CI at a branch that
[23:15] <racarr_> fixes unity-mir build
[23:15] <kgunn> racarr_: i don't disagree...but its the mir teams responsibility to make that happen
[23:16] <kgunn> if we break abi we should either work with someone or do the job ourself
[23:16] <racarr_> right what I am saying is it needs
[23:16] <racarr_> to be part of continuous integration reviews
[23:16] <racarr_> because we cant keep track of it
[23:17] <racarr_> and we need the dev branch so
[23:17] <racarr_> we can always make the ABI change/update right after one another
[23:17] <racarr_> rather than end up with a list of buffered ABI changes like now
[23:17] <racarr_> because now there are unbuildable combinations of branches
[23:19] <racarr_> The thing is
[23:19] <racarr_> we can never land the changes exactly concurrently obviously because
[23:19] <racarr_> unity-mir CI will depend on the new version of mir being published
[23:20] <racarr_> if we had no dev branch, and didnt have the problem of CI getting choked up around difficult...times
[23:21] <racarr_> then its no problem, mir ABI breaks land and are published, unity-mir immediately follows, everything moves out of proposed
[23:21] <racarr_> Err...I kind of lost track of my conclusion there lol
[23:21] <racarr_> trying to head back to: We need a dev branch for unity-mir too
[23:21] <kgunn> racarr_: if you want...there are 3 branches here
[23:21] <kgunn> called stage
[23:21] <kgunn> d
[23:21] <kgunn> in the names
[23:21] <kgunn> for each platform-api, usc, unity-mir
[23:21] <kgunn> they should all build together for tip....
[23:22] <kgunn> as i already merged all the various MP's in
[23:22] <kgunn> and i got all but unity-mir to build for tip
[23:22] <racarr_> kgunn: Excellent :D
[23:22] <racarr_> so what Ia m saying, is 1. Those branches should always exist
[23:22] <racarr_> 2. if a mir commit causes those branches to fail to build
[23:22] <racarr_> the commit description or something has to include a link to branches that fix it
[23:23] <kdub> or, better yet, debian/changelog
[23:23] <kgunn> sure...and i don't think its that hard to figure out when abi is broken for server
[23:23] <kgunn> its not magic
[23:23] <kgunn> i mean to me, before even landing a break...every individual on the team should have a matching MP
[23:23] <racarr_> Well, rather than trying
[23:23] <kgunn> on the relevant projects
[23:24] <racarr_> to detect ABI breaks
[23:24] <racarr_> lets just literally
[23:24] <racarr_> build the dependent projects
[23:24] <kgunn> sure
[23:24] <racarr_> with the fixing branch merged in you cant
[23:24] <racarr_> merge the fixing branch at first but we can have some sort of
[23:24] <racarr_> special syntax jenkins bot understands like
[23:24] <kgunn> racarr_: there are some nuancess....
[23:24] <kgunn> like, stupid ppa builders...do not today permit running of our android integration tests
[23:25] <racarr_> <fixes unity-mir-build> lp:~santaclaus/unity-mir/update-abi
[23:25] <kgunn> they always fail
[23:25] <racarr_> Even without testing
[23:25] <kgunn> so literally the mir staged branch is mir-dev w/ android integraion tests disabeld
[23:25] <racarr_> it still buys us a lot
[23:25] <racarr_> we can make it impossible to land a mir commit without
[23:25] <racarr_> having an open proposal to fix
[23:26] <racarr_> all dependent projects which are broken
[23:26] <racarr_> at least in terms of
[23:26] <racarr_> building
[23:26] <kgunn> so we could simply add that to the jenkins job today could we not ?
[23:26] <kdub> kgunn, maybe i can work on getting those tests disabled if no hardware is detected
[23:26] <racarr_> kgunn: I think almost.
[23:26] <kgunn> kdub: that would mean we could use lp:mir/devel so yeah that'd be awesome
[23:26] <racarr_> We will have to play with the jenkins bot to get it to
[23:27] <racarr_> 1. Understand some list we place somewhere of
[23:27] <racarr_> dependent projects
[23:27] <kdub> kgunn, I'll see what can be done
[23:27] <racarr_> I mean I guess its a new job
[23:27] <racarr_> that 1. understands the list of dependent projects. 2. understands this special syntax for specifying branches that fix ABI breaks
[23:27] <racarr_> 3. Builds everything
[23:28] <racarr_> so, probably not today
[23:28] <racarr_> but in the scope of a few days espescially if someone knows what they are doing with jenkins
[23:28] <kgunn> racarr_: acutally what you are describing is a dedicated build silo from the "ci train" process that didrocks/asac own
[23:28] <racarr_> more than me lol
[23:28] <kgunn> and i've been asking for this...
[23:28] <racarr_> You lost me
[23:29] <racarr_> build silo = ?? ci train = ??
[23:29] <kgunn> racarr_: basically ci train silo is what i take all the mp's dump them into ...and then it builds matching packages across all the projects
[23:29] <racarr_> ok yes something like that
[23:29] <kgunn> racarr_: output from a build silo https://launchpad.net/~ci-train-ppa-service/+archive/landing-003
[23:29] <racarr_> except integrated in to Mir devel
[23:29] <racarr_> continuous integration
[23:29] <kgunn> but its more flexible than recipes
[23:29] <racarr_> which requires the mir dependent branches to have devel branches too
[23:30] <kgunn> but not as good as our ci on mir-devel
[23:30] <racarr_> and this little syntax to tell jenkins which branches to use
[23:30] <racarr_> but produces the same result
[23:30] <racarr_> I just want to find a way to get it part of our
[23:30] <racarr_> mir devel CI
[23:31] <racarr_> once we have a job like this as part of Mir CI too
[23:31] <racarr_> we can start adding integration tests
[23:31] <racarr_> like you cant land on mir devel if it breaks a Qt window from opening
[23:32] <racarr_> or we can run autopilot tests on the produced set, etc
[23:33] <racarr_> tbh this whole CI bit I am talking about is
[23:33] <racarr_> really step 2.
[23:33] <racarr_> just step 1 maintaining a staged/devel branch for unity-mir, platform API, etc.
[23:33] <racarr_> I think could help us a lot
[23:34] <racarr_> because right now when someone from the shell team needs a mir change you often cant make it against mir devel (so you lose other recent changes)
[23:35] <racarr_> or you have to wait a long time on test turn around
[23:35] <racarr_> kgunn: Sorry haha hope it doesnt seem I am ranting at you
[23:35] <racarr_> I am just brainstorming
[23:41] <racarr_> kgunn: If you want I can take some time to try and
[23:41] <racarr_> rig something up
[23:41] <racarr_> I am kind of waiting on Alan to finish studyibg things to move forward on QML compositor stuff
[23:41] <racarr_> so mustly just picking up odd bits and ends atm
[23:46] <kgunn> yes...please
[23:46] <kgunn> it would help immensely
[23:46] <kgunn> feel free to harnes the staging ppa with the branches...if you want