[00:05] <robert_ancell> come on jenkins... land those merges
[00:18] <robert_ancell> kgunn, up for some Sunday Mir fun?
[00:39] <kgunn> robert_ancell: maybe...just kind of checking in
[00:39] <robert_ancell> kgunn, did you resolve your system compositor issues?
[00:39] <kgunn> nope....
[00:40] <robert_ancell> :(
[00:40] <kgunn> but realized i'm intel 64bit
[00:40] <kgunn> and know that was failing build
[00:40] <kgunn> (honestly i hadn't tried again due to that)
[00:40] <robert_ancell> kgunn, I'm amd64 here. It was i386 that was failing build, but that shouldn't affect you
[00:41] <kgunn> robert_ancell: why wouldnt it effect me ?
[00:41] <robert_ancell> kgunn, you should be using amd64 packages too right?
[00:42] <kgunn> robert_ancell: i guess i'm lost/my assumptions are wrong
[00:42] <kgunn> thot i would be on i386 packages
[00:42] <kgunn> ...e.g. on an intel core you can use amd64  ?
[00:42] <robert_ancell> kgunn, what does uname -a
[00:42] <robert_ancell> say?
[00:43] <robert_ancell> kgunn, yes, amd64 is the name for the 64 bit PC instruction set used in Debian (at least). Since AMD came up with it in the first place
[00:43] <robert_ancell> Might be the GNU name methinks?
[00:43] <kgunn> Linux kg-MacBookPro 3.9.0-7-generic #15-Ubuntu SMP Fri Jun 21 12:22:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[00:43] <robert_ancell> yep, you're using amd64 packages
[00:43] <robert_ancell> So i386 issues shouldn't affect you
[00:44] <kgunn> ah...so amd is just a leftover from the fact they did 64bit first
[00:44] <robert_ancell> yeah, and whoever picked the string for it :)
[00:44] <robert_ancell> Read amd64 == x86_64
[00:45] <kgunn> ok....so i386 means 32 bit, and amd64 means 64bit....(doesn;t follow the vendor)
[00:45] <robert_ancell> yeah
[00:45]  * kgunn files aways a new learning about ubuntu nomenclature
[00:46] <robert_ancell> We must have reached the tipping point - traditionally you had more trouble running amd64 Ubuntu, but now it's i386 having the issues :)
[00:46] <robert_ancell> And then it will be amd64 having the issues and armhf working the best :)
[00:46] <kgunn> robert_ancell: btw...i did try vt swtiching
[00:47] <kgunn> and it still complained about libboost...wanting 49 altho i'm on 53 w/ standard saucy
[00:47] <robert_ancell> so odd
[00:47] <kgunn> robert_ancell: i basically went thru and dpkg'd -s  every
[00:48] <kgunn> darn lib in the chain....all the depends...then i checked those depends
[00:48] <kgunn> none of them were depending on v49 boosts that i could see
[00:48] <robert_ancell> kgunn, did you try an apt-get remove --purge libmirserver0 and then reinstall?
[00:48] <kgunn> will try that...
[00:48] <robert_ancell> (don't think the purge will help but just in case)
[00:48] <kgunn> i actually wondered....
[00:48] <kgunn> i only did remove and no --purge
[00:49] <kgunn> so maybe....will try
[00:49]  * robert_ancell wishes the arm builders were faster
[00:50] <kgunn> while we're waiting...how's the kiddo
[00:50] <robert_ancell> takes 13 minutes just to start building
[00:50] <robert_ancell> kgunn, good, getting more alert every day
[00:51] <kgunn> robert_ancell: mom doing ok? recovering....
[00:51] <robert_ancell> kgunn, yeah, she recovered from the c-section super fast so all good there. A bit sleep deprived but doing ok :)
[00:52] <kgunn> that's great
[00:52] <kgunn> ....well the recovery part
[00:52] <kgunn> not the sleep deprivation part
[00:53] <RAOF> That bit's just the price of admission :)
[00:59] <robert_ancell> RAOF, it was in the fine print :)
[01:06] <robert_ancell> thomi, RAOF, this arm saucy build problem is a known thing right? https://launchpadlibrarian.net/143239191/buildlog_ubuntu-saucy-armhf.lightdm_1.7.3bzr1628saucy0_FAILEDTOBUILD.txt.gz
[01:07] <thomi> /usr/lib/arm-linux-gnueabihf/libEGL.so.1: undefined reference to `mir_egl_mesa_display_is_valid'
[01:07] <thomi> robert_ancell: looks to me like something in RAOF's dept. Not a problem I'm aware of
[01:10] <RAOF> robert_ancell: What PPA is that in? Mir wasn't building on armhf in the PPA for a good long while.
[01:10] <robert_ancell> RAOF, staging
[01:12] <RAOF> Awah?
[01:12] <RAOF> What's happening there?
[01:14] <RAOF> How has libegl1-mesa failed to pick up a dependency on libmirclient?
[01:16] <duflu> RAOF: It's blocked by https://code.launchpad.net/~vanvugt/mir/fix-1192908/+merge/170770
[01:18] <duflu> In fact, most of our PPA builds are blocked by that
[01:19] <duflu> Someone can unlock the build pipe with https://code.launchpad.net/~vanvugt/mir/fix-1192908/+merge/170770
[01:19] <duflu> :)
[01:19] <duflu> -unlock +unblock
[01:19] <robert_ancell> duflu, reviewing
[01:20] <robert_ancell> duflu, do we just need that to unlock and then can remove it?
[01:21] <duflu> robert_ancell, it will be needed so long as we ever intend to bump the soname of mirclient again
[01:21] <robert_ancell> i.e. once libmirclient.so.0 disappears
[01:21] <robert_ancell> yeah, just thought of that
[01:21] <RAOF> We should really split mirclient into a separate source.
[01:21] <duflu> robert_ancell, if you want a quick-fix then just modify the recipe for building Mir to not use Mir-Mesa
[01:21] <duflu> but regular Mesa instead
[01:21] <robert_ancell> RAOF, agreed
[01:21] <duflu> I totally disagree. There's too much overlap between the projects
[01:22] <duflu> You would also create a "shared" project, a "demos" project...
[01:22] <duflu> Too many
[01:22] <robert_ancell> duflu, well, demos should follow the mirclient source
[01:23] <robert_ancell> shared is a pita, agreed
[01:23] <duflu> robert_ancell, and then there's our tests which are client _and_ server in one :)
[01:23] <RAOF> As long as we can bootstrap from a non-Mir-enabled mesa I guess we don't strictly need a separate source.
[01:24] <robert_ancell> RAOF, if our changes go upstream we can't do that..
[01:24] <RAOF> Well, we kindof can.
[01:25] <duflu> I would actually prefer just going back to libmirclient.so.0 to match the version :)
[01:25] <RAOF> Everyone already has a mir-less mesa which they can use to build Mir, and then use that Mir to build a mir-full mesa.
[01:25] <RAOF> The bootstrap sucks a bit, but it's not *too* onerous.
[01:26] <robert_ancell> duflu, I don't get how the version is involved here
[01:27] <duflu> robert_ancell, the soname bump in r749 caused this problem
[01:27] <duflu> If we go back to zero then it is OK
[01:27] <duflu> But saucy will need a similar bootstrap to go back
[01:28] <robert_ancell> We need to be able to version our libraries properly
[01:28] <duflu> OK, and my proposal allows any number of future bumps
[01:28] <duflu> (with modification when we bump the ABI soname)
[01:29] <robert_ancell> yeah, we need to make +1 the versions in that case right?
[01:29] <duflu> Yes, add another symlink for each old version
[01:30] <duflu> I'm all for finding a nicer EGL-related solution. But can we please land something in the mean time? This FTBFS is holding me up, and the PPAs
[01:30] <RAOF> But the symlinks are lies, right?
[01:30] <robert_ancell> yes, me too
[01:30]  * RAOF is happy to temporarily unblock duflu 
[01:30] <robert_ancell> RAOF, yes, and there's no guarantee they will work if the ABI has broken majorly
[01:30] <kgunn> reboot
[01:30] <duflu> RAOF: Only lies to the binaries we run during build (tests)
[01:31] <duflu> And even then it's closer to the truth
[01:31] <RAOF> duflu: Right. But as soon as we change the ABI in a way that affects mesa those binaries will fail to run because of linker errors anyway.
[01:31] <duflu> They don't have to *work*
[01:31] <duflu> It just has to build
[01:31] <duflu> Because we link to the new version that *works*
[01:31] <duflu> And test cases do work. Because they now link to just one (right) version
[01:32] <RAOF> I don't see how?
[01:32] <duflu> RAOF: Mir's tests run against it's local binaries.
[01:32] <duflu> RAOF: Yes EGL clients will fail, but only until EGL is rebuilt
[01:33] <RAOF> None of Mir's tests link to EGL?
[01:33] <duflu> They fail right now
[01:33] <duflu> RAOF: Yes they do. libmirserver uses it. But not as an EGL client. So the important functionality is never used
[01:33] <duflu> Not as an EGL Mir client
[01:33] <robert_ancell> RAOF, damn, now I realise why you rebuild binaries on copy.  I need to rebuild u-s-c, what method are you doing for +build1? Just dput it up?
[01:34] <RAOF> robert_ancell: Correct, I just dput up a +build1 :)
[01:34] <RAOF> duflu: But loading EGL is going to cause the linker to try and resolve its symbols, right? If we've broken that ABI, the linker is still going to fail?
[01:35] <duflu> RAOF: Just to clarify - My fix forces the link to use the correct library (the new one). The symlink just pleases the runtime linker which has old links to version 0 from EGL
[01:35] <RAOF> ie: even if the tests don't use any Mir client EGL platform code, the Mir client EGL platform code still needs to access the symbols it needs.
[01:36] <duflu> RAOF: Only clients with indirect links to the old libmirclient.so.0 will fail. Not after Mesa is rebuilt
[01:36] <RAOF> duflu: Right; a mesa rebuild fixes everything no matter what we do.
[01:36] <duflu> RAOF: Right, but a Mesa rebuild will fail without my fix
[01:36] <duflu> And is failing
[01:37] <duflu> We need Mir to build successfully. And then that allows Mesa to build, finally
[01:38] <RAOF> I still don't see why a test-full build of Mir wouldn't fail under not-too-unlikely (but not current) circumstances with this hack, but I'm not unhappy to have this hack to unblock you.
[01:38] <duflu> Another possible solution is to avoid linking our test code to EGL. But that's difficult while libmirserver always needs it
[01:39] <duflu> RAOF: Look at the PPA build logs to see the errors it avoids
[01:40] <robert_ancell> kgunn, this message is always fun "No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):"
[01:40] <robert_ancell> Let me know if you need deciphering
[01:41] <RAOF> duflu: Right, and I think *this particular* ABI break doesn't break ABI in such a way that diverting the runtime linker from libmirclient0 to libmirclient1 will fail in the tests.
[01:42] <duflu> RAOF: Correct. Our tests don't need functioning Mir-EGL compatibility.
[01:42] <RAOF> duflu: But "functioning" is not the barrier we're trying to clear.
[01:43] <duflu> No. In fact, our tests technically should not depend on having a graphics head
[01:43] <duflu> So really should not depend on EGL in future
[01:43] <RAOF> duflu: The barrier we're trying to clear is ‘the dynamic linker will load libEGL’, and I'm pretty sure that we can break ABI in such a way that diverting libmirclient.so.x to libmirclient.so.(x+1) will result in the dynamic linker *not* successfully loading libEGL.
[01:43]  * robert_ancell -> lunch
[01:45] <RAOF> duflu: Anyway, I've approved that. Unblock away!
[01:45] <duflu> RAOF: The runtime linker only every loads the correct (new one). The hack is only to trick build-time linkage. Hence ABI breaks don't matter
[01:46] <duflu> The important thing is to link to the version of a library that you will use at run time. And we are doing that
[01:47] <duflu> If our acceptance-tests somehow become more dependent on having a working EGL head in future then we can tweak the tests
[01:47] <duflu> Though they do get a working EGL server. Only EGL clients fail till Mesa is rebuilt
[01:48] <RAOF> duflu: I don't the ‘ABI breaks don't matter’ bit is true? What happens when libEGL uses mir_foo_two from libmirclient.so.2, and we remove mir_foo_two in libmirclient.so.3? Getting the runtime linker to load libmrclient.so.3 instead of libmirclient.so.2 doesn't help, because it now fails to resolve mir_foo_two?
[01:48] <duflu> RAOF: We're not running the code that would refer to that missing symbol.
[01:48] <RAOF> Unless you're lazily resolving symbols that doesn't matter.
[01:49] <RAOF> We're not lazily resolving symbols, are we?
[01:49] <kgunn> robert_ancell: i caught that 2nd reference to ppa a moment ago myself (doh)
[01:49] <kgunn> i updated
[01:49] <kgunn> do i have to hit "request another review" or some such ?
[01:49] <duflu> RAOF: No lazier than the default ld.so behaviour
[01:50] <duflu> Which is lazy
[01:50] <kgunn> robert_ancell: back in a bit...family pressure to take an evening walk here...
[01:51] <RAOF> duflu: That might be the source of my confusion, then!
[01:51] <duflu> RAOF: ld.so is lazy unless you set LD_BIND_NOW
[01:52] <duflu> All said, if we can find a way to weaken the Mir/EGL coupling more elegantly then that's awesome
[02:44] <robert_ancell> no
[02:47] <duflu> ?
[02:48] <robert_ancell> no to kgunns last questions
[02:48] <robert_ancell> Not a general no
[02:49] <robert_ancell> duflu, though you get a no for running raring - we need to just support saucy. You can still use a raring desktop but your changes wont be tested against raring and packages wont be provided in the PPA
[02:50] <duflu> robert_ancell: That's fine. I test saucy too
[02:51]  * duflu wonders why we can't write software that's buildable with existing stable platforms, like the rest of the world does
[02:51] <duflu> Maybe the deb format is somewhat to blame
[02:53] <RAOF> duflu: Because we're trying to write the platform at the same time?
[02:53] <duflu> Yeah, that's a bad plan
[02:53] <duflu> Despite the fact it kinda works
[02:53] <duflu> Except when it does not
[02:55] <robert_ancell> RAOF, I need Mir >= 736 in the system-compositor PPA - what's the process to update?
[02:56] <RAOF> robert_ancell: I copy-with-binaries Mir from staging to the PPA, then rebuild u-s-c.
[02:56] <robert_ancell> RAOF, and what about everything else?
[02:57] <robert_ancell> We need a big lock on the PPA - Lock it; make all the changes; unlock :)
[02:57] <RAOF> Only things with a dependency on libmirserver0 need rebuilding, and that's just u-s-c.
[02:57] <robert_ancell> ok, cool
[02:57] <RAOF> robert_ancell: We can *kind* of do that - copy & build in a temporary PPA, then copy-with-binaries.
[02:58] <robert_ancell> yeah, I guess
[03:02]  * RAOF dislikes how adding a private non-virtual function to a class triggers a rebuild of everything :/
[03:03] <duflu> RAOF: Fair point but do you really want your trigger to try and make intelligent decisions based on code analysis. Relying on such is dangerous if it's wrong
[03:04] <RAOF> A different language design could remove that need entirely.
[03:20] <duflu> RAOF: D++? Go? :)
[03:23] <robert_ancell> RAOF, is this build not going to complete? i.e. should I just cancel it? https://launchpad.net/~mir-team/+archive/system-compositor-testing/+build/4741287
[03:25] <duflu> RAOF, robert_ancell: What project/package should we target XMir bugs at?
[03:26] <robert_ancell> duflu, whatever RAOF finds easiest. At the moment they're just against Mir
[03:26] <duflu> Yeah that's easy. But technically we should only do that where the bug is in lp:mir
[03:28] <robert_ancell> yep
[03:28] <RAOF> Indeed.
[03:28] <robert_ancell> It's kind of hard when we're not the upstream
[03:28] <RAOF> I don't really care where they end up.
[03:29] <RAOF> Oh, god. I'm going to need to write MockUdev to land this branch, aren't I?
[03:29] <RAOF> duflu: D++, Go, C#, whatever :)
[03:30] <RAOF> duflu: Maybe even C
[03:30] <RAOF> duflu: Maybe even C
[03:30] <RAOF> duflu: Maybe even C++-plus-a-module-RFC.
[03:33]  * RAOF needs an <enter> key not quite so close to ‘-’
[03:33] <robert_ancell> RAOF, that "indeed" refers to the i386 build?
[03:34]  * robert_ancell bets RAOF replies with "indeed"
[03:34] <RAOF> Incorrect!@
[03:34] <robert_ancell> RAOF, incorrect on my bet or the i386 build?
[03:35] <robert_ancell> CONTEXT ERROR CONTEXT ERROR
[03:35] <RAOF> ERECURSIVECTX
[03:35] <RAOF> That build is not going to finish.
[03:35] <RAOF> And the only bugs filed against the Mir project should be bugs in lp:mir.
[03:36] <RAOF> Also, needing to write MockUdev means that it's an excellent time for lunch!
[03:41] <duflu> Hmm... OK I'm just going to assume XMir will get fixed (if not already) and the bug is invalid for lp:mir [https://bugs.launchpad.net/bugs/1192957]
[03:56] <duflu> RAOF: Would it help in any way to move struct defs like MirMesaEGLNativeSurface into Mesa? I'm not sure it would [MirMesaEGLNativeSurface]
[03:57] <duflu> [https://bugs.launchpad.net/mir/+bug/1192908/comments/2]
[03:57] <RAOF> duflu: That's fixed in Saucy; I haven't built a raring XMir, sorry.
[03:57] <RAOF> I'll upload one, just for you!
[03:57] <duflu> RAOF: That's OK I only use XMir on saucy :)
[03:57] <duflu> RAOF: No raring required there
[03:58] <duflu> RAOF: Oh, umm, seems I do have it installed. I wonder how necessary that is
[03:59] <RAOF> duflu: It won't load the xmir module unless you try to use it.
[04:00] <duflu> RAOF: Yeah I don't need XMir fixed for raring thanks
[04:00] <RAOF> Why am I not drinking a coffee?
[04:00]  * RAOF goes to remedy this.
[04:01] <duflu> ... although the person who logged the bug might be on raring (https://bugs.launchpad.net/mir/+bug/1192957)
[04:05] <duflu> RAOF: As XMir is a nice loadable module, can we not make it a nice separate deb package too?
[04:06] <duflu> Also, can anyone tell me what the changes are that we need in xserver-xorg-video-* ?
[04:09] <RAOF> duflu: The loadable module, yes. We also need core patches to make it work (such as the option handling, autoload, etc).
[04:09] <duflu> RAOF: Yeah I expected those core changes. But that's only a small part right?
[04:09] <RAOF> Yeah.
[04:10] <robert_ancell> RAOF, those core changes useful for upstream?
[04:10] <RAOF> duflu: The changes to xf86-video-* are basically 1) Don't open the drm device directly; get it from XMir, 2) Don't do any modesetting, 3) Hook up a couple of callbacks.
[04:10] <duflu> Ah OK
[04:10] <RAOF> robert_ancell: A small number, yes.
[04:10] <robert_ancell> RAOF, Have they been proposed?
[04:10] <RAOF> Not yet.
[04:10] <RAOF> Although I think I may have proposed all the bugfixy bits.
[04:10] <RAOF> I should check.
[04:11] <robert_ancell> X.org still uses mailing lists for patches right?
[04:11] <RAOF> Yes.
[04:12] <robert_ancell> *sigh*
[04:12] <RAOF> But mostly the patches are “add the -mir commandline option”, “add the xorgMir global switch”, “load the XMir module if xorgMir”, etc.
[04:12] <RAOF> There'll be a bunch of equivalent patches for XWayland, FWIW.
[04:13] <robert_ancell> RAOF, are those flags just ignored if the module isn't there?
[04:13] <RAOF> Not really.
[04:14] <RAOF> Because it doesn't really make sense to pass -mir but get a non-XMir server.
[04:14] <RAOF> They're entirely harmless if you don't pass -mir.
[04:15] <duflu> Great another major compiz/unity regression I need to figure out and report
[05:03] <robert_ancell> duflu, is this a related bug to the libmirclient one? https://launchpadlibrarian.net/143241855/buildlog_ubuntu-saucy-armhf.lightdm_1.7.3bzr1628saucy0_FAILEDTOBUILD.txt.gz
[05:03] <robert_ancell> Note in this case nothing is linking to libmirclient
[05:05] <robert_ancell> it looks almost like libEGL.so.1 is not linked against libmirclient
[05:06] <robert_ancell> RAOF, where is your mesa branch again?
[05:06] <RAOF> robert_ancell: github.com/RAOF/mesa
[05:11] <duflu> robert_ancell, looks like a separate issue sorry
[05:11]  * duflu runs to the shop
[05:15] <robert_ancell> RAOF, aha, libegl-mesa-dev doesn't depend on libmirclient-dev
[05:15] <RAOF> Does it need to?
[05:15] <robert_ancell> RAOF, it has mir headers in it
[05:15] <RAOF> Does it? Hm, ok.
[05:16] <tvoss> good morning :)
[05:16] <robert_ancell> tvoss, hello
[05:16] <tvoss> robert_ancell, hey there :) just checked: mir in the ppa for i386 is failing still, right?
[05:16] <robert_ancell> RAOF, in both lightdm and u-s-c libmirclient is not installed at all
[05:17] <robert_ancell> tvoss, yes, I was trying to find your branches :)
[05:17] <RAOF> robert_ancell: But that's right, isn't it? lightdm doesn't use mirclient, and u-s-c doesn't use mirclient.
[05:17] <robert_ancell> RAOF, yeah, but libEGL links against it
[05:17] <tvoss> robert_ancell, pushing them now, it's one branch that hopefully fixes the issues
[05:17] <robert_ancell> tvoss, gimme gimme gimme
[05:17] <robert_ancell> tvoss, fixed in mir?
[05:18] <tvoss> robert_ancell, ack, although I have to say that it really only shows up in the weird builder configuration
[05:19] <RAOF> robert_ancell: Yeah, and libEGL pulls in libmirclient1 *because* it links against it.
[05:19] <robert_ancell> RAOF, but not on arm it seems?
[05:19] <RAOF> Right, that's a WTF.
[05:19] <robert_ancell> Does this normally just get worked around because of the -dev dependency?
[05:19] <RAOF> Mesa doesn't (by default) have any headers that depend on Mir headers, though, so a dependency on libmirclient-dev is incorrect.
[05:20] <robert_ancell> RAOF, /usr/include/EGL/eglplatform.h according to my system
[05:20] <RAOF> robert_ancell: Behind a compile guard that's never defined.
[05:20] <RAOF> At least in client code.
[05:20] <RAOF> Although we could reasonably add that dependency.
[05:21] <robert_ancell> it might solve the immediate problem
[05:27] <RAOF> Eh, why not.
[05:27] <RAOF> It's not incorrect.
[05:27] <RAOF> Let me push that change...
[05:29] <tvoss> RAOF, duflu, robert_ancell we still have the local gmock version, and I think we are good to remove it
[05:29] <tvoss> or is there any reason we still carry it?
[05:31] <RAOF> Because google are crazymad, I think.
[05:31] <duflu> tvoss: Not sure, but someone should check certainly
[05:31] <RAOF> And by “crazymad” I mean “do not appreciate the position of a distribution”.
[05:36] <duflu> RAOF: What did Google do wrong?
[05:36] <tvoss> duflu, we have gtest installed in source in /usr/src/gtest
[05:36] <RAOF> duflu: Their basic stance for gmock (and gtest) is that you must include their source in your project and build them from that source during your build.
[05:37] <tvoss> RAOF, although we still have gmock as prebuilt package available
[05:37] <duflu> Hmm, why?
[05:37] <RAOF> duflu: Because they're paranoid about C++ ABI, #define subtleties, etc.
[05:38] <duflu> That's a fair point, but it's a problem they should let the distro own
[05:38] <RAOF> Exactly.
[05:39] <tvoss> robert_ancell, https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown
[05:43] <robert_ancell> RAOF, will you run that through the PPAs and make sure all the armhf builds work?
[05:46] <RAOF> robert_ancell: Sure.
[05:48] <duflu> Awesome. GPU hang
[05:49] <RAOF> Woo!
[05:49] <robert_ancell> RAOF, I checked the .deb for libegl1-mesa using dpkg -I and it does not depend on libmirclient. So shlibs is not working for some reason
[05:49] <robert_ancell> RAOF, I'll file you a bug
[05:49] <RAOF> robert_ancell: But only, as far as I can tell, on armhf.
[05:49] <robert_ancell> RAOF, yes
[05:49] <RAOF> Which is weird.
[05:49] <duflu> robert_ancell, https://bugs.launchpad.net/mir/+bug/1192908/comments/5
[05:50] <robert_ancell> duflu, but mesa has built, and it has Mir symbols in it. It's just shlibs in the debian packaging that doesn't think so
[05:51] <duflu> robert_ancell, OK so not directly related
[05:51] <duflu> But still both real issues
[05:52] <robert_ancell> yeah
[05:57] <tvoss> duflu, can you take a look at https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown/+merge/171017 and top-approve if you are fine with the changes?
[05:57] <robert_ancell> bye all
[06:00] <duflu> tvoss: Yeah sure. I will look at the transformation stuff this week too
[06:00] <tvoss> duflu, cool, but let's get started with caching it before we completely move it to the gpu
[06:00] <duflu> tvoss: Yes that's all I intended
[06:00] <tvoss> duflu, cool :)
[06:01] <duflu> Right now though I'm buried in Mir bug triage and testing
[06:01] <duflu> There shouldn't be this much...
[06:01] <tvoss> how do you mean?
[06:04] <tvoss> duflu, ?
[06:04] <duflu> tvoss: I mean just busy logging new serious bugs as I find them, and testing bugs for robert he wants to know they still exist
[06:05] <tvoss> duflu, ack
[06:06] <duflu> Argh! Now LP is broken
[06:06]  * duflu logs bugs against LP
[06:06] <tvoss> duflu, I'm encountering timeouts quite regularly with LP these days
[06:09] <duflu> tvoss: No, it's a really dumb bug: https://bugs.launchpad.net/launchpad/+bug/1194007
[06:10] <RAOF> Damnit! What the hell is my laptop doing?
[06:10] <duflu> RAOF: Busy fan? I have that
[06:11] <duflu> Maybe because https://bugs.launchpad.net/ubuntu-power-consumption/+bug/1194004
[06:11] <RAOF> Busy fan, 5 second delay on typing.
[06:12] <duflu> Also, the compiz config is corrupt. It won't let me enter a valid frame rate
[06:28] <duflu> RAOF: Mesa rebuild hiccups... configure: error: Package requirements (libdrm_radeon >= 2.4.45) were not met:
[06:39] <tvoss> duflu, we need https://code.google.com/p/googlemock/issues/detail?id=79 to get rid of the local gmock version
[06:43] <duflu> tvoss: Can't quite approve yet: https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown/+merge/171017
[06:44] <RAOF> Aha! Something was swap-thrashing.
[06:44] <duflu> RAOF: Yes, compiz... ?
[06:44] <tvoss> duflu, agreed on your comment, however, we are hit by this issue on the buildd's and I don't know any other easy fix to workaround it
[06:44] <RAOF> I don't *think* it was compiz. It might have been geary.
[06:44] <duflu> tvoss: "buildd"?
[06:45] <tvoss> duflu, the builders for ppa and archive
[06:45] <tvoss> duflu, that's why the i386 build of mir in the system-compositor-testing ppa fails
[06:45] <duflu> Hmm, kay. I'm just concerned we're not fixing the root cause and it will pop up on some other global
[06:45] <tvoss> duflu, or better: hangs
[06:47] <RAOF> The root cause would appear to be “Pre 2.6 kernels suck” :)
[06:48] <tvoss> RAOF, with Daniel abstaining, would you mind taking a look here: https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown/+merge/171017
[06:48] <tvoss> ?
[06:48] <duflu> tvoss: Top approved still
[06:48] <tvoss> duflu, ah :)
[06:48] <tvoss> RAOF, cancel my comment then :)
[06:48] <RAOF> tvoss: Sure. Was doing so before my machine entered swap-hell.
[06:48] <tvoss> RAOF, ah
[06:49] <duflu> RAOF: Oooh you mean (memory)-swap-thrashing and not (buffer)-swap-thrashing like I am seeing?.. :)
[06:50] <RAOF> duflu: Indeed. memory-swap-thrashing.
[06:51] <duflu> Thrashing of disks, not of framebuffers
[07:15] <duflu> Hmm is it right that lightdm.conf ignores comments and typos?
[07:25] <mlankhorst> RAOF: ping, can you accept xxv-intel and mesa in quantal/raring and precise-lts?
[07:25] <RAOF> mlankhorst: Sure. Could you give me another ping in an hour or so if I haven't done it by then?
[07:26] <tvoss> RAOF, mind uploading a new mir version to the sys-comp-testing ppa? the gflag fix just landed
[07:26] <mlankhorst> sure
[07:26]  * didrocks fights with this pthread issue on google-mock…
[07:27] <RAOF> tvoss: I'll wait until it's built in the staging PPA and then binary-copy it. That way it's easier to ensure that unity-system-compositor stays in sync.
[07:28] <tvoss> RAOF, yup :)
[07:29] <didrocks> RAOF: I'm starting to be out of options right now, did you fix some similar pthread issue regarding gtest? http://paste.ubuntu.com/5794746/
[07:30] <didrocks> we can see that google-mock defines -pthread twice, one before the .la, one after, so it should be fine
[07:31] <didrocks> I tried to add -L to standard path (which should be uneeded), using -lpthread in case we regresssed here in GNU gcc, and even adding intermediate -pthread flags
[07:31] <didrocks> no luck…
[07:33] <tvoss> didrocks, I think it fails to link the internal gtest version
[07:33] <didrocks> tvoss: yep, exactly
[07:33] <tvoss> didrocks, wouldn't it be a better idea to link against our gtest version anyways?
[07:33] <RAOF> didrocks: Urgh. That doesn't look like fun.
[07:34] <RAOF> We don't have a gtest binary.
[07:34] <didrocks> tvoss: what RAOF told ^ :)
[07:34] <didrocks> (+ the unfun part as well :p)
[07:35] <RAOF> didrocks: Did I fix that in gtest before? I don't recall if I did :/
[07:36] <didrocks> RAOF: no, it was just in case you did get that somewhere into saucy by any luck
[07:37] <RAOF> No, I haven't noticed that before.
[07:37] <didrocks> ok, I'll continue digging
[08:01] <RAOF> Baby time!
[08:01] <didrocks> tvoss: ok, I'm out of any clue TBH, and seb128 spending some time last week on this unsuccessfully compensated a little bit the depressing feeling I started to get :)
[08:04] <tvoss> didrocks, looking
[08:17] <mlankhorst> RAOF: ping ;)
[08:23] <duflu> Me joins the queue to talk to RAOF [https://launchpad.net/~mir-team/+archive/staging/+build/4741584]
[08:23]  * duflu does too
[08:26]  * mlankhorst hopes it's a fifo, not a stack
[08:31]  * duflu push_front
[08:34] <tvoss> didrocks, is it a good idea to rely on the deprecated autotools setup?
[08:34] <didrocks> tvoss: can you be more explicit? :)
[08:35] <tvoss> didrocks, the gmock source package does not use the cmake setup
[08:35] <tvoss> didrocks, but uses the auto* setup
[08:35] <didrocks> tvoss: ah, you are calling the whole "autotools" deprecated
[08:36] <tvoss> didrocks, yeah, the setup is discouraged by google iirc
[08:36] <didrocks> can we stop using that "deprecated" tool for anything? it's still used by the vast majority of free software
[08:36] <didrocks> I would like we more concentrate on where we are going than downsiding a bunch of technologies…
[08:36] <didrocks> that worked for years
[08:37] <didrocks> I don't care about autotools vs cmake in particular, just that extra word was uneeded at least…
[08:37] <didrocks> tvoss: to come back to the subject, we are using what upstream is using
[08:38] <didrocks> so we can switch to cmake as they ship both
[08:38] <seb128> didrocks, they have both in there, I think tvoss was suggesting that the gmock guys recommend using the cmake build
[08:38] <didrocks> I would appreciate if we switch to them to send the patch to debian as well
[08:38] <seb128> I pondered trying that to see if that fixes the build the other day
[08:38] <seb128> but my cmake foo are not that great ;-)
[08:39] <didrocks> seb128: it still doesn't explain the linking issue, but if by change this is not impacted :)
[08:39] <didrocks> at least, maybe --enable-external-gtest will be picked
[08:39] <didrocks> (which isn't the case I guess because of Makefile.am)
[08:40] <tvoss> didrocks, why do we ship gmock different than gtest btw? gtest installs to /usr/src, which works just fine for us
[08:40] <tvoss> or am I missing something?
[08:40] <didrocks> tvoss: because the package comes from debian?
[08:40] <tvoss> didrocks, does gtest come from debian, too?
[08:40] <didrocks> IIRC, we did ourselves the gtest package
[08:41] <didrocks> let me check
[08:41] <didrocks> hum, it was remerged
[08:41] <didrocks> tvoss: different maintainers
[08:42] <didrocks> tvoss: we should standardize in a path and send the patch to debian I guess
[08:42] <tvoss> didrocks, okay, why not have /usr/src/gmock, then?
[08:42] <didrocks> tvoss: if it makes things easier, I'm fine with it
[08:43] <didrocks> you don't want to ship binaries then?
[08:43] <didrocks> only the sources
[08:43] <didrocks> like for gtests and others…
[08:43] <tvoss> didrocks, it's way easier for cmake based projects, and we have magic to support autotools, too
[08:43] <tvoss> didrocks, yup
[08:44] <didrocks> tvoss: we don't have any reverse dependencies for google-mock, let me check for build-reverse-dep before a final ack
[08:44] <didrocks> tvoss: hum, we do have some though
[08:45] <didrocks> apart from rlvm, coming from us
[08:45] <didrocks> tvoss: http://paste.ubuntu.com/5794887/
[08:45] <didrocks> they need to be converted to rebuild google-mock I guess, and not relying on the .so or .la
[08:46] <tvoss> didrocks, hmmmm...
[08:46] <didrocks> rlvm was in sync with debian, so better to ship the patch to them as well
[08:46] <didrocks> (alongside the google-mock one)
[08:46] <duflu> tvoss: On the other hand... having gtest/gmock inline makes building on other distros much easier, if they don't have it :)
[08:47] <duflu> But you can argue that with all dependencies
[08:47] <tvoss> duflu, yup
[08:48] <didrocks> duflu: but it means that if there is a bug that you want to get fixed, you have to fix them in a bunch of different places :)
[08:48] <duflu> didrocks: Yeah, OK, inline is bad
[08:49] <duflu> Hmm, actually no, that's no a valid argument. Cos any issue that affects Mir will get fixed faster than distro.
[08:49] <duflu> +t
[08:49] <duflu> Arguably
[08:49] <didrocks> duflu: well, let's say that you have a pthread issue
[08:49] <didrocks> like now
[08:50] <duflu> We do?
[08:50] <didrocks> you have to fix it in 7 different projects
[08:50] <didrocks> yep
[08:50] <duflu> Fairy nuff
[08:51] <tvoss> didrocks, just built the source package manually with the autotools toolchain (no dpkg-buildpackage), works fine
[08:51] <didrocks> tvoss: right, because you don't use --as-needed I guess
[08:53] <didrocks> tvoss: even without it
[08:53] <didrocks> tvoss: did you run make check?
[08:54] <tvoss> trying
[08:57] <tvoss> RAOF, ping
[08:59] <mlankhorst> no!
[09:01] <tvoss> mlankhorst, ?
[09:02] <tvoss> mlankhorst, oh sorry, I need to go to the queue
[09:02] <mlankhorst> :D
[09:06] <tvoss> didrocks, fails in run make check. The interesting thing is that the tests shouldn't link to gtest as they have fused_src compiled in
[09:06] <tvoss> didrocks, I'm confused now
[09:07] <didrocks> tvoss: what's this fused_src?
[09:07] <tvoss> didrocks, it's all src and header files of gmock and gtest fusioned together by some python scripts
[09:07] <didrocks> copying all src into the same .o?
[09:07] <didrocks> interesting…
[09:08] <didrocks> tvoss: we can try to switch to the cmake version if needed
[09:08] <tvoss> didrocks, let me first try to understand what's going on :)
[09:08] <didrocks> no make check/make tests though
[09:09] <didrocks> tvoss: ok, I'll be out for a short bit, will be back later on :)
[09:09] <tvoss> didrocks, ack, need some breakfast, too
[09:09] <didrocks> enjoy!
[09:16] <tvoss> didrocks, thanks :)
[09:50] <duflu> tvoss: I can't see the magic 18% CPU. Maximum 6%
[09:50] <duflu> Any hints?
[09:50] <tvoss> duflu, 18% within that function
[09:51] <tvoss> duflu, I did a simple run with 1000 buffer swaps
[09:51] <duflu> tvoss: No, all transformation logic only adds up to 6%. And only 3% in the glm matrix library
[09:51] <duflu> I wonder what I'm missing
[09:51] <tvoss> duflu, weird
[09:51] <duflu> I did >66000 swaps
[09:52] <tvoss> let me see if I can find my results
[09:52]  * tvoss thinks that adding the respective callgrind logs to the bug reports would be a good idea
[09:52] <duflu> Same issue really, just that I get 6% instead of 18%
[09:52] <tvoss> duflu, do you think it's still worth fixing?
[09:53] <duflu> tvoss: Yes I think so
[09:53] <duflu> If we can gain it back easily
[09:53] <tvoss> duflu, okay, do you have the callgrind trace handy? if so, mind attaching it to the bug report, too?
[09:54] <didrocks> tvoss: hum, it seems the Mir licenses weren't updated when inlining new components in 3rd_party
[09:54] <tvoss> didrocks, mind filing a bug?
[09:54] <didrocks> tvoss: sure :) knowing the time I spent to fix it the first time, I would appreciate upstream then to file debian/copyright this time
[09:54] <tvoss> didrocks, sure
[09:57] <duflu> tvoss: Done
[09:57] <tvoss> duflu, thx
[09:57] <didrocks> tvoss: https://bugs.launchpad.net/mir/+bug/1194073, this is a prerequisite to have mir in distro
[09:57] <tvoss> didrocks, ack
[09:58] <didrocks> tvoss: do you know why we don't use cucumber from distro?
[09:58] <didrocks> (no cpp bindings?)
[09:58] <tvoss> didrocks, not sure, need to check with racarr
[09:58] <tvoss> didrocks, might well be that we are able to pull it out, too
[09:59] <didrocks> ancillary isn't in distro, so it's fine
[09:59] <didrocks> let me open bugs for them
[09:59] <didrocks> (gmock and cucumber)
[10:00] <tvoss> didrocks, gmock bug should be there
[10:00] <didrocks> tvoss: ok, let me add a tag to it
[10:00] <tvoss> didrocks, ack
[10:01] <didrocks> done
[10:01] <tvoss> duflu, do we have a performance tag?
[10:01] <tvoss> duflu, how about performance, performance-cpu, performance-gpu?
[10:01] <duflu> tvoss: It appears not. Just "performance" is OK
[10:01] <tvoss> duflu, ack
[10:02] <didrocks> tvoss: we don't run tests on armhf?
[10:04] <duflu> didrocks: We do during CI.
[10:04] <didrocks> duflu: any reason we don't do that in the ppa?
[10:04] <duflu> didrocks: No idea
[10:04] <RAOF> duflu: Ah. Mesa is too new to build on raring.
[10:05] <duflu> Ah dependency madness
[10:07] <duflu> Though Mir does spend all its time in boost::asio stuff
[10:07] <duflu> I might have to learn what that is
[10:09] <tvoss> duflu, where do you see that?
[10:09] <duflu> tvoss: In kcachegrind
[10:10] <duflu> The boost/asio call graph is so huge and complex I haven't quite figured it out yet
[10:26] <didrocks> tvoss_: mir_demo* are just technical demos, right? They can be combined to be used by another applications?
[10:27] <tvoss_> didrocks, right, only technical demos. we use them for benchmarking purposes, too
[10:27] <didrocks> tvoss_: I would add them in a examples/ directory rather
[10:28] <tvoss_> didrocks, we had that discussion before within the team
[10:28] <tvoss_> didrocks, or do you mean for the packaging?
[10:28] <didrocks> what was the outcome? do you have anything written you can share?
[10:28] <didrocks> tvoss_: for the packaging
[10:28] <didrocks> like usr/lib/<triplet>/mir/examples
[10:28] <didrocks> (I'm going to multiarch mir as well)
[10:29] <tvoss_> didrocks, @install: sounds sane, for the discussion: it was informal but I cannot even recall the conclusion
[10:29] <didrocks> same for mir_stress
[10:29] <didrocks> ahah :)
[10:29] <tvoss_> didrocks, so I do not have any strong feelings
[10:29] <didrocks> tvoss_: yeah, seeing the number of bins, I think have usr/lib/<triplet>/mir makes sense
[10:31] <didrocks> tvoss_: libmirserverlttng.so being shipped alongside the server is wanted?
[10:31] <didrocks> it's only for instrumenting it, right?
[10:31] <tvoss_> didrocks, right
[10:32] <didrocks> tvoss_: shouldn't that be in the -tools package rather then?
[10:32] <tvoss_> didrocks, good point
[10:32] <tvoss_> didrocks, but please check with alf, too
[10:32] <didrocks> tvoss_: yeah, I'll do a MP anyway
[10:32] <tvoss_> didrocks, yup
[10:37] <tvoss_> RAOF, installed from testing ppa, works fine :)
[10:38] <RAOF> tvoss_: Woot!
[10:39] <tvoss_> RAOF, a crash in plymouth after login, but that has been reported since 11.10
[10:58] <didrocks> tvoss_: urgh, lib is hardcoded as a destination in all MIR cmake file, I'm fixing it
[11:00] <RAOF> GRARGH! Why is my open() only being called _sometimes_?!
[11:06] <duflu> GMock! Tell me which function is has no default action!
[11:07]  * RAOF decides that 9pm really isn't the time to play second-guess-the-linker.
[11:08] <mlankhorst> But it is the perfect time to write your own linker! :-)
[11:08] <tvoss_> mlankhorst, rofl
[11:09] <tvoss_> mlankhorst, mind giving ppa:mir-team/system-compositor-testing a spin on some nouveau hw?
[11:09] <duflu> No, really. If GMock doesn't tell me which function needs fixing and gdb doesn't show it in the call stack, how do you find out?
[11:10] <mlankhorst> tvoss_: in a bit, need to finish my recompile first :-)
[11:10] <tvoss_> mlankhorst, I have an amd here
[11:12] <mlankhorst> oh btw the kernel dma-buf slowness fixes for amd will be in 3.11
[11:14] <tvoss_> mlankhorst, \o/
[12:28] <duflu> tvoss_, OK, done
[12:28] <duflu> https://code.launchpad.net/~vanvugt/mir/fix-1193020/+merge/171070
[12:40] <tvoss> mlankhorst, finished your rebuild?
[12:58] <mlankhorst> tvoss: yeah but got preempted by a security update collission with -proposed
[12:58] <tvoss> mlankhorst, oh
[12:59] <mlankhorst> I'll check now
[13:20] <mlankhorst> tvoss: ok i installed it, what do I need to test?
[13:21] <tvoss> mlankhorst, restart, see if xmir runs and you are annoyed by the additional cursor distracting you permanently :)
[13:23] <mlankhorst> I only have 1 cursor when testing on radeon, fwiw
[13:29] <tvoss> mlankhorst, interesting
[13:31] <mlankhorst> then again might be intel too *checks*
[13:31] <mlankhorst> tvoss: oh there is a cursor in upper left
[13:32] <tvoss> mlankhorst, yup :)
[13:32] <mlankhorst> intel seems to be loaded
[13:32] <arsson> with nouvea still two cursors
[13:33] <mlankhorst> tvoss: I forgot that mir doesn't support hybrids yet :/
[13:33] <tvoss> mlankhorst, yup
[13:33] <tvoss> arsson, did you install from the system-compositor-testing ppa?
[13:33] <arsson> yup
[13:34] <mlankhorst> is it hardcoded to /dev/dri/card0 by any chance?
[13:34] <tvoss> arsson, the second cursor is meant to be there until we find have a more subtle way to say: you are running a system-compositor :)
[13:34] <tvoss> mlankhorst, would need to check the source, too
[13:35] <mlankhorst> oh worse..
[13:36] <mlankhorst> it just runs through an array with i915, radeon and nouveau and grabs the first one that works
[13:37] <mlankhorst> which fails when the first one in the array is not boot_vga
[13:40] <tvoss> mlankhorst, patches are welcome :)
[13:42] <mlankhorst> tvoss: unfortunately not very easy to do without udev discovery
[13:51]  * kgunn hoping mlankhorst hangs out here with us alot :)
[13:52] <mlankhorst> I only have hybrid laptops to test nouveau with atm though ;P
[13:52] <mlankhorst> not even muxed
[13:53] <tvoss> mlankhorst, okay
[13:54] <katie> tvoss ping
[13:54] <tvoss> katie, pong
[13:54] <katie> tvoss do you have 15 mins to have a chat with myself and mpt?
[13:54] <tvoss> katie, not right now, a bit later?
[13:55] <katie> tvoss, ok, after 4.30 is ok for me
[13:55] <tvoss> katie, cool, thx
[14:49] <tvoss_> kdub, ping
[14:49] <tvoss_> kdub, mind taking a look at: https://code.launchpad.net/~vanvugt/mir/fix-1193020
[14:49] <tvoss_> ?
[15:00] <kdub> tvoss_, sure
[15:00] <kdub> good morning channel
[15:00] <tvoss_> kdub, good morning, and thx
[15:08] <racarr> AAMorning
[15:28] <greyback> racarr: and a happy sober morning to you too
[15:30] <racarr> greyback: XD
[15:30] <racarr> keyboard error
[15:30] <greyback> http://i.imgur.com/lLdt36t.jpg is me after 6 hours of XMir and dual cursors
[15:30] <racarr> hahahaha
[15:31] <racarr> hangout? https://plus.google.com/hangouts/_/8015a964c25dbb4a92528d82f94676c27eb14a7a
[15:32] <greyback> coming
[16:00] <kdub> is alf around today?
[16:14] <sil2100> tvoss: hi!
[16:14] <sil2100> tvoss: how's the PPA-setup going?
[16:22] <kgunn> kdub: national holiday for alf
[16:22] <kdub> ah, ok
[16:22] <kgunn> kdub: you stuck
[16:22] <kgunn> ?
[16:23] <kdub> eh, i know that resizing is probably needed for the xmir stuff, might get started on that
[16:24] <kdub> i tinkered with sf enough to see how it resizes last week while tinkering with driver refcounting :)
[16:44] <kgunn> kdub: cool
[17:04] <didrocks> kgunn: hey, FYI, this is my MP for getting MIR almost good to enter the archives (I just need to find a way to fix one additional thing, but need to check with a lttng expert first):  https://code.launchpad.net/~didrocks/mir/packages-fix/+merge/171140
[17:04] <didrocks> kgunn: https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy is the bugs that need to be discussed and fixed before entering saucy. I'll need your team on this
[17:05] <didrocks> kgunn: especially debian/copyright, as I cleaned it 3 months ago and it's totally out of sync with the new 3rd party librairies that got included, so would be nice to have your team fixing this :)
[17:38] <racarr> lol...khonos_uint32_t strikes again
[17:41] <kdub> anyone object to the separate libgraphicsplatform.so? (dlopen'd). its ready to land, last chance to object
[17:43] <racarr> kdub: Sounds good :)
[17:43] <kdub> kgunn, is the difference between 'system compositor testing' and 'staging' ppa that the staging is just the latest of everything, and 'testing' should break less often?
[18:14] <kgunn> kdub: yep that's the idea
[18:19] <racarr> Lunching while bunches of things download on my phone :)
[18:19] <racarr> back soon
[18:51] <racarr> back :)
[22:12] <kdub> racarr, ping
[22:46] <racarr> kdub: pong
[22:46] <racarr> sorry was wrapped up in
[22:46] <racarr> [       OK ] TestClientInput.clients_do_not_receive_motion_outside_input_region (16 ms)
[22:46] <racarr> :)
[22:46] <racarr> you can put holes in windows now
[22:46] <kdub> oh really?
[22:46] <racarr> Yeah the shell will be using it
[22:46] <racarr> its input only now..eventually it would be cool if we could
[22:46] <racarr> clip to the region
[22:47] <racarr> as an optimization for the giant ullscreen shell with lots of transparency (which is what is happening now on SF)
[22:49] <racarr> Aha, the input stack gained support for resizing and moving
[22:49] <racarr> as a free bonus
[22:50] <kgunn> racarr: thats kinda cool
[22:50] <racarr> Just finishing off the "input shape" stuff for the shell
[22:51] <kgunn> robert_ancell: i painstakingly looked at each version of my libs to make sure the version matched system-comp-testing ppa
[22:51] <kgunn> just to be sure
[22:51] <kgunn> when you say i have an old mir....when i see orange arrow
[22:51] <kgunn> is that simply libmirserver0 ?
[22:51] <robert_ancell> kgunn, yes
[22:51] <kgunn> robert_ancell: ta, double check
[22:52] <robert_ancell> Did you try setting fire to your computer, buying a new one and adding the PPA again?
[22:52] <kdub> racarr, now just the buffers need resizing :)
[22:53] <kgunn> robert_ancell: i am close :)
[22:53] <kgunn> arg...double check...dpkg -s yeilds 0.0.4bzr766saucy0 which is exactly whats in the ppa
[22:54] <kgunn> i actually want it to be wrong
[22:54] <kgunn> itd make sense
[22:54] <kgunn> searching entire fs for libmirserver0
[22:56] <kgunn> robert_ancell: couple of other oddities...upon boot (not even trying xmir)
[22:56] <kgunn> i get a race...which i have to hit keys really fast then i boot (otherwise i freeze on cursor screen, no way out)
[22:56] <kgunn> also...once i boot...i end up on vt8, instead of vt7
[22:57] <kgunn> which i only discovered in the logs
[22:57] <kgunn> and then wehn i do try mir_demo_server i see big orange arrow (BOA)
[22:57]  * kgunn tired of typing big orange arrow
[22:58]  * kgunn searches internet for best laptop combustion accelerant 
[23:01] <robert_ancell> kgunn, lightdm.log? It should show why it picked VT8
[23:04] <kgunn> lightdm.log -> https://pastebin.canonical.com/93333/
[23:05] <kgunn> and then usc log -> https://pastebin.canonical.com/93334/
[23:05] <robert_ancell> kgunn, oh, looks like we don't release the VT when the compositor dies, so the fallback X server starts on the next one (8)
[23:06] <kgunn> btw, there is no other libmirserver0 on my system...just the one fresh w/ todays date, rev matching ppa...but yet still see BOA
[23:08] <robert_ancell> kgunn, is that the whole usc log? It's truncated
[23:09] <kgunn> i can repaste the whole thing...that was the interesting bit
[23:10] <kgunn> https://pastebin.canonical.com/93335/
[23:10] <kgunn> entire usc log ^
[23:11] <kgunn> rebooting...
[23:16] <kgunn> robert_ancell: so now i can't tell if i'm seeing a real error...or a "its just me prob"
[23:16] <kgunn> i'm pretty sure everything got cleanedup
[23:17] <robert_ancell> kgunn, so that log shows you do have an out of date libmirserver0 - it doesn't have the --vt option
[23:19] <kgunn> robert_ancell: but every thing i check says i only have 1 and its from the ppa today...ideas on verifying ?
[23:20] <kgunn> (btw, i already did ppa purge earlier...and it seemed to work)
[23:21] <robert_ancell> kgunn, Can you do a find in /usr/local etc, and see if you have some locally build one?
[23:22] <robert_ancell> kgunn, ok, try the following, and I will confirm on my system
[23:22] <robert_ancell> dpkg -s unity-system-compositor|grep Version
[23:22] <robert_ancell> ldd /usr/bin/unity-system-compositor
[23:22] <robert_ancell> unity-system-compositor --help
[23:23] <kgunn> Version: 0.0.1bzr29saucy0.79
[23:24] <robert_ancell> kgunn, same
[23:24] <kgunn> robert_ancell: ok...fme....this is too weird
[23:25] <kgunn> from the ldd i have "	libmirserver.so.0 => /usr/local/lib/libmirserver.so.0 (0x00007fb3b5b11000)"
[23:25] <kgunn> but if i go check...its not there
[23:25] <kgunn> wtf
[23:26] <kgunn> oh...nvmd..i lied, typo
[23:26] <kgunn> damn it...May 20th
[23:27] <robert_ancell> whoops :)
[23:28]  * kgunn note to self...don't look for libmirserver0...but libmirserver*
[23:29] <kgunn> robert_ancell: you have the patience of Job...thanks
[23:30] <kgunn> robert_ancell: i'll blow those away..purge again....and reinstall
[23:31] <robert_ancell> kgunn, you should be good to just reboot and try again
[23:45] <kgunn> reboot
[23:56] <robert_ancell> hmm, where is kgunn...