thomiRAOF: any news?00:53
thomior, too soon? :)00:53
RAOFthomi: I can't reproduce locally00:54
thomithat's annoying00:54
RAOFYou're on intel, right?00:54
RAOFWhat package versions do you have?00:55
thomiRAOF: let me see...00:55
thomiugh, have to re-add the PPA, since I wiped the changes last time, one moment00:56
* RAOF also has a sleeping baby in his arms, so will be a bit slow00:56
thomiRAOF: sorry for the delay - which packagesa re you interested in?01:16
RAOFlibegl1-mesa, xserver-xorg-core, xserver-xorg-video-intel01:16
thomilibegl1-mesa: 9.2~git20130628.g6b676e6-0ubunt01:18
thomixserver-xorg-core: 2:1.13.3-0ubuntu1301:18
thomixserver-xorg-video-intel: 2:2.21.9-0ubuntu201:18
thomilooks like that first version was truncated a bit :-/01:18
* thomi notes with annoyance that mir_demo_server has moved back to /usr/bin01:19
* thomi wonders if mir_stress will move about under him as well01:19
RAOFthomi: Hm. You're on raring, then?01:21
thomiuhhh... no, I shouldn't be01:22
thomishould be saucy, but it's an lxc container, so maybe something is broken01:22
thomiRAOF: what makes you think raring?01:22
robert_ancellthomi, Is the client API file descriptor leaking mentioned in mir-stress/src/client.cpp still valid?01:22
RAOFBecause  *** 2:1.14.1-0ubuntu0.6+xmir1 001:22
RAOF        500 http://ppa.launchpad.net/mir-team/staging/ubuntu/ saucy/main amd64 Packages01:22
thomirobert_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 you01:23
thomirobert_ancell: but I think that issue is still open?01:24
robert_ancellthomi, was there a bug about this?01:24
* thomi searches01:24
thomithere was certainly a lot of discussion :)01:24
thomirobert_ancell: problem description is here: https://bugs.launchpad.net/mir/+bug/119802201:56
ubot5Launchpad bug 1198022 in Mir "mir client API leaks FD without an explicit close, which is unexpected" [Undecided,New]01:56
thomiRAOF: interestingly, it seems like when apt installed the packages it didn't get the latest versions, so a dist-upgrade may fix the problem01:58
dufluthomi: We have automated tests, which coupled with valgrind should report FD leaks. If it doesn't then we're missing a valgrind option somewhere02:01
dufluthomi: Like --track-fds=yes (default no)02:02
thomiduflu: 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
thomiI'll look into changing the valgrind options and seeing if it catches anything new02:05
dufluthomi: I mean, I know we have tests that should trigger leaks (if there are any)02:05
dufluWe have full client lifecycle tests...02:05
thomiduflu: sure, but maybe whoever wrote them expected to have to close those FDs themselves, whereas my expectation was that mir would handle that for me02:06
=== csslayer_ is now known as csslayer
robert_ancellthomi, what were you using to show there were open fds?02:18
dufluHah. I've never seen a 50000 line MP before02:19
thomirobert_ancell: I discovered it when I hit the open FD limit in the stress test02:38
thomirobert_ancell: but valgrind with --track-fds should show it as well02:38
robert_ancellthomi, yes, I reproduced it now02:38
duflurobert_ancell: A simpler way to track files is: ls -l /proc/$pid/fd/02:47
robert_ancellduflu, I've also done that02:47
robert_ancellduflu, though valgrind it nice because it tells you where the fd came from02:48
dufluvalgrind is nice for so many reasons...02:48
dufluThough I fear all the errors we are yet to discover using --tool=helgrind02:49
dufluping RAOF03:20
RAOFduflu: Pong03:21
RAOFMesa should work now, btw03:22
dufluRAOF: gbm_surface_lock_front_buffer ... what's the difference between the "front buffer" being locked and the "new one" returned?03:22
* RAOF looks03:23
* duflu afk briefly03:24
RAOFduflu: Ok. So, gbm_surface_lock_front_buffer /03:38
RAOFduflu: 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.e03:44
dufluRAOF: Oh OK thanks. I misinterpreted "A new bo representing the new front buffer is returned"03:44
dufluIt's not the "new" front buffer. It's the old one03:45
RAOFIt's the front buffer that you should send to the output.03:45
dufluSo sounds like the doxygen for gbm is wrong03:45
dufluBut your explanation makes sense03:45
dufluPlus, the code works right now03:45
RAOFOh, fun. the drm EGL platform is tripleish-buffered.03:46
duflu3.141592653 buffers?03:50
RAOFIt'll use up to three buffers.03:52
darkxsthas anyone got Mir running under vmware?03:54
dufludarkxst: No I don't think so. It wasn't as simple as we expected and requires more work for a generic software rendering solution03:55
darkxstduflu, is there accellerated driver missing things?03:56
dufluRAOF ^ what was missing from VMware's DRI support?03:57
RAOFdma-buf support.03:57
RAOFWith the new, improved, actually-probe-the-hardware gbm backend that should be the only thing blocking VMWare.03:57
dufluRAOF: The DMA requirement comes from Mir? Or GBM?03:58
dufluIt's crazy that we're blocked on DMA-buf support, on a platform where it's all in system memory anyway :)03:59
RAOFComes from Mir.03:59
RAOFWe 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
TheDrumsVirtualbox 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 surprising04:16
=== Debolaz is now known as Guest40169
=== zoktar_ is now known as zoktar
tvoss|errandsRAOF, ping05:02
=== tvoss|errands is now known as tvoss
RAOFtvoss: Pong05:03
tvossRAOF, good morning :) how goes?05:03
RAOFWell, albeit cold.05:03
tvossRAOF, cold in your part of the world?05:04
RAOFCold and bright this morning, then it started raining just after I'd got back from a walk with Zoë.05:04
tvossRAOF, Bryce handed me some vm contacts for graphics drivers.05:05
RAOFAs 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
tvossRAOF, yup05:13
* duflu thinks it's about time Linux stopped talking about CRTC's05:16
RAOFtvoss: There's always Prf_Jakob :)05:25
tvossRAOF, +105:25
* RAOF wonders how the full-program optimisations of clang's -O4 would influence Mir performance06:00
tvossRAOF, sounds like fun :) I would also be curious to know how AddressSanitizer with gcc 4.8 works06:01
dufluRAOF: Anything above O2 is usually a bad idea. It creates much larger code, for little gain06:02
RAOFduflu: As far as I can tell, -O4 is (confusingly) not actually above O2 in that sense.06:03
dufluRAOF: Well, usually, around O1 is where superfluous code is removed, and O2/O3 is where speed optimizations (at the expense of size) kick in06:04
RAOFO4 is going to have more opportunity to remove superfluous code, too.06:06
dufluRAOF: Per the gcc man page, O2 is the highest level at which optimizations "do not involve a space-speed tradeoff"06:10
dufluYou use O3 and above only if you're willing to have say a 20% larger binary that runs 2% faster06:11
RAOFduflu: But I'm talking about clang, where O4 is “compile to LLVM bytecode and then do an optimisation pass at link time”06:11
dufluOh. Hmm yeah clang might treat the scale differently. Though it previously tried to match gcc06:12
RAOFI think it *does* match gcc. gcc doesn't *have* an -O4, though.06:12
RAOFI mean - match gcc where the range overlaps.06:13
dufluRAOF: 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
RAOFduflu: Already done ☺: https://code.launchpad.net/~raof/mir/fix-clanger/+merge/17295606:29
dufluRAOF: Still more to go methinks: https://bugs.launchpad.net/mir/+bugs?field.tag=clang06:31
RAOFEh. clang-3.4 builds a testsuite that works for me.06:32
dufluHmm, I might have to retest06:32
RAOFMan, it'll be nice to have a laptop that isn't always thermally throttled.06:33
dufluRAOF: which one did you order?06:33
RAOFA fully-specced galago.06:34
* duflu stops bashing his head against interfaces that don't actually support varying implementations and goes to look at hardware specs06:34
dholbachgood morning06:35
dufluMorning dholbach06:36
dholbachhi duflu06:36
tvossogra_, ping06:36
tvossdholbach, morning :)06:36
dholbachhey tvoss06:36
tvossdidrocks, what's the default approach in ubuntu for installing documentation? a separate doc package?06:38
didrockstvoss: yeah, see my change in location-service (or was it libusermetrics?)06:39
tvossdidrocks, I think location service06:39
didrockstvoss: while I was looking at it: https://code.launchpad.net/~didrocks/location-service/devsuggestsdoc/+merge/17313606:41
RAOFHah. Well, that was short lived. Trunk introduces an ICE with clang-3.4 ☺06:47
alfRAOF: did you get a chance to take a look at the Mesa pull request?07:32
RAOFalf: Let me check now. Have the mir-side chanegs landed?07:33
alfRAOF: they are on their way there (waiting for jenking to perform autolanding)07:34
RAOFThermally throtttled laptop running the testsuite under valgrind. It's poetry in motion.07:37
=== Cimi_ is now known as Cimi
alfRAOF: mir changes done, feel free to merge mesa changes if everything is ok08:29
* RAOF hits the button, and refreshes the packaging.08:32
RAOFalf: Was https://code.launchpad.net/~raof/mir/udev-wrapper/+merge/173151 the sort of thing you were thinking of?08:33
alfRAOF: I haven't looked at the details yet, but the interfaces look good08:37
alfRAOF: One thing that caught my eye, do we really need CopyAssign for the wrappers?08:37
RAOFalf: They're refcounted, so CopyAssign is cheap, and I'm pretty sure I pass-by-value somewhere in there.09:03
RAOFOr, at least, I'm pretty sure UdevContext gets copy-constructed somewhere in there.09:04
tvossdidrocks, mind having a look: https://code.launchpad.net/~thomas-voss/platform-api/add-documentation-part-109:14
didrockstvoss: kind reping on https://code.launchpad.net/~didrocks/location-service/devsuggestsdoc/+merge/173136 if you didn't see it :p09:14
tvossdidrocks, sorry :) lost in doc land09:15
didrockstvoss: mind making a MP of your branch? will be easier :)09:15
tvossdidrocks, https://code.launchpad.net/~thomas-voss/platform-api/add-documentation-part-1/+merge/17315909:16
didrockstvoss: thanks!09:17
tvossdidrocks, ack09:17
* tvoss grabs coffee09:17
didrockstvoss: it seems to me you have unrelated diff like the addition of libubuntu_platform_hardware_api, and others changes09:30
didrockstvoss: the symbols file is wrong, you didn't follow the doc I guess for C++ symbols :p09:30
didrocksand didn't change that by 0replaceme either09:30
didrocksconflict in debian/changelog btw ;)09:30
didrocksand no -doc package09:31
tvossdidrocks, hmmm, you told me I could happily copy over the symbols file :/09:32
didrockstvoss: for non C++ packages right, you ask me in big lines09:32
didrockstvoss: I pointed you to a documentation with step by steps instruction, please read it :p09:32
didrocksI didn't write it for my own pleasure :p09:33
tvossdidrocks, the platform api is not C++, only parts of its implementation09:33
didrockstvoss: yeah, that's why you have mangled symbols09:33
tvossdidrocks, I will hide them from the abi then. That should avoid the need to have them in the symbols file, right?09:33
didrockstvoss: if they shouldn't be exported, yeah, it's better to hide them09:34
didrocksand they won't be list in the symbols file09:34
ogra_tvoss, hey09:54
tvossogra_, salut :)09:55
alan_gtvoss: I think you're right - we need pkg-config, which doesn't exist in the cross-compile job10:03
tvossalan_g, weird10:03
tvossdidrocks, is pkg-config part of build-essential?10:03
didrockstvoss: no, you need to build-dep on it10:04
tvossdidrocks, cool, thx10:04
didrocksyw ;)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 6610:06
alan_gbut the cross-compile does thins in mysterious (and fragile) ways10:08
alan_gdidrocks: 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/console10:11
didrocksalan_g: is pkgconfig in the package build-deps?10:11
alan_gdidrocks: that's what I hope diff line 66 does10:12
didrocksas I told, it's not part of build-essentials10:12
didrocksline 66? I see 66-  message(STATUS "Tests are run with real graphics.")10:12
alan_gOpps, looking at old webpage10:13
didrocksalan_g: oh, the job is not using the package build-deps10:14
didrockswhat's this job? it's ackish10:14
alan_gdidrocks: it is horribly fragile too10:15
didrocksurgh tools/setup-partial-armhf-chroot.sh10:15
didrocksall build-deps repeated :/10:15
didrocksand you don't have pkg-config in it10:16
didrockswhile in debian/control, for the package build-deps, you have it10:16
didrocksthis is a recipe for failure, not sure why it's there, but I think we should work on a better solution10:16
didrocksat least, taking the build-deps from the packaging and handle the cross-arch case10:16
alan_gAgreed (and am on record saying it_10:16
didrocksdpkg-checkbuilddeps -a armhf10:17
didrocksrun in the source directory10:17
didrocksshould list all needed deps to be installed10:17
didrocks(forcing armhf in that case)10:17
didrocks    rm ./usr/lib/arm-linux-gnueabihf/libEGL.so10:18
didrocks    rm ./usr/lib/arm-linux-gnueabihf/libGLESv2.so10:18
didrocks    ln -s libhybris-egl/libEGL.so.1 ./usr/lib/arm-linux-gnueabihf/libEGL.so10:19
didrocks    ln -s libhybris-egl/libGLESv2.so.2 ./usr/lib/arm-linux-gnueabihf/libGLESv2.so10:19
didrockswaow :)10:19
alan_gIn this case my problem is orthogonal to that mess - as I don't want the armhf pkg-config10:19
didrocksalan_g: hum, you are calling find_package( PkgConfig ), right? you need to have at least a pkg-config installed10:20
didrocksalan_g: and it seems that the job is ignoring all build-deps on the machine and need to have this list setup10:20
didrocksin tools/setup-partial-armhf-chroot.sh10:20
alan_gThat would be more reasonable than the current hack (but isn't my priority this morning)10:21
didrocksalan_g: I think you just need to add pkg-config to the list in tools/setup-partial-armhf-chroot.sh10:22
didrocksthen, this would install it in this jenkins job10:22
alan_gWon't that just put the armhf version into the chroot?10:22
* alan_g might as well try it anyway10:22
didrocksalan_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_gdidrocks: I *think* that as cmake is run outside the chroot it will wants the host version. But I'll try it.10:28
didrocksif cmake is run outside the chroot, yeah, that won't help10:29
=== alan_g is now known as alan_g|afk
didrocksnot sure how this job is setup, but manual install on the machine seems to be the only way then10:29
didrocks(yeah for non maintenable jobs :p)10:29
tvossdidrocks, mind taking another look at: https://code.launchpad.net/~thomas-voss/platform-api/introduce-hardware-subdirectory-and-package/+merge/169458?10:31
didrockstvoss: the symbols file looks better :) there are still my remarks about conflicts in debian/changelog, missing -doc package and so on though ;)10:33
tvossdidrocks, that's not the same mp10:33
didrockstvoss: ah good, the diff wasn't regenerated :)10:34
didrockstvoss: 343+ _Z24ua_sensors_light_disablePv@Base 0.18.1daily13.06.2110:35
didrocksyou 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_gdidrocks: thanks10:36
didrockstvoss: I guess the ABI for libunity_application and libubuntu-platform will evolve in sync?10:36
tvossdidrocks, what is libunity application?10:36
tvossyup, at least for now10:37
didrockstvoss: ok, but this change requests a rebuild of everything rebuilding against those libs10:39
didrocksdo you know what's using it, if any?10:39
tvossdidrocks, sorry, I cannot follow you10:39
didrockstvoss: as you separate now some symbols from one lib to another10:40
didrockswhat are using those symbols needs to be rebuild against latest10:40
didrocksto link against the right lib10:40
didrocksbasically, all rdepends of libplatform-api1-hybris10:40
tvosssure, I would assume that is automatically tracked and done10:40
didrocks(and this breaks the ABI, right?)10:40
didrockstvoss: tracked and done by what?10:40
tvossdidrocks, some clever build system?10:41
didrocksthe build system needs manual rebuilds10:41
didrocksand upstream would need to bump ABI as a clever upstream :p10:41
didrockshere, we have none of those, so we have to do that manually, ensuring the upgrade path and so on10:42
tvossdidrocks, sorry, I cannot follow: what do I have to do to make this land?10:42
didrockstvoss: https://wiki.ubuntu.com/DailyRelease/FAQ#I_need_to_break_an_API.2BAC8-ABI10:42
didrocks(it's weird that you are adding a changelog not on top of debian/changelog btw, with a higher version)10:43
tvossdidrocks, 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 anymore10:44
didrockstvoss: feel free to create them10:44
didrockstvoss: breaking ABI a lot isn't agile as well10:45
didrockstvoss: we have tools that we have and need to deal with those by creating procedure10:45
tvossdidrocks, how do we plan to keep the mir development at high pace then? We are going to break the abi regularly10:46
didrockstvoss: yeah, I'll have a hack for this, but it's a hack10:46
didrockssimilar to nux and compiz10:46
tvossdidrocks, how does that work?10:47
didrockstvoss: mind having a hangout? will be easier10:47
tvosslet me grab coffee and eat something ... 10 minutes?10:47
alan_gtvoss: since mmrazik left do we have a preferred contact for our jenkins setup?10:47
tvossalan_g, not that I know of10:48
tvossdidrocks, updated: https://code.launchpad.net/~thomas-voss/platform-api/introduce-hardware-subdirectory-and-package/+merge/16945810:55
didrockstvoss: bzr bd gives me:10:55
didrocks- ua_sensors_light_disable(void*)@Base 0.18.1daily13.06.2110:55
didrocks+#MISSING: 0.18.1+13.10.20130705-0ubuntu1# ua_sensors_light_disable(void*)@Base 0.18.1daily13.06.2110:55
didrocksyou 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 message10:56
tvossdidrocks, nope, it is pulled in as a C++ symbol, let me check why that is the case10:57
didrockstvoss: + _Z24ua_sensors_light_disablePv@Base 0.18.1+13.10.20130705-0ubuntu110:58
didrockstvoss: it's not unmangled properly it seems10:58
tvossmzanetti, I think alan_g needs some help with Jenkins11:01
* mzanetti needs a little more details :)11:03
tvossalan_g, mzanetti is your poc :)11:03
hikikohi :)11:03
mzanettihi hikiko :)11:03
alan_gmzanetti: there's a rather hacked job - mir-android-saucy-i386-build11:03
hikikoanyone who has worked on android-mir? (except kdub who has a us timezone and I guess is sleeping right now :))11:04
hikikoI'd like to build mir for android11:04
alan_gmzanetti: which ought to have pkg-config installed, but doesn't11:04
hikikoand run it there11:04
alan_ghikiko: you've read the instructions right?11:05
hikikobut I only know how to crosscompile it11:05
hikikommm I read some instructions alan_g11:05
hikikomaybe not the correct sec :) i ll check again :)11:05
alan_ghikiko: it helps to know where you are stuck11:05
hikikoalan_g, nowhere :D11:05
hikikoI fixed the issue I had11:06
mzanettialan_g: it looks like Umockdev is not installed11:06
hikikoand gbm works11:06
mzanettialan_g: you sure its a pkgconfig issue and not a missing build dep in your package?11:06
hikikoso I want to do a minimal android nested platform11:06
hikikoand an MP11:06
alan_gmzanetti: the job ignores the build-deps11:06
hikikoso that I can move on with what you suggested next week :)11:06
mzanettialan_g: hmm... thats not what it should do, or am I wrong?11:07
alan_gmzanetti: there's a rather hacked job - mir-android-saucy-i386-build11:07
hikikoafter I get your (mir-team) feedback for the "dummy" nested platforms11:07
mzanettialan_g: yeah... I'm looking through that right now11:07
mzanettialan_g: ah... found it... it installs all the stuff manually11:08
mzanettialan_g: so should I just add the udevmockd there and thats it?11:08
mzanettior where does that come from?11:09
alan_gmzanetti: No, umockdev is just a victim11:09
alan_gmzanetti: what is needed is pkg-config in the host environment, not umockdev in the cross-compile "chroot"11:10
tvossdidrocks, sent you a hangout invite11:11
didrockstvoss: let me switch to chrome11:11
mzanettialan_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/console11:12
mzanettilets see how it goes11:12
alan_gmzanetti: 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
mzanettialan_g: yep... it got over the cmake step11:14
mzanettialan_g: everything fine now?11:14
alan_gmzanetti: thanks - I've added introducing sanity to this job to my backlog11:15
mzanettialan_g: ok cool. feel free to ping me in urgent cases where the US timezone is not up11:16
alan_gmzanetti: I hope you don't regret that offer. ;)11:16
mzanettihehe... I'll demand beer at the next sprint if you overuse it11:17
tvossalan_g,  \o/12:06
=== Guest40169 is now known as Debolaz
alan_gtvoss: it still hasn't landed12:07
=== alan_g is now known as alan_g|lunch
tvossalan_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
tvossdidrocks, https://code.launchpad.net/~thomas-voss/platform-api/introduce-hardware-subdirectory-and-package/+merge/16945813:39
tvossalf, mind hopping into #qa?13:44
alftvoss: sure13:44
tvossalf, cancel that13:44
alftvoss: sure :)13:45
tvossdidrocks, https://code.launchpad.net/~thomas-voss/platform-api/add-documentation-part-113:52
tvossbregma, ping13:53
bregmatvoss, pong13:53
tvossbregma, hey there :) you looking into https://bugs.launchpad.net/mir/+bug/1195260?13:53
bregmatvoss, I was but (1) PPC pbuilder/qemu hangs and (b) https://bugs.launchpad.net/mir/+bug/1195265 took precedence13:55
=== Guest88166 is now known as Debolaz
bregmaif you want to take 1195260 over be my gues :)13:55
tvossbregma, 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 it13:56
tvossbregma, just wanted to do it, but my Firday evening meeting marathon is about to begin :)13:57
=== Stskeepz is now known as Stskeeps
didrockstvoss: bregma: +1 on disabling tests on ppc14:06
bregmaI 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 others14:07
tvossbregma, +114:18
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
didrockstvoss: bregma: not in favor on this one14:54
didrockstvoss: bregma: at least, it's fine for the ppa, but not for entering distro14:54
kdubhey 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 on16:21
kdubits one of those merge conflicts where there's actually something different happening between the two branches16:22
greybackkdub: I've heard he's on holidays today16:29
kdubthanks greyback16:30
* kdub rewrites input stack.... muahaha16:31
tvosskdub, rofl16:33
alan_gThe 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
kdubalan_g|EOW, enjoy!16:50
=== francisco is now known as Guest44759
bregmasomeone forgot 'bzr add' ?18:15
kdubbregma, i just fired off a compile of lp:mir, went fine for me :)18:25
bregmakdub, I caughtthe xmir_debug_guide merge half way in, it's OK now18:27
bregmaof course, if you were trying to build on arm like I am it's be a looooong while before you found out it compiles fine18:28
kdubbregma, not sure what your workflow is... but if you need faster compiles, we have some cross compile  scripts18:31
bregmaI'm trying to run the integration tests on arm, as far as I can tell cross compiles won't help18:32
* kdub tries armhf compile...18:35
kdublp:mir integration tests seem ok to me on nex418:38
kdubbregma,  is there a pastebin of what you're seeing18:38
bregmaTestClientIPCRender.render_accelerated deadlocks waiting for a buffer swap, running on a nexu718:41
bregmaif you're enthuisiastic, http://paste.debian.net/14611/ for the output log (I've added tracing printfs)18:43
kdubsame problem from a few days ago?18:44
bregmanot going away by itself :(18:45
kdubbregma, but it works without valgrind?18:46
bregmanope, still deadlocks18:46
bregmathe child process exits while the parent is waiting on the buffer swap18:47
bregmaunfortunately after a couple of days I have only the vaguest understanding of the internal dataflow of mir18:49
bregmafirehose won't turn off18:49
kdubbregma,  let me see if i can test mine really quickly...18:53
kdubthe n7 is like our forgotten stepchild, the focus is the gnex/nex4 at the moment18:53
bregmait's the only arm device I have that runs touch18:58
bregmaqemu doesn't cut the mustard either18:58
kdubbregma, yeah..., there's a few people in that boat (i think mterry as well)19:00
kdubinteresting... mine went ok19:01
bregmaI have a xformer but it's running precise (hmmm, hobby project for the weeken.... ideal target for Unity 8 Desktop)19:01
kdubbregma, are you running as root?19:02
bregmacertainly not, that's anathema19:02
bregmashould I?19:02
kdubi don't know if we checked the permissions on the /dev stuff for the n719:02
kdubn4/gnex don't need root, but we had to change some permissions I think19:03
bregmawell, it doesn;t seem to make a difference19:04
kdubhmm, trying to think what the difference might be19:05
bregmaI'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 hardwares19:05
ubot5Ubuntu bug 1195265 in Mir "tests stuck on armhf" [Critical,In progress]19:05
kdubbregma, 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
bregmaandroid 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.1019:11
bregmajust that simple, really19:11
bregmawe have a cunning plan19:11
bregmabut successful builds on arm are blocking everything19:11
bregmaand Didier won;t let us just disable the test19:12
kdubright :) that test goes and hits the drivers19:13
bregmaI'm all for disabling just that test, since if it uses the actual drivers it's not a valid generic test19:14
kdubright, i think at this time, we just guarantee that the tests all work on gnex/nex419:15
kdubalthough the nex7 is (as you've no doubt seen) very close19:15
bregmawell, 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-no19:21
bregmaare there any other tests that exercise the drivers or is it limited to TestClientIPCRender ?19:22
kdubthe only mir rule is that unit tests don't touch the driver19:26
kdubbregma, i guess the mir team has work items, which are to get the generic arm builders to run only generic tests19:27

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