=== ValicekB_ is now known as ValicekB
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[10:57]  * alan_g reproduces something that looks like lp:1502782 \o/
[11:00] <alan_g> ...and the stack is complete @!"$£
[11:01] <anpok_> without any library unloading?
[11:03] <alan_g> anpok_: not sure yet. Only just found a formula for reproducing.
[11:04] <anpok_> we do keep the platform alive within server settings
[11:04] <anpok_> +library
[11:05] <anpok_> and the platform is also stored in display_server..
[11:05] <anpok_> (maybe a problem of the driver shutting down..)
[11:05] <alan_g> Ah, but AndroidHardwareSanity plays "silly bugger" with SetUpTestCase() and a static member variable.
[11:06] <anpok_> alan_g: btw, can you reproduce it only on krillin?
[11:06] <alan_g> anpok_: only tried on krillin so far
[11:06] <anpok_> me couldnt on mx4
[11:06] <anpok_> ok
[11:06] <alan_g> FWIW: $ gdb --args bin/mir_integration_tests --gtest_filter=AndroidHardwareSanity.* --gtest_repeat=2
[11:23] <alf> robert_ancell: Hi!
[11:23] <robert_ancell> alf, hi!
[11:24] <alf> robert_ancell: I filed a bug (enhancement really) for lightdm https://bugs.launchpad.net/lightdm/+bug/1506426
[11:24] <ubot5`> Ubuntu bug 1506426 in Light Display Manager "LightDM needs better log file rotation" [Medium,Triaged]
[11:24] <alf> robert_ancell: Looking at some other packages, I guess this should be handled at the packaging level
[11:25] <alf> robert_ancell: (if we use logrotate)
[11:25] <alf> robert_ancell: but I wanted to hear what your thoughts are on it
[11:25] <robert_ancell> alf, I don't know the best way to do this but we should probably match other packages. Being done in the packaging sounds good to me.
[11:26] <robert_ancell> I don't think LightDM wants to grow a super-sophisticated logging system
[11:26] <robert_ancell> What does Xorg do?
[11:29] <alf> robert_ancell: I agree. I took a look at upstart, it ships upstart.logrotate file with some rules. I don't know how well logrotate would interact with lightdm moving old log files to *.old.
[11:29] <robert_ancell> alf, we can look at disabling that if it's not necessary with logrotate
[11:29] <robert_ancell> It was just a cheap method of keeping the previous log
[11:31] <alan_g> kdub: is there something about what AndroidHardwareSanity.display_can_post_overlay uses that is dubious (seen on krillin)?
[11:31] <alan_g> Works: $ gdb --args bin/mir_integration_tests --gtest_repeat=8 --gtest_filter=AndroidHardwareSanity.*:-AndroidHardwareSanity.display_can_post_overlay
[11:31] <alan_g> Fails: $ gdb --args bin/mir_integration_tests --gtest_repeat=2 --gtest_filter=AndroidHardwareSanity.display_can_post_overlay
[11:32] <alan_g> probably bug 1502782
[11:32] <ubot5`> bug 1502782 in Mir "CI segfault in mir-mediumtests-runner-mako after AndroidHardwareSanity tests" [Medium,Confirmed] https://launchpad.net/bugs/1502782
[11:33] <kdub> alan_g, right, it pulls in the drivers, and trying to tear down and start up the drivers in the same process tends to be problematic in the driver code
[11:35] <alf> robert_ancell: do you have time to take a look, or should I?
[11:35] <robert_ancell> alf, if you have the time please do
[11:35] <alan_g> So you think this may be unrelated to the bug and just an effect of --gtest_repeat?
[11:36] <alf> robert_ancell: ok, and I should propose all changes (including packagin) against lp:lightdm?
[11:36] <robert_ancell> alf, yes please
[11:36] <alf> robert_ancell: ack
[11:37] <kdub> alan_g, right, last time I looked, it was the repeating that was the problem
[11:38]  * alan_g wonders if AndroidHardwareSanity is the only integration test case that loads drivers...
[11:39] <alan_g> kdub: Curious that it is triggered by that one test (when repeating the rest of the test case seems to work)
[11:39] <kdub> It should be the only integration test that loads the drivers
[11:41] <alan_g> Confirmed
[11:42] <anpok_> hm interesting .. is also that it only happens with basic .. here.
[11:42] <anpok_> nm, client in use does not matter
[11:46] <anpok_> it is just more easier to reproduce with it
=== alan_g is now known as alan_g|lunch
[12:59] <zzarr> hello! will XMIR be implemented in OTA-7? (if not will it in OTA-8?)
=== alan_g|lunch is now known as alan_g
[13:04] <alan_g> zzarr: Xmir won't be usable in OTA-7. I doubt it will be working well for OTA-8, but there is some progress happening.
[13:07] <zzarr> okey, alan_g, I wondered because a developer (don't remember a name) showed an image of a Nexus 4 running Firefox and GIMP
[13:07]  * alan_g left the AndroidHardwareSanity.* in a loop script over lunch and came back to a core file.
[13:09] <alan_g> zzarr: that's a WIP, not ready for general use. Most of the work there missed OTA-7 and not all of it is finished. There's a couple of weeks to land stuff for OTA-8 and IMO not everything will be ready in that timeframe.
[13:11] <zzarr> okey, thanks alan_g, but there's always a OTA-9 after OTA-8 and the hope is still there ;)
[13:14] <alan_g> zzarr: yes, it will certainly come but there's a lot of issues to trace through the software stack and only a few hands with time to spend on it. And depending on your intended usage there are other solutions (like gtk-mir).
[13:15] <zzarr> I have a ASUS ChromeBook Flip, is it possible to install MIR/Unity8 and XMIR if I install Ubuntu 15:10 and libhybris in a dualboot with the help of a android driver for the RK3288 SoC
[13:16] <zzarr> I know there's a gtk Java version, how do I install it on my MX4?
[13:20] <alan_g> zzarr: I've no idea about support for Chromebook hardware. Installing stuff on a phone is problematic. Maybe this is some help? http://accu.org/index.php/journals/2158
[13:20] <zzarr> many questions... but I really would like a Unity8 environment on the ChromeBook (since it can fold like a tablet)
[13:20] <zzarr> okey
[13:21] <zzarr> thanks
[13:28] <zzarr> alan_g, do you know how they will make the convergence work? I mean in a more technical aspect, will the desktop be a lxc inside the Phone system (lika an system app) and run desktop applications within that lxc? (in order to maintain OTA support)
[13:30] <alan_g> zzarr: I'm able to answer that.
[13:30] <alan_g> zzarr: I'm *not* able to answer that.
[13:32] <zzarr> okey, alan_g, thanks in any way :D
[13:33] <alan_g> kdub: anything spring to mind? https://bugs.launchpad.net/mir/+bug/1502782/comments/5
[13:33] <ubot5`> Ubuntu bug 1502782 in Mir "CI segfault in mir-mediumtests-runner-mako after AndroidHardwareSanity tests" [Medium,Confirmed]
[13:36] <kdub> alan_g, maybe check dmesg and /system/bin/logcat to see if there are any complaints?
[13:41] <alan_g> kdub: http://paste.ubuntu.com/12789072/
[13:41] <kdub> that "failed to close ion client" is some sort of driver problem, probably what's going on
[13:42] <kdub> *probably related to the error
[13:48] <alan_g> Is the (EGL_NOT_INITIALIZED) likely to be something
[13:50] <alan_g> kdub: *something* is racy - I've hacked in a small sleep at the end of the test and it runs nicely.
[13:51] <kdub> alan_g, the not initialized message doesnt concern me, although hard to rule it out completely
[13:53] <kdub> alan_g, we've had some problems in this area with this device only (quirk in mga::DeviceQuirks)
[13:56] <kdub> iirc, repeatedly opening and closing that module had some problems that we couldn't fix from the mir's side... and running it repeatedly within the same process like that will still try to open() and close() the module
[13:57] <alan_g> kdub: I'm restarting the process (while loop in the shell)
[13:58] <kdub> i guess though that I don't trust the synchronization of this module around open() and close() with the kernel
[14:00] <kdub> we could have an "if" dependent on that quirk that will introduce a sleep there
[14:00] <kdub> a bit of a workaround, but we don't have the sources for the module to try a root-cause/proper fix
[14:02] <alan_g> duflu added a "mako" tag, so I'm not sure it is krillin only
[14:03] <alan_g> ...although every instance I've seen in CI is krillin. So I think that's wrong
[14:06] <kdub> let me see if I can reproduce on mako
[14:07] <kdub> eh, there is a problem there too
[14:08] <alan_g> :(
[14:09] <alan_g> +    test_buffer.reset();
[14:09] <alan_g> +    std::this_thread::sleep_for(std::chrono::milliseconds(10));
[14:18] <anpok_> alan_g: that helps?
[14:18] <anpok_> quit
[14:18] <anpok_> wrong terminal
[14:18] <alan_g> anpok_: yes
[14:20]  * alan_g doesn't find it a very satisfying solution. kdub does it help mako too? (https://code.launchpad.net/~alan-griffiths/mir/workaround-1502782/+merge/274564)
[14:21]  * kdub is mid upgrade of the build, so wont know for a bit yet
[14:21] <kdub> build system
[14:22] <alan_g> np just hoped you were set up
[14:23]  * alan_g plugs in mako
[14:48] <anpok_> alan_g: I am tinkering with that on the mir_demo_server shutdown issue..
=== dandrader is now known as dandrader|afk
[16:07] <alan_g> anpok_: does any of it help with the  mir_demo_server shutdown?
[16:07]  * alan_g wishes mako was faster
[16:44] <anpok_> alan_g: that didnt help for the mir_demo_client_basic issue..
[16:45] <anpok_> alan_g: i wrapped the buffer allocator and added an object that will add a sleep after the allocator destruction..
[16:45] <alan_g> anpok_: thanks.
[16:46] <anpok_> didnt help.. but I also removed our global static ShardLibrary that currently keeps the graphics platform alive to not have the segfault on application exit.. but still no further clues..
=== alan_g is now known as alan_g|afk
=== dandrader|afk is now known as dandrader
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== chihchun is now known as chihchun_afk