robert_ancellcome on jenkins... land those merges00:05
robert_ancellkgunn, up for some Sunday Mir fun?00:18
kgunnrobert_ancell: maybe...just kind of checking in00:39
robert_ancellkgunn, did you resolve your system compositor issues?00:39
kgunnbut realized i'm intel 64bit00:40
kgunnand know that was failing build00:40
kgunn(honestly i hadn't tried again due to that)00:40
robert_ancellkgunn, I'm amd64 here. It was i386 that was failing build, but that shouldn't affect you00:40
kgunnrobert_ancell: why wouldnt it effect me ?00:41
robert_ancellkgunn, you should be using amd64 packages too right?00:41
kgunnrobert_ancell: i guess i'm lost/my assumptions are wrong00:42
kgunnthot i would be on i386 packages00:42
kgunn...e.g. on an intel core you can use amd64  ?00:42
robert_ancellkgunn, what does uname -a00:42
robert_ancellkgunn, 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 place00:43
robert_ancellMight be the GNU name methinks?00:43
kgunnLinux 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/Linux00:43
robert_ancellyep, you're using amd64 packages00:43
robert_ancellSo i386 issues shouldn't affect you00:43
kgunnah...so amd is just a leftover from the fact they did 64bit first00:44
robert_ancellyeah, and whoever picked the string for it :)00:44
robert_ancellRead amd64 == x86_6400:44
kgunnok....so i386 means 32 bit, and amd64 means 64bit....(doesn;t follow the vendor)00:45
* kgunn files aways a new learning about ubuntu nomenclature00:45
robert_ancellWe 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_ancellAnd then it will be amd64 having the issues and armhf working the best :)00:46
kgunnrobert_ancell: btw...i did try vt swtiching00:46
kgunnand it still complained about libboost...wanting 49 altho i'm on 53 w/ standard saucy00:47
robert_ancellso odd00:47
kgunnrobert_ancell: i basically went thru and dpkg'd -s  every00:47
kgunndarn lib in the chain....all the depends...then i checked those depends00:48
kgunnnone of them were depending on v49 boosts that i could see00:48
robert_ancellkgunn, did you try an apt-get remove --purge libmirserver0 and then reinstall?00:48
kgunnwill try that...00:48
robert_ancell(don't think the purge will help but just in case)00:48
kgunni actually wondered....00:48
kgunni only did remove and no --purge00:48
kgunnso maybe....will try00:49
* robert_ancell wishes the arm builders were faster00:49
kgunnwhile we're waiting...how's the kiddo00:50
robert_ancelltakes 13 minutes just to start building00:50
robert_ancellkgunn, good, getting more alert every day00:50
kgunnrobert_ancell: mom doing ok? recovering....00:51
robert_ancellkgunn, yeah, she recovered from the c-section super fast so all good there. A bit sleep deprived but doing ok :)00:51
kgunnthat's great00:52
kgunn....well the recovery part00:52
kgunnnot the sleep deprivation part00:52
RAOFThat bit's just the price of admission :)00:53
robert_ancellRAOF, it was in the fine print :)00:59
robert_ancellthomi, 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.gz01:06
thomi/usr/lib/arm-linux-gnueabihf/libEGL.so.1: undefined reference to `mir_egl_mesa_display_is_valid'01:07
thomirobert_ancell: looks to me like something in RAOF's dept. Not a problem I'm aware of01:07
RAOFrobert_ancell: What PPA is that in? Mir wasn't building on armhf in the PPA for a good long while.01:10
robert_ancellRAOF, staging01:10
RAOFWhat's happening there?01:12
RAOFHow has libegl1-mesa failed to pick up a dependency on libmirclient?01:14
dufluRAOF: It's blocked by https://code.launchpad.net/~vanvugt/mir/fix-1192908/+merge/17077001:16
dufluIn fact, most of our PPA builds are blocked by that01:18
dufluSomeone can unlock the build pipe with https://code.launchpad.net/~vanvugt/mir/fix-1192908/+merge/17077001:19
duflu-unlock +unblock01:19
robert_ancellduflu, reviewing01:19
robert_ancellduflu, do we just need that to unlock and then can remove it?01:20
duflurobert_ancell, it will be needed so long as we ever intend to bump the soname of mirclient again01:21
robert_ancelli.e. once libmirclient.so.0 disappears01:21
robert_ancellyeah, just thought of that01:21
RAOFWe should really split mirclient into a separate source.01:21
duflurobert_ancell, if you want a quick-fix then just modify the recipe for building Mir to not use Mir-Mesa01:21
duflubut regular Mesa instead01:21
robert_ancellRAOF, agreed01:21
dufluI totally disagree. There's too much overlap between the projects01:21
dufluYou would also create a "shared" project, a "demos" project...01:22
dufluToo many01:22
robert_ancellduflu, well, demos should follow the mirclient source01:22
robert_ancellshared is a pita, agreed01:23
duflurobert_ancell, and then there's our tests which are client _and_ server in one :)01:23
RAOFAs long as we can bootstrap from a non-Mir-enabled mesa I guess we don't strictly need a separate source.01:23
robert_ancellRAOF, if our changes go upstream we can't do that..01:24
RAOFWell, we kindof can.01:24
dufluI would actually prefer just going back to libmirclient.so.0 to match the version :)01:25
RAOFEveryone 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
RAOFThe bootstrap sucks a bit, but it's not *too* onerous.01:25
robert_ancellduflu, I don't get how the version is involved here01:26
duflurobert_ancell, the soname bump in r749 caused this problem01:27
dufluIf we go back to zero then it is OK01:27
dufluBut saucy will need a similar bootstrap to go back01:27
robert_ancellWe need to be able to version our libraries properly01:28
dufluOK, and my proposal allows any number of future bumps01:28
duflu(with modification when we bump the ABI soname)01:28
robert_ancellyeah, we need to make +1 the versions in that case right?01:29
dufluYes, add another symlink for each old version01:29
dufluI'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 PPAs01:30
RAOFBut the symlinks are lies, right?01:30
robert_ancellyes, me too01:30
* RAOF is happy to temporarily unblock duflu 01:30
robert_ancellRAOF, yes, and there's no guarantee they will work if the ABI has broken majorly01:30
dufluRAOF: Only lies to the binaries we run during build (tests)01:30
dufluAnd even then it's closer to the truth01:31
RAOFduflu: 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
dufluThey don't have to *work*01:31
dufluIt just has to build01:31
dufluBecause we link to the new version that *works*01:31
dufluAnd test cases do work. Because they now link to just one (right) version01:31
RAOFI don't see how?01:32
dufluRAOF: Mir's tests run against it's local binaries.01:32
dufluRAOF: Yes EGL clients will fail, but only until EGL is rebuilt01:32
RAOFNone of Mir's tests link to EGL?01:33
dufluThey fail right now01:33
dufluRAOF: Yes they do. libmirserver uses it. But not as an EGL client. So the important functionality is never used01:33
dufluNot as an EGL Mir client01:33
robert_ancellRAOF, 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:33
RAOFrobert_ancell: Correct, I just dput up a +build1 :)01:34
RAOFduflu: 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:34
dufluRAOF: 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 EGL01:35
RAOFie: 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:35
dufluRAOF: Only clients with indirect links to the old libmirclient.so.0 will fail. Not after Mesa is rebuilt01:36
RAOFduflu: Right; a mesa rebuild fixes everything no matter what we do.01:36
dufluRAOF: Right, but a Mesa rebuild will fail without my fix01:36
dufluAnd is failing01:36
dufluWe need Mir to build successfully. And then that allows Mesa to build, finally01:37
RAOFI 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
dufluAnother possible solution is to avoid linking our test code to EGL. But that's difficult while libmirserver always needs it01:38
dufluRAOF: Look at the PPA build logs to see the errors it avoids01:39
robert_ancellkgunn, 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_ancellLet me know if you need deciphering01:40
RAOFduflu: 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:41
dufluRAOF: Correct. Our tests don't need functioning Mir-EGL compatibility.01:42
RAOFduflu: But "functioning" is not the barrier we're trying to clear.01:42
dufluNo. In fact, our tests technically should not depend on having a graphics head01:43
dufluSo really should not depend on EGL in future01:43
RAOFduflu: 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 -> lunch01:43
RAOFduflu: Anyway, I've approved that. Unblock away!01:45
dufluRAOF: The runtime linker only every loads the correct (new one). The hack is only to trick build-time linkage. Hence ABI breaks don't matter01:45
dufluThe important thing is to link to the version of a library that you will use at run time. And we are doing that01:46
dufluIf our acceptance-tests somehow become more dependent on having a working EGL head in future then we can tweak the tests01:47
dufluThough they do get a working EGL server. Only EGL clients fail till Mesa is rebuilt01:47
RAOFduflu: 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
dufluRAOF: We're not running the code that would refer to that missing symbol.01:48
RAOFUnless you're lazily resolving symbols that doesn't matter.01:48
RAOFWe're not lazily resolving symbols, are we?01:49
kgunnrobert_ancell: i caught that 2nd reference to ppa a moment ago myself (doh)01:49
kgunni updated01:49
kgunndo i have to hit "request another review" or some such ?01:49
dufluRAOF: No lazier than the default ld.so behaviour01:49
dufluWhich is lazy01:50
kgunnrobert_ancell: back in a bit...family pressure to take an evening walk here...01:50
RAOFduflu: That might be the source of my confusion, then!01:51
dufluRAOF: ld.so is lazy unless you set LD_BIND_NOW01:51
dufluAll said, if we can find a way to weaken the Mir/EGL coupling more elegantly then that's awesome01:52
robert_ancellno to kgunns last questions02:48
robert_ancellNot a general no02:48
robert_ancellduflu, 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 PPA02:49
duflurobert_ancell: That's fine. I test saucy too02:50
* duflu wonders why we can't write software that's buildable with existing stable platforms, like the rest of the world does02:51
dufluMaybe the deb format is somewhat to blame02:51
RAOFduflu: Because we're trying to write the platform at the same time?02:53
dufluYeah, that's a bad plan02:53
dufluDespite the fact it kinda works02:53
dufluExcept when it does not02:53
robert_ancellRAOF, I need Mir >= 736 in the system-compositor PPA - what's the process to update?02:55
RAOFrobert_ancell: I copy-with-binaries Mir from staging to the PPA, then rebuild u-s-c.02:56
robert_ancellRAOF, and what about everything else?02:56
robert_ancellWe need a big lock on the PPA - Lock it; make all the changes; unlock :)02:57
RAOFOnly things with a dependency on libmirserver0 need rebuilding, and that's just u-s-c.02:57
robert_ancellok, cool02:57
RAOFrobert_ancell: We can *kind* of do that - copy & build in a temporary PPA, then copy-with-binaries.02:57
robert_ancellyeah, I guess02:58
* RAOF dislikes how adding a private non-virtual function to a class triggers a rebuild of everything :/03:02
dufluRAOF: 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 wrong03:03
RAOFA different language design could remove that need entirely.03:04
dufluRAOF: D++? Go? :)03:20
robert_ancellRAOF, is this build not going to complete? i.e. should I just cancel it? https://launchpad.net/~mir-team/+archive/system-compositor-testing/+build/474128703:23
dufluRAOF, robert_ancell: What project/package should we target XMir bugs at?03:25
robert_ancellduflu, whatever RAOF finds easiest. At the moment they're just against Mir03:26
dufluYeah that's easy. But technically we should only do that where the bug is in lp:mir03:26
robert_ancellIt's kind of hard when we're not the upstream03:28
RAOFI don't really care where they end up.03:28
RAOFOh, god. I'm going to need to write MockUdev to land this branch, aren't I?03:29
RAOFduflu: D++, Go, C#, whatever :)03:29
RAOFduflu: Maybe even C03:30
RAOFduflu: Maybe even C03:30
RAOFduflu: Maybe even C++-plus-a-module-RFC.03:30
* RAOF needs an <enter> key not quite so close to ‘-’03:33
robert_ancellRAOF, that "indeed" refers to the i386 build?03:33
* robert_ancell bets RAOF replies with "indeed"03:34
robert_ancellRAOF, incorrect on my bet or the i386 build?03:34
RAOFThat build is not going to finish.03:35
RAOFAnd the only bugs filed against the Mir project should be bugs in lp:mir.03:35
RAOFAlso, needing to write MockUdev means that it's an excellent time for lunch!03:36
dufluHmm... 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:41
ubot5Launchpad bug 1192957 in Mir " /usr/lib/xorg/modules/extensions/libxmir.so: undefined symbol: mir_surface_next_buffer" [Undecided,Invalid]03:41
dufluRAOF: Would it help in any way to move struct defs like MirMesaEGLNativeSurface into Mesa? I'm not sure it would [MirMesaEGLNativeSurface]03:56
ubot5Launchpad bug 1192908 in Mir "Mir/Mesa packaging have a dependency cycle so neither can build" [Critical,In progress]03:57
RAOFduflu: That's fixed in Saucy; I haven't built a raring XMir, sorry.03:57
RAOFI'll upload one, just for you!03:57
dufluRAOF: That's OK I only use XMir on saucy :)03:57
dufluRAOF: No raring required there03:57
dufluRAOF: Oh, umm, seems I do have it installed. I wonder how necessary that is03:58
RAOFduflu: It won't load the xmir module unless you try to use it.03:59
dufluRAOF: Yeah I don't need XMir fixed for raring thanks04:00
RAOFWhy am I not drinking a coffee?04:00
* RAOF goes to remedy this.04:00
duflu... although the person who logged the bug might be on raring (https://bugs.launchpad.net/mir/+bug/1192957)04:01
ubot5Launchpad bug 1192957 in Mir " /usr/lib/xorg/modules/extensions/libxmir.so: undefined symbol: mir_surface_next_buffer" [Undecided,Invalid]04:01
dufluRAOF: As XMir is a nice loadable module, can we not make it a nice separate deb package too?04:05
dufluAlso, can anyone tell me what the changes are that we need in xserver-xorg-video-* ?04:06
RAOFduflu: The loadable module, yes. We also need core patches to make it work (such as the option handling, autoload, etc).04:09
dufluRAOF: Yeah I expected those core changes. But that's only a small part right?04:09
robert_ancellRAOF, those core changes useful for upstream?04:10
RAOFduflu: 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
dufluAh OK04:10
RAOFrobert_ancell: A small number, yes.04:10
robert_ancellRAOF, Have they been proposed?04:10
RAOFNot yet.04:10
RAOFAlthough I think I may have proposed all the bugfixy bits.04:10
RAOFI should check.04:10
robert_ancellX.org still uses mailing lists for patches right?04:11
RAOFBut mostly the patches are “add the -mir commandline option”, “add the xorgMir global switch”, “load the XMir module if xorgMir”, etc.04:12
RAOFThere'll be a bunch of equivalent patches for XWayland, FWIW.04:12
robert_ancellRAOF, are those flags just ignored if the module isn't there?04:13
RAOFNot really.04:13
RAOFBecause it doesn't really make sense to pass -mir but get a non-XMir server.04:14
RAOFThey're entirely harmless if you don't pass -mir.04:14
dufluGreat another major compiz/unity regression I need to figure out and report04:15
robert_ancellduflu, is this a related bug to the libmirclient one? https://launchpadlibrarian.net/143241855/buildlog_ubuntu-saucy-armhf.lightdm_1.7.3bzr1628saucy0_FAILEDTOBUILD.txt.gz05:03
robert_ancellNote in this case nothing is linking to libmirclient05:03
robert_ancellit looks almost like libEGL.so.1 is not linked against libmirclient05:05
robert_ancellRAOF, where is your mesa branch again?05:06
RAOFrobert_ancell: github.com/RAOF/mesa05:06
duflurobert_ancell, looks like a separate issue sorry05:11
* duflu runs to the shop05:11
robert_ancellRAOF, aha, libegl-mesa-dev doesn't depend on libmirclient-dev05:15
RAOFDoes it need to?05:15
robert_ancellRAOF, it has mir headers in it05:15
RAOFDoes it? Hm, ok.05:15
tvossgood morning :)05:16
robert_ancelltvoss, hello05:16
tvossrobert_ancell, hey there :) just checked: mir in the ppa for i386 is failing still, right?05:16
robert_ancellRAOF, in both lightdm and u-s-c libmirclient is not installed at all05:16
robert_ancelltvoss, yes, I was trying to find your branches :)05:17
RAOFrobert_ancell: But that's right, isn't it? lightdm doesn't use mirclient, and u-s-c doesn't use mirclient.05:17
robert_ancellRAOF, yeah, but libEGL links against it05:17
tvossrobert_ancell, pushing them now, it's one branch that hopefully fixes the issues05:17
robert_ancelltvoss, gimme gimme gimme05:17
robert_ancelltvoss, fixed in mir?05:17
tvossrobert_ancell, ack, although I have to say that it really only shows up in the weird builder configuration05:18
RAOFrobert_ancell: Yeah, and libEGL pulls in libmirclient1 *because* it links against it.05:19
robert_ancellRAOF, but not on arm it seems?05:19
RAOFRight, that's a WTF.05:19
robert_ancellDoes this normally just get worked around because of the -dev dependency?05:19
RAOFMesa doesn't (by default) have any headers that depend on Mir headers, though, so a dependency on libmirclient-dev is incorrect.05:19
robert_ancellRAOF, /usr/include/EGL/eglplatform.h according to my system05:20
RAOFrobert_ancell: Behind a compile guard that's never defined.05:20
RAOFAt least in client code.05:20
RAOFAlthough we could reasonably add that dependency.05:20
robert_ancellit might solve the immediate problem05:21
RAOFEh, why not.05:27
RAOFIt's not incorrect.05:27
RAOFLet me push that change...05:27
tvossRAOF, duflu, robert_ancell we still have the local gmock version, and I think we are good to remove it05:29
tvossor is there any reason we still carry it?05:29
RAOFBecause google are crazymad, I think.05:31
duflutvoss: Not sure, but someone should check certainly05:31
RAOFAnd by “crazymad” I mean “do not appreciate the position of a distribution”.05:31
dufluRAOF: What did Google do wrong?05:36
tvossduflu, we have gtest installed in source in /usr/src/gtest05:36
RAOFduflu: 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:36
tvossRAOF, although we still have gmock as prebuilt package available05:37
dufluHmm, why?05:37
RAOFduflu: Because they're paranoid about C++ ABI, #define subtleties, etc.05:37
dufluThat's a fair point, but it's a problem they should let the distro own05:38
tvossrobert_ancell, https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown05:39
robert_ancellRAOF, will you run that through the PPAs and make sure all the armhf builds work?05:43
RAOFrobert_ancell: Sure.05:46
dufluAwesome. GPU hang05:48
robert_ancellRAOF, I checked the .deb for libegl1-mesa using dpkg -I and it does not depend on libmirclient. So shlibs is not working for some reason05:49
robert_ancellRAOF, I'll file you a bug05:49
RAOFrobert_ancell: But only, as far as I can tell, on armhf.05:49
robert_ancellRAOF, yes05:49
RAOFWhich is weird.05:49
duflurobert_ancell, https://bugs.launchpad.net/mir/+bug/1192908/comments/505:49
ubot5Launchpad bug 1192908 in mesa (Ubuntu) "Mir/Mesa packaging have a dependency cycle so neither can build" [Medium,Triaged]05:49
robert_ancellduflu, but mesa has built, and it has Mir symbols in it. It's just shlibs in the debian packaging that doesn't think so05:50
duflurobert_ancell, OK so not directly related05:51
dufluBut still both real issues05:51
tvossduflu, 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_ancellbye all05:57
duflutvoss: Yeah sure. I will look at the transformation stuff this week too06:00
tvossduflu, cool, but let's get started with caching it before we completely move it to the gpu06:00
duflutvoss: Yes that's all I intended06:00
tvossduflu, cool :)06:00
dufluRight now though I'm buried in Mir bug triage and testing06:01
dufluThere shouldn't be this much...06:01
tvosshow do you mean?06:01
tvossduflu, ?06:04
duflutvoss: I mean just busy logging new serious bugs as I find them, and testing bugs for robert he wants to know they still exist06:04
tvossduflu, ack06:05
dufluArgh! Now LP is broken06:06
* duflu logs bugs against LP06:06
tvossduflu, I'm encountering timeouts quite regularly with LP these days06:06
duflutvoss: No, it's a really dumb bug: https://bugs.launchpad.net/launchpad/+bug/119400706:09
ubot5Launchpad bug 1194007 in Launchpad itself "Launchpad jumps to invalid page: https://bugs.launchpad.net/baz/+bug/200" [Undecided,New]06:09
RAOFDamnit! What the hell is my laptop doing?06:10
dufluRAOF: Busy fan? I have that06:10
dufluMaybe because https://bugs.launchpad.net/ubuntu-power-consumption/+bug/119400406:11
ubot5Launchpad bug 1194004 in compiz (Ubuntu) "Compiz wakes up 200Hz while the screen is locked" [Undecided,New]06:11
RAOFBusy fan, 5 second delay on typing.06:11
dufluAlso, the compiz config is corrupt. It won't let me enter a valid frame rate06:12
dufluRAOF: Mesa rebuild hiccups... configure: error: Package requirements (libdrm_radeon >= 2.4.45) were not met:06:28
tvossduflu, we need https://code.google.com/p/googlemock/issues/detail?id=79 to get rid of the local gmock version06:39
duflutvoss: Can't quite approve yet: https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown/+merge/17101706:43
RAOFAha! Something was swap-thrashing.06:44
dufluRAOF: Yes, compiz... ?06:44
tvossduflu, 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 it06:44
RAOFI don't *think* it was compiz. It might have been geary.06:44
duflutvoss: "buildd"?06:44
tvossduflu, the builders for ppa and archive06:45
tvossduflu, that's why the i386 build of mir in the system-compositor-testing ppa fails06:45
dufluHmm, kay. I'm just concerned we're not fixing the root cause and it will pop up on some other global06:45
tvossduflu, or better: hangs06:45
RAOFThe root cause would appear to be “Pre 2.6 kernels suck” :)06:47
tvossRAOF, with Daniel abstaining, would you mind taking a look here: https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown/+merge/17101706:48
duflutvoss: Top approved still06:48
tvossduflu, ah :)06:48
tvossRAOF, cancel my comment then :)06:48
RAOFtvoss: Sure. Was doing so before my machine entered swap-hell.06:48
tvossRAOF, ah06:48
dufluRAOF: Oooh you mean (memory)-swap-thrashing and not (buffer)-swap-thrashing like I am seeing?.. :)06:49
RAOFduflu: Indeed. memory-swap-thrashing.06:50
dufluThrashing of disks, not of framebuffers06:51
dufluHmm is it right that lightdm.conf ignores comments and typos?07:15
mlankhorstRAOF: ping, can you accept xxv-intel and mesa in quantal/raring and precise-lts?07:25
RAOFmlankhorst: Sure. Could you give me another ping in an hour or so if I haven't done it by then?07:25
tvossRAOF, mind uploading a new mir version to the sys-comp-testing ppa? the gflag fix just landed07:26
* didrocks fights with this pthread issue on google-mock…07:26
RAOFtvoss: 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:27
tvossRAOF, yup :)07:28
didrocksRAOF: 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:29
didrockswe can see that google-mock defines -pthread twice, one before the .la, one after, so it should be fine07:30
didrocksI 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 flags07:31
didrocksno luck…07:31
tvossdidrocks, I think it fails to link the internal gtest version07:33
didrockstvoss: yep, exactly07:33
tvossdidrocks, wouldn't it be a better idea to link against our gtest version anyways?07:33
RAOFdidrocks: Urgh. That doesn't look like fun.07:33
RAOFWe don't have a gtest binary.07:34
didrockstvoss: what RAOF told ^ :)07:34
didrocks(+ the unfun part as well :p)07:34
RAOFdidrocks: Did I fix that in gtest before? I don't recall if I did :/07:35
didrocksRAOF: no, it was just in case you did get that somewhere into saucy by any luck07:36
RAOFNo, I haven't noticed that before.07:37
didrocksok, I'll continue digging07:37
RAOFBaby time!08:01
didrockstvoss: 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:01
tvossdidrocks, looking08:04
mlankhorstRAOF: ping ;)08:17
dufluMe joins the queue to talk to RAOF [https://launchpad.net/~mir-team/+archive/staging/+build/4741584]08:23
* duflu does too08:23
* mlankhorst hopes it's a fifo, not a stack08:26
* duflu push_front08:31
tvossdidrocks, is it a good idea to rely on the deprecated autotools setup?08:34
didrockstvoss: can you be more explicit? :)08:34
tvossdidrocks, the gmock source package does not use the cmake setup08:35
tvossdidrocks, but uses the auto* setup08:35
didrockstvoss: ah, you are calling the whole "autotools" deprecated08:35
tvossdidrocks, yeah, the setup is discouraged by google iirc08:36
didrockscan we stop using that "deprecated" tool for anything? it's still used by the vast majority of free software08:36
didrocksI would like we more concentrate on where we are going than downsiding a bunch of technologies…08:36
didrocksthat worked for years08:36
didrocksI don't care about autotools vs cmake in particular, just that extra word was uneeded at least…08:37
didrockstvoss: to come back to the subject, we are using what upstream is using08:37
didrocksso we can switch to cmake as they ship both08:38
seb128didrocks, they have both in there, I think tvoss was suggesting that the gmock guys recommend using the cmake build08:38
didrocksI would appreciate if we switch to them to send the patch to debian as well08:38
seb128I pondered trying that to see if that fixes the build the other day08:38
seb128but my cmake foo are not that great ;-)08:38
didrocksseb128: it still doesn't explain the linking issue, but if by change this is not impacted :)08:39
didrocksat least, maybe --enable-external-gtest will be picked08:39
didrocks(which isn't the case I guess because of Makefile.am)08:39
tvossdidrocks, why do we ship gmock different than gtest btw? gtest installs to /usr/src, which works just fine for us08:40
tvossor am I missing something?08:40
didrockstvoss: because the package comes from debian?08:40
tvossdidrocks, does gtest come from debian, too?08:40
didrocksIIRC, we did ourselves the gtest package08:40
didrockslet me check08:41
didrockshum, it was remerged08:41
didrockstvoss: different maintainers08:41
didrockstvoss: we should standardize in a path and send the patch to debian I guess08:42
tvossdidrocks, okay, why not have /usr/src/gmock, then?08:42
didrockstvoss: if it makes things easier, I'm fine with it08:42
didrocksyou don't want to ship binaries then?08:43
didrocksonly the sources08:43
didrockslike for gtests and others…08:43
tvossdidrocks, it's way easier for cmake based projects, and we have magic to support autotools, too08:43
tvossdidrocks, yup08:43
didrockstvoss: we don't have any reverse dependencies for google-mock, let me check for build-reverse-dep before a final ack08:44
didrockstvoss: hum, we do have some though08:44
didrocksapart from rlvm, coming from us08:45
didrockstvoss: http://paste.ubuntu.com/5794887/08:45
didrocksthey need to be converted to rebuild google-mock I guess, and not relying on the .so or .la08:45
tvossdidrocks, hmmmm...08:46
didrocksrlvm was in sync with debian, so better to ship the patch to them as well08:46
didrocks(alongside the google-mock one)08:46
duflutvoss: On the other hand... having gtest/gmock inline makes building on other distros much easier, if they don't have it :)08:46
dufluBut you can argue that with all dependencies08:47
tvossduflu, yup08:47
didrocksduflu: 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
dufludidrocks: Yeah, OK, inline is bad08:48
dufluHmm, actually no, that's no a valid argument. Cos any issue that affects Mir will get fixed faster than distro.08:49
didrocksduflu: well, let's say that you have a pthread issue08:49
didrockslike now08:49
dufluWe do?08:50
didrocksyou have to fix it in 7 different projects08:50
dufluFairy nuff08:50
tvossdidrocks, just built the source package manually with the autotools toolchain (no dpkg-buildpackage), works fine08:51
didrockstvoss: right, because you don't use --as-needed I guess08:51
didrockstvoss: even without it08:53
didrockstvoss: did you run make check?08:53
tvossRAOF, ping08:57
tvossmlankhorst, ?09:01
tvossmlankhorst, oh sorry, I need to go to the queue09:02
tvossdidrocks, fails in run make check. The interesting thing is that the tests shouldn't link to gtest as they have fused_src compiled in09:06
tvossdidrocks, I'm confused now09:06
didrockstvoss: what's this fused_src?09:07
tvossdidrocks, it's all src and header files of gmock and gtest fusioned together by some python scripts09:07
didrockscopying all src into the same .o?09:07
didrockstvoss: we can try to switch to the cmake version if needed09:08
tvossdidrocks, let me first try to understand what's going on :)09:08
didrocksno make check/make tests though09:08
didrockstvoss: ok, I'll be out for a short bit, will be back later on :)09:09
tvossdidrocks, ack, need some breakfast, too09:09
tvossdidrocks, thanks :)09:16
duflutvoss: I can't see the magic 18% CPU. Maximum 6%09:50
dufluAny hints?09:50
tvossduflu, 18% within that function09:50
tvossduflu, I did a simple run with 1000 buffer swaps09:51
duflutvoss: No, all transformation logic only adds up to 6%. And only 3% in the glm matrix library09:51
dufluI wonder what I'm missing09:51
tvossduflu, weird09:51
dufluI did >66000 swaps09:51
tvosslet me see if I can find my results09:52
* tvoss thinks that adding the respective callgrind logs to the bug reports would be a good idea09:52
dufluSame issue really, just that I get 6% instead of 18%09:52
tvossduflu, do you think it's still worth fixing?09:52
duflutvoss: Yes I think so09:53
dufluIf we can gain it back easily09:53
tvossduflu, okay, do you have the callgrind trace handy? if so, mind attaching it to the bug report, too?09:53
didrockstvoss: hum, it seems the Mir licenses weren't updated when inlining new components in 3rd_party09:54
tvossdidrocks, mind filing a bug?09:54
didrockstvoss: sure :) knowing the time I spent to fix it the first time, I would appreciate upstream then to file debian/copyright this time09:54
tvossdidrocks, sure09:54
duflutvoss: Done09:57
tvossduflu, thx09:57
didrockstvoss: https://bugs.launchpad.net/mir/+bug/1194073, this is a prerequisite to have mir in distro09:57
ubot5Launchpad bug 1194073 in Mir "debian/copyright is not up to date with latest files included in MIR" [High,Confirmed]09:57
tvossdidrocks, ack09:57
didrockstvoss: do you know why we don't use cucumber from distro?09:58
didrocks(no cpp bindings?)09:58
tvossdidrocks, not sure, need to check with racarr09:58
tvossdidrocks, might well be that we are able to pull it out, too09:58
didrocksancillary isn't in distro, so it's fine09:59
didrockslet me open bugs for them09:59
didrocks(gmock and cucumber)09:59
tvossdidrocks, gmock bug should be there10:00
didrockstvoss: ok, let me add a tag to it10:00
tvossdidrocks, ack10:00
tvossduflu, do we have a performance tag?10:01
tvossduflu, how about performance, performance-cpu, performance-gpu?10:01
duflutvoss: It appears not. Just "performance" is OK10:01
tvossduflu, ack10:01
didrockstvoss: we don't run tests on armhf?10:02
dufludidrocks: We do during CI.10:04
didrocksduflu: any reason we don't do that in the ppa?10:04
dufludidrocks: No idea10:04
RAOFduflu: Ah. Mesa is too new to build on raring.10:04
dufluAh dependency madness10:05
dufluThough Mir does spend all its time in boost::asio stuff10:07
dufluI might have to learn what that is10:07
tvossduflu, where do you see that?10:09
duflutvoss: In kcachegrind10:09
dufluThe boost/asio call graph is so huge and complex I haven't quite figured it out yet10:10
didrockstvoss_: mir_demo* are just technical demos, right? They can be combined to be used by another applications?10:26
tvoss_didrocks, right, only technical demos. we use them for benchmarking purposes, too10:27
didrockstvoss_: I would add them in a examples/ directory rather10:27
tvoss_didrocks, we had that discussion before within the team10:28
tvoss_didrocks, or do you mean for the packaging?10:28
didrockswhat was the outcome? do you have anything written you can share?10:28
didrockstvoss_: for the packaging10:28
didrockslike usr/lib/<triplet>/mir/examples10:28
didrocks(I'm going to multiarch mir as well)10:28
tvoss_didrocks, @install: sounds sane, for the discussion: it was informal but I cannot even recall the conclusion10:29
didrockssame for mir_stress10:29
didrocksahah :)10:29
tvoss_didrocks, so I do not have any strong feelings10:29
didrockstvoss_: yeah, seeing the number of bins, I think have usr/lib/<triplet>/mir makes sense10:29
didrockstvoss_: libmirserverlttng.so being shipped alongside the server is wanted?10:31
didrocksit's only for instrumenting it, right?10:31
tvoss_didrocks, right10:31
didrockstvoss_: shouldn't that be in the -tools package rather then?10:32
tvoss_didrocks, good point10:32
tvoss_didrocks, but please check with alf, too10:32
didrockstvoss_: yeah, I'll do a MP anyway10:32
tvoss_didrocks, yup10:32
tvoss_RAOF, installed from testing ppa, works fine :)10:37
RAOFtvoss_: Woot!10:38
tvoss_RAOF, a crash in plymouth after login, but that has been reported since 11.1010:39
didrockstvoss_: urgh, lib is hardcoded as a destination in all MIR cmake file, I'm fixing it10:58
RAOFGRARGH! Why is my open() only being called _sometimes_?!11:00
=== mmrazik is now known as mmrazik|lunch
dufluGMock! Tell me which function is has no default action!11:06
* RAOF decides that 9pm really isn't the time to play second-guess-the-linker.11:07
mlankhorstBut it is the perfect time to write your own linker! :-)11:08
tvoss_mlankhorst, rofl11:08
tvoss_mlankhorst, mind giving ppa:mir-team/system-compositor-testing a spin on some nouveau hw?11:09
dufluNo, 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:09
mlankhorsttvoss_: in a bit, need to finish my recompile first :-)11:10
tvoss_mlankhorst, I have an amd here11:10
mlankhorstoh btw the kernel dma-buf slowness fixes for amd will be in 3.1111:12
tvoss_mlankhorst, \o/11:14
=== mmrazik|lunch is now known as mmrazik
duflutvoss_, OK, done12:28
=== mzanetti is now known as mzanetti|lunch
tvossmlankhorst, finished your rebuild?12:40
mlankhorsttvoss: yeah but got preempted by a security update collission with -proposed12:58
tvossmlankhorst, oh12:58
=== mzanetti|lunch is now known as mzanetti
mlankhorstI'll check now12:59
=== greyback is now known as greyback|lunch
mlankhorsttvoss: ok i installed it, what do I need to test?13:20
tvossmlankhorst, restart, see if xmir runs and you are annoyed by the additional cursor distracting you permanently :)13:21
mlankhorstI only have 1 cursor when testing on radeon, fwiw13:23
tvossmlankhorst, interesting13:29
mlankhorstthen again might be intel too *checks*13:31
mlankhorsttvoss: oh there is a cursor in upper left13:31
tvossmlankhorst, yup :)13:32
mlankhorstintel seems to be loaded13:32
arssonwith nouvea still two cursors13:32
mlankhorsttvoss: I forgot that mir doesn't support hybrids yet :/13:33
tvossmlankhorst, yup13:33
tvossarsson, did you install from the system-compositor-testing ppa?13:33
mlankhorstis it hardcoded to /dev/dri/card0 by any chance?13:34
tvossarsson, 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
tvossmlankhorst, would need to check the source, too13:34
mlankhorstoh worse..13:35
mlankhorstit just runs through an array with i915, radeon and nouveau and grabs the first one that works13:36
mlankhorstwhich fails when the first one in the array is not boot_vga13:37
tvossmlankhorst, patches are welcome :)13:40
mlankhorsttvoss: unfortunately not very easy to do without udev discovery13:42
=== greyback|lunch is now known as greyback
* kgunn hoping mlankhorst hangs out here with us alot :)13:51
mlankhorstI only have hybrid laptops to test nouveau with atm though ;P13:52
mlankhorstnot even muxed13:52
tvossmlankhorst, okay13:53
katietvoss ping13:54
tvosskatie, pong13:54
katietvoss do you have 15 mins to have a chat with myself and mpt?13:54
tvosskatie, not right now, a bit later?13:54
katietvoss, ok, after 4.30 is ok for me13:55
tvosskatie, cool, thx13:55
tvoss_kdub, ping14:49
tvoss_kdub, mind taking a look at: https://code.launchpad.net/~vanvugt/mir/fix-119302014:49
kdubtvoss_, sure15:00
kdubgood morning channel15:00
tvoss_kdub, good morning, and thx15:00
greybackracarr: and a happy sober morning to you too15:28
racarrgreyback: XD15:30
racarrkeyboard error15:30
greybackhttp://i.imgur.com/lLdt36t.jpg is me after 6 hours of XMir and dual cursors15:30
racarrhangout? https://plus.google.com/hangouts/_/8015a964c25dbb4a92528d82f94676c27eb14a7a15:31
=== mmrazik is now known as mmrazik|afk
kdubis alf around today?16:00
=== dpm_ is now known as dpm
sil2100tvoss: hi!16:14
sil2100tvoss: how's the PPA-setup going?16:14
kgunnkdub: national holiday for alf16:22
kdubah, ok16:22
kgunnkdub: you stuck16:22
kdubeh, i know that resizing is probably needed for the xmir stuff, might get started on that16:23
kdubi tinkered with sf enough to see how it resizes last week while tinkering with driver refcounting :)16:24
kgunnkdub: cool16:44
=== olli__ is now known as olli
didrockskgunn: 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/17114017:04
didrockskgunn: 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 this17:04
didrockskgunn: 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:05
racarrlol...khonos_uint32_t strikes again17:38
kdubanyone object to the separate libgraphicsplatform.so? (dlopen'd). its ready to land, last chance to object17:41
racarrkdub: Sounds good :)17:43
kdubkgunn, 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?17:43
kgunnkdub: yep that's the idea18:14
racarrLunching while bunches of things download on my phone :)18:19
racarrback soon18:19
racarrback :)18:51
=== francisco is now known as Guest80960
kdubracarr, ping22:12
=== kode54_ is now known as kode54
racarrkdub: pong22:46
racarrsorry was wrapped up in22:46
racarr[       OK ] TestClientInput.clients_do_not_receive_motion_outside_input_region (16 ms)22:46
racarryou can put holes in windows now22:46
kduboh really?22:46
racarrYeah the shell will be using it22:46
racarrits input only now..eventually it would be cool if we could22:46
racarrclip to the region22:46
racarras an optimization for the giant ullscreen shell with lots of transparency (which is what is happening now on SF)22:47
racarrAha, the input stack gained support for resizing and moving22:49
racarras a free bonus22:49
kgunnracarr: thats kinda cool22:50
racarrJust finishing off the "input shape" stuff for the shell22:50
kgunnrobert_ancell: i painstakingly looked at each version of my libs to make sure the version matched system-comp-testing ppa22:51
kgunnjust to be sure22:51
kgunnwhen you say i have an old mir....when i see orange arrow22:51
kgunnis that simply libmirserver0 ?22:51
robert_ancellkgunn, yes22:51
kgunnrobert_ancell: ta, double check22:51
robert_ancellDid you try setting fire to your computer, buying a new one and adding the PPA again?22:52
kdubracarr, now just the buffers need resizing :)22:52
kgunnrobert_ancell: i am close :)22:53
kgunnarg...double check...dpkg -s yeilds 0.0.4bzr766saucy0 which is exactly whats in the ppa22:53
kgunni actually want it to be wrong22:54
kgunnitd make sense22:54
kgunnsearching entire fs for libmirserver022:54
kgunnrobert_ancell: couple of other oddities...upon boot (not even trying xmir)22:56
kgunni 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
kgunnalso...once i boot...i end up on vt8, instead of vt722:56
kgunnwhich i only discovered in the logs22:57
kgunnand then wehn i do try mir_demo_server i see big orange arrow (BOA)22:57
* kgunn tired of typing big orange arrow22:57
* kgunn searches internet for best laptop combustion accelerant 22:58
robert_ancellkgunn, lightdm.log? It should show why it picked VT823:01
kgunnlightdm.log -> https://pastebin.canonical.com/93333/23:04
kgunnand then usc log -> https://pastebin.canonical.com/93334/23:05
robert_ancellkgunn, 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:05
kgunnbtw, there is no other libmirserver0 on my system...just the one fresh w/ todays date, rev matching ppa...but yet still see BOA23:06
robert_ancellkgunn, is that the whole usc log? It's truncated23:08
kgunni can repaste the whole thing...that was the interesting bit23:09
kgunnentire usc log ^23:10
kgunnrobert_ancell: so now i can't tell if i'm seeing a real error...or a "its just me prob"23:16
kgunni'm pretty sure everything got cleanedup23:16
robert_ancellkgunn, so that log shows you do have an out of date libmirserver0 - it doesn't have the --vt option23:17
kgunnrobert_ancell: but every thing i check says i only have 1 and its from the ppa today...ideas on verifying ?23:19
kgunn(btw, i already did ppa purge earlier...and it seemed to work)23:20
robert_ancellkgunn, Can you do a find in /usr/local etc, and see if you have some locally build one?23:21
robert_ancellkgunn, ok, try the following, and I will confirm on my system23:22
robert_ancelldpkg -s unity-system-compositor|grep Version23:22
robert_ancellldd /usr/bin/unity-system-compositor23:22
robert_ancellunity-system-compositor --help23:22
kgunnVersion: 0.0.1bzr29saucy0.7923:23
robert_ancellkgunn, same23:24
kgunnrobert_ancell: ok...fme....this is too weird23:24
kgunnfrom the ldd i have "libmirserver.so.0 => /usr/local/lib/libmirserver.so.0 (0x00007fb3b5b11000)"23:25
kgunnbut if i go check...its not there23:25
kgunnoh...nvmd..i lied, typo23:26
kgunndamn it...May 20th23:26
robert_ancellwhoops :)23:27
* kgunn note to self...don't look for libmirserver0...but libmirserver*23:28
kgunnrobert_ancell: you have the patience of Job...thanks23:29
kgunnrobert_ancell: i'll blow those away..purge again....and reinstall23:30
robert_ancellkgunn, you should be good to just reboot and try again23:31
robert_ancellhmm, where is kgunn...23:56

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!