| thomi | RAOF: any news? | 00:53 |
|---|---|---|
| thomi | or, too soon? :) | 00:53 |
| RAOF | thomi: I can't reproduce locally | 00:54 |
| thomi | hmmmmm | 00:54 |
| thomi | that's annoying | 00:54 |
| RAOF | You're on intel, right? | 00:54 |
| RAOF | What package versions do you have? | 00:55 |
| thomi | RAOF: let me see... | 00:55 |
| thomi | ugh, have to re-add the PPA, since I wiped the changes last time, one moment | 00:56 |
| * RAOF also has a sleeping baby in his arms, so will be a bit slow | 00:56 | |
| thomi | RAOF: sorry for the delay - which packagesa re you interested in? | 01:16 |
| RAOF | libegl1-mesa, xserver-xorg-core, xserver-xorg-video-intel | 01:16 |
| thomi | libegl1-mesa: 9.2~git20130628.g6b676e6-0ubunt | 01:18 |
| thomi | xserver-xorg-core: 2:1.13.3-0ubuntu13 | 01:18 |
| thomi | xserver-xorg-video-intel: 2:2.21.9-0ubuntu2 | 01:18 |
| thomi | looks like that first version was truncated a bit :-/ | 01:18 |
| * thomi notes with annoyance that mir_demo_server has moved back to /usr/bin | 01:19 | |
| * thomi wonders if mir_stress will move about under him as well | 01:19 | |
| RAOF | thomi: Hm. You're on raring, then? | 01:21 |
| thomi | uhhh... no, I shouldn't be | 01:22 |
| thomi | should be saucy, but it's an lxc container, so maybe something is broken | 01:22 |
| thomi | RAOF: what makes you think raring? | 01:22 |
| robert_ancell | thomi, Is the client API file descriptor leaking mentioned in mir-stress/src/client.cpp still valid? | 01:22 |
| RAOF | Because *** 2:1.14.1-0ubuntu0.6+xmir1 0 | 01:22 |
| RAOF | 500 http://ppa.launchpad.net/mir-team/staging/ubuntu/ saucy/main amd64 Packages | 01:22 |
| thomi | robert_ancell: I believe so - certainly no one has told me that it's been fixed. If the server-side problem has been fixed I can test it for you | 01:23 |
| thomi | robert_ancell: but I think that issue is still open? | 01:24 |
| robert_ancell | thomi, was there a bug about this? | 01:24 |
| * thomi searches | 01:24 | |
| thomi | there was certainly a lot of discussion :) | 01:24 |
| thomi | robert_ancell: problem description is here: https://bugs.launchpad.net/mir/+bug/1198022 | 01:56 |
| ubot5 | Launchpad bug 1198022 in Mir "mir client API leaks FD without an explicit close, which is unexpected" [Undecided,New] | 01:56 |
| thomi | RAOF: interestingly, it seems like when apt installed the packages it didn't get the latest versions, so a dist-upgrade may fix the problem | 01:58 |
| duflu | thomi: We have automated tests, which coupled with valgrind should report FD leaks. If it doesn't then we're missing a valgrind option somewhere | 02:01 |
| duflu | thomi: Like --track-fds=yes (default no) | 02:02 |
| thomi | duflu: I agree - it also requires that a test actually exercises that use case. I suspect this may be a case of my expectations being different to the original developers :) | 02:04 |
| thomi | I'll look into changing the valgrind options and seeing if it catches anything new | 02:05 |
| duflu | thomi: I mean, I know we have tests that should trigger leaks (if there are any) | 02:05 |
| duflu | We have full client lifecycle tests... | 02:05 |
| thomi | duflu: sure, but maybe whoever wrote them expected to have to close those FDs themselves, whereas my expectation was that mir would handle that for me | 02:06 |
| === csslayer_ is now known as csslayer | ||
| robert_ancell | thomi, what were you using to show there were open fds? | 02:18 |
| duflu | Hah. I've never seen a 50000 line MP before | 02:19 |
| thomi | robert_ancell: I discovered it when I hit the open FD limit in the stress test | 02:38 |
| thomi | robert_ancell: but valgrind with --track-fds should show it as well | 02:38 |
| robert_ancell | thomi, yes, I reproduced it now | 02:38 |
| thomi | cool | 02:42 |
| duflu | robert_ancell: A simpler way to track files is: ls -l /proc/$pid/fd/ | 02:47 |
| robert_ancell | duflu, I've also done that | 02:47 |
| robert_ancell | duflu, though valgrind it nice because it tells you where the fd came from | 02:48 |
| duflu | valgrind is nice for so many reasons... | 02:48 |
| duflu | Though I fear all the errors we are yet to discover using --tool=helgrind | 02:49 |
| duflu | ping RAOF | 03:20 |
| RAOF | duflu: Pong | 03:21 |
| RAOF | Mesa should work now, btw | 03:22 |
| duflu | RAOF: gbm_surface_lock_front_buffer ... what's the difference between the "front buffer" being locked and the "new one" returned? | 03:22 |
| * RAOF looks | 03:23 | |
| duflu | Oh... | 03:24 |
| * duflu afk briefly | 03:24 | |
| RAOF | duflu: Ok. So, gbm_surface_lock_front_buffer / | 03:38 |
| duflu | ? | 03:41 |
| RAOF | duflu: gbm_surface_lock_front_buffer just returns the current front buffer. It's there for integration with eglSwapBuffers - when you lock the front buffer it marks various internal bits.e | 03:44 |
| duflu | RAOF: Oh OK thanks. I misinterpreted "A new bo representing the new front buffer is returned" | 03:44 |
| duflu | It's not the "new" front buffer. It's the old one | 03:45 |
| RAOF | It's the front buffer that you should send to the output. | 03:45 |
| duflu | So sounds like the doxygen for gbm is wrong | 03:45 |
| duflu | But your explanation makes sense | 03:45 |
| duflu | Plus, the code works right now | 03:45 |
| RAOF | Heh. | 03:45 |
| RAOF | Oh, fun. the drm EGL platform is tripleish-buffered. | 03:46 |
| duflu | 3.141592653 buffers? | 03:50 |
| RAOF | It'll use up to three buffers. | 03:52 |
| darkxst | has anyone got Mir running under vmware? | 03:54 |
| darkxst | http://paste.ubuntu.com/5845576/ | 03:54 |
| duflu | darkxst: No I don't think so. It wasn't as simple as we expected and requires more work for a generic software rendering solution | 03:55 |
| darkxst | duflu, is there accellerated driver missing things? | 03:56 |
| duflu | RAOF ^ what was missing from VMware's DRI support? | 03:57 |
| RAOF | dma-buf support. | 03:57 |
| RAOF | With the new, improved, actually-probe-the-hardware gbm backend that should be the only thing blocking VMWare. | 03:57 |
| duflu | RAOF: The DMA requirement comes from Mir? Or GBM? | 03:58 |
| duflu | It's crazy that we're blocked on DMA-buf support, on a platform where it's all in system memory anyway :) | 03:59 |
| RAOF | Comes from Mir. | 03:59 |
| RAOF | We technically don't *need* dma-buf support - we could, and did, just use flink - but dma-buf is secure against id guessing. | 04:00 |
| RAOF | (And when I say “id guessing” what I mean is “guessing an integer id that starts at zero and is infrequently incremented”) | 04:00 |
| * duflu is still coming to grips with the fact that the front buffer is not always what's visible on screen. Too many abstractions... | 04:08 | |
| === Mirv_ is now known as Mirv | ||
| TheDrums | Virtualbox does nothing but crash too. | 04:15 |
| duflu_ | TheDrums: Yeah well VM support of any sort is not implemented yet. So it's not very surprising | 04:16 |
| === Debolaz is now known as Guest40169 | ||
| === zoktar_ is now known as zoktar | ||
| tvoss|errands | RAOF, ping | 05:02 |
| === tvoss|errands is now known as tvoss | ||
| RAOF | tvoss: Pong | 05:03 |
| tvoss | RAOF, good morning :) how goes? | 05:03 |
| RAOF | Well, albeit cold. | 05:03 |
| tvoss | RAOF, cold in your part of the world? | 05:04 |
| RAOF | Yup. | 05:04 |
| RAOF | Cold and bright this morning, then it started raining just after I'd got back from a walk with Zoë. | 05:04 |
| tvoss | RAOF, Bryce handed me some vm contacts for graphics drivers. | 05:05 |
| RAOF | As in - contacts for VM graphics driver developers? | 05:06 |
| * RAOF is not sure how to parse that. | 05:06 | |
| === duflu_ is now known as duflu | ||
| tvoss | RAOF, yup | 05:13 |
| * duflu thinks it's about time Linux stopped talking about CRTC's | 05:16 | |
| RAOF | tvoss: There's always Prf_Jakob :) | 05:25 |
| tvoss | RAOF, +1 | 05:25 |
| * RAOF wonders how the full-program optimisations of clang's -O4 would influence Mir performance | 06:00 | |
| tvoss | RAOF, sounds like fun :) I would also be curious to know how AddressSanitizer with gcc 4.8 works | 06:01 |
| duflu | RAOF: Anything above O2 is usually a bad idea. It creates much larger code, for little gain | 06:02 |
| RAOF | duflu: As far as I can tell, -O4 is (confusingly) not actually above O2 in that sense. | 06:03 |
| duflu | RAOF: Well, usually, around O1 is where superfluous code is removed, and O2/O3 is where speed optimizations (at the expense of size) kick in | 06:04 |
| RAOF | O4 is going to have more opportunity to remove superfluous code, too. | 06:06 |
| duflu | RAOF: Per the gcc man page, O2 is the highest level at which optimizations "do not involve a space-speed tradeoff" | 06:10 |
| duflu | You use O3 and above only if you're willing to have say a 20% larger binary that runs 2% faster | 06:11 |
| RAOF | duflu: But I'm talking about clang, where O4 is “compile to LLVM bytecode and then do an optimisation pass at link time” | 06:11 |
| duflu | Oh. Hmm yeah clang might treat the scale differently. Though it previously tried to match gcc | 06:12 |
| RAOF | I think it *does* match gcc. gcc doesn't *have* an -O4, though. | 06:12 |
| RAOF | I mean - match gcc where the range overlaps. | 06:13 |
| duflu | RAOF: On the subject of clang, last I checked Mir's test cases still failed when built with it. Best to solve that first :) | 06:28 |
| RAOF | duflu: Already done ☺: https://code.launchpad.net/~raof/mir/fix-clanger/+merge/172956 | 06:29 |
| duflu | RAOF: Still more to go methinks: https://bugs.launchpad.net/mir/+bugs?field.tag=clang | 06:31 |
| RAOF | Eh. clang-3.4 builds a testsuite that works for me. | 06:32 |
| duflu | Hmm, I might have to retest | 06:32 |
| RAOF | Man, it'll be nice to have a laptop that isn't always thermally throttled. | 06:33 |
| duflu | RAOF: which one did you order? | 06:33 |
| RAOF | A fully-specced galago. | 06:34 |
| RAOF | https://www.system76.com/laptops/model/galu1 | 06:34 |
| * duflu stops bashing his head against interfaces that don't actually support varying implementations and goes to look at hardware specs | 06:34 | |
| dholbach | good morning | 06:35 |
| duflu | Morning dholbach | 06:36 |
| dholbach | hi duflu | 06:36 |
| tvoss | ogra_, ping | 06:36 |
| tvoss | dholbach, morning :) | 06:36 |
| dholbach | hey tvoss | 06:36 |
| tvoss | didrocks, what's the default approach in ubuntu for installing documentation? a separate doc package? | 06:38 |
| didrocks | tvoss: yeah, see my change in location-service (or was it libusermetrics?) | 06:39 |
| tvoss | didrocks, I think location service | 06:39 |
| didrocks | tvoss: while I was looking at it: https://code.launchpad.net/~didrocks/location-service/devsuggestsdoc/+merge/173136 | 06:41 |
| RAOF | Hah. Well, that was short lived. Trunk introduces an ICE with clang-3.4 ☺ | 06:47 |
| alf | RAOF: did you get a chance to take a look at the Mesa pull request? | 07:32 |
| RAOF | alf: Let me check now. Have the mir-side chanegs landed? | 07:33 |
| alf | RAOF: they are on their way there (waiting for jenking to perform autolanding) | 07:34 |
| RAOF | LGTM | 07:35 |
| RAOF | Thermally throtttled laptop running the testsuite under valgrind. It's poetry in motion. | 07:37 |
| === Cimi_ is now known as Cimi | ||
| alf | RAOF: mir changes done, feel free to merge mesa changes if everything is ok | 08:29 |
| * RAOF hits the button, and refreshes the packaging. | 08:32 | |
| RAOF | alf: Was https://code.launchpad.net/~raof/mir/udev-wrapper/+merge/173151 the sort of thing you were thinking of? | 08:33 |
| alf | RAOF: I haven't looked at the details yet, but the interfaces look good | 08:37 |
| alf | RAOF: One thing that caught my eye, do we really need CopyAssign for the wrappers? | 08:37 |
| RAOF | alf: They're refcounted, so CopyAssign is cheap, and I'm pretty sure I pass-by-value somewhere in there. | 09:03 |
| RAOF | Or, at least, I'm pretty sure UdevContext gets copy-constructed somewhere in there. | 09:04 |
| tvoss | didrocks, mind having a look: https://code.launchpad.net/~thomas-voss/platform-api/add-documentation-part-1 | 09:14 |
| tvoss | ? | 09:14 |
| didrocks | tvoss: kind reping on https://code.launchpad.net/~didrocks/location-service/devsuggestsdoc/+merge/173136 if you didn't see it :p | 09:14 |
| tvoss | didrocks, sorry :) lost in doc land | 09:15 |
| didrocks | tvoss: mind making a MP of your branch? will be easier :) | 09:15 |
| tvoss | didrocks, https://code.launchpad.net/~thomas-voss/platform-api/add-documentation-part-1/+merge/173159 | 09:16 |
| didrocks | tvoss: thanks! | 09:17 |
| tvoss | didrocks, ack | 09:17 |
| * tvoss grabs coffee | 09:17 | |
| didrocks | tvoss: it seems to me you have unrelated diff like the addition of libubuntu_platform_hardware_api, and others changes | 09:30 |
| didrocks | tvoss: the symbols file is wrong, you didn't follow the doc I guess for C++ symbols :p | 09:30 |
| didrocks | and didn't change that by 0replaceme either | 09:30 |
| didrocks | conflict in debian/changelog btw ;) | 09:30 |
| didrocks | and no -doc package | 09:31 |
| tvoss | didrocks, hmmm, you told me I could happily copy over the symbols file :/ | 09:32 |
| didrocks | tvoss: for non C++ packages right, you ask me in big lines | 09:32 |
| didrocks | tvoss: I pointed you to a documentation with step by steps instruction, please read it :p | 09:32 |
| didrocks | I didn't write it for my own pleasure :p | 09:33 |
| tvoss | didrocks, the platform api is not C++, only parts of its implementation | 09:33 |
| didrocks | tvoss: yeah, that's why you have mangled symbols | 09:33 |
| tvoss | didrocks, I will hide them from the abi then. That should avoid the need to have them in the symbols file, right? | 09:33 |
| didrocks | tvoss: if they shouldn't be exported, yeah, it's better to hide them | 09:34 |
| didrocks | and they won't be list in the symbols file | 09:34 |
| didrocks | listed* | 09:34 |
| ogra_ | tvoss, hey | 09:54 |
| tvoss | ogra_, salut :) | 09:55 |
| alan_g | tvoss: I think you're right - we need pkg-config, which doesn't exist in the cross-compile job | 10:03 |
| tvoss | alan_g, weird | 10:03 |
| tvoss | didrocks, is pkg-config part of build-essential? | 10:03 |
| didrocks | tvoss: no, you need to build-dep on it | 10:04 |
| tvoss | didrocks, cool, thx | 10:04 |
| didrocks | yw ;) | 10:04 |
| didrocks | (I tend to put it in the top, next to eventual gcc, just after debhelper/cmake) | 10:05 |
| * alan_g doesn't understand - that's https://code.launchpad.net/~alan-griffiths/mir/fix-1196987/+merge/172798 line 66 | 10:06 | |
| alan_g | but the cross-compile does thins in mysterious (and fragile) ways | 10:08 |
| alan_g | didrocks: can you see what I've done wrong? Here: https://code.launchpad.net/~alan-griffiths/mir/fix-1196987/+merge/172798 doesn't find pkg-config on the cross-compile job https://jenkins.qa.ubuntu.com/job/mir-android-saucy-i386-build/1179/console | 10:11 |
| didrocks | alan_g: is pkgconfig in the package build-deps? | 10:11 |
| alan_g | didrocks: that's what I hope diff line 66 does | 10:12 |
| didrocks | as I told, it's not part of build-essentials | 10:12 |
| didrocks | line 66? I see 66- message(STATUS "Tests are run with real graphics.") | 10:12 |
| alan_g | Opps, looking at old webpage | 10:13 |
| didrocks | :) | 10:13 |
| didrocks | alan_g: oh, the job is not using the package build-deps | 10:14 |
| didrocks | what's this job? it's ackish | 10:14 |
| didrocks | hackish* | 10:14 |
| didrocks | even | 10:14 |
| alan_g | didrocks: it is horribly fragile too | 10:15 |
| didrocks | urgh tools/setup-partial-armhf-chroot.sh | 10:15 |
| didrocks | all build-deps repeated :/ | 10:15 |
| didrocks | and you don't have pkg-config in it | 10:16 |
| didrocks | while in debian/control, for the package build-deps, you have it | 10:16 |
| didrocks | this is a recipe for failure, not sure why it's there, but I think we should work on a better solution | 10:16 |
| didrocks | at least, taking the build-deps from the packaging and handle the cross-arch case | 10:16 |
| alan_g | Agreed (and am on record saying it_ | 10:16 |
| didrocks | :) | 10:16 |
| didrocks | dpkg-checkbuilddeps -a armhf | 10:17 |
| didrocks | run in the source directory | 10:17 |
| didrocks | should list all needed deps to be installed | 10:17 |
| didrocks | (forcing armhf in that case) | 10:17 |
| didrocks | rm ./usr/lib/arm-linux-gnueabihf/libEGL.so | 10:18 |
| didrocks | rm ./usr/lib/arm-linux-gnueabihf/libGLESv2.so | 10:18 |
| didrocks | ln -s libhybris-egl/libEGL.so.1 ./usr/lib/arm-linux-gnueabihf/libEGL.so | 10:19 |
| didrocks | ln -s libhybris-egl/libGLESv2.so.2 ./usr/lib/arm-linux-gnueabihf/libGLESv2.so | 10:19 |
| didrocks | waow :) | 10:19 |
| alan_g | In this case my problem is orthogonal to that mess - as I don't want the armhf pkg-config | 10:19 |
| didrocks | alan_g: hum, you are calling find_package( PkgConfig ), right? you need to have at least a pkg-config installed | 10:20 |
| alan_g | yes | 10:20 |
| didrocks | alan_g: and it seems that the job is ignoring all build-deps on the machine and need to have this list setup | 10:20 |
| didrocks | in tools/setup-partial-armhf-chroot.sh | 10:20 |
| alan_g | That would be more reasonable than the current hack (but isn't my priority this morning) | 10:21 |
| didrocks | alan_g: I think you just need to add pkg-config to the list in tools/setup-partial-armhf-chroot.sh | 10:22 |
| didrocks | then, this would install it in this jenkins job | 10:22 |
| alan_g | Won't that just put the armhf version into the chroot? | 10:22 |
| * alan_g might as well try it anyway | 10:22 | |
| didrocks | alan_g: yeah, but that should be what you want? I have no idea what this hack is doing other than installing the armhf version for everything in the jenkins jobs apparently (for cross-build) | 10:23 |
| alan_g | didrocks: I *think* that as cmake is run outside the chroot it will wants the host version. But I'll try it. | 10:28 |
| didrocks | alan_g: | 10:28 |
| didrocks | ah | 10:29 |
| didrocks | if cmake is run outside the chroot, yeah, that won't help | 10:29 |
| === alan_g is now known as alan_g|afk | ||
| didrocks | not sure how this job is setup, but manual install on the machine seems to be the only way then | 10:29 |
| didrocks | (yeah for non maintenable jobs :p) | 10:29 |
| tvoss | didrocks, mind taking another look at: https://code.launchpad.net/~thomas-voss/platform-api/introduce-hardware-subdirectory-and-package/+merge/169458? | 10:31 |
| didrocks | tvoss: the symbols file looks better :) there are still my remarks about conflicts in debian/changelog, missing -doc package and so on though ;) | 10:33 |
| tvoss | didrocks, that's not the same mp | 10:33 |
| didrocks | tvoss: ah good, the diff wasn't regenerated :) | 10:34 |
| didrocks | tvoss: 343+ _Z24ua_sensors_light_disablePv@Base 0.18.1daily13.06.21 | 10:35 |
| didrocks | you still expose that one ^ | 10:35 |
| === alan_g|afk is now known as alan_g | ||
| didrocks | (and there is still the conflict in debian/changelog, even if it's another MP ;)) | 10:36 |
| alan_g | didrocks: thanks | 10:36 |
| didrocks | tvoss: I guess the ABI for libunity_application and libubuntu-platform will evolve in sync? | 10:36 |
| tvoss | didrocks, what is libunity application? | 10:36 |
| didrocks | autotyping | 10:37 |
| didrocks | libunbuntu-application | 10:37 |
| didrocks | ubuntu* | 10:37 |
| tvoss | yup, at least for now | 10:37 |
| didrocks | tvoss: ok, but this change requests a rebuild of everything rebuilding against those libs | 10:39 |
| didrocks | do you know what's using it, if any? | 10:39 |
| tvoss | didrocks, sorry, I cannot follow you | 10:39 |
| didrocks | tvoss: as you separate now some symbols from one lib to another | 10:40 |
| didrocks | what are using those symbols needs to be rebuild against latest | 10:40 |
| didrocks | to link against the right lib | 10:40 |
| didrocks | basically, all rdepends of libplatform-api1-hybris | 10:40 |
| tvoss | sure, I would assume that is automatically tracked and done | 10:40 |
| didrocks | (and this breaks the ABI, right?) | 10:40 |
| didrocks | tvoss: tracked and done by what? | 10:40 |
| tvoss | didrocks, some clever build system? | 10:41 |
| didrocks | the build system needs manual rebuilds | 10:41 |
| didrocks | and upstream would need to bump ABI as a clever upstream :p | 10:41 |
| didrocks | here, we have none of those, so we have to do that manually, ensuring the upgrade path and so on | 10:42 |
| tvoss | didrocks, sorry, I cannot follow: what do I have to do to make this land? | 10:42 |
| didrocks | tvoss: https://wiki.ubuntu.com/DailyRelease/FAQ#I_need_to_break_an_API.2BAC8-ABI | 10:42 |
| didrocks | (it's weird that you are adding a changelog not on top of debian/changelog btw, with a higher version) | 10:43 |
| tvoss | didrocks, is there the executive summary of steps that I need to do somewhere? seriously, we shouldn't expect our devs to go through this procedure for every change, turnaround time is way too high and I wouldn't call this agile anymore | 10:44 |
| didrocks | tvoss: feel free to create them | 10:44 |
| didrocks | tvoss: breaking ABI a lot isn't agile as well | 10:45 |
| didrocks | tvoss: we have tools that we have and need to deal with those by creating procedure | 10:45 |
| tvoss | didrocks, how do we plan to keep the mir development at high pace then? We are going to break the abi regularly | 10:46 |
| didrocks | tvoss: yeah, I'll have a hack for this, but it's a hack | 10:46 |
| didrocks | similar to nux and compiz | 10:46 |
| tvoss | didrocks, how does that work? | 10:47 |
| didrocks | tvoss: mind having a hangout? will be easier | 10:47 |
| tvoss | let me grab coffee and eat something ... 10 minutes? | 10:47 |
| didrocks | yep | 10:47 |
| alan_g | tvoss: since mmrazik left do we have a preferred contact for our jenkins setup? | 10:47 |
| tvoss | alan_g, not that I know of | 10:48 |
| tvoss | didrocks, updated: https://code.launchpad.net/~thomas-voss/platform-api/introduce-hardware-subdirectory-and-package/+merge/169458 | 10:55 |
| didrocks | tvoss: bzr bd gives me: | 10:55 |
| didrocks | - ua_sensors_light_disable(void*)@Base 0.18.1daily13.06.21 | 10:55 |
| didrocks | +#MISSING: 0.18.1+13.10.20130705-0ubuntu1# ua_sensors_light_disable(void*)@Base 0.18.1daily13.06.21 | 10:55 |
| didrocks | you hide it, not unmangle it, isn't it? | 10:56 |
| didrocks | * remove the change in debian/changelog, it will be injected once merged into trunk and on top from the commit message | 10:56 |
| tvoss | didrocks, nope, it is pulled in as a C++ symbol, let me check why that is the case | 10:57 |
| didrocks | tvoss: + _Z24ua_sensors_light_disablePv@Base 0.18.1+13.10.20130705-0ubuntu1 | 10:58 |
| didrocks | tvoss: it's not unmangled properly it seems | 10:58 |
| tvoss | mzanetti, I think alan_g needs some help with Jenkins | 11:01 |
| mzanetti | ok... | 11:02 |
| * mzanetti needs a little more details :) | 11:03 | |
| tvoss | alan_g, mzanetti is your poc :) | 11:03 |
| hikiko | hi :) | 11:03 |
| mzanetti | hi hikiko :) | 11:03 |
| alan_g | mzanetti: there's a rather hacked job - mir-android-saucy-i386-build | 11:03 |
| hikiko | anyone who has worked on android-mir? (except kdub who has a us timezone and I guess is sleeping right now :)) | 11:04 |
| hikiko | I'd like to build mir for android | 11:04 |
| alan_g | mzanetti: which ought to have pkg-config installed, but doesn't | 11:04 |
| hikiko | and run it there | 11:04 |
| alan_g | hikiko: you've read the instructions right? | 11:05 |
| hikiko | but I only know how to crosscompile it | 11:05 |
| hikiko | mmm I read some instructions alan_g | 11:05 |
| hikiko | maybe not the correct sec :) i ll check again :) | 11:05 |
| alan_g | hikiko: it helps to know where you are stuck | 11:05 |
| hikiko | alan_g, nowhere :D | 11:05 |
| hikiko | I fixed the issue I had | 11:06 |
| mzanetti | alan_g: it looks like Umockdev is not installed | 11:06 |
| hikiko | and gbm works | 11:06 |
| mzanetti | alan_g: you sure its a pkgconfig issue and not a missing build dep in your package? | 11:06 |
| hikiko | so I want to do a minimal android nested platform | 11:06 |
| hikiko | and an MP | 11:06 |
| alan_g | mzanetti: the job ignores the build-deps | 11:06 |
| hikiko | so that I can move on with what you suggested next week :) | 11:06 |
| mzanetti | alan_g: hmm... thats not what it should do, or am I wrong? | 11:07 |
| alan_g | mzanetti: there's a rather hacked job - mir-android-saucy-i386-build | 11:07 |
| hikiko | after I get your (mir-team) feedback for the "dummy" nested platforms | 11:07 |
| mzanetti | alan_g: yeah... I'm looking through that right now | 11:07 |
| mzanetti | alan_g: ah... found it... it installs all the stuff manually | 11:08 |
| mzanetti | alan_g: so should I just add the udevmockd there and thats it? | 11:08 |
| mzanetti | or where does that come from? | 11:09 |
| alan_g | mzanetti: No, umockdev is just a victim | 11:09 |
| alan_g | mzanetti: what is needed is pkg-config in the host environment, not umockdev in the cross-compile "chroot" | 11:10 |
| tvoss | didrocks, sent you a hangout invite | 11:11 |
| didrocks | tvoss: let me switch to chrome | 11:11 |
| mzanetti | alan_g: ok. I don't yet exactly understand how that job works so I just did what you said. This one installs pkg-config now: http://s-jenkins:8080/job/mir-android-saucy-i386-build/1182/console | 11:12 |
| mzanetti | lets see how it goes | 11:12 |
| alan_g | mzanetti: Its OK not to understand, it has taken me some time to work out what is happening (and I still don't want to believe it) | 11:13 |
| mzanetti | alan_g: yep... it got over the cmake step | 11:14 |
| mzanetti | alan_g: everything fine now? | 11:14 |
| alan_g | mzanetti: thanks - I've added introducing sanity to this job to my backlog | 11:15 |
| mzanetti | alan_g: ok cool. feel free to ping me in urgent cases where the US timezone is not up | 11:16 |
| alan_g | mzanetti: I hope you don't regret that offer. ;) | 11:16 |
| mzanetti | hehe... I'll demand beer at the next sprint if you overuse it | 11:17 |
| tvoss | alan_g, \o/ | 12:06 |
| === Guest40169 is now known as Debolaz | ||
| alan_g | tvoss: it still hasn't landed | 12:07 |
| === alan_g is now known as alan_g|lunch | ||
| tvoss | alan_g|lunch, is it top-approved, yet? | 12:08 |
| === yofel is now known as Guest6895 | ||
| === alan_g|lunch is now known as alan_g | ||
| === Debolaz is now known as Guest88166 | ||
| === Guest6895 is now known as yofel | ||
| tvoss | didrocks, https://code.launchpad.net/~thomas-voss/platform-api/introduce-hardware-subdirectory-and-package/+merge/169458 | 13:39 |
| tvoss | alf, mind hopping into #qa? | 13:44 |
| alf | tvoss: sure | 13:44 |
| tvoss | alf, cancel that | 13:44 |
| alf | tvoss: sure :) | 13:45 |
| tvoss | E_PARENTHESIS_MISMATCH | 13:45 |
| tvoss | didrocks, https://code.launchpad.net/~thomas-voss/platform-api/add-documentation-part-1 | 13:52 |
| tvoss | bregma, ping | 13:53 |
| bregma | tvoss, pong | 13:53 |
| tvoss | bregma, hey there :) you looking into https://bugs.launchpad.net/mir/+bug/1195260? | 13:53 |
| bregma | tvoss, I was but (1) PPC pbuilder/qemu hangs and (b) https://bugs.launchpad.net/mir/+bug/1195265 took precedence | 13:55 |
| === Guest88166 is now known as Debolaz | ||
| bregma | if you want to take 1195260 over be my gues :) | 13:55 |
| tvoss | bregma, okay, I think disabling the tests for powerpc with the help of the global option from https://code.launchpad.net/~alan-griffiths/mir/fix-1196987/+merge/172798 should be quick way to fix it | 13:56 |
| tvoss | bregma, just wanted to do it, but my Firday evening meeting marathon is about to begin :) | 13:57 |
| === Stskeepz is now known as Stskeeps | ||
| didrocks | tvoss: bregma: +1 on disabling tests on ppc | 14:06 |
| bregma | I think we'll want to disable integration tests on armhf as well, until someone else can figure out why they fail on some hardware and not others | 14:07 |
| tvoss | bregma, +1 | 14:18 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| didrocks | tvoss: bregma: not in favor on this one | 14:54 |
| didrocks | tvoss: bregma: at least, it's fine for the ppa, but not for entering distro | 14:54 |
| kdub | hey racarr, could you take a look at remove-surface-target? just merging in the 'InputRegion' changes now, but you could still get a good feel for what's going on | 16:21 |
| kdub | its one of those merge conflicts where there's actually something different happening between the two branches | 16:22 |
| greyback | kdub: I've heard he's on holidays today | 16:29 |
| kdub | ah | 16:29 |
| kdub | thanks greyback | 16:30 |
| greyback | np | 16:30 |
| * kdub rewrites input stack.... muahaha | 16:31 | |
| tvoss | kdub, rofl | 16:33 |
| kdub | :d | 16:40 |
| alan_g | The sun is shining, I'm tempted to start the weekend 10 min early today. | 16:47 |
| === alan_g is now known as alan_g|EOW | ||
| kdub | alan_g|EOW, enjoy! | 16:50 |
| === francisco is now known as Guest44759 | ||
| bregma | someone forgot 'bzr add' ? | 18:15 |
| kdub | hmm? | 18:16 |
| kdub | bregma, i just fired off a compile of lp:mir, went fine for me :) | 18:25 |
| bregma | kdub, I caughtthe xmir_debug_guide merge half way in, it's OK now | 18:27 |
| bregma | of course, if you were trying to build on arm like I am it's be a looooong while before you found out it compiles fine | 18:28 |
| kdub | bregma, not sure what your workflow is... but if you need faster compiles, we have some cross compile scripts | 18:31 |
| bregma | I'm trying to run the integration tests on arm, as far as I can tell cross compiles won't help | 18:32 |
| * kdub tries armhf compile... | 18:35 | |
| kdub | lp:mir integration tests seem ok to me on nex4 | 18:38 |
| kdub | bregma, is there a pastebin of what you're seeing | 18:38 |
| bregma | TestClientIPCRender.render_accelerated deadlocks waiting for a buffer swap, running on a nexu7 | 18:41 |
| bregma | if you're enthuisiastic, http://paste.debian.net/14611/ for the output log (I've added tracing printfs) | 18:43 |
| kdub | same problem from a few days ago? | 18:44 |
| bregma | yep | 18:45 |
| bregma | not going away by itself :( | 18:45 |
| kdub | bregma, but it works without valgrind? | 18:46 |
| bregma | nope, still deadlocks | 18:46 |
| bregma | the child process exits while the parent is waiting on the buffer swap | 18:47 |
| bregma | unfortunately after a couple of days I have only the vaguest understanding of the internal dataflow of mir | 18:49 |
| bregma | firehose won't turn off | 18:49 |
| kdub | bregma, let me see if i can test mine really quickly... | 18:53 |
| kdub | the n7 is like our forgotten stepchild, the focus is the gnex/nex4 at the moment | 18:53 |
| bregma | it's the only arm device I have that runs touch | 18:58 |
| bregma | qemu doesn't cut the mustard either | 18:58 |
| kdub | bregma, yeah..., there's a few people in that boat (i think mterry as well) | 19:00 |
| kdub | interesting... mine went ok | 19:01 |
| bregma | I have a xformer but it's running precise (hmmm, hobby project for the weeken.... ideal target for Unity 8 Desktop) | 19:01 |
| kdub | bregma, are you running as root? | 19:02 |
| bregma | certainly not, that's anathema | 19:02 |
| bregma | should I? | 19:02 |
| kdub | i don't know if we checked the permissions on the /dev stuff for the n7 | 19:02 |
| kdub | n4/gnex don't need root, but we had to change some permissions I think | 19:03 |
| bregma | well, it doesn;t seem to make a difference | 19:04 |
| kdub | hmm, trying to think what the difference might be | 19:05 |
| bregma | I'm trying to fix https://bugs.launchpad.net/mir/+bug/1195265 which happens on the buildbots, but it's possible there are two different hang problems on the two different hardwares | 19:05 |
| ubot5 | Ubuntu bug 1195265 in Mir "tests stuck on armhf" [Critical,In progress] | 19:05 |
| kdub | bregma, we might need some sync for what's going on... is there a drive to get android under integration testing? | 19:09 |
| kdub | (which would make me happy :) ) | 19:10 |
| bregma | android is the primary target, there is a drive to get mir into daily builds and then into universe so we can include it in main ASAP so we can ship as the default in 13.10 | 19:11 |
| bregma | just that simple, really | 19:11 |
| bregma | we have a cunning plan | 19:11 |
| bregma | but successful builds on arm are blocking everything | 19:11 |
| bregma | and Didier won;t let us just disable the test | 19:12 |
| kdub | right :) that test goes and hits the drivers | 19:13 |
| bregma | I'm all for disabling just that test, since if it uses the actual drivers it's not a valid generic test | 19:14 |
| kdub | right, i think at this time, we just guarantee that the tests all work on gnex/nex4 | 19:15 |
| kdub | although the nex7 is (as you've no doubt seen) very close | 19:15 |
| bregma | well, to get into Ubuntu (the short-term goal) we need to make sure all the tests pass on the ubuntu buildbots -- I'm not even sure what kind of hardware that is, but relying on hardware drivers in an sbuild environment is typically a no-no | 19:21 |
| bregma | are there any other tests that exercise the drivers or is it limited to TestClientIPCRender ? | 19:22 |
| kdub | the only mir rule is that unit tests don't touch the driver | 19:26 |
| kdub | bregma, i guess the mir team has work items, which are to get the generic arm builders to run only generic tests | 19:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!