#ubuntu-mir 2013-07-01
<thomi> robert_ancell: ping?
<robert_ancell> thomi, hey
<thomi> robert_ancell: so I think I'm getting close to getting all the infrastructure stuff lined up so we can run mir_stress as part of a CI run. However, there are a few issues yet to solve:
<thomi> first, mir_stress currently fails - it causes the server to crash, and the test to hang, which means that if we were to integrate it today, it would take a long time before we got any MP feedback (although we could set the jenkins job timeout to something a little tighter I guess)
<robert_ancell> bug #?
<robert_ancell> (I know the bug, just don't have the number handy)
<thomi> https://bugs.launchpad.net/mir/+bug/1195089
<ubot5> Launchpad bug 1195089 in Mir "mir_stress suite causes mir_demo_server to crash" [Critical,Triaged]
<thomi> the second issue is that our infrastructure seems really flakey, but until I have a job that passes when everything does work, it's hard for me to apply pressure to get those issues fixed up
<robert_ancell> thomi, I'll have a look at that one
<thomi> thanks. :)
<duflu> robert_ancell: To clarify the confusion I've made this tag/group ... https://bugs.launchpad.net/mir/+bugs?field.tag=multimonitor
<robert_ancell> duflu, thanks
<duflu> RAOF: It's a bit inaccurate to keep tracking XMir bugs in the Mir project. Can we use a new project for it?
<RAOF> duflu: We can file them against X with the xmir tag.
<duflu> RAOF: Where's the code BTW?
<RAOF> github.com/RAOF/xserver
<duflu> Awesome.
<duflu> Hmm
<RAOF> Why is cmake suddenly unable to find glog?
<RAOF> Argh.
<RAOF> CMake doesn't understand multiarch?
<RAOF> God damn it build systems. DON'T REIMPLEMENT A HALF-ARSED, BROKEN VERSION OF PKG-CONFIG.
<kgunn> xmir...finally!
<robert_ancell> kgunn, \o/
<kgunn> no doubt!
<RAOF> Woot!
<duflu> RAOF: It's not Mir's fault! (which is bad news) https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1194004
<ubot5> Launchpad bug 1194004 in xserver-xorg-video-intel (Ubuntu) "[regression] Compiz wakes up 200Hz while the screen is locked" [High,New]
<RAOF> Whoops!
<duflu> RAOF: Also, we now have https://launchpad.net/xmir
<kgunn> quick, one, anyone know how to get runtime config dumps of xorg, e.g. let's say i want to see what the color format
<kgunn> of a front buffer is that an app is rendering into
<kgunn> or resolution etc
<kgunn> RAOF: duflu ^ ?
<duflu> kgunn: /var/log/Xorg.0.log is my best guess but may be insufficient
<RAOF> kgunn: âxwininfo -rootâ does some of that.
<RAOF> There's no single âintrospect Xâ tool, though.
<kgunn> thanks guys....will poke around thos
<duflu> kgunn: From memory, Compiz (rightly or wrongly) uses the current X visual. Even when it could (in theory) choose anything the GL implementation allows
<duflu> So that means asking X tools should be accurate right now. But you can't rely on them indefinitely
<robert_ancell> thomi, I've updated bug 1195089 - I'm not reproducing
<ubot5> bug 1195089 in Mir "mir_stress suite causes mir_demo_server to crash" [Critical,Triaged] https://launchpad.net/bugs/1195089
<RAOF> Woot!
<thomi> robert_ancell: hmmm
<RAOF> So when the documentation says âset the CTEST_ENVIRONMENT variable to influence the environment your tests are run inâ what it *means* is âthe CTEST_ENVIRONMENT variable is totally ignored, suckerâ.
<thomi> robert_ancell: only thing I'm doing differently is I'm not running mir_demo_server or mir_stress as root. Will try with latest trunk - maybe it got fixed some time in the last 12 hours?
<robert_ancell> thomi, hopefully :)
<robert_ancell> thomi, note if you don't run as root you can't get the VT
<thomi> robert_ancell: I ususally ssh in to run mir_stress
<RAOF> Man, I get all the good things.
<RAOF> Non-deterministic double-free in  unit-tests.GBMGraphicsPlatform.*
<tvoss_> good morning :)
<duflu> Ah tvoss_ is here.
<duflu> Must be time for lunch
<duflu>  :)
<tvoss_> duflu, exactly :)
<tvoss_> RAOF, good morning :)
<RAOF> tvoss_: Good morning.
<tvoss_> RAOF, happy new week
<RAOF> tvoss_: You should be pleased to learn that https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 should finally pass the tests on the CI infrastructure.
<tvoss_> \o/
<RAOF> (Pending one final change to mir_discover_gtest_tests)
<tvoss_> RAOF, that's great news :)
<tvoss_> thomi, hey there :)
<thomi> tvoss_: o/
<tvoss_> thomi, hey, for the autopilot integration tests: sounds good, thanks for clarifying :)
<thomi> tvoss_: it sucks that the three of us are in really awkward timezones, but I think it'd be good to have a chat some time to work out the big picture: what we need, and where autopilot fits
<thomi> Martin knew a lot more about the app functional test suite progress ....
<tvoss_> thomi, yeah, I know. Are there some example jobs that are run on real hardware?
<thomi> tvoss_: Yes, I believe that all the core apps are run on the real hardware, but I'm not the person to speak to about that
<tvoss_> thomi, who would that be now?
<thomi> tvoss_: I think ChrisGagnon and om26er are the ones to try
<tvoss_> thomi, cool, thx
<thomi> tvoss_: no worries - Omer is (AFAIK) the one working for the phone app teams
<thomi> Chris does a lot of deployment work
<tvoss_> RAOF, still get the non-deterministic double-free?
<RAOF> Yes, but I'm pretty sure I can avoid it.
<tvoss_> RAOF, if the busid is still a char*, it's most likely that :)
<RAOF> Could be :)
<tvoss_> RAOF, I think I had this pastebin last week ...
<RAOF> I've still got the patch in a bzr shelf.
<tvoss_> RAOF, ah cool
<NikTh> Hello. I have reported this bug : https://bugs.launchpad.net/mir/+bug/1196355 . Now I'm in this corrupted system and I will stay for 2 hours at least. Anything you want me to do, just ask it. I will not logout-login or reboot or restart DM.
<ubot5> Launchpad bug 1196355 in xmir "After the latest updates, no desktop session - Ubuntu 13.10 (2013/07/01) - XMir dies with signal 6" [High,Incomplete]
<tvoss_> duflu, ping
<duflu> tvoss_,  hi
<tvoss_> NikTh, looking at your bug report :)
<NikTh> Also you have to know that is difficult for me to handle the system , because of the lack of windows decoration , unity and almost everything else.
<duflu> NikTh, unfortunately lack of decorations and general "wrong things on screen" is not related to Mir
<duflu> NikTh: Only failure to start up is a Mir issue. Can't you reproduce it?
<NikTh> duflu, I attached the logs you asked.
 * duflu looks
<duflu> NikTh: Yep, if it's working now then we can't figure out the original problem
<duflu> Unity failing to start is a different bug
<NikTh> duflu: I will reboot the system and see if I can reproduce it.  Thanks
<duflu> Though it looks like the issue was XMir crashing. I suspect other people have reported similar but not known why they had blank screens
<duflu> So we have some progress I guess
<RAOF> Hah. Once again my tests catch me out :)
<NikTh> Is it a big difference if Xmir is enabled or disabled ?
<duflu> tvoss_, I think sabdfl was getting similar startup issues till last weekend. Now he doesn't... randomly
<tvoss_> duflu, yup, RAOF's prober branch should help a lot here
<tvoss_> duflu, at least in diagnosing
<duflu> Oh, wait, no. Twas a different error: https://bugs.launchpad.net/mir/+bug/1195509
<ubot5> Launchpad bug 1195509 in Unity System Compositor "System compositor fails to start - Failed to set the current VT mode: Input/output error (5)" [Critical,Triaged]
 * RAOF is just removing intermediate debugging before pushing something that will pass CI (fingers crossed)
<NikTh> This system was created for this propose . Testing Xmir .  So it is a pure system. The only package I installed is "ubuntu-restricted-extras" . Nothing else.
<duflu> RAOF: If Mir spits an exception to stderr will it go in the X log?
<RAOF> duflu: Do you mean if libmirclient spits an exception to stderr?
<duflu> RAOF: Not sure. I mean XMir
<NikTh> I will reboot now to see if I can reproduce the problem.  Thanks.
<RAOF> The X log will only catch output generated by X, and XMir only links to libmirclient.
<RAOF> duflu: But lightdm will (should) catch anything printed to either stderr or stdout by unity-system-compositor
<duflu> RAOF: Hmm, well it was the X server crashing apparently.
<duflu> Forgive me for not continuing with this issue. I've already spent half the day triaging Mir bugs
<duflu> ... which is enough
<RAOF> NikTh: Neither of the Xorg.0.log files attached on that bug appear to come from failed attempts to run xmir?
<RAOF> duflu: If you want to comment on https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 beyond your âabstainâ, I'm pretty confident that this go will pass CI :)
<RAOF> Hah. Apart from the merge conflicts, apparently :(
<duflu> RAOF: Yeah trying to catch up on all the MPs I'm holding up :(
 * duflu wishes it was easier to have a say in what lands, _and_ get some work done himself
<arsson> latest updates, unity is gone.
<tvoss_> arsson, did you pin the ppa priority?
<arsson> tvoss_ no special methods are use in here
<tvoss_> arsson, the lightdm version you are pulling in is newer than the version in the system compositor testing ppa
<tvoss_> see https://launchpad.net/~mir-team/+archive/system-compositor-testing
<tvoss_> arsson, let me find you the pinning instructions
<arsson> tvoss_  dumbass  version please?
<tvoss_> arsson, so when upgrading, you get a lightdm version that is newer than the one in the testing ppa. That newer version is not mir-enabled right now as we are in the process of landing Mir to universe
<tvoss_> arsson, to make a long story short: yup, might well break your setup and I'm searching for the instructions to help you fix the issue :)
<arsson> there was some kernel and unity updates and i was using gdm at the time.
<tvoss_> arsson, okay, thx for the information
<admiralmarcus> hi, how will window decorations be handled in mir? client side (csd) or server side (ssd)?
<duflu> admiralmarcus: It's still debatable. The people designing it argue client side whereas the people implementing it still prefer server side
<duflu> Not sure where the argument ended last
<tvoss_> duflu, the tendency is server-side right now
<duflu> \o/
<duflu> admiralmarcus: Though technically right now, XMir makes X a single client and everything (including compiz and decorations) is inside the client
<duflu> ping RAOF
<RAOF> Pong duflu
<RAOF> duflu: You're aware that "the tests" that are disabled without umockdev are "all the GBM tests", right?
<duflu> RAOF: Different subject :)
<duflu> RAOF: So XMir talks native GBM, but only as far as being a native GBM client, right? It never accesses the physical server buffers by GBM?
<duflu> Cos that would be bypass
<RAOF> I'm not sure what you mean by "physical server buffers" in this case; it does directly touch the buffers handed out via libmirclient, which means it's touching the server buffers.
<RAOF> But it's *not* touching the framebuffer, unless the server is handing that out (and it doesn't, yet)
<duflu> RAOF: Yes, umm, I mean it still can't bypass the composition
<duflu> Right
<duflu> RAOF: OK I will look at ways to automagically hand out the framebuffer (under conditions when it's safe)
<RAOF> That would be good
<duflu> Though I thought alf might have strong opinions on that
<RAOF> Plausibly?
<tvoss_> alf, ping
<alf> duflu: I haven't looked into bypass at all. Last I know alan_g was looking into it for Android, but I guess the non-platform specific part of the mechanisms would be made generic enough to support all platforms.
<alf> tvoss_: pong
 * tvoss_ calls trigger_conversation(duflu, alf); :))
<alf> duflu: also kdub was working into supporting it in the buffer swapping component
<admiralmarcus> duflu: okay, thanks for the answer
<alf> duflu: it's probably worth syncing with both alan_g and kdub to check what their plans where
<alf> were
<duflu> alf: kgunn asked me to start on it ASAP. Research at least
<duflu> alf: Oh I see where alan_g started
<RAOF> duflu: Note: when I said "the framebuffer", what I really meant was "a framebuffer"; for the gbm platform we can have arbitrarily many framebuffers. The only difference between a potential framebuffer and a regular buffer is an allocation flag.
<duflu> RAOF: OK, so something scan-out-able
<NikTh> Hi again. Sorry before, but I had a connection problem. (general not IRC only). I attached the new logs, I reproduced the problem. You can review them when you have time.  https://bugs.launchpad.net/mir/+bug/1196355 . Thanks
<ubot5> Launchpad bug 1196355 in xmir "After the latest updates, no desktop session - Ubuntu 13.10 (2013/07/01) - XMir dies with signal 6" [High,Incomplete]
<alf> RAOF: duflu: (also keep in mind the discussions we had about giving new framebuffers or clearing the framebuffer for security reasons)
<alf> RAOF: or is this resolved with prime fds?
<duflu> alf: OK, I have the issue in mind. But was not in the discussions
<RAOF> alf: No, not resolved with prime fds.
<duflu> alf: Yep, the code I was already looking at is the groundwork that Alan did late May
<alf> duflu: ok
<duflu> alf: GBM doesn't have actual documentation does it?
<alf> duflu: there is doxygen documentation in the source files (in the mesa tree)
<alf> RAOF: Have you started working on a C++ Udev class? I may need to do some work there soon to support monitor hotplugging.
<tvoss> duflu, regarding the prober branch: What would be your proposal for an alternative umockdev package available on other platforms?
<duflu> tvoss: My only suggestion is: Fall back to whatever we do now (without umockdev) if it's not present
<duflu> I don't know the details, but I'm pretty sure it's not a portable assumption to assume a distro has it
<tvoss> duflu, not appropriate from my perspective, we will skip a bunch of tests
<duflu> tvoss: People building on other distros care more that the code is unbuildable than the reduced coverage, I think
<tvoss> duflu, and that makes it a required build-dep from my pov
<duflu> I mean, we're moving further away from Mir being portable and usable outside of Ubuntu. And we said we would work on that
<tvoss> duflu, hmmm, I think failing at build time with a clear indication of the missing dependency is quite straightforward to fix outside of Ubuntu
<duflu> tvoss: Not realistic. We can't depend on packages that other distros don't have packaging for yet. Unless we properly document how to build all-the-things from source
<tvoss> duflu, hold on: I think it's a bad idea to automatically skip tests that ensure that Mir's components are working correctly
<duflu> tvoss: It's not as bad as not being able to build (or test) it at all
<duflu> tvoss: The debian build-dep is OK. We use that for Jenkins. I'm just saying don't impose it as a CMake requirement
<duflu> Make the CMakeLists smarter
<tvoss> RAOF, want me to help with that?
<duflu> tvoss: didrocks and RAOF has already said that build-dep is a superset of the actual requirements. But if you're clever enough to build from CMake then you should have the option of not requiring things that are not required
<duflu> -has +have
<tvoss> duflu, I would consider something that enables all of our gbm-platform testing as required
<duflu> tvoss: This does not limit the Ubuntu requirements. Those come from debian/control. I'm only saying loosen the restriction in CMakeLists
<duflu> We're going in the wrong direction if Mir continually becomes less portable, as it keeps doing
<tvoss> duflu, that's what I'm trying to say: disabling tests that are meant to be run at build-time is a dangerous thing
<duflu> tvoss: They're still enabled for Ubuntu builds
<duflu> By virtue of debian/control forcing them to be installed
<duflu> But we need to be more flexible for people building Mir by hand (which includes external packagers)
<tvoss> duflu, how do you document the udevmock dependency then for external packagers?
<duflu> tvoss: It's enforced for Ubuntu in debian/control, and documented for everyone in CMake output as the usual "detecting XYZ: Not found: Not enabling XYZ"
<tvoss> duflu, hmm, is that really sufficient?
<duflu> tvoss: It's how all CMake projects work
<duflu> You give a warning that "we think you should install XYZ", but don't absolutely require it
<duflu> And Ubuntu packagers will never see that warning because the control file already forces umockdev to be installed
<tvoss> okay, I think we need to agree to disagree here
<duflu> tvoss: No problem. You can land stuff without my approval. I'll propose changes if/when it bugs me. Or someone else will
<tvoss> duflu, fair
<duflu> We'll stall too much if we allow vetos on everything. And we'll also land things that need more fixing later. But that's life
<RAOF> alf: I have indeed started on a udev C++ class.
<alf> RAOF: ok, then I will use something hacky as a first step with a TODO to replace it with services from your class when it lands
<RAOF> alf: Sounds good.
<tvoss_> alf, any news from jenkins?
<alf> tvoss_: no, jobs still stuck http://s-jenkins:8080/job/mir-ci/
<ogra_> did you contact IS ?
<alf> ogra_: We are waiting for the US to wake up
<ogra_> ah, yeah, lexington
<racarr> Morning!
<alf> racarr: Hi!
<kdub> morning racarr
<alf> status: Implementing notification and reconfiguration when a monitor is plugged in/out
 * alf has found a new indicator for EOD... noticable reduction in internet speed as people come home from work and start browsing :)
<kdub> status, got rid of ms::Surface : public mi::InputTarget, which lets us untangle a few things
<racarr> kdub: ? What is the InputTarget then
<racarr> alf: Happens to me too XD
<kdub> ms::Surface is not an InputTarget, but rather owns an InputTarget
<racarr> ok
<racarr> kdub: I think the toyds.Window should just fire up an inputReceiver goroutine
<racarr> err
<racarr> :p
<kdub> hah :P
<kdub> breaking that inheritance though lets us proxy ms::Surface, which resolves a lot of funny lifetime issues in msh
<racarr> I understand I think
<racarr> makes sense
<kgunn> bregma: ping
<kgunn> bregma: just curious, since your guys do a lot of x debug....if i have an app rendering, and i wanted to check (runtime) what the color format of the render buffer is...is there a simple way to do that?
<mhall119> kgunn: did we get any metrics for XMir vs. just X that aren't based on OpenGL and Framerate?
<mhall119> for things like Lubuntu, who's performance concerns aren't about games, but rather how fast Gtk and Openbox are
<robotfuel> mhall119: is there an existing test that measures that?
<mhall119> I don't know
<mhall119> just wondering if the phoronix guy measured anything except games
<kdub> hey racarr, if you have time today  look over lp:~kdub/mir/remove-surface-target :)
<robotfuel> mhall119: I can have jenkins run test via utah, if you have a test you want me to run I can set that up.
<racarr> kdub: Ok
<robotfuel> there is a regression today though. so the results won't be very useful
<robotfuel> until that's fixed.
<kdub> racarr, thanks :D
<greyback> mhall119: you've seen: http://www.phoronix.com/scan.php?page=article&item=ubuntu_xmir_2d&num=1 - he measured gtk and x11 perf
<mhall119> greyback: ah, thanks, missed that somehow
<mhall119> robotfuel: could we run those gtkperf tests (and any other performance benchmarks" in utah?
<racarr> Anyone...flashed a phone this morning?
<racarr> phablet-flash is failing over and over with md5 validation errors
<racarr> when I download the images
<ogra_> racarr, tried re-downloading ?
<racarr> ogra_: Like 20 times now :p
<racarr> I am now faking the md5sum
<racarr> That can't go wrong right
<ogra_> which images is that ? flipped (as you should) or unflipped ?
<racarr> the md5sum on +mako was right, just not on
<racarr> preinstalled-touch-armhf
<racarr> flipped
<ogra_> hmm
<racarr> ogra_: Presumably its the NSA slipping a backdoor in ubuntu touch
<racarr> though you'd think theyw ould update .md5sum
<racarr> :p
<ogra_> we do
<ogra_> oh, they, heh
<ogra_> racarr, well, comparing the md5sums here all seems right
<racarr> :/
<racarr> what does it mean
<racarr> haha
<ogra_> racarr, oh
<ogra_> can you check if there is a path in your md5sum ?
<ogra_> if so, edit it and remove that
<ogra_> you only want a filename
<racarr> lets see, I already replaced the downloaded version with one that works
<racarr> but didnt look at the contents
<ogra_> ah, well
 * ogra_ thinks he fixed it server side now
<racarr> ailed to fetch bzip2:/var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-ports_dists_saucy_main_binary-armhf_Packages  Hash Sum mismatch
<racarr> W: Failed to fetch bzip2:/var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-ports_dists_saucy_universe_binary-armhf_Packages  Hash Sum mismatch
<racarr> wow
<racarr> am I being
<racarr> mitmed on apt by comcast
<racarr> or something
<racarr> hmm things are in fact broken on nexus 4
<racarr> will investigate ter lunch
<racarr> things are still running and input still works but nothing
<racarr> on screen
<kdub> really o.O? tip worked on my device this morning
<kdub> granted, its a week or two since I flashed latest phablet
<racarr|lunch> well this is unity
<racarr|lunch> I will test just mir after I eat SPICY BASIL WITH TOFU AND VEGETABLES
<racarr|lunch> omnomnom
<racarr> hmm
<racarr> mir_demo_egltriangle works
<bschaefer> interesting crash that halted the xserver: http://paste.ubuntu.com/5834336/
<bschaefer> full x log: http://paste.ubuntu.com/5834333/
<jono> olli, tvoss hey
<olli> jono, what's up
<jono> olli, tvoss so I think it could be useful to have a schedule in place for dogfooding
<jono> as an example, this is what I would need:
<jono>  * Get rid of the cursor and use an overlay (cursor makes it difficult to use)
<jono>  * Basic multi-monitor support (even if just mirrored)
<jono> Unity 7 seems functional on XMir for me for daily use
<jono> olli, would this be worth posting about to mir-devel?
<olli> jono, I just took an AI to follow up
<olli> I think it's good for us to have a more specific plan in place
<olli> need to chat with poor kgunn though
<ahayzen> is there any way of running Mir in a VM yet?
<jono> olli, yeah
<olli> jono, eta Wed/Thu
<jono> olli, I think it could be good for rallying around a goal
<jono> olli, cool
<greyback> racarr: hey, compiler errors for you: http://pastebin.ubuntu.com/5834366/ I've merged Mir trunk into implement-client-credentials, and installed that, all fine. Then trying to build platform-api "mir-with-packaging" branch again with platform-api trunk merged into that. But it fails to compile with that message
<racarr> greyback: Just revert the last revision
<racarr> I tried merging trunk and didn't test yet
<greyback> racarr: ah ok
<racarr> I dunno
<racarr> hmm I dont even know in regards to that compile error -.-
<greyback> racarr: this should fix the first error: http://pastebin.ubuntu.com/5834416/ . still not sure about the second
<racarr> greyback: Do you have any ide hat
<racarr> //home/phablet/phablet-integrate-mir/Shell.qml:20:1: module "LightDM" plugin "LightDM-qml" not found  import LightDM 0.1 as LightDM
<racarr> may be about?
<racarr> greyback: Something weird is going on there I have to understand
<racarr> because mir trunk compiles...
<greyback> racarr: did you run the "./run" script in phablet-integrate-mir?
<greyback> racarr: it should compile the QML plugin that you're missing
<greyback> racarr: sorry, I meant "./build"
<greyback> "./build -s" will pull in any build dependencies it needs, so that's usually run first.
<racarr> greyback: Yeah :) nvm
<racarr> I was trying to get away with a partial build XD
<racarr> and forgot what I did
<greyback> :)
<racarr> no one can make it work
<racarr> including me :(
<racarr> it's all black screens
<racarr> input works because multi touch crashes the binary (and doesnt with ix-pointer-indexing!)
<greyback> grrr, what broke/changed
<racarr> I dunno
<racarr> build -s doesn't work either because it wants libboost 1.49
<racarr> and mir wants 1.53 now
<racarr> Ill figure out what broke XD
<greyback> blimey, dependencies are changing all over the place
<greyback> racarr: above patch fixes platform-api compile error completey
<racarr> greyback: I don't understand it though
<racarr> how can mir build
<racarr> if that header cant be included
<greyback> racarr: see that the inherited class SurfaceBufferAccess has a deconstructor defined as ~SurfaceBufferAccess() noexcept - explicitly says it won't throw an exception
<greyback> but Surface's deconstructor didn't define what exceptions it could throw (if any) - which is considered too loose by gcc. I think clang is ok with it though, if you don't define what exceptions you throw, it assumes you can throw any
<racarr> except it's not
<racarr> because it builds :p
<greyback> why Mir builds: you using gcc4.7?
<racarr> so why doesn't it build in the platorm-api pbuilder
<racarr> I think we are using 4.
<racarr> 8
<greyback> ok, me too
<racarr> 4.8
<racarr> yeah
<greyback> then yeah, I don't understand that.
<racarr> I don't think noexceot should be needed because it's the parent is defaulted
<racarr> greyback: Maybe you are using 4.7 somehow? https://code.launchpad.net/~vanvugt/mir/fix-1196415/+merge/172279
<greyback> racarr: holy sh*t I am. wtf
<greyback> whaaat
<racarr> greyback: It's ok. I'm begining to suspect the structure of logic itself is deteriorating
<greyback> racarr: I've both 4.7 and 4.8 installed. cmake must go for the first one it sees, even though 4.8 is the default
<greyback> dammit, sorry for wasting your item
<greyback> time
<racarr> no worries :)
<RAOF> racarr: Good morning!
<RAOF> Or afternoon. Or whatever.
<bschaefer> RAOF, hey, I've a new crash from the x.log...this time it actually killed the server... figure you were the one to poke about it
<bschaefer> full log: http://paste.ubuntu.com/5834333/, cut out bit: http://paste.ubuntu.com/5834336/
<bschaefer> also, when the xserver went down, mir was still running, as the hardware cursor was still working. Just everything else was black....if thats any help :)
<olli> RAOF, ping
<olli> bschaefer, ping
<bschaefer> olli, hello
<racarr> RAOF: Morning!
<racarr> RAOF: You must have good news right? ;
<racarr> )
<RAOF> bschaefer: Cool.
<RAOF> racarr: Not any particularly good news? Except that it's morning!
<racarr> oh well that's great news
<thomi> hi guys - what things land in the compositor-testing PPA?
<RAOF> thomi: Whatever we manually copy across.
<RAOF> thomi: Also, hi!
<thomi> RAOF: Hi :)
<RAOF> thomi: How do I get umockdev installed in jenkins? https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/105/console
<thomi> RAOF: hmmmm, olli is wondering if we can do something to prevent people having to use pinning in order to test the compositor - any ideas?
<thomi> RAOF: add it as a build-dep to the mir source package, if you need it as part of the build process
<RAOF> Impromptu baby,.
<thomi> RAOF: .....
<thomi> Of course I'm serious, and stop calling me Shirley?
<RAOF> thomi: Re: not pinning.
<thomi> I don't understand...
<RAOF> There are two options that I can think of -
<RAOF> 1) Ensure everything in the PPA has a higher version than in the archive. We can do this with an epoch. Downsides: you'll need to ppa-purge to get off those package versions, and that's somewhat fragile.
<RAOF> 2) Add a new package in the PPA, depending on a virtual package provided only by the packages in the PPA.
<RAOF> Downsides: users who dist-upgrade need to be sure the upgrade doesn't remove that package.
<RAOF> bschaefer: Wow, that's a fun Xorg log!
<thomi> RAOF: hmmm, it seems to be that those options both suck :-/
<RAOF> thomi: Correct. Which is why we chose pinning âº
<thomi> yeah
<thomi> ok
<bschaefer> RAOF, yeah, its only happened twice today though...both while my CPU was close to 100% (from compiling..)
<RAOF> Is your system particularly slow?
<bschaefer> hmm not really, every now and then everything hangs for 5-10 seconds
<bschaefer> and sometimes during that hang, the xserver crashes...which it just seems like the event queue is getting filled up
<RAOF> It looks like it might be triggered by something that only happens when the event queue fills up, yeah.
<bschaefer> does mir give events off to X? If so maybe mir needs to filter out more events?
<RAOF> Mir doesn't give X any events; it's a strictly standard X input stack.
<bschaefer> o well ignore that thought then :)
<RAOF> It's a bit curious that libmirclient is above synaptics in that stack, but I suspect that's it being slow on message submission because everything's slow.
<bschaefer> hmm yeah, im really wondering what is blocking...that causes ~500 events to be missed
<RAOF> You're not using something silly, like btrfs are you?
<RAOF> That's *excellent* at blocking
 * bschaefer isn't sure what that is
