robert_ancellRAOF, sounds fine - is there some time skew?00:00
RAOFrobert_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_ancelloh, right00:01
RAOFRather than [ +time_since_lightdm_start s] :)00:01
RAOFthomi: 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 that00:02
thomiRAOF: nope, It still hangs. The last boot line is something about 'startpar bridge'00:04
thomibrb, gotta get more caffeine in me00:04
thomithat's better00:24
thomiRAOF: so, anything I can do to try and get this working?00:24
RAOFthomi: Could you try booting without plymouth splash all together? That would be removing the ‘quiet splash’ line from the grub boot entry.00:25
RAOFthomi: 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
thomiRAOF: I'll try the first thing now. I don't know about the second thing, something to try later perhaps00:26
thomiturning off the boot splash all together makes no difference00:29
thomiRAOF: also, I get the same crash if I boot normally, enable u-s-c and then restart lightdm00:33
thomiRAOF: what should i do next?00:34
RAOFOk. So, we're doing something stupid then.00:34
RAOFOr maybe I just need to take a newer mesa snapshot :)00:34
RAOFthomi: Do the Mir demos render correctly?00:34
thomiI haven't tried them in a while, let me check00:35
thomiRAOF: yes, they work perfectly00:38
RAOFHm. Maybe xf86-video-intel damage then?00:38
thomianything I can do to test that hypothesis?00:39
RAOFSecond commit after our Mesa snapshot: Revert "i965: Disable unused pipeline stages once at startup on Gen7+."00:39
RAOFApparently causes GPU hangs.00:39
RAOFthomi: Allow me to cut a new mesa snapshot :)00:39
thomiyeah, thanks00:39
thomiI need to pick my girlfriend up from the airport, so maybe that'll be ready by the time I get back00:40
=== alex_abreu is now known as alex-abreu
=== asac` is now known as asac
RAOFHm. The jenkins mesa job doesn't seem to have worked.01:41
NikThHello everyone01:50
NikThI'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
thomiRAOF: no new mesa yet?01:53
thomiNikTh: good!01:53
RAOFthomi: The jenkins mesa job seems to have failed?01:53
* thomi looks01:53
NikThI 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.html01:53
RAOFNikTh: Oh, yes.01:54
NikThRAOF,  please explain .. I want to test this, no matter if I brake the system down :P01:54
RAOFYes, those instructions should work.01:55
thomiRAOF: 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
RAOFthomi: Correct.01:55
NikThThe commands maybe are only examples or something, because their not exist. :(01:56
thomihmm, the git polling is set to @hourly01:56
thomiNikTh: those commands are now in /usr/lib/x86_64-linux-gnu/mir/examples01:56
thomiNikTh: or whatever your platform string is :)01:56
NikThThanks thomi . Thanks. :)01:56
RAOFAh. Documentation update time!01:57
NikThI will test it right now :)01:57
bschaeferany reason im getting this with the mir ppa?01:58
bschaeferunity-system-compositor : Depends: libmirserver0 (= 0.0.6bzr785saucy0) but 0.0.6bzr786saucy0 is to be installed01:58
bschaefer:( no lightdm01:58
NikThthomi,  what client you suggest ? mir demo client or mir demo client accelerated as first hit .01:58
NikThthomi, OK. No worries. I will test it either way. :)02:00
RAOFbschaefer: 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
NikThThanks again02:00
RAOFbschaefer: This is why we provide the system-compositor-testing PPA :)02:00
bschaeferRAOF, i see :), well no worries, I can just force start X for now02:01
* bschaefer hopes its built by tomorrow morning02:01
RAOFIt probably will be, but there'll also likely be a new mir to break things again.02:02
bschaeferRAOF, o yeah, i also wanted to point you to this stack trace I got yesterday from Xorg.log02:02
bschaeferwhile running Xmir02:03
RAOFInstall from system-compositor-testing ☺02:03
RAOFbschaefer: Looks like Mir has hung?02:03
bschaeferRAOF, yeah, I might as well do that at this point :)02:03
bschaeferRAOF, yeah, it ended up crashing X though02:03
RAOFNo, I don't think it did crash X.02:04
RAOFOh! mir_wait_for did eventually return.02:04
bschaeferRAOF, hm, as a giant error box with that stacktrace appeared, and it didn't seem like X was running02:05
RAOFThose backtraces are "whoops, something's blocking the event loop and we're still getting input events"02:05
RAOFYour log ends with [   373.614] Server terminated successfully (0). Closing log file.02:05
RAOFSomething decided to shutdown X, and it did.02:05
bschaeferRAOF, well it shut it down nicely :)02:06
bschaeferhopefully it isn't a recurring problem! also thanks again for pointing me to that other ppa :)02:07
RAOFBut there certainly is a bug in there - mir_wait_for shouldn't be blocking the mainloop for so long.02:07
bschaeferRAOF, are there any mir logging that would give more info?02:10
bschaeferor look at running mir trunk from through gdb to get a better stracktrace if it were to happen again?02:11
RAOFbschaefer: 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/119438402:12
ubot5Launchpad bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Medium,In progress]02:12
RAOFThat should dump a bunch of info relating to IPC.02:13
bschaeferRAOF, sweet, ill give that try02:13
bschaeferduflu, also hello! how was your vacation?02:15
duflubschaefer, was good thanks02:15
dufluBut I've been back a few weeks02:15
dufluSo all is "normal" again02:15
bschaeferduflu, nice, thats good02:16
bschaeferI also see you merge the cursor change :), though Im starting to miss that large orange one haha02:16
duflubschaefer: We can make it anything within 64x64. I suspect we will need an API for changing it too02:21
bschaeferduflu, in due time, but that API will be needed at some point :)02:22
NikThI'm back :)02:22
NikThExcept 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
NikThKeep up the good work guys and thank you again for the help :-)02:26
dufluNikTh, mir_demo_client actually does nothing by design. How did the unaccelerated one get stuck?02:29
dufluNikTh, did you say some client reported 457 FPS? That shouldn't happen right now02:30
dufluRAOF ^02:30
NikThduflu, 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
dufluNikTh, interesting. Normally it freezes (lower FPS) when a Mir client is not focussed. That shouldn't happen..02:33
NikThduflu, do you want me to record this with an external camera and upload it.. ? (if happens again of course :P )02:35
dufluNikTh, that would be great if you could. Just log all bugs at: https://bugs.launchpad.net/mir/+filebug02:35
NikThduflu, is this a bug really ? I thought more FPS are better :P (don't know technical stuff)02:36
dufluNikTh: 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
NikThI think 1 FPS was the mir_demo_client_accelerated only. All other demos was above.. 250 FPS or so.02:39
NikThI will test it again.. and I will try to record it this time. Thanks duflu  :)02:40
dufluNikTh, no problem. I think I need to test it for myself again..02:45
Nikth2duflu, 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
dufluNikth2, 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 of02:55
dufluNikth2, to run a basic Mir server you need to disable XMir first02:56
robert_ancellduflu, damn, you moved a bug to milestone 0.0.6, but I can't move it back to 0.0.5...02:56
Nikth2duflu, OK. I think I got it now.  Thank you.02:56
duflurobert_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 correct02:57
duflurobert_ancell: Any bug in progress already missed 0.0.5. Hence it's targeted for 0.0.602:59
robert_ancellduflu, it was re-opened, but I'm closing it again and using a new bug for 0.0.602:59
duflurobert_ancell, is it really a different bug?03:00
dufluI generally say reopen the old one unless an explicit fix was committed and tested03:00
robert_ancellduflu, well, the first bug didn't have detailed information, so it's just confusing - the new bug has a particular symptom03:00
duflurobert_ancell: If the old one lacked info, it should either be enhanced or marked incomplete. But not fixed03:01
robert_ancellduflu, changes were made that fixed the bug "black screen" for some people, thus it is fixed.03:02
dufluI haven't retested staging with system compositor to verify it properly03:02
dufluBah, that's enough time spent arguing03:02
robert_ancellduflu, 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 logs03:02
ubot5bug 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/119550903:02
duflurobert_ancell, I wasn't getting any logs. You expect that situation is better now?03:03
robert_ancellduflu, yes03:03
thomiRAOF: presumably I need to copy the new mesa package into the s-c-testing PPA, right?03:04
RAOFthomi: Yes, please.03:05
thomiok, they're building now03:06
robert_ancellRAOF, does X handle alt+ctrl+Fn?03:13
RAOFrobert_ancell: I don't *think* so? Let me check.03:13
robert_ancellRAOF, normal X must right?03:13
RAOFNot necessarily?03:14
robert_ancellI'm just wondering if we need u-s-c to handle any key events at all03:14
robert_ancellHow else would you switch to VT103:14
RAOFBy the kernel handling ctrl-alt-F1, sending X signal saying "I'd like to VT switch", and X replying "sure, go ahead"03:14
dufluRAOF: If it's not X then why is the combo different when inside X?03:15
dufluOutside of X, you don't need Ctrl03:15
* robert_ancell -> EOD03:19
robert_ancellRAOF, I'll ask you next week :)03:20
RAOFduflu: Possibly because of X setting the VT mode?03:22
dufluRAOF: You're saying X lets something outside of X handle Ctrl+Alt+Fn?04:00
RAOFSo far I've not been able to find something *inside* X which handles it.04:00
thomiRAOF: new mesa built & published for amd64. going to reboot now04:10
* thomi crosses fingers04:10
RAOFGood lucjk!04:10
thomiRAOF: :(04:12
thomiRAOF: still crashes when booting with u-s-c enabled. Trying a normal boot now04:13
thomiRAOF: OK, that works!04:14
thomiso, as long as I don't reboot, I'm fine :-/04:14
RAOFthomi: So u-s-c works after boot, but not if you boot to it?04:28
thomiRAOF: correct04:28
RAOFOk. Have you tried the various "not splash" options of a direct boot?04:28
thomino, I'll try that next04:29
thomirunning some perf benchmarks at the moment04:29
thomiRAOF: with the splash screen turned off I get the same hang as before04:35
RAOFOk, some additional crazy on boot, then.04:36
RAOFPlausibly I should pull in a newer xf86-video-intel :)04:36
thomigo on, do it! :)04:36
RAOFAlso plausibly switching to SNA...04:38
RAOFHm, no relevant commits to xf86-video-intel.04:39
RAOFMainly because upstream cares only for sna now :/04:40
thomiwhat's sna?04:42
RAOFThe new acceleration architecture.04:45
thomiRAOF: so, what should I do from here?04:56
RAOFthomi: 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
thomiRAOF: hmm, the dmesg message is gone, but the u-s-c message is the same04:58
thomiu-s-c log is: http://paste.ubuntu.com/5806808/04:58
RAOFOk. So, we've replaced your hang with a different problem; can you VT switch once it's failed to boot?05:00
thomiRAOF: nope05:02
thomiRAOF: It hasn't even blanked the screen, I see the boot messages still05:02
RAOFHm. If you wait a bit, does the gpu hang message appear in dmesg?05:02
RAOFI 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
thomiRAOF: I can't see it - I'm looking at 'dmesg | grep intel' - there are a few messages, but nothing that looks like an error05:03
RAOFCan you ssh in and start lightdm?L05:06
thomiRAOF: it says lightdm is already running05:07
thomitrying to restart lightdm05:08
tvoss_good morning all :)05:08
RAOFMorning tvoss_!05:08
thomiRAOF: when I restart lightdm, it works fine05:08
thomihi tvoss_05:08
tvoss_hey guys, how goes?05:08
thomiRAOF: so it seems to be a problem with the initial boot only05:08
RAOFthomi: Right. This has gone from "I lock your GPU! HAAHAHAHAHAHAAH!"05:08
RAOFTo "we're still racing with plymouth somewhere, sigh"05:08
thomitvoss_: found some problems with xmir on intel, but slowly fxing them05:08
thomiRAOF: yeah05:09
thomiRAOF: I might try rebooting a few times to see if it alway fails on boot, or only sometimes05:09
tvoss_thomi, problems? a little more detail would help :)05:09
thomiRAOF: 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 switch05:10
RAOFtvoss_: Oh, btw I'm pretty sure we can use umockdev for our tests, too.05:11
thomioops, 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 intel05:13
tvoss_RAOF, umockdev as in the google version?05:13
RAOFtvoss_: As in pitti version.05:13
RAOFThe 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 helper05:14
tvoss_RAOF, thomi is umockdev integrated with autopilot?05:14
thomitvoss_: no05:14
RAOFI don't think we'd need to?05:14
RAOFWe can use it in perfectly normal gtest test cases.05:15
RAOFAll 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
RAOFWhat do you mean by a tiny wrapper? Do you mean wrapping the umockdev API up in a class?05:20
RAOFThat 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 implementation05:21
tvoss_we will enable reporting for the core components to stderr and thus to the lightdm unity-system-compositor.log05:22
RAOFYeah, that'd be good.05:23
thomitvoss_: sounds good to me05:24
thomiI gotta go help with dinner - will be back later05:25
didrockswaow, the new sso layout is… surprising05:38
didrocksfinished emails before 8, not a bad day \o/05:38
didrockstvoss_: 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/17196005:40
tvoss_didrocks, looking05:41
* didrocks is still concerned about bug #119526505:41
ubot5bug 1195265 in Mir "tests stuck on armhf" [High,New] https://launchpad.net/bugs/119526505:41
tvoss_RAOF, did you alter -Bsymbolic-functions to -Bsymbolic, yet?05:42
RAOFtvoss_: No. I stopped doing the thing that was triggering that bug.05:42
tvoss_didrocks, let me give you a top-approve, too05:43
tvoss_didrocks, when jenkins says go for it :)05:43
tvoss_didrocks, is that hang only happening on the buildd's?05:44
didrockstvoss_: not sure, I don't have a pbuilder ready, at least, the hang is reproduceable in the buildd's05:47
tvoss_didrocks, jenkins is building armhf, too. kinda curious what it has to say about your branch adding valgrind05:48
=== jono is now known as Guest59629
didrockstvoss_: is it? I don't see armhf results: https://code.launchpad.net/~robert-ancell/mir/xmir-diagnostic-recovery-docs/+merge/17171205:52
didrocksi386 and amd64 only05:52
tvoss_didrocks, oh, thx for the info05:53
didrockstvoss_: duflu reverted without talking on IRC05:53
didrocksduflu: I want the maximum quality before we release a package05:54
dufludidrocks: Yes, I have lots of questions. See the MP05:54
didrocksduflu: why removing valgrind then?05:54
didrocksduflu: and if so, why if vaglgrind is not installed, the package build will fail because of no valgrind?05:54
dufludidrocks: That's possibly a CMake bug. It's meant to (and does for me) elegantly skip valgrind if it's not installed05:55
didrocksduflu: Recommends: doesn't change anything for building the package05:55
didrocksduflu: I would prefer we have all available tests executed05:55
dufludidrocks: Absolutely. But that's not a requirement for other people building Mir05:55
didrocksduflu: in that case, don't build the package05:56
didrocksbut the upstream source05:56
didrocksduflu: OTOH, on the other archs, valgrind is already pulled during package build due to some other requirements05:56
didrocksso you are not fixing anything here05:56
tvoss_duflu, trying to understand your concern. Mind elaborating a bit?05:57
dufludidrocks: OK, I give in. Approved. I think we're limited by our tools and deb05:57
duflutvoss_, all explained in the MP05:57
didrocksduflu: I don't see the concern TBH… but thanks :)05:57
duflutvoss_, normally you should never declare something a requirement unless it's required05:57
didrocksit is required by our quality standards I would say05:58
didrocksas we are build-dep on stuff to run tests05:58
didrocksyou can argue it's not a requirement per see05:58
RAOFBut it is a requirement - we require to run the valgrind tests?05:58
didrocksbut it's one by our stadnards :)05:58
RAOFWhen we're building in the archive.05:58
dufludidrocks: Yeah debian needs more levels of grey05:58
didrocksduflu: but I agree there is a bug in MirCommon05:58
didrocksduflu: how so? we don't provide multiple "build level", not sure what you meant? :)05:59
didrockswe can have something like an alternative05:59
RAOFduflu: 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
dufluRAOF: OK. I guess it doesn't matter if we're working toward distro-agnostic build instructions anyway06:00
tvoss_didrocks, do you want to file the bug or shall I?06:01
didrockstvoss_: for the valgrind detection? please do06:01
didrockstvoss_: it's weird, it's working well on other archs06:01
didrockslike https://launchpadlibrarian.net/143541061/buildlog_ubuntu-saucy-i386.mir_0.0.6%2B13.10.20130627ubuntu.unity.next-0ubuntu1_UPLOADING.txt.gz06:02
didrocksnot on armhf06:02
didrockstvoss_: but OTOH, the stuck armhf tests are more important IMHO06:02
tvoss_didrocks, fair, medium priority then06:03
didrocksRAOF: do you have any idea of what can stuck the tests?06:03
didrockstvoss_: yep :)06:03
tvoss_didrocks, how can I get access to the buildd setup to try and reproduce locally?06:03
didrockstvoss_: I tried on pbuilder with cross-compile, didn't succeed06:03
RAOFdidrocks: tvoss is the expert in debugging stupid PPA buildds and their stupid 30-year-old kernel bugs :)06:03
didrocksahah :p06:03
didrocksRAOF: you infer that he loves that too? :p06:04
tvoss_didrocks, I spent 4 days in lala-land, I'm a bit hesitant to go their again06:04
didrockstvoss_: the thing is that we have a build stuck now06:04
didrockstvoss_: so #webops can help knowing the current state I guess06:04
didrockstvoss_: https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+build/475109106:04
didrockstell me we're taking the builder in hostage :p06:05
tvoss_didrocks, that one is terminated isn't it?06:05
didrocksI see this Session terminated, terminating shell... ...terminated.06:05
didrocksbut the build is in that state for at least 12h06:05
tvoss_argh ...06:05
didrocks(I think it started at 6PM)06:05
didrockstvoss_: I can relaunch the build if they kill it06:05
tvoss_didrocks, mind talking to them?06:06
didrockstvoss_: ask done, but I see no Vanguard06:06
tvoss_didrocks, \o/06:07
tvoss_yell at someone06:07
* duflu would be keep to see said 30yo kernel bugs RAOF mentions ;)06:08
duflu-keep +keen06:08
tvoss_duflu, it's a hardy kernel running a saucy chroot06:08
didrocksduflu: "I'm using Linux for at least 40 years" :)06:08
didrocks"and ubuntu for even more"06:08
dufluYeah, me too. 50 if you count when it was just cogs and pulleys06:09
tvoss_didrocks, https://bugs.launchpad.net/mir/+bug/119559006:13
ubot5Launchpad bug 1195590 in Mir "cmake/MirCommon.cmake fails in detecting that valgrind is not installed" [Medium,New]06:13
didrockstvoss_: confirmed06:15
tvoss_didrocks, ack06:16
RAOFmlankhorst: Where did the PPA with xserver 1.14 go?06:23
RAOFAh, 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/17175506:38
tvoss_RAOF, lgtm and I would top-approve06:38
tvoss_duflu, ^06:38
tvoss_okay guys, taking another screencast :)06:40
tvoss_back in a few06:40
RAOFduflu is too fast06:40
dufluIf that were true I would have started on VESA already :P06:41
RAOFBy "vesa" I assume we mean "fbdev", right?06:42
dufluRAOF: Yeah whatever it ends up being06:43
dufluI have lots of testing and research to do yet06:43
dufluRAOF: Looks like I will be pushing it to finish my new proposal for thread safety this week. So no fbdev work06:47
dufluDoes 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 screen06:48
duflu... kind of like X with its default root pattern06:48
duflu... and not aubergine either ;)06:50
didrocksduflu: orange? :)06:51
didrockswould be ubuntuish :p06:51
dufludidrocks: I thought Orange was an obvious no :)06:51
dufluobvious "No"06:51
dufluRAOF: Oh, now that raring support is back, I can test various graphics cards if need be06:53
sgx1hi, 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
didrockssgx1: there is a build issue on armhf, and some bugs to fix before entering the distro07:13
didrocksso 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 distro07:14
didrocksthis is something the mir team here can answer and tvoss_ (back to you dude! :p)07:14
didrockstvoss_: 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 wondering07:15
didrockstvoss_: I'm recharging it and will try an armhf build on that just to ensure we don't reproduce it locally07:15
tvoss_sgx1, helps?07:17
dufludidrocks: AFAIK it never shuts down. You have to: adb root ; adb shell ; poweroff07:20
didrocksduflu: even if I long press the button? I see no screen then, like if it was shut down07:21
didrocksbut by experience it seems to clearly shows it's a wrong assumption :)07:21
dufludidrocks: That should work. But it will be an unclean power off.  Once it is off, the screen will show the battery charging icon only07:22
didrocksduflu: right, that's what I'm pretty sure I saw last time, but this morning, no battery :/07:23
dufluBut maybe phablet has a shutdown option now. I haven't checked in a while07:23
didrockshence this "I'm totally puzzle" :)07:23
dufludidrocks: Can you adb shell? If not then it's off. Totally user friendly07:24
didrocksduflu: oh nice tip! I'll definitively give it a try :)07:26
tvossRAOF, 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
tvossogra_, nope, not yet. We are looking into vesa/fbdev support right now08:57
tvossduflu, ping08: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
tvossogra_, https://bugs.launchpad.net/mir/+bug/111890308:58
ubot5Launchpad bug 1118903 in Mir "System compositor lacks a software rendering backend" [High,Triaged]08:58
tvossogra_, sure, I'll let you know08: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 XMir09:01
duflutvoss: pong09:03
dufluogra_: I am about to begin fbdev exploration on Monday, hopefully09:06
didrockssimple and kind small MP: https://code.launchpad.net/~didrocks/unity-system-compositor/correct-copyright-url/+merge/171970 :)09:11
xnoxRAOF: =)))) ok. i'll file bugs about it not being mirrored. my setup is "interesting".09:28
hikikohttps://www.youtube.com/watch?v=AiL6XQQc_4Y the nested gbm display worked :)09:37
hikikoI am moving to the buffer allocation now09:37
tvosshikiko, \o/09:39
alfhikiko: great!09:43
tvossRAOF, if still about: the updated mesa in the system-compositor testing ppa fixes the gpu hang, right?10:13
RAOFFixes *an* intel GPU hang, yes.10:14
tvossRAOF, :)10:15
greybacktvoss: ROAF: need a tester? I was getting that hang quite frequently, so switched back to normal X10:43
tvossRAOF, is the ppa in a good state?10:43
tvossgreyback, not using chrome helps a lot :)10:43
greybacktvoss: hmm, will give it a try anyway10:45
RAOFtvoss: The PPA is indeed in a good state.10:45
tvossRAOF, cool, thx10:49
RAOFDear internet: *faster*10:49
tvossRAOF, rofl10:50
RAOFIf 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
tvossRAOF, what do you want me to test?10:56
RAOFThat xmir works, basically.10:56
tvossRAOF,  do I just need that ppa?10:59
tvossbut I can stay on system-compositor-testing?11:00
* tvoss has started download and upgrade11:00
* tvoss grabs coffee, should be there in 311:01
tvossRAOF, see you in a bit, hopefully :)11:09
tvoss_RAOF, back11:11
tvoss_RAOF, all good as far as I can tell11:14
* duflu -> dinner, weekend11:17
bregmatvoss_, 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 gmock12:43
tvoss_in the archive, not sure what the status is there12:44
bregmais there a bug open for that work item?12:44
tvoss_bregma, let me find it12:47
tvoss_or better: didrocks, do you have the bug for ftbfs for gmock handy?12:47
bregmagoogle-mock in raring and saucy is the latest upstream release12:53
didrockstvoss_: 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 librairie12:58
tvoss_didrocks, thx for the update13:02
tvoss_bregma, in that case it should be a matter of adjusting the add_subdirectory in Mir's top-level cmake13:03
didrockstvoss_: 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
didrocksbregma: you are debugging the hung and the MirCommon.cmake issue then?13:26
bregmadidrocks, yeah, but arm builds take a looooong time13:27
didrocksbregma: 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 else13:27
didrocksbregma: don't tell me, I started it 1h30 ago :p13:27
bregmasamesies, except I'm using qemu13:28
bregmahaven't got to the tests yet13:28
* didrocks makes some useless support noise for his phone, before thinking it's useless :p13:28
didrocksbregma: I cross fingers we can reproduce and it's not a stupid buildd-only issue13:28
bregmaI suspect there is an issue running tests through valgrind on arm, and if we avoid that everything will be shiny13:30
didrocksbregma: yeah, but not sure it's wise to avoid valgrinding in our main target arch13:33
didrocksbregma: either my phone is really really slow13:34
didrocksbregma: or I'm confirmining the hang on my nexus 413:34
didrockstvoss_: FYI ^13:34
didrocks(the tests takes few milliseconds normally and it's been 30s)13:34
tvoss_didrocks, ack and thanks13:34
tvoss_didrocks, mind running ctest -V?13:35
didrockstvoss_: sure13:35
didrocksand installs pastebinit :p13:36
didrockstvoss_: http://paste.ubuntu.com/5807793/13:36
didrocksthis time, it passed13:37
didrockslet me retry this run13:38
didrocksok, maybe I didn't wait enough, after 30s, now every time, I see the tests progressing13:38
didrocksso, let's see until where it's going (I | tee anyway)13:38
didrockstvoss_: ok, lot of failures, but things moved13:45
didrocksand finished with integration-tests ................***Exception: SegFault107.32 sec13:45
* didrocks now retries without -v and time it13:46
tvoss_didrocks,here is the point: it tries to build for the android graphics backend13:49
bregmadidrocks, 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=24714:23
bregmathe 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 initialization14:25

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!