[00:05] come on jenkins... land those merges [00:18] kgunn, up for some Sunday Mir fun? [00:39] robert_ancell: maybe...just kind of checking in [00:39] kgunn, did you resolve your system compositor issues? [00:39] nope.... [00:40] :( [00:40] but realized i'm intel 64bit [00:40] and know that was failing build [00:40] (honestly i hadn't tried again due to that) [00:40] kgunn, I'm amd64 here. It was i386 that was failing build, but that shouldn't affect you [00:41] robert_ancell: why wouldnt it effect me ? [00:41] kgunn, you should be using amd64 packages too right? [00:42] robert_ancell: i guess i'm lost/my assumptions are wrong [00:42] thot i would be on i386 packages [00:42] ...e.g. on an intel core you can use amd64 ? [00:42] kgunn, what does uname -a [00:42] say? [00:43] 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] Might be the GNU name methinks? [00:43] 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] yep, you're using amd64 packages [00:43] So i386 issues shouldn't affect you [00:44] ah...so amd is just a leftover from the fact they did 64bit first [00:44] yeah, and whoever picked the string for it :) [00:44] Read amd64 == x86_64 [00:45] ok....so i386 means 32 bit, and amd64 means 64bit....(doesn;t follow the vendor) [00:45] yeah [00:45] * kgunn files aways a new learning about ubuntu nomenclature [00:46] 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] And then it will be amd64 having the issues and armhf working the best :) [00:46] robert_ancell: btw...i did try vt swtiching [00:47] and it still complained about libboost...wanting 49 altho i'm on 53 w/ standard saucy [00:47] so odd [00:47] robert_ancell: i basically went thru and dpkg'd -s every [00:48] darn lib in the chain....all the depends...then i checked those depends [00:48] none of them were depending on v49 boosts that i could see [00:48] kgunn, did you try an apt-get remove --purge libmirserver0 and then reinstall? [00:48] will try that... [00:48] (don't think the purge will help but just in case) [00:48] i actually wondered.... [00:48] i only did remove and no --purge [00:49] so maybe....will try [00:49] * robert_ancell wishes the arm builders were faster [00:50] while we're waiting...how's the kiddo [00:50] takes 13 minutes just to start building [00:50] kgunn, good, getting more alert every day [00:51] robert_ancell: mom doing ok? recovering.... [00:51] kgunn, yeah, she recovered from the c-section super fast so all good there. A bit sleep deprived but doing ok :) [00:52] that's great [00:52] ....well the recovery part [00:52] not the sleep deprivation part [00:53] That bit's just the price of admission :) [00:59] RAOF, it was in the fine print :) [01:06] 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] /usr/lib/arm-linux-gnueabihf/libEGL.so.1: undefined reference to `mir_egl_mesa_display_is_valid' [01:07] robert_ancell: looks to me like something in RAOF's dept. Not a problem I'm aware of [01:10] robert_ancell: What PPA is that in? Mir wasn't building on armhf in the PPA for a good long while. [01:10] RAOF, staging [01:12] Awah? [01:12] What's happening there? [01:14] How has libegl1-mesa failed to pick up a dependency on libmirclient? [01:16] RAOF: It's blocked by https://code.launchpad.net/~vanvugt/mir/fix-1192908/+merge/170770 [01:18] In fact, most of our PPA builds are blocked by that [01:19] Someone can unlock the build pipe with https://code.launchpad.net/~vanvugt/mir/fix-1192908/+merge/170770 [01:19] :) [01:19] -unlock +unblock [01:19] duflu, reviewing [01:20] duflu, do we just need that to unlock and then can remove it? [01:21] robert_ancell, it will be needed so long as we ever intend to bump the soname of mirclient again [01:21] i.e. once libmirclient.so.0 disappears [01:21] yeah, just thought of that [01:21] We should really split mirclient into a separate source. [01:21] robert_ancell, if you want a quick-fix then just modify the recipe for building Mir to not use Mir-Mesa [01:21] but regular Mesa instead [01:21] RAOF, agreed [01:21] I totally disagree. There's too much overlap between the projects [01:22] You would also create a "shared" project, a "demos" project... [01:22] Too many [01:22] duflu, well, demos should follow the mirclient source [01:23] shared is a pita, agreed [01:23] robert_ancell, and then there's our tests which are client _and_ server in one :) [01:23] As long as we can bootstrap from a non-Mir-enabled mesa I guess we don't strictly need a separate source. [01:24] RAOF, if our changes go upstream we can't do that.. [01:24] Well, we kindof can. [01:25] I would actually prefer just going back to libmirclient.so.0 to match the version :) [01:25] 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] The bootstrap sucks a bit, but it's not *too* onerous. [01:26] duflu, I don't get how the version is involved here [01:27] robert_ancell, the soname bump in r749 caused this problem [01:27] If we go back to zero then it is OK [01:27] But saucy will need a similar bootstrap to go back [01:28] We need to be able to version our libraries properly [01:28] OK, and my proposal allows any number of future bumps [01:28] (with modification when we bump the ABI soname) [01:29] yeah, we need to make +1 the versions in that case right? [01:29] Yes, add another symlink for each old version [01:30] 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] But the symlinks are lies, right? [01:30] yes, me too [01:30] * RAOF is happy to temporarily unblock duflu [01:30] RAOF, yes, and there's no guarantee they will work if the ABI has broken majorly [01:30] reboot [01:30] RAOF: Only lies to the binaries we run during build (tests) [01:31] And even then it's closer to the truth [01:31] 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] They don't have to *work* [01:31] It just has to build [01:31] Because we link to the new version that *works* [01:31] And test cases do work. Because they now link to just one (right) version [01:32] I don't see how? [01:32] RAOF: Mir's tests run against it's local binaries. [01:32] RAOF: Yes EGL clients will fail, but only until EGL is rebuilt [01:33] None of Mir's tests link to EGL? [01:33] They fail right now [01:33] RAOF: Yes they do. libmirserver uses it. But not as an EGL client. So the important functionality is never used [01:33] Not as an EGL Mir client [01:33] 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] robert_ancell: Correct, I just dput up a +build1 :) [01:34] 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] 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] 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] RAOF: Only clients with indirect links to the old libmirclient.so.0 will fail. Not after Mesa is rebuilt [01:36] duflu: Right; a mesa rebuild fixes everything no matter what we do. [01:36] RAOF: Right, but a Mesa rebuild will fail without my fix [01:36] And is failing [01:37] We need Mir to build successfully. And then that allows Mesa to build, finally [01:38] 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] Another possible solution is to avoid linking our test code to EGL. But that's difficult while libmirserver always needs it [01:39] RAOF: Look at the PPA build logs to see the errors it avoids [01:40] 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] Let me know if you need deciphering [01:41] 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] RAOF: Correct. Our tests don't need functioning Mir-EGL compatibility. [01:42] duflu: But "functioning" is not the barrier we're trying to clear. [01:43] No. In fact, our tests technically should not depend on having a graphics head [01:43] So really should not depend on EGL in future [01:43] 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] duflu: Anyway, I've approved that. Unblock away! [01:45] 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] 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] If our acceptance-tests somehow become more dependent on having a working EGL head in future then we can tweak the tests [01:47] Though they do get a working EGL server. Only EGL clients fail till Mesa is rebuilt [01:48] 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] RAOF: We're not running the code that would refer to that missing symbol. [01:48] Unless you're lazily resolving symbols that doesn't matter. [01:49] We're not lazily resolving symbols, are we? [01:49] robert_ancell: i caught that 2nd reference to ppa a moment ago myself (doh) [01:49] i updated [01:49] do i have to hit "request another review" or some such ? [01:49] RAOF: No lazier than the default ld.so behaviour [01:50] Which is lazy [01:50] robert_ancell: back in a bit...family pressure to take an evening walk here... [01:51] duflu: That might be the source of my confusion, then! [01:51] RAOF: ld.so is lazy unless you set LD_BIND_NOW [01:52] All said, if we can find a way to weaken the Mir/EGL coupling more elegantly then that's awesome [02:44] no [02:47] ? [02:48] no to kgunns last questions [02:48] Not a general no [02:49] 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] 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] Maybe the deb format is somewhat to blame [02:53] duflu: Because we're trying to write the platform at the same time? [02:53] Yeah, that's a bad plan [02:53] Despite the fact it kinda works [02:53] Except when it does not [02:55] RAOF, I need Mir >= 736 in the system-compositor PPA - what's the process to update? [02:56] robert_ancell: I copy-with-binaries Mir from staging to the PPA, then rebuild u-s-c. [02:56] RAOF, and what about everything else? [02:57] We need a big lock on the PPA - Lock it; make all the changes; unlock :) [02:57] Only things with a dependency on libmirserver0 need rebuilding, and that's just u-s-c. [02:57] ok, cool [02:57] robert_ancell: We can *kind* of do that - copy & build in a temporary PPA, then copy-with-binaries. [02:58] yeah, I guess [03:02] * RAOF dislikes how adding a private non-virtual function to a class triggers a rebuild of everything :/ [03:03] 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] A different language design could remove that need entirely. [03:20] RAOF: D++? Go? :) [03:23] 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] RAOF, robert_ancell: What project/package should we target XMir bugs at? [03:26] duflu, whatever RAOF finds easiest. At the moment they're just against Mir [03:26] Yeah that's easy. But technically we should only do that where the bug is in lp:mir [03:28] yep [03:28] Indeed. [03:28] It's kind of hard when we're not the upstream [03:28] I don't really care where they end up. [03:29] Oh, god. I'm going to need to write MockUdev to land this branch, aren't I? [03:29] duflu: D++, Go, C#, whatever :) [03:30] duflu: Maybe even C [03:30] duflu: Maybe even C [03:30] duflu: Maybe even C++-plus-a-module-RFC. [03:33] * RAOF needs an key not quite so close to ‘-’ [03:33] RAOF, that "indeed" refers to the i386 build? [03:34] * robert_ancell bets RAOF replies with "indeed" [03:34] Incorrect!@ [03:34] RAOF, incorrect on my bet or the i386 build? [03:35] CONTEXT ERROR CONTEXT ERROR [03:35] ERECURSIVECTX [03:35] That build is not going to finish. [03:35] And the only bugs filed against the Mir project should be bugs in lp:mir. [03:36] Also, needing to write MockUdev means that it's an excellent time for lunch! [03:41] 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:41] Launchpad bug 1192957 in Mir " /usr/lib/xorg/modules/extensions/libxmir.so: undefined symbol: mir_surface_next_buffer" [Undecided,Invalid] [03:56] RAOF: Would it help in any way to move struct defs like MirMesaEGLNativeSurface into Mesa? I'm not sure it would [MirMesaEGLNativeSurface] [03:57] [https://bugs.launchpad.net/mir/+bug/1192908/comments/2] [03:57] Launchpad bug 1192908 in Mir "Mir/Mesa packaging have a dependency cycle so neither can build" [Critical,In progress] [03:57] duflu: That's fixed in Saucy; I haven't built a raring XMir, sorry. [03:57] I'll upload one, just for you! [03:57] RAOF: That's OK I only use XMir on saucy :) [03:57] RAOF: No raring required there [03:58] RAOF: Oh, umm, seems I do have it installed. I wonder how necessary that is [03:59] duflu: It won't load the xmir module unless you try to use it. [04:00] RAOF: Yeah I don't need XMir fixed for raring thanks [04:00] Why am I not drinking a coffee? [04:00] * RAOF goes to remedy this. [04:01] ... although the person who logged the bug might be on raring (https://bugs.launchpad.net/mir/+bug/1192957) [04:01] Launchpad bug 1192957 in Mir " /usr/lib/xorg/modules/extensions/libxmir.so: undefined symbol: mir_surface_next_buffer" [Undecided,Invalid] [04:05] RAOF: As XMir is a nice loadable module, can we not make it a nice separate deb package too? [04:06] Also, can anyone tell me what the changes are that we need in xserver-xorg-video-* ? [04:09] duflu: The loadable module, yes. We also need core patches to make it work (such as the option handling, autoload, etc). [04:09] RAOF: Yeah I expected those core changes. But that's only a small part right? [04:09] Yeah. [04:10] RAOF, those core changes useful for upstream? [04:10] 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] Ah OK [04:10] robert_ancell: A small number, yes. [04:10] RAOF, Have they been proposed? [04:10] Not yet. [04:10] Although I think I may have proposed all the bugfixy bits. [04:10] I should check. [04:11] X.org still uses mailing lists for patches right? [04:11] Yes. [04:12] *sigh* [04:12] But mostly the patches are “add the -mir commandline option”, “add the xorgMir global switch”, “load the XMir module if xorgMir”, etc. [04:12] There'll be a bunch of equivalent patches for XWayland, FWIW. [04:13] RAOF, are those flags just ignored if the module isn't there? [04:13] Not really. [04:14] Because it doesn't really make sense to pass -mir but get a non-XMir server. [04:14] They're entirely harmless if you don't pass -mir. [04:15] Great another major compiz/unity regression I need to figure out and report [05:03] 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] Note in this case nothing is linking to libmirclient [05:05] it looks almost like libEGL.so.1 is not linked against libmirclient [05:06] RAOF, where is your mesa branch again? [05:06] robert_ancell: github.com/RAOF/mesa [05:11] robert_ancell, looks like a separate issue sorry [05:11] * duflu runs to the shop [05:15] RAOF, aha, libegl-mesa-dev doesn't depend on libmirclient-dev [05:15] Does it need to? [05:15] RAOF, it has mir headers in it [05:15] Does it? Hm, ok. [05:16] good morning :) [05:16] tvoss, hello [05:16] robert_ancell, hey there :) just checked: mir in the ppa for i386 is failing still, right? [05:16] RAOF, in both lightdm and u-s-c libmirclient is not installed at all [05:17] tvoss, yes, I was trying to find your branches :) [05:17] robert_ancell: But that's right, isn't it? lightdm doesn't use mirclient, and u-s-c doesn't use mirclient. [05:17] RAOF, yeah, but libEGL links against it [05:17] robert_ancell, pushing them now, it's one branch that hopefully fixes the issues [05:17] tvoss, gimme gimme gimme [05:17] tvoss, fixed in mir? [05:18] robert_ancell, ack, although I have to say that it really only shows up in the weird builder configuration [05:19] robert_ancell: Yeah, and libEGL pulls in libmirclient1 *because* it links against it. [05:19] RAOF, but not on arm it seems? [05:19] Right, that's a WTF. [05:19] Does this normally just get worked around because of the -dev dependency? [05:19] Mesa doesn't (by default) have any headers that depend on Mir headers, though, so a dependency on libmirclient-dev is incorrect. [05:20] RAOF, /usr/include/EGL/eglplatform.h according to my system [05:20] robert_ancell: Behind a compile guard that's never defined. [05:20] At least in client code. [05:20] Although we could reasonably add that dependency. [05:21] it might solve the immediate problem [05:27] Eh, why not. [05:27] It's not incorrect. [05:27] Let me push that change... [05:29] RAOF, duflu, robert_ancell we still have the local gmock version, and I think we are good to remove it [05:29] or is there any reason we still carry it? [05:31] Because google are crazymad, I think. [05:31] tvoss: Not sure, but someone should check certainly [05:31] And by “crazymad” I mean “do not appreciate the position of a distribution”. [05:36] RAOF: What did Google do wrong? [05:36] duflu, we have gtest installed in source in /usr/src/gtest [05:36] 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] RAOF, although we still have gmock as prebuilt package available [05:37] Hmm, why? [05:37] duflu: Because they're paranoid about C++ ABI, #define subtleties, etc. [05:38] That's a fair point, but it's a problem they should let the distro own [05:38] Exactly. [05:39] robert_ancell, https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown [05:43] RAOF, will you run that through the PPAs and make sure all the armhf builds work? [05:46] robert_ancell: Sure. [05:48] Awesome. GPU hang [05:49] Woo! [05:49] 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] RAOF, I'll file you a bug [05:49] robert_ancell: But only, as far as I can tell, on armhf. [05:49] RAOF, yes [05:49] Which is weird. [05:49] robert_ancell, https://bugs.launchpad.net/mir/+bug/1192908/comments/5 [05:49] Launchpad bug 1192908 in mesa (Ubuntu) "Mir/Mesa packaging have a dependency cycle so neither can build" [Medium,Triaged] [05:50] 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] robert_ancell, OK so not directly related [05:51] But still both real issues [05:52] yeah [05:57] 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] bye all [06:00] tvoss: Yeah sure. I will look at the transformation stuff this week too [06:00] duflu, cool, but let's get started with caching it before we completely move it to the gpu [06:00] tvoss: Yes that's all I intended [06:00] duflu, cool :) [06:01] Right now though I'm buried in Mir bug triage and testing [06:01] There shouldn't be this much... [06:01] how do you mean? [06:04] duflu, ? [06:04] 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] duflu, ack [06:06] Argh! Now LP is broken [06:06] * duflu logs bugs against LP [06:06] duflu, I'm encountering timeouts quite regularly with LP these days [06:09] tvoss: No, it's a really dumb bug: https://bugs.launchpad.net/launchpad/+bug/1194007 [06:09] Launchpad bug 1194007 in Launchpad itself "Launchpad jumps to invalid page: https://bugs.launchpad.net/baz/+bug/200" [Undecided,New] [06:10] Damnit! What the hell is my laptop doing? [06:10] RAOF: Busy fan? I have that [06:11] Maybe because https://bugs.launchpad.net/ubuntu-power-consumption/+bug/1194004 [06:11] Launchpad bug 1194004 in compiz (Ubuntu) "Compiz wakes up 200Hz while the screen is locked" [Undecided,New] [06:11] Busy fan, 5 second delay on typing. [06:12] Also, the compiz config is corrupt. It won't let me enter a valid frame rate [06:28] RAOF: Mesa rebuild hiccups... configure: error: Package requirements (libdrm_radeon >= 2.4.45) were not met: [06:39] duflu, we need https://code.google.com/p/googlemock/issues/detail?id=79 to get rid of the local gmock version [06:43] tvoss: Can't quite approve yet: https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown/+merge/171017 [06:44] Aha! Something was swap-thrashing. [06:44] RAOF: Yes, compiz... ? [06:44] 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] I don't *think* it was compiz. It might have been geary. [06:44] tvoss: "buildd"? [06:45] duflu, the builders for ppa and archive [06:45] duflu, that's why the i386 build of mir in the system-compositor-testing ppa fails [06:45] Hmm, kay. I'm just concerned we're not fixing the root cause and it will pop up on some other global [06:45] duflu, or better: hangs [06:47] The root cause would appear to be “Pre 2.6 kernels suck” :) [06:48] 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] ? [06:48] tvoss: Top approved still [06:48] duflu, ah :) [06:48] RAOF, cancel my comment then :) [06:48] tvoss: Sure. Was doing so before my machine entered swap-hell. [06:48] RAOF, ah [06:49] RAOF: Oooh you mean (memory)-swap-thrashing and not (buffer)-swap-thrashing like I am seeing?.. :) [06:50] duflu: Indeed. memory-swap-thrashing. [06:51] Thrashing of disks, not of framebuffers [07:15] Hmm is it right that lightdm.conf ignores comments and typos? [07:25] RAOF: ping, can you accept xxv-intel and mesa in quantal/raring and precise-lts? [07:25] mlankhorst: Sure. Could you give me another ping in an hour or so if I haven't done it by then? [07:26] RAOF, mind uploading a new mir version to the sys-comp-testing ppa? the gflag fix just landed [07:26] sure [07:26] * didrocks fights with this pthread issue on google-mock… [07:27] 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] RAOF, yup :) [07:29] 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] we can see that google-mock defines -pthread twice, one before the .la, one after, so it should be fine [07:31] 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] no luck… [07:33] didrocks, I think it fails to link the internal gtest version [07:33] tvoss: yep, exactly [07:33] didrocks, wouldn't it be a better idea to link against our gtest version anyways? [07:33] didrocks: Urgh. That doesn't look like fun. [07:34] We don't have a gtest binary. [07:34] tvoss: what RAOF told ^ :) [07:34] (+ the unfun part as well :p) [07:35] didrocks: Did I fix that in gtest before? I don't recall if I did :/ [07:36] RAOF: no, it was just in case you did get that somewhere into saucy by any luck [07:37] No, I haven't noticed that before. [07:37] ok, I'll continue digging [08:01] Baby time! [08:01] 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] didrocks, looking [08:17] RAOF: ping ;) [08:23] 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] didrocks, is it a good idea to rely on the deprecated autotools setup? [08:34] tvoss: can you be more explicit? :) [08:35] didrocks, the gmock source package does not use the cmake setup [08:35] didrocks, but uses the auto* setup [08:35] tvoss: ah, you are calling the whole "autotools" deprecated [08:36] didrocks, yeah, the setup is discouraged by google iirc [08:36] can we stop using that "deprecated" tool for anything? it's still used by the vast majority of free software [08:36] I would like we more concentrate on where we are going than downsiding a bunch of technologies… [08:36] that worked for years [08:37] I don't care about autotools vs cmake in particular, just that extra word was uneeded at least… [08:37] tvoss: to come back to the subject, we are using what upstream is using [08:38] so we can switch to cmake as they ship both [08:38] didrocks, they have both in there, I think tvoss was suggesting that the gmock guys recommend using the cmake build [08:38] I would appreciate if we switch to them to send the patch to debian as well [08:38] I pondered trying that to see if that fixes the build the other day [08:38] but my cmake foo are not that great ;-) [08:39] seb128: it still doesn't explain the linking issue, but if by change this is not impacted :) [08:39] at least, maybe --enable-external-gtest will be picked [08:39] (which isn't the case I guess because of Makefile.am) [08:40] didrocks, why do we ship gmock different than gtest btw? gtest installs to /usr/src, which works just fine for us [08:40] or am I missing something? [08:40] tvoss: because the package comes from debian? [08:40] didrocks, does gtest come from debian, too? [08:40] IIRC, we did ourselves the gtest package [08:41] let me check [08:41] hum, it was remerged [08:41] tvoss: different maintainers [08:42] tvoss: we should standardize in a path and send the patch to debian I guess [08:42] didrocks, okay, why not have /usr/src/gmock, then? [08:42] tvoss: if it makes things easier, I'm fine with it [08:43] you don't want to ship binaries then? [08:43]