[00:11] <thomi> robert_ancell: I'll email francis and see what he thinks
[00:34] <robert_ancell> RAOF, I think I saw you had some bzr magic that tells you if you have merged branches that can now be pruned - is that right?
[00:38] <RAOF> robert_ancell: Correct.
[00:39] <RAOF> robert_ancell: You're looking for the bzr-removable plugin.
[00:39] <RAOF> cd ~/.bazaar/plugins; bzr branch lp:bzr-removable removable
[00:46] <robert_ancell> RAOF, ta
[00:47] <RAOF> for I in $(bzr removable trunk) ; do rm -r $I ; done
[00:47] <RAOF> (Obviously in the repository)
[00:49] <robert_ancell> so handy
[00:51] <RAOF> You'll likely find that it misses a number of branches that are actually removable - it's quite conservative. So if you've got any untracked files or uncommitted changes, the branch will not be marked as removable.
[00:51] <RAOF> ‘bzr unremovable trunk’ will tell you why things aren't removable.
[01:49] <thomi> duflu: you around?
[01:49] <duflu> thomi: Maybe
[01:49] <thomi> duflu: any idea how I can narrow down the reason why, as of this morning, compiz is using 80% of my CPU, and Xorg the other 20%?
[01:50] <thomi> even when I have no windows open :(
[01:50] <duflu> thomi: Wow. What driver/GPU?
[01:50] <thomi> well, other than a terminal
[01:50] <thomi> duflu: it's an nvidia GF116M  [GeForce GT 560M]
[01:51] <duflu> thomi: Yeah Nvidia's the worst for CPU usage on a good day...
[01:51] <thomi> it's never been this bad
[01:51] <thomi> I also have a bangin' CPU, so 80% is quite a lot :)
[01:51] <duflu> thomi: It's probably some hidden(?) window generating damage
[01:51] <thomi> hmmmm
[01:52] <duflu> thomi: Try the compiz plugin CCSM>Utility>Show Repaint
[01:52] <thomi> duflu: I don't see that plugin in ccsm - is there a separate package I need to install?
[01:52] <duflu> thomi: Yes, the compiz-plugins package
[01:53] <thomi> gotchya
[01:54] <duflu> thomi: Also, some snapshots of the compiz threads using a script I will email you...
[01:55] <thomi> duflu: hmm, interesting. I now have a very colorful desktop
[01:55] <duflu> thomi: That's showing the windows generating damage/redraws
[01:55] <thomi> duflu: also, it seems like when I enabled that plugin the CPU usage dropped down to 30%
[01:55] <duflu> thomi: Perhaps it's the root window; nautilus misbehaving?
[01:56] <duflu> Or the unityshell plugin
[01:56] <thomi> wow, there we go...
[01:56] <duflu> ?
[01:56] <thomi> epileptic fit time :-/
[01:56] <thomi> back up to 80% :-/
[01:57] <duflu> thomi: sudo dstack compiz    # a few times
[01:57] <duflu> https://launchpadlibrarian.net/106890342/dstack
[01:57] <thomi> it seems to be repainting both monitors every frame :-/
[01:57] <duflu> And then send me the output somehow. In a bug?
[01:58] <duflu> I'm not going to *fix* compiz but might be able to tell you what the issue is
[01:58] <duflu> thomi: Also try unloading the unityshell plugin. It has a history of doing such things
[01:59] <thomi> duflu: http://paste.ubuntu.com/6001417/
[02:00] <duflu> thomi: Yep, that confirms something is triggering rendering constantly. And unityshell being slow at rendering makes that 100% CPU
[02:01] <duflu> thomi: But unityshell is not always the trigger. Can you try disabling it in CCSM, briefly?
[02:01] <thomi> sure
[02:02] <thomi> duflu: with unityshell disabled, CPU usage drops to 63%
[02:02] <duflu> thomi: Still busy tho?
[02:03] <duflu> thomi: OK, try killall nautilus :)
[02:03] <thomi> hmmm, I don't see the repaint plugin flashing me anymore
[02:04]  * thomi tries re-enabling unity
[02:05] <thomi> hmm, seems to be better... so far
[02:06] <duflu> thomi: Yeah I think I've seen that before. Nautilus randomly goes nuts and since it draws the desktop, that means everything gets repainted
[02:07] <thomi> interestingly, this happened after a reboot as well
[02:07] <thomi> it's interesting to see just how often we repaint things, sometimes for no discernable reason
[02:07] <thomi> for example, as I type this on the RHS monitor, chromioum is busy repainting all sorts of things on the LHS monitor
[02:09] <duflu> thomi: Yes, we browsers will repaint constantly due to animations, somehere, on some tab
[02:09] <duflu> -we +web
[02:13] <thomi> well, it seems to be sitting at 60%, which is at least somewhat usable - thanks for your help
[02:17] <duflu> thomi: 60% is bad. Is the flashing at least limited to a window now?
[02:19] <duflu> I mean, Show Repaint no longer shows the whole screen repainting, right?
[02:29] <duflu> ... You have to treat the root cause, which sounds like nautilus in this case. Unfortunately using unityshell (< 8.0) and Nvidia drivers will make performance worse
[02:54]  * duflu vanishes to test some ISOs briefly
[03:02] <duflu> thomi: I'm curious and concerned... Still 60%? Is showrepaint showing the whole screen repainting or just some windows?
[03:17] <thomi> duflu: hey, yeah, still %64
[03:17] <thomi> but showrepaint no longer shows whole screens being redrawn
[03:17] <thomi> so I think we're one step better than we were
[03:19] <thomi> ahaaaaa
[03:19] <duflu> thomi: Without a browser?
[03:19] <thomi> duflu: one of my chromium tabs had a notification, which makes chromium fade the tab colour in and out endlessly. if I get rid of the notification, it drops down to 19%
[03:20] <duflu> thomi: Also, I think some hacks in unityshell means compiz will get damage events from minimized windows. Which is not ideal.
[03:20] <thomi> :-/
[03:20] <thomi> man, I can't wait until we have mir - I'm sure then we won't see these sorts of problem.... RIGHT GUYS!??
[03:20] <thomi> :P
[03:22] <duflu> thomi: Yeah Mir has a simpler and more sensible damage model. It also doesn't have Unity7/Nux sitting on top of it to consume yet more CPU/GPU
[03:22] <thomi> yup
[03:23] <thomi> by then hopefully we'll have better graphics driver support as well
[03:23] <duflu> thomi: Tho we can't "fix" browsers or make Nvidia's proprietary drivers any less CPU hungry
[03:23] <thomi> :-/
[03:24] <duflu> By "fix" I mean stopping them from repainting when they actually need to
[03:24] <duflu> You could "fix" /all/ the web pages to make them more efficient for idle desktops
[03:24] <duflu> There can't be that many web pages
[03:45] <duflu> thomi: CPU usage is really an equation with many coefficients. So we don't need to "fix" browsers or drivers if we can lower enough of the coefficients using Mir/Unity8
[03:46] <thomi> sure
[04:59] <robert_ancell> thomi, I'm going to merge in the Ubuntu packaging into LightDM - https://code.launchpad.net/~robert-ancell/lightdm/debian-packaging/+merge/180766. Can you make the appropriate changes to CI / autolanding so it doesn't try and use the obsolete lp:~lightdm-team/lightdm/trunk-packaging?
[05:02] <thomi> robert_ancell: yes, but we cannot redeploy those changes until tomorrow
[05:02] <robert_ancell> thomi, that's fine
[05:03] <thomi> ok, cool
[05:05] <thomi> robert_ancell: while I'm in here, do you still need/want autolanding & CI for lp:~mir-team/lightdm/unity ?
[05:05] <robert_ancell> thomi, nope, that branch is dead
[05:06] <thomi> cool
[05:06] <robert_ancell> Mir support is in trunk now, and in the archive
[05:06] <robert_ancell> thomi, oh, did the raring builds get turned off for the staging PPA?
[05:07] <robert_ancell> they seem to still be building
[05:07] <thomi> robert_ancell: hmm, I could have sworn I'd landed that change, but it seems they're still configured
[05:07] <thomi> removing them now as well
[05:11] <thomi> robert_ancell: FYI: https://code.launchpad.net/~autopilot/cupstream2distro-config/lightdm-config-tweaks/+merge/180768
[05:12] <robert_ancell> thomi, does the staging PPA still get lightdm built from trunk? Is that done from somewhere else?
[05:13] <tvoss_> good morning
[05:13] <robert_ancell> tvoss_, hello
[05:13] <thomi> robert_ancell: no, it looks like lightdm trunk gets built into ppa:lightdm-team/daily
[05:13] <tvoss_> robert_ancell, hey there :) happy new week
[05:13] <thomi> hi tvoss_, how's it going?
[05:13] <robert_ancell> thomi, ah, ok
[05:13] <tvoss_> thomi, good, but my week is roughly 13 minutes old :)
[05:13] <thomi> robert_ancell: and in that PPA we build for precise<->saucy and everything inbetyween
[05:13] <tvoss_> thomi, how are you?
[05:14] <thomi> tvoss_: so far so good :)
[05:14] <thomi> enjoying a quiet monday without all you europeans asking me for things :P
[05:14] <robert_ancell> thomi, cool. So I'll delete lightdm from the staging PPA and point people at the lightdm-team/daily PPA if they need to test new changes
[05:14] <robert_ancell> thomi, so does the config need updating for the daily PPA to change the packaging?
[05:14] <thomi> robert_ancell: yeah. If we want it built into two places we may be able to accomodate that, but TBH that sounds like a bad idea to me
[05:15] <robert_ancell> thomi, shouldn't be any need
[05:15] <thomi> robert_ancell: that's what I just changed
[05:15] <thomi> robert_ancell: diff line 17 from that MP
[05:16] <robert_ancell> ah, ok
[05:16] <robert_ancell> awesome!
[05:16] <thomi> although, the diff is kind of hard to read, since LP doesn't give us much context around changes :-/
[05:16] <robert_ancell> yeah, that's what go me
[05:31] <robert_ancell> RAOF, can haz review plz? https://code.launchpad.net/~robert-ancell/unity-system-compositor/apport-pci-info/+merge/180771
[05:31] <robert_ancell> stolen shamelessly from xorg packaging
[05:32]  * robert_ancell -> EOD
[05:42] <RAOF> didrocks: Are we able to reproduce the ATI bug on the jenkins machine with the most recent mir?
[05:42] <didrocks> RAOF: not sure, as we stopped building it
[05:42] <didrocks> RAOF: do you think there is hope?
[05:43] <RAOF> didrocks: Well, https://bugs.launchpad.net/mir/+bug/1212516 is maybe related and might be fixed...
[05:43] <didrocks> RAOF: ok, I'll ask to have a try later today
[07:01] <dholbach> good morning
[07:16] <tvoss_> dholbach, salut
[07:18] <dholbach> hi tvoss_
[07:24] <Saviq> morning all
[07:26] <RAOF> Ah, yes. When changing XMir ABI it's important to actually update the drivers…
[07:28]  * duflu is still impressed every time he sees Mir smoothly and reliably use multiple monitors
[07:28] <RAOF> Then prepare to be amazed by XMir smoothly and reliably using multiple monitors!
[07:28] <RAOF> *: FSVO ‘smoothly’
[07:29] <RAOF> *: FSVO ‘reliably’ ☺
[07:29] <duflu> FSVO?
[07:29] <RAOF> For Some Values Of.
[07:30] <duflu> Ah, my math terminology is rusty
[07:31] <dholbach> sudo apt-get install bsdgames; wtf fsvo      :)
[07:32] <RAOF> Woot!
[07:32] <RAOF> Gone from no output to infinite loop after presenting the first frame!
[07:32] <duflu> It's /a step/
[07:33] <duflu> One small step for correctness, one giant leap for fan noise
[07:41] <RAOF> Gah. Stupid closures in C and their stupid type-erasing void *ctx.
[07:49] <tvoss_> RAOF, https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801
[07:50] <tvoss_> mzanetti, good morning :)
[07:50] <mzanetti> good morning tvoss_
[07:50] <tvoss_> mzanetti, hey :) so can you check if our friend the upstream merger is still alive?
[07:50] <mzanetti> hehe, sure
[07:52] <mzanetti> tvoss_: what makes you think it isn't?
[07:53] <tvoss_> mzanetti, I pushed to https://code.launchpad.net/~thomas-voss/platform-api/location-service/+merge/180692
[07:53] <tvoss_> mzanetti, an hour ago, and still no vote
[07:53] <mzanetti> tvoss_: right. I'll check
[07:53] <mzanetti> tvoss_: otherwise it seems to do stuff. not sure why this one wasn't picked up
[07:53] <tvoss_> mzanetti, thx :)
[07:54] <didrocks> tvoss_: "no vote" -> maybe he's undecided and wants to vote blank ;)
[07:54] <tvoss_> didrocks, well, I always figured that our jenkins setup might evolve to become skynet, but I haven't expected it that early
[07:55] <mzanetti> tvoss_: oh... the build queue holds like 50 jobs :/
[07:55] <tvoss_> mzanetti, oops
[07:56] <mzanetti> this is not looking good.
[07:56] <didrocks> tvoss_: ahah ;)
[07:58] <alf__> duflu: Hi! Bypass question: why do we care about transformations of non-fullscreen windows in the bypass filter?
[07:58] <duflu> alf__: Because no one uses the fullscreen state yet. It's not "wired up"
[07:59] <duflu> When it is, the certainly we'll use it
[07:59] <alf__> duflu: no, I mean we are checking for orthogonality of all windows, why is that?
[08:00] <duflu> alf__: Because a rotated window should not get bypassed. It would lose transformation
[08:00] <duflu> Oh, I see
[08:00] <duflu> Hang on
[08:01] <duflu> That was to fix a bug, let me find it
[08:02] <duflu> alf__: It's to reliably detect overlaps. If a window overlaps a fullscreen window then the fullscreen window can't be bypassed. And I do calculate the overlap for "orthogonal" windows, but for rotated windows it's too hard/unreliable. Safer to assume if anything is rotated (not orthogonal) then some fullscreen window "might" be overlapped.
[08:03] <duflu> And there are test cases which will fail otherwise...
[08:04] <alf__> duflu: ok, thanks
[08:05] <duflu> alf__: Also, I suspect in future that rotation will not be an attribute of a surface, but rather a function of an effect or animation that's in progress. If that changes then we will test for "any effects in progress" instead
[08:09] <duflu> alf__: I now see however that I shouldn't be caring about rotated windows that are underneath
[08:10] <duflu> Unless we start using Z-buffers
[08:10] <alf__> duflu: I think that's ok for now (for the XMir use case)
[08:11] <duflu> alf__: I think it may even become preferable to be "less correct" in future to stop more edge cases from accidentally un-bypassing a fullscreen window
[08:12] <duflu> Although that's less important for Mir where bypass can be switched on/off between frames. It was important in Compiz where there's a 2-frame lag
[08:15] <duflu> alf__: Actually that's a fun multimonitor test for bypass: Run egl{plasma,triagnle} -n -f, and then a second smaller windowed client. See how the first fullscreen client speeds up when there's nothing overlapping it
[08:15] <alf__> duflu: ack, will try it out
[08:17] <Saviq> tsdgeos, so it's not looking like racarr got anywhere on Friday? :/
[08:18] <tsdgeos> i think not :_/
[08:18] <tvoss_> Saviq, is ogra_ back?
[08:18] <tvoss_> ogra_, ping
[08:18] <Saviq> tvoss_, was he away?
[08:18] <tvoss_> Saviq, ah no, that was rsalveti
[08:19] <Saviq> tvoss_, canonicaladmin.com says he should be back today
[08:19] <tvoss_> Saviq, ah
[08:19] <Saviq> greyback, tsdgeos let me know what I can halp with, will try the app auth out now
[08:20] <ogra_> tvoss_, yup
[08:20] <greyback> Saviq: thanks
[08:20] <tvoss_> ogra_, hey, did something change in the lxc-android-container configuration in terms of memory limits?
[08:21] <ogra_> tvoss_, nope, not that i'm aware of
[08:21] <ogra_> hmm ... unless ...
[08:21] <ogra_> ask the security team, they might have tightened apparmor rules
[08:22] <ogra_> thats the only thing that comes to mind
[08:22] <tvoss_> ogra_, for some weird reason, when Mir tries to access the framebuffer, we see ENOMEM in ptrace
[08:22] <tvoss_> ogra_, thanks for the hint
[08:24] <ogra_> tvoss_, oh, there were also apparmor kernel changes now that i think of it, but i dont think xnox has rebuilt the android package for them yet
[08:24] <ogra_> might be that something is out of sync there
[08:25] <xnox> ogra_: ack.
[08:25] <tvoss_> ogra_, thanks
[08:39] <mzanetti> tvoss_: jenkins doesn't come up again after a restart. I fear we need to live without it for the next couple of hours until some of our jenkins experts are online
[08:40] <tvoss_> mzanetti, thx
[08:41] <didrocks> tvoss_: maybe ask gema? her team should have some people for this kind of production issue?
[08:49] <alan_g> hikiko: welcome back. Good break?
[08:50] <hikiko> hi alan_g :) yes it was nice!
[08:52] <alan_g> hikiko: Are you caught up yet? We landed some nested mir stuff while you were away and more is waiting for review: https://code.launchpad.net/~alan-griffiths/mir/native-platform/+merge/180618
[08:52] <hikiko> let me get a look at it :)
[08:55] <alan_g> hikiko: Once you've done that we should plan the next steps together.
[08:59] <hikiko> alan_g, you merged the nested-display branch and you added the NestedGbmPlatform isn't it?
[09:00] <Saviq> tvoss_, oh, interesting find (re ENOMEM)
[09:01] <alan_g> hikiko: *Native*GbmPlatform (and NativeAndroidPlatform)
[09:02] <tvoss_> Saviq, yup, that was the only thing that was hinting to an issue
[09:04] <hikiko> sorry that's what I meant I am pulling :)
[09:19] <tvoss_> didrocks, can you give https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing a try on the ati machine
[09:20] <didrocks> sil2100: ^
[09:21] <didrocks> tvoss_: weird that RAOF told me that latest trunk may fix it
[09:21] <didrocks> as it's not merged yet
[09:21] <sil2100> ;/
[09:21] <didrocks> so we will need a ppa + rebuild
[09:21] <sil2100> ;\
[09:21] <RAOF> didrocks: That's another possible fix.
[09:21] <didrocks> sil2100: handling that?
[09:22] <didrocks> sil2100: maybe take latest mir trunk + merge that
[09:22] <didrocks> and push to a ppa
[09:22] <didrocks> once built, push u-s-c there
[09:22] <didrocks> and we can then just test installing from the ppa?
[09:34] <sil2100> Ok
[09:49] <duflu> Hmm, I could return to trying to figure out test case side-effects and whether they're important...
[09:50] <duflu> ... or I could finish early and work on preparing a healthy meal
[09:50] <duflu> Right then
[09:51] <hikiko> alan_g, when I build trunk
[09:51] <hikiko> I get this:
[09:51] <hikiko> make[2]: *** No rule to make target `/usr/lib/libboost_chrono.so', needed by `lib/libmirclient.so.1'.  Stop.
[09:51] <hikiko> although I have libboost-chrono-dev installed
[09:52] <alan_g> hikiko: your cmake cache is out of date with saucy
[09:52] <alan_g> delete it and run cmake again
[09:52] <hikiko> but I just did bzr branch lp:mir :s
[09:52] <hikiko> ok
[09:52] <hikiko> I will try
[09:53] <alan_g> hikiko: that's odd then
[09:54] <alan_g> hikiko: are you using any ppas?
[09:54] <Saviq> greyback, oh, tricky... webbrowser creates a separate surface it seems
[09:55] <Saviq> greyback, and it gets rejected
[09:55] <greyback> Saviq: quite likely, as the webprocess separate. Good catch...wonder how to work-around
[09:55] <Saviq> greyback, indeed
[09:56] <hikiko> alan_g, mir-team/staging/ubuntu and http://ppa.launchpad.net/phablet-team/ppa/ubuntu
[09:57] <Saviq> greyback, it feels like unity8 starts faster with Mir, are you seeing the same?
[09:57] <greyback> Saviq: hud is disabled :)
[09:57] <Saviq> lol
[09:57] <greyback> must re-enable it
[09:57] <hikiko> alan_g, I am dist-upgrading maybe that will solve the problem, I didn't upgrade for 10 days or more
[09:57] <Saviq> greyback, desktop hint → happroved
[09:58] <greyback> Saviq: thanks.
[09:58] <alan_g> hikiko: you shouldn't need the ppas as everything ought to be in the distro
[09:59] <hikiko> ok, I ll remove them and try again, thanks!
[10:21] <hikiko> alan_g, the branch looks good but shouldn't we call the NativeGbmPlatform NativeGBMPlatform to match the GBMPlatform? could I rename it?
[10:22] <alan_g> hikiko: we should, but as alf__ top-approved without that tweak we can do it in a future MP (it only affects a couple of lines in a .cpp we need to change anyway)
[10:26] <alan_g> hikiko: you building OK now?
[10:27] <hikiko> yes alan_g
[10:27] <hikiko> after upgrading everything is fine
[10:49] <Saviq> tsdgeos, hey, I might take over QDesktopServices::openUrl from you, interested?
[10:49] <tsdgeos> Saviq: all yours, i'm doing some unit/auto/something-tests for greyback
[10:50] <Saviq> tsdgeos, yup, know that
[10:50] <Saviq> tsdgeos, any quick pointers where I should put that in (e.g. the DBus service backing it)?
[10:51] <tsdgeos> Saviq: tbh not sure what's needed, so we want QDesktopServices::openUrl to do what? open the appropiate app for that url? do we have such system in place?
[10:52] <Saviq> tsdgeos, a preliminary one, yes
[10:52] <tsdgeos> and that's going to call ApplicationManager::startProcess or something unrelated to start the app?
[10:52] <Saviq> tsdgeos, https://launchpad.net/url-dispatcher
[10:53] <Saviq> tsdgeos, upstart
[10:53] <tsdgeos> Saviq: ok, why not ApplicationManager::startProcess? it needs to have upstart support afaics from the comments
[10:53] <tsdgeos> may as well have the upstart code only once?
[10:53] <Saviq> tsdgeos, yeah, it seems url-dispatcher is a self-contained thing now
[10:54] <Saviq> tsdgeos, will talk to tedg on that later
[10:56] <tsdgeos> Saviq: i would understand that it should go in unity-mir, probably
[10:56] <Saviq> tsdgeos, yeah, that's for sure
[10:56] <tsdgeos> not sure which class exactly
[10:57] <tsdgeos> i don't think ApplicationManager is a bad place
[10:57] <tsdgeos> but gerry may disagree
[10:57] <Saviq> tsdgeos, we agreed on that before already
[10:57] <greyback_> fine with me
[10:57] <tsdgeos> ah, did we?
[10:57] <tsdgeos> :D
[10:57]  * tsdgeos can't read lately
[10:58]  * greyback_ rebooting as Mir seems to freeze his machine
[10:59] <greyback_> alan_g: ping
[10:59] <alan_g> greyback_: hello
[10:59] <greyback_> alan_g: hey there, I need some advice from you
[11:00] <greyback_> alan_g: I am trying a simple unity-mir server on my desktop. Something is not happy, as when running it, my machine's graphics completely hangs. I can ssh in, but could you give me tips on how to debug?
[11:01] <mlankhorst> does ssh work?
[11:01] <greyback_> mlankhorst: yes
[11:02] <greyback_> I suppose catching output into a file is necessary for a start
[11:02] <greyback_> alan_g: also, if using XMir, would my Mir instance with XMir collide? (I've disabled xmir)
[11:02] <alan_g> greyback_: I usually try running from an ssh session so that I can see errors. (and maybe turning on some logging)
[11:03] <alan_g> greyback_: yes, we don't have nested mir sessions working yet
[11:03] <greyback_> alan_g: ack
[11:04] <greyback_> alan_g: any way to confirm xmir not running?
[11:05] <alan_g> greyback_: I'm the wrong one to ask (I have never enabled it)
[11:05] <greyback_> alan_g: ok, thanks
[11:06] <alan_g> greyback_: I'd guess there's be a u-s-c process running (but I don't actually know)
[11:06] <Saviq> greyback|unstabl,  lp:platform-api/mir is merged into lp:platform-api already?
[11:08] <greyback|unstabl> Saviq: yes
[11:08] <Saviq> greyback|unstabl, good, thanks
[11:08] <greyback|unstabl> Saviq: same with qtubuntu
[11:10] <greyback|unstabl> alan_g: ever got this exception: "Failed to mute keyboard" when launching over ssh? Would it be that I'm sshing into my primary machine (that I'm typing this on)
[11:12] <alan_g> greyback|unstabl: yeah, sounds like X owns the keyboard. You need to be in a VT (and tell your server which one with --vt)
[11:12] <greyback|unstabl> alan_g: aha, --vt! Thanks
[11:13] <alan_g> greyback|unstabl: ./mir_demo_server --help is wonderful
[11:18] <tsdgeos> greyback|unstabl: how do i "stop" a QMirServer?
[11:18] <tsdgeos> it seems that returning from the function i pass to runWithClient is not enough
[12:49] <kgunn> alf__: hey...nice job on mm...
[12:53] <alf__> kgunn: thanks, did you try it out?
[12:54] <kgunn> alf__: not yet....was just looking at what landed while i was out....
[12:54] <kgunn> alf__: and what new problems we have :)
[13:52] <kgunn> tvoss|lunch: so are we able to pilot https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801 on didrocks machine? (sorry if this is old news)
[13:54] <tvoss|lunch> kgunn, I think sil2100 did
[13:55] <kgunn> sil2100: how many successful runs? i only ask because this is a heisenbug....i know didrocks got 10 in a row once
[13:55] <kgunn> with the "current failing config"
[14:02] <tvoss_> didrocks, got an update on https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801
[14:03] <didrocks> tvoss_: as you told, sil2100 is on it
[14:03] <didrocks> I didn't got any update since, he had some issue with his ppa, then I think he copied to another one but didn't get feedback
[14:03] <didrocks> let's wait for him :)
[14:09] <sil2100> didrocks: running the tests, but so far no failures - but no many tests have passed yet
[14:10] <didrocks> if 2 tests pass, we're fine TBH
[14:10] <didrocks> sil2100: you will rerun it then?
[14:10] <didrocks> (hum, aren't we at next tick though?)
[14:10] <didrocks> still 30 minutes until the first stack starts I guess
[14:10] <sil2100> I know ;p
[14:11] <sil2100> uuuu
[14:12] <sil2100> didrocks: hmmm
[14:12] <sil2100> didrocks: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console
[14:12] <sil2100> didrocks: looks to me like 'it' ;/
[14:12] <sil2100> didrocks: since it seems that it stopped on the opengl
[14:12] <sil2100> kgunn: ^
[14:13] <didrocks> right
[14:13] <didrocks> tvoss_: ^
[14:13] <didrocks> sil2100: we'll need to free it for production in some minutes (reboot electrically directly the machines to avoid having next test failing)
[14:14] <didrocks> sil2100: let's wait a little bit to see if kgunn/tvoss have a chance to get to it
[14:15] <sil2100> Ok
[14:24] <sil2100> tvoss_: ?
[14:24] <sil2100> didrocks: I guess we might have to reset the machine?
[14:24] <kgunn> sil2100: didrocks ...can we get another opportunity to build in the patch
[14:24] <didrocks> sil2100: agreed
[14:24] <kgunn> from RAOF http://paste.ubuntu.com/5983202/
[14:25] <kgunn> understanding this might be a while
[14:25] <didrocks> kgunn: IIRC, this one was already tried
[14:25] <didrocks> kgunn: without any success
[14:25] <kgunn> didrocks: its not a solution...
[14:25] <kgunn> its debug
[14:25] <didrocks> yeah, we tried it
[14:25] <didrocks> and couldn't get any blocking situation
[14:25] <didrocks> (after 20 runs)
[14:26] <didrocks> damn heisenberg… :p
[14:26] <kgunn> didrocks: oh...the debug patch changes timing...
[14:26] <kgunn> ug
[14:26] <didrocks> right :/
[14:27] <kgunn> didrocks: sil2100 ...can you at least grab the logs off it before rebooting
[14:28] <didrocks> sil2100: mind doing that? see the logs I attached to the bug and paste the same
[14:28] <didrocks> sil2100: just log into the container and installs pastebinit
[14:28] <didrocks> it's the easiest
[14:28] <didrocks> sil2100: can help you if needed (but in meetings)
[14:29] <sil2100> Doing ;)
[14:29] <sil2100> Looking at the bug first
[14:35] <sil2100> kgunn, tvoss_: attached the logs to the bug as a comment
[14:35] <kgunn> sil2100: thank alot
[14:36] <sil2100> didrocks: would it be enough if I just restart the machine through ssh?
[14:36] <tvoss_> sil2100, thx
[14:37] <didrocks> sil2100: yeah
[14:37] <sil2100> didrocks: do I have to detach the lxc containers first or nothing needed ;p ?
[14:37] <didrocks> sil2100: no no, it's fine
[14:38] <didrocks> sil2100: just reboot outside the container though :p
[14:38] <didrocks> or you just shut down the container then :p
[14:38] <sil2100> Rebooting normally then, thanks ;) I prefer to double-ask with fragile things
[14:40] <tvoss_> sil2100, does not look like anything failed judging from the logs
[14:41] <sil2100> tvoss_: didn't paste in compiz logs, but it's the same as before - it's stopping on loading the opengl plugin
[14:42] <tvoss_> sil2100, ah, what was the error message again?
[14:44] <sil2100> tvoss_: no error message really, just this from compiz, as seen in this comment: https://bugs.launchpad.net/mir/+bug/1204939/comments/11
[14:45] <kgunn> Saviq: confirmed with alan_g ....current mir worked on old image....so, makes me wonder if we updated android trees or move kernel
[14:45] <kgunn> more so than i did
[14:45] <Saviq> kgunn, right
[14:46] <kgunn> Saviq: even better...alan_g says old mir fails on new image
[14:46] <Saviq> ricmm, hey, wanted to ask, where should put the platform api part of QDesktopServices::openUrl()?
[14:47] <ricmm> Saviq: I need more context
[14:47] <Saviq> ricmm, it'll effectively be just a DBus call to AppManager
[14:47] <tvoss_> sil2100, so it segfaults?
[14:47] <Saviq> ricmm, that will ask it to open the url provided
[14:47] <alan_g> kgunn: Saviq - alf__ tried an old mir on the new image
[14:48] <sil2100> tvoss_: hm, hard to say this time, I would assume yes but it says nothing in the logs: jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console
[14:48] <sil2100> tvoss_: scroll down to the bottom and try finding compiz init phase
[14:49] <tvoss_> sil2100, I get an error accessing https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console
[14:49] <sil2100> hm, then maybe http://10.97.0.1:8080/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console <- with VPN access
[15:11] <racarr_> Morning
[15:20] <alan_g> afternoon
[16:17] <kgunn> racarr_: ping
[16:19] <kgunn> so wrt "mir doesn't  work on n4"...the current belief is that its a um/km out of sync issue....
[16:19] <kgunn> looks like at ~1:30 today there will be a 19.2 image available (where all will be resync'd)
[16:20] <kgunn> racarr_: so basically....save beating your head on the n4 mir thing until then....&
[16:20] <kgunn> hopefully it will just be corrected by the image creation...can you test that this afternoon ??
[16:20] <racarr_> kgunn: um/km?
[16:20] <racarr_> I definitely can! and that's
[16:20] <kgunn> user mode/kernel mode
[16:20] <racarr_> good to hear
[16:20] <racarr_> oh ok
[16:20] <racarr_> yes that
[16:20] <racarr_> seems really feasible
[16:21] <racarr_> it was getting absurd on friday when I was trying to figure it out :p
[16:21] <kgunn> racarr_: yeah...sounds like it was android um as well as ubuntu um code that was outta whack
[16:21] <kgunn> at least ogra seems to be strongly thinking the same
[16:22] <ogra_> err, not exactly :)
[16:22] <ogra_> apparmor userspace and kernel got updated ... but the kernel didnt make it into the images yet, so something *could* be out of sync
[16:23]  * ogra_ never said "strongly" ... it was just the best guess i could make on the situation you guys hit 
[16:24] <racarr_> ogra_: It might not be possible for it to be that...I think I tried
[16:24] <racarr_> to unload apparmor
[16:24] <racarr_> but im not confident I did it correctly so or the mismatch could have made that
[16:24] <racarr_> incorrect
[16:24] <racarr_> so I will test the image
[16:24] <ogra_> with luck the fix made it into 19.1
[16:24] <ogra_> it will definitely make 19.2 though
[16:25] <ogra_> (which starts building at 20:00 UTC ... so should be available in a few hours)
[16:25] <ogra_> racarr, to do it right you need to disable apparmor on the kernel cmdline
[16:26] <ogra_> (apparmor=0 iirc)
[16:26] <racarr> ogra_: Ah ok
[16:26] <racarr> It sounds pretty feasible
[16:26] <racarr> :)
[16:31] <kgunn> ogra_: "updated kernel"....so besides apparmor...there are other updates to the kernel ?
[16:32] <ogra_> kgunn, https://launchpad.net/ubuntu/saucy/+source/linux-mako/3.4.0-3.20
[16:35] <ogra_> and as i said above ... i was only guessing, not sure it is actually your issue
[16:51] <ogra_> kgunn, racarr: http://paste.ubuntu.com/6003505/ these are two scripts that help with manipulating the kernel cmdline on touch images
[16:52] <ogra_> so just try appending the apparmor=0 and see if it helps
[17:04] <robotfuel> it looks like 3d acceleration broke on nouveau starting on friday, for regular x as well.
[17:24] <racarr> finally have time to do powermangement
[17:24] <racarr> it seems maybe dpms_mode is a member of
[17:24] <racarr> MirDisplayOutput
[17:24] <racarr> ?
[18:11] <tvoss> racarr, ping
[18:55] <racarr> tvoss: pong
[18:55] <racarr> Was lunching :)
[18:56] <tvoss> racarr, cool, just wanted to say that I'm around to help out with the nexus 4 issue
[18:57] <racarr> tvoss: The rumor is that it could be a kernel space userspace mismatch for apparmor
[18:57] <racarr> so waiting on new images to build
[18:58] <racarr> where the rumor was they would build around 1:30 today
[18:58] <tvoss> ack, in ~1.5 hours from now, right?
[18:58] <racarr> Yeah
[19:00] <racarr> ill try ith apparmor=0 right now :)
[19:02] <racarr> Hmm it doesn't work :(
[19:02] <racarr> ogra_: ^ :(
[19:02] <racarr> I think I ill wait for the new images though to do anything more here
[19:43] <kgunn> racarr: can you elaborate on "doesn't work" ??
[19:44] <racarr> kgunn: I mean with apparmor=0 nothing changes
[19:45] <kgunn> racarr: meaning our theory is busted ?
[19:45] <racarr> kgunn: Probably!
[19:45] <racarr> but it could be something else with the kernel
[19:45] <racarr> or maybe something can someho load apparmor later, and something fishy
[19:46] <racarr> so I have decided to work on DPMS and wait for the new image
[19:46] <racarr> to know for sure
[19:50] <kgunn> racarr: for your next attempt...could you add a report of the egl error like so
[19:50] <kgunn> https://pastebin.canonical.com/96033/
[19:50] <kgunn> in android_framebuffer_window.cpp
[19:51] <kgunn> ...or something like that
[19:57] <racarr> kgunn: ok
[19:57] <kgunn> racarr: thanks...
[19:58] <racarr> Based on some other errors I think either the framebufer isnt' allocating
[19:58] <racarr> or some ioctl inside the driver to reference it is failing
[19:58] <racarr> so this might be useful
[20:05] <racarr> I may need to talk to alf before I can finish this DPMS stuff
[20:05] <racarr> I'm not sure we have theinfrastructure in place to apply display configuration changes without reallocating the scanout buffers
[20:05] <racarr> and don't want to step on things
[20:06] <racarr> That could also just be what happens in the first implementation of DPMS but that kind of
[20:07] <racarr> defeats the point I think
[20:08] <kgunn> racarr: kinda weird...i would
[20:08] <kgunn> 've thot that
[20:09] <kgunn> dps would've been more about cutting clocks to the display/gpu
[20:10] <kgunn> rather than messing with mem allocations....altho...maybe the system could save power on mem rails if it frees enoug ?
[20:11] <racarr> kgunn: Right, I just mean the way mir is set up
[20:11] <racarr> I was encoding the DPMS mode as part of the display configuration
[20:12] <racarr> which seems kind of correct
[20:12] <racarr> but when you apply a display configuration it rebuilds everything
[20:12] <racarr> which is correct for most other things you might ant to change.
[20:12] <racarr> but the DPMS settings dont change the layout or anything
[20:12] <racarr> so it just requires some reworking of the existing code
[20:13] <racarr> maybe I can figure it out today :)it's almost done though so I think syncing iwth alf in the morning might be a good plan
[20:13] <racarr> and back to nexus 4 soon
[20:13] <kgunn> racarr: gotcha....you're just trying to avoid triggering an unnecessary tear down
[20:14] <kgunn> alf__: ^ in case you read scrollback :)
[20:18] <racarr> kgunn: Yeah :)
[20:21] <racarr> I feel like today is the day for client focus notifications.
[20:22] <racarr> Back in 20 to switch to nexus 4
[20:39] <racarr> Nexus time
[20:41] <kgunn> bregma: robert_ancell ....well...gooogle....that was rude
[20:41] <robert_ancell> indeed!
[20:41] <robert_ancell> we're back
[20:43] <racarr> http://cdimages.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/ hot of the press ;)
[20:51] <robert_ancell> olli_, do we have a hangout for the CFT meeting?
[20:54]  * kgunn waits for word from racarr 
[20:55] <racarr> kgunn: Flash is alllmost done then takes a bit to install mir
[20:55] <racarr> fingers crossed
[20:59] <racarr> wow surface flinger took like 30 seconds to come up
[20:59] <olli_> robert_ancell, will add
[21:00] <olli_> robert_ancell, kgunn https://plus.google.com/hangouts/_/calendar/b2xpdmVyLnJpZXNAY2Fub25pY2FsLmNvbQ.miib2j0d57b9590jbd8dufi79c
[21:18] <tvoss> racarr, any new insights?
[21:21] <kgunn> tvoss: apparmor=0 didn't change the result
[21:22] <racarr> Also it's still broken on the new image :(
[21:22] <tvoss> racarr, okay, and you said that surfaceflinger is slow to start?
[21:23] <racarr> yes that's true it was really slow to start. I haven't tested that again
[21:23] <racarr> > 30 seconds to the point where I started trying to  investigate if it was broken
[21:23] <racarr> then it came up
[21:23] <racarr> Im building mir again now (actuallyd onloading 391mb of build dependencies to the phone woohoo)
[21:24] <racarr> then probing the egl errors
[21:24] <racarr> sometimes there have been errors about not being able to find an egl config
[21:24] <racarr> kgunn: Wait where did that
[21:24] <racarr> exception come from
[21:24] <racarr> I saw it once and was never able to get it again (went away after reboot)
[21:25] <kgunn> racarr: its the exception that alan documented in the bug
[21:25] <kgunn> my assumption was it was repeatable
[21:25] <kgunn> (or consistent)
[21:27] <racarr> kgunn:  not exactly I got that once
[21:27] <racarr> well
[21:27] <racarr> many times ina  row
[21:27] <racarr> but then when I rebooted it went back
[21:27] <racarr> to th same no errors except for the ioctl failures in strace
[21:27] <racarr> maybe once I build mir I will get that exception this time? :/
[21:27] <racarr> I dont get it from running mir_demo_server on the fresh image
[21:28] <racarr> also for me/tmp/mir_socket is created
[21:33] <racarr> clients
[21:33] <racarr> are stuck at half FPS
[21:34] <racarr> 1 FPS
[21:34] <racarr> 7 FPS
[21:34] <racarr> 26 FPS
[21:34] <racarr> 28 FPS
[21:34] <racarr> 29 FPS
[21:34] <racarr> 30 FPS
[21:34] <racarr> 30 FPS
[21:34] <racarr> not that anything shows up
[21:34] <racarr> oh wo I left one open for a while
[21:34] <racarr> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' what():  error posting with fb device
[21:45] <robert_ancell> robotfuel, oh you are here already :)
[21:45] <robotfuel> :)
[21:46] <robert_ancell> robotfuel, we'd like to verify https://code.launchpad.net/~vanvugt/mir/bypass/+merge/180503 against the test machines before landing it - what is the best way to do that?
[21:48] <robotfuel> robert_ancell: how do I test it?
[21:48] <robert_ancell> robotfuel, Would a PPA fit in with the test system?
[21:49] <robert_ancell> Otherwise it's just building from source
[21:49] <robert_ancell> The tests are the same as before - if you can run a session and run a GL app then it's good to go
[21:49] <robotfuel> robert_ancell: yes ppa's fit as long as ps-jenkins can see them.
[21:54] <robotfuel> robert_ancell: what ppa is it in?
[21:55] <robert_ancell> robotfuel, I'll set one up and email you the details
[21:55] <tvoss> racarr, kgunn which image is the latest that Mir is working with?
[22:00] <kgunn> tvoss: unsure...i'm guessing circa 2 weeks ago (based on the bug info)
[22:00] <kgunn> meaning 2 week old image
[22:01] <racarr> tvoss: Seems about right
[22:01] <racarr> maybe even ~1 week
[22:02] <kgunn> racarr: should we bisect ?
[22:02] <kgunn> images
[22:03] <racarr> kgunn: seems so...:(
[22:03] <racarr> ^Cphablet@ubuntu-phablet:~/src/trunk/build/bin$ sudo ./mir_demo_standalone_rendeto_fb
[22:03] <racarr> __pthread_gettid -2
[22:03] <racarr> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' what():  Could not unblank display
[22:03] <racarr> why does
[22:03] <racarr> it keep moving
[22:03] <racarr> phablet@ubuntu-phablet:~/src/trunk/build/bin$ sudo ./mir_demo_standalone_render_surfaces
[22:03] <racarr> __pthread_gettid -2
[22:03] <racarr> ERROR: /home/phablet/src/trunk/src/server/graphics/android/hwc_common_device.cpp(64): Throw in function mir::graphics::android::HWCCommonDevice::HWCCommonDevice(const std::shared_ptr<hwc_composer_device_1>&, const std::shared_ptr<mir::graphics::android::HWCVsyncCoordinator>&)
[22:03] <racarr> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
[22:04] <racarr> std::exception::what: Could not unblank display
[22:04] <racarr> [boost::errinfo_errno_*] = 1, "Operation not permitted"
[22:04] <racarr> even
[22:04] <racarr> more fascinating
[22:04] <kgunn> racarr: so basically new error code every time
[22:04] <kgunn> ?
[22:04] <racarr> well
[22:04] <racarr> it seems like new error code with new image
[22:04] <racarr> on this image so far it's consistent
[22:04] <racarr> well
[22:04] <racarr> ok so the mir from the archive ust silently fails
[22:04] <racarr> when I build mir it always fails with
[22:04] <racarr> "Could not unblank display"
[22:04] <racarr> operation not permitted
[22:05] <racarr> the first demo ust doesnt print the errno
[22:05] <racarr> always = always on this image
[22:06] <racarr> why
[22:06] <racarr> is root
[22:06] <racarr> not root
[22:06] <racarr> :p
[22:08] <racarr> of course now I reboot and its back to silently failing
[22:14] <racarr> kgunn: After reboot that error is now gone forever seemingly and it's back to failing silently
[22:15] <kgunn> racarr: what the what?...so consistently fails with no permission to blank display ....then fails silent ? (meaning just a hang, no exception thrown)
[22:17] <kgunn> racarr: well...bisecting will likely be better use of cycles i think
[22:17] <racarr> no hang
[22:17] <racarr> just nothing on screen
[22:17] <kgunn> racarr: got it...(sorry misuse of the word hang)
[22:18] <kgunn> racarr: what happens if you try a demo client in that state ?
[22:19] <racarr> nothing
[22:19] <racarr> just the same half FPS stuff as before
[22:19] <racarr> the files in /usr/include/android/hardware
[22:19] <racarr> the headers
[22:19] <racarr> are significantly different than the files in 3rd-party/android-deps
[22:19] <kgunn> racarr: but at least, the client can get an egl context and render to the fb
[22:19] <kgunn> ?
[22:20] <racarr> kgunn: Seemingly it can
[22:20] <racarr> but nothing happens
[22:20] <racarr> I assume there are the same strace errors there were on the last image with the ioctl failing
[22:20] <kgunn> eeeewwww....header changes huh
[22:20] <racarr> maybe
[22:20] <racarr> maybe libhardware itself changed
[22:21] <racarr> or maybe this is normal and the files in android-deps are magical I don't really know the
[22:21] <racarr> story around them
[22:21] <racarr> digging
[22:21] <kgunn> racarr: actually this is what i was fearing...that egl/hwc/fb glue we can't see possibly changes
[22:21] <kgunn> changed
[22:22] <tvoss> kgunn, we can see all of the glue
[22:22] <kgunn> tvoss: you have egl & hwc implementations ?
[22:23] <racarr> libhardware itself is open afaik
[22:23] <tvoss> kgunn, racarr exactly
[22:23] <robotfuel> robert_ancell: this is blocking nexuiz from running on nvidia and radeon https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1214030
[22:24] <racarr> I'm not sure im interpreting things right
[22:24] <robert_ancell> robotfuel, ta
[22:24] <racarr> but it seems like if these headers are out of sync, they have been for ages
[22:24] <racarr> so it seems to not matter
[22:24] <racarr> what do the different headers mean then
[22:24] <tvoss> racarr, are we building against libhardware?
[22:25] <robotfuel> robert_ancell: do I need to make that bug public or can you see it?
[22:25] <robert_ancell> robotfuel, I can see it - any reason not to make it public?
[22:25] <racarr> tvoss: Oi, mir is
[22:26] <racarr> but it has it's own headers in 3rd-party/android-deps
[22:26] <kgunn> tvoss: racarr ....sure, there is an open source impl...but what about vendor blobs ?
[22:26] <robotfuel> robert_ancell: not that I am aware of, I guess apport does that by default.
[22:26] <tvoss> racarr, so which headers do we pull into the build?
[22:26] <racarr> tvoss: For mir we use the headers in 3rd-party/android-deps
[22:26] <kgunn> most vendors replace hwcomposer.cpp
[22:26] <racarr> seemingly, because I just copied the headers from /usr/include in to there
[22:27] <racarr> and it doesn't build anymore ;)
[22:27] <tvoss> kgunn, no worries, all good. It's only about symbols
[22:27] <tvoss> racarr, okay, and then we link against what? libhardware?
[22:27] <racarr> oi
[22:28] <tvoss> racarr, is that yes or no?
[22:28] <tvoss> :)
[22:28] <robotfuel> robert_ancell: there is also this bug that is blocking us from getting results on nvidia
[22:28] <robotfuel> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1214066
[22:28] <robotfuel> robert_ancell: it's a regression in regular x as well
[22:28] <racarr> tvoss: Yes
[22:28] <racarr> tvoss: We link against system libhardware but explicitly use the
[22:28] <racarr> in tree headers
[22:29] <tvoss> racarr, here we go ...
[22:29] <robotfuel> robert_ancell: benchmarks are timing out on nvidia because acceleration is non-existent or slow
[22:30] <tvoss> racarr, do we _link_ against libhardware on the ubuntu side or are we using hybris?
[22:31] <racarr> tvoss: Err,as far as I can see we are linking against the
[22:31] <racarr> hybris libhardware
[22:31] <tvoss> racarr, okay, even worse than
[22:31] <racarr> there is no hwcomposter.h in /usr/include
[22:33] <tvoss> kgunn, when is kdub back?
[22:33] <racarr> there is some series of macros preventing me from immediately seeing why this compile is faling XD but it's something about version defines/compatibility macros
[22:33] <racarr> this compile is when I tried to use the system headers
[22:33] <racarr> I think
[22:34] <racarr> if I could get a new
[22:34] <racarr> hwcomposer.h
[22:34] <racarr> it would work
[22:35] <kgunn> tvoss: sept2
[22:35] <tvoss> kgunn, really?
[22:36] <kgunn> really
[22:38] <rsalveti> racarr: which version of hwcomposer.h are you originally using?
[22:38] <rsalveti> tvoss: indeed, that's not part of the android-platform-headers
[22:38] <rsalveti> I can add it there, but I first want to check how different it is from our current hwcomposer.h from 4.2.2
[22:39] <tvoss> racarr, ^
[22:39] <racarr> rsalveti: see in lp:mir 3rd-party/android-deps/hardware
[22:39] <racarr> Phone sorry, will be back in 5 min with more info XD
[22:42] <racarr> ok
[22:42] <racarr> so...um. I guess I dont know
[22:42] <racarr> how to identify what version of hwcomposer.h it is
[22:42] <racarr> or why we use these in tree headers
[22:42] <racarr> is it legacy only? or is there another reason
[22:43] <rsalveti> racarr: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_hardware_libhardware.git;a=tree;f=include/hardware;h=139b8bb682030607ffea03beca691ef877a5e794;hb=refs/heads/phablet-saucy
[22:43] <rsalveti> this is the one we're using at our android images now
[22:44] <kgunn> hwcomposer_defs.h changed as well
[22:44] <kgunn> racarr: ^
[22:44] <racarr> yeah
[22:44] <racarr> rsalveti: Ok thanks. I am going to see if I can get mir to compile
[22:44] <racarr> against these headers
[22:45] <rsalveti> racarr: tvoss: http://paste.ubuntu.com/6004566/
[22:46] <rsalveti> comparing the headers, nothing really critical
[22:46] <rsalveti> only difference is removal of HWC_BLIT
[22:46] <racarr> rsalveti: Err, ok so these
[22:46] <racarr> aren't the headers
[22:46] <racarr> that are in /usr/include/android
[22:46] <racarr> on the device
[22:46] <racarr> the diff there is much larger
[22:47] <rsalveti> racarr: there's no hwcomposer.h in there
[22:47] <rsalveti> that's why I'm comparing with what got changed in the android side
[22:47] <rsalveti> to see if the headers inside mir would need any sort of update
[22:48] <rsalveti> racarr: what was the last known working image?
[22:48] <racarr> err
[22:48] <racarr> I had a hardware.h with a much larger difference
[22:48] <racarr> and no it wont build
[22:48] <racarr> rsalveti: No one knows. 2 weeks ago should be safe though
[22:48] <kgunn> rsalveti: yeah...but that addition of ifdef qcom hw adds an int right in the middle of a hwc struct
[22:48] <kgunn> that's used for hwframebuffer
[22:49] <rsalveti> right, can't we get someone to trace that based on the ones available in http://cdimage.ubuntu.com/ubuntu-touch/ ?
[22:49] <rsalveti> we got one from 12 there, would be nice to see if it works there
[22:50] <kgunn> racarr: can you test http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130812/
[22:50] <rsalveti> kgunn: right, but I don't think QCOM_HARDWARE is defined at all for nexus 4
[22:50] <rsalveti> iirc
[22:51] <tvoss> racarr, rsalveti off now, quite late here. kgunn, racarr can you guys send me a handover mail?
[22:51] <kgunn> tvoss: you bet
[22:51] <kgunn> rsalveti: really...? that would surprise me...isn't n4 qcom ?
[22:52] <racarr> tvoss: Ok
[22:52] <rsalveti> kgunn: it is, but iirc that define was cm specific for other qcom based devices
[22:52] <racarr> rsalveti: http://pastebin.ubuntu.com/6004587/
[22:52] <rsalveti> but would need to double check, and you can easily rebuild against the updated header to test as well
[22:52] <racarr> this is the diff I get when copying /usr/include/android
[22:52] <racarr> in to the android-deps
[22:52] <racarr> so where are
[22:52] <racarr> THESE files coming from?
[22:53] <racarr> using the files from github with the small diff didnt ork
[22:55] <racarr> interesting trivia: Cmake does not detect changes to the android-deps folder ;)
[22:55] <rsalveti> racarr: these are from libhybris, which originally came from our phablet git repos
[22:55] <rsalveti> but they were always different, that's why I'm not sure if this is indeed the cause
[22:55] <racarr> yes
[22:56] <racarr> thats hat the changelogs seemed to say to me too
[22:56] <rsalveti> tracing the last working image would be a better idea I guess
[22:56] <racarr> but I am double checking because hat else could it be
[22:56] <racarr> yeah...
[22:56] <racarr> kgunn: http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130812/
[22:56] <racarr> still ant me to test that one?
[22:57] <kgunn> racarr: i think that would help
[22:58] <racarr> ok
[23:08] <racarr> ok the thing is installing the PPA on this image will bring in other updates I guess so I have to
[23:08] <racarr> build mir again..
[23:12] <racarr> at this rate it will take like 1 hour per image
[23:12] <racarr> sigh
[23:20] <RAOF> Ah, vgdb. You're the best.
[23:25] <kgunn> racarr: sorry dude
[23:26] <kgunn> racarr: i do think you're on to something with the header deltas....
[23:27] <kgunn> gonna hop off to eat dinner..