[00:11] <bregma> so, I'm hacking up a Unity8 session for the desktop, and now I'm stuck with Mir throwing an exception  what():  Failed to create GBM buffer object ... any ideas what to persue with this?
[00:12] <RAOF> bregma: I always end up gdbing that, and catching the exception to see what's broken.
[00:13] <bregma> problem is there's other exceptions thrown in the stack as a means of regular control flow (shame!) so it's a pain to trace during the login session startup
[00:13] <RAOF> What? Where are our exceptions-as-control-flow?
[00:13] <RAOF> Oh.
[00:13] <RAOF> Yeah. In UdevWrapper?
[00:14] <RAOF> AKA: my code

[00:15] <bregma> no, it's somewhere in one of the Unity8 libraries
[00:15] <bregma> processing config files, throws an exception at end of file just like Java does

[00:16] <bregma> anyway, my problem comes from a gbm_bo_create() failed call, which sounds like perms mayve?
[00:16] <RAOF> Quite possibly.
[00:16] <RAOF> Although I thought that would break earlier.
[00:17] <bregma> well, this is nested mir-on-mir, everything is baby steps
[00:49] <robert_ancell> bregma, is there anything else you need from me for Unity 8 session work?
[00:49] <bregma> robert_ancell, I'm not sure, but I'm using your lightdm branch and at least that works OK
[00:49] <robert_ancell> cool
[00:50] <bregma> I seem to be stuck on this gbm_bo_create() fail without a clue, though
[00:53] <RAOF> What's the callstack?
[00:57] <bregma> http://paste.ubuntu.com/6753595/
[00:58] <bregma> no debug symbols because it's installed from a PPA hashtag sadface
[01:00] <RAOF> Ah, ok.
[01:00] <RAOF> At least it isn't trying and failing to allocate a hardware cursor buffer or something.
[07:12] <RAOF> Hm. Has anyone tied Alan's in_process_server?
[07:13] <RAOF> Or even tried it; I'm easy :)
[07:18] <RAOF> EOD
[07:39] <duflu> RAOF: Should I know about that? Was it announced anywhere?
[08:00] <didrocks> kgunn: hey, reverted your approval (see the commits)
[08:00] <didrocks> comments*
[08:01] <kgunn> didrocks: sorry...comments where ?
[08:01] <didrocks> kgunn: Mir MP you just approved
[08:01] <kgunn> didrocks: ah..i see
[08:02] <didrocks> kgunn: I saw IS told the firewall is opened, I need to test those, but I can get someone from your team piloting the new process as soon as tomorrow I guess (my tomorrow)
[08:02] <didrocks> do you know who should be this "lander" ?
[08:02] <kgunn> didrocks: ok...so new process i get that...but
[08:03] <kgunn> i'm confused about changelog...i thot we _did_ want to list all the changes
[08:03] <kgunn> ?
[08:03] <didrocks> kgunn: yeah, for the current release
[08:03] <didrocks> not for an older one
[08:03] <didrocks> see, there are two stenzas that was added in debian/changelog
[08:03] <kgunn> didrocks: ah...ok...so remove the second stanza in changelog and we are all good ?
[08:04] <didrocks> one for current release
[08:04] <didrocks> +mir (0.1.4-0ubuntu1) UNRELEASED; urgency=medium
[08:04] <didrocks> and one for  mir (0.1.3+14.04.20140108-0ubuntu1) trusty; urgency=low
[08:04] <didrocks> yeah, just remove the modification for 0.1.3+14.04.20140108-0ubuntu1
[08:04] <kgunn> didrocks: as for "lander"...what capabilities does that person need ?
[08:04] <kgunn> didrocks: i would recommend duflu if you do it in the morning hours...and then alan_g or alf_ in euro time...
[08:05] <didrocks> kgunn: rigourness, tracking of failures. Of course, being in a compatible timezone will help
[08:05] <didrocks> but I agree duflu sounds the best to me
[08:05] <didrocks> I just need to ensure that we can catch up in the morning so that we can discuss the process and I can show him how this works :)
[08:07] <kgunn> duflu: you still on ?....can would you mind quickly just removing the 0.1.3 ref from the debian changelog as mentioned by didrocks above ?
[08:07] <kgunn> (i gotta pay attention to the room)
[08:47] <duflu> kgunn: Sorry, had a birthday visitor, and plumber digging up the pavement. Simultaneously
[08:48] <kgunn> duflu: sounds awesome :)
[08:48] <kgunn> duflu: and now my confidence is shattered after i read the rejection based on missing 2kloc from my MP :)
[08:48] <kgunn> which...i still can't figure why that happened...
[08:49] <duflu> kgunn: Seems to have come from some pre-0.1.4 revision.
[08:49] <kgunn> i know...i was really careful...
[08:50] <kgunn> but then again, those were bzr repos, which i thot i pulled correctly to, but who knows...
[08:50] <kgunn> old local bzr repos that is
[08:52] <duflu> didrocks: The old changelog for 0.1.3 is wrong. Are you sure we want to keep it?
[08:52] <kgunn> ^ i agree with duflu ...the one in there is more descriptive
[08:53] <didrocks> duflu: yeah, you don't rewrite history, it's like if you uncommit, change content commit and push --overwrite
[08:53] <duflu> Or do we just need to restore "Automatic snapshot..." ?
[08:53] <duflu> didrocks: Even if it's wrong? What use the changelog if it's not accurate? :)
[08:53] <duflu> ^os
[08:53] <duflu> ^is
[08:54] <didrocks> duflu: it's published all over the place, and you are changing it
[08:54] <didrocks> you need to be careful before publishing it, not after :)
[08:54] <didrocks> and don't change history
[08:54] <duflu> didrocks: OK...
[08:55] <didrocks> duflu: do you think that tomorrow morning, we can try doing that piloting for the new release process? probably a hangout or anything like that will be easier
[08:55] <duflu> didrocks: It was the robot/script that got it wrong I think
[08:55] <didrocks> (my morning)
[08:55] <didrocks> duflu: well, it's because your process didn't follow with your second trunk, what we support
[08:55] <duflu> didrocks: Sure
[08:55] <didrocks> but that's going to be fixed ;)
[08:55] <didrocks> ok, let's do that, I'll ping that
[08:55] <didrocks> you*
[08:56]  * duflu still likes "bzr pull :push"
[08:59] <duflu> didrocks: changelog fixed
[08:59] <didrocks> duflu: thanks, will get it merged as per tomorrow training
[08:59] <kgunn> thanks guys
[14:39] <fginther> greyback, ping
[14:40] <greyback> fginther: pong
[14:41] <fginther> greyback, do you have some time to discuss the mir testing you asked about last week?
[14:41] <greyback> fginther: sure
[14:42] <fginther> greyback, this is for a physical desktop hardware test right?
[14:44] <greyback> fginther: these tests need to run on devices where mir runs
[14:44] <fginther> greyback, ok, so touch devices and desktop
[14:45] <greyback> fginther: yep
[14:46] <greyback> fginther: so this is for the unity-mir project
[14:47] <greyback> tsdgeos: can you show fginther what test we want to run - I'm about to eod
[14:47] <tsdgeos> sure
[14:48] <tsdgeos> fginther: there's a package called libunity-mir-tests or something
[14:48] <tsdgeos> fginther: inside it there's a binary called unity-mir-test-app
[14:49] <tsdgeos> just run that one
[14:49] <fginther> tsdgeos, ok, are there any specifics about how the test system should be provisioned, or is installing the test package sufficient
[14:50] <greyback> fginther: we're just getting started off with unity-mir tests, so please advise us on how to structure/change things
[14:50] <tsdgeos> fginther: i would hope that installing it should be enough
[14:50] <fginther> Most of our test runners are setup to install packages on top of a fully provisioned system, run the test command, then collect the junitxml result files
[14:51] <tsdgeos> that should work
[14:51] <tsdgeos> unity-mir-test-app should accept the -oxml thing
[14:51] <tsdgeos> to give you junitxml output
[14:52] <tsdgeos> -o filepath,xunitxml
[14:52] <tsdgeos> to be more precise
[14:53] <fginther> tsdgeos, if you have those execution details, can I ask that you create a bug under https://bugs.launchpad.net/ubuntu-ci-services-itself/+bugs to track this?
[14:53] <tsdgeos> sure
[14:54] <fginther> tsdgeos, also, in may be a lot easier to get a touch test working for this, would it be helpful to you if that were ready before the desktop test, or do both need to be ready at the same time?
[14:54] <tsdgeos> fginther: i actually was thinking device only :D
[14:55] <tsdgeos> so yeah, no need to have them at the same time
[14:55] <tsdgeos> just trying to boostrap the thing
[14:56] <fginther> tsdgeos, I can't make any promises on when this will be ready, but I'll try to get started on it this week
[14:56] <tsdgeos> cool
[14:56] <greyback> fginther: tsdgeos: thanks!
[14:57] <fginther> greyback, you're welcome
[16:13] <tsdgeos> fginther: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1269485 is enough?
[16:21] <fginther> tsdgeos, thanks
[19:28] <bregma> racarr, got a minute to help with a Mir input issue?
[19:30] <racarr> bregma: Hey. Let me try! What's up?
[19:30] <racarr> I am making tea but will be back in like...2 min
[19:31] <bregma> I have Unity8 running on Mir on my desktop, but no input seems to work ... is there a good way to approach debugging this (like maybe an environment variable to dump debug info to stderr)?
[19:32] <bregma> oh, umm, I'm using a laptop with a touchscreen, so at least that should work I would think
[19:33] <racarr> lets start with MIR_SERVER_INPUT_REPORT=log and MIR_SERVER_LEGACY_INPUT_REPORT=log
[19:33] <racarr> bregma: ^
[19:33] <racarr> first thing to check is of course permissions
[19:33] <racarr> user can't read from /dev/input
[19:34] <bregma> racarr, OK, sounds like a good start ... gotta reconfigure and reboot
[19:35] <bregma> /dev/input/* is all root:root
[19:38] <racarr> areyourunning u8 as user? You definitely wontget input then
[19:38] <bregma> wait, Unity8 doesn't support being used?
[19:39] <bregma> that doesn;t sound too sleable
[19:40] <bregma> how does Unity8 work on the phone then?
[19:44] <racarr> I think...we put user in some group that can read /dev/input
[19:44] <racarr> I think
[19:44] <racarr> the proper solution involves lightdm
[19:44] <racarr> no one ever explained it to me but it must be like
[19:44] <racarr> lightdm and upstart and fd passing
[19:45] <racarr> I guess we need that for the desktop preview
[19:46] <bregma> mmm, I can ping RobertAncell later
[19:47] <racarr> yes lets ask him.
[19:47] <racarr> I think that's the short story though
[19:59] <bregma> racarr, I manually set the permissions on /dev/input/*(a+rw, for the lulz) and set those env vars, I see motion events being logged now, but no response from Unity8 .. any suggestions?
[19:59] <bregma> [1389815848.590785] (II) input: Published motion event seq_id=147 time=1389815848590506000 (0.264998 ms ago) dest_fd=54
[20:10] <racarr> bregma: Hmm...
[20:11] <racarr> nowits hard tosay, I tried unity8 on desktop not so long ago and input was working when I ran it as root (basically what you did)
[20:11] <racarr> anything even a little interesting in the logs?
[20:11] <racarr> Could it be related to this laptop touchscreen?(Does anything elsework)
[20:11] <bregma> Unity7 works just dandy
[20:12] <bregma> like I say, I see the motion events in the Unity8 log, but there seems to be a piece missing
[20:15] <bregma> I see 'UbuntuKeyboardInfo - socket error: "QLocalSocket::connectToServer: Invalid name"' as well
[20:15] <bregma> in case that's any help
[20:16] <bregma> latest log: http://paste.ubuntu.com/6758171/
[22:04] <dandrader> bregma, about the "UbuntuKeyboardInfo" error. that's unity8 trying to talk to ubuntu-keyboard (the virtual keyboard daemon on phablet)
[22:04] <dandrader> but, naturally, this daemon is not available on desktop
[22:04] <bregma> naturally
[22:04] <bregma> yet
[22:08] <dandrader> bregma, as for input debugging, you can check what's happening at the next layer,  the qpa (qtubuntu), where mir events are transformed into qt ones
[22:09] <bregma> dandrader, that's the information i was missing
[22:09] <bregma> I'm using the ubuntumirserver QPA
[22:10] <dandrader> qtubuntu is a bit of a maze as classes there have deep inheritance trees
[22:10] <dandrader> (could be easily flattened, btw)
[22:11] <dandrader> bregma, the file you want to look at there is src/platforms/base/input.cc
[22:11] <bregma> aptly names
[22:12] <dandrader> bregma, you can set #define LOG_EVENTS to 1 there and build it with CONFIG+=debug to get a lot of output
[22:12] <dandrader> bregma, the place where that translation (mir -> qt) of input events happens is QUbuntuBaseInput::dispatchMotionEvent
[22:12] <kdub> racarr, i'm tinkering with the 4.4-based ubuntu touch... not getting input though, any quick checks/fixes I can do?
[22:13] <dandrader> EOD
[22:15] <bregma> gah, evidently Mir does not work with the latest libgl1-mesa-dri because of missing symbols ... the fun never stops
[22:20] <racarr> kdub: MIR_SERVER_LEGACY_INPUT_REPORT=log might help
[22:20] <racarr> um maybeit relates
[22:20] <racarr> to the device configuration file stuff
[22:21] <bregma> failed to open /usr/lib/x86_64-linux-gnu/dri/i965_dri.so: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so: undefined symbol: _glapi_tls_Dispatch (unity-system-compositor.log)
[22:22] <racarr> woah its a party now
[22:23] <racarr> kdub: they end in like .idc and were in android_root/system/devices
[22:23] <racarr> InputDevice.cpp l89
[22:23] <racarr> just a guess though
[22:23] <racarr> will think more am expectingmylandlord and bug inspector at any moment
[22:23] <racarr> bug exterminator