[00:53] <thomi> RAOF: any news?
[00:53] <thomi> or, too soon? :)
[00:54] <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:55] <RAOF> What package versions do you have?
[00:55] <thomi> RAOF: let me see...
[00:56] <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
[01:16] <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:18] <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:19]  * 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:21] <RAOF> thomi: Hm. You're on raring, then?
[01:22] <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:23] <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:24] <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:56] <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:58] <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
[02:01] <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:02] <duflu> thomi: Like --track-fds=yes (default no)
[02:04] <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:05] <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:06] <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
=== csslayer_ is now known as csslayer
[02:18] <robert_ancell> thomi, what were you using to show there were open fds?
[02:19] <duflu> Hah. I've never seen a 50000 line MP before
[02:38] <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:42] <thomi> cool
[02:47] <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:48] <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:49] <duflu> Though I fear all the errors we are yet to discover using --tool=helgrind
[03:20] <duflu> ping RAOF
[03:21] <RAOF> duflu: Pong
[03:22] <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:23]  * RAOF looks
[03:24] <duflu> Oh...
[03:24]  * duflu afk briefly
[03:38] <RAOF> duflu: Ok. So, gbm_surface_lock_front_buffer /
[03:41] <duflu> ?
[03:44] <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:45] <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:46] <RAOF> Oh, fun. the drm EGL platform is tripleish-buffered.
[03:50] <duflu> 3.141592653 buffers?
[03:52] <RAOF> It'll use up to three buffers.
[03:54] <darkxst> has anyone got Mir running under vmware?
[03:54] <darkxst> http://paste.ubuntu.com/5845576/
[03:55] <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:56] <darkxst> duflu, is there accellerated driver missing things?
[03:57] <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:58] <duflu> RAOF: The DMA requirement comes from Mir? Or GBM?
[03:59] <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.
[04:00] <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:08]  * duflu is still coming to grips with the fact that the front buffer is not always what's visible on screen. Too many abstractions...
=== Mirv_ is now known as Mirv
[04:15] <TheDrums> Virtualbox does nothing but crash too.
[04:16] <duflu_> TheDrums: Yeah well VM support of any sort is not implemented yet. So it's not very surprising
=== Debolaz is now known as Guest40169
=== zoktar_ is now known as zoktar
[05:02] <tvoss|errands> RAOF, ping
=== tvoss|errands is now known as tvoss
[05:03] <RAOF> tvoss: Pong
[05:03] <tvoss> RAOF, good morning :) how goes?
[05:03] <RAOF> Well, albeit cold.
[05:04] <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:05] <tvoss> RAOF, Bryce handed me some vm contacts for graphics drivers.
[05:06] <RAOF> As in - contacts for VM graphics driver developers?
[05:06]  * RAOF is not sure how to parse that.
=== duflu_ is now known as duflu
[05:13] <tvoss> RAOF, yup
[05:16]  * duflu thinks it's about time Linux stopped talking about CRTC's
[05:25] <RAOF> tvoss: There's always Prf_Jakob :)
[05:25] <tvoss> RAOF, +1
[06:00]  * RAOF wonders how the full-program optimisations of clang's -O4 would influence Mir performance
[06:01] <tvoss> RAOF, sounds like fun :) I would also be curious to know how AddressSanitizer with gcc 4.8 works
[06:02] <duflu> RAOF: Anything above O2 is usually a bad idea. It creates much larger code, for little gain
[06:03] <RAOF> duflu: As far as I can tell, -O4 is (confusingly) not actually above O2 in that sense.
[06:04] <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:06] <RAOF> O4 is going to have more opportunity to remove superfluous code, too.
[06:10] <duflu> RAOF: Per the gcc man page, O2 is the highest level at which optimizations "do not involve a space-speed tradeoff"
[06:11] <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:12] <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:13] <RAOF> I mean - match gcc where the range overlaps.
[06:28] <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:29] <RAOF> duflu: Already done ☺: https://code.launchpad.net/~raof/mir/fix-clanger/+merge/172956
[06:31] <duflu> RAOF: Still more to go methinks: https://bugs.launchpad.net/mir/+bugs?field.tag=clang
[06:32] <RAOF> Eh. clang-3.4 builds a testsuite that works for me.
[06:32] <duflu> Hmm, I might have to retest
[06:33] <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:34] <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:35] <dholbach> good morning
[06:36] <duflu> Morning dholbach
[06:36] <dholbach> hi duflu
[06:36] <tvoss> ogra_, ping
[06:36] <tvoss> dholbach, morning :)
[06:36] <dholbach> hey tvoss
[06:38] <tvoss> didrocks, what's the default approach in ubuntu for installing documentation? a separate doc package?
[06:39] <didrocks> tvoss: yeah, see my change in location-service (or was it libusermetrics?)
[06:39] <tvoss> didrocks, I think location service
[06:41] <didrocks> tvoss: while I was looking at it: https://code.launchpad.net/~didrocks/location-service/devsuggestsdoc/+merge/173136
[06:47] <RAOF> Hah. Well, that was short lived. Trunk introduces an ICE with clang-3.4 ☺
[07:32] <alf> RAOF: did you get a chance to take a look at the Mesa pull request?
[07:33] <RAOF> alf: Let me check now. Have the mir-side chanegs landed?
[07:34] <alf> RAOF: they are on their way there (waiting for jenking to perform autolanding)
[07:35] <RAOF> LGTM
[07:37] <RAOF> Thermally throtttled laptop running the testsuite under valgrind. It's poetry in motion.
=== Cimi_ is now known as Cimi
[08:29] <alf> RAOF: mir changes done, feel free to merge mesa changes if everything is ok
[08:32]  * RAOF hits the button, and refreshes the packaging.
[08:33] <RAOF> alf: Was https://code.launchpad.net/~raof/mir/udev-wrapper/+merge/173151 the sort of thing you were thinking of?
[08:37] <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?
[09:03] <RAOF> alf: They're refcounted, so CopyAssign is cheap, and I'm pretty sure I pass-by-value somewhere in there.
[09:04] <RAOF> Or, at least, I'm pretty sure UdevContext gets copy-constructed somewhere in there.
[09:14] <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:15] <tvoss> didrocks, sorry :) lost in doc land
[09:15] <didrocks> tvoss: mind making a MP of your branch? will be easier :)
[09:16] <tvoss> didrocks, https://code.launchpad.net/~thomas-voss/platform-api/add-documentation-part-1/+merge/173159
[09:17] <didrocks> tvoss: thanks!
[09:17] <tvoss> didrocks, ack
[09:17]  * tvoss grabs coffee
[09:30] <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:31] <didrocks> and no -doc package
[09:32] <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:33] <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:34] <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:54] <ogra_> tvoss, hey
[09:55] <tvoss> ogra_, salut :)
[10:03] <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:04] <didrocks> tvoss: no, you need to build-dep on it
[10:04] <tvoss> didrocks, cool, thx
[10:04] <didrocks> yw ;)
[10:05] <didrocks> (I tend to put it in the top, next to eventual gcc, just after debhelper/cmake)
[10:06]  * alan_g doesn't understand - that's https://code.launchpad.net/~alan-griffiths/mir/fix-1196987/+merge/172798 line 66
[10:08] <alan_g> but the cross-compile does thins in mysterious (and fragile) ways
[10:11] <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:12] <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:13] <alan_g> Opps, looking at old webpage
[10:13] <didrocks> :)
[10:14] <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:15] <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:16] <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:17] <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:18] <didrocks>     rm ./usr/lib/arm-linux-gnueabihf/libEGL.so
[10:18] <didrocks>     rm ./usr/lib/arm-linux-gnueabihf/libGLESv2.so
[10:19] <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:20] <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:21] <alan_g> That would be more reasonable than the current hack (but isn't my priority this morning)
[10:22] <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:23] <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:28] <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:29] <didrocks> ah
[10:29] <didrocks> if cmake is run outside the chroot, yeah, that won't help
=== alan_g is now known as alan_g|afk
[10:29] <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:31] <tvoss> didrocks, mind taking another look at: https://code.launchpad.net/~thomas-voss/platform-api/introduce-hardware-subdirectory-and-package/+merge/169458?
[10:33] <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:34] <didrocks> tvoss: ah good, the diff wasn't regenerated :)
[10:35] <didrocks> tvoss: 343+ _Z24ua_sensors_light_disablePv@Base 0.18.1daily13.06.21
[10:35] <didrocks> you still expose that one ^
=== alan_g|afk is now known as alan_g
[10:36] <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:37] <didrocks> autotyping
[10:37] <didrocks> libunbuntu-application
[10:37] <didrocks> ubuntu*
[10:37] <tvoss> yup, at least for now
[10:39] <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:40] <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:41] <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:42] <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:43] <didrocks> (it's weird that you are adding a changelog not on top of debian/changelog btw, with a higher version)
[10:44] <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:45] <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:46] <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:47] <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:48] <tvoss> alan_g, not that I know of
[10:55] <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:56] <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:57] <tvoss> didrocks, nope, it is pulled in as a C++ symbol, let me check why that is the case
[10:58] <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
[11:01] <tvoss> mzanetti, I think alan_g needs some help with Jenkins
[11:02] <mzanetti> ok...
[11:03]  * 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:04] <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:05] <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:06] <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:07] <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:08] <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:09] <mzanetti> or where does that come from?
[11:09] <alan_g> mzanetti: No, umockdev is just a victim
[11:10] <alan_g> mzanetti: what is needed is pkg-config in the host environment, not umockdev in the cross-compile "chroot"
[11:11] <tvoss> didrocks, sent you a hangout invite
[11:11] <didrocks> tvoss: let me switch to chrome
[11:12] <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:13] <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:14] <mzanetti> alan_g: yep... it got over the cmake step
[11:14] <mzanetti> alan_g: everything fine now?
[11:15] <alan_g> mzanetti: thanks - I've added introducing sanity to this job to my backlog
[11:16] <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:17] <mzanetti> hehe... I'll demand beer at the next sprint if you overuse it
[12:06] <tvoss> alan_g,  \o/
=== Guest40169 is now known as Debolaz
[12:07] <alan_g> tvoss: it still hasn't landed
=== alan_g is now known as alan_g|lunch
[12:08] <tvoss> alan_g|lunch, is it top-approved, yet?
=== 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
[13:39] <tvoss> didrocks, https://code.launchpad.net/~thomas-voss/platform-api/introduce-hardware-subdirectory-and-package/+merge/169458
[13:44] <tvoss> alf, mind hopping into #qa?
[13:44] <alf> tvoss: sure
[13:44] <tvoss> alf, cancel that
[13:45] <alf> tvoss: sure :)
[13:45] <tvoss> E_PARENTHESIS_MISMATCH
[13:52] <tvoss> didrocks, https://code.launchpad.net/~thomas-voss/platform-api/add-documentation-part-1
[13:53] <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:55] <bregma> tvoss, I was but (1) PPC pbuilder/qemu hangs and (b) https://bugs.launchpad.net/mir/+bug/1195265 took precedence
=== Guest88166 is now known as Debolaz
[13:55] <bregma> if you want to take 1195260 over be my gues :)
[13:56] <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:57] <tvoss> bregma, just wanted to do it, but my Firday evening meeting marathon is about to begin :)
=== Stskeepz is now known as Stskeeps
[14:06] <didrocks> tvoss: bregma: +1 on disabling tests on ppc
[14:07] <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:18] <tvoss> bregma, +1
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
[14:54] <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
[16:21] <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:22] <kdub> its one of those merge conflicts where there's actually something different happening between the two branches
[16:29] <greyback> kdub: I've heard he's on holidays today
[16:29] <kdub> ah
[16:30] <kdub> thanks greyback
[16:30] <greyback> np
[16:31]  * kdub rewrites input stack.... muahaha
[16:33] <tvoss> kdub, rofl
[16:40] <kdub> :d
[16:47] <alan_g> The sun is shining, I'm tempted to start the weekend 10 min early today.
=== alan_g is now known as alan_g|EOW
[16:50] <kdub> alan_g|EOW, enjoy!
=== francisco is now known as Guest44759
[18:15] <bregma> someone forgot 'bzr add' ?
[18:16] <kdub> hmm?
[18:25] <kdub> bregma, i just fired off a compile of lp:mir, went fine for me :)
[18:27] <bregma> kdub, I caughtthe xmir_debug_guide merge half way in, it's OK now
[18:28] <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:31] <kdub> bregma, not sure what your workflow is... but if you need faster compiles, we have some cross compile  scripts
[18:32] <bregma> I'm trying to run the integration tests on arm, as far as I can tell cross compiles won't help
[18:35]  * kdub tries armhf compile...
[18:38] <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:41] <bregma> TestClientIPCRender.render_accelerated deadlocks waiting for a buffer swap, running on a nexu7
[18:43] <bregma> if you're enthuisiastic, http://paste.debian.net/14611/ for the output log (I've added tracing printfs)
[18:44] <kdub> same problem from a few days ago?
[18:45] <bregma> yep
[18:45] <bregma> not going away by itself :(
[18:46] <kdub> bregma, but it works without valgrind?
[18:46] <bregma> nope, still deadlocks
[18:47] <bregma> the child process exits while the parent is waiting on the buffer swap
[18:49] <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:53] <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:58] <bregma> it's the only arm device I have that runs touch
[18:58] <bregma> qemu doesn't cut the mustard either
[19:00] <kdub> bregma, yeah..., there's a few people in that boat (i think mterry as well)
[19:01] <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:02] <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:03] <kdub> n4/gnex don't need root, but we had to change some permissions I think
[19:04] <bregma> well, it doesn;t seem to make a difference
[19:05] <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:09] <kdub> bregma, we might need some sync for what's going on... is there a drive to get android under integration testing?
[19:10] <kdub> (which would make me happy :) )
[19:11] <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:12] <bregma> and Didier won;t let us just disable the test
[19:13] <kdub> right :) that test goes and hits the drivers
[19:14] <bregma> I'm all for disabling just that test, since if it uses the actual drivers it's not a valid generic test
[19:15] <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:21] <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:22] <bregma> are there any other tests that exercise the drivers or is it limited to TestClientIPCRender ?
[19:26] <kdub> the only mir rule is that unit tests don't touch the driver
[19:27] <kdub> bregma, i guess the mir team has work items, which are to get the generic arm builders to run only generic tests