<bschaefer> haha
<RAOF> bschaefer: Want to try the X stack from ppa:raof/aubergine? That's xmir rebased on 1.14, which may just fix this for you.
#ubuntu-mir 2013-07-02
<bschaefer> sure, that'll be fun
<bschaefer> is it a bit different than: ppa:canonical-x/x-staging
<bschaefer> oo thats xmirs rebased...nm!
<bschaefer> RAOF, Im still dropping a lot of events with the new 1.14 server :(, though it hasnt caused the server to crash yet
<RAOF> Hm.
<RAOF> Still dropping events in a libdrm-intel ioctl?
 * bschaefer looks
<bschaefer> seems to be: (EE) 11: /lib/i386-linux-gnu/libc.so.6 (ioctl+0x19) [0xb72160c9]
<bschaefer> which is above:
<bschaefer> (EE) 13: /usr/lib/i386-linux-gnu/libdrm_intel.so.1 (0xb6aff000+0x5d6c) [0xb6b04d6c]
<bschaefer> (EE) 14: /usr/lib/i386-linux-gnu/libdrm_intel.so.1 (drm_intel_bo_subdata+0x28) [0xb6b011f8]
<bschaefer> though this time mir isn't mentioned in the stacktraces
<RAOF> bschaefer: Do you know if that happens outside of Mir?
<bschaefer> RAOF, I have not tested that, but i've not noticed theses things until I swiched to xmir
<bschaefer> RAOF, let me see if I can get these problems when just using plain old X
<RAOF> Ta.
<bschaefer> np, and thanks for looking at the log!
<bschaefer> so far, plain X everythings fine...but Ill see what happens with working on it all day tomorrow
<RAOF> setup-partial-android-chroot.sh is annoying :(
<duflu> RAOF: Yep. Enhancements welcome
<duflu> RAOF: How so?
<duflu> RAOF: Also, if you're still tinkering in this, please unset Needs review: prober-drm-device-probe
<RAOF> duflu: No, should now be good.
<RAOF> Should have been good the last go around, but setup-partial-android-chroot.sh broke it.
<duflu> ?
<duflu> Farq. Another ABI bump?!
<RAOF> Because libhybris added a dependency, and setup-partial-android-chroot doesn't use apt.
<duflu> Come on people...
<RAOF> What? When?
<duflu> RAOF: Ahem. Just in the proposal I'm testing. Not as bad as I feared
<duflu> RAOF: What's the new dep?
<RAOF> libandroid-properties1
 * duflu shrugs
<RAOF> (Or see the merge proposal)
<duflu> RAOF: Hmm, so I can't run any *-tests any more? Is there a compromise possible?
<RAOF> I could push down the check so that you can't run any gbm tests, but I'm not sure if that's a good idea.
<RAOF> Basically, the further down I push that check, (a) the more complicated it is, and (b) the less obvious it is that you're not running the full test suite.
<duflu> RAOF: Yeah that's what I was suggesting originally
 * duflu hacks it up
<kgunn> since i am xmir'ing now....ran my own data
<duflu> ?...
<robert_ancell> RAOF, is vladmir the correct branch on https://github.com/RAOF/xserver?
<robert_ancell> and egl-platform-mir on https://github.com/RAOF/mesa?
<RAOF> robert_ancell: Correct.
<RAOF> Anyone want to top-approve https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 ? There have been enough changes since the other two approvals that it's probably worth a second lookover.
<tvoss> kgunn, ping
<duflu> Hmm 1am. Good luck :)
<RAOF> tvoss: Good morning!
<tvoss> RAOF, good afternoon :) how goes?
<RAOF> tvoss: Feel like top-approving https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 ? :)
<tvoss> RAOF, for sure :
<tvoss> )
<RAOF> Assuming you approve of disabling the whole testsuite when umockdev is not available.
<tvoss> RAOF, mind renaming TESTS_ENABLED to MIR_TESTS_ENABLED?
<RAOF> Not at all.
<mlankhorst> smurf everything
<RAOF> tvoss: Anything else?
 * duflu thinks mlankhorst might have a valid point
<tvoss> RAOF, nope
<RAOF> Dear System76 Galago: make with the getting here faster.
 * duflu gives in and grabs the Mesa source as *documentation*
