| robert_ancell | RAOF, sounds fine - is there some time skew? | 00:00 |
|---|---|---|
| RAOF | robert_ancell: No, but it would make correlating debugging messages much easier when dmesg, Xorg.0.log, and lightdm.log all had the same timestamps. | 00:00 |
| robert_ancell | oh, right | 00:01 |
| RAOF | Rather than [ +time_since_lightdm_start s] :) | 00:01 |
| robert_ancell | yep | 00:01 |
| RAOF | thomi: So, I'd try booting, but hitting <esc> when you see the boot splash so it goes into text mode, and see if that boots correctly to xmir. | 00:02 |
| * thomi tries that | 00:02 | |
| thomi | RAOF: nope, It still hangs. The last boot line is something about 'startpar bridge' | 00:04 |
| thomi | brb, gotta get more caffeine in me | 00:04 |
| RAOF | :) | 00:04 |
| thomi | that's better | 00:24 |
| thomi | RAOF: so, anything I can do to try and get this working? | 00:24 |
| RAOF | thomi: Could you try booting without plymouth splash all together? That would be removing the ‘quiet splash’ line from the grub boot entry. | 00:25 |
| RAOF | thomi: Also, does this only apply at boot? If you boot successfully without XMir, change your lightdm config, and run ‘sudo restart lightdm’ do you get the same crash? | 00:26 |
| thomi | RAOF: I'll try the first thing now. I don't know about the second thing, something to try later perhaps | 00:26 |
| thomi | turning off the boot splash all together makes no difference | 00:29 |
| thomi | RAOF: also, I get the same crash if I boot normally, enable u-s-c and then restart lightdm | 00:33 |
| thomi | RAOF: what should i do next? | 00:34 |
| RAOF | Ok. So, we're doing something stupid then. | 00:34 |
| RAOF | Or maybe I just need to take a newer mesa snapshot :) | 00:34 |
| RAOF | thomi: Do the Mir demos render correctly? | 00:34 |
| thomi | I haven't tried them in a while, let me check | 00:35 |
| thomi | RAOF: yes, they work perfectly | 00:38 |
| RAOF | Hm. Maybe xf86-video-intel damage then? | 00:38 |
| thomi | anything I can do to test that hypothesis? | 00:39 |
| RAOF | Heh. | 00:39 |
| RAOF | Second commit after our Mesa snapshot: Revert "i965: Disable unused pipeline stages once at startup on Gen7+." | 00:39 |
| RAOF | Apparently causes GPU hangs. | 00:39 |
| thomi | O.0 | 00:39 |
| RAOF | thomi: Allow me to cut a new mesa snapshot :) | 00:39 |
| thomi | yeah, thanks | 00:39 |
| thomi | I need to pick my girlfriend up from the airport, so maybe that'll be ready by the time I get back | 00:40 |
| === alex_abreu is now known as alex-abreu | ||
| === asac` is now known as asac | ||
| RAOF | Hm. The jenkins mesa job doesn't seem to have worked. | 01:41 |
| NikTh | Hello everyone | 01:50 |
| NikTh | I've just installed 13.10 and I tested Xmir.. (I'm on Xmir now) , pretty good, no major differences , except of the two mouse pointers (LoL). | 01:51 |
| thomi | RAOF: no new mesa yet? | 01:53 |
| thomi | NikTh: good! | 01:53 |
| RAOF | thomi: The jenkins mesa job seems to have failed? | 01:53 |
| * thomi looks | 01:53 | |
| NikTh | I want to ask, is this valid ? (true?) , can be applied in 13.10 ? I mean the "Run Mir Natively" -> http://unity.ubuntu.com/mir/using_mir_on_pc.html | 01:53 |
| RAOF | NikTh: Oh, yes. | 01:54 |
| NikTh | RAOF, please explain .. I want to test this, no matter if I brake the system down :P | 01:54 |
| RAOF | Yes, those instructions should work. | 01:55 |
| thomi | RAOF: it looks to me like it has not run yet. Is https://github.com/RAOF/mesa.git the correct repo? with the mir-ppa branch? | 01:55 |
| RAOF | thomi: Correct. | 01:55 |
| NikTh | The commands maybe are only examples or something, because their not exist. :( | 01:56 |
| thomi | hmm, the git polling is set to @hourly | 01:56 |
| thomi | NikTh: those commands are now in /usr/lib/x86_64-linux-gnu/mir/examples | 01:56 |
| thomi | NikTh: or whatever your platform string is :) | 01:56 |
| NikTh | Thanks thomi . Thanks. :) | 01:56 |
| RAOF | Ah. Documentation update time! | 01:57 |
| NikTh | I will test it right now :) | 01:57 |
| bschaefer | any reason im getting this with the mir ppa? | 01:58 |
| bschaefer | unity-system-compositor : Depends: libmirserver0 (= 0.0.6bzr785saucy0) but 0.0.6bzr786saucy0 is to be installed | 01:58 |
| bschaefer | :( no lightdm | 01:58 |
| NikTh | thomi, what client you suggest ? mir demo client or mir demo client accelerated as first hit . | 01:58 |
| NikTh | thomi, OK. No worries. I will test it either way. :) | 02:00 |
| RAOF | bschaefer: Because unity-system-compositor hasn't been rebuilt against the latest mir (and it requires it because we're making no attempt at a stable mirserver ABI at this point) | 02:00 |
| NikTh | Thanks again | 02:00 |
| RAOF | bschaefer: This is why we provide the system-compositor-testing PPA :) | 02:00 |
| bschaefer | RAOF, i see :), well no worries, I can just force start X for now | 02:01 |
| * bschaefer hopes its built by tomorrow morning | 02:01 | |
| RAOF | It probably will be, but there'll also likely be a new mir to break things again. | 02:02 |
| bschaefer | RAOF, o yeah, i also wanted to point you to this stack trace I got yesterday from Xorg.log | 02:02 |
| bschaefer | http://paste.ubuntu.com/5802840/ | 02:02 |
| bschaefer | while running Xmir | 02:03 |
| RAOF | Install from system-compositor-testing ☺ | 02:03 |
| RAOF | bschaefer: Looks like Mir has hung? | 02:03 |
| bschaefer | RAOF, yeah, I might as well do that at this point :) | 02:03 |
| bschaefer | RAOF, yeah, it ended up crashing X though | 02:03 |
| RAOF | No, I don't think it did crash X. | 02:04 |
| RAOF | Oh! mir_wait_for did eventually return. | 02:04 |
| RAOF | Odd. | 02:04 |
| bschaefer | RAOF, hm, as a giant error box with that stacktrace appeared, and it didn't seem like X was running | 02:05 |
| RAOF | Those backtraces are "whoops, something's blocking the event loop and we're still getting input events" | 02:05 |
| RAOF | Your log ends with [ 373.614] Server terminated successfully (0). Closing log file. | 02:05 |
| RAOF | :) | 02:05 |
| RAOF | Something decided to shutdown X, and it did. | 02:05 |
| bschaefer | RAOF, well it shut it down nicely :) | 02:06 |
| bschaefer | hopefully it isn't a recurring problem! also thanks again for pointing me to that other ppa :) | 02:07 |
| RAOF | But there certainly is a bug in there - mir_wait_for shouldn't be blocking the mainloop for so long. | 02:07 |
| bschaefer | RAOF, are there any mir logging that would give more info? | 02:10 |
| bschaefer | or look at running mir trunk from through gdb to get a better stracktrace if it were to happen again? | 02:11 |
| RAOF | bschaefer: I think you can pass --msg-processor-report=log through to unity-system-compositor by editing /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf (and adding a unity-compositor-command=unity-system-compositor --msg-processor-report=log key) | 02:12 |
| * duflu hopes it's not due to https://bugs.launchpad.net/mir/+bug/1194384 | 02:12 | |
| ubot5 | Launchpad bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Medium,In progress] | 02:12 |
| RAOF | That should dump a bunch of info relating to IPC. | 02:13 |
| bschaefer | RAOF, sweet, ill give that try | 02:13 |
| bschaefer | thanks | 02:13 |
| bschaefer | duflu, also hello! how was your vacation? | 02:15 |
| duflu | bschaefer, was good thanks | 02:15 |
| duflu | But I've been back a few weeks | 02:15 |
| duflu | So all is "normal" again | 02:15 |
| bschaefer | duflu, nice, thats good | 02:16 |
| bschaefer | I also see you merge the cursor change :), though Im starting to miss that large orange one haha | 02:16 |
| duflu | bschaefer: We can make it anything within 64x64. I suspect we will need an API for changing it too | 02:21 |
| bschaefer | duflu, in due time, but that API will be needed at some point :) | 02:22 |
| NikTh | I'm back :) | 02:22 |
| NikTh | Except mir_demo_client (connection released = nothing happened) and mir_demo_client_unaccelerated (got stuck) , all other demos ran smoothly. Most FPS = 457 = mir_demo_client_egltriangle. Most amazing =mir_demo_client_eglplasma ! | 02:26 |
| NikTh | Keep up the good work guys and thank you again for the help :-) | 02:26 |
| duflu | NikTh, mir_demo_client actually does nothing by design. How did the unaccelerated one get stuck? | 02:29 |
| duflu | NikTh, did you say some client reported 457 FPS? That shouldn't happen right now | 02:30 |
| duflu | RAOF ^ | 02:30 |
| NikTh | duflu, don't know. Just a black screen on mir VT and could not change VT. I rebooted with SysRq. Yes the mir_demo_client_egltriangle reported almost 457 FPS, but decreased as let it running. | 02:32 |
| duflu | NikTh, interesting. Normally it freezes (lower FPS) when a Mir client is not focussed. That shouldn't happen.. | 02:33 |
| NikTh | duflu, do you want me to record this with an external camera and upload it.. ? (if happens again of course :P ) | 02:35 |
| duflu | NikTh, that would be great if you could. Just log all bugs at: https://bugs.launchpad.net/mir/+filebug | 02:35 |
| NikTh | duflu, is this a bug really ? I thought more FPS are better :P (don't know technical stuff) | 02:36 |
| duflu | NikTh: Yes, when something's not in use, it should idle to zero FPS. Also technically, those demos are set to sync to the monitor's refresh rate (make 60 usually) | 02:37 |
| NikTh | I think 1 FPS was the mir_demo_client_accelerated only. All other demos was above.. 250 FPS or so. | 02:39 |
| NikTh | I will test it again.. and I will try to record it this time. Thanks duflu :) | 02:40 |
| duflu | NikTh, no problem. I think I need to test it for myself again.. | 02:45 |
| Nikth2 | duflu, last question before I leave. Does it matter that when I tested mir natively I was in Xmir on VT7 ? Perhaps I had to run X only ? | 02:52 |
| duflu | Nikth2, yes it could matter. AFAIK you can only have one Mir server running at the moment. And if that was XMir that your native clients were rendering to, then that's something we haven't tested much of | 02:55 |
| duflu | Nikth2, to run a basic Mir server you need to disable XMir first | 02:56 |
| robert_ancell | duflu, damn, you moved a bug to milestone 0.0.6, but I can't move it back to 0.0.5... | 02:56 |
| Nikth2 | duflu, OK. I think I got it now. Thank you. | 02:56 |
| duflu | robert_ancell, no problem. Just unlock 0.0.5, fix the bug and relock. I've done it many times. But I think 0.0.6 is correct | 02:57 |
| duflu | robert_ancell: Any bug in progress already missed 0.0.5. Hence it's targeted for 0.0.6 | 02:59 |
| duflu | Right? | 02:59 |
| robert_ancell | duflu, it was re-opened, but I'm closing it again and using a new bug for 0.0.6 | 02:59 |
| duflu | Ah | 03:00 |
| duflu | robert_ancell, is it really a different bug? | 03:00 |
| duflu | I generally say reopen the old one unless an explicit fix was committed and tested | 03:00 |
| robert_ancell | duflu, well, the first bug didn't have detailed information, so it's just confusing - the new bug has a particular symptom | 03:00 |
| duflu | robert_ancell: If the old one lacked info, it should either be enhanced or marked incomplete. But not fixed | 03:01 |
| robert_ancell | duflu, changes were made that fixed the bug "black screen" for some people, thus it is fixed. | 03:02 |
| duflu | I haven't retested staging with system compositor to verify it properly | 03:02 |
| duflu | Bah, that's enough time spent arguing | 03:02 |
| robert_ancell | duflu, ok, if you still have the problem note it in bug 1195509, or file a new bug with the reason for the failure from the logs | 03:02 |
| ubot5 | bug 1195509 in Unity System Compositor "System compositor fails to start - Failed to set the current VT mode: Input/output error (5)" [Critical,Triaged] https://launchpad.net/bugs/1195509 | 03:02 |
| duflu | robert_ancell, I wasn't getting any logs. You expect that situation is better now? | 03:03 |
| robert_ancell | duflu, yes | 03:03 |
| duflu | cool | 03:03 |
| thomi | RAOF: presumably I need to copy the new mesa package into the s-c-testing PPA, right? | 03:04 |
| RAOF | thomi: Yes, please. | 03:05 |
| thomi | ok, they're building now | 03:06 |
| robert_ancell | RAOF, does X handle alt+ctrl+Fn? | 03:13 |
| RAOF | robert_ancell: I don't *think* so? Let me check. | 03:13 |
| robert_ancell | RAOF, normal X must right? | 03:13 |
| RAOF | Not necessarily? | 03:14 |
| robert_ancell | I'm just wondering if we need u-s-c to handle any key events at all | 03:14 |
| robert_ancell | How else would you switch to VT1 | 03:14 |
| RAOF | By the kernel handling ctrl-alt-F1, sending X signal saying "I'd like to VT switch", and X replying "sure, go ahead" | 03:14 |
| robert_ancell | Really? | 03:15 |
| duflu | RAOF: If it's not X then why is the combo different when inside X? | 03:15 |
| duflu | Outside of X, you don't need Ctrl | 03:15 |
| * robert_ancell -> EOD | 03:19 | |
| robert_ancell | RAOF, I'll ask you next week :) | 03:20 |
| RAOF | Sure! | 03:21 |
| RAOF | duflu: Possibly because of X setting the VT mode? | 03:22 |
| duflu | RAOF: You're saying X lets something outside of X handle Ctrl+Alt+Fn? | 04:00 |
| RAOF | So far I've not been able to find something *inside* X which handles it. | 04:00 |
| thomi | RAOF: new mesa built & published for amd64. going to reboot now | 04:10 |
| * thomi crosses fingers | 04:10 | |
| RAOF | Good lucjk! | 04:10 |
| thomi | RAOF: :( | 04:12 |
| thomi | RAOF: still crashes when booting with u-s-c enabled. Trying a normal boot now | 04:13 |
| thomi | RAOF: OK, that works! | 04:14 |
| thomi | so, as long as I don't reboot, I'm fine :-/ | 04:14 |
| RAOF | thomi: So u-s-c works after boot, but not if you boot to it? | 04:28 |
| thomi | RAOF: correct | 04:28 |
| RAOF | Ok. Have you tried the various "not splash" options of a direct boot? | 04:28 |
| thomi | no, I'll try that next | 04:29 |
| thomi | running some perf benchmarks at the moment | 04:29 |
| RAOF | Cool. | 04:30 |
| thomi | RAOF: with the splash screen turned off I get the same hang as before | 04:35 |
| RAOF | Ok, some additional crazy on boot, then. | 04:36 |
| thomi | yeah | 04:36 |
| RAOF | Plausibly I should pull in a newer xf86-video-intel :) | 04:36 |
| thomi | go on, do it! :) | 04:36 |
| RAOF | Also plausibly switching to SNA... | 04:38 |
| RAOF | Hm, no relevant commits to xf86-video-intel. | 04:39 |
| RAOF | Mainly because upstream cares only for sna now :/ | 04:40 |
| thomi | what's sna? | 04:42 |
| RAOF | The new acceleration architecture. | 04:45 |
| thomi | RAOF: so, what should I do from here? | 04:56 |
| RAOF | thomi: It's exactly the same hang? ie: you still have dmesg with an intel gpu hang in it, unity-system-compositor logs "can't set VT mode", etc? | 04:57 |
| thomi | RAOF: hmm, the dmesg message is gone, but the u-s-c message is the same | 04:58 |
| thomi | u-s-c log is: http://paste.ubuntu.com/5806808/ | 04:58 |
| RAOF | Ok. So, we've replaced your hang with a different problem; can you VT switch once it's failed to boot? | 05:00 |
| thomi | RAOF: nope | 05:02 |
| thomi | RAOF: It hasn't even blanked the screen, I see the boot messages still | 05:02 |
| RAOF | Hm. If you wait a bit, does the gpu hang message appear in dmesg? | 05:02 |
| RAOF | I didn't think we'd be able to get the system into a state where the GPU wasn't hung but you can't VT switch. | 05:02 |
| thomi | RAOF: I can't see it - I'm looking at 'dmesg | grep intel' - there are a few messages, but nothing that looks like an error | 05:03 |
| RAOF | Hrm. | 05:06 |
| RAOF | Can you ssh in and start lightdm?L | 05:06 |
| thomi | RAOF: it says lightdm is already running | 05:07 |
| thomi | trying to restart lightdm | 05:08 |
| tvoss_ | good morning all :) | 05:08 |
| RAOF | Morning tvoss_! | 05:08 |
| thomi | RAOF: when I restart lightdm, it works fine | 05:08 |
| thomi | hi tvoss_ | 05:08 |
| tvoss_ | hey guys, how goes? | 05:08 |
| thomi | RAOF: so it seems to be a problem with the initial boot only | 05:08 |
| RAOF | thomi: Right. This has gone from "I lock your GPU! HAAHAHAHAHAHAAH!" | 05:08 |
| RAOF | To "we're still racing with plymouth somewhere, sigh" | 05:08 |
| thomi | tvoss_: found some problems with xmir on intel, but slowly fxing them | 05:08 |
| thomi | RAOF: yeah | 05:09 |
| thomi | RAOF: I might try rebooting a few times to see if it alway fails on boot, or only sometimes | 05:09 |
| tvoss_ | thomi, problems? a little more detail would help :) | 05:09 |
| thomi | RAOF: initially we were hanging the GPU, but an updated mesa fixed that issue. Now there seems to be a race with plymouth where, upon initial boot, you don't get a lightdm, and can't VT switch | 05:10 |
| RAOF | tvoss_: Oh, btw I'm pretty sure we can use umockdev for our tests, too. | 05:11 |
| thomi | oops, I mean tvoss_ ^^ | 05:11 |
| tvoss_ | thomi, fix it :) if we can get of the gpu hangs, I have hardly any issues with mir on intel | 05:13 |
| tvoss_ | RAOF, umockdev as in the google version? | 05:13 |
| RAOF | tvoss_: As in pitti version. | 05:13 |
| RAOF | The google version didn't seem to be super fleshed out. | 05:14 |
| tvoss_ | RAOF, yeah, came to the same conclusion, it's really only a test helper | 05:14 |
| tvoss_ | RAOF, thomi is umockdev integrated with autopilot? | 05:14 |
| thomi | tvoss_: no | 05:14 |
| RAOF | I don't think we'd need to? | 05:14 |
| RAOF | We can use it in perfectly normal gtest test cases. | 05:15 |
| RAOF | All we need to do is LD_PRELOAD the appropriate library, and it turns out that I've already written code to add that to our test suite. | 05:15 |
| tvoss_ | RAOF, ah, that's cool :) some tiny wrapper would make me even happier, though :) | 05:19 |
| RAOF | What do you mean by a tiny wrapper? Do you mean wrapping the umockdev API up in a class? | 05:20 |
| RAOF | That would be a wrapper so tiny that I'd feel it was superfluous :) | 05:20 |
| tvoss_ | RAOF, then just use it I would say :) | 05:21 |
| tvoss_ | thomi, RAOF I would think that we should extend the reporting for the LinuxVirtualTerminal implementation | 05:21 |
| tvoss_ | we will enable reporting for the core components to stderr and thus to the lightdm unity-system-compositor.log | 05:22 |
| RAOF | Yeah, that'd be good. | 05:23 |
| thomi | tvoss_: sounds good to me | 05:24 |
| thomi | I gotta go help with dinner - will be back later | 05:25 |
| didrocks | waow, the new sso layout is… surprising | 05:38 |
| didrocks | finished emails before 8, not a bad day \o/ | 05:38 |
| didrocks | tvoss_: RAOF: do you mind acking that one? at least, it's giving one step closer to have mir building on armhf: https://code.launchpad.net/~didrocks/mir/add-valgrind-build-dep/+merge/171960 | 05:40 |
| tvoss_ | didrocks, looking | 05:41 |
| * didrocks is still concerned about bug #1195265 | 05:41 | |
| ubot5 | bug 1195265 in Mir "tests stuck on armhf" [High,New] https://launchpad.net/bugs/1195265 | 05:41 |
| tvoss_ | RAOF, did you alter -Bsymbolic-functions to -Bsymbolic, yet? | 05:42 |
| RAOF | tvoss_: No. I stopped doing the thing that was triggering that bug. | 05:42 |
| tvoss_ | didrocks, let me give you a top-approve, too | 05:43 |
| tvoss_ | didrocks, when jenkins says go for it :) | 05:43 |
| tvoss_ | didrocks, is that hang only happening on the buildd's? | 05:44 |
| didrocks | tvoss_: not sure, I don't have a pbuilder ready, at least, the hang is reproduceable in the buildd's | 05:47 |
| tvoss_ | didrocks, jenkins is building armhf, too. kinda curious what it has to say about your branch adding valgrind | 05:48 |
| === jono is now known as Guest59629 | ||
| didrocks | tvoss_: is it? I don't see armhf results: https://code.launchpad.net/~robert-ancell/mir/xmir-diagnostic-recovery-docs/+merge/171712 | 05:52 |
| didrocks | i386 and amd64 only | 05:52 |
| tvoss_ | didrocks, oh, thx for the info | 05:53 |
| didrocks | tvoss_: duflu reverted without talking on IRC | 05:53 |
| didrocks | duflu: I want the maximum quality before we release a package | 05:54 |
| duflu | didrocks: Yes, I have lots of questions. See the MP | 05:54 |
| didrocks | duflu: why removing valgrind then? | 05:54 |
| didrocks | duflu: and if so, why if vaglgrind is not installed, the package build will fail because of no valgrind? | 05:54 |
| duflu | didrocks: That's possibly a CMake bug. It's meant to (and does for me) elegantly skip valgrind if it's not installed | 05:55 |
| didrocks | duflu: Recommends: doesn't change anything for building the package | 05:55 |
| didrocks | duflu: I would prefer we have all available tests executed | 05:55 |
| duflu | didrocks: Absolutely. But that's not a requirement for other people building Mir | 05:55 |
| didrocks | duflu: in that case, don't build the package | 05:56 |
| didrocks | but the upstream source | 05:56 |
| didrocks | duflu: OTOH, on the other archs, valgrind is already pulled during package build due to some other requirements | 05:56 |
| didrocks | so you are not fixing anything here | 05:56 |
| tvoss_ | duflu, trying to understand your concern. Mind elaborating a bit? | 05:57 |
| duflu | didrocks: OK, I give in. Approved. I think we're limited by our tools and deb | 05:57 |
| duflu | tvoss_, all explained in the MP | 05:57 |
| didrocks | duflu: I don't see the concern TBH… but thanks :) | 05:57 |
| duflu | tvoss_, normally you should never declare something a requirement unless it's required | 05:57 |
| didrocks | it is required by our quality standards I would say | 05:58 |
| didrocks | as we are build-dep on stuff to run tests | 05:58 |
| didrocks | you can argue it's not a requirement per see | 05:58 |
| RAOF | But it is a requirement - we require to run the valgrind tests? | 05:58 |
| didrocks | but it's one by our stadnards :) | 05:58 |
| RAOF | When we're building in the archive. | 05:58 |
| duflu | didrocks: Yeah debian needs more levels of grey | 05:58 |
| didrocks | duflu: but I agree there is a bug in MirCommon | 05:58 |
| didrocks | duflu: how so? we don't provide multiple "build level", not sure what you meant? :) | 05:59 |
| didrocks | we can have something like an alternative | 05:59 |
| RAOF | duflu: Build-depends in Debian are almost always a super-set of the minimum possible. They're also not something that anyone normally objects to? | 05:59 |
| duflu | RAOF: OK. I guess it doesn't matter if we're working toward distro-agnostic build instructions anyway | 06:00 |
| tvoss_ | didrocks, do you want to file the bug or shall I? | 06:01 |
| didrocks | tvoss_: for the valgrind detection? please do | 06:01 |
| didrocks | tvoss_: it's weird, it's working well on other archs | 06:01 |
| didrocks | like https://launchpadlibrarian.net/143541061/buildlog_ubuntu-saucy-i386.mir_0.0.6%2B13.10.20130627ubuntu.unity.next-0ubuntu1_UPLOADING.txt.gz | 06:02 |
| didrocks | not on armhf | 06:02 |
| didrocks | https://launchpadlibrarian.net/143544949/buildlog_ubuntu-saucy-armhf.mir_0.0.6%2B13.10.20130627ubuntu.unity.next-0ubuntu1_FAILEDTOBUILD.txt.gz | 06:02 |
| didrocks | tvoss_: but OTOH, the stuck armhf tests are more important IMHO | 06:02 |
| tvoss_ | didrocks, fair, medium priority then | 06:03 |
| didrocks | RAOF: do you have any idea of what can stuck the tests? | 06:03 |
| didrocks | tvoss_: yep :) | 06:03 |
| tvoss_ | didrocks, how can I get access to the buildd setup to try and reproduce locally? | 06:03 |
| didrocks | tvoss_: I tried on pbuilder with cross-compile, didn't succeed | 06:03 |
| RAOF | didrocks: tvoss is the expert in debugging stupid PPA buildds and their stupid 30-year-old kernel bugs :) | 06:03 |
| didrocks | ahah :p | 06:03 |
| didrocks | RAOF: you infer that he loves that too? :p | 06:04 |
| tvoss_ | didrocks, I spent 4 days in lala-land, I'm a bit hesitant to go their again | 06:04 |
| didrocks | tvoss_: the thing is that we have a build stuck now | 06:04 |
| didrocks | tvoss_: so #webops can help knowing the current state I guess | 06:04 |
| didrocks | tvoss_: https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+build/4751091 | 06:04 |
| didrocks | tell me we're taking the builder in hostage :p | 06:05 |
| tvoss_ | didrocks, that one is terminated isn't it? | 06:05 |
| didrocks | I see this Session terminated, terminating shell... ...terminated. | 06:05 |
| didrocks | but the build is in that state for at least 12h | 06:05 |
| tvoss_ | argh ... | 06:05 |
| didrocks | (I think it started at 6PM) | 06:05 |
| didrocks | tvoss_: I can relaunch the build if they kill it | 06:05 |
| tvoss_ | didrocks, mind talking to them? | 06:06 |
| didrocks | sure | 06:06 |
| didrocks | tvoss_: ask done, but I see no Vanguard | 06:06 |
| tvoss_ | didrocks, \o/ | 06:07 |
| tvoss_ | yell at someone | 06:07 |
| didrocks | :) | 06:07 |
| * duflu would be keep to see said 30yo kernel bugs RAOF mentions ;) | 06:08 | |
| duflu | -keep +keen | 06:08 |
| tvoss_ | duflu, it's a hardy kernel running a saucy chroot | 06:08 |
| didrocks | duflu: "I'm using Linux for at least 40 years" :) | 06:08 |
| didrocks | "and ubuntu for even more" | 06:08 |
| duflu | Yeah, me too. 50 if you count when it was just cogs and pulleys | 06:09 |
| didrocks | ;) | 06:09 |
| tvoss_ | didrocks, https://bugs.launchpad.net/mir/+bug/1195590 | 06:13 |
| ubot5 | Launchpad bug 1195590 in Mir "cmake/MirCommon.cmake fails in detecting that valgrind is not installed" [Medium,New] | 06:13 |
| didrocks | tvoss_: confirmed | 06:15 |
| tvoss_ | didrocks, ack | 06:16 |
| RAOF | mlankhorst: Where did the PPA with xserver 1.14 go? | 06:23 |
| mlankhorst | canonical-x/x-staging? | 06:27 |
| RAOF | Ah, of course! | 06:28 |
| tvoss_ | RAOF, want to have a quick glance at https://code.launchpad.net/~afrantzis/mir/fix-render-surfaces-vt-switch/+merge/171755 | 06:38 |
| tvoss_ | RAOF, lgtm and I would top-approve | 06:38 |
| tvoss_ | duflu, ^ | 06:38 |
| tvoss_ | okay guys, taking another screencast :) | 06:40 |
| tvoss_ | back in a few | 06:40 |
| RAOF | duflu is too fast | 06:40 |
| duflu | If that were true I would have started on VESA already :P | 06:41 |
| RAOF | By "vesa" I assume we mean "fbdev", right? | 06:42 |
| duflu | RAOF: Yeah whatever it ends up being | 06:43 |
| duflu | I have lots of testing and research to do yet | 06:43 |
| duflu | RAOF: Looks like I will be pushing it to finish my new proposal for thread safety this week. So no fbdev work | 06:47 |
| duflu | Does anyone else think Mir's default glClear colour should be not-black? Black makes it less obvious that something like a Mir server owns the screen | 06:48 |
| duflu | ... kind of like X with its default root pattern | 06:48 |
| duflu | ... and not aubergine either ;) | 06:50 |
| didrocks | duflu: orange? :) | 06:51 |
| didrocks | would be ubuntuish :p | 06:51 |
| duflu | didrocks: I thought Orange was an obvious no :) | 06:51 |
| duflu | obvious "No" | 06:51 |
| duflu | RAOF: Oh, now that raring support is back, I can test various graphics cards if need be | 06:53 |
| sgx1 | hi, i'm an ubuntu user. when will we test mir in Saucy without adding the mir ppa ? | 07:10 |
| tvoss_ | sgx1, hey there, didrocks would be the best person to answer that question ^ | 07:11 |
| didrocks | sgx1: there is a build issue on armhf, and some bugs to fix before entering the distro | 07:13 |
| didrocks | so once https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy is fixed and we have the integration tests in autopilot form (robert is working on that), we are good for distro | 07:14 |
| didrocks | this is something the mir team here can answer and tvoss_ (back to you dude! :p) | 07:14 |
| didrocks | tvoss_: grrr, I went out of battery once again even if I shutted down ubuntu touch, with the power button, is it really shutting it down? I'm wondering | 07:15 |
| didrocks | tvoss_: I'm recharging it and will try an armhf build on that just to ensure we don't reproduce it locally | 07:15 |
| tvoss_ | sgx1, helps? | 07:17 |
| duflu | didrocks: AFAIK it never shuts down. You have to: adb root ; adb shell ; poweroff | 07:20 |
| didrocks | duflu: even if I long press the button? I see no screen then, like if it was shut down | 07:21 |
| didrocks | but by experience it seems to clearly shows it's a wrong assumption :) | 07:21 |
| duflu | didrocks: That should work. But it will be an unclean power off. Once it is off, the screen will show the battery charging icon only | 07:22 |
| didrocks | duflu: right, that's what I'm pretty sure I saw last time, but this morning, no battery :/ | 07:23 |
| duflu | But maybe phablet has a shutdown option now. I haven't checked in a while | 07:23 |
| didrocks | hence this "I'm totally puzzle" :) | 07:23 |
| duflu | didrocks: Can you adb shell? If not then it's off. Totally user friendly | 07:24 |
| didrocks | duflu: oh nice tip! I'll definitively give it a try :) | 07:26 |
| tvoss | RAOF, any chance we can land https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 today? | 08:47 |
| ogra_ | is XMir supposed to run on arm already ? | 08:54 |
| ogra_ | (and if yes, what happens on devices that casn only use xfbdev because they are lacking an xserver) | 08:55 |
| tvoss | ogra_, nope, not yet. We are looking into vesa/fbdev support right now | 08:57 |
| tvoss | duflu, ping | 08:57 |
| ogra_ | ok | 08:57 |
| ogra_ | if you have something i'll happily test on my chromebook ... Mir should be fine if it is working on nexus10 (same driver and GPU) | 08:58 |
| tvoss | ogra_, https://bugs.launchpad.net/mir/+bug/1118903 | 08:58 |
| ubot5 | Launchpad bug 1118903 in Mir "System compositor lacks a software rendering backend" [High,Triaged] | 08:58 |
| tvoss | ogra_, sure, I'll let you know | 08:58 |
| ogra_ | yeah, that bug isnt exactly the same thing i mean :) | 09:00 |
| ogra_ | i was talking about setups where you actually have drivers to have composite but there is no Xserver (i would assume thats the majority of arm devices)... would it be possible to have Mir use the driver to have composite and an fbdev implementation for XMir | 09:01 |
| ogra_ | ? | 09:01 |
| duflu | tvoss: pong | 09:03 |
| duflu | ogra_: I am about to begin fbdev exploration on Monday, hopefully | 09:06 |
| ogra_ | great | 09:06 |
| didrocks | simple and kind small MP: https://code.launchpad.net/~didrocks/unity-system-compositor/correct-copyright-url/+merge/171970 :) | 09:11 |
| xnox | RAOF: =)))) ok. i'll file bugs about it not being mirrored. my setup is "interesting". | 09:28 |
| hikiko | https://www.youtube.com/watch?v=AiL6XQQc_4Y the nested gbm display worked :) | 09:37 |
| hikiko | I am moving to the buffer allocation now | 09:37 |
| tvoss | hikiko, \o/ | 09:39 |
| alf | hikiko: great! | 09:43 |
| hikiko | :D | 09:45 |
| tvoss | RAOF, if still about: the updated mesa in the system-compositor testing ppa fixes the gpu hang, right? | 10:13 |
| RAOF | Fixes *an* intel GPU hang, yes. | 10:14 |
| tvoss | RAOF, :) | 10:15 |
| greyback | tvoss: ROAF: need a tester? I was getting that hang quite frequently, so switched back to normal X | 10:43 |
| tvoss | RAOF, is the ppa in a good state? | 10:43 |
| tvoss | greyback, not using chrome helps a lot :) | 10:43 |
| greyback | tvoss: hmm, will give it a try anyway | 10:45 |
| RAOF | tvoss: The PPA is indeed in a good state. | 10:45 |
| tvoss | RAOF, cool, thx | 10:49 |
| RAOF | Dear internet: *faster* | 10:49 |
| tvoss | RAOF, rofl | 10:50 |
| RAOF | If someone with a pipe fatter than 30kbit/sec to launchpad felt like it they could test xserver 1.14 from ppa:raof/aubergine. | 10:54 |
| tvoss | RAOF, what do you want me to test? | 10:56 |
| RAOF | That xmir works, basically. | 10:56 |
| tvoss | RAOF, do I just need that ppa? | 10:59 |
| RAOF | Yeah. | 11:00 |
| tvoss | but I can stay on system-compositor-testing? | 11:00 |
| * tvoss has started download and upgrade | 11:00 | |
| RAOF | Yes | 11:01 |
| * tvoss grabs coffee, should be there in 3 | 11:01 | |
| tvoss | RAOF, see you in a bit, hopefully :) | 11:09 |
| tvoss_ | RAOF, back | 11:11 |
| tvoss_ | RAOF, all good as far as I can tell | 11:14 |
| * duflu -> dinner, weekend | 11:17 | |
| bregma | tvoss_, are you going to propose a merge for your branch fixing #1194017 (embedded gmock removal)? | 12:43 |
| tvoss_ | bregma, sure, but we need a newer gmock | 12:43 |
| tvoss_ | in the archive, not sure what the status is there | 12:44 |
| bregma | is there a bug open for that work item? | 12:44 |
| tvoss_ | bregma, let me find it | 12:47 |
| tvoss_ | or better: didrocks, do you have the bug for ftbfs for gmock handy? | 12:47 |
| bregma | google-mock in raring and saucy is the latest upstream release | 12:53 |
| didrocks | tvoss_: there is a fixed version, syncing with debian, but we need all rdepends to use the source and rebuild there mock instead of relying on the shared librairie | 12:58 |
| tvoss_ | didrocks, thx for the update | 13:02 |
| tvoss_ | bregma, in that case it should be a matter of adjusting the add_subdirectory in Mir's top-level cmake | 13:03 |
| didrocks | tvoss_: if someone has time to deal with it, would be great to open a bug and list all components, I'll take care of that next one :) | 13:03 |
| tvoss_ | didrocks, ;) | 13:03 |
| didrocks | bregma: you are debugging the hung and the MirCommon.cmake issue then? | 13:26 |
| bregma | didrocks, yeah, but arm builds take a looooong time | 13:27 |
| didrocks | bregma: tvoss_: I'm almost done building Mir on the nexus4, I will be able to tell you if the test issue is a buildd one or something else | 13:27 |
| didrocks | bregma: don't tell me, I started it 1h30 ago :p | 13:27 |
| didrocks | 90% | 13:27 |
| bregma | samesies, except I'm using qemu | 13:28 |
| bregma | haven't got to the tests yet | 13:28 |
| * didrocks makes some useless support noise for his phone, before thinking it's useless :p | 13:28 | |
| didrocks | bregma: I cross fingers we can reproduce and it's not a stupid buildd-only issue | 13:28 |
| bregma | I suspect there is an issue running tests through valgrind on arm, and if we avoid that everything will be shiny | 13:30 |
| didrocks | bregma: yeah, but not sure it's wise to avoid valgrinding in our main target arch | 13:33 |
| didrocks | bregma: either my phone is really really slow | 13:34 |
| didrocks | bregma: or I'm confirmining the hang on my nexus 4 | 13:34 |
| didrocks | tvoss_: FYI ^ | 13:34 |
| didrocks | (the tests takes few milliseconds normally and it's been 30s) | 13:34 |
| tvoss_ | didrocks, ack and thanks | 13:34 |
| tvoss_ | didrocks, mind running ctest -V? | 13:35 |
| didrocks | tvoss_: sure | 13:35 |
| didrocks | and installs pastebinit :p | 13:36 |
| didrocks | tvoss_: http://paste.ubuntu.com/5807793/ | 13:36 |
| didrocks | oh | 13:37 |
| didrocks | this time, it passed | 13:37 |
| didrocks | let me retry this run | 13:38 |
| didrocks | ok, maybe I didn't wait enough, after 30s, now every time, I see the tests progressing | 13:38 |
| didrocks | so, let's see until where it's going (I | tee anyway) | 13:38 |
| didrocks | tvoss_: ok, lot of failures, but things moved | 13:45 |
| didrocks | and finished with integration-tests ................***Exception: SegFault107.32 sec | 13:45 |
| didrocks | http://paste.ubuntu.com/5807816/ | 13:46 |
| * didrocks now retries without -v and time it | 13:46 | |
| tvoss_ | didrocks,here is the point: it tries to build for the android graphics backend | 13:49 |
| bregma | didrocks, tvoss_ , the problem didrocks is seeing is a combination of running the test on an actual running phone and http://code.google.com/p/googletest/issues/detail?id=247 | 14:23 |
| bregma | the test is designed to fail if it's run on a real live android system, but a flaw in gtest means the test gets run without proper initialization | 14:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!