[00:00] <racarr> RAOF: You just need to switch the scheduling policy on your brain.
[00:00] <racarr> Of course, that could bring down the whole system so it's not allowed under the controlled substances act...
[00:03] <thomi> RAOF: got a second?
[00:10] <RAOF> thomi: Sure.
[00:10] <thomi> RAOF: just writing this autopilot test for u-s-c, what's the best way of determining the graphics chipset in use?
[00:10] <thomi> RAOF: also, Didier's email seemed to say that we should only be running u-s-c on intel chipsets?
[00:10] <RAOF> How specific are we about "in use"?
[00:11] <RAOF> ie: hybrid graphics, what should we report?
[00:11] <thomi> RAOF: I don't know... I guess you'd know better than me
[00:11] <thomi> the test is to determine whether we're actually running u-s-c on supported hardware
[00:13] <RAOF> glxinfo | grep renderer (in XMir) is not-terrible
[00:13] <thomi> RAOF: I guess IO could do something like run "lshw -class display" and parse the output
[00:14] <thomi> RAOF: OK, so under what situations should we be running u-s-c?
[00:14] <RAOF> Everywhere that isn't proprietary driver.
[00:14] <RAOF> Oh, and not on virtual hw, or crazy old stuff like SiS.
[00:15] <thomi> RAOF: so, how do I determine "not on proprietary driver"?
[00:15] <thomi> or "not on virtual hardware"?
[00:15] <thomi> I'm wondering if it's better to whitelist suppoorted hardware, or to blacklist unsupported hardware
[00:15] <RAOF> If i915.ko, radeon.ko, or nouveau.ko are loaded.
[00:15] <thomi> ahh, ok, that's much easier
[00:16] <thomi> thanks!
[00:16] <RAOF> Acutally, that'll miss some hybrid systems.
[00:17] <RAOF> You actually want to make sure that each VGA device in lspci | grep VGA has its associated driver loaded.
[00:17] <RAOF> So, if there's an nvidia device in lspci | grep VGA, then nouveau.ko is loaded, itc.
[00:17] <RAOF> etc.
[00:18] <thomi> hmmmm, that sounds harder to do exhaustively
[00:19] <RAOF> lspci -vvv, parse it out, check that "Kernel driver in use: " is the right thing.
[00:20] <thomi> RAOF: OK, but presumably there's edge cases when matching device -> driver? or do we really only care about those three cases: intel, nvidia & ati?
[00:21] <RAOF> Only those three cases.
[00:21] <thomi> ok, sweet
[00:22] <RAOF> If there's an intel VGA device (identifiable by 8088 pci id), then it must have i915 loaded; if there's an nvidia device, it must have nouveau loaded, likewise ati.
[00:22] <thomi> awesome, thanks for your help.
[00:22] <thomi> Going to lunch now, will get this finished when I get back.
[00:24] <RAOF> Arse. This kernel is built with debug symbols, making it 700 MB, or significantly larger than my boot partition. Poot.
[00:45] <xnox> ... chain-load?!
[00:46] <xnox> boot of usb?! =)
[00:48] <racarr> RAOF: Sounds like the second reason today to switch to FreeBSD
[01:15] <RAOF> Surely GNU/Hurd!
[02:01] <thomi> I don't suppose anyone here has a machine with a radeon graphics chipset?
[02:02] <thomi> RAOF: perhaps you have one?
[02:02] <RAOF> thomi: I do.
[02:03] <RAOF> What can I do for yoU?
[02:03] <thomi> RAOF: any chance you could send me the output of 'lspci -vvv' on that machine please?
[02:03] <thomi> or maybe just the section for the VGA device
[02:10] <RAOF> http://paste.ubuntu.com/5886137/ (and with -n, which you should probably use so you can match on PCIID )
[02:11] <RAOF> http://paste.ubuntu.com/5886140/
[02:12] <RAOF> thomi: ^^^
[02:14] <thomi> RAOF: thanks
[02:14] <RAOF> You'll notice this is a hybrid system, so a good test :)
[02:53] <thomi> RAOF: what's the best way to determine if xmir is running? simply "pgrep unity-system-compositor" ?
[02:54] <thomi> or is there some better way that you can think of?
[02:57] <RAOF> Two options; pgrep unity-system-compositor or grep xmir /var/log/Xorg.$(echo $DISPLAY | sed s/://g).log
[02:58] <thomi> RAOF: I don't like the log file apprach, it seems a bit fragile to me... but I'm having trouble getting pgrep to do what I want :(
[02:58] <thomi> ahh yes, I remember
[02:58] <thomi> pgrep cuts process names
[02:58] <thomi> so "pgrep unity-system" works, "pgrep unity-system-compositor" will never return anything :(
[02:59] <RAOF> You could also check the args used to spawn /usr/bin/X; if they contain “-mir ”, then it's XMir.
[03:03] <duflu> robert_ancell: What's you're preferred medium? :)
[03:03] <duflu> Oh
[03:22] <thomi> robert_ancell: got a second?
[03:25] <robert_ancell> thomi, otp
[03:26] <robert_ancell> thomi, sure
[03:26] <robert_ancell> thomi, are you checking from inside X or outside it?
[03:26] <thomi> robert_ancell: https://code.launchpad.net/~thomir/unity-system-compositor/add-autopilot-test/+merge/175444
[03:27] <thomi> robert_ancell: I'm hoping we can get didier to do the packaging for us?
[03:27] <robert_ancell> thomi, what packaging is required?
[03:27] <thomi> robert_ancell: autopilot tests are usually packaged into <appname>-autopilot
[03:27] <thomi> package
[03:28] <thomi> so in this case, unity-system-compositor-autopilot
[03:28] <robert_ancell> thomi, and that's part of the u-s-c source package? I can do that
[03:28] <thomi> yes
[03:28] <thomi> awesome - I can package python modules, but packages where it's half Cmake, half python build systems confuse me
[03:29] <robert_ancell> thomi, what is an existing package I can look at?
[03:29] <thomi> robert_ancell: lp:unity8 has one
[03:30] <thomi> as does lp:unity, and any of the phone apps
[03:30] <thomi> usually I'd point dh at the setup.py file in tests/autopilot, but I'm not sure how you do that in a mixed package?
[03:31] <robert_ancell> thomi, because it's all python we just make a debian/unity-system-compositor-autopilot.install file and update debian/control. I'm doing a merge now
[03:31] <thomi> awesome, thanks
[03:33] <thomi> I thought it was more complicateed than that, but OK :)
[03:38] <robert_ancell> thomi, was there a reason for unity_system_compositor over unity-system-compositor?
[03:38] <thomi> robert_ancell: yes, you can't have '-' in module names
[03:44] <robert_ancell> thomi, https://code.launchpad.net/~robert-ancell/unity-system-compositor/add-autopilot-test-packaging/+merge/175446
[03:45] <thomi> will merge now
[03:47] <thomi> robert_ancell: OK, those changes are now in my branch. Will email the list so didrocks reviews it
[04:26] <robert_ancell> kdub, still here?
[04:42] <robert_ancell> thomi, did you want didrocks to specifically review https://code.launchpad.net/~thomir/unity-system-compositor/add-autopilot-test/+merge/175444?
[04:42] <thomi> robert_ancell: yes
[04:43] <thomi> robert_ancell: Standard procedure is that his team review any packaging changes for stuff that's being daily-released
[04:43] <robert_ancell> thomi, oh, I forgot to say, you probably want to add something to the Depends line in debian/control for the test
[04:43] <thomi> robert_ancell: otherwise it's too easy to release broken packages into distro
[04:43] <robert_ancell> I'm not sure which packages it needs
[04:43] <thomi> robert_ancell: oh, good point, thanks :)
[04:43] <robert_ancell> thomi, can you add a specific review request for him? Otherwise when I review it it will not be pending on him
[04:44] <thomi> sure
[04:44] <robert_ancell> (and then I'll forget and just approve it)
[04:45] <thomi> done and done
[04:59] <RAOF> I hope this doesn't hit the thermal trip point...
[05:03] <tvoss_> good morning :)
[05:04] <RAOF> Good morning
[05:05]  * RAOF wonders if packaging thermald would be a useful way of attempting to make this laptop less likely to emergency-shutdown due to hitting the thermal trip point.
[05:28] <duflu> RAOF: What? Ubuntu doesn't already come with sane sensors monitoring?
[05:31] <didrocks> thomi: hey, still around?
[05:31] <thomi> didrocks: yo yo
[05:31] <didrocks> thomi: just looking at MP ;) So I think we need another tests: if we are not on a open source driver, ensuring unity-system-compositor doesn't run
[05:32] <didrocks> thomi: of installing autopilot tests, I prefer having a setup.py and some hack in debian/rules, do you want me to propose a branch with that?
[05:32] <thomi> didrocks: sure, that's trivial, one second
[05:32] <didrocks> thomi: something similar than unity8 if you want to do it (setup.py in the autopilot directory) and in debian/rules, see my call to setup.py
[05:33] <didrocks> then dh --with python2 and build-dep on python
[05:33] <thomi> didrocks: ugh, I had that initially, and robert_ancell removed it
[05:33] <thomi> didrocks: can I ask you to do the packaging for me? Pretty please?
[05:33] <didrocks> thomi: sure sure, incoming!
[05:33] <thomi> I'll buy you a beer next time we meet :)
[05:33] <didrocks> heh, \o/
[05:35] <tvoss_> didrocks, for the armhf test hangs ...
[05:35] <tvoss_> did you see Stephen's mail?
[05:35] <didrocks> tvoss_: hey, yeah, read it
[05:36] <tvoss_> didrocks, so one way would be for us to come up with a custom TEST macro (TEST_WITH_REQUIREMENTS) that checks if android runtime is present and disables the test if not automatically
[05:37] <tvoss_> didrocks, what do you think?
[05:38] <didrocks> tvoss_: sounds the right way to me, do you have any way to tests that we are running with android? like detecting a file is present?
[05:38] <tvoss_> didrocks, we could try to resolve symbols from the platform api
[05:38] <thomi> didrocks: actually, I'll make this test case test both scenarios
[05:38] <didrocks> thomi: that's fine as well, just change the name then :)
[05:39] <tvoss_> didrocks, essentially taking the cause of the error as check
[05:39] <didrocks> thomi: platform-api will tell "not on android"?
[05:39] <didrocks> tvoss_: because platform-api will be installed, right, so platform-api symbols will be there
[05:40] <tvoss_> didrocks, fair point ... hmmm, we need a way to force the backend instantiation and report an error if something is missing ...
[05:41] <didrocks> tvoss_: couldn't platform-api have this check?
[05:41] <didrocks> like a platform-run call to know where we are running on?
[05:41] <didrocks> (just a silly proposal :p)
[05:42] <tvoss_> didrocks, hmmm ... let me think about it for a bit
[05:44] <didrocks> thomi: ok, the longer was to readd the ppa to install libmirserver-dev ;) here we are, do you want a MP against your branch? (it's just one commit): lp:~didrocks/unity-system-compositor/autopilot-packaging-fixes
[05:45] <thomi> didrocks: nah, I'll just merge it in, thanks!
[05:45] <didrocks> thomi: yw ;)
[05:45] <thomi> didrocks: just finished the test as well
[05:45] <didrocks> great :)
[05:45] <didrocks> RAOF: hey, did you see that xorg-server is lower than distro? are you planning on updating it?
[05:45] <didrocks> RAOF: I thin I can't run the autopilot tests because of that, right?
[05:46] <mlankhorst> sec
[05:47] <didrocks> https://launchpad.net/~mir-team/+archive/staging/+copy-packages still times out :/
[05:47] <thomi> didrocks: your changes have been merged in, and the new test is pushed.
[05:47] <didrocks> thomi: excellent! looking at the testing part, you want a second review from robert_ancell I guess as well?
[05:48] <thomi> didrocks: if he's still here
[05:48] <thomi> didrocks: otherwise I think we're good to merge
[05:48] <thomi> what could possibly go wrong!? :P
[05:48] <didrocks> thomi: heh, indeed! ;)
[05:48] <mlankhorst> RAOF: pushed
[05:49] <didrocks> thomi: sounds perfect to me with those changes, +1 ;)
[05:49] <didrocks> I'm now adding it to the tests to run
[05:51] <didrocks> done
[06:10] <tvoss_> didrocks, https://github.com/ros-infrastructure/buildfarm/issues/87
[06:11] <didrocks> tvoss_: but, the buildds (not the virtualized builders) are now running with qmenu? Not sure of the latest, but from last news I got, they were still running on bare metal
[06:12] <tvoss_> didrocks, hmmm, good question ... checking with #is
[06:13] <RAOF> didrocks: Yes, I was planning to update xorg-server. Just after mlankhorst pushes 1.14.2-0ubuntu1 to git :)
[06:14] <RAOF> duflu: Ubuntu *does* have sane sensors monitoring, but thermald does intel-specific tricks.
[06:15] <mlankhorst> it's all you now, stop hiding behind me :P
[06:15] <duflu> RAOF: Cool. In fact cooler the better
[06:15] <RAOF> mlankhorst: Ta
[06:15] <didrocks> RAOF: I can't copy package to the daily-build-next and next ppas :/
[06:16] <RAOF> didrocks: I'm updating now.
[06:16] <didrocks> RAOF: I can't add the staging ppa, because different version of Mir and unity-system-compositor (with versions higher than daily-build-next/next)
[06:16] <didrocks> RAOF: do you think I should just reupload to daily-build-next them?
[06:16] <didrocks> mesa + xorg*
[06:18] <RAOF> I'm not sure what you're asking.
[06:18] <didrocks> RAOF: basically, I need mesa + xorg* copied in daily-build-next ppa
[06:18] <didrocks> (I can't add staging because of mir/unity-system-compositor version mistmatch)
[06:18] <RAOF> Right. And for that we need an xserver that's newer than the archive.
[06:18] <didrocks> RAOF: I wanted to binary copy your packages, but https://launchpad.net/~mir-team/+archive/staging/+copy-packages times out constantly for me
[06:19] <RAOF> Really? I've been happily copying packages from staging for a while.
[06:19] <didrocks> RAOF: is it timeouting for you?
[06:19] <RAOF> How many packages are you trying to copy?
[06:19] <didrocks> RAOF: well, I can't even display https://launchpad.net/~mir-team/+archive/staging/+copy-packages
[06:20] <RAOF> didrocks: Yes.
[06:20] <RAOF> I can happily load that page .
[06:20] <didrocks> urgh, not me, not yesterday, no today :/
[06:20] <didrocks> RAOF: hum, do you mind copying that yourself to daily-build-next?
[06:20] <RAOF> Odd.
[06:20] <didrocks> RAOF: I can add you to the team
[06:20] <RAOF> Yeah, sure.
[06:20] <didrocks> thanks a bunch :)
[06:20] <RAOF> Just mesa + the X packages that you need, right?
[06:21] <didrocks> RAOF: exactly! to https://launchpad.net/~ubuntu-unity/+archive/daily-build-next
[06:22] <RAOF> And once Mir has landed in Universe I can just add the xmir patch to our regular xserver git, and all will be well.
[06:22] <didrocks> RAOF: you need Mir to be landed in Universe? xmir depends on Mir?
[06:22] <didrocks> not the other way around?
[06:23] <mlankhorst> RAOF: no
[06:23] <mlankhorst> RAOF: mir needs to be in main for that depends
[06:23] <RAOF> mlankhorst: Oh, yeah, quite true.
[06:23] <RAOF> didrocks: Yes, indeed. XMir depends on libmirclient.
[06:23] <didrocks> ok, which is the stable API part :)
[06:24] <RAOF> Correct.
[06:24] <didrocks> RAOF: I think Mir entering main isn't an issue, I know an archive admin who as well reviewed and fixed the packaging for Main :p
[06:36] <RAOF> Faster, laptop, faster!
[06:40] <alf_> RAOF: Are you sure you want to push your thermally challenged laptop so hard? ;)
[06:41] <RAOF> I've chocked it up, and the kernel build has finished. It's only 65℃ now :)
[06:44] <tvoss_> ffs, why does swithcing to a guest session fix the input lag issue?
[06:44] <tvoss_> s/input lag/output lag
[06:45] <RAOF> Hm. Does that suggest a Mir platform?
[06:46] <tvoss_> RAOF, ?
[06:46] <RAOF> Because that's switching surface focus.
[06:46] <tvoss_> RAOF, it does ... let me check something
[06:47] <RAOF> Notably, it *doesn't* stop X from rendering, unless Mir blocks it.
[06:49] <tvoss_> RAOF, yup
[06:50] <RAOF> Does u-s-c block mir_surface_swap_buffers block when a surface isn't focused?
[06:50] <tvoss_> RAOF, checking exactly that
[06:51] <tvoss_> robert_ancell, ping
[07:06] <duflu> RAOF: It shouldn't block for obvious compositing reasons, but it does due to https://bugs.launchpad.net/mir/+bug/1188486
[07:12] <tvoss_> RAOF, might that be the reason that a switch to the guest session "aligns" things again?
[07:12] <RAOF> Plausibly.
[07:13]  * RAOF wanders through the code while Mesa builds.
[07:14] <duflu> ... it's a general problem Mir has with unfocused clients getting paused. They shouldn't get paused, obviously
[07:15] <duflu> At least not by default
[07:16] <tvoss_> duflu, agreed, it should be a policy
[07:18] <dholbach> good morning
[07:22] <tvoss_> woot, no more second cursor :)
[07:27] <duflu> tvoss_: So now just try to VT switch to tell if you're in Mir ;)
[07:27] <tvoss_> duflu, fair :) but htop tells me I'm in mir
[07:28] <tvoss_> wow, only one cursor ... this is so mainstream
[07:30] <duflu> It's so 20th century
[07:33] <tvoss_> duflu, exactly
[07:33] <tvoss_> duflu, my mind feels bored now ...
[07:33] <pete-woods> morning guys!
[07:34] <pete-woods> I just tried running mir in a VM
[07:34] <pete-woods> and it doesn't seem to start
[07:34] <pete-woods> is this expected for the moment?
[07:35] <tvoss_> pete-woods, yup
[07:35] <tvoss_> pete-woods, what vm are you trying?
[07:36] <pete-woods> tvoss_: it's parallels - it has a fantastic pass-through GLX driver
[07:36] <pete-woods> obviously I've uninstalled that for trying out Mir
[07:37] <pete-woods> so I was expecting it to run with fbdev/llvmpipe like X11 does
[07:37] <tvoss_> pete-woods, we need a driver capable of gbm/drm/kms
[07:37] <duflu> pete-woods: It is planned, but not implemented yet
[07:38] <pete-woods> tvoss_, duflu: no worries guys, is this something we'd be trying to have ready for 13.10?
[07:39] <duflu> pete-woods: We will be trying yes, but I don't believe it's on the critical list
[07:39] <tvoss_> pete-woods, exactly what duflu said. The easiest way for us would be if the vm offers the required driver functionality and an XMir integration
[07:39] <pete-woods> duflu: that's fair enough - I'm really just a very interested party here
[07:40] <duflu> pete-woods: https://bugs.launchpad.net/mir/+bug/1118903
[07:43] <RAOF> Oooooh.
[07:43] <RAOF> Hm.
[07:43] <tvoss_> RAOF, ?
[07:44] <RAOF> So, because threading and X is a world of pain, we push events through a pipe.
[07:45]  * tvoss_ listens excitedly to RAOF
[07:45] <RAOF> Which obviously happens asynchronously.
[07:46] <RAOF> But that's ok, because we register the pipe as a general socket, and have a wakeup handler.
[07:48] <RAOF> So, what happens is we receive the buffer on a thread. We push this through the pipe, which wakes up the server if it's not already busy...
[07:49] <RAOF> So what I should check is whether we should *also* be registering a BlockHandler to check the pipe before the server goes into select.
[07:49] <RAOF> Although my understanding is that it should just immediately wake up.
[07:50] <RAOF> But first, Zoë bath.\
[07:53] <robert_ancell> didrocks, ah, I was looking at an out-of-date version of unity8 which didn't have setup.py
[07:53] <robert_ancell> tvoss_, hellp
[07:54] <robert_ancell> hello
[07:54] <didrocks> robert_ancell: be on the edge! (yeah, it's something I fixed) :-)
[08:10] <tvoss_> robert_ancell, you running in XMir?
[08:10] <robert_ancell> tvoss_, not this very second
[08:10] <tvoss_> robert_ancell, I've got a patched libmirserver package that disables input for the usc and the second cursor
[08:11] <tvoss_> robert_ancell, need some mileage to make sure that the lag does not show up anymore
[08:11] <robert_ancell> tvoss_, I never remember noticing the lag
[08:11] <tvoss_> robert_ancell, weird
[08:14] <tvoss_> robert_ancell, still, some mileage would be great :)
[08:15] <robert_ancell> tvoss_, email me the link
[08:15] <tvoss_> robert_ancell, the package :)
[08:16] <robert_ancell> tvoss_, just send the branch, it will be easier to compile here
[08:16] <tvoss_> robert_ancell, not a branch yet, patched the src package from the system compositor testing ppa
[08:16] <robert_ancell> tvoss_, don't you build from the branch?
[08:17] <tvoss_> robert_ancell, nope, I did an apt-get source libmirserver0 and patched the package, it's really a hack right now, would need to be handled in usc and shouldn't go into mir at all
[08:18] <robert_ancell> tvoss_, so can't you just do a bzr branch, make the change, commit and push somewhere?
[08:23] <tvoss_> robert_ancell, https://code.launchpad.net/~thomas-voss/mir/disable-input-by-default
[08:23]  * tvoss_ notes that this is hacky and should be cleanly done in the unity-system-compositor server configuration
[08:33] <robert_ancell> brb
[08:37] <didrocks> RAOF: do you mind telling me once everything is copied so that I can run the tests?
[08:37] <RAOF> didrocks: Sure
[08:37] <didrocks> thanks!
[08:39] <RAOF> Hm. Where did my xorg-server upload disappear to?
[08:42] <didrocks> RAOF: never heard about the launchpad black hole? ;)
[08:42] <RAOF> Ah. sacuy ≠ saucy :(
[08:42] <tvoss_> RAOF, :)
[08:42] <didrocks> RAOF: so close, should have worked! :-)
[09:11] <alan_g> tvoss_: ping
[09:11] <tvoss_> alan_g, grabbing coffee :) mind opening a hangout and inviting me, would like to use the ipad
[09:12] <alan_g> tvoss_: ack
[09:15] <tvoss_> alan_g, can you call again please?
[09:16] <robert_ancell> tvoss_, I'm still seeing a similar delay
[09:16] <tvoss_> robert_ancell, hmmm, is that a new issue for you? you said you haven't seen it before, right?
[09:17] <robert_ancell> tvoss_, now I try it I do remember it
[09:17] <robert_ancell> but I tried both, and I'm not seeing any major difference
[09:18] <RAOF> didrocks: Everything's in the PPA now; enjoy.
[09:18] <didrocks> RAOF: \o/ I'll for sure, thanks!
[10:46] <alan_g> \o/ networking and cursor now working again on my laptop
[10:49] <katie> tvoss_, ping
[10:55] <tvoss_> katie, pong
[10:56] <katie> tvoss_, hi. are we having our meeting in 5 mins?
[10:56] <tvoss_> katie, if you want to, yes. I still owe you a review, though. Anything urgent to discuss?
[10:57] <katie> tvoss_, i do have a couple of general questions, so yes, would still like a quick chat
[10:57] <tvoss_> sure
[10:57] <tvoss_> can you invite me to the hangout then?
[10:57] <katie> sure, thanks
[11:28] <alan_g> alf_: are you happy to top approve move-graphicsplatform-dependencies-to-graphics-less-contentious?
[11:29] <alf_> alan_g: sure,
[11:30] <alf_> alan_g: do you want me to do it?
[11:33] <alan_g> alf_: that would make me happy too
[11:35] <alan_g> Oh! /o\ only *wireless* and g3 networking is working. Laptop still doesn't do wired networking.
[11:42] <alf_> alan_g: (done)
[11:45]  * duflu wanders off dazed
[11:46] <alan_g> duflu was still up?! No wonder he's dazed
[11:59] <alan_g> alf_: just looking at gl_pixel_buffer.cpp and see a runtime test "is_big_endian()" - shouldn't that be detected at compile time?
[12:07] <alf_> alan_g: We could, although ARM CPUs are bi-endian, but I am not sure if this is a scenario we have to care about.
[13:13] <didrocks> kgunn: hey, around?
[13:34] <kgunn> didrocks: yeah
[13:35] <didrocks> kgunn: so, I have a good news and a bad news :)
[13:35] <didrocks> kgunn: good news is that the tests failing were finally flacky tests it seems
[13:35] <didrocks> the bad news is that with thomi's script, we have the confirmation that mir isn't running
[13:36] <didrocks> https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/501/
[13:37] <didrocks> can be a config issue, but would be better to debug with someone knowing how lightdm runs unity-system-compositor
[13:49] <mterry> kgunn, hi
[13:49] <mterry> ahem
[13:49] <kgunn> mterry: hey...your here :)
[13:50]  * kgunn suffering irc ping-tsunami
[13:51] <kgunn> mterry: so didrocks having  u-s-c/mir failing to start on his autopilot daily release testing
[13:52] <kgunn> wondered if you've tinkered enough to have a look
[13:52] <kgunn> https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/501/
[13:52] <mterry> couldn't hurt...
[13:52] <kgunn> didrocks: how to get the log files off that machined?
[13:53] <kgunn> didrocks: we'd need the usual suspects in /var/log/lightdm
[13:53] <didrocks> kgunn: we have them
[13:53] <didrocks> mterry: hey hey! :)
[13:53] <didrocks> mterry: one sec, just grabbing my coffee ;)
[13:54] <kgunn> didrocks: please don't scare mterry :))
[13:54]  * mterry runs into the brush
[13:54] <didrocks> kgunn: I've scared hum for many years now you know :p
[13:54] <didrocks> first on the OEM side, he was taking unity from my packaging
[13:54] <didrocks> I think he was scared from that date :p
[13:55] <didrocks> s/hum/him/
[13:56] <kgunn> didrocks: actually i should ask...have you simply done a subsequent reboot on that machine ?
[13:57] <kgunn> bschaefer & robotfuel were seeing yesterday that
[13:57] <kgunn> on a few machines xmir wouldn't come up after initial dist-upgrade
[13:57] <kgunn> but then after second reboot it would
[13:57] <kgunn> and then it was fine thereafter
[13:57] <mterry> didrocks, so I see two failures,  test_running_hardware_check and a 'unity_system_compositor' test
[13:58] <mterry> Oh, maybe those are the same
[13:58] <didrocks> mterry: they are, on the 2 configs :)
[13:59] <didrocks> kgunn: in fact, we install the packages before lightdm starts
[13:59] <mterry> didrocks, but I don't see the /var/log/lightdm stuff in the archive.zip file
[13:59] <didrocks> mterry: ok, so in the log, you can see http://10.97.4.139/otto/saucy-i386-20130718-1122
[13:59] <didrocks> mterry: I: Archive of the container to run this test available for download from:
[13:59] <mterry> oh man, ok
[14:00] <didrocks> mterry: we can collect lightdm logs in the next run if needed
[14:00] <didrocks> mterry: this is simple config file
[14:00] <didrocks> kgunn: can you tell, I'll be 5 minutes late?
[14:00] <didrocks> mterry: here, you have in archive/ all the delta from the base image
[14:00] <didrocks> (it's an overlayfs)
[14:01] <didrocks> as in the logs:
[14:01] <didrocks> I: Run archived as ubuntu_13.10_saucy_salamander_alpha_i386_20130718.1374153658.otto
[14:01] <didrocks> mterry: so you want http://10.97.4.139/otto/saucy-i386-20130718-1122/archive/ubuntu_13.10_saucy_salamander_alpha_i386_20130718.1374153658.otto I guess
[14:01] <didrocks> mterry: this is just a tar, untar it (for some reason, file-roller doesn't like that it's ending up with .otto)
[14:01] <mterry> didrocks, .otto is weird, yah  :)
[14:01] <didrocks> and you should have all the delta from the base image
[14:02] <kgunn> didrocks: ack
[14:02] <didrocks> mterry: because the archive can be use to rerun the same tests on your machine
[14:02] <didrocks> :)
[14:02] <didrocks> it has some metatada ;)
[14:03] <didrocks> we are using lightdm from distro FYI
[14:03] <didrocks> which is enough from what robert told
[14:05] <kgunn> didrocks: lightdm from distro...yeah
[14:05] <kgunn> it better be :) that's what his instructions say
[14:26] <mterry> didrocks, well, I downloaded/unpacked the logs and the error we get from u-s-c is:
[14:26] <mterry> ERROR: /build/buildd/mir-0.0.7+13.10.20130718ubuntu.unity.next/src/server/graphics/gbm/gbm_display_helpers.cpp(284): Throw in function int mir::graphics::gbm::helpers::DRMHelper::open_drm_device(const mir::graphics::gbm::helpers::UdevHelper&)
[14:26] <mterry> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
[14:26] <mterry> std::exception::what: Error opening DRM device
[14:26] <mterry> [boost::errinfo_errno_*] = -13, "Unknown error -13"
[14:26] <mterry> So...  didrocks, looks like you have an unknown error.
[14:26]  * mterry goes home
[14:27] <didrocks> mterry: thanks! that's helpful :)
[14:28] <mterry> didrocks, more seriously, I haven't run into an error opening DRM device before
[14:28] <didrocks> jibel: do you think it's linked to lxc? ^
[14:28] <mterry> racarr, ^ is that error familiar to you?
[14:29] <didrocks> mterry: we are running in a lxc container with otto, it's working fine with acceleration for compiz & others
[14:29] <didrocks> mterry: but maybe this has influence
[14:30] <mterry> didrocks, maybe a permission error on some udev device in the container?
[14:30] <jibel> didrocks, it is possible, it is what I reported to thomi last week
[14:30] <didrocks> mterry: yeah, if you use more than what is used
[14:30] <didrocks> mterry: any idea what's under used?
[14:30] <didrocks> use*
[14:30] <mterry> didrocks, I didn't parse that
[14:31] <didrocks> mterry: do you know exactly which udev device you need?
[14:33] <mterry> didrocks, not exactly...  something inside /dev/drm/card[0-9] or some such, looking at code
[14:33] <didrocks> jibel: do you think we should get stgraber as well to help?
[14:34] <jibel> mterry, which job did you get this message from?
[14:35] <didrocks> jibel: 501
[14:35] <didrocks> /var/log/lightdm
[14:35] <didrocks> (from the archive)
[14:43] <mterry> kdub, do you know more about the above error message? ^
[14:45] <didrocks> mterry: is is that hidden in the code?
[14:47] <didrocks> :)
[14:47]  * didrocks tries to branch mir to look as well
[14:49] <mterry> didrocks, well, it just enumerates some devices and errors out if problems
[14:49] <mterry> didrocks, so hard to see what's the exact issue by looking at code
[14:49] <didrocks> mterry: yeah, I wonder how we can debug that, I'm sure it's lxc/udev in lxc which doesn't authorize the right dev/
[14:50] <mterry> didrocks, build a version with better debugging?  strace it?
[14:50] <didrocks> mterry: do you want debug symbols? :)
[14:50] <didrocks> I can have that for you!
[14:51] <mterry> didrocks, not symbols but just printfs saying what it is doing
[14:51] <mterry> but stracing would likely be easier
[14:51] <mterry> just insert that into the jenkins job
[14:51] <didrocks> mterry: you can get access to the machine if needed
[14:51] <didrocks> by ssh
[14:51] <didrocks> and running inside the container
[14:51] <didrocks> if that's easier than hacking the jenkins job
[14:51] <mterry> or wherever it launches u-s-c
[14:51] <mterry> didrocks, maybe, ok
[14:51] <jibel> mterry, I need to know which device it is trying to access to to see if there are missing privileges, or apparmor blocking access, or a module mismatch, ...
[14:52] <didrocks> jibel: strace will indeed help, as mterry mentionned
[14:53] <didrocks> mterry: to run unity-system-compositor, we can do that without any X, just starting from a login prompt, right?
[14:55] <mterry> didrocks, I think so...?
[14:56] <mterry> didrocks, I already have ssh access?
[14:56] <mterry> which machine?
[14:56] <didrocks> mterry: from magners, it's ssh ubuntu@dx-autopilot-intel
[14:56] <didrocks> mterry: but we're going to restart the container with this install for you :)
[14:57] <didrocks> mterry: just need to hack to not have the tests running and the machine staying up
[15:41] <sil2100> racarr: hi!
[15:44] <didrocks> mterry: so
[15:44] <mterry> didrocks, OK, so trying in container, we get mir running
[15:44] <didrocks> we tried to shutdown the machine
[15:44] <mterry> unlike on jenkins
[15:44] <didrocks> and just restart it
[15:44] <didrocks> mterry: well, unlike on the first attempt as well
[15:44] <didrocks> mterry: like, when you joined
[15:45] <didrocks> we restarted it
[15:45] <didrocks> and there was the error
[15:45] <didrocks> and so, the fallback was running
[15:45] <didrocks> it's just since you get it working once that now it's ok
[15:45] <mterry> My work here is done!
[15:45] <didrocks> :p
[15:45] <didrocks> I didn't follow with the pings on IRC, but…
[15:46] <didrocks> did you change anything in /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf ?
[15:47] <mterry> didrocks, I commented my change back out
[15:47] <didrocks> yeah, that's why we see
[15:47] <didrocks> can it be a race?
[15:47] <mterry> didrocks, but if you want to run with strace, uncomment the line in there
[15:50] <didrocks> mterry: see!
[15:50] <didrocks> mterry: just restarted
[15:51] <didrocks> it's on your plate \o/\o/\o/
[15:51] <mterry> didrocks, OK.  Now if we restart lightdm, do we expect to see this error again?
[15:51] <didrocks> so, more seriously, seems there is a race
[15:51] <didrocks> I bet we won't
[15:51] <didrocks> mterry: want to try?
[15:51] <mterry> Hmm
[15:51] <mterry> didrocks, OK.  And if it fails, let's add strace, then restart.  Or will that wipe out the config change?
[15:51] <didrocks> mterry: no, that will keep the config change
[15:51] <didrocks> so yeah, let's do that :)
[15:52] <mterry> ok, restart worked-ish
[15:52] <mterry> didrocks, OK, how to restart?
[15:52] <didrocks> (I just rechecked)
[15:53] <didrocks> mterry: just shutdown (like that)
[15:53] <didrocks> then it archives :p
[15:53] <didrocks> (my fault)
[15:53] <didrocks> see the lxc-start command
[15:54] <sil2100> racarr: (here as well) ping
[15:54] <didrocks> mterry: it's running, jibel restarts
[15:55] <mterry> didrocks, sorry, wasn't watching byobu when that all happened :)
[15:56] <didrocks> mterry: ok, restarted
[15:56] <didrocks> so it's running again
[15:56] <didrocks> strace should slows the start enough :/
[15:57] <mterry> ok, let's see that log
[15:57] <mterry> didrocks, it looks like it worke
[15:58] <mterry> didrocks, so yeah, race condition?
[15:58] <didrocks> mterry: right, I'm sure strace slows it down enough :/
[15:58] <mterry> didrocks, well...  file a bug and add a sleep 1 in meantime?  :-/
[15:59] <didrocks> mterry: like sleep && unity-system-compositor in the conffile?
[15:59] <didrocks> sleep 1*
[16:00] <racarr> sil2100: Pong
[16:01] <racarr> Dentist soon sorry but im around for next 30 minutes
[16:01] <mterry> didrocks, yeah, that could work
[16:03] <sil2100> racarr: priv then!
[16:06] <mterry> didrocks, I looked away, did the sleep work?
[16:07] <didrocks> mterry: we are trying first to see how many times it fails
[16:07] <didrocks> it's really random
[16:07] <mterry> didrocks, hmm..  also, for testing sleep, probably better to test higher value than 1 in case that's not enough time
[16:07] <mterry> didrocks, I'm going to grab lunch
[16:08] <didrocks> mterry: well, we need to have that merged in unity-system-compositor package as long as we don't fix the race :/
[16:08] <didrocks> so I'm afraid about the value we would put here
[16:09] <didrocks> we tried with cold cache, without any difference
[16:09] <didrocks> (it worked the first time)
[16:13] <didrocks> ok, without sleep, it started 7 times on 10 trials
[16:13] <didrocks> kgunn: FYI ^
[16:21]  * kgunn read most of the scrollback
[16:21]  * didrocks feels sorry for kgunn
[16:21] <kgunn> didrocks: so sleep seems to fix it, otherwise 70% working..."randomly"
[16:21] <didrocks> kgunn: no, we are trying sleep for now
[16:21] <kdub> mterry, that error (from way up in the /sb) didn't mean anything obvious to me either
[16:21] <didrocks> and the syntax doesn't support it
[16:22] <didrocks> we are trying to have a shell calling unity-system-compositor with a sleep
[16:22] <kgunn> didrocks: so at this very moment you are testing for the reliability of sleep (e.g. u-s-c sleep 1)
[16:23] <kgunn> ?
[16:23] <didrocks> kgunn: yeah, with no interesting value right now (we have 100% failures)
[16:24] <kgunn> didrocks: sorry still confused by your last statement "no interesting value"...what is value ? and didn't you say even w/o sleep you get 70% working ? what config is failing 100% ? (sorry if i am slow minded :)
[16:25] <didrocks> kgunn: 70% working -> call with no config
[16:26] <didrocks> 0% working with the sleep, but still trying
[16:26] <kgunn> didrocks: bummer
[16:28] <kgunn> didrocks: and by failure we mean...xmir doesn't launch, but rather fallsback to standalone x
[16:28] <didrocks> kgunn: right
[16:28] <kgunn> (just confirming that is _still_ the failure mode)
[16:28] <didrocks> no unity-system-compositor (so no xmir) running
[16:28] <didrocks> kgunn: yeah, we tested well the fallback work
[16:28] <didrocks> it's working :)
[16:28] <didrocks> (that's the bright side :p)
[16:29] <kgunn> bregma: bschaefer ^ just fyi...mterry helping, but good to know...have you seen this recently on any of your reboots ?
[16:29] <didrocks> kgunn: FYI, 50% working without any sleep on another test run
[16:29] <kgunn> e.g. xmir not starting but falling back to x
[16:30] <bschaefer> kgunn, with a recent update? Or the same problem as yesterday?
[16:30] <didrocks> kgunn: sleep 1 seems to be a "better" value: 90% passed (on 10 runs)
[16:31] <kgunn> bschaefer: oh yeah...duh...this is identicle to robotfuel's isn't it....
[16:31] <bregma> I have never had u-s-c fail to start on reboot on my test machine
[16:31] <didrocks> kgunn: sorry, no, not the sleep 1, just no sleep but embedding it in a shell
[16:31] <didrocks> trying with sleep 1 on 10 runs now
[16:31] <didrocks> it's clearly a race anyway…
[16:31] <bschaefer> interesting either way ...
[16:31]  * kgunn wonders....no one ever sees this locally....wondering about kvm monitors
[16:32] <didrocks> kgunn: do people notice you think?
[16:32] <kgunn> didrocks: hard to miss the giant-ass mouse missing
[16:32] <kgunn> :)
[16:33] <didrocks> kgunn: indeed ;) but you know… at least, having a case we can reproduce the race is good
[16:33] <kgunn> didrocks: sure....its just we've had suspicions about the kvm monitors about other things
[16:34] <didrocks> kgunn: hum? this is running on bare metal
[16:34] <didrocks> we are connected directly to ssh on it
[16:34] <kgunn> didrocks: oh...really, so this is a machined hooked to a normal monitor ? (or embedded lcd)
[16:34] <didrocks> kgunn: we can remove the kvm daemon, but it's not in the hook at all
[16:35] <didrocks> we are in a ssh connexion directly connected to it, not using kvm
[16:36] <kgunn> didrocks: who is "We" & "it"....i guess, i'm trying to get at, is there a display phyically connected to the processor running u-s-c (or attempting to)
[16:36] <kgunn> ?
[16:37] <didrocks> kgunn: we == jibel and I right now
[16:37] <didrocks> we are connected by ssh to the machine
[16:37] <didrocks> and start/stop lightdm
[16:37] <didrocks> there is a display physically connected to it
[16:37] <didrocks> but in lexington
[16:37] <kgunn> didrocks: got it...
[16:37] <didrocks> so a little bit far for us to look at it :)
[16:37] <kgunn> theory busted
[16:37] <didrocks> right
[16:38] <didrocks> ok, another run with sleep .1
[16:38] <didrocks> -> 100% pass on 10 trials
[16:38] <kdub> would people be ok if we had mir_init_display_info(DisplayStruct*); mir_get_display_info(DisplayStruct*); mir_destroy_display_info(DisplayStruct*); in the client api?
[16:38] <didrocks> kgunn: so, to be able to move on this… what do you think we should do?
[16:38] <kgunn> didrocks: \o/ ....for sleep 1 or .1 (typo or not)
[16:38] <kgunn> ?
[16:39] <didrocks> kgunn: sleep .1 (no typo)
[16:39] <kgunn> you add to the u-s-c conf file right ?
[16:40] <didrocks> no, u-s-c config doesn't support && apparently :/
[16:40] <didrocks> so we call unity-system-compositor.sleep, which is a shell script, with sleep .1; unity-system-compositor
[16:40] <didrocks> and call unity-system-compositor.sleep from u-s-c conf file
[16:40] <didrocks> kgunn: I just want to be able to give you one set of test results with xmir enabled
[16:41] <didrocks> not sure if you want to go that ugly way then ^
[16:42] <kgunn> didrocks: seems there's enough proof there we know what that issue is....and it should permit more testing
[16:42] <kgunn> so that would be fine (as it shouldn't alter anything but the startup)
[16:42] <didrocks> kgunn: so, you want me to MP it?
[16:44] <kgunn> didrocks: yes...i think so, we know its a dirty hack....we'll have an assoc bug to fix it
[16:44] <kgunn> not that we have a nice repro capability
[16:45] <kgunn> bschaefer: what was the pass/fail experience you had yesterday with robotfuel ?
[16:45] <kgunn> was it on the order of 70% ?
[16:45] <bschaefer> kgunn, you mean ChrisGagnon?
[16:45] <kgunn> yes
[16:45] <bschaefer> right, umm sorry was a bit confused :)
[16:45] <kgunn> bschaefer: ^
[16:46] <bschaefer> he was hitting it pretty commonly
[16:46] <bschaefer> i never asked percentage, and I couldn't reproduce it on my machine
[16:46] <bschaefer> kgunn, I would say greater than 50% though
[16:47] <bschaefer> err greater than 50% passing
[16:47] <kgunn> bschaefer: even better
[16:47] <kgunn> bschaefer: oh...then about the same
[16:47] <bschaefer> kgunn, but he'll have a better grabs on the numbers :)
[16:48] <bschaefer> I only asked about 3-4 machines, but it seemed like he could get a failing one pretty fast
[16:48] <kgunn> bschaefer: this little work around will at least unblock him
[16:48] <bschaefer> awesome, adding that .1 sleep in?
[16:48] <kgunn> bschaefer: yep
[16:48] <bschaefer> interesting, i remember lightdm having a racing problem before...
[16:48] <bschaefer> when the machine was super fast, but it could be a different issue :)
[16:49] <kgunn> didrocks: to make sure i understand....sleep 0 = 70% pass, sleep 1 = 0% pass, sleep .1 = 100% (10 runs each)
[16:50] <didrocks> kgunn: between 50-70% for no sleep
[16:50] <didrocks> kgunn: now, shell with sleep .1: 100% pass
[16:50] <bschaefer> sounds about right (with sleep 0 that is)
[16:50] <bschaefer> didrocks, awesome :)
[16:50] <didrocks> kgunn: sleep 1: 100% as well (it was a test issue)
[16:50] <didrocks> but let's keep .1, it's working
[16:51] <kgunn> didrocks: cool....better....that was gonna freak me out
[16:51] <didrocks> bschaefer: well, not that awesome TBH :p
[16:51] <bschaefer> didrocks, well its an odd workaround, but still a workaround for now
[16:51] <bschaefer> and you found a way to 100% reproduce :)
[16:51] <didrocks> bschaefer: no, 30% reproduce the failure (without any sleep) :p
[16:52] <bschaefer> oo I see it was a test issue
[16:53] <didrocks> kgunn: https://code.launchpad.net/~didrocks/unity-system-compositor/add-dirty-sleep/+merge/175633
[16:53] <didrocks> kgunn: I'm opening the bug
[16:53] <kgunn> didrocks: there's one already open
[16:54] <didrocks> ah, url?
[16:54] <kgunn> https://bugs.launchpad.net/xmir/+bug/1201565
[16:54] <bschaefer> was it htis one: https://bugs.launchpad.net/xmir/+bug/1201565
[16:54] <bschaefer> opps :)
[16:54] <didrocks> kgunn: hum, doesn't seem to be that one
[16:55] <didrocks> we don't have unity-system-compositor running, not unity
[16:56] <kgunn> bschaefer: hmmmm, did we morph this bug on accident...are there really 2 bugs ? or did the unity problem actually go away...
[16:57] <bschaefer> kgunn, hmm IIRC, that but above was about u-s-c not running, or really just a symptom...
[16:57] <bschaefer> didrocks, which problem were you looking at?
[16:57] <didrocks> bschaefer: unity-system-compositor doesn't run
[16:57] <didrocks> and so, we fallback to legacy X
[16:57] <didrocks> the bug title you have is unity crashing under xmir
[16:57] <bschaefer> didrocks, right, thats what that bug is about, as u-s-c doesn't run which was causing unity to now run...
[16:57] <didrocks> bschaefer: but xmir doesn't start even
[16:58] <didrocks> bschaefer: which is what the bug seems to be about
[16:58] <didrocks> and here, we fallback to traditional xorg
[16:58] <bschaefer> didrocks, right, xmir wans't starting either...but you can't have xmir with u-s-c right?
[16:58] <didrocks> and unity is running
[16:58] <bschaefer> didrocks, well I never actually saw the problem happening...it was on a VM somehwere
[16:58] <bschaefer> or a machine somewhere
[16:58] <didrocks> bschaefer: your bug is mentionning a crash in unity, which isn't the case here
[16:59] <didrocks> kgunn: I would suggest keeping the bug separated and see where we can get for more clarity, thoughts?
[16:59] <bschaefer> didrocks, right... ChrisGagnon is on lunch atm sooo he would be the one I would poke ...
[16:59] <robotfuel> didrocks: rebooting seems to help starting xmir
[16:59] <didrocks> robotfuel: we did reboot by a set of 10 times multiple times
[17:00] <kgunn> i gotta run
[17:00] <bschaefer> didrocks, though the overall problem with that bug was u-s-c was not starting, and on a second reboot it would start...
[17:00] <kgunn> iterviewing
[17:00] <didrocks> bschaefer: why is is associated with xmir then?
[17:00] <didrocks> bschaefer: xmir even doesn't start at this level
[17:00] <bschaefer> didrocks, well what we can do, is you can open a bug up, and if we can confirm its the same we can mark it as a dup as the one you open
[17:00] <didrocks> then, we fallback to xorg
[17:00] <bschaefer> didrocks, right
[17:00] <didrocks> and unity start
[17:00] <didrocks> doesn't crash
[17:00] <bschaefer> it was black screening on that bug
[17:00] <bschaefer> err
[17:00] <didrocks> bschaefer: yeah, sounds a good plan :)
[17:01] <bschaefer> well actually im not sure if it was, no one actually saw a visual
[17:01] <bschaefer> didrocks, yeah, Ill poke Chris when gets back, or Ill just take a look at it :)
[17:02] <robotfuel> didrocks: no I can try that right now though, I have a bunch of machines with it loaded.  the reboot 10 times is a good idea
[17:02] <didrocks> robotfuel: we did that a lot and have data FYI, one sec, summarizing this
[17:04] <didrocks> mterry: bschaefer: robotfuel: kgunn: bug #1202752
[17:04] <kgunn> didrocks: cool
[17:04] <bschaefer> didrocks, thanks
[17:05] <didrocks> yw :)
[17:05] <didrocks> thanks to jibel as well
[17:05] <bschaefer> jibel, thanks :)
[17:05] <bschaefer> didrocks, also, it does look a but different
[17:05] <bschaefer> didrocks, as that error you get, wasn't showing up in the othe rbug
[17:05] <didrocks> bschaefer: isn't it? :)
[17:05] <didrocks> ok, better to keep that separated
[17:06] <bschaefer> didrocks, yup, until we can confirm that its the same, it could be somewhat related, but yeeah
[18:46] <robotfuel_> kdub: I've found the version of checkbox we are using for ihv's, so I can run it on xmir -> http://certification-static.canonical.com/checkbox-ihv/
[18:46] <robotfuel_> oops
[18:46] <robotfuel_> wrong k
[18:47] <robotfuel_> kgunn: ^
[18:47] <racarr>  back
[18:47] <kgunn> robotfuel_: cool....kdub might like to know too :)
[19:19] <TheDrums> Howdy, just curious, when might 0.0.7 hit the "System Compositor Testing" PPA?
[19:39] <racarr> Yay ust implemented my session transaction stuff I was fantasizing about yesterday
[19:39] <racarr> and it does in fact fix the stress test
[19:58] <kgunn> TheDrums: honestly not sure, we've been laser locked on bugs for entering distro....i meet with the team in a bit, i'll see if we can bump it
[19:58] <kgunn> racarr: i thot robert_ancell fixed it ?....or were we multi-bugged
[19:58] <TheDrums> Cool, thanks.
[20:01] <kgunn> TheDrums: what exactly were you after in the latest? or what is the testing ppa lacking ?
[20:01] <kgunn> just curious
[20:02] <kgunn> ...pardon me while i reboot, brb
[20:10] <TheDrums> kgunn: Latest?  See if any crashing is fixed, or anything like that mainly.  Going to spin up a new ISO for it when it hits and trying to follow the official testing "rules" by not using staging. ;)  (The System Compositor Testing I'd hope is more likely to work, and as I can't actually test it on my hardware all I can do is see if the deps are right while generating.)
[20:11] <racarr> kgunn: Err, I think we were multibugged
[20:11] <racarr> well, we have definitely been multibugged
[20:14] <kgunn> TheDrums: mos def....-testing PPA should totally work....its just a copy of "confirmed" synch'd packages from staging
[20:15] <TheDrums> That's my idea, only had it once so far where it had unmet depends.  Anywho, was just asking about it, not trying to get into anything. :)
[20:15] <kgunn> TheDrums: sure...and yeah....we screwed up about a week ago on that one :)
[20:15] <kgunn> no hiccups since
[20:16] <kgunn> another reason for getting in distro soon....to escape the ppa madness
[20:21] <kgunn> ...and rebooting again
[20:50] <racarr> Late lunch...back soon!
[21:01] <racarr> mm tacos
[21:17] <robert_ancell> bregma, so, the armhf builds are supposed to be working now?
[21:18] <bregma> robert_ancell, as far as I know, tvoss disabled the tests so the packages build
[21:18] <robert_ancell> bregma, ok, it looks like jenkins is just behind then
[21:19] <bregma> I'm working with an older branch so I can try to make the tests fail sanely, so I haven't verified the builds myself
[21:22] <kdub> robert_ancell, so with the changes for ~kdub/mir/display-grouping, the client api has not changed (other than new functions) because we'll support the now-deprecated display query function
[21:22] <kdub> but the protobuf protocol has changed
[21:22] <kdub> so the soname for the client should be the same (because there is no abi breakage), right?
[21:23] <robert_ancell> kdub, correct - I'll re-review
[21:24] <robert_ancell> src/client/CMakeLists.txt still has the soname bump - is that what you were just about to remove?
[21:25] <kdub> right, just pushed seconds ago
[21:29] <robert_ancell> kdub, you can't change DisplayMode in mir_protobuf.proto like that - it will break old clients
[21:30] <robert_ancell> you either need to extend it and keep the old width, height and supported_pixel_format fields, or make a new message
[21:31] <robert_ancell> You can rename the fields though if they have the same content as the new fields. Though it looks like width, height and supported_pixel_format no longer exist
[21:33] <robert_ancell> kdub, http://paste.ubuntu.com/5888893/ shows how you could extend DisplayInfo
[21:33] <robert_ancell> there's a wire cost of sending the obsolete fields because they were marked 'required'
[21:34] <robert_ancell> Note the field numbers can never be reused - they form part of what goes on the wire
[21:41] <kdub> hmm
[21:44] <kdub> what about Connection going from 'optional' to 'repeated'
[21:46] <robert_ancell> kdub, that's allowed if it makes sense - an old client will take the first or last (I can't remember which) of the fields and just use that.
[21:46] <kdub> ah, ok
[21:46] <kdub> won't we break old clients eventually though and remove those fields?
[21:47] <robert_ancell> kdub, yes probably. This is a little bit artificial because in practise if probably wont matter. But we've made an API/ABI guarantee so we should get in the habit of doing it right
[21:47] <kgunn> thomi: mind a review on https://code.launchpad.net/~didrocks/unity-system-compositor/add-dirty-sleep/+merge/175633
[21:47] <robert_ancell> At least we should have the fallback code and delete it once we know all clients in the wild are updated
[21:48] <robert_ancell> kdub, it will be easier to make a new message, then drop the old one in the future
[21:48] <robert_ancell> (than extend the current message)
[21:48] <robert_ancell> we should really add the version into the connect message and reject old clients once we make that break
[21:50] <kdub> robert_ancell, but... if a new server is running and an old client connects, the client won't work
[21:50] <kdub> even if we preserve the right fields
[21:50] <robert_ancell> no?
[21:50] <kdub> because the code in the frontend is just talking in terms of the new messages
[21:50] <robert_ancell> kdub, yes, we have to populate the old fields to be backwards compatible
[21:51] <kdub> that really complicates everything though :/
[21:54] <robert_ancell> kdub, is the old supported_pixel_format == the new pixel_format?
[21:54] <kdub> yes
[21:55] <robert_ancell> kdub, rather supported_pixel_format = pixel_format[0]
[21:55] <kdub> sure, that shouldnt have changed
[21:55] <robert_ancell> and width == mode[0].horizontal_resolution?
[21:57] <kdub> right, I see what you're saying :) maybe i'm just resistant to deprecated code that has to be supported
[21:57] <robert_ancell> kdub, it's the cost of having a protocol
[21:57] <racarr> robert_ancell: kdub: Just being nosy ;) this sounds like it may be a recurring problem over the next month
[21:58] <racarr> I wonder if we can do something like add a version to connect
[21:58] <robert_ancell> kdub, this is where it might make sense to make a new connect message
[21:58] <racarr> and then it can just fail sanely and people need to update their clients
[21:58] <robert_ancell> and we just reject the old connect message for old clients.
[21:58] <racarr> I mean obviously we can't break things all the time, but for the time being it's mostly a matter of keeping things sane
[21:58] <racarr> rather than actually having "clients int he wild"
[21:58] <robert_ancell> The problem with the changes as you've made them is an old client will interpret the new data incorrectly
[21:59] <robert_ancell> basically what racarr is saying :)
[21:59] <thomi> kgunn: sure
[22:00] <robert_ancell> thomi, I just approved it
[22:00] <thomi> I see :)
[22:00] <thomi> looks nice a nasty hack, but *shrug* if it gets the job done :)
[22:00] <thomi> I ahve so many IRC channels I don't always see when people ping me :-/
[22:01] <racarr> thomi: Oh btw this is supposed to be
[22:01] <racarr> the stress test fix )
[22:01] <racarr> :)*
[22:01] <racarr> https://code.launchpad.net/~robertcarr/mir/session-transactions/+merge/175669
[22:01] <thomi> racarr: awesome, will test locally
[22:01] <thomi> dumb question: can I still run mir natively if I'm running xmir?
[22:02] <racarr> I...think so?
[22:02] <kgunn> thomi: i have run democlients while running xmir
[22:02] <kgunn> it uses the same window thos
[22:02] <kgunn> though
[22:02] <racarr> you should be able to run another server
[22:03] <kgunn> so i had to ctl-c to get my unity back
[22:03] <thomi> awesome, thanks
[22:03] <racarr> but you will need to pass -f or something
[22:03] <racarr> so they dont use the same socket file
[22:03] <thomi> hmm, ok
[22:03] <kgunn> thomi: right...what racarr said...otherwise it gloms onto your active mir window
[22:03] <racarr> then your client has to support that :p
[22:03] <racarr> we should have an environment variable
[22:03] <racarr> maybe we do and I forgot
[22:04] <thomi> kgunn: "gloms" - technical term? :P
[22:04] <kgunn> thomi: don't think so...
[22:04] <kgunn> gotta be some slang i picked up from my 15 yr old...
[22:04] <racarr> yeah we dont' have an environment variable
[22:04] <thomi> racarr: so I run "mir_demo_server -f /path/to/some/nonexistent/socket" ?
[22:04] <robert_ancell> racarr, there's MIR_SERVER_FILE
[22:04] <kgunn> glom = a parasitic type use of
[22:04] <racarr> robert_ancell: I mean one for the client library
[22:04] <racarr> thomi: Yes, or mirserver file
[22:04] <robert_ancell> racarr, ah, ok
[22:04] <racarr> it would be nice if like
[22:04] <kdub> robert_ancell, so I guess for now, i'll just support the old messages at the same time
[22:05] <racarr> MIR_CLIENT_SOCKET
[22:05] <racarr> if it was set, was the socket used for
[22:05] <racarr> mir_connect(NULL,
[22:05]  * robert_ancell hates it's called --file. How vague is that?
[22:05] <racarr> clients can still specify a socket of course
[22:05] <robert_ancell> racarr, +1
[22:05] <kdub> but i think adding versioning to connect in the near future is a good plan
[22:05] <thomi> robert_ancell: --file-descriptor :)
[22:05] <robert_ancell> thomi, but it's a path!
[22:05] <racarr> robert_ancell: mir --the-thing-that-used-to-be-export-display-equals-0=/tmp/bla
[22:05] <thomi> robert_ancell: a path to a file descriptor, right?
[22:06] <robert_ancell> mir --socket?
[22:06] <robert_ancell> thomi, no the name of a socket that will be opened by the server
[22:06] <racarr> mir --address
[22:06] <thomi> oh ok
[22:06] <robert_ancell> mir --client-socket?
[22:08] <racarr> I like --socket-path
[22:09] <robert_ancell> racarr, it probably needs to be --client-socket-path because for nested Mir we'll need --parent-socket-path or similar
[22:09] <thomi> ugh. Can we make ./native_compile.sh run "sudo mk-build-deps -i" at the top?
[22:09] <thomi> hmm. . pity it needs sudo, and isn't installed by default I guess
[22:09] <racarr> robert_ancell: Well, for nested mir it should have the same name as this
[22:09] <racarr> MIR_CLIENT_SOCKET_...
[22:09] <racarr> variable
[22:10] <robert_ancell> I guess
[22:10] <racarr> (the parent-socket-path)
[22:10] <robert_ancell> so we can use two env variables MIR_SERVER_SOCKET_PATH and MIR_CLIENT_SOCKET_PATH
[22:11] <thomi> why do you need two variables? Surely they should always be the same?
[22:11] <racarr> mir on mir
[22:11] <racarr> It's mir all the way down.
[22:11] <thomi> ... and we want to do that why?
[22:11] <racarr> Unity 8?
[22:11] <racarr> the future.
[22:12] <thomi> so.. maybe I'm being obtuse, but why is that "mir on mir", and not just "mir" ?
[22:12] <racarr> same idea as xmir where there is a system compositor
[22:12] <racarr> and each user session runs in a
[22:12] <racarr> session compositor
[22:12] <thomi> ahh, I see
[22:12] <racarr> and you can spin between user sessions on a burning cube
[22:13] <thomi> well... that seems very practical
[22:14] <kdub> robert_ancell, how's this diff for the protobuf file?
[22:14] <kdub> http://pastebin.ubuntu.com/5888989/
[22:15] <racarr> thomi: Practically the biggest gain is that the system compositor comes up very very early in the boot process
[22:15] <racarr> and after tht its flicker free :)
[22:15] <robert_ancell> kdub, that looks good. I think the DEPRECATED should be on the display_info field, not the display_state right?
[22:15] <robert_ancell> not the Connection message I mean
[22:16] <robert_ancell> kdub, and we just omit setting display_info in the new code? Since it's optional we can do that
[22:17] <kdub> deprecated is on the right field, there's a diff break
[22:17] <thomi> racarr: so with your banch, the server no longer deadlocks, but it does seem to crash
[22:17] <kdub> hmm... not sure
[22:17] <thomi> racarr: and I have to restart lightdm if I want my console back :-/
[22:18] <kdub> robert_ancell, old clients won't break (eg crash) if we don't set that field, but they won't be able to get any display information
[22:18] <robert_ancell> kdub, oh duh :)
[22:19] <kdub> :)
[22:19] <robert_ancell> kdub, right, so we don't break API or ABI, but we do change behaviour. That's probably acceptable given the state of the project
[22:19] <kdub> ok
[22:35] <racarr> thomi: Oh thats a shame
[22:35] <racarr> I never had a deadlock
[22:35] <racarr> I just had a crhs
[22:35] <racarr> crash*
[22:35] <racarr> Ok well I will try out with my laptop and longer times and
[22:35] <racarr> stuff
[22:35] <racarr> this definitely fixes a race though! so
[22:35] <racarr> ...something!
[22:35] <thomi> racarr: I just built packages, will install them now and make sure I can replicate
[22:36] <thomi> I just built locally before
[22:36] <racarr> It feels like
[22:36] <racarr> race conditions are more prevalent in the southern hemisphere
[22:37] <racarr> :p
[22:41] <thomi> racarr: yup, confirmed it crashes, but it seems to crash when mir_stress is about to exit, not half way through the run
[22:42] <thomi> racarr: let me know if there's anythign I can do to help you debug this, but I feel like your MP should be 'Needs Fixing' until I can run mir_stress without crashes - do you agree?
[22:42] <racarr> hmm
[22:43] <racarr> I guess my thought was merge it, because by inspection it fixes a bug
[22:43] <racarr> and it's just we have multiple bugs
[22:43] <racarr> s
[22:43] <racarr> I have an idea about a crash that could only occur when the client is actually exiting.
[22:44] <racarr> thomi: in src/server/frontend/session_mediator.cpp ~SessionMediator l66
[22:44] <racarr> right before if (session)
[22:44] <racarr> could you add
[22:45] <racarr> std::unique_lock<std::mutex> lock(session_mutex)
[22:45] <racarr> outside the scope of the if.
[22:45] <racarr> That may fix it! If not the most useful info would come from runnign the server with
[22:45] <racarr> MIR_SERVER_MSG_PROCESSOR_REPORT=log MIR_SERVER_SESSION_MEDIATOR_REPORT=log
[22:46] <thomi> racarr: that line already exists at that location
[22:46] <racarr> huh
[22:47] <thomi> racarr: what about the SessionMediator dtor?
[22:47] <thomi> does that need a lock as well?
[22:47] <racarr> thomi: That's what I meant
[22:47] <thomi> oh
[22:47] <racarr> shouldn't the if (session) in ~SessionMediator be
[22:47] <thomi> sorry
[22:47] <racarr> at l66?
[22:47] <thomi> I saw l66 as 166
[22:47] <racarr> ah!
[22:47] <thomi> :)
[22:47] <racarr> haha, I was like
[22:47] <racarr> oh god, I don't even know what branch is what anymore
[22:48] <thomi> ok, building...
[22:54] <racarr> Ah :) always feels good to get to the end of my own branch list
[23:04] <racarr> this
[23:05] <racarr> eh nvm the thought vanished
[23:06] <thomi> racarr: nope, that doesn't work either
[23:06] <racarr> the races around msh::Surface in the  session-transactions branch
[23:06] <thomi> racarr: when I do that, mir_server hangs, and mir_stress never exits
[23:06] <racarr> I feel like they have given me a lot more clarity about what the scenegraph needs to do, and whats wrong with the existing interfaces
[23:06] <racarr> but apparently not that clear because I just completely brain dumped
[23:06] <racarr> thomi: Ok. Can you pastebin with the two env variables I sent up above
[23:08] <thomi> racarr: where does the output go?
[23:10] <thomi> racarr: got it.. trying to pastebin a 5.3MB log file :-/
[23:10] <thomi> maybe that's a bad idea :)
[23:11] <racarr> haha oh right
[23:12] <thomi> hmmm... I now have a 280KB .gz fie.. I'll email it to you
[23:12] <racarr> I..had some good times with those log files
[23:12] <racarr> I ended up adding roughly ~15 random printfs with line and thread-id
[23:12] <racarr> and added thread-id in the logs
[23:12] <racarr> and used emacs macros
[23:12] <racarr> to reorder them
[23:12] <racarr> and did that roughlly
[23:12] <racarr> 100 times in a row
[23:12] <racarr> and that was tuesday
[23:12] <racarr> lol
[23:13] <thomi> racarr: OK, email sent. let me know if you get it
[23:14] <racarr> thomi: got it
[23:14] <thomi> awesome
[23:15] <racarr> thomi: Does the file really cut off int he middle of
[23:15] <racarr> disconn...
[23:15] <racarr> it seems to contain no information :(
[23:15] <racarr> is that stderr and stdout?
[23:15] <thomi> racarr: that's stdout, and yeah, it really does cut off there
[23:44] <racarr> thomi: :( ok I will see if I can reproduce it on some of my other devices
[23:44] <thomi> racarr: ok, let me know if I can get you anything else
[23:48] <robert_ancell> racarr, what's the advantage of a transaction over a lock?
[23:49] <robert_ancell> racarr, ps, are you using emacs?