| robert_ancell | come on jenkins... land those merges | 00:05 |
|---|---|---|
| robert_ancell | kgunn, up for some Sunday Mir fun? | 00:18 |
| 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:39 |
| 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:40 |
| kgunn | robert_ancell: why wouldnt it effect me ? | 00:41 |
| robert_ancell | kgunn, you should be using amd64 packages too right? | 00:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 | |
| 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:46 |
| 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:47 |
| 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:48 |
| kgunn | so maybe....will try | 00:49 |
| * robert_ancell wishes the arm builders were faster | 00:49 | |
| 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:50 |
| 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:51 |
| kgunn | that's great | 00:52 |
| kgunn | ....well the recovery part | 00:52 |
| kgunn | not the sleep deprivation part | 00:52 |
| RAOF | That bit's just the price of admission :) | 00:53 |
| robert_ancell | RAOF, it was in the fine print :) | 00:59 |
| 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:06 |
| 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:07 |
| 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:10 |
| RAOF | Awah? | 01:12 |
| RAOF | What's happening there? | 01:12 |
| RAOF | How has libegl1-mesa failed to pick up a dependency on libmirclient? | 01:14 |
| duflu | RAOF: It's blocked by https://code.launchpad.net/~vanvugt/mir/fix-1192908/+merge/170770 | 01:16 |
| duflu | In fact, most of our PPA builds are blocked by that | 01:18 |
| 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:19 |
| robert_ancell | duflu, do we just need that to unlock and then can remove it? | 01:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| robert_ancell | RAOF, if our changes go upstream we can't do that.. | 01:24 |
| RAOF | Well, we kindof can. | 01:24 |
| 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:25 |
| robert_ancell | duflu, I don't get how the version is involved here | 01:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| duflu | We need Mir to build successfully. And then that allows Mesa to build, finally | 01:37 |
| 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:38 |
| duflu | RAOF: Look at the PPA build logs to see the errors it avoids | 01:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 | |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| duflu | Which is lazy | 01:50 |
| kgunn | robert_ancell: back in a bit...family pressure to take an evening walk here... | 01:50 |
| 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:51 |
| duflu | All said, if we can find a way to weaken the Mir/EGL coupling more elegantly then that's awesome | 01:52 |
| robert_ancell | no | 02:44 |
| duflu | ? | 02:47 |
| robert_ancell | no to kgunns last questions | 02:48 |
| robert_ancell | Not a general no | 02:48 |
| 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:49 |
| duflu | robert_ancell: That's fine. I test saucy too | 02:50 |
| * 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:51 |
| 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:53 |
| robert_ancell | RAOF, I need Mir >= 736 in the system-compositor PPA - what's the process to update? | 02:55 |
| 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:56 |
| 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:57 |
| robert_ancell | yeah, I guess | 02:58 |
| * RAOF dislikes how adding a private non-virtual function to a class triggers a rebuild of everything :/ | 03:02 | |
| 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:03 |
| RAOF | A different language design could remove that need entirely. | 03:04 |
| duflu | RAOF: D++? Go? :) | 03:20 |
| 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:23 |
| duflu | RAOF, robert_ancell: What project/package should we target XMir bugs at? | 03:25 |
| 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:26 |
| 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:28 |
| 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:29 |
| RAOF | duflu: Maybe even C | 03:30 |
| RAOF | duflu: Maybe even C | 03:30 |
| RAOF | duflu: Maybe even C++-plus-a-module-RFC. | 03:30 |
| * RAOF needs an <enter> key not quite so close to ‘-’ | 03:33 | |
| robert_ancell | RAOF, that "indeed" refers to the i386 build? | 03:33 |
| * 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:34 |
| 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:35 |
| RAOF | Also, needing to write MockUdev means that it's an excellent time for lunch! | 03:36 |
| 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:41 |
| ubot5 | Launchpad bug 1192957 in Mir " /usr/lib/xorg/modules/extensions/libxmir.so: undefined symbol: mir_surface_next_buffer" [Undecided,Invalid] | 03:41 |
| duflu | RAOF: Would it help in any way to move struct defs like MirMesaEGLNativeSurface into Mesa? I'm not sure it would [MirMesaEGLNativeSurface] | 03:56 |
| duflu | [https://bugs.launchpad.net/mir/+bug/1192908/comments/2] | 03:57 |
| ubot5 | Launchpad bug 1192908 in Mir "Mir/Mesa packaging have a dependency cycle so neither can build" [Critical,In progress] | 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:57 |
| duflu | RAOF: Oh, umm, seems I do have it installed. I wonder how necessary that is | 03:58 |
| RAOF | duflu: It won't load the xmir module unless you try to use it. | 03:59 |
| 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:00 | |
| duflu | ... although the person who logged the bug might be on raring (https://bugs.launchpad.net/mir/+bug/1192957) | 04:01 |
| ubot5 | Launchpad bug 1192957 in Mir " /usr/lib/xorg/modules/extensions/libxmir.so: undefined symbol: mir_surface_next_buffer" [Undecided,Invalid] | 04:01 |
| duflu | RAOF: As XMir is a nice loadable module, can we not make it a nice separate deb package too? | 04:05 |
| duflu | Also, can anyone tell me what the changes are that we need in xserver-xorg-video-* ? | 04:06 |
| 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:09 |
| 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:10 |
| robert_ancell | X.org still uses mailing lists for patches right? | 04:11 |
| RAOF | Yes. | 04:11 |
| 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:12 |
| robert_ancell | RAOF, are those flags just ignored if the module isn't there? | 04:13 |
| RAOF | Not really. | 04:13 |
| 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:14 |
| duflu | Great another major compiz/unity regression I need to figure out and report | 04:15 |
| 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:03 |
| robert_ancell | it looks almost like libEGL.so.1 is not linked against libmirclient | 05:05 |
| robert_ancell | RAOF, where is your mesa branch again? | 05:06 |
| RAOF | robert_ancell: github.com/RAOF/mesa | 05:06 |
| duflu | robert_ancell, looks like a separate issue sorry | 05:11 |
| * duflu runs to the shop | 05:11 | |
| 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:15 |
| 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:16 |
| 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:17 |
| tvoss | robert_ancell, ack, although I have to say that it really only shows up in the weird builder configuration | 05:18 |
| 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:19 |
| 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:20 |
| robert_ancell | it might solve the immediate problem | 05:21 |
| RAOF | Eh, why not. | 05:27 |
| RAOF | It's not incorrect. | 05:27 |
| RAOF | Let me push that change... | 05:27 |
| 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:29 |
| 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:31 |
| 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:36 |
| 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:37 |
| duflu | That's a fair point, but it's a problem they should let the distro own | 05:38 |
| RAOF | Exactly. | 05:38 |
| tvoss | robert_ancell, https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown | 05:39 |
| robert_ancell | RAOF, will you run that through the PPAs and make sure all the armhf builds work? | 05:43 |
| RAOF | robert_ancell: Sure. | 05:46 |
| duflu | Awesome. GPU hang | 05:48 |
| 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:49 |
| ubot5 | Launchpad bug 1192908 in mesa (Ubuntu) "Mir/Mesa packaging have a dependency cycle so neither can build" [Medium,Triaged] | 05:49 |
| 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:50 |
| duflu | robert_ancell, OK so not directly related | 05:51 |
| duflu | But still both real issues | 05:51 |
| robert_ancell | yeah | 05:52 |
| 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 | 05:57 |
| 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:00 |
| 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:01 |
| 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:04 |
| tvoss | duflu, ack | 06:05 |
| 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:06 |
| duflu | tvoss: No, it's a really dumb bug: https://bugs.launchpad.net/launchpad/+bug/1194007 | 06:09 |
| ubot5 | Launchpad bug 1194007 in Launchpad itself "Launchpad jumps to invalid page: https://bugs.launchpad.net/baz/+bug/200" [Undecided,New] | 06:09 |
| RAOF | Damnit! What the hell is my laptop doing? | 06:10 |
| duflu | RAOF: Busy fan? I have that | 06:10 |
| duflu | Maybe because https://bugs.launchpad.net/ubuntu-power-consumption/+bug/1194004 | 06:11 |
| ubot5 | Launchpad bug 1194004 in compiz (Ubuntu) "Compiz wakes up 200Hz while the screen is locked" [Undecided,New] | 06:11 |
| RAOF | Busy fan, 5 second delay on typing. | 06:11 |
| duflu | Also, the compiz config is corrupt. It won't let me enter a valid frame rate | 06:12 |
| duflu | RAOF: Mesa rebuild hiccups... configure: error: Package requirements (libdrm_radeon >= 2.4.45) were not met: | 06:28 |
| tvoss | duflu, we need https://code.google.com/p/googlemock/issues/detail?id=79 to get rid of the local gmock version | 06:39 |
| duflu | tvoss: Can't quite approve yet: https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown/+merge/171017 | 06:43 |
| 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:44 |
| 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:45 |
| RAOF | The root cause would appear to be “Pre 2.6 kernels suck” :) | 06:47 |
| 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:48 |
| duflu | RAOF: Oooh you mean (memory)-swap-thrashing and not (buffer)-swap-thrashing like I am seeing?.. :) | 06:49 |
| RAOF | duflu: Indeed. memory-swap-thrashing. | 06:50 |
| duflu | Thrashing of disks, not of framebuffers | 06:51 |
| duflu | Hmm is it right that lightdm.conf ignores comments and typos? | 07:15 |
| 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:25 |
| 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:26 | |
| 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:27 |
| tvoss | RAOF, yup :) | 07:28 |
| 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:29 |
| didrocks | we can see that google-mock defines -pthread twice, one before the .la, one after, so it should be fine | 07:30 |
| 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:31 |
| 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:33 |
| 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:34 |
| RAOF | didrocks: Did I fix that in gtest before? I don't recall if I did :/ | 07:35 |
| didrocks | RAOF: no, it was just in case you did get that somewhere into saucy by any luck | 07:36 |
| RAOF | No, I haven't noticed that before. | 07:37 |
| didrocks | ok, I'll continue digging | 07:37 |
| 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:01 |
| tvoss | didrocks, looking | 08:04 |
| mlankhorst | RAOF: ping ;) | 08:17 |
| duflu | Me joins the queue to talk to RAOF [https://launchpad.net/~mir-team/+archive/staging/+build/4741584] | 08:23 |
| * duflu does too | 08:23 | |
| * mlankhorst hopes it's a fifo, not a stack | 08:26 | |
| * duflu push_front | 08:31 | |
| tvoss | didrocks, is it a good idea to rely on the deprecated autotools setup? | 08:34 |
| didrocks | tvoss: can you be more explicit? :) | 08:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| didrocks | let me check | 08:41 |
| didrocks | hum, it was remerged | 08:41 |
| didrocks | tvoss: different maintainers | 08:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| duflu | But you can argue that with all dependencies | 08:47 |
| tvoss | duflu, yup | 08:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| didrocks | tvoss: even without it | 08:53 |
| didrocks | tvoss: did you run make check? | 08:53 |
| tvoss | trying | 08:54 |
| tvoss | RAOF, ping | 08:57 |
| mlankhorst | no! | 08:59 |
| tvoss | mlankhorst, ? | 09:01 |
| tvoss | mlankhorst, oh sorry, I need to go to the queue | 09:02 |
| mlankhorst | :D | 09:02 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| tvoss | didrocks, thanks :) | 09:16 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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 |
| ubot5 | Launchpad bug 1194073 in Mir "debian/copyright is not up to date with latest files included in MIR" [High,Confirmed] | 09:57 |
| tvoss | didrocks, ack | 09:57 |
| 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:58 |
| 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) | 09:59 |
| 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:00 |
| 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:01 |
| didrocks | tvoss: we don't run tests on armhf? | 10:02 |
| 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:04 |
| duflu | Ah dependency madness | 10:05 |
| duflu | Though Mir does spend all its time in boost::asio stuff | 10:07 |
| duflu | I might have to learn what that is | 10:07 |
| tvoss | duflu, where do you see that? | 10:09 |
| duflu | tvoss: In kcachegrind | 10:09 |
| duflu | The boost/asio call graph is so huge and complex I haven't quite figured it out yet | 10:10 |
| didrocks | tvoss_: 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, too | 10:27 |
| didrocks | tvoss_: I would add them in a examples/ directory rather | 10:27 |
| 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:28 |
| 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:29 |
| 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:31 |
| 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:32 |
| tvoss_ | RAOF, installed from testing ppa, works fine :) | 10:37 |
| RAOF | tvoss_: Woot! | 10:38 |
| tvoss_ | RAOF, a crash in plymouth after login, but that has been reported since 11.10 | 10:39 |
| didrocks | tvoss_: urgh, lib is hardcoded as a destination in all MIR cmake file, I'm fixing it | 10:58 |
| RAOF | GRARGH! Why is my open() only being called _sometimes_?! | 11:00 |
| === mmrazik is now known as mmrazik|lunch | ||
| duflu | GMock! 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 | |
| mlankhorst | But it is the perfect time to write your own linker! :-) | 11:08 |
| tvoss_ | mlankhorst, rofl | 11:08 |
| 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:09 |
| mlankhorst | tvoss_: in a bit, need to finish my recompile first :-) | 11:10 |
| tvoss_ | mlankhorst, I have an amd here | 11:10 |
| mlankhorst | oh btw the kernel dma-buf slowness fixes for amd will be in 3.11 | 11:12 |
| tvoss_ | mlankhorst, \o/ | 11:14 |
| === mmrazik|lunch is now known as mmrazik | ||
| duflu | tvoss_, OK, done | 12:28 |
| duflu | https://code.launchpad.net/~vanvugt/mir/fix-1193020/+merge/171070 | 12:28 |
| === mzanetti is now known as mzanetti|lunch | ||
| tvoss | mlankhorst, finished your rebuild? | 12:40 |
| mlankhorst | tvoss: yeah but got preempted by a security update collission with -proposed | 12:58 |
| tvoss | mlankhorst, oh | 12:58 |
| === mzanetti|lunch is now known as mzanetti | ||
| mlankhorst | I'll check now | 12:59 |
| === greyback is now known as greyback|lunch | ||
| mlankhorst | tvoss: ok i installed it, what do I need to test? | 13:20 |
| tvoss | mlankhorst, restart, see if xmir runs and you are annoyed by the additional cursor distracting you permanently :) | 13:21 |
| mlankhorst | I only have 1 cursor when testing on radeon, fwiw | 13:23 |
| tvoss | mlankhorst, interesting | 13:29 |
| mlankhorst | then again might be intel too *checks* | 13:31 |
| mlankhorst | tvoss: oh there is a cursor in upper left | 13:31 |
| tvoss | mlankhorst, yup :) | 13:32 |
| mlankhorst | intel seems to be loaded | 13:32 |
| arsson | with nouvea still two cursors | 13:32 |
| 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:33 |
| 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:34 |
| mlankhorst | oh worse.. | 13:35 |
| mlankhorst | it just runs through an array with i915, radeon and nouveau and grabs the first one that works | 13:36 |
| mlankhorst | which fails when the first one in the array is not boot_vga | 13:37 |
| tvoss | mlankhorst, patches are welcome :) | 13:40 |
| mlankhorst | tvoss: unfortunately not very easy to do without udev discovery | 13:42 |
| === greyback|lunch is now known as greyback | ||
| * kgunn hoping mlankhorst hangs out here with us alot :) | 13:51 | |
| mlankhorst | I only have hybrid laptops to test nouveau with atm though ;P | 13:52 |
| mlankhorst | not even muxed | 13:52 |
| tvoss | mlankhorst, okay | 13:53 |
| 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:54 |
| katie | tvoss, ok, after 4.30 is ok for me | 13:55 |
| tvoss | katie, cool, thx | 13:55 |
| tvoss_ | kdub, ping | 14:49 |
| tvoss_ | kdub, mind taking a look at: https://code.launchpad.net/~vanvugt/mir/fix-1193020 | 14:49 |
| tvoss_ | ? | 14:49 |
| kdub | tvoss_, sure | 15:00 |
| kdub | good morning channel | 15:00 |
| tvoss_ | kdub, good morning, and thx | 15:00 |
| racarr | AAMorning | 15:08 |
| greyback | racarr: and a happy sober morning to you too | 15:28 |
| 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:30 |
| racarr | hangout? https://plus.google.com/hangouts/_/8015a964c25dbb4a92528d82f94676c27eb14a7a | 15:31 |
| greyback | coming | 15:32 |
| === mmrazik is now known as mmrazik|afk | ||
| kdub | is alf around today? | 16:00 |
| === dpm_ is now known as dpm | ||
| sil2100 | tvoss: hi! | 16:14 |
| sil2100 | tvoss: how's the PPA-setup going? | 16:14 |
| kgunn | kdub: national holiday for alf | 16:22 |
| kdub | ah, ok | 16:22 |
| kgunn | kdub: you stuck | 16:22 |
| kgunn | ? | 16:22 |
| kdub | eh, i know that resizing is probably needed for the xmir stuff, might get started on that | 16:23 |
| kdub | i tinkered with sf enough to see how it resizes last week while tinkering with driver refcounting :) | 16:24 |
| kgunn | kdub: cool | 16:44 |
| === olli__ is now known as olli | ||
| 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:04 |
| 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:05 |
| racarr | lol...khonos_uint32_t strikes again | 17:38 |
| kdub | anyone object to the separate libgraphicsplatform.so? (dlopen'd). its ready to land, last chance to object | 17:41 |
| 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? | 17:43 |
| kgunn | kdub: yep that's the idea | 18:14 |
| racarr | Lunching while bunches of things download on my phone :) | 18:19 |
| racarr | back soon | 18:19 |
| racarr | back :) | 18:51 |
| === francisco is now known as Guest80960 | ||
| kdub | racarr, ping | 22:12 |
| === kode54_ is now known as kode54 | ||
| 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:46 |
| racarr | as an optimization for the giant ullscreen shell with lots of transparency (which is what is happening now on SF) | 22:47 |
| racarr | Aha, the input stack gained support for resizing and moving | 22:49 |
| racarr | as a free bonus | 22:49 |
| kgunn | racarr: thats kinda cool | 22:50 |
| racarr | Just finishing off the "input shape" stuff for the shell | 22:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| kgunn | i actually want it to be wrong | 22:54 |
| kgunn | itd make sense | 22:54 |
| kgunn | searching entire fs for libmirserver0 | 22:54 |
| 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:56 |
| 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:57 | |
| * kgunn searches internet for best laptop combustion accelerant | 22:58 | |
| robert_ancell | kgunn, lightdm.log? It should show why it picked VT8 | 23:01 |
| kgunn | lightdm.log -> https://pastebin.canonical.com/93333/ | 23:04 |
| 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:05 |
| 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:06 |
| robert_ancell | kgunn, is that the whole usc log? It's truncated | 23:08 |
| kgunn | i can repaste the whole thing...that was the interesting bit | 23:09 |
| kgunn | https://pastebin.canonical.com/93335/ | 23:10 |
| kgunn | entire usc log ^ | 23:10 |
| kgunn | rebooting... | 23:11 |
| 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:16 |
| robert_ancell | kgunn, so that log shows you do have an out of date libmirserver0 - it doesn't have the --vt option | 23:17 |
| kgunn | robert_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_ancell | kgunn, Can you do a find in /usr/local etc, and see if you have some locally build one? | 23:21 |
| 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:22 |
| kgunn | Version: 0.0.1bzr29saucy0.79 | 23:23 |
| robert_ancell | kgunn, same | 23:24 |
| kgunn | robert_ancell: ok...fme....this is too weird | 23:24 |
| 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:25 |
| kgunn | oh...nvmd..i lied, typo | 23:26 |
| kgunn | damn it...May 20th | 23:26 |
| robert_ancell | whoops :) | 23:27 |
| * kgunn note to self...don't look for libmirserver0...but libmirserver* | 23:28 | |
| kgunn | robert_ancell: you have the patience of Job...thanks | 23:29 |
| kgunn | robert_ancell: i'll blow those away..purge again....and reinstall | 23:30 |
| robert_ancell | kgunn, you should be good to just reboot and try again | 23:31 |
| kgunn | reboot | 23:45 |
| robert_ancell | hmm, where is kgunn... | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
