| 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:00 |
| thomi | RAOF: got a second? | 00:03 |
| 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:10 |
| 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:11 |
| 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:13 |
| 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:14 |
| 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:15 |
| thomi | thanks! | 00:16 |
| RAOF | Acutally, that'll miss some hybrid systems. | 00:16 |
| 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:17 |
| thomi | hmmmm, that sounds harder to do exhaustively | 00:18 |
| RAOF | lspci -vvv, parse it out, check that "Kernel driver in use: " is the right thing. | 00:19 |
| 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:20 |
| RAOF | Only those three cases. | 00:21 |
| thomi | ok, sweet | 00:21 |
| 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:22 |
| === thomi is now known as thomi|lunch | ||
| RAOF | Arse. This kernel is built with debug symbols, making it 700 MB, or significantly larger than my boot partition. Poot. | 00:24 |
| xnox | ... chain-load?! | 00:45 |
| xnox | boot of usb?! =) | 00:46 |
| racarr | RAOF: Sounds like the second reason today to switch to FreeBSD | 00:48 |
| RAOF | Surely GNU/Hurd! | 01:15 |
| === thomi|lunch is now known as thomi | ||
| thomi | I don't suppose anyone here has a machine with a radeon graphics chipset? | 02:01 |
| thomi | RAOF: perhaps you have one? | 02:02 |
| RAOF | thomi: I do. | 02:02 |
| 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:03 |
| RAOF | http://paste.ubuntu.com/5886137/ (and with -n, which you should probably use so you can match on PCIID ) | 02:10 |
| RAOF | http://paste.ubuntu.com/5886140/ | 02:11 |
| RAOF | thomi: ^^^ | 02:12 |
| thomi | RAOF: thanks | 02:14 |
| RAOF | You'll notice this is a hybrid system, so a good test :) | 02:14 |
| thomi | RAOF: what's the best way to determine if xmir is running? simply "pgrep unity-system-compositor" ? | 02:53 |
| thomi | or is there some better way that you can think of? | 02:54 |
| RAOF | Two options; pgrep unity-system-compositor or grep xmir /var/log/Xorg.$(echo $DISPLAY | sed s/://g).log | 02:57 |
| 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:58 |
| RAOF | You could also check the args used to spawn /usr/bin/X; if they contain “-mir ”, then it's XMir. | 02:59 |
| duflu | robert_ancell: What's you're preferred medium? :) | 03:03 |
| duflu | Oh | 03:03 |
| thomi | robert_ancell: got a second? | 03:22 |
| robert_ancell | thomi, otp | 03:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| robert_ancell | thomi, what is an existing package I can look at? | 03:29 |
| thomi | robert_ancell: lp:unity8 has one | 03:29 |
| 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:30 |
| 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:31 |
| thomi | I thought it was more complicateed than that, but OK :) | 03:33 |
| 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:38 |
| robert_ancell | thomi, https://code.launchpad.net/~robert-ancell/unity-system-compositor/add-autopilot-test-packaging/+merge/175446 | 03:44 |
| thomi | will merge now | 03:45 |
| thomi | robert_ancell: OK, those changes are now in my branch. Will email the list so didrocks reviews it | 03:47 |
| robert_ancell | kdub, still here? | 04:26 |
| 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:42 |
| 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:43 |
| thomi | sure | 04:44 |
| robert_ancell | (and then I'll forget and just approve it) | 04:44 |
| thomi | done and done | 04:45 |
| RAOF | I hope this doesn't hit the thermal trip point... | 04:59 |
| tvoss_ | good morning :) | 05:03 |
| RAOF | Good morning | 05:04 |
| * 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:05 | |
| duflu | RAOF: What? Ubuntu doesn't already come with sane sensors monitoring? | 05:28 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:35 |
| 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:36 |
| tvoss_ | didrocks, what do you think? | 05:37 |
| 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:38 |
| 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:39 |
| tvoss_ | didrocks, fair point ... hmmm, we need a way to force the backend instantiation and report an error if something is missing ... | 05:40 |
| 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:41 |
| tvoss_ | didrocks, hmmm ... let me think about it for a bit | 05:42 |
| 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:44 |
| 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:45 |
| mlankhorst | sec | 05:46 |
| 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:47 |
| 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:48 |
| didrocks | thomi: sounds perfect to me with those changes, +1 ;) | 05:49 |
| didrocks | I'm now adding it to the tests to run | 05:49 |
| didrocks | done | 05:51 |
| tvoss_ | didrocks, https://github.com/ros-infrastructure/buildfarm/issues/87 | 06:10 |
| 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:11 |
| tvoss_ | didrocks, hmmm, good question ... checking with #is | 06:12 |
| RAOF | didrocks: Yes, I was planning to update xorg-server. Just after mlankhorst pushes 1.14.2-0ubuntu1 to git :) | 06:13 |
| RAOF | duflu: Ubuntu *does* have sane sensors monitoring, but thermald does intel-specific tricks. | 06:14 |
| 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:15 |
| 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:16 |
| 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:18 |
| 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:19 |
| 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:20 |
| didrocks | RAOF: exactly! to https://launchpad.net/~ubuntu-unity/+archive/daily-build-next | 06:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| RAOF | Faster, laptop, faster! | 06:36 |
| alf_ | RAOF: Are you sure you want to push your thermally challenged laptop so hard? ;) | 06:40 |
| RAOF | I've chocked it up, and the kernel build has finished. It's only 65℃ now :) | 06:41 |
| tvoss_ | ffs, why does swithcing to a guest session fix the input lag issue? | 06:44 |
| tvoss_ | s/input lag/output lag | 06:44 |
| RAOF | Hm. Does that suggest a Mir platform? | 06:45 |
| tvoss_ | RAOF, ? | 06:46 |
| RAOF | Because that's switching surface focus. | 06:46 |
| tvoss_ | RAOF, it does ... let me check something | 06:46 |
| RAOF | Notably, it *doesn't* stop X from rendering, unless Mir blocks it. | 06:47 |
| tvoss_ | RAOF, yup | 06:49 |
| 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:50 |
| tvoss_ | robert_ancell, ping | 06:51 |
| duflu | RAOF: It shouldn't block for obvious compositing reasons, but it does due to https://bugs.launchpad.net/mir/+bug/1188486 | 07:06 |
| ubot5 | Launchpad bug 1188486 in Mir "Unfocused apps are never visible on screen" [Medium,Triaged] | 07:06 |
| tvoss_ | RAOF, might that be the reason that a switch to the guest session "aligns" things again? | 07:12 |
| RAOF | Plausibly. | 07:12 |
| * RAOF wanders through the code while Mesa builds. | 07:13 | |
| duflu | ... it's a general problem Mir has with unfocused clients getting paused. They shouldn't get paused, obviously | 07:14 |
| duflu | At least not by default | 07:15 |
| tvoss_ | duflu, agreed, it should be a policy | 07:16 |
| dholbach | good morning | 07:18 |
| tvoss_ | woot, no more second cursor :) | 07:22 |
| 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:27 |
| tvoss_ | wow, only one cursor ... this is so mainstream | 07:28 |
| duflu | It's so 20th century | 07:30 |
| tvoss_ | duflu, exactly | 07:33 |
| tvoss_ | duflu, my mind feels bored now ... | 07:33 |
| pete-woods | morning guys! | 07:33 |
| 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:34 |
| tvoss_ | pete-woods, yup | 07:35 |
| tvoss_ | pete-woods, what vm are you trying? | 07:35 |
| 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:36 |
| 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:37 |
| pete-woods | tvoss_, duflu: no worries guys, is this something we'd be trying to have ready for 13.10? | 07:38 |
| 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:39 |
| duflu | pete-woods: https://bugs.launchpad.net/mir/+bug/1118903 | 07:40 |
| ubot5 | Launchpad bug 1118903 in Mir "Mir lacks a software rendering backend" [High,Triaged] | 07:40 |
| RAOF | Oooooh. | 07:43 |
| RAOF | Hm. | 07:43 |
| tvoss_ | RAOF, ? | 07:43 |
| RAOF | So, because threading and X is a world of pain, we push events through a pipe. | 07:44 |
| * tvoss_ listens excitedly to RAOF | 07:45 | |
| RAOF | Which obviously happens asynchronously. | 07:45 |
| RAOF | But that's ok, because we register the pipe as a general socket, and have a wakeup handler. | 07:46 |
| 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:48 |
| 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:49 |
| RAOF | But first, Zoë bath.\ | 07:50 |
| 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:53 |
| robert_ancell | hello | 07:54 |
| didrocks | robert_ancell: be on the edge! (yeah, it's something I fixed) :-) | 07:54 |
| === alan_g|EOD is now known as alan_g | ||
| 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:10 |
| 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:11 |
| tvoss_ | robert_ancell, still, some mileage would be great :) | 08:14 |
| robert_ancell | tvoss_, email me the link | 08:15 |
| tvoss_ | robert_ancell, the package :) | 08:15 |
| 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:16 |
| 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:17 |
| robert_ancell | tvoss_, so can't you just do a bzr branch, make the change, commit and push somewhere? | 08:18 |
| 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:23 | |
| robert_ancell | brb | 08:33 |
| 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:37 |
| RAOF | Hm. Where did my xorg-server upload disappear to? | 08:39 |
| 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! :-) | 08:42 |
| 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:11 |
| alan_g | tvoss_: ack | 09:12 |
| tvoss_ | alan_g, can you call again please? | 09:15 |
| 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:16 |
| 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:17 |
| RAOF | didrocks: Everything's in the PPA now; enjoy. | 09:18 |
| didrocks | RAOF: \o/ I'll for sure, thanks! | 09:18 |
| alan_g | \o/ networking and cursor now working again on my laptop | 10:46 |
| katie | tvoss_, ping | 10:49 |
| tvoss_ | katie, pong | 10:55 |
| 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:56 |
| 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 | 10:57 |
| === greyback is now known as greyback|lunch | ||
| alan_g | alf_: are you happy to top approve move-graphicsplatform-dependencies-to-graphics-less-contentious? | 11:28 |
| alf_ | alan_g: sure, | 11:29 |
| alf_ | alan_g: do you want me to do it? | 11:30 |
| alan_g | alf_: that would make me happy too | 11:33 |
| alan_g | Oh! /o\ only *wireless* and g3 networking is working. Laptop still doesn't do wired networking. | 11:35 |
| === greyback|lunch is now known as greyback | ||
| alf_ | alan_g: (done) | 11:42 |
| * duflu wanders off dazed | 11:45 | |
| alan_g | duflu was still up?! No wonder he's dazed | 11:46 |
| 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? | 11:59 |
| === alan_g is now known as alan_g|lunch | ||
| 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. | 12:07 |
| === Guest70312 is now known as Debolaz | ||
| didrocks | kgunn: hey, around? | 13:13 |
| === alan_g|lunch is now known as alan_g | ||
| kgunn | didrocks: yeah | 13:34 |
| 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:35 |
| didrocks | https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/501/ | 13:36 |
| didrocks | can be a config issue, but would be better to debug with someone knowing how lightdm runs unity-system-compositor | 13:37 |
| mterry | kgunn, hi | 13:49 |
| mterry | ahem | 13:49 |
| kgunn | mterry: hey...your here :) | 13:49 |
| * kgunn suffering irc ping-tsunami | 13:50 | |
| kgunn | mterry: so didrocks having u-s-c/mir failing to start on his autopilot daily release testing | 13:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| didrocks | s/hum/him/ | 13:55 |
| === jono is now known as Guest30113 | ||
| kgunn | didrocks: actually i should ask...have you simply done a subsequent reboot on that machine ? | 13:56 |
| 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:57 |
| mterry | Oh, maybe those are the same | 13:58 |
| didrocks | mterry: they are, on the 2 configs :) | 13:58 |
| 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 | 13:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| didrocks | we are using lightdm from distro FYI | 14:03 |
| didrocks | which is enough from what robert told | 14:03 |
| kgunn | didrocks: lightdm from distro...yeah | 14:05 |
| kgunn | it better be :) that's what his instructions say | 14:05 |
| 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:26 | |
| didrocks | mterry: thanks! that's helpful :) | 14:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| didrocks | mterry: do you know exactly which udev device you need? | 14:31 |
| 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:33 |
| jibel | mterry, which job did you get this message from? | 14:34 |
| didrocks | jibel: 501 | 14:35 |
| didrocks | /var/log/lightdm | 14:35 |
| didrocks | (from the archive) | 14:35 |
| mterry | kdub, do you know more about the above error message? ^ | 14:43 |
| didrocks | mterry: is is that hidden in the code? | 14:45 |
| didrocks | :) | 14:47 |
| * didrocks tries to branch mir to look as well | 14:47 | |
| 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:49 |
| 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:50 |
| 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:51 |
| didrocks | jibel: strace will indeed help, as mterry mentionned | 14:52 |
| didrocks | mterry: to run unity-system-compositor, we can do that without any X, just starting from a login prompt, right? | 14:53 |
| mterry | didrocks, I think so...? | 14:55 |
| 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:56 |
| didrocks | mterry: just need to hack to not have the tests running and the machine staying up | 14:57 |
| sil2100 | racarr: hi! | 15:41 |
| 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:44 |
| 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:45 |
| didrocks | did you change anything in /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf ? | 15:46 |
| 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:47 |
| didrocks | mterry: see! | 15:50 |
| didrocks | mterry: just restarted | 15:50 |
| 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:51 |
| mterry | ok, restart worked-ish | 15:52 |
| mterry | didrocks, OK, how to restart? | 15:52 |
| didrocks | (I just rechecked) | 15:52 |
| 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:53 |
| sil2100 | racarr: (here as well) ping | 15:54 |
| didrocks | mterry: it's running, jibel restarts | 15:54 |
| mterry | didrocks, sorry, wasn't watching byobu when that all happened :) | 15:55 |
| didrocks | mterry: ok, restarted | 15:56 |
| didrocks | so it's running again | 15:56 |
| didrocks | strace should slows the start enough :/ | 15:56 |
| mterry | ok, let's see that log | 15:57 |
| mterry | didrocks, it looks like it worke | 15:57 |
| 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:58 |
| didrocks | mterry: like sleep && unity-system-compositor in the conffile? | 15:59 |
| didrocks | sleep 1* | 15:59 |
| racarr | sil2100: Pong | 16:00 |
| racarr | Dentist soon sorry but im around for next 30 minutes | 16:01 |
| mterry | didrocks, yeah, that could work | 16:01 |
| sil2100 | racarr: priv then! | 16:03 |
| mterry | didrocks, I looked away, did the sleep work? | 16:06 |
| 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:07 |
| 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:08 |
| didrocks | we tried with cold cache, without any difference | 16:09 |
| didrocks | (it worked the first time) | 16:09 |
| didrocks | ok, without sleep, it started 7 times on 10 trials | 16:13 |
| didrocks | kgunn: FYI ^ | 16:13 |
| * 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:21 |
| 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:22 |
| kgunn | ? | 16:23 |
| didrocks | kgunn: yeah, with no interesting value right now (we have 100% failures) | 16:23 |
| 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:24 |
| didrocks | kgunn: 70% working -> call with no config | 16:25 |
| didrocks | 0% working with the sleep, but still trying | 16:26 |
| kgunn | didrocks: bummer | 16:26 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 | |
| didrocks | kgunn: do people notice you think? | 16:32 |
| kgunn | didrocks: hard to miss the giant-ass mouse missing | 16:32 |
| kgunn | :) | 16:32 |
| 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:33 |
| 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:34 |
| didrocks | we are in a ssh connexion directly connected to it, not using kvm | 16:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| didrocks | kgunn: sleep .1 (no typo) | 16:39 |
| kgunn | you add to the u-s-c conf file right ? | 16:39 |
| 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:40 |
| didrocks | not sure if you want to go that ugly way then ^ | 16:41 |
| 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:42 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| kgunn | didrocks: to make sure i understand....sleep 0 = 70% pass, sleep 1 = 0% pass, sleep .1 = 100% (10 runs each) | 16:49 |
| 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:50 |
| 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:51 |
| bschaefer | oo I see it was a test issue | 16:52 |
| 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:53 |
| 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 |
| ubot5 | Launchpad bug 1201565 in XMir "unity doesn't run in xmir session " [Critical,Triaged] | 16:54 |
| bschaefer | opps :) | 16:54 |
| didrocks | kgunn: hum, doesn't seem to be that one | 16:54 |
| didrocks | we don't have unity-system-compositor running, not unity | 16:55 |
| kgunn | bschaefer: hmmmm, did we morph this bug on accident...are there really 2 bugs ? or did the unity problem actually go away... | 16:56 |
| 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:57 |
| 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:58 |
| 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 | 16:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| didrocks | mterry: bschaefer: robotfuel: kgunn: bug #1202752 | 17:04 |
| ubot5 | bug 1202752 in Unity System Compositor "race when starting unity-system-compositor from lightdm" [Undecided,New] https://launchpad.net/bugs/1202752 | 17:04 |
| kgunn | didrocks: cool | 17:04 |
| bschaefer | didrocks, thanks | 17:04 |
| 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:05 |
| bschaefer | didrocks, yup, until we can confirm that its the same, it could be somewhat related, but yeeah | 17:06 |
| === alan_g is now known as alan_g|EOD | ||
| === sfeole` is now known as sfeole | ||
| === dpm_ is now known as dpm | ||
| 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:46 |
| robotfuel_ | kgunn: ^ | 18:47 |
| racarr | back | 18:47 |
| kgunn | robotfuel_: cool....kdub might like to know too :) | 18:47 |
| TheDrums | Howdy, just curious, when might 0.0.7 hit the "System Compositor Testing" PPA? | 19:19 |
| 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:39 |
| 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. | 19:58 |
| kgunn | TheDrums: what exactly were you after in the latest? or what is the testing ppa lacking ? | 20:01 |
| kgunn | just curious | 20:01 |
| kgunn | ...pardon me while i reboot, brb | 20:02 |
| 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:10 |
| racarr | kgunn: Err, I think we were multibugged | 20:11 |
| racarr | well, we have definitely been multibugged | 20:11 |
| kgunn | TheDrums: mos def....-testing PPA should totally work....its just a copy of "confirmed" synch'd packages from staging | 20:14 |
| 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:15 |
| kgunn | another reason for getting in distro soon....to escape the ppa madness | 20:16 |
| kgunn | ...and rebooting again | 20:21 |
| racarr | Late lunch...back soon! | 20:50 |
| racarr | mm tacos | 21:01 |
| robert_ancell | bregma, so, the armhf builds are supposed to be working now? | 21:17 |
| 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:18 |
| 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:19 |
| 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:22 |
| robert_ancell | kdub, correct - I'll re-review | 21:23 |
| robert_ancell | src/client/CMakeLists.txt still has the soname bump - is that what you were just about to remove? | 21:24 |
| kdub | right, just pushed seconds ago | 21:25 |
| robert_ancell | kdub, you can't change DisplayMode in mir_protobuf.proto like that - it will break old clients | 21:29 |
| 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:30 |
| 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:31 |
| 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:33 |
| robert_ancell | Note the field numbers can never be reused - they form part of what goes on the wire | 21:34 |
| kdub | hmm | 21:41 |
| kdub | what about Connection going from 'optional' to 'repeated' | 21:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:50 |
| kdub | that really complicates everything though :/ | 21:51 |
| robert_ancell | kdub, is the old supported_pixel_format == the new pixel_format? | 21:54 |
| kdub | yes | 21:54 |
| 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:55 |
| 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:57 |
| 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:58 |
| robert_ancell | basically what racarr is saying :) | 21:59 |
| thomi | kgunn: sure | 21:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| racarr | I like --socket-path | 22:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| thomi | well... that seems very practical | 22:13 |
| kdub | robert_ancell, how's this diff for the protobuf file? | 22:14 |
| kdub | http://pastebin.ubuntu.com/5888989/ | 22:14 |
| 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:15 |
| robert_ancell | kdub, and we just omit setting display_info in the new code? Since it's optional we can do that | 22:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:35 |
| 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:36 |
| racarr | :p | 22:37 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| thomi | racarr: that line already exists at that location | 22:46 |
| racarr | huh | 22:46 |
| 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:47 |
| thomi | ok, building... | 22:48 |
| racarr | Ah :) always feels good to get to the end of my own branch list | 22:54 |
| racarr | this | 23:04 |
| racarr | eh nvm the thought vanished | 23:05 |
| 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:06 |
| thomi | racarr: where does the output go? | 23:08 |
| thomi | racarr: got it.. trying to pastebin a 5.3MB log file :-/ | 23:10 |
| thomi | maybe that's a bad idea :) | 23:10 |
| racarr | haha oh right | 23:11 |
| 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:12 |
| thomi | racarr: OK, email sent. let me know if you get it | 23:13 |
| racarr | thomi: got it | 23:14 |
| thomi | awesome | 23:14 |
| 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:15 |
| 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:44 |
| robert_ancell | racarr, what's the advantage of a transaction over a lock? | 23:48 |
| robert_ancell | racarr, ps, are you using emacs? | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!