<RAOF> duflu: Hunting down bypass support? :)
<duflu> RAOF: Not even that. Hunting down an understanding of src/server/*
<RAOF> Ah.
<duflu> Hmm. GBM has documentation but it's buried in the source package as alf mentioned. They really should have put it in the header
<RAOF> Or even build it and ship it? :)
<duflu> Yeah, shipping the docs would be nice.
<duflu> alf: Hello...
<alf> duflu: hi :)
<duflu> alf: "Schedule the current front buffer object for display" ... how is it GBM doesn't think the "front buffer" is front?
<duflu> Or is it just a "new" frontbuffer object each time?
<tvoss> duflu, mind if I top-approve the prober-mp?
<duflu> tvoss: My eyes are closed.
<duflu> .. which means I will mind later when I open them. But that won't be today
<tvoss> duflu, ack ;)
<alf> duflu: gbm doesn't handle display itself, it just has a surface with two (or conceivably) more buffers. When we swap the buffers we get a new front buffer that we are responsible for displaying if we want.
<duflu> alf: I am very confused by that terminology. "Front" usually means the one and only buffer visible right now
<alf> duflu: this is the front buffer from the surface's perspective (the one that should be visible, gbm_surface_lock_front_buffer()), independent of what is actually displayed.
<duflu> alf: That makes sense. I'm just trying to understand why GBM says you call gbm_surface_lock_front_buffer _after_ swap buffers
<duflu> alf: Oh, yes, I see. Because swap buffers is not "visible" either. You still have to flip it (which is another buffer swap of sorts)
<alf> duflu: right, the swapping operation is independent of displaying any buffers, it's literally just swapping two buffers.
<hikiko> I forgot my objectives :/
<tvoss> hikiko, ?
<hikiko> I forgot to set them this weekend and now I can't do it anymore
<hikiko> :s
 * RAOF returns from his impromptu IRC bouncer explosion
<alan_g> Good morning all, you've had a busy week and a day!
<duflu> alan_g: Hello. Yes it seems to always be busy
<duflu> I find myself drawing up a class  diagram for parts of mirserver. Has anyone else does this yet?...
<alan_g> hi duflu - I see you've taken on comp-bypass. Got all you need>
<alan_g> *?
<alan_g> @diagram - only the one in the source tree (which is less granular)
<duflu> alan_g: All except about 1 month of learning libmirserver's workings I think
<duflu> alan_g: Yeah my diagram is quite disparate to the Architecture.dia
<alan_g> Doesn't doygen do diagrams if you've got dot?
<duflu> Hmm, I suspect it might
<duflu> alan_g: Yes doxygen does one diagram per class. I need more
<duflu> Oh, there's a more complete one: http://unity.ubuntu.com/mir/inherits.html
<alan_g> If that doesn't suit it ought to be possible to munge the doxygen representation - I know folks do that
<duflu> On that note, the doxygen style feels a bit ugly and more difficult to navigate than it should be. Can we configure it for other HTML styles?
<alan_g> duflu: there are a lot of config options.  IIRC tvoss found a volunteer to investigate (I don't remember who) but I never heard any more.
<tvoss> alan_g, that guy never came back to me :/
<tvoss> alan_g, welcome back
<alan_g> duflu: here's one starting point: http://www.stack.nl/~dimitri/doxygen/manual/customize.html
<duflu> Ah, too technical. I was thinking more like pick and choose a "theme"
<alan_g> duflu: I've seen mention of a graphical front-end.
 * alan_g doesn't believe it is as easy as wordpress
<iceroot> hi
<RAOF> hey.
<iceroot> i am running MIR at the moment and i dont see a real difference to X11 (just a broken mouse pointer), can you recommend a ressource where i will find examples to test out the advantages of MIR? so it would be easier to understand MIR
<RAOF> At the moment the advantages are mostly latent. There are a bunch of demos in the mir-demos package, but nothing particularly "wow"
<RAOF> Mostly the advantages are when the shell (ie: unity) becomes the display server as well.
<iceroot> maybe there is something like "ssh -X" which is running much better then on old X11
<RAOF> Nope; we've got no special remote protocol.
<RAOF> What we should have for 13.10 is nicer bootâgreeterâloginâuser switchâshutdown transitions.
<iceroot> when my vga is fully supported will i face differences/problems when using games from steam? or is this not realted to MIR but just the display driver itself? the programs dont need a change?
<RAOF> The programs don't need to change; we'll support running X11 apps for the forseeable future.
<RAOF> (They may get the ability to be more awesome if they do change, though)
<duflu> alf: Roughly speaking a DisplayBuffer is presently an output, and "Display" is the set of all outputs, right?
<duflu> So in Compiz-speak DisplayBuffer==Output and Display==Screen
<duflu> Though it would all sound the same to the casual reader
<dholbach> hey, so I'm trying to follow the build instructions for mir, but I run into the following:
<dholbach> CMake Error at shared/protobuf/CMakeLists.txt:11 (protobuf_generate_cpp):
<dholbach>   Unknown CMake command "protobuf_generate_cpp".
<dholbach> ^ any advice?
<alf> duflu: correct, with the detail that a DisplayBuffer could be shared by different physical monitors (e.g. if we are cloning), so it's not strictly DisplayBuffer==Output
<duflu> alf: Sure. OK thanks
<iceroot> RAOF: thank you for the useful info
<alan_g> dholbach: that sounds like you're missing the protobuf dependency. Did you get errors running "sudo mk-build-deps --install --tool "apt-get -y" --build-dep debian/control"?
<duflu> dholbach: It's actually part of CMake (you need a newer CMake): http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:FindProtobuf
<dholbach> duflu, I'm on saucy - how do we build mir in the ppa then? I didn't see a newer cmake in there
<duflu> dholbach: Oh actually seems like we might be missing:
<duflu> find_package(Protobuf REQUIRED)
<duflu> Which should come before the function
<duflu> Not sure why it works for the rest of us
<dholbach> so if I install all the build dependencies, should  bzr branch lp:mir; cd mir;mkdir build; cd build; cmake ..  succeed?
<duflu> dholbach: Yes. Otherwise it's a bug (which is quite possible)
<duflu> dholbach: Actually the top-level CMakeLists.txt gets protobuf, which should be inherited in subdirs
<dholbach> ok, nevermind - I got it working now - I had to regenerate the cmake data bits after I installed all the build-deps
<dholbach> thanks duflu
<duflu> dholbach: Cool. Yes CMake often thinks its cache is clean when it's not :/
<NikTh> Hello everyone
<NikTh> duflu: available ?
<duflu> NikTh, yes?
<NikTh> Is it a good idea to re-install the system, make all the updates and activate again the PPA to see what's happen ?
<NikTh> Now things are messed up. From 4 reboots, 1 can start the display manager with a corrupted desktop (but as you said this is not xmir's problem) and other 3 cannot even start a display manager, I cannot even switch to a VT.
<NikTh> If I re-install the system and things are good, we can close this bug as fix released or invalid.. maybe.
<NikTh> What you say ?
<NikTh> https://bugs.launchpad.net/mir/+bug/1196355
<ubot5> Launchpad bug 1196355 in XMir "After the latest updates, no desktop session - Ubuntu 13.10 (2013/07/01) - XMir dies with signal 6" [High,Incomplete]
<duflu> NikTh, I find sometimes with similar issues, I just need to delete ".Xauthority" from the home directory to get my desktop back
<duflu> Delete it and then reboot, try again
<NikTh> duflu: I have already tried this but to no avail :)
<duflu> NikTh: OK, well if it's causing such system-wide issues and you can't debug it further by yourself, then yes I would suggest a full re-install and avoiding all PPAs. Because PPAs are use-at-your-own-risk
<NikTh> duflu: The PPA and my own-risk is not the problem. I created this installation to test xmir and help.. (in any way I can- I'm not a programmer)
<NikTh> To report bugs.. etc
<NikTh> But now, I cannot do much. The system is unusable. If I re-install and after full updates, the same problem occurs, then this is definitely a bug. And you(we) should check it, seriously.
<NikTh> But If I re-install and after full updates, this is not happen , maybe we can close this as invalid or something ;)
<NikTh> xmir will be the default Display Server in 13.10 as I know. If I (or some other people) cannot install and use 13.10... well I guess this is a problem :)
<NikTh> What you suggest. To re-install, or wait for updates ? I can still update the system. I can chroot.
<duflu> NikTh: I know it's something that needs wider testing. But at the same time, we can only easily fix the bugs that we (any Mir developer) can reproduce.
<duflu> Other bugs are still bugs, certainly, but we can't fix them (knowingly and confidently) without reproducing them
<NikTh> hmm.. I think I understand that. Then I guess 13.10 will be a "testing release" for xmir. When you getting in to universe and apport works, It will be easier to report bugs.
<duflu> NikTh: Certainly managing bugs will be easier when everyone is using the same installation and updates (13.10)
<NikTh> Then I will leave it to your judge to do whatever you want with my report :)
<duflu> NikTh: Incomplete can stay so indefinitely. And if more information comes up, even from other people, then it can be re-opened and work continue on that bug
<NikTh> More info came from me last night. See the last logs but I don't know if they help.
<NikTh> OK, nice talking to you.. I have to leave now. :)
<NikTh> duflu: Thanks )
<duflu> Hmm, doxygen documents deleted methods. Useful
<alf> duflu: @threadsafe-clients, are the locks recursive to handle the protobuf RPC "done" callbacks?
<duflu> alf: Actually they're recursive because they used to be around all client callbacks too. But no longer. I'm not sure if there's a remaining need for recursiveness, but that bug is still open
<duflu> Good point, but I must go set dinner on fire
<dholbach> so I just built mir locally and built RAOF's xserver branch with --enable-xmir - it can't seem to find mir_client_library.h though (it was placed in /usr/local/include/mirclient/mir_toolkit/mir_client_library.h) - anything I probably missed somewhere?
<dholbach> basically what I ran into was: http://paste.ubuntu.com/5835758/
<greyback> hi folks, am having problem with Mir with egl clients. They fail with libegl - unsupported platform (null)
<greyback> alan_g: ^ any idea?
<alan_g> greyback: on desktop?
<greyback> alan_g: yep
<alan_g> Last time I had that it was because of a bad mesa version (caused by the repo being messed up)
<greyback> alan_g: what mesa package version have you? Are accelerated demo clients working ok for you? I'm using mir staging
<alan_g> greyback: I'm about a week out of date - been on vacation and not updated
<greyback> ok
<alan_g> alf: anything you're aware of ^^
<alf> greyback: what version does dpkg -s libegl1-mesa give you?
<alf> alan_g: I am not aware of any problems
<greyback> alf: 9.2~git20130628.g6b676e6-0ubuntu0+mir1-jenkins83saucy0
<alf> greyback: is mir from the ppa too, or are you building from source?
<greyback> alf: from mir staging ppa
<greyback> as are all the mir-related packages on my machine right now
<greyback> alf: any ideas? My problem or no?
<alf> greyback: Does mir server start fine, only clients fail?
<greyback> alf: server fine. unaccelerated clients fine. Only those using egl
<kgunn> greyback: i would change ppa to be system-compositor-testing
<kgunn> http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html
<kgunn> the staging ppa is wild west
<greyback> kgunn: apparantly so.
<kgunn> greyback: note, if you're running xmir....they moved type==unity to a "unitysystemcompositor" conf file (out of lightdm)
<kgunn> just in case you're toggling xmir/x in lightdm....it could trip you up
<greyback> kgunn: noted, thanks
<greyback> rebooting
<didrocks> kgunn: hey! how are you?
<kgunn> didrocks: good (crazy times)
<didrocks> kgunn: I'm looking at the progress on https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy and it doesn't seem good (the only ones which are fixed committed are the copyright stuff my team worked on with robert)
<didrocks> kgunn: FYI, since Thursday, I have nothing I can do more to get mir under dailies, the ball is in your team's camp :)
<didrocks> (for daily release and then distro)
<didrocks> just as a reminder, the armhf FTBFS is a blocker for dailies
<kgunn> didrocks: understood...
<didrocks> the rest are blockers for distro
<didrocks> kgunn: do you have any idea for a date at least to get dailies?
<kgunn> didrocks: yeah, bregma was looking at arm build and it was canadian holiday yesterday
<didrocks> kgunn: ok, please keep me in touch :)
 * bregma lifts his groggy head
<kgunn> :)
<kgunn> alan_g: alf question...regarding swapinterval(0), i noticed a caveat on kdub's mp, that it'll work for work for gbm ipc clients only
<kgunn> doesn't that only really mean you couldn't get the shell to set it via this mech
<kgunn> ?
<kgunn> e.g. any other app will work just fine
<alf> kgunn: that MP implements SwapInterval support for IPC clients only, native client (e.g. the shell) support hasn't been implemented yet.
<kgunn> alf thanks...i was just verifying my thot/understanding. hooray...i understood
<kgunn> alf: which also means, we need a cooresponding bit in xmir to pass it through....which probably isn't there yet ?
<alf> kgunn: I think the code in Mesa is already hooked up
<alf> kgunn: so in theory now eglSwapInterval(0) from a IPC client should work
<alan_g> WTF? ctest only runs 2 tests
<kgunn> alf: thanks
<alf> alan_g: there were some changes while you were away... we decided that TDD isn't worth it after all :D
 * alan_g is glad he hasn't signed the new contract
<kgunn> :)
<alan_g> alf: is it just me? OR has something changed?
<alf> alan_g: ctest runs fine for me. I remember having come across a similar situation and the solution was a fresh build in my case.
<alan_g> alf: tried that, and deleting the cmake cache and regenerating
<alf> alan_g: ahh, got it... apt-get install libumockdev-dev
<alan_g> ?
<alan_g> That's why my test binaries are old?
<alan_g> Couldn't cmake give me a useful message instead of dropping build targets?
<alf> alan_g: https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 check comments from 2013-07-01 and on
 * alan_g glad he's not the only one not happy with this
<kdub> good morning
<alan_g> LOL
<kdub> welcome back alan_g
<alan_g> thanks kdub - looks like fun has been had while I was away
<greyback> hey, I'm using the cross-compiler script to build Mir. Is failing with this error: http://pastebin.ubuntu.com/5836380/
<greyback> where do I get libandroid-properties.so.1 ?
<kdub> greyback, i'll look for it...
<kdub> hopefully the script isnt broken
<greyback> kdub: thanks!
<kdub> greyback, i see the script in lp:mir downloading that dependency... perhaps merge the tip of lp:mir?
<kdub> and regenerate the ndk
<greyback> kdub: by "regenerate the ndk" you mean what exactly?
<kdub> rm the partial-armhf-chroot in the build directory
<greyback> gotcha
<kdub> greyback, the file appears to be in 'libandroid-properties1', by the way
<greyback> kdub: makes sense :)
<greyback> it's been downloaded into the chroot anyway
<kgunn> rebooting
<kdub> doh, my mir-devel mails were ending up in a never checked gmail folder -_-
<greyback> oh today is not my day with Mir. I'm on GalaxyNexus, using saucy flipped image, installed the mir-team/staging PPA, now mir_demo_server* fails this this error : http://pastebin.ubuntu.com/5836465/
<kdub> greyback, somehow, you look to be loading the mesa drivers
 * alf is unhappy that umockdev is leaking memory and his tests fail under valgrind :/
<greyback> kdub: sorry to sound like an idiot, but what driver should load?
<alan_g> alf should punish those that approved the MP
<kdub> greyback, it should link tho the hybris egl implementations, not the mesa ones. check where libEGL.so is resolving into
<greyback> alan_g: that's what reverting is for :)
<alan_g> alf: ^
<alf> greyback: alan_g: that's what whips are for ;)
<greyback> kdub: yep is mesa. but no idea where the hybris egl implementation is.
<kdub> greyback, i'd make sure you have libhybris installed (although i think its default on phablet)
<kdub> /usr/lib/arm-linux-gnueabihf/libhybris-egl/libEGL.so.1.0.0
<greyback> kdub: libhybris installed ok, but seems all mir demos are linked to mesa
 * alan_g has just lost all his window decorations
<kdub> we have like an 'on air' meeting in a bit?
<kdub> is that still true jono? :)
<dholbach> kdub, AFAIK it's kgunn, jono, pmcgowan, mramm, thostr_ (and a few others) giving a weekly update on ubuntuonair.com
<dholbach> or did kgunn send you as his replacement? :)
<kgunn> dholbach: coming....
<kdub> dholbach, nah, just made a note of 'mir meeting 5pm utc today' while reading planet ubuntu a while back
<dholbach> ahhhh ok
<kgunn> work still happens before the weekly ;)
<jono> kdub, Mir meeting is after the weekly update
<alan_g> Goodbye all
<kdub> english needs more synonyms for 'surface'
<kdub> racarr got lucky revno #800
<kgunn> kdub: i feel totally challenged....synonyms for surface
<kgunn> kdub: skin
<baronos> the last daily-live image the ubuntu is already with the mir by default?
<ogra_> baronos, images are only built from packages in the ubuntu archive ... Mir is not in the archive yet
<baronos> ok, thanks :)
<tvoss> RAOF, you about?
<RAOF> Yes.
<robert_ancell> thomi, there?
<tvoss> RAOF, mute mic and cam
<tvoss> :)
<thomi> robert_ancell: no, sorry, but I am now
<robert_ancell> thomi, np, on air session finishing now.
<robert_ancell> thomi, there wasn't any major testing questions for you :)
<thomi> robert_ancell: nuts, sorry, I completely forgot. TBH, somehow it never made it on my calendar
<thomi> sorry about that
<kdub> wait... is desktop using boost 1.53?
<racarr> Seems so
<kdub> doh. android is still using 1.49
<kdub> well, rather... if you cross compile using the scripts, its 1.49 (pbuilder probably does the right thing)
<racarr> somehow I am not getting a vtable for my interface
<racarr> SessionAuthorizer, when I remove the std::string argument
<racarr> the method gets inlined and there is no vtable for the whole class as far as I can tell
<racarr> what does it mean :
<racarr> (
<racarr> oh it means I deleted the = 0
<robert_ancell> RAOF, ping
<robert_ancell> RAOF, It seems the vladmir-ubuntu branch is the correct xserver branch, not vladmir - Is there a way to set up github to use vladmir-ubuntu by default? Or delete the old branch / update it?
<racarr> for each acceptance test client that is connecting
<racarr> SocketSession::on_new_connection is being called twice
<racarr> and it's being added to the
<racarr> connected sessions list twice
<racarr> except the first time the socket credentials are nonsense
<racarr> and the second time they are the correct client PID
<racarr> oO
<RAOF> robert_ancell: github now shows vladmir-ubuntu by default. I forgot that I'd started to just make changes directly to the ubuntu branch.
#ubuntu-mir 2013-07-03
<bschaefer> RAOF, hey, been using normal X and no event queue overflowing
<RAOF> bschaefer: Ta.
<RAOF> So we're doing something that's slowing you down.
<bschaefer> RAOF, np, is there a way I could start debuging this?
<RAOF> Oh! Next time you see that, could you check dmesg? It's entirely possible that what's slowing you down is that the GPU is hung and getting reset :)
<bschaefer> RAOF, recompiling
<bschaefer> RAOF, yes I can! Is it fine checking it on a reboot?
<RAOF> Yes, but dmesg  will obviously have been blown away by a reboot :)
<bschaefer> [ 1204.260268] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
<RAOF> But you should be able to find that in syslog.
<bschaefer> that sounds bad
<bschaefer> RAOF, cool, Ill switch back over to xmir and gather some more info!
<bschaefer> but that was a segfault in libgrid.so/compiz which I was messing around with that...so im guessing that was me :)
<RAOF> Heh
<kdub> if anyone's got some spare cycles :) lp:~kdub/mir/remove-surface-target
<RAOF> kdub: InputChannel seems like the wrong name for that class. But I can't offhand think of a better one.
<kdub> RAOF, yeah, i just adopted a name that was already there
<RAOF> Actually, is there any particular reason it shouldn't be SurfaceInfo?
<RAOF> That's what it appears to contain.
<RAOF> Also, âª doxygen comments, doxygen comments â«
<kdub> well, SurfaceInfo is an object that contains the data common to both the input and graphics side of things
<kdub> so as it is now, both have a pointer to the object with all the data, instead of them trying to both get at the same data via inheritance
<kdub> (which isn't threadsafe in trunk anyways)
<RAOF> But an InputChannel is *also* just an object that contains the data common to both the input and graphics side of things?
<kdub> well, its the interface that the input system gets at that data
<kdub> really, both the compositor and the input stack should get a SurfaceInfo object and a Renderable/Channel (respectively)
<kdub> but that made for more and more churn
<RAOF> Right.
<RAOF> I don't want to make the perfect the enemy of the good here, but client_fd() and server_fd() are both also info about a surface, and it looks to me like everywhere you pass an InputChannel you could pass a const SurfaceInfo, *and* that would be clearer.
<kdub> i agree it would be cleaner
<kdub> well, actually, i have to think about it a bit more
<kdub> the input system registers one object...
<RAOF> I also don't see it as being significant extra work, but that's from my perspective of reading over the MP and not being the *target* of that extra work, so may well be wrong :)
<RAOF> Oh, I guess it would mean that SurfaceInfo is not atomically correct - you'd need to populate it with data from two separate places...
<kdub> yeah
<RAOF> Sweet! Anything including glib fails to build with -Werror under clang.
<duflu> :(
<RAOF> At least with clang-3.4; we're good with clang 3.2 for a while.
<duflu> glib requires everything start with "g", including the compiler
<duflu> Although that is almost surprising because glib has long been ported to Windows and beyond. So it has good compiler portability
<duflu> -good +adequate
<RAOF> âregisterâ is deprecated in C++11 (and maybe C11?), which is why clang fails.
<RAOF> Presumably g++ will fail there too, once it catches up with the standard.
<RAOF> duflu: Oh, by the way - have you thought about submitting a paper for LCA?
<RAOF> Since you'll be in the neighbourhood anyway :)
<duflu> RAOF: Wha?
<duflu> RAOF: Hmm, why must they deprecate "register" when it would be less harmful to just ignore?... :S
<RAOF> Linux.conf.au. Is in Perth in January, where I presume you will also be.
<duflu> RAOF: Yes, I see. They fail to mention that on the main LCA site
<RAOF> Oh, that it will be in Perth? Really?
<duflu> RAOF: Oops, that's linux.org.au that's out of date
<RAOF> http://linux.conf.au/ says âWhere: University of Western Australiaâ, which strongly suggests Perth :)
<duflu> -org +conf
<duflu> And you'll see it
<duflu> kgunn: This estimates work, I feel will take longer. But I also feel adding a few days may not improve the accuracy of my findings. I have a lot to learn about libmirserver and our approach to "buffers" still
<kgunn> duflu: i hear you
<kgunn> hmmm, anyone experienced using xmir just fine...then after rebooting once, seemingly u-s-c not starting, end up in vanilla x
 * duflu updates and tests
<robert_ancell> RAOF, with your drm changes Mir no longer starts for me. It appears to be because it is picking card0 to use, which is the nvidia card in my laptop. It used to pick card1 because it prefererred intel over nouveau.
<robert_ancell> RAOF, Q1 - should card0 work anyway?
<robert_ancell> Q2 - How would we detect that card1 is the more appropriate card?
<RAOF> robert_ancell: Does card0 have any outputs attached?
<robert_ancell> RAOF, how would I know?
<RAOF> ls /sys/class/drm
<duflu> kgunn: Yes, I'm now getting regular X with type=unity
<RAOF> You'll get a bunch of card0, card1, card1-$DISPLAY_CONNECTOR, and (if card0 is connected to anything) a bunch of card0-$DISPLAY_CONNECTOR
<duflu> Checking for cause...
<robert_ancell> RAOF, http://paste.ubuntu.com/5839255/
<robert_ancell> No DP - but otherwise the same?
<RAOF> Yup, you've got output attached to both.
<RAOF> Or, at least, *connectors* attached to both.
<duflu> kgunn, robert_ancell: Yup, lightdm 1.7.5bzr1634saucy0 is not starting the system compositor. It's using legacy X even with type=unity
<RAOF> We've previously determined that you don't have a vga_switcheroo debugfs switch to frob, haven't we?
<duflu> Got a bug yet?
<robert_ancell> duflu, and the logs say?
 * duflu looks
<robert_ancell> RAOF, last we tried I don't think I had any switches..
<RAOF> robert_ancell: So, there's already a herustic in there to not start on any GPU which doesn't have any connectors, and that fixes *my* laptop.
<robert_ancell> RAOF, the specific thing it's failing on is gbm_surface_lock_front_buffer, not sure if that helps at all
<duflu> robert_ancell: lightdm logs say starting USC, but silently does not and uses plain X... ?
<robert_ancell> duflu, can I see?
<duflu> kgunn: Can you log a bug for it?
<RAOF> I'm not sure why it'd fail there, although possibly because we're doing something stupid and asking for an invalid framebuffer, like 0x0.
<kgunn> duflu: i saw same in the log...just complains no usc start
<RAOF> robert_ancell: To fix this in general I think we need to create a GBM backend for each GPU, actually probe the connected outputs, and bring up display on each connected output. This would fix your case because your nvidia card has no connected outputs (although it does have connectors)
<kgunn> will do
<duflu> robert_ancell: USC log shows command line help, as if lightdm is giving bad options
<duflu> At least fallback works :)(
<robert_ancell> duflu, sounds like you have an old u-s-c that doesn't support the vt option
<duflu> robert_ancell: No, the command line help mentions vt
<robert_ancell> duflu, and what does lightdm.log say the command line was?
<duflu> robert_ancell: This is getting messy. I'll put it in a bug
<duflu> In kgunn's bug
<robert_ancell> RAOF, can I do anything to debug from this end?
<duflu> robert_ancell: USC doesn't understand --{from,to}-dm-fd
<robert_ancell> duflu, huh, that's weird
<duflu> Glad to see automatic fallback is seamless tho
<robert_ancell> did something change in the option parser code?
<duflu> No idea
<robert_ancell> RAOF, i.e. is this just a matter of putting more code into is_appropriate_device?
<RAOF> robert_ancell: We could do a full output probe in is_appropriate_device; I think that would fix it for you.
<robert_ancell> RAOF, what's the API for that? I'll hack it up here
<RAOF> robert_ancell: You want to pull the drm fd opening bits out of int mggh::DRMHelper::open_drm_device(UdevHelper const& udev)
<RAOF> Then set_master on that fd (see int mggh::DRMHelper::open_drm_device(UdevHelper const& udev))
<RAOF> Then do the actual probe - kms_display_configuration.cpp and drm_mode_resources.cpp have that code.
<kgunn> https://bugs.launchpad.net/unity-system-compositor/+bug/1197232
<ubot5`> Launchpad bug 1197232 in Unity System Compositor "Lightdm can't start Mir (unity-system-compositor) and falls back to legacy X" [High,Confirmed]
<kgunn> oh...you already saw it
<RAOF> robert_ancell: Hm. I think you might be able to get away with just getting up the setting drm master bit, and then creating a KMSDisplayConfiguration from that fd.
<robert_ancell> RAOF, ta
<RAOF> (That list of steps should make it obvious that this is not a correct fix âº)
<RAOF> Woot! std::initializer_list!
<robert_ancell> RAOF, but is that conceptually the right thing to do? i.e. open, set master, probe outputs, bail if there aren't any
<RAOF> robert_ancell: Conceptually the right thing to do is to open, probe outputs, and only put up displays on anything with an output.
<RAOF> So it's almost the right thing to do conceptually.
<robert_ancell> duflu, looks like my --version change broke it..
<RAOF> ie: the end state that we need to be in is for the GBM platform to have all the drm devices open, and handle that appropriately.
<robert_ancell> RAOF, that's what X does right? (according to the X log)
<RAOF> Right.
<RAOF> Well, except I don't know if it handles two gpus, both of which have connected outputs.
<robert_ancell> duflu, kgunn, was this from the staging or the system-compositor-testing PPA?
<kgunn> robert_ancell: i'm pinned to system-comp-testing
<robert_ancell> duflu, fix is https://code.launchpad.net/~robert-ancell/unity-system-compositor/fix-dm-fd-options/+merge/172729
<robert_ancell> Boost options uses some weird templating stuff.
<robert_ancell> Does anyone know why std::cerr doesn't seem to work from inside the gbm code?
<duflu> robert_ancell: SCT PPA
<RAOF> robert_ancell: It sholud work inside the gbm code? It worked for me when I was doing printf debugging.
<RAOF> robert_ancell: Although if you're running âmake testâ then that eats all test output, for maximal annoyance.
<RAOF> Although now *I* can't get cout or cerr to print anything?=
<robert_ancell> RAOF, yeah, odd right!>
<robert_ancell> ?
<RAOF> Hah, no false alarm.
<RAOF> exception raised before it would have printed something
<RAOF> Nope, works fine here.
<robert_ancell> RAOF, maybe I did the same thing
<duflu> bbl
<tvoss> good morning :)
<tvoss> RAOF, robert_ancell for maximum make test noise, try ctest -V :)
 * RAOF stalks robert_ancell
<duflu> Wow Mir builds really quick when the tests are disabled for you ;)
<RAOF> :)
<RAOF> robert_ancell: It's possible that I've mislead you, and there's something cheaper we could use as a herustic.
<RAOF> robert_ancell: Can you pastebin the output of running "umockdev-record /sys/class/drm/card*"?
<robert_ancell> RAOF, I seem to have it working
<RAOF> Ah, sweet.
<robert_ancell> RAOF, see lp:~robert-ancell/mir/gbm-check-connections and see if that makes sense
<robert_ancell> I don't think we need DRM master unless we're actually rendering something
<RAOF> That'd be true. Or, rather, unless we're trying to change the mode.
<robert_ancell> It works for me, but I'm trying to fix the tests
<robert_ancell> card0 has 0 connections, and card1 has 1 so it picks that one
<duflu> Oh, it's a Wednesday so Mir doesn't work again :(
<duflu> My fault for updating... something...
 * duflu reboots
<robert_ancell> duflu, hikiko, racarr, alf, kgunn, tvoss, thomi, meeting
<robert_ancell> kdub, too
<tvoss> robert_ancell, mind adding me to the hangout, would like to join on the ipad
<duflu> bye, Bye, BYE, by
<RAOF> BYE!
<alf> bye-pass
<duflu> Argh
<dholbach> good morning
<duflu> dholbach, hi
<dholbach> hey duflu
<duflu> RAOF: glDrawArrays now SIGSEGV's for me in Mir clients :(
<duflu> That's raring, maybe saucy is still good
 * duflu checks
<duflu> Nop, saucy is broken too
<duflu> Yay
<duflu> https://bugs.launchpad.net/mir/+bug/1197260
<ubot5`> Launchpad bug 1197260 in Mir "Mir GL clients are crashing with SIGSEGV inside gl* calls" [Critical,New]
<duflu> RAOF: What changed in Mesa?... Or should have changed? https://bugs.launchpad.net/mir/+bug/1197260
<ubot5`> Launchpad bug 1197260 in Mir "Mir GL clients are crashing with SIGSEGV inside gl* calls" [Critical,New]
<RAOF> I'm not sure; investigating.
<duflu> Because the lp:mir that worked yesterday doesn't any more. The only thing I changed was my Mesa debs from PPAs
<RAOF> I don't think I changed anything in the Mesa ppas?
<RAOF> duflu: Most recent build of Mesa was on the 28th.
<duflu> RAOF: Yeah I have avoided system updates for a few days for this kind of reason
<RAOF> Heh.
<duflu> RAOF: Still looks like Mesa
<RAOF> Kindly wait while my internet pigeons grab me the crumbs my router will reassemble into the PPA's packages so I can test the latest stuff.
<duflu> Oh that reminds me
 * duflu sends another email
<RAOF> Man, your internet is so awesome!
<duflu> I think my copper has gaps, and I'm relying on slightly moist soil in between
<RAOF> Troubling in Perth. You'll lose all internet in the summer!
<duflu> RAOF: Oddly, Summer is when it last worked properly
<duflu> So my hypothesis must be wrong
<RAOF> Possibly you're missing some insulation, so it's grounding when the soil is moist.
<duflu> RAOF: Well if Telstra don't find/fix a problem I have a lot of wiring to experiment with :(
 * duflu doesn't want to have to rig up a phone socket in the front garden just to prove a point :P
<mlankhorst> hahah
<alf> mlankhorst: Is the dmabuf system memory pinning issue for gallium or radeon only?
<mlankhorst> for ttm
<mlankhorst> so strictly speaking nouveau too
<alf> mlankhorst: ok, so intel escapes :)
<duflu> Sounds like a big deal. We may as well just have shm :)
<mlankhorst> well that's pretty much it
<mlankhorst> :P
<duflu> alf: How is a "Prime" fd guaranteed valid across processes?
<alf> duflu: we send it as we would any fd, through unix sockets
 * duflu still doesn't get it. The allocation of the fd number is local to the client. So how does it work coming from the server process?
<alf> duflu: the client gets a different fd, which is backed by the same internal file information internally in the kernel (like when you dup())
<alf> duflu: so it's a cross-process dup()
<duflu> alf: OK. So I missed the part where the fd int changes...
<duflu> grayback: Someone said you had similar issues to https://bugs.launchpad.net/mir/+bug/1197260
<duflu> ?
<alf> greyback: FYI, duflu encountered a similar problem with the one you had yesterday with Mir egl clients, and RAOF is looking into it
<ubot5`> Launchpad bug 1197260 in Mir "Mir GL clients are crashing with SIGSEGV inside gl* calls" [Critical,New]
<duflu> greyback, ^
<alf> duflu: talk about perfect coordination :)
<duflu> alf: I am disturbed by the synchronisation of our thoughts
<duflu> But it might be handy
<greyback> alf: duflu: thanks for the update! I managed to get a working system from an older spin, so I'm ok for now
<duflu> greyback: What worked for you? Was it Mesa updates?
<duflu> Or "down-dates"?
<greyback> duflu: older mesa release
<duflu> Yup
<duflu> Cool, thanks
<duflu> RAOF: FYI ^
<tvoss> duflu, alan_g, RAOF so what is a good way forward to handle the issue of missing build-dependencies for tests?
<duflu> tvoss: I was going to just improve the CMakeLists around the place to disable the tests that are untestable
<duflu> And keep as much as possible enabled
<alan_g> If build dependencies are missing cmake should report it
<alan_g> (by failing)
<tvoss> I think we all agree that just disabling tests is a bad idea. My pov: build fails when tests cannot be built and run. The tests are as important as the actual code
<duflu> alan_g: Yeah it will always be reported. Just as warning, not error
<alan_g> warnings get ignored
<alan_g> It needs to be an error
<tvoss> duflu, I'm not entirely sure that this scales. We add a massive amount of logic to the build system setup just to end up in a situation where we potentially disable all tests anyway
<duflu> tvoss: I disagree. Outside of Ubuntu NO ONE will care about test failures. Same as when you're packaging any project from an external upstream.
<duflu> People don't run tests. They rely on the maintainers to run tests and verify they pass
<tvoss> duflu, then we can as well have an option: MIR_DISABLE_TESTS
<duflu> tvoss: I think disabling all tests is a bad move. I'm happy to make it possible to run as much testing as possible
<duflu> Hmm, maybe I need to not sound like I'm arguing both sides
<tvoss> duflu, well, if no one is going to run the tests except for us, we shouldn't invest the time/effort/hassle to make it possible for them :)
<duflu> tvoss: It's for me, I am going to fix it :)
<duflu> I care about test failures. Other distros don't. I mean...
<tvoss> duflu, let's just have an option MIR_DISABLE_TESTS_DURING_BUILD that people can explicitly request
<tvoss> duflu, if that option is set, we skip the checks for test build-deps anyways and everyone is happy
<alan_g> duflu: tvoss - alf has thoughts too: https://bugs.launchpad.net/mir/+bug/1196987/comments/3
<ubot5`> Launchpad bug 1196987 in Mir "Most tests are silently disabled if libumockdev-dev is missing" [Medium,Confirmed]
<duflu> tvoss: OK, so long as tests are enabled by default. And preferably avoiding double negatives (don't call it "DISABLE")
<duflu> Call it MIR_ENABLE_TESTS (default true)
<tvoss> duflu, @double negatives: fair point, it is MIR_ENABLE_TESTS
<tvoss> \o/
<duflu> Then I will add more granularity when I get around to it...
<tvoss> duflu, fair, but as you said: only we care about the tests, external packagers most likely will not care
<duflu> tvoss: Remind me why you need the option? We already skip *all* tests when umockdev is missing. That's enough for other distros too
<tvoss> duflu, yup, but I want to make it an explicit and conscious choice instead of taking that decision automatically
<tvoss> duflu, if someone switches the option to OFF, I would like to have a big warning on the terminal that it is a bad idea
<duflu> tvoss: Hmm, oookaaay. So long as the CMake error tells the user how to disable them :)
<alf> alan_g: duflu: tvoss: this is a chance to make some of our other dependencies (e.g. gmock) test only dependencies, i.e., don't fail if gmock is missing nad MIR_ENABLE_TESTS=false
<duflu> It's a good first step. And one we have time for right now
<tvoss> alf, sure, I think the dep checking for tests should be moved to subdirectory tests in the respective CMakeLists.txt, and we only inlcude that subdirectory if the enable option is ON
<tvoss> duflu, +1
 * alan_g so long as cmake fails by default if anything (including tests) can't be built and run 
<tvoss> alan_g, that's the plan
<duflu> And it's made very clear to the user *how* to build without the tests, and get over the line
<tvoss> duflu, that's definitely doable
<alan_g> duflu: and equally clear which dependencies are missing
<tvoss> alan_g, can you look into adding the respective option?
<duflu> Alright. Tests enabled and passing means "The Mir team fully expects Mir to work on this system". Anything else and we make no guarantees
<alan_g> tvoss: sure (although duflu has grabbed the bug)
<duflu> Although, AFAIK you can successfully build Mir without the requisite Mesa changes :)
<duflu> alan_g: Not as of 2 minutes ago
<alan_g> :)
<tvoss> alan_g, have fun then :)
<duflu> Sigh. I think I just agreed to having to do all future Mir work on my slow saucy machines :P
<alan_g> duflu: @"AFAIK you can successfully build Mir without the requisite Mesa changes" - sounds like missing tests
<duflu> alan_g: Not sure. Needs checking
<duflu> Also, that's a question we should all know the answer to
<duflu> Basic Mir dependencies...
<alan_g> duflu: +1
<duflu> alan_g: You (or someone) restyled doxygen? ... http://unity.ubuntu.com/mir/index.html
<alan_g> duflu: ack
<duflu> alan_g: Feels a bit better
<alan_g> duflu: glad you like it.
<duflu> alan_g: I think the function docs feel cluttered still. But that's likely only because so many lack documentation and it's just headers
<hikiko> alan_g, can I ask you something for mir on mir?
<alan_g> hikiko: sure
<alan_g> duflu: there's more to be done, but that got things closer to "house style"
<RAOF> Needs more aubergine :)
<tvoss> RAOF, ;)
<tvoss> RAOF, please file a bug ;)
 * alan_g ducks
 * tvoss thinks that it might be possible to get rid of the weird -DBOOST_ASIO_DISABLE_* cpp definitions for the package build
<hikiko> I have the following issue: I was starting the nested server and then the nested was connected to the host server, but the result wasn't exactly a nested server but mostly a connected one, so I moved the code to the mir_demo_server example and performed the connection before anything and the result was much better but! I'd like to do it properly and move the connection code to the mir initialization, so I wonder if you can give me an idea on where
<hikiko>  to look at... (I saw that there's the run_mir.cpp and DisplayServer in src/server do you think is this the right place?
<duflu> http://design.ubuntu.com/brand
<duflu> RAOF: A little bit: http://design.ubuntu.com/brand/colour-palette#the-amount-of-colour-we-use
<alan_g> hikiko: I don't follow "the result wasn't exactly a nested server but mostly a connected one"
<hikiko> well it was running on a different tty
<hikiko> but it was connected to the mir server
<hikiko> because the connection was performed after the server was starting
<hikiko> if I move the code at the beginning of the mir_demo server
<hikiko> the nested_mir appears inside the host server
<hikiko> which I guess is what we want
<hikiko> so, I'd like to remove the connection from the demo_mir_server
<hikiko> and put it somewhere in the mir startup
<alan_g> hikiko: let me have a look at your code and we'll hangout in half an hour?
<alan_g> Which branch?
<hikiko> yes but let me push a recent version in 5 minutes
<hikiko> https://code.launchpad.net/~hikiko/mir/mir.nested-gbm
<hikiko> this one
<alan_g> hikiko: let me know when you've pushed
<duflu> Hmm, it seems a lot of people are jumping in to mir_demo_server because of its name. When they actually would benefit from mir_demo_server_shell instead. I think we have a minor communication issue
<duflu> _shell sounds like a shell but we need to communicate it is a _server too
<hikiko> you can start looking at it if you have some time the changes aren't big I was just moving the connection part here and there :) pushed right now :)
<RAOF> Bah, stupid mesa.
<duflu> Bah, dinner
<duflu> That doesn't even make sense
<alf> RAOF: alan_g: I was thinking... Mesa doesn't need to link to libmirclient, it just needs some headers. It does need access to the  mir_egl_mesa_display_is_valid() symbol which is provided either by libmirserver or libmirclient, but it can pick that up automatically during dynamic linking.
<alf> RAOF: alan_g: which I guess is another reason to not link to libmirclient...
<alf> tvoss: @mesa, I think the best way (at least the best that has come up so far :)), is for mesa to dlopen(NULL), dlsym("mir_server_egl_mesa_display_is_valid"), dlsym("mir_client_egl_mesa_display_is_valid") and try all of the available mir_*_is_valid() functions when checking.
<tvoss> didrocks, hey there, looking at pulling out gmock again. Remind me, is the ftbfs for gmock fixed, yet?
<didrocks> tvoss: the fixed package is available on the link I gave you
<didrocks> tvoss: but all projects needs now to build their own gmock from this source, no more shared library
<didrocks> so we nede to patch the rdepends
<tvoss> didrocks, trying to get the rdepends but apt-rdepends tells me that it cannot resolve reverse build-deps
<didrocks> tvoss: try reverse-depends -b
<tvoss> didrocks, and I'm only looking into main, right?
<didrocks> tvoss: no, we'll need everything to be ported
<didrocks> tvoss: otherwise, we can't move further along
<tvoss> didrocks, ack
<tvoss> didrocks, however reverse-depends -b is a manageable list
<didrocks> tvoss: it is, just need to have time for it :)
<tvoss> didrocks, fair. so could we live with mir carrying its internal gmock version when entering universe and treating as another reverse build-dependency of gmock once we landed?
<didrocks> tvoss: no, we can't get it with this internal version
<tvoss> didrocks, why is that?
<didrocks> tvoss: because it's not what we do for components in the distro
<didrocks> tvoss: and we know that with time pressure, we'll overpass it
<didrocks> this already happened in the past
<didrocks> so let's try to have it ready before entering
<didrocks> knowing that step1 is having it building on armhf and powerpc anyway :)
<tvoss> didrocks, we have got a problem then: no one has time to fix the reverse-build-dependencies of gmock, but mir needs the fixed gmock version
<tvoss> didrocks, how can we push forward here?
<didrocks> tvoss: well, find time for it
<didrocks> which isn't going to happen if we spend all our time discussing about it
<didrocks> there are enough other blockers anyway on the list, this one shouldn't be the priority right now
<didrocks> the armhf and powerpc ones should be
<tvoss> didrocks, for the powerpc ones. I thought we agreed that we disable the tests on powerpc?
<didrocks> tvoss: yeah, it just needs to get done
<tvoss> alan_g, we might want to use the MIR_ENABLE_TESTS option for that, too :9
<tvoss> alan_g, are you looking into that option?
<hikiko> hi, question: what does the gbm/gbm_display.cpp configure() function?
<hikiko> I am trying to understand if I need something like that for mir-on-mir because if I leave the func completely empty I get compile errors
<alan_g> tvoss: preview here: https://code.launchpad.net/~alan-griffiths/mir/fix-1196987/+merge/172798
<alf> hikiko: It configures the displays (e.g. sets up the monitor etc). You will eventually need to implement it, but probably don't need it right now. What error do you get?
<hikiko> alf, https://pastebin.canonical.com/93745/
<hikiko> i think it's irrelevant
<hikiko> sorry :)
<alan_g> alf: are we intending to use libumockdev for anything other than unit tests?
<alf> alan_g: We may want to use it for tests in general, not just unit tests.
<alan_g> alf: I suspected as much. ;)
<alan_g> alf: do you know of a better option than the LD_PRELOAD=libumockdev-preload.so ugliness?
<alan_g> I really hate it that running unit-tests produces a core
<alf> alan_g: The idea I had in mind was to create a MockUdev object (like we have MockGL), and forward the udev calls to symbols dlsym()-ed from a dlopen()-ed libumockdev-preload.so
<alf> alan_g: which is not less ugly, but at least it is hidden :)
<alan_g> alf: thinking about it - how can *unit* tests depend on umockdev?
<alf> alan_g: But I need to check if this will actually work as expected
<alan_g> Sure. I'm going to file a bug - feel free to grab ownership.
<alf> alan_g: We are using a link-time seam for udev
<alan_g> alf: my point was that *unit* tests shouldn't be hitting udev
<alf> alan_g: Well, link seams blur the line between unit and integration tests.
<alan_g> alf: OK. I've just logged the broken LD_PRELOAD seam. Not going to get into the unit/integration test debate.
<alf> alan_g: thanks, btw, the direct use of udev in the display-configuration-change-handler MP, will go way when RAOF's C++ Udev classes land, hopefully along with an interface we can inject and mock.
<alf> alan_g: At least, that's my plan :)
<alan_g> alf: cool.
<alan_g> alf: hikiko: There's a lot of info floating around "in people's heads" - we should reinstate the daily standup to keep folks in the loop. (Let's have a EU one at least.)
<alf> alan_g: we can do it at 16:00 UTC (as before) to allow US people to join if they want to.
<alf> alan_g: actually 16:00 UK time not UTC
<alan_g> Sure. A 5 minute hangout at 15:00UTC/17:00CET
<kdub> yay, flipped images
<ogra_> :)
<kdub> very cool :)
<kdub> racarr, ping
<kdub> also, what if we had a policy that for interface Interface...
<kdub> we mock it using gmock and call it MockInterface
<kdub> and then typedef a NiceMock of MockInterface, calling it StubInterface
<kdub> and put all that in the include/test/mir_test_doubles/mock_interface.h file
<kgunn> bregma: hey, i know arm builds were angry due to expecting valgrind....do you know what the proposed solution is ?....is it simply a option/switch on mir tests ? (e.g. was tvoss proposing some MIR_ENABLE_TESTS option fot that)
<bregma> I have a patch that just switches off tests with valgrind (the trivial solution) but one of the tests hangs (valgrind or no) on a deadlock condition, I've spent the last 2 days trying to track it down
<bregma> in particular, TestClientIPCRender.test_accelerated_render deadlock on my arm device (an N7)
<kdub> bregma, that test actually drives the driver... might be an actual bug on the n7
<bregma> maybe, but valgrind actually spews a whole lot of double delete errors before the hang, so it's possible there's a code fault
<bregma> at this point I may just suggest that test be disabled until someone with more in-depth knowledge can look at it
<bregma> it stymies me
<kgunn> bregma: let's get didrocks ok with that....i will help convince :)
<bregma> I'll keep poking at it until he agrees
 * bregma gnaws at problems like a dog at a bone
<mterry> robert_ancell, heyo!  So we talked about the greeter-mir API as being over DBus.  Mir doesn't seem to use DBus at all right now, is that right?
<robert_ancell> mterry, correct, but the API would be to u-s-c, not Mir
<robert_ancell> tvoss, around?
<mterry> robert_ancell, ah
<greyback> racarr: ping
<racarr> greyback: Pong
<greyback> racarr: hey, I might be mis-understanding SessionListener, but in the code I've written I'm not being notified of new sessions. Can you have a look: lp:~gerboland/+junk/qml-demo-shell/
<greyback> racarr: see unity-mir/shellServerConfiguration_p.h for where I register a SessionListener
<racarr> greyback: Looking
<mterry> robert_ancell, anyway, same deal.  No current dbus use.  So I'll just make something up interface wise and you can correct me during review
<robert_ancell> mterry, yep
<racarr> greyback: It's "the_shell_session_listener"
<racarr> that you need to override
<racarr> you can use override keyword in C++11
<racarr> i.e. like
<racarr> the_session_listener() override
<racarr> to get compile errors
<greyback> racarr: ah was that it. Damn
<racarr> on stuff like this
<greyback> yep
<racarr> aha, no worries. I lost so much time to stuff like this before we switched to a G++ that supported override
<greyback> must've missed that. Ok
 * greyback kicks himself
<kdub> its interesting how good your eyes get at scanning g++ explosions quickly
<kdub> RAOF, I implemented that change we were talking about yesterday where input channel and surface info are submitted separately to the input system
<kdub> definitely makes for nicer interfaces :)
<kdub> thomi, do we have the infrastructure to get the nexus 4 tests run in our CI?
<thomi> kdub: let me ask, one second
<kdub> cool thanks :)
<robert_ancell> kdub, https://code.launchpad.net/~kdub/mir/cross-compile-script-boost-version/+merge/172686 - libboost-chrono-dev depends on libboost-chrono1.53-dev (and will be updated as future versions come out)
<robert_ancell> So agree with Alan here, if we don't care for a specific version, just use the unversioned -dev packages
<robert_ancell> I wasn't sure if we intentionally had the specific versions for a reason, I have heard boost is somewhat API unstable
<kdub> robert_ancell, yeah, i just have to figure out boost's packaging a bit better to download what I need
<robert_ancell> racarr, ping
<mterry> robert_ancell, so in u-s-c, what libraries are allowed?  glib is probs out.  So I imagine is Qt?
<mterry> robert_ancell, just looking at dbus solutions for c++
<robert_ancell> mterry, I guess Qt is OK? We can always swap out later if a problem
<robert_ancell> mterry, glib would be fine since lightdm is using it anyway
<mterry> robert_ancell, ok, that's easier than I thought.  I'll look at QtDBus first
<mterry> more c++y
<robert_ancell> yeah, probably will fit better
<racarr> robert_ancell: Pong
<robert_ancell> racarr, hey, do you get the opposition to putting the pid in the protocol?
<kdub> i was just writing a comment on that one :)
<RAOF> mterry: tvoss has a super-funky C++ dbus library under development, you could find that :)
<racarr> robert_ancell: Sort of
<racarr> I think the same way FDs are passed over the protocol in a side band
<racarr> you could say the client credentials are
<mterry> super funky eh?
#ubuntu-mir 2013-07-04
<racarr> but uh, yeh I'm trying to remove it from the proto
<racarr> there is some weirdness that goes on below the session mediator
<racarr> that I don't entirely understand yet
<racarr> robert_ancell: The other thing is if we reject connections
<racarr> in the communicator as suggested, then we reject them before we read the client name
<robert_ancell> racarr, no - there's an important difference. In the fd case, one end sets the fd in the message, it is removed from the message and transmitted out of band and then refilled in the receivers message (with a different numerical value)
<robert_ancell> In the pid case, the client never sets the value, and the server never reads the value from the message (it reads it from the socket)
<robert_ancell> So conceptually, the pid is not part of the protocol
<racarr> so we have to change the model, the idea was before, the clients send their name/.desktop file and the shell matches up (i.e. this pid is allowed to have the desktop)
<racarr> to just the shell fills in the name
<racarr> based on the pid
<racarr> and I haven't figured out the best way to propose all that yet.
<racarr> robert_ancell: The client sends the pid, it's just hidden away
<racarr> in the call to open
<RAOF> If the client sends the pid we can't trust it.
<robert_ancell> racarr, the system sets the pid, the client never sets it
<robert_ancell> it's completely transparent to the client
<racarr> RAOF: I mean the socket credentials
<RAOF> If you're trying to do authentication, you can't possibly trust anything the client sends you.
<robert_ancell> RAOF, no, he's using it in the message as a convenience when we pass it around the server. It's set on reception of the message
<robert_ancell> It's true that the pid is associated with the message, but it's not part of it
<RAOF> racarr: I guess. I think you'll technically find that it's the kernel that sets the pid, and probably only when you ask it.
<racarr> No, it always sets it
<racarr> POSIX models is as an implicit out of band message, just like FD passing
<racarr> linux has a special API with getsockopt to read it without using recvmsg
<racarr> I dunno
<RAOF> racarr: If it's set in the client, then we can't trust it - because we can't trust that the client hasn't interposed an open() implementation that sets a bad pid.
<RAOF> Ah, but I see that's not what you're actually saying. :)
<racarr> mm
<racarr> RAOF: The context, is that it was just easiest with the current abstractions to add it as a field to the ConnectParameters protobuf message and fill it in based on the socket credentials
<racarr> in the message processor
<racarr> and I don't think this really breaks any abstractions horribly
<robert_ancell> racarr, but that's bad because it exposes this detail all the way back to the client via the .proto which is very confusing
<RAOF> racarr: This would be https://code.launchpad.net/~robertcarr/mir/implement-client-credentials/+merge/171889 right?
<robert_ancell> racarr, and unnecessary as long as you pass meta information with the message in the server or set the PID as a property of the Session
<racarr> Oi
<racarr> robert_ancell: And how do you pass the pid up
<racarr> from the RPC part of the frontend
<racarr> I mean it has to pass through the SessionMediator
<racarr> where the interface is generated from the .proto file
<racarr> or you have to do it beore the SessionMediator (i.e. before there is a session, and the name is read, etc)
<racarr> I
<racarr> am not interested in being right or wrong about this though :p
<racarr> i've already moved it out like I said, and moved it to the communicator
<racarr> I'm just running in to some
<racarr> bugs/non understood behavior
 * robert_ancell dives into the complexity of the frontend..
<racarr> notably on_new_connection is called twice (in the acceptance tests at least)
<racarr> for each client
<racarr> and both times added to connected_sessions
<racarr> the first time the socket credentials I get off the pid are
<racarr> some sort of nonsense
<racarr> neither the client or the server process pid
<racarr> but very close!
<racarr> numerically that is
<racarr> That was EOD yesterday
<racarr> ill revisit it soon
<RAOF> From the MP it sounds like what the shell actually wants is a callback when a certain pid connects.
<RAOF> Maybe you don't need to pass the pid up at all?
<robert_ancell> RAOF, you need the PID for the shell to match an incoming Mir connection with the app the shell launched
<robert_ancell> closing the loop
<robert_ancell> though you're stuffed if the app forks...
<racarr> RAOF: The thought was originally you needed to mtch the pid with the name
<racarr> which isn't read until the SessionMediator (or the processor, preparing to invoke the session mediator, at least)
<racarr> but yes, that is the idea now, just dont pass it up
<racarr> and do it in the communicator
<RAOF> Ah.
<racarr> on_new_connection
<robert_ancell> Argh, There really should be a SessionMediator per connection. That's dumb
<racarr> which is where I ran in to this strange behavior
<racarr> robert_ancell: ? There is
<RAOF> It seems like pid would be a perfectly reasonable property of a SessionMediator.
<robert_ancell> yeah
<racarr> Yes
<RAOF> Should we at some point need to pass that up :)
<racarr> I think it's the natural place to put it  :p
<racarr> but the SessionMediator interface
<racarr> is generated
<racarr> by the .proto
<racarr> is the whole point
<robert_ancell> racarr, no it isn't - it extends the interface generated in the .proto
<robert_ancell> so you can attach additional information
 * robert_ancell chases make_ipc_server() backwards
<racarr> robert_ancell: class SessionMediator : public mir::protobuf::DisplayServer
<robert_ancell> racarr,  mir::protobuf::DisplayServer is generated, but SessionMediator is not
<racarr> I know but you have to do it in the
<racarr> connect method
<robert_ancell> racarr, but by the time you get to the connect method, the PID will already be set for that instance of SessionMediator
<robert_ancell> or is SessionMediator created after a connect?
<RAOF> Why do you have to do it in the connect method?
<racarr> well. I guess you don't hve to
<robert_ancell> racarr, Can't you get the PID in mf::ProtobufSocketCommunicator::start_accept and  make it an arg to make_ipc_server?
<racarr> Sure
<robert_ancell> actually, that's weird - we create a SocketSession before on_new_connection is called
<robert_ancell> that seems wrong
<racarr> I am probably just going to sort out making it work
<racarr> in the Communicator
<racarr> with no name in the authorizer interface
<racarr> and nothing in the .proto
<racarr> if the shell wants to do something with the pid later
<racarr> they already know the assosciation of pid/desktop
<racarr> so they can attach it to whatever session object they have
<robert_ancell> sounds good
<RAOF> Of course, unless the client fork()s ;)
<duflu> Whee, copper wires
<RAOF> Oh, hi. Mesa refactoring may well be what's causing the mesa crash.
<tvoss> good morning :)
<RAOF> Yo!
<RAOF> I have the obvious question!
<tvoss> RAOF, shoot :)
<tvoss> didrocks, what is the best way to pull in the new gmock package to saucy to start working on mp's for all reverse-build-depends?
<didrocks> tvoss: right now, using the link I sent you is the best way
<tvoss> didrocks, mind pinging me the link again? :)
<didrocks> tvoss: http://people.canonical.com/~doko/tmp/
<tvoss> didrocks, thx
<didrocks> tvoss: you can get dget google-mock_1.6.0-1ubuntu1.dsc
<didrocks> (the source is available upstream or in the debian PTS)
<tvoss> didrocks, there is a tar.gz. in there, too
<didrocks> tvoss: the tar.gz is the debian diff
<tvoss> didrocks, ah
<didrocks> tvoss: FYI, rlvm is fine and rebuild using the source
<tvoss> didrocks, ack, will look into libusermetrics. Did you do any particular magic or just added an add_subdirectory(..)?
<didrocks> tvoss: we don't ship any CMakeLists.txt with gmock, isn't it?
<didrocks> add_subdirectory won't work then?
<tvoss> didrocks, how do we do it then?
<didrocks> tvoss: I'm thinking :)
<tvoss> didrocks, also another look at https://code.launchpad.net/~thomas-voss/platform-api/add-package-config/+merge/168642
<tvoss> would be very much appreciated
<didrocks> tvoss: will do, do I need to backlog all the comments?
<tvoss> didrocks, I think rsalveti had some good comments and the diff should be cleaner now
<didrocks> ok
<didrocks> tvoss: it seems we'll need to build it ourselves
<didrocks> like:
<didrocks> g++ -I/usr/src/gmock -c /usr/src/gmock/src/gmock-all.cc
<didrocks> g++ -I/usr/src/gtest -c /usr/src/gtest/src/gtest-all.cc
<didrocks> ar -rv libgmock.a gmock-all.o gtest-all.o
<didrocks> and then link against it
<tvoss> didrocks, can we add the CMakeLists.txt as a distro patch?
<didrocks> tvoss: sure, I think that will help more than just us :)
<didrocks> tvoss: I was looking if we can reuse something like that from upstream source first, didn't find anything reusable
<didrocks> but please double check
<tvoss> didrocks, looking at trunk here, a CMakeLists.txt is part of both trunk and the zip from googlemock
<tvoss> https://code.google.com/p/googlemock/source/browse/#svn%2Ftrunk
<didrocks> tvoss: yeah, I think a substract of it (as it redefines the project name and so on) can be useful
<didrocks> like, we don't want I guess:
<didrocks> project(gmock CXX C)
<didrocks> cmake_minimum_required(VERSION 2.6.2)
<didrocks> right?
<tvoss> didrocks, oh, those should be perfectly fine, cmake is clever enough i nthat case :)
<tvoss> didrocks, we have used the CMakeLists.txt within mir from its in-tree gmock version for some time now
<didrocks> tvoss: ah, my knowledge is not so advanced :) but how do you deal with the prefix? (as it's ${sourcedir}/src instead of ${prefix}/src?
<didrocks> you just hack around sourcedir == prefix?
<tvoss> didrocks, it should "just work"(tm). In mir, we only did an add_subdirectory(3rd_party/gmock gmock) and that pulled in all of the targets
<tvoss> didrocks, that being said, as projects are reasoning in terms of targets, things are easy :)
<tvoss> robert_ancell, ping
<tvoss> robert_ancell, hey, I was looking for a branch you pasted here recently that addresses a vt issue
 * tvoss waves hands
<didrocks> tvoss: we'll see, I'm a little bit afraid with gtests
<didrocks> tvoss: as you copied that in build tree and you end up with the copy
<didrocks> it seems it's looking for ../gtests
<didrocks> so it could work
<didrocks> and google-mock deps on libgtest-dev
<tvoss> didrocks, I'm confused now :) gmock usually has got its own gtest :)
<didrocks> tvoss: not on the installed version
<tvoss> didrocks, I see, so time to adjust the cmakelists.txt for gmock to pull in /usr/src/gtest :)
<didrocks> tvoss: done that, I'm just fighting with add_subdirectory for now :p
<didrocks> tvoss: I have no idea where the .a will ends up TBH ;)
<tvoss> didrocks, you should not need the .a, the target should be fine
<didrocks> tvoss: it will build a .a at some points, no?
<didrocks> or just the .o? where we invoke the target?
<didrocks> When specifying an out-of-tree source a
<didrocks>   binary directory must be explicitly specified.
<tvoss> didrocks, yeah, just call it gmock or gtest respectively
<tvoss> didrocks, then cmake takes care of the rest
<didrocks> yeah, let's see how it goes :)
<didrocks> you think it will magically find them? ;)
<tvoss> didrocks, I'm pretty sure ;)
<didrocks> at least, it doesn't complain :p
 * tvoss believes in cmake ;)
<didrocks> lets see if Mir builds
<didrocks> how come I've a backlog of 3 hours so early in the morning?
<tvoss> didrocks, don't ask, just do ;)
<didrocks> tvoss: well, that's my life :p
 * tvoss reads the slashdot article on the BART strike and the conclusion that software engineers should have a union, too
<didrocks> ah
<didrocks> build failure
 * didrocks tests with internal gmock to check if the diff is from this
<tvoss> didrocks, mind pastebinning the build failure?
<didrocks> tvoss: http://paste.ubuntu.com/5842593/
<didrocks> hum
<didrocks> thanks build-area
<didrocks> I've relaunched the vanilla build, hence the truncated log
<tvoss> didrocks, a little less french would help me;)
<didrocks> ahah ;)
<didrocks> tvoss: ok, will run the next one with LANG=C :p
<tvoss> \o/
 * tvoss needs coffee
<didrocks> I kept the warning downgrade though, but maybe adding the subdirectory had some side-effects
 * didrocks as well while mir is building
<smspillaz> tvoss: ah frick, BART strike?
<smspillaz> tvoss: this isn't good, I'm going there tomorrow and kinda need to get around...
<tvoss> smspillaz, http://tech.slashdot.org/story/13/07/03/2042253/bart-strike-provides-stark-contrast-to-techs-non-union-world
<didrocks> tvoss: http://paste.ubuntu.com/5842602/
<smspillaz> tvoss: hmm, as much as I support unions, I hope it'll be over soon (http://www.mercurynews.com/breaking-news/ci_23581424/full-speed-ahead-day-2-bart-strike). My flight arrives at around 2230h
<didrocks> -Werror=unused-local-typedefs
<tvoss> didrocks, we had some specific parts for handling that in Mir
<tvoss> didrocks, let me find them
<alf> RAOF: Hi! In the display-configuration-change-handler MP, I intoduced the VideoDevices interface and a UdevVideoDevices implementation for it. It is used only in Display right now, to register an event handler, but I was thinking that it could also be extended for device discovery in Platform (i.e. replace the direct udev calls we have there). This would allow easier mocking/unit-testing.
<didrocks> tvoss: # Don't treat warnings as errors in 3rd_party/{gmock}
<didrocks> string (REPLACE " -Werror " " " CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
<didrocks> I guess
<didrocks> but the add_subdirectory is just after that one
<tvoss> didrocks, that might well be the case, and we restore the flags right after the add_subdirectory
<alf> RAOF: The UdevVideoDevices implementation uses ad-hoc udev wrappers that should probably be replaced by your c++ udev classes.
<didrocks> tvoss: yep, the change are quite simple (for now, I'll clean that with prefix): http://paste.ubuntu.com/5842607/
<didrocks> tvoss: but I don't understand what changes compared to your internal gmock though
<tvoss> didrocks, I do see errors when using gmock, mind building with -j1?
<didrocks> tvoss: good idea, it will be clearer
<RAOF> alf: I'll have a look.
<alf> RAOF: (note: the MP was merged)
<RAOF> alf: We'll need something more generic later, because we'll also need to handle input hotplug & discovery, which I don't *think* the code currently does
<alf> RAOF: VideoDevices is just the interface the graphics subsystem cares about, which will be implemented with udev. I guess the input subsystem can have a similar interface, again implemented with udev
<RAOF>  Yeah
<didrocks> tvoss: ah, more interesting: http://paste.ubuntu.com/5842616/
<didrocks> -Werror=unused-local-typedefs
<didrocks> so those files including gmock.h, it seems they get the gmock warning
<didrocks> but I don't see the difference with the inline version, it should first build gmock
<didrocks> with -Werror disable
<didrocks> and then, just link to the .o files?
<RAOF> But it can't just link to the .o files? It needs to parse the headers anyway.
<dholbach> good morning
<didrocks> RAOF: I would think he would do that
<didrocks> hey dholbach
<didrocks> they are built again: gmock-all.cc.o
<dholbach> hey didrocks
<tvoss> didrocks, the typedef is in the header, so if we reenable -Werror, we bail out: https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1185719/+merge/167474
<RAOF> RAOF: Looks good. I'll udev-wrapper-ify it and fold in the device probing?
<RAOF> alf ^^^
<tvoss> lol
<alf> RAOF: sure
<didrocks> tvoss: but why don't we have that with the internal gmock then?
<tvoss> didrocks, it might well be that the typedefs changed, let me check
<didrocks> ah, you are not using 1.6?
<tvoss> didrocks, checking ...
 * RAOF wonders why his laptop has suddenly hit the thermal trip point.
<tvoss> didrocks, mir's internal gmock version has the typedefs only in include/gmock/gmock-generated-function-mockers.h
<tvoss> didrocks, and they are not even defined, as the compiler bails out anyways when that point is reached
<didrocks> tvoss: yeah, you're right
<didrocks> hum
<didrocks> tvoss: I'm not fan or disabling -Werror for everything under tests, but do you have any other idea?
<tvoss> didrocks, we could explicitly set -Wno-unused-local-typedefs
<tvoss> didrocks, to be a bit more subtle
<RAOF> Or -Wno-error=unused-local-typedefs
<didrocks> (basically, I guess everything in include/test/mir_test/)
<didrocks> or globally?
<didrocks> it still enables to cleanswap if needed for the rest of the case
<didrocks> code*
<tvoss> didrocks, I would do it for everything under tests/
<tvoss> RAOF, ^, thoughts?
<didrocks> (I agree)
<RAOF> I'd push -Wno-error=unused-local-typedefs for everything under tests
<didrocks> ok, we all agree then
<tvoss> \o/
 * didrocks does and rebuild :)
 * RAOF would also like to push -Wno-error=deprecated for everything under tests, too, so that they build on recent clang
 * tvoss grabs another coffee
<didrocks> RAOF: can add :)
 * didrocks still at first mug
<RAOF> Although glib might be fixed before g++ hits that particular snag.
<RAOF> And while we're at it, why not merge https://code.launchpad.net/~raof/mir/fix-clanger/+merge/172956 so *everything* works when built with clang!
<tvoss> didrocks, still building?
<didrocks> tvoss: still building, so hope :)
 * tvoss crosses fingers
<didrocks> tvoss: /tmp/googlemockification/build-area/mir-0.0.6/obj-x86_64-linux-gnu/bin/unit-tests: symbol lookup error: /tmp/googlemockification/build-area/mir-0.0.6/obj-x86_64-linux-gnu/bin/unit-tests: undefined symbol: eglCreateImageKHR
<tvoss> RAOF, ^
<RAOF> Not linking to libEGL
<RAOF> Actually, that might be our bug. eglCreateImageKHR isn't actually a part of the EGL exported symbols, is it?
<tvoss> RAOF, I wouldn't think so
<alf> tvoss: didrocks: Some time ago we updated the internal gmock version to svn r432 to avoid all these problems... now we are essentially reverting to 1.6...
<tvoss> alf, ah, thanks for the hint
<tvoss> didrocks, I thought we would pull in the latest and greatest from tip?
<didrocks> tvoss: can you point me again to the patches to add?
 * didrocks cleans to be override meanwhile
<didrocks> overridable
<duflu> robert_ancell: Sorry, Telstra started playing with my phone line this morning and just finished (without fixing anything)
<tvoss> didrocks, r437 is latest according to googlemock svn. How do I generate patches against the currently released version? or is a zipped svn-export fine for you?
<alf> didrocks: can we just pull in the latest trunk for gmock? gmock 1.6.0 was published over 2 years ago, and a lot has changed (include proper c++11 and recent g++/clang support) since then
<didrocks> tvoss: no, we need to manually cherry-pick patches (or better, just the patch we need)
<didrocks> for latest update, we can as well just create a tarball
<didrocks> and have google-mock 1.6+svn<rev>
<tvoss> didrocks, okay, so that is a +1 on svn-export + tar gz?
<didrocks> tvoss: see when I told you that maintaining components are not light :)
<didrocks> yep
 * didrocks fights with cmake meanwhile
<tvoss> didrocks, so I can just send you the tar.gz now?
<tvoss> didrocks, sent
<didrocks> tvoss: thanks, will update shortly
<didrocks> ok, cmakeries done
<didrocks> now back to gmock
<tvoss> didrocks, sent you the tar.gz
<didrocks> ok, patches don't apply now, let's see
<robert_ancell> duflu, how nice of them!
<alf> alan_g: Yesterday, IIRC, you mentioned something about a crash while running unit-tests. See if https://code.launchpad.net/~afrantzis/mir/fix-mock-drmgetbusid-race/+merge/172964 fixes it for you.
<tvoss> didrocks, still building mir? :)
<didrocks> tvoss: I'm fixing google-mock first :p
<didrocks> tvoss: the snapshot doesn't build as is
<tvoss> didrocks, ?
<didrocks> tvoss: needing to reapply patches and so onâ¦
 * didrocks wonders how seriously doko tested his upgradeâ¦
<didrocks> tvoss: ok, rebuilding Mir now
<tvoss> didrocks, awesome
<alan_g> alf: sure (https://bugs.launchpad.net/mir/+bug/1197408)
<ubot5`> Launchpad bug 1197408 in Mir "unit-tests core unless LD_PRELOAD=libumockdev-preload.so is set" [Medium,New]
<duflu> RAOF: Any luck with the GL crashes?
<didrocks> tvoss: waow, latest snapshot has a lot of failures
<tvoss> didrocks, ?
<didrocks> tvoss: http://paste.ubuntu.com/5842794/
<didrocks> should be a missing } somewhere
<RAOF> duflu: Got a very plausible cause, not yet fixed.
<duflu> Cool. That's something
 * RAOF updates the bug.
<tvoss> didrocks, might be one of the distro patches
<tvoss> a simple test executable builds fine locally
<didrocks> tvoss: no, the only one I kept is a python path
<didrocks> tvoss: want the deb?
<tvoss> didrocks, ah, I know: I'm pretty sure the GTEST_EXCLUSIVE_LOCK_REQUIRED_ is not defined by the gtest version in the archive
<didrocks> tvoss: ah, that's a nice point and will explain with gmock is working :)
<didrocks> why*
<didrocks> as it's using its internal gtests
<tvoss> didrocks, you sure?
<didrocks> tvoss: from CMake, yeah, gmock source is using its internal one, but once installed, it's using the system one
<didrocks> so what you are telling makes sense
<alf> alan_g: it's a different problem then (not related to LD_PRELOAD missing or not)
<alan_g> alf: Maybe it is the same problem(!) - as I've just tried it an see no crash
<alan_g> *and
<robert_ancell> alf, ah, the crash is because KMSOutput::size() assumes there is at least one mode - is it worth making Mir handle there not being a mode (i.e. is that possible?) or should I mock the mode (which is what causes the crtc error)
<alf> alan_g: It's a race condition, so perhaps it happened to you when you tried without LD_PRELOAD, and didn't occur when trying with LD_PRELOAD, by chance (or by LD_PRELOAD changin some timings)
<alf> robert_ancell: I would say just mock the mode for now, the  KMSOutput requires a bit more thought
<alf> robert_ancell: the "KMSOutput change"
<didrocks> tvoss: I'm a little bit uneasy with updating gtests
<didrocks> seeing the numbers of build-deps
<tvoss> didrocks, looking
<tvoss> didrocks, can we offer a testing package?
<didrocks> tvoss: what do you mean?
<didrocks> tvoss: you want the .deb for testing the new google-mock & gtest?
<tvoss> didrocks, pulling in the latest gtest, building a test package, asking people to check?
<didrocks> tvoss: who are people? :)
<tvoss> didrocks, the people responsible for the reverse-build-dependencies
<didrocks> tvoss: we don't have responsible maintainers in ubuntu
<didrocks> so I doubt anyone will check the reverse deps
<didrocks> and for indicator-* & co, it's us, so same people having to do all the work :p
<tvoss> didrocks, okay, so what's a good way forward here?
<didrocks> tvoss: TBH, I don't know, maybe just identifying the patches you need from 1.6 to latest gmock
<didrocks> to build with Mir
<didrocks> and only include those
<tvoss> didrocks, hmmm, that does not solve the problem as I'm pretty sure that we will need said macro in gtest
<tvoss> didrocks, why do we install gmock btw?
<tvoss> didrocks, why don't we just put it in /usr/src?
<didrocks> what do you mean?
<didrocks> that's what we are doing
<didrocks> maybe we can ship gtests in gmock
<didrocks> so that it's going to use that synced version
<tvoss> didrocks, we can, gtest is contained within gmock
<didrocks> (it's a bad hack, but still better than nothing)
<didrocks> yep
<didrocks> that's why I'm proposing that :)
<tvoss> didrocks, why can't we do both? gtest and gmock in /usr/src?
<didrocks> tvoss: gtest is also in /usr/src/
<didrocks> it's just out of sync with gmock if we push the latest I guess
<tvoss> didrocks, I'm thinking about the situation where someone only wants to use gtest
<didrocks> not following you, we do have gtests as well
<didrocks> separated
<didrocks> this is the whole issue
<didrocks> to be able to upgrade that one, but seeing the number of build-depsâ¦
<tvoss> okay, so my proposal is: let's have /usr/src/gtest _and_ /usr/src/gmock, with gmock containing a gtest version, too
<didrocks> tvoss: that's exactly what I'm proposing :)
<tvoss> didrocks, +1 then
<tvoss> didrocks, which ties gmock to its internal gtest versoin, all is good :)
<didrocks> tvoss: I wonder what's happening with all those gtest includes though
<tvoss> didrocks, good question
<didrocks> I think we need to hack around the paths so that everytime we use gmock, we check for internal gtest
<didrocks> if not using gmock, use the system gtest
<tvoss> didrocks, I would rather say: if you use gmock, don't use gtest. Is a policy sufficient here?
<didrocks> tvoss: hum, you are using both in mir :)
<didrocks> same with unity and so on
<didrocks> $ grep -r gtest tests/ | grep include | wc -l
<didrocks> 163
<didrocks> in Mir
<tvoss> didrocks, using might be the wrong term: if you do add_subdirectory(/usr/src/gmock) don't do add_subdirectory(/usr/src/gtest)
<didrocks> tvoss: ah, right, agreed
<didrocks> tvoss: I hope that all build-deps for google-mock will still build with newer gtest
<didrocks> tvoss: ok, so at least, not the same error
<didrocks> tvoss: but back to /tmp/googlemockification/build-area/mir-0.0.6/obj-x86_64-linux-gnu/bin/unit-tests: symbol lookup error: /tmp/googlemockification/build-area/mir-0.0.6/obj-x86_64-linux-gnu/bin/unit-tests: undefined symbol: eglCreateImageKHR
<didrocks> (so it seems 1.6 was enough? :p)
<tvoss> alf, ^?
<alf> didrocks: @1.6 was enough, our experience with 1.6 was that we needed to disable warnings/errors for it to build properly with our code, svn version could work mostly ok without disabling stuff
<alf> tvoss: didrocks: @eglCreateImageKHR, I have never seen this error before... we are not using eglCreateImageKHR directly, we are getting it as an EGL extension function pointer
<didrocks> tvoss: alf: if we can keep 1.6 for now, I would be in favor of that
<alf> didrocks: 1.6 is ancient... the policy of prefering released versions doesn't work well with gmock and other projects that take so long to publish.
<didrocks> alf: yeah, but did you follow the discussion about gtests?
<didrocks> alf: the only way for us would be to ack around and ship gtests with gmock, I'm fine with that, but at least, if it fixes anything and if upstream can help fixing the new issues in all build-deps
<didrocks> alf: however, I do confirm that we don't need to hack around -Werror
<didrocks> tvoss: any idea of this eglCreateImageKHR?
<didrocks> I've ported location-service meanwhile
<tvoss> didrocks, mind pastebining the build log?
<tvoss> didrocks, thx for porting location service
<didrocks> tvoss: libusermetrics failed though :/
<tvoss> didrocks, why is that?
<didrocks> tvoss: build logs for Mir: http://paste.ubuntu.com/5843027/
<didrocks> tvoss: libusermetrics: http://paste.ubuntu.com/5843029/
<didrocks> we can think of some changes in gmock and gtests
<didrocks> but all those undefined reference make me think the issue is somewhere else
<tvoss> didrocks, it does not link against gtest
<didrocks> tvoss: yeah, just came to the same conclusion
<didrocks> tvoss: ok, libusermetrics fixed
<tvoss> alf, ping
<tvoss> didrocks, I think I have the issue with the missing symbol
<didrocks> ah?
<tvoss> tests/unit-tests/graphics/test_graphics_platform.cpp returns eglCreateImageKHR
<alf> tvoss: pong
<tvoss> alf, in tests/unit-tests/graphics/test_graphics_platform.cpp, we have got a free eglCreateImageKHR
<tvoss> that triggers the missing symbol issue
<alf> tvoss: ok, checking
<alf> tvoss: ok, easy fix, will push shortly
<tvoss> didrocks, in test_graphics_platform.cpp, lines 72 - 77
<tvoss> alf, ^, removing those lines should fix the issue
<alf> tvoss: yes, the right version of this code is already in MockEGL
<tvoss> alf, yup :)
<tvoss> didrocks, ^
<alf> tvoss: so do you want me to submit the fix or do it another way?
<tvoss> alf, might be a good idea if didrocks just adds it to his changes
<alf> tvoss: fine with me
<alf> didrocks: actually lines 70-77, we don't need the typedef anymore
<didrocks> ok
<didrocks> let me try that
<didrocks> tvoss: some segfault in tests, but it seems to be libGLESv2.so related: http://paste.ubuntu.com/5843104/
<tvoss> didrocks, mind running the tests manually in the build directory with ctest -V?
<didrocks> tvoss: here we go: http://paste.ubuntu.com/5843116/
<tvoss> didrocks, okay, that did not give me the information I was after :)
<tvoss> didrocks, gdb to the rescue then: in the build-dir: gdb bin/unit-tests
<didrocks> tvoss: sorry, I'm cleaning location-service meanwhile :)
<didrocks> tvoss: http://paste.ubuntu.com/5843140/
<tvoss> alf, this looks like soemthing for you: http://paste.ubuntu.com/5843140/
<didrocks> tvoss: mind having a quick look? https://code.launchpad.net/~didrocks/location-service/clean-location-service-pkg/+merge/173003
<alf> didrocks: is the packaging being run on the phone?
<didrocks> alf: no, I'm on my desktop here
<didrocks> (no pbuilder, just saucy)
<alf> didrocks: tvoss: because on error message looks strange "linker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found"
<hikiko> I have a problem with mir trunk
<hikiko> I run it (intel i9650)
<didrocks> alf: yep, I agree
<hikiko> and I can't switch to tty
<hikiko> even if I kill mir
<hikiko> everything is frozen
<hikiko> and I have to reboot
<hikiko> does anyone has the problem?
<hikiko> also I see something different in my laptop screen and in my external monitor
<alf> hikiko: is that with pure mir trunk, or does it contain any other changes?
<hikiko> pure mir trunk alan_g
<hikiko> alf sorry
<hikiko> I first had the problem in my branch after merge to trunk but then I compiled trunk itself (fresh clean download and compile)
<hikiko> and got the same error
<alf> hikiko: ok, let me try... this usually means that something crashes in mir and leaves the VT in a strange state not being able to VT switch
<hikiko> thank you alf
<alf> hikiko: does it happen with e.g. render_surfaces ?
<hikiko> no alf I only start the server
<hikiko> nothing else
<hikiko> mir_demo_server as root
<hikiko> it crashes after a few seconds from what I see when I ssh
<hikiko> so it's probably the crash that causes that
<alf> hikiko: I can't recreate this locally, everything works fine for me. Can you get a backtrace?
<hikiko> let me try
<hikiko> crashed but I can't get the bt from gdb I can't switch vt... I ll try to start gdb inside screen in the next reboot and get its output with ssh
<didrocks> seb128: seems tvoss isn't around, do you mind acking https://code.launchpad.net/~didrocks/location-service/clean-location-service-pkg/+merge/173003 please?
<didrocks> alf: ok, google-mock set into the pbuilder env, now running mir inside that build env
<seb128> didrocks, why do you ned the --fail-missing on the dh line if you override dh_install and have it there already?
<didrocks> seb128: I added first to the dh line, then added the override
<didrocks> seb128: so had to repeat it
<didrocks> but if one day we remove the override, we'll still have --fail-missing
<seb128> didrocks, k, wfm, acked
<didrocks> (here, the override was removed and fail-missing then skipped)
<didrocks> and I noticed all those beautiful docs not installed!
<didrocks> thanks seb128 :)
<seb128> didrocks, you need to change the MR status, I'm not in the right team
<didrocks> seb128: thanks! done
<seb128> yw ;-)
 * didrocks crosses fingers that mir build will pass
<didrocks> then, on the list for updating google-mock "only" unity and nux
<didrocks> I'll let that to bregma's team I guess :p
<didrocks> tvoss: alf: all tests pass for Mir in a pbuilder
<didrocks> so I think I've something local triggering that
 * didrocks will do a MP
<didrocks> alf: tvoss: (failing right now because of google-mock version of course): https://code.launchpad.net/~didrocks/mir/use-system-googlemock/+merge/173008
<tvoss> didrocks, awesome
<alf> tvoss: didrocks: just remember that to support g++-4.7 we need another fix that is not upstream yet, do we care?
<alf> tvoss: didrocks: (fix in gmock)
<didrocks> alf: oh, it's needed even with latest snapshot?
<alf> didrocks: yes
<didrocks> (as everything built fineâ¦)
<alf> didrocks: everything works with g++-4.8
<didrocks> alf: do you mind pastebining it right now? I should have it in my logs but will help if you have it handy
<alf> didrocks: http://paste.ubuntu.com/5843334/ it's rev 750.1.5 in trunk
<didrocks> alf: ok, getting it
<didrocks> alf: your patch results in http://paste.ubuntu.com/5843397/
<alf> didrocks: it's not compiled in C++11 mode :/
<didrocks> alf: any hint for that?
<alf> didrocks: the problem is that we can't provide c++11 mode headers, since not all gmock users want to use c++11 :/
<didrocks> alf: yep
<didrocks> alf: so removing the patch for now I guess
<alf> didrocks: unless you are ok with conditional compilation "if c++11" ...
<alf> didrocks: I mean defines in the header
<tvoss> didrocks, alf why don't we add a NOEXCEPT macro?
<didrocks> alf: if you provide a patch for it, I'm fine, but you have to repatch all build-deps for it (if they intented to have if c++11)
<arsson> Is there any livecd with xmir working on it?
<tvoss> arsson, not yet, but some people have been asking for it
<didrocks> tvoss: ok, any idea when unity and nux will be ported? then, we can flip the switch for all projects
<alf> didrocks: no, that's only in the gmock headers, like the NOEXCEPT macro tvoss mentioned
<tvoss> alf, +1
<didrocks> alf: that's fine with me, just send the patch and I'll integrate it
<didrocks> tvoss: I can provide the binaries in a ppa if needed
<tvoss> didrocks, for the new gmock?
<tvoss> didrocks, I was more or less thinking about when I should review your mp on Mir :)
<didrocks> tvoss: it's pushed, see the hilight 50 minutes ago
<didrocks> didrocks | alf: tvoss: (failing right now because of google-mock version of course):
<didrocks>          | https://code.launchpad.net/~didrocks/mir/use-system-googlemock/+merge/173008
<didrocks> tvoss: so yeah, need unity and nux for new gmock
<didrocks> I've handled the rest I guess
<tvoss> didrocks, ack
<tvoss> alan_g|lunch, did the enable_test option land, yet?
<didrocks> tvoss: I still don't have any answer on who will do unity/nux :p
<didrocks> alf: give me the patch with #define once you have it, I'll push gmock then to a ppa
<tvoss> didrocks, can look into it
<didrocks> tvoss: I have a start for the unity branch if you want, but I really need to switch to unity8 daily builds
<didrocks> otherwise Saviq will kill me :p
<tvoss> didrocks, fair. The ppa with the new gmock version would be great though
<didrocks> tvoss: let me update without alf's patch for now
<tvoss> didrocks, ack
<alan_g> tvoss: not yet - I need some cmake help with it. https://code.launchpad.net/~alan-griffiths/mir/fix-1196987/+merge/172798/comments/386707
<didrocks> tvoss: unity branch is at lp:~didrocks/unity/new-gmock and new gmock without alf's patch is building at https://launchpad.net/~didrocks/+archive/ppa
<tvoss> didrocks, ack
<tvoss> didrocks, hmmm, seems like we need to add pkg-config as a build-dep
<tvoss> didrocks, does that make sense?
<tvoss> alan_g, can you try to add pkg-config to the build-deps in debian/control?
<alan_g> tvoss: yes (after a context switch)
<alan_g> tvoss: I don't think that makes sense - we're talking cross build here (and that uses tools/setup-partial-armhf-chroot.sh to set things up. Not debian/control)
<alf> didrocks: tvoss: The updated fix http://paste.ubuntu.com/5843511/
<alf> didrocks: let me prefix the macro to avoid collisions...
<alan_g> tvoss: doesn't work (nor does adding it to tools/setup-partial-armhf-chroot.sh)
<alf> didrocks: http://paste.ubuntu.com/5843518/
<tvoss> alan_g, okay ... I was confused
<alan_g> tvoss: AFAICS the problem is that pkg_check_modules() checks the host, not the chroot
<tvoss> alan_g, as far as I can tell, there is a package list in the partial chroot setup
<alan_g> tvoss: yeah, but if I install libmockdev in the host, then pkg_check_modules() is happy in the chroot, and if I remove it from the host pkg_check_modules() fails in the chroot.
 * alan_g is confused
<alan_g> Hence asking for help before getting bogged down in learning the details
<tvoss> alan_g, my best guess would be that you need to add it to PACKAGES_ALL
<tvoss> alan_g, any luck with that?
<alan_g> tvoss: there's no libumockdev-dev..._all.deb, so it doesn't work - but I'm not following your thinking
<tvoss> alan_g, there is a set of packages that gets installed in the chroot in the setup script
<tvoss> alan_g, umock dev is not mentioned there
<alan_g> yes, and I've put libumockdev-dev into the PACKAGES_ARMHF list
<alan_g> That (sort of) works, as it gets installed
<alan_g> But pkg_check_modules() doesn't find it
<alan_g> pkg_check_modules() finds the one in the host system regardless of the chroot
<tvoss> alan_g, what is the path to the chroot?
<alan_g> /home/alan/display_server/mir/partial-armhf-chroot
<tvoss> alan_g, might be that we need to adjust PKG_CONFIG_PATH
 * ogra_ hopes that weird hacking you guys do above isnt supposed to be uploaded anywheer 
<alan_g> tvoss: that does it. \o/ (Now looking for the best place to set it)
<didrocks> tvoss: I don't think we need pkg-config, we don't use it in my branch
<tvoss> ogra_, it is :)
<tvoss> alan_g, ack
<ogra_> tvoss, ugh
<tvoss> didrocks, I need to run some errands, will look at nux and unity when back
<tvoss> ogra_, not entirely sure what hackery you mean?
<ogra_> tvoss, cross building in the archive ?
<ogra_> or is that only for local builds
<tvoss> ogra_, not in the archive, on jenkins :)
<tvoss> ogra_, and for local builds
<ogra_> phew :)
<tvoss> ogra_, no worries, how could we ever dare to propose such weird concpets?
<ogra_> i know people are desparate to get faster builds ... the chatter above sounded scary :)
 * ogra_ LOLs 
<ogra_> https://plus.google.com/117323436464400045874/posts/Zu8PkqTmnEN
<ogra_> so he is testing Mir ... but all comments are about the wallpaper
<tvoss> didrocks, would be great if we could sync up on package maintainers tomorrow
<tvoss> ogra_, have seen ;)
<tvoss> ogra_, I was tempted to write: that sunny spot in the middle, that's (x)mir land ;)
<ogra_> LOl
<didrocks> tvoss: sorry, not sure to understand? you mean package ownership?
<tvoss> didrocks, yup
<didrocks> sure
<katie> racarr, hello
<alan_g> katie: FWIW it appears to be a USA holiday
<katie> alan_g, of course!
<katie> alan_g, thanks for reminding me :)
<ricmm> hey guys
<robert_ancell> thomi, any luck with those infrastructure issues?
<robert_ancell> "file:///usr/share/unity8/GreeterShell.qml:18:1: module "Ubuntu.Application" is not installed
<robert_ancell>      import Ubuntu.Application 0.1 "
<thomi> robert_ancell: for the mir_stress stuff? Yes, the solution is to ditch UTAH in favour of Otto to provision the machine. I feel like I"m getting closer
<ricmm> so guys, mir is broken on armhf due to a test
<ricmm> kinda need to to build so I can update mir in our image
<ricmm> https://code.launchpad.net/~ricmm/mir/fix-android-registrar-test/+merge/173106
<ricmm> if a merciful soul could take care of that review, I would appreciate it
<ricmm> builds fine locally on my armhf devices
<robert_ancell> ricmm, oh, the compiler fails on that?
<ricmm> yea, because of unused result
<ricmm> so might as well test the result
<robert_ancell> yep
<ricmm> that test only builds on armhf
<robert_ancell> approved
<ricmm> thanks
<thomi> RAOF: ping?
<RAOF> thomi: Pong.
<thomi> RAOF: I'm fairly sure something in the mir-team/staging PPA is preventing unity 7 from starting, I get:
<thomi> compiz: ../../../../../src/mesa/main/hash.c:164: _mesa_HashLookup_unlocked: Assertion `key' failed.
<thomi> I wonder if you have any ideas what that could be?
<RAOF> Well, that sounds suspiciously like mesa :)
<RAOF> I'm currently updating, so I'll be able to reproduce for you soon, I guess.
<thomi> RAOF: thanks, I need to go get some lunch soon, so I'll bug you when I get back I suppose :)
#ubuntu-mir 2013-07-05
<thomi> RAOF: any news?
<thomi> or, too soon? :)
<RAOF> thomi: I can't reproduce locally
<thomi> hmmmmm
<thomi> that's annoying
<RAOF> You're on intel, right?
<RAOF> What package versions do you have?
<thomi> RAOF: let me see...
<thomi> ugh, have to re-add the PPA, since I wiped the changes last time, one moment
 * RAOF also has a sleeping baby in his arms, so will be a bit slow
<thomi> RAOF: sorry for the delay - which packagesa re you interested in?
<RAOF> libegl1-mesa, xserver-xorg-core, xserver-xorg-video-intel
<thomi> libegl1-mesa: 9.2~git20130628.g6b676e6-0ubunt
<thomi> xserver-xorg-core: 2:1.13.3-0ubuntu13
<thomi> xserver-xorg-video-intel: 2:2.21.9-0ubuntu2
<thomi> looks like that first version was truncated a bit :-/
 * thomi notes with annoyance that mir_demo_server has moved back to /usr/bin
 * thomi wonders if mir_stress will move about under him as well
<RAOF> thomi: Hm. You're on raring, then?
<thomi> uhhh... no, I shouldn't be
<thomi> should be saucy, but it's an lxc container, so maybe something is broken
<thomi> RAOF: what makes you think raring?
<robert_ancell> thomi, Is the client API file descriptor leaking mentioned in mir-stress/src/client.cpp still valid?
<RAOF> Because  *** 2:1.14.1-0ubuntu0.6+xmir1 0
<RAOF>         500 http://ppa.launchpad.net/mir-team/staging/ubuntu/ saucy/main amd64 Packages
<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
<thomi> robert_ancell: but I think that issue is still open?
<robert_ancell> thomi, was there a bug about this?
 * thomi searches
<thomi> there was certainly a lot of discussion :)
<thomi> robert_ancell: problem description is here: https://bugs.launchpad.net/mir/+bug/1198022
<ubot5> Launchpad bug 1198022 in Mir "mir client API leaks FD without an explicit close, which is unexpected" [Undecided,New]
<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
<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
<duflu> thomi: Like --track-fds=yes (default no)
<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 :)
<thomi> I'll look into changing the valgrind options and seeing if it catches anything new
<duflu> thomi: I mean, I know we have tests that should trigger leaks (if there are any)
<duflu> We have full client lifecycle tests...
<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
<robert_ancell> thomi, what were you using to show there were open fds?
<duflu> Hah. I've never seen a 50000 line MP before
<thomi> robert_ancell: I discovered it when I hit the open FD limit in the stress test
<thomi> robert_ancell: but valgrind with --track-fds should show it as well
<robert_ancell> thomi, yes, I reproduced it now
<thomi> cool
<duflu> robert_ancell: A simpler way to track files is: ls -l /proc/$pid/fd/
<robert_ancell> duflu, I've also done that
<robert_ancell> duflu, though valgrind it nice because it tells you where the fd came from
<duflu> valgrind is nice for so many reasons...
<duflu> Though I fear all the errors we are yet to discover using --tool=helgrind
<duflu> ping RAOF
<RAOF> duflu: Pong
<RAOF> Mesa should work now, btw
<duflu> RAOF: gbm_surface_lock_front_buffer ... what's the difference between the "front buffer" being locked and the "new one" returned?
 * RAOF looks
<duflu> Oh...
 * duflu afk briefly
<RAOF> duflu: Ok. So, gbm_surface_lock_front_buffer /
<duflu> ?
<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
<duflu> RAOF: Oh OK thanks. I misinterpreted "A new bo representing the new front buffer is returned"
<duflu> It's not the "new" front buffer. It's the old one
<RAOF> It's the front buffer that you should send to the output.
<duflu> So sounds like the doxygen for gbm is wrong
<duflu> But your explanation makes sense
<duflu> Plus, the code works right now
<RAOF> Heh.
<RAOF> Oh, fun. the drm EGL platform is tripleish-buffered.
<duflu> 3.141592653 buffers?
<RAOF> It'll use up to three buffers.
<darkxst> has anyone got Mir running under vmware?
<darkxst> http://paste.ubuntu.com/5845576/
<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
<darkxst> duflu, is there accellerated driver missing things?
<duflu> RAOF ^ what was missing from VMware's DRI support?
<RAOF> dma-buf support.
<RAOF> With the new, improved, actually-probe-the-hardware gbm backend that should be the only thing blocking VMWare.
<duflu> RAOF: The DMA requirement comes from Mir? Or GBM?
<duflu> It's crazy that we're blocked on DMA-buf support, on a platform where it's all in system memory anyway :)
<RAOF> Comes from Mir.
<RAOF> We technically don't *need* dma-buf support - we could, and did, just use flink - but dma-buf is secure against id guessing.
<RAOF> (And when I say âid guessingâ what I mean is âguessing an integer id that starts at zero and is infrequently incrementedâ)
 * duflu is still coming to grips with the fact that the front buffer is not always what's visible on screen. Too many abstractions...
<TheDrums> Virtualbox does nothing but crash too.
<duflu_> TheDrums: Yeah well VM support of any sort is not implemented yet. So it's not very surprising
<tvoss|errands> RAOF, ping
<RAOF> tvoss: Pong
<tvoss> RAOF, good morning :) how goes?
<RAOF> Well, albeit cold.
<tvoss> RAOF, cold in your part of the world?
<RAOF> Yup.
<RAOF> Cold and bright this morning, then it started raining just after I'd got back from a walk with ZoÃ«.
<tvoss> RAOF, Bryce handed me some vm contacts for graphics drivers.
<RAOF> As in - contacts for VM graphics driver developers?
 * RAOF is not sure how to parse that.
<tvoss> RAOF, yup
 * duflu thinks it's about time Linux stopped talking about CRTC's
<RAOF> tvoss: There's always Prf_Jakob :)
<tvoss> RAOF, +1
 * RAOF wonders how the full-program optimisations of clang's -O4 would influence Mir performance
<tvoss> RAOF, sounds like fun :) I would also be curious to know how AddressSanitizer with gcc 4.8 works
<duflu> RAOF: Anything above O2 is usually a bad idea. It creates much larger code, for little gain
<RAOF> duflu: As far as I can tell, -O4 is (confusingly) not actually above O2 in that sense.
<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
<RAOF> O4 is going to have more opportunity to remove superfluous code, too.
<duflu> RAOF: Per the gcc man page, O2 is the highest level at which optimizations "do not involve a space-speed tradeoff"
<duflu> You use O3 and above only if you're willing to have say a 20% larger binary that runs 2% faster
<RAOF> duflu: But I'm talking about clang, where O4 is âcompile to LLVM bytecode and then do an optimisation pass at link timeâ
<duflu> Oh. Hmm yeah clang might treat the scale differently. Though it previously tried to match gcc
<RAOF> I think it *does* match gcc. gcc doesn't *have* an -O4, though.
<RAOF> I mean - match gcc where the range overlaps.
<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 :)
<RAOF> duflu: Already done âº: https://code.launchpad.net/~raof/mir/fix-clanger/+merge/172956
<duflu> RAOF: Still more to go methinks: https://bugs.launchpad.net/mir/+bugs?field.tag=clang
<RAOF> Eh. clang-3.4 builds a testsuite that works for me.
<duflu> Hmm, I might have to retest
<RAOF> Man, it'll be nice to have a laptop that isn't always thermally throttled.
<duflu> RAOF: which one did you order?
<RAOF> A fully-specced galago.
<RAOF> https://www.system76.com/laptops/model/galu1
 * duflu stops bashing his head against interfaces that don't actually support varying implementations and goes to look at hardware specs
<dholbach> good morning
<duflu> Morning dholbach
<dholbach> hi duflu
<tvoss> ogra_, ping
<tvoss> dholbach, morning :)
<dholbach> hey tvoss
<tvoss> didrocks, what's the default approach in ubuntu for installing documentation? a separate doc package?
<didrocks> tvoss: yeah, see my change in location-service (or was it libusermetrics?)
<tvoss> didrocks, I think location service
<didrocks> tvoss: while I was looking at it: https://code.launchpad.net/~didrocks/location-service/devsuggestsdoc/+merge/173136
<RAOF> Hah. Well, that was short lived. Trunk introduces an ICE with clang-3.4 âº
<alf> RAOF: did you get a chance to take a look at the Mesa pull request?
<RAOF> alf: Let me check now. Have the mir-side chanegs landed?
<alf> RAOF: they are on their way there (waiting for jenking to perform autolanding)
<RAOF> LGTM
<RAOF> Thermally throtttled laptop running the testsuite under valgrind. It's poetry in motion.
<alf> RAOF: mir changes done, feel free to merge mesa changes if everything is ok
 * RAOF hits the button, and refreshes the packaging.
<RAOF> alf: Was https://code.launchpad.net/~raof/mir/udev-wrapper/+merge/173151 the sort of thing you were thinking of?
<alf> RAOF: I haven't looked at the details yet, but the interfaces look good
<alf> RAOF: One thing that caught my eye, do we really need CopyAssign for the wrappers?
<RAOF> alf: They're refcounted, so CopyAssign is cheap, and I'm pretty sure I pass-by-value somewhere in there.
<RAOF> Or, at least, I'm pretty sure UdevContext gets copy-constructed somewhere in there.
<tvoss> didrocks, mind having a look: https://code.launchpad.net/~thomas-voss/platform-api/add-documentation-part-1
<tvoss> ?
<didrocks> tvoss: kind reping on https://code.launchpad.net/~didrocks/location-service/devsuggestsdoc/+merge/173136 if you didn't see it :p
<tvoss> didrocks, sorry :) lost in doc land
<didrocks> tvoss: mind making a MP of your branch? will be easier :)
<tvoss> didrocks, https://code.launchpad.net/~thomas-voss/platform-api/add-documentation-part-1/+merge/173159
<didrocks> tvoss: thanks!
<tvoss> didrocks, ack
 * tvoss grabs coffee
<didrocks> tvoss: it seems to me you have unrelated diff like the addition of libubuntu_platform_hardware_api, and others changes
<didrocks> tvoss: the symbols file is wrong, you didn't follow the doc I guess for C++ symbols :p
<didrocks> and didn't change that by 0replaceme either
<didrocks> conflict in debian/changelog btw ;)
<didrocks> and no -doc package
<tvoss> didrocks, hmmm, you told me I could happily copy over the symbols file :/
<didrocks> tvoss: for non C++ packages right, you ask me in big lines
<didrocks> tvoss: I pointed you to a documentation with step by steps instruction, please read it :p
<didrocks> I didn't write it for my own pleasure :p
<tvoss> didrocks, the platform api is not C++, only parts of its implementation
<didrocks> tvoss: yeah, that's why you have mangled symbols
<tvoss> didrocks, I will hide them from the abi then. That should avoid the need to have them in the symbols file, right?
<didrocks> tvoss: if they shouldn't be exported, yeah, it's better to hide them
<didrocks> and they won't be list in the symbols file
<didrocks> listed*
<ogra_> tvoss, hey
<tvoss> ogra_, salut :)
<alan_g> tvoss: I think you're right - we need pkg-config, which doesn't exist in the cross-compile job
<tvoss> alan_g, weird
<tvoss> didrocks, is pkg-config part of build-essential?
<didrocks> tvoss: no, you need to build-dep on it
<tvoss> didrocks, cool, thx
<didrocks> yw ;)
<didrocks> (I tend to put it in the top, next to eventual gcc, just after debhelper/cmake)
 * alan_g doesn't understand - that's https://code.launchpad.net/~alan-griffiths/mir/fix-1196987/+merge/172798 line 66
<alan_g> but the cross-compile does thins in mysterious (and fragile) ways
<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
<didrocks> alan_g: is pkgconfig in the package build-deps?
<alan_g> didrocks: that's what I hope diff line 66 does
<didrocks> as I told, it's not part of build-essentials
<didrocks> line 66? I see 66-  message(STATUS "Tests are run with real graphics.")
<alan_g> Opps, looking at old webpage
<didrocks> :)
<didrocks> alan_g: oh, the job is not using the package build-deps
<didrocks> what's this job? it's ackish
<didrocks> hackish*
<didrocks> even
<alan_g> didrocks: it is horribly fragile too
<didrocks> urgh tools/setup-partial-armhf-chroot.sh
<didrocks> all build-deps repeated :/
<didrocks> and you don't have pkg-config in it
<didrocks> while in debian/control, for the package build-deps, you have it
<didrocks> this is a recipe for failure, not sure why it's there, but I think we should work on a better solution
<didrocks> at least, taking the build-deps from the packaging and handle the cross-arch case
<alan_g> Agreed (and am on record saying it_
<didrocks> :)
<didrocks> dpkg-checkbuilddeps -a armhf
<didrocks> run in the source directory
<didrocks> should list all needed deps to be installed
<didrocks> (forcing armhf in that case)
<didrocks>     rm ./usr/lib/arm-linux-gnueabihf/libEGL.so
<didrocks>     rm ./usr/lib/arm-linux-gnueabihf/libGLESv2.so
<didrocks>     ln -s libhybris-egl/libEGL.so.1 ./usr/lib/arm-linux-gnueabihf/libEGL.so
<didrocks>     ln -s libhybris-egl/libGLESv2.so.2 ./usr/lib/arm-linux-gnueabihf/libGLESv2.so
<didrocks> waow :)
<alan_g> In this case my problem is orthogonal to that mess - as I don't want the armhf pkg-config
<didrocks> alan_g: hum, you are calling find_package( PkgConfig ), right? you need to have at least a pkg-config installed
<alan_g> yes
<didrocks> alan_g: and it seems that the job is ignoring all build-deps on the machine and need to have this list setup
<didrocks> in tools/setup-partial-armhf-chroot.sh
<alan_g> That would be more reasonable than the current hack (but isn't my priority this morning)
<didrocks> alan_g: I think you just need to add pkg-config to the list in tools/setup-partial-armhf-chroot.sh
<didrocks> then, this would install it in this jenkins job
<alan_g> Won't that just put the armhf version into the chroot?
 * alan_g might as well try it anyway
<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)
<alan_g> didrocks: I *think* that as cmake is run outside the chroot it will wants the host version. But I'll try it.
<didrocks> alan_g:
<didrocks> ah
<didrocks> if cmake is run outside the chroot, yeah, that won't help
<didrocks> not sure how this job is setup, but manual install on the machine seems to be the only way then
<didrocks> (yeah for non maintenable jobs :p)
<tvoss> didrocks, mind taking another look at: https://code.launchpad.net/~thomas-voss/platform-api/introduce-hardware-subdirectory-and-package/+merge/169458?
<didrocks> tvoss: the symbols file looks better :) there are still my remarks about conflicts in debian/changelog, missing -doc package and so on though ;)
<tvoss> didrocks, that's not the same mp
<didrocks> tvoss: ah good, the diff wasn't regenerated :)
<didrocks> tvoss: 343+ _Z24ua_sensors_light_disablePv@Base 0.18.1daily13.06.21
<didrocks> you still expose that one ^
<didrocks> (and there is still the conflict in debian/changelog, even if it's another MP ;))
<alan_g> didrocks: thanks
<didrocks> tvoss: I guess the ABI for libunity_application and libubuntu-platform will evolve in sync?
<tvoss> didrocks, what is libunity application?
<didrocks> autotyping
<didrocks> libunbuntu-application
<didrocks> ubuntu*
<tvoss> yup, at least for now
<didrocks> tvoss: ok, but this change requests a rebuild of everything rebuilding against those libs
<didrocks> do you know what's using it, if any?
<tvoss> didrocks, sorry, I cannot follow you
<didrocks> tvoss: as you separate now some symbols from one lib to another
<didrocks> what are using those symbols needs to be rebuild against latest
<didrocks> to link against the right lib
<didrocks> basically, all rdepends of libplatform-api1-hybris
<tvoss> sure, I would assume that is automatically tracked and done
<didrocks> (and this breaks the ABI, right?)
<didrocks> tvoss: tracked and done by what?
<tvoss> didrocks, some clever build system?
<didrocks> the build system needs manual rebuilds
<didrocks> and upstream would need to bump ABI as a clever upstream :p
<didrocks> here, we have none of those, so we have to do that manually, ensuring the upgrade path and so on
<tvoss> didrocks, sorry, I cannot follow: what do I have to do to make this land?
<didrocks> tvoss: https://wiki.ubuntu.com/DailyRelease/FAQ#I_need_to_break_an_API.2BAC8-ABI
<didrocks> (it's weird that you are adding a changelog not on top of debian/changelog btw, with a higher version)
<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
<didrocks> tvoss: feel free to create them
<didrocks> tvoss: breaking ABI a lot isn't agile as well
<didrocks> tvoss: we have tools that we have and need to deal with those by creating procedure
<tvoss> didrocks, how do we plan to keep the mir development at high pace then? We are going to break the abi regularly
<didrocks> tvoss: yeah, I'll have a hack for this, but it's a hack
<didrocks> similar to nux and compiz
<tvoss> didrocks, how does that work?
<didrocks> tvoss: mind having a hangout? will be easier
<tvoss> let me grab coffee and eat something ... 10 minutes?
<didrocks> yep
<alan_g> tvoss: since mmrazik left do we have a preferred contact for our jenkins setup?
<tvoss> alan_g, not that I know of
<tvoss> didrocks, updated: https://code.launchpad.net/~thomas-voss/platform-api/introduce-hardware-subdirectory-and-package/+merge/169458
<didrocks> tvoss: bzr bd gives me:
<didrocks> - ua_sensors_light_disable(void*)@Base 0.18.1daily13.06.21
<didrocks> +#MISSING: 0.18.1+13.10.20130705-0ubuntu1# ua_sensors_light_disable(void*)@Base 0.18.1daily13.06.21
<didrocks> you hide it, not unmangle it, isn't it?
<didrocks> * remove the change in debian/changelog, it will be injected once merged into trunk and on top from the commit message
<tvoss> didrocks, nope, it is pulled in as a C++ symbol, let me check why that is the case
<didrocks> tvoss: + _Z24ua_sensors_light_disablePv@Base 0.18.1+13.10.20130705-0ubuntu1
<didrocks> tvoss: it's not unmangled properly it seems
<tvoss> mzanetti, I think alan_g needs some help with Jenkins
<mzanetti> ok...
 * mzanetti needs a little more details :)
<tvoss> alan_g, mzanetti is your poc :)
<hikiko> hi :)
<mzanetti> hi hikiko :)
<alan_g> mzanetti: there's a rather hacked job - mir-android-saucy-i386-build
<hikiko> anyone who has worked on android-mir? (except kdub who has a us timezone and I guess is sleeping right now :))
<hikiko> I'd like to build mir for android
<alan_g> mzanetti: which ought to have pkg-config installed, but doesn't
<hikiko> and run it there
<alan_g> hikiko: you've read the instructions right?
<hikiko> but I only know how to crosscompile it
<hikiko> mmm I read some instructions alan_g
<hikiko> maybe not the correct sec :) i ll check again :)
<alan_g> hikiko: it helps to know where you are stuck
<hikiko> alan_g, nowhere :D
<hikiko> I fixed the issue I had
<mzanetti> alan_g: it looks like Umockdev is not installed
<hikiko> and gbm works
<mzanetti> alan_g: you sure its a pkgconfig issue and not a missing build dep in your package?
<hikiko> so I want to do a minimal android nested platform
<hikiko> and an MP
<alan_g> mzanetti: the job ignores the build-deps
<hikiko> so that I can move on with what you suggested next week :)
<mzanetti> alan_g: hmm... thats not what it should do, or am I wrong?
<alan_g> mzanetti: there's a rather hacked job - mir-android-saucy-i386-build
<hikiko> after I get your (mir-team) feedback for the "dummy" nested platforms
<mzanetti> alan_g: yeah... I'm looking through that right now
<mzanetti> alan_g: ah... found it... it installs all the stuff manually
<mzanetti> alan_g: so should I just add the udevmockd there and thats it?
<mzanetti> or where does that come from?
<alan_g> mzanetti: No, umockdev is just a victim
<alan_g> mzanetti: what is needed is pkg-config in the host environment, not umockdev in the cross-compile "chroot"
<tvoss> didrocks, sent you a hangout invite
<didrocks> tvoss: let me switch to chrome
<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
<mzanetti> lets see how it goes
<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)
<mzanetti> alan_g: yep... it got over the cmake step
<mzanetti> alan_g: everything fine now?
<alan_g> mzanetti: thanks - I've added introducing sanity to this job to my backlog
<mzanetti> alan_g: ok cool. feel free to ping me in urgent cases where the US timezone is not up
<alan_g> mzanetti: I hope you don't regret that offer. ;)
<mzanetti> hehe... I'll demand beer at the next sprint if you overuse it
<tvoss> alan_g,  \o/
<alan_g> tvoss: it still hasn't landed
<tvoss> alan_g|lunch, is it top-approved, yet?
<tvoss> didrocks, https://code.launchpad.net/~thomas-voss/platform-api/introduce-hardware-subdirectory-and-package/+merge/169458
<tvoss> alf, mind hopping into #qa?
<alf> tvoss: sure
<tvoss> alf, cancel that
<alf> tvoss: sure :)
<tvoss> E_PARENTHESIS_MISMATCH
<tvoss> didrocks, https://code.launchpad.net/~thomas-voss/platform-api/add-documentation-part-1
<tvoss> bregma, ping
<bregma> tvoss, pong
<tvoss> bregma, hey there :) you looking into https://bugs.launchpad.net/mir/+bug/1195260?
<bregma> tvoss, I was but (1) PPC pbuilder/qemu hangs and (b) https://bugs.launchpad.net/mir/+bug/1195265 took precedence
<bregma> if you want to take 1195260 over be my gues :)
<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
<tvoss> bregma, just wanted to do it, but my Firday evening meeting marathon is about to begin :)
<didrocks> tvoss: bregma: +1 on disabling tests on ppc
<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
<tvoss> bregma, +1
<didrocks> tvoss: bregma: not in favor on this one
<didrocks> tvoss: bregma: at least, it's fine for the ppa, but not for entering distro
<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
<kdub> its one of those merge conflicts where there's actually something different happening between the two branches
<greyback> kdub: I've heard he's on holidays today
<kdub> ah
<kdub> thanks greyback
<greyback> np
 * kdub rewrites input stack.... muahaha
<tvoss> kdub, rofl
<kdub> :d
<alan_g> The sun is shining, I'm tempted to start the weekend 10 min early today.
<kdub> alan_g|EOW, enjoy!
<bregma> someone forgot 'bzr add' ?
<kdub> hmm?
<kdub> bregma, i just fired off a compile of lp:mir, went fine for me :)
<bregma> kdub, I caughtthe xmir_debug_guide merge half way in, it's OK now
<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
<kdub> bregma, not sure what your workflow is... but if you need faster compiles, we have some cross compile  scripts
<bregma> I'm trying to run the integration tests on arm, as far as I can tell cross compiles won't help
 * kdub tries armhf compile...
<kdub> lp:mir integration tests seem ok to me on nex4
<kdub> bregma,  is there a pastebin of what you're seeing
<bregma> TestClientIPCRender.render_accelerated deadlocks waiting for a buffer swap, running on a nexu7
<bregma> if you're enthuisiastic, http://paste.debian.net/14611/ for the output log (I've added tracing printfs)
<kdub> same problem from a few days ago?
<bregma> yep
<bregma> not going away by itself :(
<kdub> bregma, but it works without valgrind?
<bregma> nope, still deadlocks
<bregma> the child process exits while the parent is waiting on the buffer swap
<bregma> unfortunately after a couple of days I have only the vaguest understanding of the internal dataflow of mir
<bregma> firehose won't turn off
<kdub> bregma,  let me see if i can test mine really quickly...
<kdub> the n7 is like our forgotten stepchild, the focus is the gnex/nex4 at the moment
<bregma> it's the only arm device I have that runs touch
<bregma> qemu doesn't cut the mustard either
<kdub> bregma, yeah..., there's a few people in that boat (i think mterry as well)
<kdub> interesting... mine went ok
<bregma> I have a xformer but it's running precise (hmmm, hobby project for the weeken.... ideal target for Unity 8 Desktop)
<kdub> bregma, are you running as root?
<bregma> certainly not, that's anathema
<bregma> should I?
<kdub> i don't know if we checked the permissions on the /dev stuff for the n7
<kdub> n4/gnex don't need root, but we had to change some permissions I think
<bregma> well, it doesn;t seem to make a difference
<kdub> hmm, trying to think what the difference might be
<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
<ubot5> Ubuntu bug 1195265 in Mir "tests stuck on armhf" [Critical,In progress]
<kdub> bregma, we might need some sync for what's going on... is there a drive to get android under integration testing?
<kdub> (which would make me happy :) )
<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
<bregma> just that simple, really
<bregma> we have a cunning plan
<bregma> but successful builds on arm are blocking everything
<bregma> and Didier won;t let us just disable the test
<kdub> right :) that test goes and hits the drivers
<bregma> I'm all for disabling just that test, since if it uses the actual drivers it's not a valid generic test
<kdub> right, i think at this time, we just guarantee that the tests all work on gnex/nex4
<kdub> although the nex7 is (as you've no doubt seen) very close
<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
<bregma> are there any other tests that exercise the drivers or is it limited to TestClientIPCRender ?
<kdub> the only mir rule is that unit tests don't touch the driver
<kdub> bregma, i guess the mir team has work items, which are to get the generic arm builders to run only generic tests
#ubuntu-mir 2013-07-07
<bcbc2> Anyone else seeing all terminal stdin (including passwords in clear case) echoed on the splash screen while shutting down?
<bcbc2> I'm trying to figure out if it's mir related or not (running saucy + mir ppa)
#ubuntu-mir 2014-06-30
<RAOF> Wey, hey! At least clang notices that 1024 * 256 -> unsigned long isn't a narrowing conversion :)
<alan_g> alf__: do you mind if I steal lp:1335741?  It has a different cause to the fix you have.
<alf__> alan_g: yes you are right, please do, I will open a new bug
<alf__> alan_g: note that some invalid memory errors we see with valgrind are actually the result of --gtest_break_on_failure (i.e. gtest causes a segv to drop into the debugger, if any)
<alan_g> alf__: yes
<camako> Hello cosmonauts! We have started the process for a new Mir release. Packages will be announced here when they are ready.
<camako> saviq, greyback, Heads up! This MP (https://code.launchpad.net/~afrantzis/unity-mir/fix-1332624-input-area/+merge/224768) will be landing with the Mir 0.4.0 release. Row 25 on CI train spreadsheet.
<Saviq> camako, k thanks
<greyback> camako: noted, tq
<alan_g> camako: you might want to use this (once it lands) https://code.launchpad.net/~alan-griffiths/mir/spike-nested-server-test-fixture/+merge/224637
<camako> alan_g... sure
<alan_g> So you might also want to review. ;)
<camako> alan_g... :-) will do
<racarr> #0  0x00000000010bb050 in typeinfo for testing::internal::ThreadLocalValueHolderBase ()
<racarr> #0  0x00000000010bb050 in typeinfo for testing::internal::ThreadLocalValueHolderBase ()
<racarr> #0  0x00000000010bb050 in typeinfo for testing::internal::ThreadLocalValueHolderBase ()
<racarr> #0  0x00000000010bb050 in typeinfo for testing::internal::ThreadLocalValueHolderBase ()
<racarr> #0  0x00000000010bb050 in typeinfo for testing::internal::ThreadLocalValueHolderBase ()
<racarr> #0  0x00000000010bb050 in typeinfo for testing::internal::ThreadLocalValueHolderBase ()
<racarr> whoops!
<racarr> ah...
<racarr> I think my test is finishing before the testing server status listener gets to call on_start
<racarr> because my tests can finish entirely in the input threads...
<racarr> and then
<racarr> something goes pretty wrong lol
<racarr> presumably invalid thisreferencein the little lambda
#ubuntu-mir 2014-07-01
<RAOF> Pfft. That was a bit of a gnarly one.
<RAOF> You know, it really would be nice if Qt creator didn't crash each time my RANDR config changed.
<duflu> Confusing.... "0.1.9" is the latest download available ... by date :)  https://launchpad.net/mir/+download
<alan_g> alf_: anpok duflu - anyone about to vote or shall I just approve it? https://code.launchpad.net/~alan-griffiths/mir/spike-nested-server-test-fixture/+merge/224637
<duflu> alan_g: Code? What's that?
 * duflu looks away
 * alan_g thinks this is a new duflu - not sure if I like it. ;)
<mpt> Hi, can anyone remember why we started talking about âsurface rolesâ instead of âsurface typesâ? The Mir code still refers to âtypesâ, correct?
<duflu> mpt: Correct. I implemented "types" and "states" based on the old design docs a year or so ago. The word "role" then appeared in newer design docs, but the Mir code still refers to types and states.
<duflu> There's another new noun too... I forget
 * duflu votes for "types and states"
<duflu> Although the enumeration values used in code don't need to match perfectly so long as the mapping is clear
<mpt> thanks duflu
<doko> alan_g, tvoss: so the phone team did choose to do this transition this way, why do the mir people insist now on a different way?
<doko> alan_g, btw, your nick name is not up to date in the directory
<alan_g> doko: the mir team are being asked to approve a change that hasn't been adequately explained to them. Why were they not involved in a decision that affects them?
<doko> alan_g, what is missing from https://bugs.launchpad.net/mir/+bug/1329089/comments/5 ?
<ubot5> Ubuntu bug 1329089 in dbus-cpp (Ubuntu) "g++-4.9 binary incompatibilties with libraries built with g++-4.8" [Critical,In progress]
<doko> alan_g, I would assume three weeks is enough for raising questions
<alan_g> doko: it was proposed two working days ago. Not three weeks
<tvoss> alan_g, the bug is way older than that, though
<alan_g> The bug comment says "Don't use versioned build dependencies for g++-4.x at all (preferred)" and the MP introduces versioned dependencies - how does one follow from the other?
<alan_g> tvoss: regardless of the merits of the chosen approach duflu does have a point about the changelog
<tvoss> alan_g, sure, happy to change that
<alan_g> tvoss: that should resolve both the "Needs Fixings" you've got. ;)
<alf_> mterry: dandrader: I saw that we updated the scene code in unity-system-compositor devel-mir-next. The issue there is that because we are creating the SceneElements on our own (instead of letting the scene do the work), we are missing on the new visibility tracking (occludded/exposed events) mechanism.
<dandrader> alf_, yes
<alf_> mterry: dandrader: Last week I suggested that we drop the scene reimplementation and just hide all sessions that are not needed. Was this considered, or was it too risky to do now?
<dandrader> alf_, fell free to do whatever you think is best. I just did it because no one else in mir team had time to do it and I had to unblock the qt comp work. My idea in that patch was to keep the exact same behavior as before
<dandrader> alf_,  thus ignoring the visibility as that method simply won't return elements that are not to be rendered
<alf_> dandrader: ok, if there is nothing blocking a potential change, I will take a look, thanks
<dandrader> alf_, which I guess yields the same result as returning elements with visible=false?
<dandrader> alf_,  and if I recall correclty, mterry wanted to keep this scene infrastructure for some future use....
<mterry> dandrader, alf_: no, it should be fine to try hiding the sessions
<dandrader> alan_g, is I call surface->configure(mir_surface_attrib_focus, mir_surface_focused), is there any logic in mir that might override this and set the focus back to unfocused?
<dandrader> s/is I/if I
<alan_g> dandrader: you mean as a result of your call or as a result of anything?
<dandrader> alan_g, well, both. :)
<racarr> dandrader: SurfaceConfigurator could...
<racarr> which it looks like you guys are implementing in unity-mir and hooking up to a Qt signal um
<racarr> youc an check the return value of surface->configure to see
<racarr> ifyou succeed in setting it to focused (and then perhaps its changed latter)
<alan_g> dandrader: yes. E.g. the surface is destroyed by the client
<racarr> or if it never gets set to focused (i.e.t he surface configurator intercepts it and changes to unfocus)
<dandrader> racarr, right, we do have a surfaceconfigurator that seems to just return whatever it gets
<dandrader> will take a closer look at this guy to see if there's any missing piece
<dandrader> racarr, is SurfaceConfigurator::attribute_set just like a signal that tells what has happened or does it expect any action to be taken in the implementation?
<racarr> dandrader: It returns the value which should actually be set
<racarr> so its like a value filter or something
<racarr> dandrader: i.e. for the shell to say
<racarr> haha no this surface cant be maximized dont be silly
<racarr> etc
<dandrader> racarr, Isn't that SurfaceConfigurator::select_attribute_value ?
<racarr> OH sorry
<racarr> Yes I believe attribute_set is just a signal
<dandrader> racarr, hmmm, looking at ms::BasicSurface::configure it looks like configuring the focus attribute doens't actually do anything?
<alf_> racarr: dandrader: We have a FocusSetter class that can change the focus in reaction to new sessions etc in SessionManager. Is unity-mir overriding this?
<dandrader> racarr, I mean, it doesn't call an internal set_focus() or anything....
<dandrader> it just notifies the observer
<dandrader> alf_, I took a quick look at FocusSetter but it seemed to deal with session focus which seemed to be a concept distinct from surface focus...
<racarr> dandrader: Ah sorry didnt understand what you were doing. yes that is true
<racarr> FocusSetter is the only way to "set focus" and the attribute is something it sets.
<racarr> It sets focus to the default surface for a session
<racarr> but I guess we can/should have focus(surface)
<dandrader> racarr, all I wanna do is calling surface->configure(mir_surface_attrib_focus, mir_surface_focused) and have the client be told that so that it can update this stuff UI accordingly
<alf_> mterry: how do you try unity-system-compositor + greeter + multiple sessions (e.g. if I make changes how do I test I haven't broken it?)
<racarr> dandrader: I'm not 100% surethats right, because it shouldn't be "focused"
<racarr> for example unless it has
<mterry> alf_, uh... that was much easier back with a split greeter
<racarr> the keyboard input target
<racarr> itspossible, that the_surface_configurator
<dandrader> racarr,  because in the qtcompositor world the focus concept lives in the qml scene of unity8, so I wanna use surface->configure(mir_surface_attrib_focus,...) as a way of exposing that info to the client. so effectively I just want  the IPC done
<racarr> could becomethenew...focus mechanism
<mterry> alf_, it's tricky because USC gets its ideas of which session should be focused from lightdm
<alf_> dandrader: racarr: use a NullFocusSetter?
<racarr> Yep
<dandrader> racarr, in qt comp, every client surface is represented by a qml item, which has a focused property
<mterry> alf_, so really unless you fake something up, you'll need an actual split greeter
<racarr> dandrader: Yes I see I forgot the input targeter,etc werent relevant
<racarr> I think Alf is right use a NullFocusSetter so no one will interfere with you setting the attributes otherwise
<mterry> alf_, but you can test the spinner / primary session swapping by killing unity8 and confirming that it brings up a spinner again
<mterry> alf_, and creating new demo clients to connect to USC and confirm that they don't display
<racarr> or implement the_focus_setter with an impl that just calls surface->configure
<dandrader> racarr, but still surface->configure(mir_surface_attrib_focus is effectively a noop in BasicSurface... no IPC gets done
<racarr> err...I dont think thats true because we have a test
<racarr> lemme look
<alf_> mterry: that would be a good starting point, but I would like to also put the greeter in the equation when testing (isn't that the reason behind current and next sessions in usc?)
<dandrader> racarr, or is there a surface observer that gets notified and does the IPC?
<mterry> alf_, yes it is the reason
<mterry> alf_, but the split greeter branch was ripped out of trunk and not replaced with anything that works against current trunk right now
<mterry> (I've been too busy with RTM stuff to rework it in the short term)
<racarr> dandrader: yeah thats it, src/server/scene/surface_event_source.cpp
<racarr> lol...its a little...nonobvious from the code
<alf_> mterry: makes sense... what does RTM use ATM? (yay, acronym madness!)
<mterry> alf_, right now it uses an integrated greeter, just some qml that the unity8 process draws
<dandrader> racarr, ahhh, ok. thanks for the info!
<racarr> np, sorry to be a little confusing lol
<alf_> mterry: ok, so that works for now because we only have one session on the phone?
<mterry> alf_, right.  No multi-user support yet
<alf_> mterry: ok, so if, for example, I used translucent sessions to visually check that two sessions (current, next) are rendered, would that be a decent test  of the expected behavior?
<mterry> alf_, yeah, sure.  But the trick is fooling USC into thinking what the next session should be
<mterry> alf_, maybe just hard-code the name for testing purposes
<davmor2> kgunn: Manta is having display issues.  If I unplug it and the screen blanks I get a brief flash of grey and then it is just black
<alf_> mterry: Sounds good, thanks. Hopefully I will find some time this week to give it a go. Thanks!
<davmor2> kgunn: we are wondering if this would be similar to the issue that people on nexus 5 are seeing
<kgunn> what image davmor2
<kgunn> i've been playing with manta last nigth &
<kgunn> this morning
<davmor2> kgunn: 106/107 for today
<kgunn> havent seen this
<kgunn> lemme check my image
<kgunn> #
<davmor2> kgunn: needs to be unplugged
<kgunn> davmor2: mmm...lemme see
<davmor2> kgunn: if you have the usb lead in it works fine
<davmor2> kgunn: once you are in the broken state you can actually plug the usb lead into the dev press the power button and it wakes fine
<kgunn> davmor2: ok, i see it...freaking weird
<kgunn> AlbertA: ^
<kgunn> check this out...
<kgunn> why would usb connection effect screen unblank & contents
<kgunn> e.g. the screen does come on, but contents missing
<kgunn> davmor2: and its seems inconsistent
<kgunn> sometimes it works
<davmor2> kgunn: happens reliably here if there is no usb lead in.  I also noticed that it sometimes happens on the music scope if you play a track from the scope and then pause it but that is flakey at best
<kgunn> davmor2: huh...it definitely happens more than not, but its not 100% i can get back to lock screen every now and then w/o usb in
<AlbertA> kgunn: davmor2: only in manta?
<kgunn> probably 1/3 of the time lock screen....2/3's grey/black
<davmor2> kgunn: I wonder if it is because of the gfx chipset and it being a tablet so it does deep sleep properly.  That would mean that adb was causing a wake on the system and then screen pops into life maybe?  long shot
<kgunn> davmor2: mmm...maybe
<kgunn> does feel kernelish
<davmor2> AlbertA: yeap only manta possible bq/meizu and maybe nexus 5
<kgunn> davmor2: i've been playing ever since you pung....it seems to be rare on time-outs (vs very common on button hit)
<AlbertA> davmor2: ok flashing #107... yeah it maybe related to suspend...
<davmor2> AlbertA, kgunn: So Flo is fine I've been trying it most of the afternoon
<davmor2> mako: was tested for promotion it is fine
<kgunn> dang it kdub driving a uhaul...he would find this interesting
<davmor2> kgunn: Shall I file a bug against mir for this initially?
<AlbertA> davmor2: against unity-system-compositor
<davmor2> AlbertA: will do
<davmor2> https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1336411
<ubot5> Ubuntu bug 1336411 in unity-system-compositor (Ubuntu) "Manta on recent images doesn't wake correctly from suspend" [High,New]
<AlbertA> davmor2: kgunn: https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1336411/+merge/225209
<AlbertA> davmor2: the blank issue in manta was due to suspend indeed
<davmor2> AlbertA: yeah
<AlbertA> davmor2: so as soon as I get a review, I'll propose to land
<AlbertA> can somebody take a look at: https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1336411/+merge/225209
<kgunn> rsalveti: or mterry ^ ? we're down a kdub today who might normally review
<mterry> I am about to head to a dentist appt, but can do later today
<olli> AlbertA, how do I take a screenshot on the device?
 * olli can't google it and doesn't remember how to do it
<racarr> phablet-screenshot exists if thats what you mean
<racarr> AlbertA: Im checkingit out...
<olli> racarr, thx
<olli> I was searching in the ubuntu- name space
<racarr> :)
<racarr> AlbertA: So the basic point is what was "acquire-sys-state"
<davmor2> AlbertA: okay back from tea.  Is there a package I can install and test and I'll happily do that for you
<racarr> which I am guessing is like...acquire a powerd we are awakecookie or something
<racarr> needs to be called
<racarr> before display->configure?
<AlbertA> racarr: right before attempting to power on the display
<AlbertA> nexus10 doesn't like it...
<AlbertA> otherwise
<racarr> ok makes sense to me lol
<racarr> youc an get in to a similar state on nexus 4 actually or at least you used to be ableto
<racarr> *thinks*
<racarr> eh
<racarr> similar but unrelated
<racarr> there was a point where to run mir without unity8 you had to run
<racarr> powerd-cli active:p becausenothing else
<racarr> waskeeping the system out of suspend state
<racarr> andthen powering the displays would fail of course.
<racarr> anyway lgtm
<AlbertA> racarr: heh :)
<olli> AlbertA, racarr phablet-screenshot seems to be looking for a local socket, wasn't there a convenience script I could run on the dekstop and which would get me a screenshot from the device
<olli> without having to login etc
<AlbertA> racarr: thankfully those days are gone
<AlbertA> olli: yeah that should let you do it from the desktop
<AlbertA> olli: it has been updated though
<AlbertA> olli: but it's a utopic package
<AlbertA> olli: so if you are not in utopic, you won't get the updated scripts I suppose
<davmor2> olli: you need to change /usr/bin/phablet-screenshot from /run/mir_socket to /var/run/mir_socket iirc then it works
<AlbertA> racarr: thanks!
<AlbertA> kgunn: can you top approve? https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1336411/+merge/225209
<davmor2> AlbertA: if there is a package I can install to test that fix give me  a ping and I'll happily test it in the morning nearly my EOD unfortunately
<AlbertA> davmor2: sure, I'll ping you thanks@
<kgunn> AlbertA: done
<kgunn> AlbertA: we should throw that in with camako's mir040 landing request
<AlbertA> kgunn: oh...I just put a new row
<AlbertA> in ci train
<kgunn> AlbertA: actually...that's fine
<kgunn> we can do it seperate
<kgunn> camako probably wants to finally get mir landed, no need to add 1 more complication ;)
<dandrader> racarr, don't you think we're missing this? http://paste.ubuntu.com/7733309/
<racarr> dandrader: Looks like it.
<dandrader> racarr, ok, I'll report a bug
<dandrader> https://bugs.launchpad.net/mir/+bug/1336548
<ubot5> Ubuntu bug 1336548 in Mir "SurfaceConfigurator::attribute_set always say "unfocused" for focus property changes" [Undecided,New]
<racarr> dandrader: Thanks ill make a test andpropose a branch unless you are already on it
<dandrader> racarr, I don't have a branch. just have that patch. that's why I reported the bug (making the test is the hardest part) :)
<racarr> dandrader: :) Thanks.
<racarr> will propose fix asap
<dandrader> racarr, thanks!
<dandrader> racarr, we are also missing a mir_surface_get_focus(), or mir_surface_get_focus_state() :(
<dandrader> on the client API side
<dandrader> same for the visibility attribute
<racarr> dandrader: Also true -.- though it does show up in the attrib change events
<racarr> will...mp an mp for that as well
<dandrader> racarr, yes
<dandrader> racarr, reported a bug for it as well https://bugs.launchpad.net/bugs/1336553
<ubot5> Ubuntu bug 1336553 in Mir "mir client API is missing getters for some surface attributes" [Undecided,New]
<racarr> Was out picking up more green tea! To the emacs machine.
<racarr> Thanks for writing it up in bugs.
<RAOF> Yay bugs!
#ubuntu-mir 2014-07-02
<AlbertA> davmor2: FYI, the fix for https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1336411 has already landed
<ubot5> Ubuntu bug 1336411 in unity-system-compositor (Ubuntu) "Manta on recent images doesn't wake correctly from suspend" [High,Fix released]
<duflu> alf_: So mir_demo_server_shell doesn't respond to SIGINT any more?
<alf_> duflu: it should, are you seeing something different?
<duflu> alf_: Yep, as of this week Ctrl+C does nothing
<duflu> Which is fine if it's intentional
<alf_> duflu: hmm, now that I think about it, I actually think that's old? I've always used ctrl-alt-backspace to quit
<duflu> alf_: Yes, well I haven't tried it since May of course :)
<alf_> duflu: so, I think this was affected by a change in the vt input mode
<duflu> Sounds plausible. Although I'm running in ssh
<alf_> duflu: then that should work, since you are just sending SIGINT to the process
<duflu> alf_: Boo. That means I have to retest and log a bug
<duflu> alf_: Oh I already reported it. Nothing new... https://bugs.launchpad.net/mir/+bug/1293965
<ubot5> Ubuntu bug 1293965 in Mir "Using the server option "--vt" prevents Ctrl+C (SIGINT) handling" [Medium,Triaged]
<dandrader> alan_g, about that "surface orientation and surface attributes" discussion: what's a surface attribute? maybe there are (or should be) read-only and read-write surface attributes (from the client point of view) and that's enough?
<alan_g> dandrader: maybe. I've not had need to think deeply nor read the design docs that motivated them.
<dandrader> alan_g, from my naive point of view, if you have some information regarding a surface, such that a client could go and ask "hey, what's the value of X for my surface Y?" or "hey, tell me when the value of X for my surface Y changes (i.e. and event)" then that "X" is a surface attribute. If the client has the right to change it or not it's another story.
<alan_g> camako: I know you've other things on your stack but... I'm hoping that this will finally make it easy to write a test for your nested lifecycle logic. Let me know if there anything isn't clear. https://code.launchpad.net/~alan-griffiths/mir/more-nested-server-testing/+merge/225174
<dandrader> alan_g, I find it odd when you are able to know when the value something changes but not its current value
<dandrader> alan_g, or vice-versa
<camako> alan_g, sorry the release took all my time... (too much time if you ask me :-) )
<camako> alan_g, still need to test xserver
<alan_g> dandrader: from my naive point of view attributes is complicated by having an ABI stable implementation (index value pairs) wrapped in an unstable API whose main benefit is that changes are routed through a "configurator". It would make more sense to me with mir_surface_get_attribute(surface, attribute)/mir_surface_set_attribute(surface, attribute, value)
<alan_g> But things must be this way for a reason. I just don't know it.
<alan_g> camako: np. (Agree about the time it sucks up.)
<alan_g> dandrader: the guy to talk to about attributes is duflu - he implemented it based on some (now ancient) design docs
<dandrader> alan_g, ah, ok. so it's about what entails when something is exposed via that attribute system (which has some limitations and expectations)
<alan_g> dandrader: yes. It may well be that we could now come up with both better requirements and a better implementation. But I've not been involved (yet) and am not sure who the stakeholders are.
<davmor2> AlbertA: manta fix landed and looks good :)
<davmor2> kgunn: ^
<alan_g> dandrader: @"I find it odd when you are able to know when the value something changes but not its current value" are you talking about orientation? doesn't mir_surface_get_orientation() do that for you?
<dandrader> alan_g, no, that's visibility
<dandrader> alan_g, that's an example. but I was more like saying in general. not pointing to any specific case
<alan_g> dandrader: sure. I just wasn't aware of an example and you started by talking about orientation.
<bregma> hey folks I started getting a segfault from Mir server code in Unity 8 (desktop) yesterday on all my machines after updating to the latest packages, reported as #1336854
<bregma> it's not clear to me if this is a Mir bug, a Mesa bug, or what, so I'm pinging people here for some better-educated advice
<AlbertA> ummm
<AlbertA> my 5sec timer is firing in 6s
<AlbertA> but std::chrono thinks it is 5s
<AlbertA> in the phone devices
<racarr> std::chrono thinks it is 5s?
<racarr> I mean...technically thats allowed right :p
<AlbertA> racarr: I mean if I measure with an external clock
<AlbertA> it's 6s...
<AlbertA> but std::chrono says its 5
<AlbertA> i'm trying to see what is up
<racarr> a non real time kernel? :p
<racarr> I guess if it does it every time though
<racarr> something is bad
<AlbertA> racarr: yeah it's consistent
<AlbertA> I would understand a few millis here and there
<AlbertA> not a full second
<AlbertA> I wonder if there's some time drift issue in the libstdc++ for armhf
<AlbertA> nah...It was my inaccurate subjective external clock
<racarr> haha wait did you really mean
<racarr> an external clock
<AlbertA> annotate-output is useful :)
<racarr> Ithought you meant like C time functions or something
<AlbertA> racarr: nah...
<AlbertA> racarr: :)
<racarr> lol
<racarr> yay time still works
<AlbertA> racarr: when I doubt I usually go to the oscilloscope but have none there :)
<racarr> lol
<AlbertA> racarr: maybe it was gravitational time dilation :)
<AlbertA> given that the external clock was closer to my body and it was slower
<AlbertA> :)
<racarr> Haha
<racarr> probably either that or the Ubuntu NSA backdoor for cryptographic timing attacks
<AlbertA> racarr: heh
<racarr> Do we have a C style guide?
<racarr> imnot 100% sure what alan is talkingabout here https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-7-name-some-cursors/+merge/225242
<racarr> am I being stupid and...missing something or is he just saying
<racarr> char const *const instead of char const* const
<racarr> which would then apparently be part of our C style guide?
<racarr> INSTANTIATE_TEST_CASE_P makes me feel like some sort of test wizard
<racarr> shooting multipronged branching test lightning bolts.
<racarr> also in investigating surface attributes found a nice mix of
<racarr> race conditions, potential deadlocks, and simple logic emissions
<racarr> -.-
<racarr> cest la vie
#ubuntu-mir 2014-07-03
<bregma> well, I'm going to try again: desktop Unity 8 has been dead in the water for a while, segfaulting in the Intel driver on uninitialized buffers when the Mir server does a glClear()
<bregma> currently logged as https://bugs.launchpad.net/ubuntu/+source/unity8-desktop-session/+bug/1336854
<ubot5> Ubuntu bug 1336854 in unity8-desktop-session (Ubuntu) "Unity 8 fails to start, segfault in i965_dri.so" [Undecided,New]
<bregma> wit han attached stack trace
<bregma> I'm looking for suggestions on what may have changed in the stack in the last week or two, and/or suggestions on how to chase down more information to help narrow the cause down
<RAOF> bregma: Yeah, I noticed that yesterday.
<RAOF> It's going to be a mesa problem.
<bregma> unity-system-compositor continues to run fine, so it could be something wacky higher in the stack, it's under a lot of churn lately too
<RAOF> usc is fine because it's not using the Mir EGL platform.
<RAOF> I suspect that you first saw this on the 23rd?
<RAOF> That's when Maarten uploaded hte new mesa.
<bregma> sounds suspicious
<bregma> if I can perhaps revert to an older version, that would point the finger
<RAOF> Give it a whirl.
<RAOF> I'll poke around in the mesa code.
<bregma> FTR, reverting libgl1-mesa-dri to 10.1.3-0ubuntu0.1 fixes the segfault
<RAOF> Thanks. I'm installing a debug build, so it shouldn't be long before working out what's wrong and fixing it.
<RAOF> Ah! There's the problem.
<RAOF> bregma: Mesa 10
<RAOF> bregma: Mesa 10.2.1-2ubuntu3 fixes your problem. Enjoy!
<duflu> racarr: What's a prompt session?
<racarr> duflu: trust sessions
<racarr> ;)
<racarr> https://wiki.ubuntu.com/Security/TrustStoreAndSessions
<racarr> sort of explains how the name prompt session
<racarr> comes about
<duflu> racarr: OK then...
<RAOF> Oh, whoops. We appear to call all manner of un-signal-safe functions in the emergency cleanup signal handler.
<RAOF> Including allocations!
<duflu> RAOF: Sounds a bit silly. Incidentally I mentioned we shouldn't ever do such a thing in a branch that's pending... https://code.launchpad.net/~vanvugt/mir/fatal-error/+merge/219471
<RAOF> Yeah, reviewing that is what brought me to look at the emergency cleanup bit.
<duflu> RAOF: Well the latest emergency cleanup stuff I don't think I reviewed either
<duflu> The plate was piled too high in May
<duflu> Hmm Chrome in Trusty has annoyingly bad tearing (diagonal/triangles)... I wonder if that's Chrome or Compiz
<duflu> If it's Compiz then of course we don't care any more
<RAOF> I think it's Chrome; it started with the Aura drop, IIRC.
 * duflu looks up Aura
<duflu> Oh, nice one Google... they really should be able to do better than that
<alf_> RAOF: duflu: where are we doing allocations in the emergency cleanup handlers?
<duflu> No idea
 * duflu points to RAOF
<RAOF> alf_: You assign to a vector; that's at least potentially doing allocation.
<duflu> Oh that will do it
<RAOF> Also, pthreads isn't threadsafe, right?
<duflu> Depending on the method...
<duflu> RAOF: Umm, what?
<RAOF> Ahem.
<RAOF> Signalsafe
<RAOF> 'cause we also lock a mutex in there.
<duflu> RAOF: It never used to be... Signals could arrive in _any_ thread but should arrive in just one. So unpredictable but safe I think
<RAOF> Right, but what happens if pthread_lock gets interrupted by a signal?
<duflu> If you want to determine the thread to use then pthread_kill
<alf_> RAOF: duflu: at vector, right, that's easy to fix I will take a look
<duflu> RAOF: "If a signal is delivered to a thread waiting for a mutex, upon return from the signal handler the thread resumes waiting for the mutex as if it was not interrupted."
<duflu> [http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_mutex_lock.html]
<RAOF> I'm not sure that covers my concern.
<RAOF> But signal-safety documentation isn't the best :)
<duflu> RAOF: Well that's just the spec. Everyone has their own implementation
<RAOF> No, I mean that it's not clear that documentation covers the case I'm concerned about.
<alf_> RAOF: "The mutex functions are not async-signal safe. What this means is that they should not be called from a signal handler. In particular, calling pthread_mutex_lock or pthread_mutex_unlock from a signal handler may deadlock the calling thread."
<alf_> RAOF: :)
<RAOF> alf_: Ding!
<duflu> Certainly, locking in signal handlers is also bad
<duflu> Then again without such bugs I would have received more core files in my life time than I have
<RAOF> Basically, the set of things you can _safely_ do in a signal handler is poke at memory addresses :)
<RAOF> </hyperbole>
<duflu> I remember plenty of stack traces from customers showing code hanging in a signal handler after a crash :/
<RAOF> Yup.
<RAOF> It's disturbingly easy to deadlock in one.
<alf_> duflu: RAOF: We can drop the locks, making it clear that you are not to call the emergency cleanup while concurrently adding a handler
<alf_> duflu: RAOF: plus the emergency cleanup is a best effort cleanup
<duflu> alf_: If we can guarantee the signal handler is only called once then I guess reduced locking is OK
<RAOF> Well, the signal handler isn't reentrant.
<RAOF> (By default)
<RAOF> But we should ensure that we don't do anything that's highly likely to deadlock there :)
<duflu> Also easy to do by accident though... if someone else asks the signal() function for the existing handler (yours) and calls it
<RAOF> ?!
<RAOF> Why on earth would they do that?+
<alf_> duflu: RAOF: and if we get rid of the locking requirement we might as well drop the vector copy
<duflu> RAOF: 3rd party libraries or general dealing with bad APIs where you need a signal handler
<RAOF> duflu: Oh, as in wrapping a signal handler?
<duflu> RAOF: I think that's one case
<duflu> alf_: If the vector never gets too big then an array is fine
<RAOF> alf_: Yup. We could, of course, make it a signal-safe data structure, but given that it's basically write-once I think we can happily read without locking.
<duflu> If it's write-once and that's guaranteed to happen before the read there is no race. And Helgrind etc will be happy without locking
<alf_> duflu: RAOF: it says "The mutex functions are not *async-signal* safe", but the signals we handle with emergency cleanup are synchronous
<RAOF> Unless someone sends us SIGsomething :)
<duflu> Heh, bypass must be awesome if it's still doing my head in a year later
<dobey> who would be best to bug to maybe get a crash in libmirclient on application exit on the phone fixed asap today?
<AlbertA> dobey: bug #?
<AlbertA> dobey: which image# ?
<AlbertA> racarr: can you take a look at https://code.launchpad.net/~albaguirre/unity-system-compositor/no-inactivity-handling-desktop/+merge/225537
<AlbertA> racarr: it's fairly small :)
<dobey> AlbertA: on 111, but lokos like it's been happening for a little while. i haven't filed a bug yet, the reports on errors.u.c failed to retrace, so there's no "create a bug" link for them. trying to determine the best way to file the bug
<AlbertA> dobey: so any application exiting crashes?
<dobey> should i just file it with the top of the stack trace and a link to the errors?
<AlbertA> dobey: what's the fastest way to reproduce?
<dobey> AlbertA: any using the mir backend of qt/qml afaict. open clock app, wait a few seconds, and close it, and there should be a crash report in /var/crash/
<dobey> https://errors.ubuntu.com/problem/6552ba4342afeb93d20e22711ac36f655cd885d8
<dobey> or go to online accounts, then hit back and should result in in a crash report too
<AlbertA> dobey: I couldn't access that link
<AlbertA> dobey: but I'll take a look, if you can submit a bug # that would be great
<dobey> AlbertA: sure. should i just copy/paste the top of the stack trace in the bug?
<AlbertA> dobey: sure
<dobey> ok will do
<racarr> AlbertA: Sure
<dobey> AlbertA: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1337481
<ubot5> Ubuntu bug 1337481 in mir (Ubuntu) "Crash in libmirclient on app exit on phone" [Undecided,New]
<racarr> dandrader|afk: greyback: https://code.launchpad.net/~unity-team/platform-api/devel-for-qtmircompositor/+merge/225320https://code.launchpad.net/~unity-team/platform-api/devel-for-qtmircompositor/+merge/225320
<racarr> err whoops
<racarr> but what is up with line 427
<racarr> It looks like, state_before_hiding is being used to save the state across minimize state changes
<racarr> but why initialize to MAXIMIZED? There must be a default or currentstate
<greyback> racarr: indeed. I can't say. Hope dandrader|afk can reply
<racarr> anyway good besides that
<racarr> if he doesnt come back soon ill leave some comments
<racarr> on launchpad
<greyback> racarr: please do, and I'll try to fix (daniel off on hols at eod today)
<racarr> :) sounds nice
<racarr> racarr off on holidays in 51 days
<racarr> lol
<dandrader> racarr, right, I'm just initializing it to something
<dandrader> racarr, the first time you call show(), the state will be set to this value
<dandrader> racarr, which is what we want on phablet anyway
<dandrader> racarr, "restored" windows make no sense there
<dandrader> racarr, and the "beautiful" papi API is not expressive enough at the moment for the user to set the mir surface states properly. eg: "papi::window::show() == mir::surface::set_state(maximized) or mir::surface::set_state(restored?
<dandrader> racarr, so I don't bother with this sad situation and just let it go maximized, which is what we want
<dandrader> and now I'm repeating myself...
<dandrader> racarr, so if you wanna to fix thing you would have to rewrite that papi api to be a 1-to-1 mapping of mir
<dandrader> racarr, which is a waste of developer time IMHO
<dandrader> and would also require changing papi users: ie, qtubuntu
#ubuntu-mir 2014-07-04
<alan_g> dednick: re ..._trusted socket. I think the essentials are done (I need some tests around starting up providers - but it ought to "just work" as a side effect of the production changes). Let me know if you try it: lp:~alan-griffiths/mir/permissions-and-error-handling-for-prompt-sessions
<dednick> alan_g: thanks. i'll take a look
<alan_g> dednick: Sorry, wrong branch in paste buffer...  lp:~alan-griffiths/mir/spike-trusted-helper-socket
<alf_> greyback: Hi! In case you know... why are using a QCoreApplication in USC? Is it a left-over? Are we going to need it in the near future?
<greyback> alf_: I don't know. mterry would
<alf_> greyback: yes, but US is on vacation today :) thanks
<greyback> alf_: sorry, I've barely looked as USC code
<alf_> greyback: no, worries, I will just remove it and we can put it back if needed
<greyback> alf_: it's mainly just adds an event loop so you can use qt signal/slots - it's not used for GUIs
<alf_> greyback: ahh, it's used by our dbus infrastructure in USC
<greyback> alf_: yeah, would be needed for that too
<greyback> alf_: can I ask you some questions on mir, gl configs & mesa?
<alf_> greyback: of course
<greyback> alf_: the qtcompositor code right now just uses the gl context that Mir chooses for it. Which is perfect on phablet devices as GLES is supported
<greyback> alf_: but on desktop, Qt compiled with only desktop GL support.
<greyback> alf_: I know in qtubuntu we had a hack to call eglBindAPI(OPEN_GL) which persuaded Mesa to let us use a GLES context with GL shaders and stuff
<greyback> alf_: was that it? Nothing else had to be done?
<greyback> I'm trying to do the same thing for QtComp but am not having success.
<alf_> greyback: I don't recall the detail, only that this was a hack that just happened to work with Mesa. The issue is that since Mir uses GLES2 it links with libGLES2. If qtcompositor comes and indirectly links with libGL (which offers many of the same symbols) there could be trouble.
<greyback> alf_: that's an idea. Perhaps there's some lib preloading happening somewhere to get around that
<mpt> Oh dear I just realized that default window positioning depends on whether youâre using an LTR or an RTL language
<alf_> greyback: but ideally Qt should support selecting GL vs GLES2 at runtime... I think they have made some first steps to support this?
<greyback> alf_: qt5.3 does, but our packaging hasn't turned it on
<greyback> alf_: ah, it's windows only :( So no change there
<alf_> greyback: So, what kind of errors are you getting?
<greyback> alf_: http://pastebin.ubuntu.com/7746717/ just a snippit (bit messy, I've debug code in)
<alf_> greyback: ok, how about creating a new GL context shared from the GLES2 context that Mir gives you and using that with Qt?
<greyback> alf_: that's what qtcomp is doing actually
<greyback> http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/platforms/mirserver/miropenglcontext.cpp
<greyback> combined with http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/platforms/mirserver/mirserverintegration.cpp#L124
<alf_> greyback: it seems though, that Qt produces a fragment shader for GL but is being compiled with a GLES2 context, and thus complains about missing precision
<greyback> alf_: right. So I tried calling eglBindAPI(EGL_OPENGL_BIT) before makeCurrent and swapBuffers, but no good
<greyback> err eglBindAPI(EGL_OPENGL_API)
<greyback> but same error
<greyback> so a difference I see is that in qtubuntu, eglBindAPI is also called before the context is created
<alf_> greyback: I don't see how the code in miropenglcontext sets the context to desktop GL. It eventually calls DisplayBuffer::make_current() which will use the built-in mir context (which is GLES2)
<greyback> alf_: it doesn't. I had thought that Mesa would "force" a GLES context to accept desktop GL
<greyback> alf_: I can confirm, if I hack Mir to use a desktop GL context, this works fine
<greyback> this = Qt Comp on desktop
<greyback> it's just the GL/GLES mismatch that I'm fighting
<greyback> and I'm trying to emulate what qtubuntu does
<alf_> greyback: From what I understand, what Mesa accepts is linking against libGLESv2 and asking for a desktop GL context and vice versa and it works
<alf_> greyback: but if the current context is GLES2 you can't do GL stuff with it
<greyback> alf_: which makes sense to me.
<greyback> alf_: so is qtubuntu actually creating a desktopGL context: http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/view/head:/src/platforms/base/context.cc#L55
<greyback> just by having bound the api before eglCreateContext
<greyback> ?
<alf_> greyback: right
<greyback> alf_: ok. Then that's my problem then so. Mir creates GLES2 context, but Qt needs desktopGL.
<alf_> greyback: what do you change in Mir to force a GL context? Only the eglBindAPI() call in display_helpers?
<greyback> alf_: I hacked Mir to choose GL context, just to prove to myself Qt would work with it on desktop. I've not tried this eglBindAPI thing before
<alf_> greyback: right, I mean how did you hack it, do you have a diff?
<greyback> alf_: all extremely messy: http://pastebin.ubuntu.com/7746824/ I hope you can see what I'm attempting though
<alf_> greyback: You also mentioned that you hacked Mir itself to produce a desktop GL context. Do you have a diff for that?
<greyback> alf_: ah. Maybe, lemme see if I kept it. It was several months ago now
<greyback> alf_: I doubt it'll apply cleanly: http://pastebin.ubuntu.com/7746849/
<greyback> it was to add a compile-time option to mir, similar to what Qt had. Think it broke more than it solved overall
<greyback> EGL_RENDERABLE_TYPE, EGL_OPENGL_BIT, <- the main bit really
<alf_> greyback: If you can confirm that just changing EGL_RENDERABLE_TYPE, EGL_OPENGL_BIT and eglBindAPI(EGL_OPENGL_API) in display_helpers.cpp (while still building mir against libGLESv2) works for you, we can provide a workaround in Mir
<alf_> greyback: with the understanding that this is the WRONG way to do it :)
<greyback> alf_: it is, definitely
<alf_> greyback: but barring Qt having runtime GL vs GLESv2 selection (or perhaps Mir having it?) there is not much we can do, other than take advantage of this fortunate quirk in Mesa
<greyback>  alf_ yeah. If I can manage to exploit the Mesa quirk, I might be happy enough for now
<alf_> greyback: ok, so try just hacking EGL_OPENGL_BIT and eglBindAPI(EGL_OPENGL_API) in display_helpers.cpp and if it works let me know
<alf_> greyback: (I want to stress again the "while still building mir against libGLESv2" part)
<greyback> alf_: sure
<MacSlow> Greetings!
<MacSlow> I'm constantly getting the error "libEGL warning: unsupported platform (null)" when trying to run a mir-client (using mir_demo_server_basic from lp:mir) on my desktop machine (ATI Radeon, driver: Gallium 0.4)
<MacSlow> I also tried passing EGL_PLATFORM=mir, but that doesn't fix it.
<MacSlow> starting a mir-client on this very system used to work just fine a couple of weeks ago.
<MacSlow> What changed in the required procedure to make that work?
<alf_> MacSlow: I don't think the error is related, we have been getting it forever (on working systems)
<MacSlow> alf_, I'll try some other clients just for cross-checking...
<alf_> MacSlow: How exactly are you are running the server and client, are you using you own build, or packages?
<MacSlow> alf_, hm... the egltriangle example from lp:mir works
<MacSlow> odd
<MacSlow> alf_, the mir-client I'm trying to get to work is the unity-system-compositor-spinner... which works fine on the phone (N4)
<MacSlow> alf_, guess i've to dig deeper
<MacSlow> How would one start a mir-client on a current UbuntuTouch image running the unity-system-compositor?
<alan_g> MacSlow: I think USC still exports a socket to the filesystem, so check you have +rw access and supply that via "-m"
<MacSlow> alan_g, sudo ./unity-system-compositor-spinner -m /run/mir_socket
<MacSlow> alan_g, is what I try to execute... but it fails and only spits out...
<MacSlow> Current active output is 2560x1600 +0+0
<MacSlow> Server supports 3 of 6 surface pixel formats. Using format: 1
<MacSlow> and then exits
<MacSlow> running mir-clients used to be a piece of cake some weeks ago
<alan_g> MacSlow:  ls -l /run/mir_socket?
<MacSlow> srwxrwxrwx 1 root root 0 Jul  4 16:50 /run/mir_socket=
<MacSlow> I just tried MIR_SOCKET=/run/mir_socket /usr/bin/unity-system-compositor-spinner
<MacSlow> which did not fail or exit... but the greeter is unresponsive to touch-inputs... I'm restarting the N10
<alan_g> MacSlow: how does a demo client behave? E.g. mir_demo_client_display_config -m /run/mir_socket
<MacSlow> alan_g, I've a way to test it... greyback suggested to kill lightdm/unity-system-compositor and start the mir_demo_server_shell
<MacSlow> alan_g, with that as basis it allows me to get my mir-client  running and visible
<alan_g> MacSlow: if you can work with mir_demo_server_shell it eliminate a bunch of code from the mix.
<MacSlow> hm... but oddly the locally compiled unity-system-compositor-spinner (from lp:unity-system-compositor) segfaults while the system-wide installed one does work
<alan_g> Are they built with the same compiler?
<alf_> MacSlow: alan_g: Confirmed, I get the same behavior
<alf_> MacSlow: ==9958== Invalid read of size 4
<alf_> ==9958==    at 0x50C5D60: cairo_surface_status (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11301.0)
<MacSlow> cairo_surface_status() crashes according to the backtrace
<alf_> ==9958==    by 0x4032FB: uploadTexture (eglspinner.c:150)
<alf_> ==9958==    by 0x403BA1: main (eglspinner.c:365)
<alf_> ==9958==  Address 0x1c is not stack'd, malloc'd or (recently) free'd
<alf_> MacSlow: cmake .. -DCMAKE_INSTALL_PREFIX=/usr
<alf_> MacSlow: it can't find the png file otherwise
<alf_> MacSlow: of course it should just print a nice error message instead of crashing :)
<MacSlow> alf_, I'll add something while I'm fixing the issue I initially wanted to address :)
<alan_g> dednick: any feedback on lp:~alan-griffiths/mir/spike-trusted-helper-socket? (I've MP'd it now)
<dednick> alan_g: hm. I was waying for tyhicks, but just realised that he's on holiday today. 4th July.
<dednick> s/waying/waiting
<MacSlow> greyback, alan_g, alf_: got all issues sorted out (on N10 and desktop) soaring away with the optimization for the spinner now... thanks!
<alf_> MacSlow: great, have fun :)
<greyback> good to hear
<alan_g> dednick: ack
<dednick> alan_g: he's back on monday
<alan_g> MacSlow: \o/
<alan_g> dednick: while that discussion might obsolete the approach I think we need something like this short term.
<dednick> alan_g: yes. i agree. I can try take a look at the MP this afternoon
#ubuntu-mir 2015-06-29
<duflu> Oooh, Jenkins now interprets gtest output
<duflu> https://jenkins.qa.ubuntu.com/job/mir-wily-amd64-ci/377/testReport/junit/(root)/MultiThreadedCompositor/recommended_sleep_throttles_compositor_loop/
<RAOF> Nice!
<duflu> greyback: Are there any tricks to click installing from the command line successfully?
<greyback> sudo click install --allow-unauthenticated --force-missing-framework --user=$USER ello.click
<greyback> duflu: my usual goto line ^^
<duflu> greyback: Ta
<greyback> pkcon install-local --allow-untrusted /path/to/click
<greyback> also supposed to work
<duflu> I believe greyback is a doc, but is he visiting another doc?
<greyback> duflu: visiting
<alf_> greyback: Hi (and welcome back)! I have started an effort to produce a Mir performance framework and sample benchmarks (see benchmarks/*.py , doc/performance_framework.md) in mir trunk
<greyback> alf_: Hey! Ok, I'll check that out
<alf_> greyback: The benchmarks need access to lttng tracepoints from Mir reports, and I was wondering if qtmir uses the compositor report
<greyback> alf_: it doesn't, but could
<alf_> greyback: if not, we should try to enable it as best as we can so that these benchmarks can be used directly with usc/unity8/qt clients if you want to
<greyback> understood
<alf_> greyback: thanks, please take a look (at your convenience, not urgent), and let me know of any feedback you have
<greyback> alf_: certainly. Quick skim of the key event test caselooks pretty great to me!
<alf_> greyback: I have been trying to write a similar test for touch/motion events, but I have been having trouble getting the input stack to accept my injected events...
<alf_> greyback: (the Mir input stack)
<greyback> alf_: I guess you know about umockdev-record
<alf_> greyback: hmm, no, I will into it, thanks!
<greyback> glad to help
<greyback> Anyone else use hte N10 recently? I see if screen tries to blank, it gets stuck in a white flash state
<racarr> Left my phone in a cafe quite some ways away yesterday so will be a while for lunch...
<racarr> finished off client specified input regions this morning...then thought about reviews on custom-input-regions-scale-with-surface-size
<racarr> I think I've been convinced the later isn't required...so ill fix things up after lunch and get that proposed
<racarr> and move on to deeper analysis of raw events.
<racarr> back!
#ubuntu-mir 2015-06-30
<greyback> anpok_: hey, any ETA on silo4 landing?
<greyback> hmm seems to be building with lots of failures, I'll assume it'll be a few days at least
<anpok_> greyback: yes
<anpok_> greyback: waiting on qtubuntu papi .. still need to port the older gtk+ used in vivid..
<alf_> anpok_: You said something about making the input stack treat the device as touchscreen instead of touchpad?
<anpok_> yes
<anpok_> the flags array that indicates the available keys (EV_KEY) needs the BTN_TOUCH bit to be set and the evdev properties array needs the DIRECT_TOUCH (or TOUCH_DIRECT?) to be set.
<alf_> anpok_: INPUT_PROP_DIRECT ?
<anpok_> ah yes
 * alf_ wonders where to use this with the evdev python bindings
<kdub> AlbertA, thanks for the vulkan video
<anpok_> there is a capabilities property
<anpok_> but that seems to be read only
<anpok_> alf_: but there is a chance that only setting BTN_TOUCH is enought (provided that the ABS_MT_POSITION_{X,Y} touch axes are configured)
<greyback> alf_: hey, when you launch mir with --vt=8, it correctly starts on vt8. But should it also switch the current vt to vt8?
<greyback> seb128: ^^
<seb128> thanks
<seb128> note that on that snappy image, for some reason the lightdm log has warnings like
<seb128> "Error using VT_ACTIVATE 7 on /dev/console: Inappropriate ioctl for
<seb128> device"
<greyback> hmm, sounds relevant
<seb128> so maybe that's the issue
<seb128> unsure why it's doing that though
<greyback> seb128: what hardware you using?
<seb128> snappy is using the standard distro/kernel
<seb128> inspiron 3000, all intel
<greyback> should be ok
<seb128> ubuntu standard doesn't have that issue
<seb128> unsure why
<seb128> or unsure why snappy has it
<seb128> it's the same software stack, just the image is built differently
<alf_> seb128: greyback: it should normally switch vts
<seb128> is there any log that could indicate why it fails it that's not working?
<greyback> seb128: is usc definitely being started after the lightdm x session? In case X is preventing the vt switch somehow (guess)
<seb128> I think so
<seb128> well, usc is not started before I try to log in as far as I can tell
<seb128> and logging in unity8 session doesn't start X, does it?
<greyback> nope
<greyback> well it shouldn't, unless something tries to spawn it
<attente> hi. when i run the mir_demo_server using the packaged version in W, mir-demos=0.13.3+15.10.20150617-0ubuntu1, the server just freezes up, no mouse input, no way to switch VTs
<AlbertA> attente: ummm... I just tried here in a haswell laptop, using W and same pkg version: "sudo mir_demo_server --vt 1" it worked ok for me
<AlbertA> attente: do you have a thread backtrace?
<attente> AlbertA: it doesn't crash, and there's very little on output on stdout/stderr
<attente> it's almost as if it doesn't respond to any input
<attente> including the vt switch shortcut
<AlbertA> attente: umm that can happen if you start the server without sudo
<attente> AlbertA: doh. thanks :)
<dandrader> I'm trying without success to print mir input log for unity8
<dandrader> should MIR_SERVER_INPUT_REPORT=log and MIR_SERVER_LEGACY_INPUT_REPORT=log still work?
<AlbertA> dandrader: they should
<dandrader> oh, wait! I think it did work!
<dandrader> AlbertA, sorry for the noise
<AlbertA> dandrader: no prob
<racarr> Howdy :)
<dandrader> racarr, so mir still uses android-input's EventHub and InputReader, right?
<racarr> dandrader: For now ;)
<dandrader> trying to get that detailed logging android-input has...
<racarr> dandrader: You have to enable it with the ifdefs in the files
<racarr> then ANDROID_LOG_TAGS=*:v
<racarr> MIR_SERVER_LEGACY_INPUT_REPORT=log
<dandrader> ahhhh!!!! missed the ANDROID_LOG_TAGS!
<racarr> It's so bad :( sorry
<dandrader> it's been ages since I last used it
<dandrader> racarr, thanks
<dandrader> racarr, all those android-input notifications of input devices coming and going etc they will be logged only by usc right? unity8 will get "high level" mir input events from usc like an app, right?
<racarr> dandrader: True, yeah...inputreader and eventhub shouldn't be used in U8
<dandrader> AlbertA, where does usc logs go?
<dandrader> not in .cache/upstart, right
<AlbertA> dandrader: they go into  /var/log/lightdm/unity-system-compositor.log
<dandrader> AlbertA, wow, would never find it. thanks!
<dandrader> AlbertA, do you know how to flush usc log messages? they don't appear in the log file as soon as they happen
<dandrader> AlbertA, so I have to touch the screen to get some more log happening so that the log file does get updated
<AlbertA> dandrader: I don't know. I usually just do tail -f
<AlbertA> messages show up fine....
<dandrader> AlbertA, that's what I'm doing. But the log file doens't get updated/written after every single message
<dandrader> AlbertA, only after a number of them have been written. and sometimes it even stops in the middle of a log line
<AlbertA> dandrader: ummm strange.. these are the android input stack message or everything?
<dandrader> AlbertA, android-input.
<dandrader> AlbertA, didn't enable other logging to tell
<AlbertA> let me see how they print
<dandrader> racarr, "[InputDispatcher]Dropping event because there is no focused window or focused application." <- this shouldn't ever happen, right?
<dandrader> racarr, in usc while unity8 is running
<racarr> dandrader: Hmm. I don't think it should no
<AlbertA> dandrader: so it goes through the mir logger which doesn't flush after every line so probably explains the behavior
<dandrader> AlbertA, thanks for looking into it. should I report a bug?
<dandrader> racarr, this happens when running autopilot tests. as they create a /dev/input/eventX file for the fake keyboard
<dandrader> racarr, the first time it works. but from the second time onwards it does not
<dandrader> racarr, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1468029
<ubot5> Launchpad bug 1468029 in unity8 (Ubuntu) "unity8 crash breaking autopilot tests entering text" [Critical,In progress]
<AlbertA> dandrader: yeah
<dandrader> AlbertA, https://bugs.launchpad.net/mir/+bug/1470204
<ubot5> Launchpad bug 1470204 in Mir "android-input logs are not flushed as soon as they happen" [Undecided,New]
<racarr> Trying to figure out what could be going on...
<racarr> dandrader: I dunno...unfortunately too a lot of relevant code to key focus selection was just replaced with the new input dispatcher
<racarr> unfortunately and or perhaps fortunately
<dandrader> racarr, at least it's easy to reproduce
<anpok> racarr: hi
<anpok> racarr: hm device introspection is kind of required for raw events because clients would observe/receive them per device rather then per surface?
<anpok> racarr: could also be someone not focusing the surface
<anpok> i mean .. there were more focus related changes in the past
<anpok> in usc..
<kgunn> racarr: so can i assign you to that bug ?
<kgunn> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1468029
<ubot5> Launchpad bug 1468029 in Mir "unity8 crash breaking autopilot tests entering text" [Critical,New]
<kgunn> it needs someone to love and care for it
<tedg> I'm getting a "std::exception::what: No appropriate client platform module found"
<tedg> How do I tell mir client what backend to use?
<tedg> Okay, fixed that.
<tedg> RAOF, So I seem to be starting Xmir, and it seems to be happy, but Unity8 isn't rendering anything. I don't think it's getting that first buffer swap.
<tedg> RAOF, What am I doing wrong? ;-)
 * tedg should be a talk show host.
<kgunn> racarr: i went ahead and gave that one to you
<racarr> kgunn: Oh you're back, I just sent you an email but, roger re:text crash bug
<kgunn> thanks racarr
<RAOF> tedg: Have you connected a client to XMir? It's not going to render anything unless a client renders.
#ubuntu-mir 2015-07-01
<tedg> RAOF, Yeah, I tried xeyes and xterm
<RAOF> Hm. They should trigger stuff.
<RAOF> Setting the MIR_CLIENT_RPC_REPORT=log environment variable might give a clue.
<tedg> Oh, wait. It rendered circles
<tedg> RAOF, http://paste.ubuntu.com/11802164/
<RAOF> Hm, that's not with MIR_CLIENT_RPC_REPORT set, is it?
<tedg> No, trying to set that now
<RAOF> tedg: I don't suppose you could try it *outside* a VM? You might simply be hitting a qxl bug.
<tedg> RAOF, Seems the same with that env var set?
<tedg> RAOF, Uhm, I don't have anything running wily on real HW.
<RAOF> Hm, it should spew at least some RPC log...
<RAOF> Softcock!
<tedg> Where would it? To stdout?
<tedg> Here is unity8 log: http://paste.ubuntu.com/11802196/
<RAOF> It should print to stdout, yeah.
<RAOF> tedg: You should get something like: http://paste.ubuntu.com/11802221/
<RAOF> Oh! Maybe you need to pass -verbose 7 to XMir; it might be doing stupid things with stdout.
<tedg> Let me try that, rebuilding.
<tedg> RAOF, (EE) Unrecognized option: -verbose
<RAOF> Gah, stupid bloody DDX split.
<RAOF> Why is -verbose not a core X option? Bah.
<tedg> RAOF, Got a new error in compwindow.c:488 http://paste.ubuntu.com/11802347/
<tedg> Turned on -rootless
<tedg> Same error with xterm as well.
<tedg> (first was xeyes)
<RAOF> Harumph.
<RAOF> tedg: Ok, so Xmir seems to work fine in mir_demo_server locally.
<tedg> So, then could it be Unity8 playing with us?
<tedg> It seems that I get a updateMirSurfaceSize and then a stopping
<tedg> old (1024,768) new (480, 376)
<tedg> Seems to be from the screen size 1024x768 to a window size
<RAOF> Hm, that's odd.
<RAOF> With rootless you shouldn't see the first; without rootless you shouldn't see the second.
<tedg> RAOF, So any recommendation on where to go with this? I feel like I'm starting things correctly, but it doesn't work.
<tedg> Not sure how to keep this moving forward.
<RAOF> I guess first check whether you can get Xmir working not-rootless in mir_demo_server. If that works, then it's something unity8 ish.
<RAOF> If it doesn't, that suggests a problem in qxl-glamor land.
<tedg> Well, I'm kinda at the integration point. I'm not sure anything I have would work really without Unity8
<RAOF> Urgh.
<tedg> Though, I mean, if you think it's likely to be an QXL thing, I'm happy to ship it.
<tedg> Just worry when the libertine container folks start to get to this point I'll have lied about its completedness :-)
<RAOF> It *could* be a qxl thing.
<RAOF> I guess you could also try deleting /usr/lib/x86_64-linux-gnu/dri; that should make Xmir drop into software-rendering-only mode.
<RAOF> Which would bypass any qxl bug.
<tedg> RAOF, That still got the compwindow.c:488 error
<RAOF> You're running not rootless?
<tedg> I am running with -rootless
<RAOF> I think -rootless will need a compositing window manager running in order to work.
<RAOF> Maybe?
<anpok_> oh we forgot to publish the mesa platform operations
<anpok_> hm
<anpok_> why does xmir require those
 * conyoo error parsing serv.dat
<anpok_> alf_: xmir used to do mir_connection_drm_auth_magic..
<anpok_> i changed that to a mir_connection_platform_operation
<anpok_> i think we have to publish mir_toolkit/mesa/platform_operation.h
<alf_> anpok_: it is in mesa-client-platform-dev
<alf_> anpok_: or rather, mir-client-platform-mesa-dev
<anpok_> oh, thx
<seb128> https://plus.google.com/u/1/+PopescuSorin/posts/GNRw5yjHEgF  shows qtcreator on mir ... does it mean we got multisurface handling in mir now? ;-)
<alf_> anpok_: Is there a way to turn off input resampling from the command line (env. variable or cmdline option) for a demo server?
<anpok_> yes
<anpok_> MIR_CLIENT_INPUT_RATE=0
<alf_> ah, so resampling is a client side operation?
<alf_> anpok_: ^^ ?
<anpok_> yes
<alf_> anpok_: Does it apply to both nested server and normal client? That is, should I set MIR_CLIENT_INPUT_RATE=0 in both?
<anpok_> and you can disable it for the nested server too
<anpok_> yes
<alf_> anpok_: thanks
<greyback> anpok_: ping
<anpok_> greyback: yip?
<anpok_> oh what a delay
<greyback> anpok_: hey I need a hand with something: lp:~unity-team/unity-system-compositor/toggle-cursor2
<greyback> anpok_: that should build against mir 0.13
<greyback> anpok_: I'm unable to make the TestCursorEnabler test pass, and I simply don't understand why
<greyback> I'm using mir::event::make_event to assemble a mouse event, but in the event handler, it's detected as a touch
<greyback> can you see my error?
<anpok_> you should store mir::EventUptr instead
<anpok_> because those events you create inside the test only live till the end of the expression
<anpok_> make_event returns unique_ptrs
<anpok_> hum how do I push a new branch with git to launchpad?
<anpok_> ah ok .. just git push rep branch..
<anpok_> greyback: and because of the way the allocator works in that case the memory pointed to by the event contained the data of the touch event
<greyback> anpok_: unique pointer deletes the MirEvent once it goes out of scope?
<anpok_> unique ptr has exclusive ownership
<anpok_> and when it dies .. it takes the object pointed to with it
<anpok_> so to keep it alive, you have to store it..
<anpok_> and unique_ptr is move only.. so you can never have a situation of shared ownership of two unique ptrs..
<greyback> anpok_: yep that was it, ta
<greyback> I got get() and release() confused ;)
<alber_m> hi, i'm trying to compile SDL2-2.0.2 with --enable-video-mir but i get this error: recive for target 'build/SDL_mirdyn.lo' failed
<alber_m> ../configure --disable-mir-shared --disable-video-opengl --disable-video-wayland --disable-video-x11 --enable-video-mir
<alber_m> am i doing something wrong?
<greyback> alber_m: can you shar ethe whole build log please, that's not much info to go on
<alber_m> :/ i can't copy on Xmir
<alber_m> i'm running xmir/firefox/irc
<alber_m> pff
<alber_m> i;m on wily
<anpok_> hm why did you disable-mir-shared?
<anpok_> alber_m: hm bschaefer would know better.. but he is not yet around
<greyback> anpok_: any idea where the mir branch for silo0 has gone?
<anpok_> nope
<anpok_> hmm
<anpok_> you want the up to date android multi monitor handling, and the override-orientation stuff?
<greyback> anpok_: mostly the override orientation stuff
<anpok_> i mean without the old android mm stuff..
<greyback> right
<guest1244> anpok_: i get the same error with or without --disable-mir-shared
<mcphail> alber_m: here's my instructions to build SDL on the phone platform. Might help in your quest: https://github.com/mcphail/ubuntu-touch-sdl-template/blob/master/lib/src/how_to_build_sdl_for_ubuntu_phone.txt
<anpok_> guest1244: which libmirclient  version are you building with?
<mcphail> anpok_: if you don't disable-mir-shared you get segfaults like this: https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1448544
<ubot5> Launchpad bug 1448544 in libsdl2 (Ubuntu) "[MIR] SDL_Init() crashes on the bq Aquaris E4.5 phone" [Undecided,New]
<anpok_> mcphail: oh looks broken.. maybe there was an abi break that was not detected.. because libsdl2 dynamically loads libmirclient
<mcphail> anpok_: I don't really understand what layer is broken, but know SDL plays nicely with libmirclient if the dynamic loading is disabled. bschaefer gave the tip
<mcphail> anpok_: don't know if it has been a new abi break - afaik it has )never_ worked
<anpok_> ah
<anpok_> s/ah/no clue/g .. that failue would make sense on top of mesa..
<mcphail> anpok_: note that I have not tried sdl with mir on anything but the phone
<anpok_> greyback: hmm do you really need the override-orientation branch?
<anpok_> greyback: oh for silo-0 we will still let usc display the cursor?
<greyback> anpok_: well if I can get it working quickly, it'll have to do
<greyback> mir is missing ability for unity8 to receive relative pointer coordinates
<greyback> which we need to have unity8 draw the cursor
<RAOF> Hey, vogons! Has anyone seen this failure before: https://jenkins.qa.ubuntu.com/job/mir-wily-amd64-ci/394/consoleFull
<RAOF> It seems that something in glib is leaking an fd created in GSourceHandle's destructor?
#ubuntu-mir 2015-07-02
<tsdgeos> guys any hint on what i may need to install? http://paste.ubuntu.com/11809663/
<kdub> tsdgeos, looks like its looking for a host server in a host/nested configuration
<tsdgeos> kdub: i'm trying to start unity8 from lightdm if that gives any hint
<racarr> kgunn: One more thing from me is I will be off monday morning...flying back from chicago :) in by the afternoon though
<kgunn> roger that
<kgunn> camako: ^
<anpok> racarr: another thought on raw input...
<anpok> given the client would subscribe to get events from raw input..
<anpok> what kind of filtering should the server do..
<anpok> i.e. like the client only receives events when focused ..?
<racarr> anpok: mm it only receives raw input for which it would receive the
<racarr> assosciated synthetic event
<anpok> ok
<anpok> http://blog.mattbierner.com/stupid-template-tricks-super-template-tetris/
<robert_ancell> kgunn, how do I land xorg-server into https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004?
<robert_ancell> anpok, what is the goal of that PPA?
<anpok> releasing mir 0.14.0
<anpok> and all the reverse dependencies that needs updates because of client abi/api breaks and server changes
<anpok> robert_ancell: dput the source package .. I believe..
<robert_ancell> anpok, the PPA description says not to upload directly to it, do I just ignore that?
<robert_ancell> Is this PPA on the CITrain somewhere?
<robert_ancell> oh, line 50 in the spreadsheet
<kgunn> robert_ancell: hmmm....so i think, you'd have to coordinate with a landing guide for ci train (e.g. robru or sil2100 or Mirv)
<kgunn> i think they have some special rights to upload to that ppa
<robert_ancell> so the spreadsheet says "xorg-server" in the additional source packages to land. Does that mean that they are approved and are outside of the normal landing procedure?
<kgunn> robert_ancell: well....yeah, that covers things that aren't in bzr (or things that are in bzr but are just syncing...but i digress)
<robert_ancell> kgunn, aha, sore point there ;)
<kgunn> robert_ancell: but the idea is that the ppa should have the pkg manually uploaded so that you can test the whole enchilada
<anpok> robert_ancell: yes... afaik only core devs and trainguards should upload..
<robert_ancell> anpok, ok, I'm core so I can just upload then
 * kgunn felt something go boom
<anpok> while compiling compile time tetris?
<robert_ancell> anpok, your changes require Mir 0.14 right? We should update configure.ac to check that
<anpok> oh right
<RAOF> Heh.
#ubuntu-mir 2015-07-03
<RAOF> Who'd object to a little helper class for passing std::funcition<> as a function pointer? :)
<RAOF> Only slightly terrifying.
<robert_ancell> RAOF, did you upload glmark2 directly to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004?
<RAOF> robert_ancell: I did, yes.
<robert_ancell> ok, cool
<robert_ancell> RAOF, and the vivid package goes to the overlay PPA when this landing is accepted?
<RAOF> Yeah, that's my understanding.
<robert_ancell> RAOF, so I just pushed the updated xmir in xorg-server into this PPA. What does this mean for the git branch for xorg-server?
<RAOF> robert_ancell: You should update the wily branch in git. And probably create a vivid-overlay branch, unless you've just uploaded the wily xorg to vivid.
<robert_ancell> RAOF, well, I can't upload this to wily because we don't have the new Mir there yet
<RAOF> But the landing PPA will be syncd to wily...
<RAOF> Maybe ask tjaalton what he'd like, though.
<robert_ancell> I was requested to put xorg-server in the landing. Don't know why we need it there..
<RAOF> I think we bumped client ABI, so it needs a rebuild at least.
<robert_ancell> yeah, but it would be easier to just do it post hitting wily
<RAOF> Yeah, but then untested code is hitting wily!!!!111111
<RAOF> Ah.
<RAOF> It's always helpful when exceptions are silently discarded, and the only visible result is that everything locks up...
<RAOF> *Of course* wayland buffer stride is in pixels, mir buffer stride is in bytes.
<duflu_> RAOF: I had a similar issue yesterday. Found a way for my client to make the server segfault but it was hidden. That's a regression of bug 1237332 that Alan intentionally made :(
<ubot5> bug 1237332 in mir (Ubuntu) "Fatal exceptions raised in a compositing thread have no usable stack trace" [Critical,Fix released] https://launchpad.net/bugs/1237332
<duflu_> Well, related bug
<duflu_> The problem is the "fix" for bug 1285084. We should not have fixed it at all.
<ubot5> bug 1285084 in Mir "Exceptions are raised in a compositing thread and not handled" [Undecided,Fix released] https://launchpad.net/bugs/1285084
<anpok_> hm could you also upload that for vivid?
<anpok_> robert_ancell: ^ that = xorg-server
<anpok_> or is the version different?
<robert_ancell> anpok_, I have been trying to but it keeps rejecting the upload. I think we have to give it a special version number so it doesn't complain about two versions.
<RAOF> Yeah, you can't upload the same thing to two different series.
<robert_ancell> ok, uploaded as 2:1.17.1-0ubuntu5~vivid
<duflu> If only there was a way to make libmirclient8 and libmirclient9 both official at the same time. Then most downstreams would not need updating immediately
<duflu> You can have both installed at once. Just not both in the distro at once, kind of, except for the release!=proposed period
 * RAOF wants to set fire to GLibMainLoop.
<RAOF> But will instead head to the shops.
<anpok_> hm we still could resurrect the asio loop
<RAOF> It's not *that* bad :)
<anpok_> duflu: scroll down.. there is predictive user input! http://blog.mattbierner.com/stupid-template-tricks-super-template-tetris/
<anpok_> well .. picking up idle tasks from dead instances..
<anpok_> provoking fancy invalid instruction crashes ..
<RAOF> Heh.
<anpok_> asio only has face palms and odd hand wavings..
<anpok_> </rant>
<duflu> asio is a four letter word. But seriously, I've never seen asio do anything worth using in production. It's generally terrible.
<duflu> Way over-complicated and not even documented in a way that makes it comprehendable
<duflu> My first encounter with asio was its regex library (which compiled to multiple megabytes and caused some compilers grief). So I replaced it with something 10kb in size
<duflu> Thus, asio is often and generally a joke
<duflu> A bad joke people keep telling
<RAOF> Anyone feel like adding some utility code for turning a std::function into a raw function pointer?
 * duflu needs to see the outside world for a little while at least once today
<anpok_> asio has no regex but .. i guess you mean xpressive .. which is very expressive..
<anpok_> RAOF: hm how raw?
<RAOF> anpok_: Passable-to-C raw.
<RAOF> It's perfectly possible if you don't mind generating the trampolines.
<anpok_> so .. void call_it(void*) ?
<duflu> anpok_: Sorry I meant boost is generally terrible. Asio is part of boost, no?
 * RAOF would just *really* like to be able to pass some bound member functions to a C interface.
<duflu> But asio is worse than the boost average even
<anpok_> hm it is simpler if you dont use std::function in between..
<RAOF> anpok_: Hm. Howso?
<anpok_> hm .. ok nah doesnt matter much because you have to pass in objects anyhow..
<anpok_> i just thought you could get away with encoding everything inside the type
<RAOF> I... don't think so?
<anpok_> ah you cannot move it
<anpok_> RAOF: http://paste.ubuntu.com/11814229/ something like that?
<anpok_> one could do it fancier if I knew how to extract the signature from a lambda
<anpok_> ... i.e. avoid the functio.. but on the other hand the c code does not take ownership of the function<..> so the creator needs to keep it alive.. and for that function seems to be a good pick
<RAOF> anpok_: Na, something more like http://paste.ubuntu.com/11814245/
<RAOF> Was what I was thinking of, but your simpler thing might be enough for what I'm considering.
<RAOF> And involves less runtime codepatching.
<anpok_> hm but you need the address somwhere.. unless of course if you squeeze the adress of the functio<>  into a symbol with external..
<anpok_> then it can be a template param..
<anpok_> *external linkage
<RAOF> No, no. It's simple. You have a static thunk with a placeholder guard value; you copy the code into memory your trampoline object owns, adjust the guard value to point to the std::function<> that your trampoline object owns, and then return that :)
<anpok_> hehe yeah simple
<RAOF> Not portable, of course, but the number of segmented memory architectures we care about can be counted on the fingers of one fish.
<anpok_> thats what encoding the address of the function into a template param would do..
<anpok_> function<>
<RAOF> Hm. How could you do that?
<RAOF> Or, at least do that in a way that doesn't require a type+external singleton per trampoline?
 * RAOF goes to get some fish.
<anpok_> RAOF: http://paste.ubuntu.com/11814351/ .. enough fun..
<greyback_> anpok_: ping
<anpok_> pong
<greyback_> anpok_: hey, need your help testing usc with your mir overrideorientation work. Can you check out lp:~unity-team/unity-system-compositor/toggle-cursor2/ please
<greyback_> I'm running it, and wanting to test the dbus method
<greyback_> (install qdbus-qt5)
<greyback_>  sudo qdbus --system  com.canonical.Unity.Screen / com.canonical.Unity.Screen.overrideOrientation 0 2
<greyback_> is the call I'm using. The first param is the display id, the second is the desired orientation
<greyback_> anpok_: aha, I'm an idiot
<greyback_> ignore me
<anpok_> greyback_: which channel do you use as a basis for silo-000
<greyback_> anpok_: rc-proposed
<anpok_> i guess I have to reflash
<anpok_> it is just getting hot while showing the logo
<ogra_> anpok_, MX4 ?
<anpok_> n4
<ogra_> oh
<anpok_> i guess it was my fault
<anpok_> .. dist-upgrade instead of citrain script .. or installing  them individually
<ogra_> yeah, the citrain script turns off access to the archive
<ogra_> so you only get PPA contents
<ogra_> if you do a normal dist-upgrade you will get archive bits along
#ubuntu-mir 2016-07-04
<miculou> hi all, how do you run apps on mir from the CLI?
<miculou> on unity8/desktop
<anpok> depending on the toolkit you have to set specific flags.. since they might find a DISPLAY env var.. so GDK_BACKEND=mir QT_QPA_PLATFORM=ubuntumirclient SDL_VIDEODRIVER=mir MIR_SOCKET=/run/user/YOU_USER_ID/mir_socket
<anpok> unset DISAPLAY..
<anpok> then depending on the applictation unsetting  QT_QPA_PLATFORMTHEME is also necessary
<anpok> oh and for unity8 to accept the connection of a starting application it needs to find a desktop file
<miculou> anpok: i'm trying to run supertux2 (sdl2 i think)
<ogra_> just look up ubuntu-app-launch ;)
<anpok> it gets either via ubuntu-app-launch or by looking at the command like parameter
<miculou> i tried both ubuntu-app-launch and -- --dektop_file_hint etc
<miculou> with ubuntu-app-launch i can see a windows + the loading spinner but then it closes
<miculou> and with -- it complains that the args are wrong wich they are
<miculou> i'm not even sure if the sdl2 in ubuntu has mir enabled, that's an option on compile.. i think? don't know very noob lol
<ogra_> it does
<miculou> DL_VIDEODRIVER=mir MIR_SOCKET=/run/mir_socket supertux2
<miculou> [FATAL] /build/supertux-7_Bg7b/supertux-0.4.0/src/supertux/main.cpp:444 Unexpected exception: Couldn't set video mode 1280x800: Failed to created a mir surface: Error processing request: An output ID must be specified
<miculou> Internal error details: /build/mir-NNwsqv/mir-0.23.2+16.10.20160624/sr
<miculou> i don't even know what i'm doing! :))
<anpok> you try to connect to a system compositor
<anpok> the system compositor only allows full screen clients (aka greeters/session shells)
<anpok> so try the mir_socket of the unity8 session instead..
<anpok> (/run/mir_socket is opened by unity-system-compositor)
<miculou> oh, i see, so this bit MIR_SOCKET=/run/user/YOU_USER_ID/mir_socket
<miculou> ?
<miculou> let's see
<anpok> yes .. should be 1000 in most desktop installations
<anpok> and if you launch it from a unity8 terminal .. you would not have to care about that part..
<miculou> DL_VIDEODRIVER=mir MIR_SOCKET=/run/user/1000/mir_socket supertux2
<miculou> [2016-07-04 15:21:24.099366] <ERROR> MirConnectionAPI: Caught exception at client library boundary (in release): /build/mir-NNwsqv/mir-0.23.2+16.10.20160624/src/client/rpc/stream_socket_transport.cpp(168): Throw in function virtual void mir::client::rpc::StreamSocketTransport::send_message(const std::vector<unsigned char>&, const std::vector<mir::Fd>&)
<miculou> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<mir::socket_disconnected_error> >
<miculou> std::exception::what: Failed to send message to server: Broken pipe
<miculou> 32, "Broken pipe"
<miculou> [FATAL] /build/supertux-7_Bg7b/supertux-0.4.0/src/supertux/main.cpp:444 Unexpected exception: Couldn't initialize SDL: Failed to connect to the Mir Server
 * ogra_ assumes the missing S in SDL_VIDEODRIVER is just a copy/paste error ?
<miculou> yep
<attente> is there a way to change the output scale factor on the mir demo server?
<anpok> attente: hm not yet..
<anpok> i mean we could add an example server that does that.. or a client that reconfigures the desired content scaling
<attente> anpok: how did you test your MirSurfaceOutputEvent patch? did you use a hi-dpi monitor?
<anpok> attente: printf... only..
<attente> anpok: but is there some way to trigger a MirSurfaceOutputEvent?
<anpok> on recent mir servers you should get one after creating the surface
<anpok> and then when you move the surface over to a different output
<anpok> hmm I am afk for 2.5 hours.. I think I can come up with some test client to play with the scale value
#ubuntu-mir 2016-07-07
<alan_g> alf: I've updated https://code.launchpad.net/~alan-griffiths/miral/rework-titlebars/+merge/298637 - still happy with it?
