#ubuntu-mir 2013-10-07
<duflu> RAOF: Another mini-fix... https://bugs.launchpad.net/xmir/+bug/1233044
<ubot5> Ubuntu bug 1233044 in XMir "XMir fails to build: error: 'xmir_screen' has no member named 'dmps_on'" [Critical,In progress]
<alf_> alan_g: greyback: Good morning! I remember you had a conversation about _suspend vs _connection_lost. Did you reach a conclusion?
<greyback> alf_: hey, I was happy with alan_g's proposal to have separate signal
<alan_g> alf_: yes greyback agreed that a separate event was warranted
<alf_> alan_g: greyback: great, thanks
<budgee> Good morning team
<budgee> I just plugged in an external monitor to my X301 and Xmir ?? appeared to crash and then restart with the external correctly recognised.  I was able to use displays to change the location of the external and launcher placement and am typing this message now using the configuration.
<budgee> ie. I had to log back into Ubuntu and restart my apps after pluggin in the external.
<budgee> If there is some loggin i can send through that would be useful, please let me know.
<budgee> ps. Good morning here in SA - Good day wherever else you might be.
<budgee> Also, unplugging the external worked fine - reconfigured to laptop display only with no problem.
<alf_> budgee: https://bugs.launchpad.net/xmir/+filebug , please include at least the Xorg log of the crashed run (probably /var/log/Xorg.*.log.old). Note that xmir multimonitor support is under development, so not all issues have been ironed out yet.
<duflu> budgee: Try "ubuntu-bug mir"
<tvoss> good morning/afternoon/evening
<alan_g> tvoss: hello there
<tvoss> alan_g, hey :) back in service after my vacation
<alf_> tvoss: welcome back
<tvoss> alf_, thank you :)
<alan_g> tvoss_: welcome back (again)
<tvoss_> alan_g, yup :)
<alan_g> tvoss_: beyond using another process can you think of any way to remove the Mir endpoint when Mir dies with prejudice? (kill -9 and the like)
<tvoss_> alan_g, let me think
<alf_> alan_g: tvoss_: Do we care about the SIGKILL case (which we can't catch in-process)? We could handle at least SIGSEGV and SIGABRT in process. The only other solution I can see is handling this in a wrapper script (e.g. unity-system-compositor.sleep).
<tvoss_> alf_, fair point, I wonder if upstart is able to handle that scenario
<alan_g> alf_: tvoss_ I'm just wondering: if some cases require handling elsewhere anyway how much Mir should try to do?
<tvoss_> alan_g, my vote would be: as much as possible, perhaps defining a std::at_exit handler
<alan_g> tvoss_: Ok, I've been playing with that. But with SIGSEGV we are getting into "undefined behaviour" territory and can't make guarantees
<tvoss_> alan_g, sure, that's what I meant with "as much as possible" under usual constraints. Makes sense?
<alf_> alan_g: tvoss_: mir can catch all of the signals that are caused by internal malfunction, so it makes sense to do the little it can (probably just unlink("/tmp/mir_socket") and _exit()) in the handler
<tvoss_> alf_, yup, +1
<alan_g> tvoss_: alf_ - OK. I just hoped someone knew of a magic API that said "this endpoint only lasts as long as this process"
<davmor2> out of interest when wir becomes the default on the phone will there be the ability to do /home/user/.display-surfaceflinger for comparison of issues?
<davmor2> s/wir/mir
<ogra_> davmor2, no, but rm /home/phablet/.display-mir
<ogra_> the switch means in the beginning that we'll just put that file in place by default
<davmor2> ogra_: ah right so you are just enabling it like that initially then that's great
<ogra_> lool, oh, the livecd-rootfs change wont be enough btw
<ogra_> lool, it wont affect OTS updates ... probably a good first test scenario for the upgrade hooks :)
<ogra_> *OTA
<lool> ogra_: that's a good point
<ogra_> and we only want to set it once indeed
<budgee> alf_: duflu: ubuntu-bug mir bombs on package name.  What package name should I use? Output here: http://pastebin.com/HUf8qPes
<budgee> alf_: duflu: xserver-xorg-xmir ?
<alf_> budgee: yes, try with xserver-xorg-xmir, and we will retarget to mir if needed (but probably xmir is the right package anyway)
<budgee> alf_: done as https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1236353
<ubot5> Ubuntu bug 1236353 in xorg-server (Ubuntu) "Xmir crashes on plugging in external" [Undecided,New]
<alf_> budgee: great, thanks
<tvoss_> ogra_, ping
<budgee> alf_: the XXorgLogOld.txt has a segfault it in
<tvoss_> ogra_, is upstart able to clean up after a service? e.g., remove a stale socket?
<ogra_> yeah, do it in a "post-stop script"
<tvoss_> ogra_, got a documentation link handy?
<ogra_> tvoss_, http://upstart.ubuntu.com/cookbook/#post-stop
<tvoss_> alan_g|lunch, alf_ http://upstart.ubuntu.com/cookbook/#post-stop
<tvoss_> ogra_, thanks
<alesage> hi all, investigating a hang while changing wallpapers on phone, reproduces without fail under mir, any suggestions?  https://bugs.launchpad.net/ubuntu-system-settings/+bug/1234733
<ubot5> Ubuntu bug 1234733 in ubuntu-system-settings (Ubuntu) "Substituting wallpaper under mir produces blackout" [High,Incomplete]
<alf_> alesage: this sounds like it's related to https://bugs.launchpad.net/mir/+bug/1234609 which has a lot of duplicates (like the one you mention 1235195)
<ubot5> Ubuntu bug 1234609 in Mir "unity8 crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::shell::Surface::name()" [Critical,In progress]
<alesage> alf_ ok although I don't get the noted crash FWIW; will wait for a resolution of your linked bug and test again
<alesage> alf_, thx
<alan_g> tvoss_: I'd guess pre-start would be better - the real difficulty is that the stale endpoint interferes with starting a new process
<alf_> alesage: it could be something different indeed, but with 1234609 in the middle it's difficult to say
<tvoss_> alan_g, I think both might be a good idea
 * alan_g wonders where to put an upstart script
<tedg> alan_g, /usr/share/upstart/sessions
<alan_g> tedg: I meant where in which project. ;)
<tedg> alan_g, Ah, which ever has the binaries you're executing :-)
<kgunn> kdub: so, gerry & duflu reporting we actually didn't fix the "unable to screen blank" prob after all
<kgunn> https://bugs.launchpad.net/mir/+bug/1188504
<ubot5> Ubuntu bug 1188504 in Mir "Nexus4: Mir server dies when display goes to sleep ("error posting with fb device") and can no longer start ("could not unblank display")" [Critical,Triaged]
<kgunn> kdub: ^ can you take a look today ?
<kgunn> tvoss_: o/ welcome back
<tvoss_> kgunn, o/
<mlankhorst> wb
<kdub> kgunn, there are two issues (last i saw) that result in that error
<kgunn> racarr: ping
<kgunn> kdub: so, i just flashed latest, left it read only...enabled mir...and when screen idles/blanks...i can wake it no problem ?
<kgunn> kdub: is the problem still limited to killing/restarting unity8 ?
<kgunn> kdub: someone earlier said it was failing to "wake" when just idling...
 * kgunn hates bug rumors, prefers real data written down :-/
<kgunn> kdub: or maybe its intermittent... ?
<kdub> kgunn, i've seen a bug that happens when the screen times out, then you push power button
<kdub> you get 'cannot blank screen'
<kgunn> kdub: hmmm....but i'm sitting here doing that
<kdub> i also was seeing mir just not starting
<kdub> which i'm trying to verify now
<kgunn> kdub: i'm on mako, build 83
<kgunn> channel devel-proposed
<kgunn> fwiw i also do --no-backup
<kdub> let me verify that's what i'm using, that's what i flashed with
<kdub> kgunn, yes, 83, with channel devel-proposed
<kgunn> kdub: did you do --no-backup ? (wonder if that could be related)
<kdub> yes, all these flash switches are flummoxing though
<kgunn> kdub: ...even after i reboot, its still waking like a champ
<kgunn> kdub: just thinking of other deltas you and i might have...i don't have a sim card in my phone
<kdub> kgunn, mir was working for me without writable mode, so i don't think that's a factor
<kdub> i probably just wasn't controlling for the power button state
<kgunn> racarr: ping
<tvoss_> kdub, ping
<kdub> pong
<alan_g> alf_: does this make sense? https://code.launchpad.net/~alan-griffiths/mir/remove-endpoint-first-when-shutting-down/+merge/189376
<kgunn> tvoss_: hey  i know Saviq asked you to look at  mir  being suddnely slow 1235190, did you have something specific you were chasing?
<tvoss_> kgunn, I was more or less bisecting Mir changes
<kgunn> racarr: when you get on, can you please check in with dandrader|lunch for mir input 1233245
<kgunn> tvoss_: ack... if you conclude could also use help on the mir input 1233245
<kgunn> tvoss_: that is, unless racarr shows up and just says "oh i know..." :)
<tvoss_> kgunn, there are only 2 changes to mir that might affect rendering performance
<racarr> Morning
<racarr> kgunn: Yes willcheck it out in just a sec
<alan_g> Evening
<kgunn> racarr: thanks!
<kgunn> brb
<racarr> ok back
<racarr> dandrader|lunch: What went wrong with the input injector approach to
<racarr> 1233245?
<racarr> kgunn: Also on my plate is #1233564 (the stuff about compositor empty queue)
<racarr> and back to ABI stuff
<racarr> should I run with 1233245?
<racarr> alf_: Can you look at input-injecter-api again and at least needs fixing->abstain? I think I fixed your bits
<dandrader> racarr, Saviq said that such approach doesn't suffice. that we need unity8/shell to be the focused surface shen it's no foreground so that things like key events generated from autopilot reaches it, etc
<dandrader> s/shen/when
<dandrader> s/no/on
<dandrader> so many typos
<dandrader> and then the sheer number of interfaces, indirections, abstractions in mir regarding focus scared me off :)
<dandrader> intimidating
<racarr> ok
<racarr> but focus doesn't fix
<racarr> the volume keys unfortunately
<racarr> because unity8 needs to get volume keys when an app is focused
<racarr> so we have two issues I guess
<dandrader> racarr, but that's not importand
<racarr> really unity8 needs to use the event filters....
<dandrader> important
<racarr> ok.
<dandrader> for now, according to Saviq
<racarr> ok
<racarr> unity8 will need like an event filter
<racarr> that gives focus to touched surfaces
<racarr> and that should be enough
<dandrader> racarr, hmm. user swipes away foreground app. unity8 qml calls unfocusCurrentApplication() in unity-mir (or something like that)
<dandrader> at some point there unity8 should get focus in place of the unfocused app
<dandrader> without the user having to touch dash
<dandrader> if I understand you correctly
<racarr> oh
<racarr> so is it only
<racarr> replace:     m_mirServer->the_session_manager()->set_focus_to(NULL); //FIXME(greyback)
<racarr> with m_mirServer->the_session_manager->set_focus_to(shell_surface)
<racarr> except
<racarr> set_focus_To on the session manager
<racarr> takes
<racarr> a session
<dandrader> man, I spent quite a bit trying to find you how does unity-mir distinguish apps surfaces from the unity8 one :) (looked at qtubuntu, platform-api....)
<dandrader> s/you/out
<racarr> mm the surface source hack
<racarr> ok I need to think about the session thing
<tvoss|quick_dinn> dandrader, the key codes you pasted into https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1233245
<ubot5> Ubuntu bug 1233245 in unity-mir "[mir] key events not working through input devices (aka volume up/down)" [Critical,Triaged]
<tvoss|quick_dinn> are weird
<tvoss|quick_dinn> either it's 114 (down) and 115(up) or 24(up) and 25(down)
<dandrader> tvoss|quick_dinn, you mean here? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1233245/comments/6
<ubot5> Ubuntu bug 1233245 in unity-mir "[mir] key events not working through input devices (aka volume up/down)" [Critical,Triaged]
<dandrader> it's code 114 there
<dandrader> tvoss|quick_dinn, so it matches your expectations
<kgunn> racarr: sorry, went for a run...right, hate that its stacking up...but i would say bug 1233245
<ubot5> bug 1233245 in unity-mir "[mir] key events not working through input devices (aka volume up/down)" [Critical,Triaged] https://launchpad.net/bugs/1233245
<kgunn> then bug  1233564
<ubot5> bug 1233564 in Mir "Greeter is seen animating when pressing the side button to wake up" [High,Triaged] https://launchpad.net/bugs/1233564
<kgunn> then api/abi
<racarr> kgunn: Ok.
<racarr> that's fine :) I am just trying to get the picture
<kgunn> racarr: no prob... its like a salvador dali painting that changes
<kgunn> kdub: unable to blank made the list (of blockers)
<kgunn> kdub: just to verify...you actually can see this at your desk on mako, on the the latest image ?
<kdub> kgunn, lets sync on this
<kdub> via hangout
<kgunn> cool
<racarr> kgunn: You mean unable to unblank?
<kgunn> racarr: wrt questions to kdub...yeah unblank
<racarr> kdub: The only times I have seen this
<racarr> is when the display was already on
<kgunn> kdub: https://plus.google.com/hangouts/_/eb454b829a446623ced641778cf81d1c2ed71e11?pqs=1&authuser=0&hl=en
<racarr> when mir tried to start
<racarr> is it possible just that
<racarr> unblank returns an error
<racarr> when the screen is already unblanked
<davmor2> kgunn: this is probably already a bug but under mir whenever you select a text input point there is a random character deposited in the test field on maguro
<kdub> alf_, still around?
<tvoss_> kgunn, ping
<kgunn> tvoss_: pong
<dandrader> racarr, so, can I help you with anything regarding those input bugs that are blocking the "unity8-mir by default" story?
<racarr> dandrader: Back from lunch...hmm well it looks like
<racarr> fix-inputarea is ok (thanks for reviewing) I will double check it asap
<racarr> I think I have a plan on key events now.
<racarr> so not off the top of my head...unless I am missing an extra bug
<dandrader> ok
#ubuntu-mir 2013-10-08
<sarnold> pfew, finally done with the Mir MIR :) thanks everyone for your help to bring me up to C++11 speed quickly. :)
 * duflu reboots for live image testing
<tvoss_> good morning
<tvoss_> RAOF, ping
<RAOF> tvoss_: Pong.
<RAOF> Good afternoon.
<tvoss_> RAOF, good morning :) how is it going?
<RAOF> Pretty well.
<RAOF> It's getting quite hot in my office.
<RAOF> Which is nice at the moment.
<RAOF> Ask again in a month or two âº
<tvoss_> RAOF, ;) it's becoming quite chilly here in the morning, I would rather prefer some hot weather
<tvoss_> RAOF, catching up after vacation, what is our current status on radeon?
<RAOF> Working
<RAOF> With some glitches on multihead, but I don't think I've rechecked that after some of the multiple-surfaces fixes landed.
<tvoss_> RAOF, ack, will try it on my netbook :)
<duflu> RAOF: Frame ordering is all good. Since about Friday :D
<duflu> tvoss: There is a lingering radeon corruption bug, but it's much rarer this one --> bug 1233545
<ubot5> bug 1233545 in xserver-xorg-video-ati (Ubuntu) "XMir screen corruption on radeon chipset" [Critical,Confirmed] https://launchpad.net/bugs/1233545
<duflu> tvoss_ ^
<tvoss_> duflu, is that "than this one"?
<duflu> tvoss_: Oops. It's much rarer than the stripes bug. The remaining radeon bug is 1233545
<tvoss_> duflu, ack
<tvoss_> duflu, RAOF do we have a theory where the corruption bug arises from?
<duflu> tvoss_: No idea. AFAIK we don't have hardware that reproduces that one
<tvoss_> duflu, okay
<duflu> But multi-monitor glitches/ordering is fixed. Did I mention that enough times? :)
<tvoss_> duflu, yup, you did :) what was the final fix?
<tvoss_> duflu, or better: the underlying issue?
<duflu> tvoss_: The SessionMediator was not designed to handle multi-surface sessions --> https://code.launchpad.net/~afrantzis/mir/fix-out-of-order-buffers-1216472/+merge/187841
<tvoss_> duflu, great, thanks
<RAOF> Boo. The Radeon glitches haven't been magically fixed by fixing the out-of-order buffers.
<duflu> RAOF: Oh, you see glitches like the remaining open bug?
<RAOF> Yes.
<duflu> Cool
<duflu> Kind of
<RAOF> Under GPU load.
<RAOF> I suspect we're hitting a sort of synchronisation problem Intel magically handles for us in the kernel.
 * tvoss_ wishes for some standardized tracing information exported via lttng from the gpu drivers
<tvoss_> racarr, you around?
<racarr> tvoss_: Hey
<racarr> am now
<racarr> Was out at an open mic :D
<racarr> what's up?
<jibel> a crash easy to reproduce with Mir and latest build on mako (build #86), bug 1236705 . Could anyone have a look?
<ubot5> bug 1236705 in unity8 (Ubuntu) "unity8 crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [Critical,Confirmed] https://launchpad.net/bugs/1236705
<jibel> another Mir only crash easy to reproduce bug 1234152
<ubot5> bug 1234152 in qtdeclarative-opensource-src (Ubuntu) "qmlscene crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [High,Confirmed] https://launchpad.net/bugs/1234152
<jibel> the initial crash was with calendar-app but it is easier to reproduce with music-app
<duflu> greyback: I swear someone told me that touch apps were all fullscreen. Surely that's not true with the panel always visible... ?
<greyback> duflu: every app's surface is a fullscreen surface. The panel draws over the surface. To stop overlap, applications make sure not to draw where the panel is
<duflu> greyback: Oh. Is that a temporary approach?
<greyback> duflu: Yes. When we get resizeable surfaces we can fix it
<alan_g> duflu, hikiko: could you re-review https://code.launchpad.net/~alan-griffiths/mir/remove-endpoint-first-when-shutting-down/+merge/189376
<duflu> alan_g: Oh. I was about to log off, but seem to be blocking it
<hikiko> sure alan_g
<alan_g> duflu: Your life is more important than work
<duflu> alan_g: Sorry about that. The proposal is more important than I have time to commit tonight...
<duflu> I don't want to rush that one
<alan_g> duflu: np
<dandrader> kdub, ping
<dandrader> I'm getting http://paste.ubuntu.com/6208867/ when I try to run unity8 from an ssh terminal, after calling "stop unity8"
<dandrader> any ideas?
<dandrader> alf_, ^
<alf_> dandrader: looking
<dandrader> not even a  "start unity8"  works after that. only rebooting solves it.
<alf_> dandrader: haven't come across that before, which image/pkg versions are you?
<dandrader> just flashed it around an hour ago with devel-proposed
<dandrader> + those packages http://people.canonical.com/~msawicz/mir-input/
<dandrader> but I don't think those extra packages have anything to do with it. I've been suffered from it before...
<dandrader> alf_, and I'm using a galaxy nexus (maguro), if that's make any difference
<alf_> dandrader: ah, probably, I only have n4
<dandrader> :(
 * alan_g hates it when he has to reboot
<hikiko> alan_g, it works fine if I send the signals one by one
<hikiko> now I ll check the seg fault case
<alf_> alan_g: Could we get a SIGPIPE under normal circumstances when a client disconnects abruptly?
<alan_g> hikiko: you do see there's a test case that does that?
<alan_g> alf_: I'm not certain
<alf_> alan_g: in any case, I don't think we should be handling SIGPIPE,SIGALRM (i.e. non-fatal signals)
<hikiko> yes alan_g :)
<hikiko> cool!
<hikiko> let me link my bug report to your branch
<alf_> alan_g: I would also argue against SIGILL, since I know of at least one library (libcrypto) that uses SIGILL to check for the presence of special ARM instructions, and is used by unity8.
<alan_g> alf_: Posix says they are "Term" signals - so I thought there was an case for handling them
<alan_g> But I'll reduce the set. We can add more easily later
<alan_g> Gotta go now
<dandrader> alf_, FYI stopping powerd solved my problems with unity8 not initializing
<alf_> dandrader: thanks
<dandrader> dang it! now the problem is back again
<dandrader> celebrated too early
<alan_g> alf_: you happy with these? SIGQUIT, SIGABRT, SIGFPE, SIGSEGV, SIGBUS
<alf_> alan_g: yes
<alan_g> alf_: updated
<mterry> Can anyone review https://code.launchpad.net/~mterry/unity-mir/permissions/+merge/189718 today?  That would be great
<alf_> greyback: In unity-mir MirSurfaceManager::sessionDestroyingSurface() is there a reason we .erase() the MirSurface before sending the surfaceDestroyed() signal?
<alf_> tsdgeos: ^^ (see question above)
<tsdgeos> i'm not very much into unity-mir architecture tbh
<tsdgeos> but i'll have a quick look
<tsdgeos> alf_: is it causing any ptoblem?
<tsdgeos> from the "i know nothing about this"
<tsdgeos> it makes sense to me
<tsdgeos> kill it and then say "destroyed"
<tsdgeos> but otoh it's connected to something that is called destroyingSurface
<tsdgeos> so maybe the expectation from whoever calls here is that you warn before the surface is gone
<tsdgeos> can't really say much more than this without an extra mile of guessing :D
<tsdgeos> alf_: you probably want Gerry, but he's away at Qt Dev Days, shall be back on thursday i think
<alf_> tsdgeos: thanks
<jfunk> ping om26er
<om26er> jfunk, pong
<kgunn> kdub: ^ i think om26er gonna check if holding "performance" on pm policy is reasonable work around....finding out a) does system idle/screen blank if you hold perfromance?
<kgunn> b) how long does battery last/does it get hot ?
<jfunk> om26er, there you have it
<om26er> kgunn, I have been using it that way for the whole day. The phone does not get hot. I do think the battery drain is a bit faster
<jfunk> om26er, we're checking on this bughttps://bugs.launchpad.net/mir/+bug/1235190
<ubot5> Ubuntu bug 1235190 in mir (Ubuntu Saucy) "[mako] Unity8 on Mir got slow" [High,Confirmed]
<kdub> kgunn, om26er, yes, i'd expect the battery to drain a bit faster
<kgunn> om26er: so does the screen blank/go dark ?
<om26er> kgunn, kdub at the same time, I am also not seeing bug 1233257 anymore
<ubot5> bug 1233257 in powerd (Ubuntu Saucy) "[mako] waking from deep sleep, phone is pretty slow, takes a while to get back to normal speed" [High,Confirmed] https://launchpad.net/bugs/1233257
<kgunn> e.g. its allowed to idel
<om26er> kgunn, yes, The screen does turn off fine, automatically
<kgunn> ogra_: lool ^...so holding pm policy to performance does seem ok
<kgunn> tvoss: ^
<tvoss> kgunn, ack and thx for testing
<lool> ogra_: ^
<ogra_> kgunn, well, if you ignore the fact that battery life goes from 12-18h to ~5h
<kgunn> ogra_: hey man...you want performance or what ? :) jk
<kgunn> whats a couple of hours between friends
<om26er> ogra_, I don't think it goes to ~5h because I was out of the house for more than 6 hours and the battery was in a pretty good shape by then
<ogra_> kgunn, i would prefer if someone could actually properly research the issue instead of plastering a patch over it that just hides the fact that it is broekn
<ogra_> om26er, i can usually use my mako for about 12h with scren on
<tvoss> ogra_, we cannot afford investing the time to dive into the memory bus/cpu performance governors present
<kgunn> ogra_: more than happy to if you can convince people to give us the breathing ropom
<ogra_> om26er, after 30min with performance set and screen on i'm at 87%
<tvoss> ogra_, at least right now
<ogra_> tvoss, what does cpufreq to do with it
<ogra_> tvoss, you *abuse* cpufreq to hide a problem you dont want to research
<tvoss> ogra_, cpufreq to performance ensures that all subcomponents like memory bus speed, gpu speed etc. operate at full speed
<tvoss> ogra_, I *want* to research it, would love to do it, but not right now
<ogra_> tvoss, right, it forces everything to full speed
<ogra_> and keeps it there (unles powerd forces it off)
<ogra_> tvoss, it also doesnt change the issue at all on maguro
<ogra_> it still persistes there
<tvoss> ogra_, right, I'm totally aware of the implications, but we just don't have the breathing room right now for researching into the clean solution
<tvoss> ogra_, the bug report talks about mako, though, iirc
<ogra_> right just dont let it off the radar please
<ogra_> tvoss, well, i was asked to force performance on all devices based on that bug
<tvoss> lool, mind clarifying here?
<ogra_> (and i know for sure that this will break grouper ... performance is broken there due to android hackery)
<tvoss> lool, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1235190 is talking about mako only
<ubot5> Ubuntu bug 1235190 in mir (Ubuntu Saucy) "[mako] Unity8 on Mir got slow" [High,Confirmed]
<ogra_> (or probably nviodia hackery)
<ogra_> though given that Mir doesnt run at all on grouper thats surely ignorable
<tvoss> ogra_, it comes down to the nvidia driver using a process-shared pthread mutex, which we cannot support via hybris
<ogra_> tvoss, yeah
<ogra_> just saying that change wont fix your world ... it will only hide the issue on mako but wont help on others
 * tvoss avoids thinking about the sizeof differences for glibc and bionic pthread mutexes
<tvoss> ogra_, fair point, but it's not only a mir issue, everything else in the system should experience worse performance, too
<tvoss> kgunn, ^, thoughts?
<ogra_> tvoss, well, surely not the cpufreq governor :)
<kgunn> tvoss: agreed...
<kdub> yes, other things would be affected too
<kgunn> tvoss: altho...graphics is the one area we're ripping out the most of what was natively android and replacing
<tvoss> kgunn, fair
<kgunn> others might get lucky...like daft punk
<tvoss> ogra_, https://code.launchpad.net/~thomas-voss/location-service/refactor-packaging/+merge/189878
<ChickenCutlass> tvoss: lool it is a mistake to force performance on cpufreq
<ChickenCutlass> bad idea
<tvoss> ChickenCutlass, we only do it on mako
<ChickenCutlass> tvoss: bad idea
<ChickenCutlass> tvoss: -1
<rsalveti> can we prove with data that it actually helps?
<tvoss> ChickenCutlass, alternative proposals?
<ChickenCutlass> tvoss: fix the problem
<rsalveti> :-)
<tvoss> ChickenCutlass, not enough time right now
<ChickenCutlass> tvoss: we can not throttle the cpu at max
<tvoss> ChickenCutlass, seriously: we haven't experienced the issue with sf as powerd was just hanging with sf
<ChickenCutlass> tvoss: seriously do not do that
<tvoss> ChickenCutlass, what else then?
<ChickenCutlass> tvoss: not sure -- but can't do this
<ChickenCutlass> tvoss: battery will suck
<ChickenCutlass> the phone will get hot
<rsalveti> and this bug is a regression right?
<tvoss> ChickenCutlass, fair point, but: we need to investigate how we can selectively pull the memory bus and GPU back to full speed
<rsalveti> seems it was faster before
<rsalveti> pushing gpu is one thing
<tvoss> rsalveti, after we enabled support for powerd actually talking to u8/mir, yes
<rsalveti> pushing CPU is another thing
<tvoss> rsalveti, true, but we just don't have the infrastructure available right now to selectively pull the gpu
<rsalveti> right, but pushing CPU won't help much
<rsalveti> will cost at *lot*
<tvoss> rsalveti, it helps according to testers
<kdub> it turns up the axi bus on the phone, which is why it helps
<rsalveti> right, but we get a lot of side effect as well
<rsalveti> anyway, -1
<ChickenCutlass> tvoss: so help me understand -- why is this not a problem with SF but with mir?
<ChickenCutlass> tvoss: what does sf do that we do not
<ricmm> I still dont think this has anything to do with powerd
<tvoss> rsalveti, -1 is fine, but we need something a little more workable, let's say ;)
<ricmm> considering 95% of the bug is people saying that opening many apps had this problem
<ChickenCutlass> me eother
<ChickenCutlass> either
<ricmm> or letting the phone sleep overnight
<ricmm> which I did btw, last night
<ricmm> and it was fine in the morning, it jiggles for 5 seconds and then its fine
<tvoss> ChickenCutlass, I think we are experiencing
<ricmm> I'm certainly not seeing a 2 minute lag-down
<ricmm> also, that bug is about general slowness with Mir... not powerd and the resume issue people are seeing
<tvoss> ricmm, you might want to cross-check with kdub, he has looked into the issue quite deeply
<ricmm> kdub: ping
<ricmm> rsalveti: get back on
<rsalveti> ricmm: ok
<kdub> well, i can see mir's demo programs going very slowly too
<kdub> and when i turn the clocks up, they start running normally
<ChickenCutlass> kdub: so how does sf account for the clocks?
<ChickenCutlass> kdub: android does not certainly keep everything at max
<kdub> ChickenCutlass, i'm sure they don't too
<ChickenCutlass> kdub: this is a phone -- we can not keep it on max
<kdub> but i'm don't have the details of their power architecture
<rsalveti> tvoss: right, but let's just investigate a bit more
<tvoss> rsalveti, sure
<rsalveti> tvoss: looking at the bug, there's no easy explanation about what happened in there
<tvoss> rsalveti, let's take the cpugovernor as baseline
<rsalveti> still -1, sorry
<rsalveti> that's a no-go
<rsalveti> that's bad press as well, let's just put some more effort into it
<rsalveti> and at least understand what changed
<rsalveti> kdub: increasing the cpu clock will probably help on whatever case we use, that's true
<rsalveti> but I don't think we want top performance all the time
<kgunn> alan_g: have you already spoken with jdstrand abotu https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1236912
<ubot5> Ubuntu bug 1236912 in mir (Ubuntu Saucy) "please use XDG_RUNTIME_DIR instead of /tmp for mir_socket" [Undecided,New]
<alan_g> kgunn: About what led to it. yes
<kdub> rsalveti, yes, i agree
<kgunn> alan_g: hate to put you under the gun...is this something you could quickly MP for testing ? and then we can provide mp for jdstrand to test on his side (he has to make changes as well)
<kdub> we're at the point where we suspect the clocks pretty strongly, but have to start diving outside of mir for solutions
<kdub> so it will be slow going for me, not really knowing ubuntu touch's power architecture either
<rsalveti> kdub: there's not much for power happening in there
<rsalveti> we're just using the default ondemand, which is also used by android
<alan_g> kgunn: what will break are scenarios where the server and the client run as different users. (E.g. the server is root)
<ricmm> kdub: so which one exactly are you looking into? the general "small slowness" or the several-seconds-stall after resuming
<alan_g> kgunn: see also https://bugs.launchpad.net/mir/+bug/1169075
<ubot5> Ubuntu bug 1169075 in Mir "Mir server running as root does not accept connections from non-root clients" [Medium,Triaged]
<rsalveti> kdub: if you never suspend it (disabling powerd), you should be able to stay at ondeman just fine
<ricmm> kdub: because I run the phone daily as my personal phone and I do see them both, but they are not nearly as critical as the bug mention
<rsalveti> yeah I think we're talking about 2 issues here
<ricmm> general slowness is one issue, that you can see when scrolling the application list expanded
<rsalveti> one is slowness after resuming, which we know that happens sometimes
<ricmm> yes, but even then I've never seen it be 1-2 minutes of super slowness
<rsalveti> the other (which the bugs is all about) is mir being slow by default, after boot
<rsalveti> before suspending
<ricmm> only 3-4 seconds of the greeter being choppy when coming in
<tvoss> hah
<alan_g> kgunn: still want me to go ahead?
<om26er> ricmm, as long as you hold your finger over the screen after waking from sleep the system is slow.
<rsalveti> lool: ^ guess you'll be involved at this as well, so read backlog :-)
<ricmm> om26er: what?
<kdub> ricmm, rsalveti i still don't know how powerd fits into the picture, and what it can and can't do
<kdub> i see slowness just starting the basic mir test programs
<rsalveti> it just suspends the device and resumes it back
<kgunn> alan_g: still reading and thinking
<ricmm> kdub: all powerd does is suspend to mem
<rsalveti> if you disable it, you'll be using the default governor
<ricmm> and resume from it
<ogra_> ricmm, hovering-slowness :)
<rsalveti> yeah, we're not that smart on that yet
<ricmm> om26er: tell me more about that
<om26er> ricmm, about the 3-4 seconds of slowness you talking about. I am saying that when you unlock the phone and keep your thumb over the screen, moving, you will see the slowness. it only gets better when you let go your thumb for a few seconds
<ricmm> ok now THATS a bug report
<tvoss> kdub, rsalveti, ricmm
<tvoss> kdub, rsalveti, ricmm according to http://androidxref.com/4.2.2_r1/xref/frameworks/native/services/surfaceflinger/DisplayHardware/PowerHAL.h
<rsalveti> yeah, for the other issue
<tvoss> the powerHAL is provided with a vsync enablement hint, too
<kgunn> alan_g: sorry..i feel so stupid..so when does mir need to run as root ?
<kdub> tvoss, i was poking around that yesterday too
<tvoss> rsalveti, ricmm, kdub http://androidxref.com/4.2.2_r1/xref/frameworks/native/services/surfaceflinger/EventThread.cpp#312
<kgunn> alan_g: i see you listed 3 scenarios...
<rsalveti> guys, let's try to break this bug properly
<tvoss> ChickenCutlass, ^
<rsalveti> one is slow by default
<kgunn> alan_g: i am guessing, since the greeter isn't split out yet, and we technically aren't on the mir-on-mir config
<rsalveti> the other is slow after suspend/resuming
<kgunn> alan_g: that will be the issue (which...would be a deal killer)
<ChickenCutlass> tvoss: right, ok so are you saying that on suspend we need to stop sync events?
<ricmm> kdub: tvoss that looks promising
<ogra_> ChickenCutlass, well, the kernel does that already
<ricmm> is it possible the pipeline is missing a bunch of frame refreshes because of vsync timeouts?
<ricmm> and it only stabilizes after a bit
<tvoss> back in 15
<rsalveti> still for the second issue :-)
<ricmm> rsalveti: yea
<rsalveti> not for the original bug
<ogra_> ChickenCutlass, i think the issue is that the vsync doesnt come back in time
<ChickenCutlass> right
<ricmm> it might be possible, however SF deals with vsync differently
<ricmm> it deals with it by using a signal on an fd which we have explicitly disabled as kdub implemented proper fencing at the hwc level
<ricmm> kdub: am I right on that?
<ricmm> om26er: rsalveti: omer, can you split that bug into two please? one is the general slowness, another is the slowness on resume (include the thumb on screen info)
<ricmm> the general slowness wont really be resolved before Thursday, but the second can
<om26er> ricmm, its already reported as two bugs. both from me
<kdub> ricmm, need to give a nuanced answer
<kdub> we wait for vsync properly
<om26er> ricmm, bug 1233257 is the second
<ubot5> bug 1233257 in powerd (Ubuntu Saucy) "[mako] waking from deep sleep, phone is pretty slow, takes a while to get back to normal speed" [High,Confirmed] https://launchpad.net/bugs/1233257
<kdub> using fencing (the kernel's sync driver) is not something we do as optimally as we can yet
<ricmm> kdub: got it, can we perhaps disable vsync when we blank the screen?
<ricmm> the same way we are disabling the SF signal when we do so
<alan_g> kgunn: well, there are loads of possible scenarios - those were the ones I thought mattered
<ricmm> the vsync on fd one, verbose
<kdub> well, we can't really disable vsync itself, just the polling for the vsync signal from hal
<ricmm> well yea I mean disable the fencing on vsync
<ricmm> I'm not entirely sure how it works internally
<kgunn> alan_g: for now let's keep it to what we know (e.g. xmir & touch) - so you're actually saying xmir  would break as well
<ricmm> but I would expect we need to do something like "disable fencing, suspend -- resume -> flush the pipeline, re-enable fencing'
<alan_g> kgunn: If Mir and xmir are different users and they both use the default, then making the default depend on the username breaks it
<kdub> ricmm, we do something similar, we stop the composition and the clients when the display goes off
<kdub> where did tvoss go? the power hal for qualcomm doesn't take a vsync hint
<kdub> https://github.com/CyanogenMod/android_hardware_qcom_power/blob/cm-10.1/power.c
<kgunn> alan_g: when are you eod'ing ?...maybe it'd help me & jamie to walk thru this on a hangout
<alan_g> kgunn: 1 hr
<alan_g> kgunn: I'm less familiar with the touch stack
<ricmm> kdub: is everything flushed out at that time?
<alan_g> kgunn: Anyway, I'll create the MP - you can decide which pain is worse
<kgunn> eeek
<kgunn> alan_g: https://plus.google.com/hangouts/_/5d829e0fcc19845aa040bb7b10366dec813e4d69?pqs=1&authuser=0&hl=en
<kgunn> mind jumping on ^
<kdub> ricmm, we finish rendering, and block the clients. everything should be out of the gpu (including clients), if that's what you meant by 'flushed'
<ricmm> I do
<ricmm> im kinda interested in omer's mention of keeping the thumb down maintains the slowness
<ogra_> might be his thumb
<ogra_> :)
<om26er> oh no, its real :)
<kdub> ricmm, i would be surprised if that has to do with the clocks issue, probably something else involving input, scheduling rendering, etc
<kgunn> kdub: rsalveti ricmm ChickenCutlass ogra_ sorry guys...lost track...so whats the decision about holding pm policy to "performance" short term ?
<rsalveti> fixing the bug? :-)
<kdub> kgunn, right, unacceptable seemed to be the general temperature
<kgunn> rsalveti: ok...open wound approach....
<ogra_> kgunn, we can do that on release day for the very last image as a very last resort ... (and even then i want a full management order to land such shit first)
<kgunn> ogra_: ack...
<ogra_> its a gross hack ... like dropping apparmor because one app doesnt start or similar
<kdub> the value in trying that was to make sure it was something to do with the device fabric/clocks
<kgunn> kdub: rsalveti ricmm ChickenCutlass ogra_ ...does anyone in phonedations know the proper pm fmwk api for nicely setting/removing constraints on things like mem i/f clocks ?
<kgunn> dunno if its generic arm kernel stuff yet...or probably some msm specific fmwk
<ogra_> kdub, right its a valid test
<ogra_> just not a solution ...
<rsalveti> kgunn: I'm afraid that might be device specific
<rsalveti> if we don't have a hal, we usually don't have a generic interface in android
<kgunn> rsalveti: i meant generic from an arm kernel perspective
<kgunn> not android
<kgunn> at least omap had one...and it was being pushed as the arm common soln at one point
<kgunn> but then ...well, ti..omap...people died, lots of blood :)
<rsalveti> I believe we do, but yeah, don't know what is currently happening in there
<rsalveti> hard because we're still using old kernels
<rsalveti> 3.4 is *very* old already
<ogra_> heh
<ogra_> and maguro has 3.0
<rsalveti> yeah
 * ogra_ would call mako mederately new in that light :)
<ogra_> *moderately
<kgunn>  3.4!!! now...what shit is in there :)
<kgunn> anyway...happy to tie in there...but we sure could use some guidance here, what's the i/f to talk to that is...
<kgunn> going for lunch
<lool> rsalveti: so is fair to say that we're trying to fix the Mir is slow after suspend/resume by making sure Mir + kernel do the correct thing and we've abandoned the governor thing unless we're desperate?
<lool> +it
<mterry> racarr, heyo.  So ApplicationManager in unity-mir...  it's focusRequested signal doesn't seem emitted ever?  Seems like it's deprecated in favor of new-style appid launching?
<rsalveti> lool: yup, but again, that's not what the original bug was all about
<rsalveti> lool: but it's fair to say people will investigate both bugs more before we decide to do such desperated decision
<rsalveti> *desperate
<lool> rsalveti: Ok good
<davmor2> kgunn: mir isn't updating photo user metrics it works on SF though.  I'm going to write a bug up for it if I can't find one
<mterry> alan_g, ricmm: are either of you particularly informed about unity-mir?
<mterry> Specifically, the app focusing bits/
<mterry> ?
<alan_g> mterry: I'm specifically uninformed about that. racarr is your man (when he awakes)
<ricmm> mterry: whats up?
<mterry> alan_g, OK
<mterry> ricmm, I'm looking at how the shell gets notified of a focused app (which we need to do if we want to hide greeter to show dialer-app when we get a call for example)
<ricmm> that dwells in the QML application manager API
<mterry> ricmm, and it looks like the only support in unity-mir for that is a "focusRequested(FavoriteApplication favoriteApplication)" signal
<mterry> ricmm, right
<mterry> ricmm, but that signal isn't hooked up to anything and should probably use appId instead
<ricmm> that signal is deprectated
<mterry> ricmm, i.e. unity-mir never actually emits that signal
<mterry> ricmm, in place of?
<ricmm> the right course of action would be to hide the greeter and use URL to invoke the dialer://
<mterry> ricmm, right.  We want notification more than action
<ricmm> whos we? the greeter?
<mterry> ricmm, like, the user clicks on "accept call" or whatever and the shell should hide the greeter
<mterry> ricmm, yeah greeter/shell
<ricmm> theres an onFocusedApplicationIdChanged
<mterry> ricmm, maybe the shell can do that, if it's managing the notifications...  I'd have to look into who owns that
<ricmm> not sure if that fires internally in QML when the greeter is shown, but if it does you could listen to it and use it to hide greeter
<mterry> ricmm, where does that live?
<mterry> oh i see it
<ricmm> yup
<ricmm> mterry: so yea I would either do that, or just do it internally in the shell
<ricmm> when a snap decision is accepted (call) just hide greeter
<ricmm> go into some greeter-out-for-call state
<ricmm> so you can lock back again after
<ricmm> and so on
<mterry> ricmm, ah, I guess that lives in unity::shell::application::ApplicationManagerInterface, so I didn't see it when I looked at unity-mir's version
<mterry> ricmm, ok, will test.  thanks for helping me find that
<ricmm> usa::ApplicationManagerInterface is the only mandated API
<ricmm> its sometimes confusing because there might be signals in unity-mir
<ricmm> that are provided by that other header
<ricmm> so just look at the unity-api definitions
<ricmm> unity-mir can extend it, but not the other way around... so start there
<ricmm> mterry: btw right now if you have the greeter locked and you launch an app from launcher, it hides greeter and it brings the app forward
<ricmm> follow that code path and have snap decisions do the same
<alan_g|EOD> kgunn: MP = https://code.launchpad.net/~mir-team/mir/fix-1236912/+merge/189916su - good fortune!
<mterry> ricmm, yeah, we handle that right, but not receiving a call case
<mterry> Poke again about super-simple merge https://code.launchpad.net/~mterry/unity-mir/permissions/+merge/189718
<mterry> It stops the infographic from being updated
<mterry> ricmm, hmm..  focusedApplicationIdChanged isn't a great choice if dialer is already focused
<mterry> ricmm, does anything expose requests themselves?
<ricmm> mterry: if its already focused then hiding should be enough, no? its just for this case after all
<ricmm> combined with a notifications-tell-shell mechanism it should work
<mterry> ricmm, but we don't get signal if it's already focuses
<ricmm> no but you get the notification
<ricmm> the qml notification lives in-shell
<ricmm> it shouldnt be too complicated to connect to an acceptance action from it
<mterry> ricmm, oh, but notifications don't know whether they will end up launching an app ornot
<mterry> ricmm, that knowledge lives inside of the app that started it
<mterry> ricmm, I might have a workaround
<mterry> ricmm, I'm thinking that we should unfocus apps when the greeter is up anyway
<ricmm> im pretty sure that we do, at least when the button is pressed / or powerd timeouts, we do
<ricmm> grep for setFocused in Shell.qml
<ricmm> yea we do, because its our mechanism to have all apps release their sensor
<ricmm> they all get a signal that they will suspend and they release blocking hw resources
<mterry> ricmm, yeah, but when we turn back on, we re-focus.  I think we should only re-focus when the greeter is swiped
<racarr> lol ugh... irssi hgangs. I just wonder why everyone is so quiet.
<bschaefer> has anyone gotten this while compiling mir on arm? http://paste.ubuntu.com/6210388/
<bschaefer> which when i print out the size im getting a 0
 * bschaefer sees this comment and wonders why its turned on...
<bschaefer>   #ctest does not work for android, so turn test discovery off
<racarr> bschaefer: That's a prett yfantastic error ;)
<racarr> I haven't seen it :(
<racarr> I remember...there used to be some strange stack corruption that could happen in discover
<racarr> tests sometimes
<bschaefer> racarr, turns out i have to set the mir_platform aim at andoird
<bschaefer> android
<racarr> if you...<blank>...
<racarr> oh XD
<racarr> yes
<bschaefer> :)
 * bschaefer is use to the nice desktop version of mir
<bschaefer> racarr, im happy it wasn't a stack corruption error...that wouldn'tbe fun!
<bschaefer> racarr, also, how bad would it be if i killed surface flinger then just tried to run mir on its on the phablet?
<bschaefer> on its own*
 * bschaefer is attempting to test if a library port works on mir/arm
<racarr> bschaefer: that should work
<racarr> bschaefer: Make sure surface flinger stays down XD
<racarr>  mv /system/bin/surfaceflinger /system/bin/surfaceflinger.lol -.-
<racarr> or I think you can 'stop' it
<bschaefer> racarr, awesome, haha that sounds like a good way
<kgunn> racarr: ping
<racarr> kgunn: pong
<kgunn> racarr: hey, i hate showing up with a new redirect every day....but....can you look at https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-saucy-amd64-ci/131/console
<kgunn> racarr: it relates to alan_g's mp i asked for https://code.launchpad.net/~mir-team/mir/fix-1236912/+merge/189916
<kgunn> racarr: regarding moving the mir_socket conn
<kgunn> to a running session related directory
<kgunn> racarr: anyway...looks like a potentially legitimate ci test failure...
<racarr> kgunn: mm
<racarr> looks like this is the actual failure
<racarr> Stack trace:
<racarr> /tmp/buildd/mir-0.0.13/tests/unit-tests/frontend/test_published_socket_connector.cpp:229: Failure
<racarr> Expected: { client->display_server.disconnect(0, &client->ignored, &client->ignored, google::protobuf::NewCallback(client.get(), &mt::TestProtobufClient::disconnect_done)); client->wait_for_disconnect_done(); } throws an exception of type std::runtime_error. Actual: it throws nothing.
<racarr> ill dig and push some revision to the branch as it's at ~mir-team
<kgunn> racarr: thanks...it seemed to me it might be legit since he was dorking with moving mir_socket...and this is about connections
<racarr> kgunn: I'm not sure yet, it seems suspiscious though
<racarr> that doesnt sound like
<racarr> a test that should be racy
<racarr> Uninteresting mock function call - returning directly. Function call: listening_on(@0xc1ba198 "./test_socket")
<racarr> Stack trace:
<racarr> suspiscious
<racarr> is rather
<racarr> among other things
<racarr> anyway have to build it and see if I can reproduce will be a few minutes
<kgunn> racarr: thankyou
<racarr> at some point recently we hit some complexity of compilation where compiling mir just makes my system crawl to the point of being unusable :(
<racarr> i.e. like 5 second compiz pauses
<racarr> etc
<racarr> kgunn: Oh good I can't reproduce it locally
<racarr> otherwise it wouldn't be a challenge :p
<racarr> kgunn: the only thing I can think of is something with the test socket getting left around leading to weird state, but I can't exactly work out how it would cause these errors...
<racarr> also the only data is once out of 30,000 test runs I got
<racarr> a failure
<racarr> with removing the socket
<racarr> I passed 30,000 test runs
<racarr> but um.
<racarr> Not sure that means much
<kgunn> racarr: hmmmm.....i wonder, maybe the machine it ran on had a stale socket at /tmp/
<kgunn> racarr: so you think just review & approve and let jenkins try again ?
<racarr> ok I can see the error
<racarr> a lot more frequently
<racarr> in valgrind
<racarr> kgunn: Well the oscket is in the test directory though
<kgunn> mmm, slower
<racarr> so it would have to be like
<racarr> some previous test leaving it around in a racy fashion
<racarr> or perhaps even...
<racarr> valgrind...being weird :p
<kgunn> racarr: maybe that test should delete first before it runs
<racarr> kgunn: That's what I tried (And we do that in some of the other tests)
<racarr> but want to collect enough data to be sure that's what is going on
<racarr> before just shoving stuff in
<kgunn> k
<racarr> kgunn: Nope. It's not juist that :) something else is going on
<racarr> ill um...keep digging though now that I can eproduce it
<kgunn> racarr: thanks again
<racarr> ok this test is a little more nerfarious than it seems
<racarr> it may have only been passing kind of coincidentally
<racarr> lol
<racarr> the test it passing now most of the time
<racarr> because the server closes the pipe after the first disconnect
<kgunn> nefarious isn't usually a character trait of a test...theyre supposed to be the good guys
<racarr> and ytou get broken pipe exception
<racarr> the problem is if the test process stalls for a long time because say you are running in valgrind :p
<racarr> you send the disconnect
<racarr> before the server has broken the pipe
<racarr> and...it seems like there are a few things that can happen now
<racarr> this
<racarr> also is not a unit test
<racarr> lol
<kgunn> racarr: huh? this is not a unit test
<racarr> kgunn: I just mean the test that is failing
<racarr> shoudl be an integration test not a unit test
<racarr> I am also pretty sure this branch has nothing to do with itand its been existing
<racarr> and become more frequent due to some changes in frontend leading to more gmock warnings
<racarr> slowing things down enough to make it come up more often
<kgunn> ah
<tvoss> ricmm, kdub did you guys look further into the power HAL?
<kdub> tvoss, dead end
<tvoss> kdub, why is that?
<kdub> tvoss, https://github.com/CyanogenMod/android_hardware_qcom_power/blob/cm-10.1/power.c#L77
<kdub> hint doesn't do anything on sf either
<kgunn> racarr: you mentioned alf made some amazing change that would fix a lot of bugs...but i don't see anything in MP's or landed on dev branch ??
<racarr> kgunn: https://code.launchpad.net/~robertcarr/mir/hold-surface-alive/+merge/189400
<racarr> kgunn: Itt's a unity-mir proposal he made that makes this not leak
<racarr> (see comments at bottom)
<racarr> there are other crashes potentially linked but am trying not to go overzealous with it XD
<kgunn> robert_ancell: by your mail regarding lightdm socket creation, do you really mean to say "these changes have no effect" or do you mean to say "it'll break it"
<robert_ancell> kgunn, first I was "it will change it", then I realised it wont (for the desktop case)
<robert_ancell> it will change on the phone case
<robert_ancell> but as alan_g said, that shouldn't matter
<robert_ancell> It might break some QA tests
<kgunn> robert_ancell: so you are really saying....we can land alan's change and xmir will be fine ?
<robert_ancell> yes
<kgunn> woohoo
<kgunn> altho...we need to be nice to qa
<kgunn> which i assume means they just need to check the new dir for the socket existance
<robert_ancell> yeah, just a heads up for them - they might just have to change a hard-coded value to another hard-coded value
<robert_ancell> yes
<kgunn> robert_ancell: i thot we should also mir-devel on that one...its like a behavior change
<robert_ancell> yes, agreed
<robert_ancell> what is XDG_RUNTIME_DIR for root?
<robert_ancell> it's not just /tmp anyway is it?
<kgunn> robert_ancell: my understanding its tmp dir associated with a running session that would disappear on termination of the session
<robert_ancell> kgunn, yes, for users I know that's true. I wasn't sure if root was special cased
<kgunn> mmm, dunno robert_ancell , you could ask jdstrand
<robert_ancell> well, the phone is not root so it wont matter in this case
<robert_ancell> brb
<racarr> lunnnnch
<robert_ancell> brought to you by the letter n
<kgunn> robert_ancell: so racarr is still looking to see if there's a legit concern around the ci test failure...he believes there's an issue there, but its likely with the test, nothing to do with this branch
<kgunn> i'd like to get it merged so we can update trunk
<kgunn> robert_ancell: oh crap...forgot the first sentence
<robert_ancell> kgunn, this is alans branch?
<kgunn> would you mind reviewing https://code.launchpad.net/~mir-team/mir/fix-1236912/+merge/189916
<kgunn> yeah...sorry :) super out of order
<robert_ancell> kgunn, already done it
<kgunn> ta...mind reader :)
<robert_ancell> kgunn, did racarr trigger a rebuild?
<kgunn> i just did robert_ancell , i ta'd
<robert_ancell> k
<racarr> I didnt, I was still trying to fix it
<racarr> Still kind of half lunching
<racarr> the thing is the test doesn't pass in the way that was originally expected either
<racarr> at least I dont think it does...
<racarr> but its hard to figure out the original intention right now
<racarr> might need to talk to alan in the morning
<robert_ancell> kgunn, is that fix important mostly for phone or both phone and desktop (wondering if I should make the associated lightdm fix)
<kgunn> robert_ancell: mainly for phone...
<kgunn> robert_ancell: jamie outlined in the bug https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1236912
<ubot5> Ubuntu bug 1236912 in apparmor-easyprof-ubuntu (Ubuntu Saucy) "please use XDG_RUNTIME_DIR instead of /tmp for mir_socket" [High,Triaged]
<racarr> kgunn: Ok so I have no quick fixes so far and it seems like
<racarr> there is probably something better for me to do than work on an intermittent acceptance test bug that alan can help with in the morning
<kgunn> racarr: yep - agreed....
<kgunn> racarr: let's see if we can get it to pass
<racarr> haha I like your email picture
<racarr> kgunn: the thing is it will show up on other mps, etc..
<racarr> but it should pass.
<racarr> most of the time :/
<racarr> robert_ancell: Could you take a peek at https://code.launchpad.net/~robertcarr/mir/hold-surface-alive/+merge/189400
<robert_ancell> racarr, everytime I see that URL I think of the beegees
<racarr> robert_ancell: P.S. We will miss you on the crazy train.
<robert_ancell> ah ah ah ah surface alive, surface alive. Surface ALIVE!
<racarr> Ahahaha
<racarr> this and many other hits, on "The Music of Mir - A Symphony of Google Mock"
<racarr> now available at your local record store
<robert_ancell> racarr, so what happens now if the surface has been destroyed (e.g. by the client quitting) and the shell tries to modify it (e.g. allow_framedropping(true))
<robert_ancell> or it is never destroyed until the shell releases it?
<racarr> robert_ancell: It's never destroyed
<racarr> so it's still a valid surface.
<racarr> can be rendered and everything
<robert_ancell> racarr, and how does the shell know it should be destroyed?
<racarr> through the "shell interface" :p
<racarr> at this moment I believe they are using
<racarr> the SessionListener
<racarr> I mean so in most cases
<racarr> the shell should still hold weak_ptr
<robert_ancell> This all makes sense to me to have the shell and the rendered surface and client surface all with the same lifecycle
<racarr> the point is when it temporarily locks it
<robert_ancell> just want to double check
<racarr> well temporarily promotes it to shared_ptr
<racarr> then that actually will hold the surface alive
<racarr> rather than the current nonsense, where that doesn't really mean anything
<racarr> but also, there are some places where the shell might want to actually hold it alive
<robert_ancell> yes, agrees
<racarr> like say, a client disconnects suddenly, the shell should probably still keep the surface alive
<racarr> to do a little animation or whatever
<robert_ancell> I'm thinking if a client quits, that doesn't mean the shell might not want to keep rendering the last frame or animate its death
<racarr> Right.
<racarr> kgunn: Do we still need a mir side to: https://bugs.launchpad.net/unity8/+bug/1233564 ?
<ubot5> Ubuntu bug 1233564 in Mir "Greeter is seen animating when pressing the side button to wake up" [High,Triaged]
<racarr> *testing*
<racarr> yes its still not working right in the latest image at least
<racarr> im a little skeptical that it's fixed in unity-mir though because the error is larger
<racarr> than a single frame
<kgunn> racarr: hmm, don't know how important it is...or well...at least, i wonder
<kgunn> will this get addressed when greeter is split out ?
<racarr> probably
<racarr> halfway
<racarr> the problem is
<racarr> the client posted frame, or compositor posted frame could be posted right before screen blank, but not actually post so then it blocks the client and compositor with the stale frames
<racarr> and when we come back an old frame gets shown
<racarr> if the greeter is another surface, then it doesn't matter that the client frames are out of date
<racarr> because it will look fine anyway
<racarr> but we still have the risk of a one old compositor frame
<racarr> flashing up
<racarr> tbh it doesn't seem like THE most important thing
<racarr> I am thinking maybe the best thing for me to do is, build trunk of everything + hold surface alive and alfs branch
<racarr> and go try and reproduce crashes
<racarr> and see what we can check off
<kgunn> racarr: yes
<kgunn> racarr: and run AP tests if you like
<kgunn> racarr: or even this one....not because its ricks, but because its a consistent crash https://bugs.launchpad.net/mir/+bug/1236946
<ubot5> Ubuntu bug 1236946 in Mir "Karma machine scrolls under SF, but not Mir" [Undecided,New]
<kgunn> robert_ancell: just curious...would you mind testing alans branch with xmir just to see
<kgunn> to verify it doesn't break anything
<robert_ancell> kgunn, sure
<racarr> kgunn: ok sounds like a plan
<racarr> halfway through the phone update dance
<racarr> is there a way to stop the nexus 4 wireless
<racarr> from getting to slow when the power turns off
<bschaefer> racarr, hmm when I try to run mir build on the N7, all i get is: __pthread_gettid -2
<bschaefer> and then when i attempt to re-run it I get:
<bschaefer> http://paste.ubuntu.com/6211379/
<bschaefer> racarr, but you seem busy, so no worries :)
<racarr> bschaefer: That looks just like the old process
<racarr> is stranded alive
<racarr> remove socket file, make sure process is dead, etc
<racarr> but I think mir on n7 is still expected to be broken
<racarr> kdub: ^
<bschaefer> yeah, but i don't see a mir process running anywhere
<kdub> yes, expected broken
<rsalveti> kdub: did a quick check and updated bug 1231917, it crashes when gralloc.tegra3.so calls pthread_mutex_lock because the original address of that pointer is not part of the process mapped memory region o_O
<ubot5> bug 1231917 in libhybris (Ubuntu) "Mir servers crash with SIGSEGV in libhybris-common.so.1 on Nexus7" [Low,Confirmed] https://launchpad.net/bugs/1231917
<bschaefer> kdub, o i see, well thats good to know :)
<bschaefer> thanks!
<racarr> :(
<racarr> love that hybris
<rsalveti> I don't get why we got that address
<kdub> in gralloc though?
<kdub> i saw in hwcomposer.tegra3.so last time i checked
<kdub> it was a long time ago though so something could have changed
<rsalveti> kdub: how to check that? it's all the same process in theory
<rsalveti> maybe it's a shared memory regioin, and that's not mapped properly
<racarr> I think it uses a mutex in a shared memory region
<racarr> is...a rumor I heard in the past :p
<rsalveti> but I don't get how if it's all the same process
<racarr> mm right who is sharing
<kdub> well, it shares it when a client connects
<racarr> maybe it shares with libEGL or something absurd
<rsalveti> still weird
<kdub> it is weird
<rsalveti> kdub: any tips or idea on what I could check?
<kdub> rsalveti, well, last time i tried that device, client rendering looked okay
<kdub> and if i forced mir to use a fallback rendering mode, it worked
<kdub> it was just bringing in the hwc that caused problems for me
<rsalveti> right, let me try removing the hwcomposer
<rsalveti> kdub: yeah, doesn't crash after removing the hwcomposer
<kdub> yay
<rsalveti> that crap is also proprietary
<kdub> yep, so can't even see what they might be doing
<rsalveti> but mir_demo_client_egltriangle is running fine
<rsalveti> time to try with the entire session
<kdub> i /suspect/ they were trying to do some fancy synchronization in the background before google added the sync fences to the native window type
<rsalveti> could be
<kdub> and google had a peek under the covers and said, 'well if you're going to go to this length, we'll accommodate you'
<rsalveti> let me reflash first, but saw unity8 crashing here
<rsalveti> :-)
<racarr> Testing trunk with hold-surface-alive and unity-mir fix...*waits for phone to reboot*
<racarr> haven't tested the monitor channel stuff either yet on phone so excited to see it all work
<rsalveti> ricmm: who starts mir in touch?
<rsalveti> ricmm: and with which user?
<rsalveti> got a few perm denied here, so wondering if that runs as phablet
<ricmm> rsalveti: phablet user
<ricmm> what perm denied?
<rsalveti> ricmm: right, nexus 7 specific
<rsalveti> I can run mir_demo server/client as root just fine
<rsalveti> but can't start unity8
<rsalveti> ricmm: it's all part of unity8, right?
<ricmm> yea mir is unity8
<rsalveti> ricmm: should you be able to run mir_demo server/client as phablet as well?
<rsalveti> that's easier to reproduce the problem
<ricmm> yes it goes through the same path
<ricmm> should hit the same error
<rsalveti> awesome
<ricmm> rsalveti: do you see the choppy greeter when resuming your nexus 4?
<ricmm> cable disconnected
<ricmm> sleep for ~10 sec
<rsalveti> ricmm: sometimes
<ricmm> can you try?
<ricmm> I have a deb with the power hint stuff
<racarr> woohoo its running great
<ricmm> resuming while swiping your finger across the screen several times should do it
<robert_ancell> kgunn, confirmed alan's branch runs fine with XMir and continues to use /tmp/mir_socket
<kgunn> robert_ancell: awesome...thanks for doing that (painful as it was i know)
<robert_ancell> kgunn, not painful, just tedious to compile :)
<kgunn> robert_ancell: about to do the paper work....it's "dch -i" for the changlog bump right ?
<robert_ancell> kgunn, yes
<racarr> how am I supposed to install click packages that arent just in the dash
<racarr> trying to test karma machine
<kgunn> i swear i wrote it down tons of times....i keep deleting it
<robert_ancell> kgunn, shouldn't the autolanding fill out the changelog?
<racarr> oh wow
<racarr> I searched the dash and it worked
<kgunn> robert_ancell: i'm gonna say i'm a dumb monkey on that one....at least, i'm just gonna follow the process that keeps me from being yelled at
<racarr> grr I have to sign on to ubuntu sso to install apps now
<robert_ancell> kgunn, probably better keep doing that then :)
<kgunn> racarr: i know searching dash is kinda cool that it actually works
<racarr> unfortunately this accounts pane to add
<racarr> my sso page isnt
 * robert_ancell -> lunch
<racarr> lol got signed in now app installing is sticking around at 0 percent...
<racarr> ah it goesss
<racarr> hey it scrolls and it doesnt crash :)
<kgunn> robert_ancell: would you do me the honors https://code.launchpad.net/~mir-team/mir/bump-deb-changelog14-mirserver6/+merge/189990
#ubuntu-mir 2013-10-09
<rsalveti> kgunn: kdub: got unity8 running with mir on my n7
<rsalveti> without the compositor
<rsalveti> just had to fix a few permission errors
<rsalveti> will be pushing this soon
<kgunn> hey...that's awesome
<kdub> yay :)
<kdub> kgunn, we might want to add an option to override to fallback display mode
<kgunn> kdub: sorry, context ?
<kdub> oh, we had to force the n7 into the fallback by hiding files
<kdub> would just be nicer if a command line switch would cause that operation mode
<kgunn> robert_ancell: i was gonna step away for an extended period - if you would, ta that mp (if its correct) and then once it merges...queue a merge of dev-> trunk
<kgunn> i'll be back later
<robert_ancell> kgunn, ok, bye
<rsalveti> kdub: yeah, a command line or similar would be nice indeed
<rsalveti> or even if internally atm, by getting the property and not using it in case of grouper
<rsalveti> would that be possible?
<kdub> hmm, not without expanding our options to include the android properties
<kdub> it is a good idea though
<robert_ancell> kgunn, https://code.launchpad.net/~mir-team/mir/development-branch/+merge/190004
<kgunn> robert_ancell: hey...back...uh-oh... duflu says there's conflicts
<duflu> Yes, umm, chat amongst yourselves :/
<robert_ancell> kgunn, duflu, that happened last time - it's just debian/changelog getting confused
<robert_ancell> I've manually pushed a merge for that
<robert_ancell> hmm, though LP says otherwise
<robert_ancell> merges locally fine..
<duflu> robert_ancell: If the conflicts aren't real then that just means its a metadata conflict. You need to merge the destination back into the source, commit it, and then propose merging the source back to destination.
<robert_ancell> done it
<duflu> This was bound to happen landing fixes in lp:mir directly
<robert_ancell> waiting for LP to notice
<robert_ancell> kgunn, duflu, https://code.launchpad.net/~mir-team/mir/development-branch/+merge/190008 seems ok now
<kgunn> thanks robert_ancell
<robert_ancell> kgunn, do you wait for didrocks to top approve mps like https://code.launchpad.net/~kgunn72/unity-system-compositor/bump-mir-dep14/+merge/190012?
<kgunn> robert_ancell: yeah...well, that's what i've done the last 2 times...
<kgunn> and it worked and no one got mad
<kgunn> robert_ancell: duflu thanks guys...i'm gonna duck out at a decent time tonight...please keep an eye on that mp such that it merges
<robert_ancell> kgunn, enjoy your evening!
<robert_ancell> well, night
<kgunn> thanks! (going to nurse my headache i developed)
<robert_ancell> thomi, is the mir autolanding broken in the same was as lightdm was? We have https://code.launchpad.net/~mir-team/mir/development-branch/+merge/190008 but http://10.97.0.26:8080/job/mir-autolanding/? shows nothing building
<thomi> robert_ancell: maybe they turned it off?
<thomi> want me to trigger that manually for you now?
<robert_ancell> thomi, yes please. I just asked in #ubunut-ci-eng if it's intentionally turned off but no response
<robert_ancell> kgunn wanted that to land
<thomi> robert_ancell: http://10.97.0.26:8080/job/mir-autolanding/709/console
<robert_ancell> thomi, ta
<robert_ancell> bbl
<olli> thomi, we stopped the upstream merger
<olli> not sure if related
<thomi> olli: ahhh.. why's that?
<olli> so we can land mir
<olli> robert_ancell, was anounced on ue-leads and ubuntu-phone
<thomi> OK... I don't understand why we need to turn it off to do that, but oK. I trust my triggering it manually for mir and lightdm hasn't caused any problems
<olli> it might, dunno
<olli> asac, will be able to tell when he is awake
<duflu> Stupid audio settings...
<RAOF> Hm.
<RAOF> Apparently my internet is all screwy.
<RAOF> That's not working very well at all, is it.
<duflu> RAOF: Pretty-please; https://bugs.launchpad.net/xmir/+bug/1233044
<ubot5> Ubuntu bug 1233044 in XMir "XMir fails to build: error: 'xmir_screen' has no member named 'dmps_on'" [Critical,In progress]
<RAOF> duflu: Ah. Had fixed that locally, but github didn't have it.
<duflu> Figures. Otherwise it's obvious no one's looked at the code in a while...
<alan_g> duflu: alf_ - @SIGPIPE can you agree on whether we should handle it?  FWIW it is "Term" (not "Core") in posix
<duflu> alan_g: Yeah I meant it normally kills the server. Even if it doesn't cause a core by default
<duflu> Hmm, I wonder if that's accurate. Otherwise we couldn't get any SIGPIPE crash reports
<duflu> Oh, the crash is because we make it an exception?
<alan_g> The crash is because we allow an exception to propagate off the end of the stack
<alan_g> duflu: does the latest rev address your other comment? https://code.launchpad.net/~alan-griffiths/mir/remove-endpoint-first-when-shutting-down/+merge/189376
<duflu> alan_g: Looks better but will take me some time to test it and verify core dumps and debugability
<alan_g> duflu: I couldn't come up with a simple test for a core dump - given that valgrind doesn't produce a core named "core" - any ideas?
<duflu> alan_g: Set up a pre-existing handler in the test and ensure the old handler gets called eventually?
<alan_g> duflu: maybe, although that doesn't prove that a core is produced.
<duflu> alan_g: No, it's possibly beyond the scope of in-process testing
<cjwatson> Hey - just pushed up https://code.launchpad.net/~cjwatson/mir/arm64-no-valgrind/+merge/190051.  Any hope of getting that merged in time for saucy?  We're racing to get the new arm64 port as complete as possible, and of course there's a batch of stuff queued up behind mir now.
<cjwatson> (I don't know for sure that this isn't going to run into https://bugs.launchpad.net/mir/+bug/1195590, but even if it does it's still an improvement)
<ubot5> Ubuntu bug 1195590 in Mir "cmake/MirCommon.cmake fails in detecting that valgrind is not installed" [Medium,Triaged]
<alan_g> cjwatson: Approved - just waiting on CI
<cjwatson> Great, thanks
<pete-woods> tvoss: good morning! could you possibly have a look at a (hopefully trivial) MR for unity-mir (https://code.launchpad.net/~pete-woods/unity-mir/window-stack-get-property/+merge/189984)
<alf_> duflu: alan_g: don't we get sigpipe ourselves when trying to write to closed socket? I think SIGPIPE is a recoverable error in general...
<duflu> alf_: Yeah fair point
<duflu> Although this is all about handling /unexpected/ signals
<duflu> Which SIGPIPE could still be
<alf_> duflu: The problem is that we don't have any control of the code that lives in the same process as us. Case in point is libcrypto, which uses SIGILL on ARM to check the presence of special instructions :/
<duflu> That's a good reason to never use other peoples' code :)
<duflu> But SIGPIPE is not important...
 * alf_ is convinced and starts hacking on his own BIOS code :)
<asac> do you guys have a way to work on the crashers/issues with mir image?
<asac> http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/
<asac> i think its mostly maliit, unity8 and hud crashes that are coming in
<asac> olli: ^^
<duflu> asac: The methodology is log bugs against unity8 or mir, and they will be triaged accordingly.
<duflu> Not sure what you mean though
<asac> duflu: we have landed mir by default
<asac> duflu: deal was that mir team would be all on fixing everything
<asac> duflu: you guys should look and crunch out things
<asac> without us filing bugs
<asac> everything that isnt happening here: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/mako/88:20131009:20131008.2/4628/
<asac> but that happens here:
<asac> http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/88:20131009:20131008.2/4626/
<asac> is a mir regression
<asac> duflu: ^^
<duflu> asac: A bug does not exist unless it's a bug in LP. Please don't encourage people to track things entirely in IRC or elsewhere...
<asac> its on you guys to file bugs etc.
<duflu> And we do. Whenever we find one
<asac> duflu: so are you working on unity8 and maliit and hud crahes?
<asac> those are the ones we see all the time
<duflu> asac: I can't because my phone is being repaired. But I am working on what I can with a PC
<tvoss> asac, duflu is not, gusch is looking into maliit crashes, pete-woods is looking into hud crashes
<asac> tvoss: well, i didnt ask him
<tvoss> asac, ?
<asac> he replied stating "dont care if there is no bug"
<asac> http://paste.ubuntu.com/6213070/
<asac> olli: ^^
<asac> duflu: please spare your comments next time. All i asked about was trying to figure was if you guys are able to work with what we produced and crunch down bugs while we do a respin that makes mir the default proper
<asac> tvoss: do you know who is looking at unity8 crashes?
<asac> thostr?
<tvoss> asac, I thought we agreed yesterday that we first tackle hud and osk crashes to eliminate variables?
<asac> tvoss: depends. i think we see the crash, so if we have someone who is qualitied, we should avoid loosing time and have people look
<asac> note: if we have someone who is qualitied.
<asac> :)
<tvoss> asac, I think with some people being at qtdevdays, we are using our available resource quite well right now
<asac> and those guys cant come back to arms?
<tvoss> asac, greyback is available in #phablet
<asac> cool
<greyback> tvoss: I'm still at a conference, so I'm not very available
<greyback> asac: ^^
<tvoss> greyback, ack, just saying: you are helping as much as possible
<greyback> doing my best
<asac> greyback: how long wil lthe conf go?
<greyback> asac: today is the last day
<asac> greyback: ok. dont know if a conference is more important than making mir-by-default shine, but...
<asac> :)
<asac> anyway. if you help as much as you can thats good enough i hope until the US wakes up
<alf_> alan_g: ok to top-approve remove-endpoint-first-when-shutting-down ?
<alan_g> alf_: If you're happy with the latest iteration
<alf_> alan_g: hmm, "If the signal handler is called as a result of abort or raise, the behavior is undefined if any of the following requirements is not followed:
<alf_> the signal handler calls raise.
<alf_> alan_g: ignore ^^, it's only if we raise the signal ourselves in the first place
<alf_> alan_g: ...but we are doing exactly that in the tests
<lool> Folks, in case you were on #88 and thought it had Mir by default, update to #89 which does  ;-)
<lool> (confirmed enabled in #89)
<jibel> kgunn, FTR, I got bug 1236525
<ubot5> bug 1236525 in unity-mir "unity8 killed/crash then restart can result in mir unable "could not unblank display"" [High,Triaged] https://launchpad.net/bugs/1236525
<jibel> kgunn, FTR, I got bug 1236525 on 1rst boot after flashing #89
<alf_> ricmm_: Could you please take a look at https://code.launchpad.net/~afrantzis/platform-api/fix-1236225/+merge/189954 ?
<alf_> Saviq: Could you please take a look at https://code.launchpad.net/~afrantzis/qtubuntu/fix-1237052/+merge/190113 ?
<Saviq> alf_, looking
<Saviq> alf_, would that be https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1234609 ?
<ubot5> Ubuntu bug 1234609 in Mir "unity8 crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::shell::Surface::name()" [Critical,In progress]
<alf_> Saviq: no, 1234609 is a server side crash, and is solved by Robert's hold-surface-alive MP (plus the unity-mir fix-1236898 for leaks/memory errors)
<alf_> Saviq: 190113 is a client-side crash
<Saviq> alf_, ok, it looks good, any way to test the fix?
<Saviq> alf_, ah well
<Saviq> alf_, so it is that bug
<Saviq> alf_, just that this part is client-side - the other is server side
<Saviq> alf_, got it
<alf_> Saviq: well, the cause is not the same though, just the trigger conditions (app closing itself)
<Saviq> alf_, ok
<alf_> Saviq: to manually test, check the instructions in https://bugs.launchpad.net/qtubuntu/+bug/1237052, we could probably make an automatic test for this using the close.qml. Does qtubuntu have automatic test infrastructure?
<ubot5> Ubuntu bug 1237052 in qtubuntu "Apps that close themselves crash trying to use deleted EGL resources" [Undecided,In progress]
<Saviq> alf_, not sure it does
<Saviq> ricmm_, â ?
<Saviq> alf_, looks like manual tests only
<kgunn> Saviq: do you have a sim ?
<Saviq> kgunn, plenty
<kgunn> Saviq: assuming you're on image88....
<kgunn> Saviq: can you turn on mir with a locked sim ?
<kgunn> Saviq: do you get a prompt
<Saviq> kgunn, sounds like we dropped a ball there
<kgunn> :)
<Saviq> kgunn, I don't think anything is talking to ofono for SIM PIN yet
<Saviq> kgunn, we support it in the shell
<Saviq> kgunn, but indicator-network doesn't yet ask for it
<Saviq> pete-woods, can you confirm â?
<kgunn> Saviq: ah...so backend....so we flog ted :)
<Saviq> kgunn, yeah, I don't think there's a backend for that indeed
<kgunn> pete-woods: so getting the "hey this doesn't work on mir" noise....can you confirm whether or not there is something "on the way" ??
<pete-woods> kgunn: https://bugs.launchpad.net/unity-mir/+bug/1233992
<ubot5> Ubuntu bug 1233992 in hud (Ubuntu) "HUD does not support unity8's ApplicationManger" [High,In progress]
<pete-woods> Saviq: https://code.launchpad.net/~nick-dedekind/indicator-network/simunlock.dialog/+merge/185810
<pete-woods> Saviq: I'm guessing that work needs to be completed + merged
<pete-woods> kgunn: the fix works now, but obviously it's being tested (and going through code review)
<Saviq> pete-woods, right, so no one is looking at it yet...
<pete-woods> Saviq: probably true
<kgunn> lool: ^ to track it...those are the relevant links
<tvoss> alf_, can I ask you to just refactor alan's branch to RAII?
<tvoss> alf_, we would like to have something testable fast
<alf_> tvoss: then I am OK with this as a quick fix
<tvoss> alf_, ack
<tvoss> alf_, just (h)approve then :)
<lool> kgunn: ok
<lool> tvoss: is the alan_g branch this one? https://code.launchpad.net/~alan-griffiths/mir/remove-endpoint-first-when-shutting-down/+merge/189376
<tvoss> lool, https://code.launchpad.net/~alan-griffiths/mir/lock_guard-for-unique_lock/+merge/190101
<lool> tvoss: do you know about the endpoint thing above?  seems to be devel branch only, not trunk
<lool> kgunn: (note that we need these in trunk)
<tvoss> lool, it's a cleanup measure
<kgunn> lool: no no...its in mir trunk
<kgunn> lool: please see https://code.launchpad.net/~mir-team/mir/development-branch/+merge/190008
<lool> kgunn: yes, but couldn't find the remove-endpoint commit
<lool> kgunn: rechekcing
<kgunn> lool: sorry...i'm confusing....i mean for socket moving
<kgunn> lool: for the cleanup stuff for osk, its only under test as an mp, not landed on dev or trunk yet
<kgunn> lool: for the socket move, its listed as  Change default filesystem endpoint to $XDG_RUNTIME_DIR/mir_socket.
<kgunn>   (LP: #1236912)
<ubot5> Launchpad bug 1236912 in apparmor-easyprof-ubuntu (Ubuntu Saucy) "please use XDG_RUNTIME_DIR instead of /tmp for mir_socket" [High,Triaged] https://launchpad.net/bugs/1236912
<lool> kgunn: https://code.launchpad.net/~alan-griffiths/mir/remove-endpoint-first-when-shutting-down/+merge/189376 is in devel, not in trunk
<lool> kgunn: Right, what I was saying earlier is let's try to land all the Mir branches in the pipe (approved or merged in devel) into trunk, then do the Mir upload
<lool> kgunn: I understand the two missing from trunk right now are at least https://code.launchpad.net/~alan-griffiths/mir/remove-endpoint-first-when-shutting-down/+merge/189376 and https://code.launchpad.net/~alan-griffiths/mir/lock_guard-for-unique_lock/+merge/190101
<lool> kgunn: thanks for the link to the sim card thing
<mterry> if anyone has a few minutes, I'd love a review of the tiny https://code.launchpad.net/~mterry/unity-mir/permissions/+merge/189718
<lool> pete-woods: Can we log a bug to add tests for sim unlock indicator and merge it?
<kgunn> lool: ack
<davmor2> kgunn: maguro is still hitting the issue that it clean locks up under mir, you can't get into the device via adb, if you are connected and it happen you are kicked from adb and can't get back in.  Next time it happens what useful stuf can I grab for you?
<pete-woods> lool: I have no idea if it even works, I also have no intention of blocking that merge
<pete-woods> it was just a random comment on it
<lool> mterry: Looks good to me, but can't top approve it
<lool> mterry: What is the symptom we were seeing before this change?
<davmor2> kgunn: oh and you have to rip the battery out in order to get the phone back up
<lool> pete-woods: Ok; I think you should file a bug because we wont revisit the merge once it has landed
<lool> pete-woods: :-)
<lool> pete-woods: Also, is someone testing that it works with a sim card?
<kgunn> davmor2: grab var/crash of course, and all the logs from homet/phablet/.cache/upstart
<pete-woods> lool: not that I'm aware of, it doesn't look like anyone is even looking at it, I just came across it
<Saviq> alf_, after building / installing just qtubuntu, I'm still getting a crash - but that's probably the other one?
<alf_> Saviq: probably so, I can tell you for sure if you can get a backtrace
<mterry> lool, unity8 couldn't receive signals from non-root daemons because it owned com.canonical.Unity.Screen
<mterry> lool, because of the deny send_dentination=com.canonical.Unity.Scren
<lool> kgunn: Hmm can you gather the status from dednick in some way?
<lool> what's his IRC nick?  is he on leave today?
<kgunn> lool: about to have our standup
<lool> mterry: what was failing that I could witness?
<davmor2> kgunn: the crash files were useless last time I had iirc but I'll have another look.  I'll grab all the /home/phablet/.cache stuff though.  I'll do another fresh flash now and see if I can make some reproducible steps
<lool> kgunn: great
<lool> kgunn: thanks
<mterry> lool, infographics couldn't be updated
<lool> mterry: Ok; great
<mterry> lool, (with mir
<lool> pete-woods: can you review unity-mir changes?  would you mind reviewing https://code.launchpad.net/~mterry/unity-mir/permissions/+merge/189718?  trivial from what I can tell
<pete-woods> lool: I've also approved, it's definitely sane
<lool> pete-woods: thanks
<lool> pete-woods: but not top approved?
<pete-woods> lool: does top approve mean anything anymore?
<pete-woods> (I've top approved now)
<lool> pete-woods: Well you have a point there I guess  :-)
<lool> pete-woods: Let's stick to top approving to mean it can go in though  :-)
<lool> pete-woods: I've poked fginther to land it
<pete-woods> :)
<mterry> lool, pete-woods: what can I do to convince the powers that be that this fix is important enough to land before freeze?
<mterry> And if that happens, do I manually merge it?
<pete-woods> mterry: er, one of the front page features of ubuntu touch doesn't work without it? (the infographics)
<pete-woods> surely that's reason enough
<mterry> pete-woods, correct
<mterry> I agree, but I have to convince someone first, I imagine, now that we disabled merging
<pete-woods> mterry: see comment above from lool about pinging for merge
<tvoss> lool, can you help mterry here?
<mterry> oh I didn't see
<mterry> Yeah, I must not have scrollback that far
<pete-woods> what, 20 lines? :p
<mterry> ah, "I've poked fginther to land it"
<mterry> cool, thanks lool !
 * mterry feels better about the phone already
<lool> mterry: I've pinged to get it reviewed and landed already
<lool> tvoss: I've done all things already!
<tvoss> lool, awesome
<mterry> lool, sorry  :)  I missed your comment about fginther originally
<lool> Ok
<kgunn> alan_g: so did either of the 2 mp's that just landed on dev branch break client api ?
<lool> worst case we should hand merge it
<alan_g> kgunn: looking
<kgunn> alan_g: "they" haven't taken trunk w the server break/bump yet...so we could do one more merge and be ok (_if_ client is ok)
<Saviq> alf_, ugh, I'm getting completely nothing in the backtrace...
<alf_> Saviq: I guess the other way is to apply https://code.launchpad.net/~afrantzis/platform-api/fix-1236225/+merge/189954 and see if it fixes things
<Saviq> alf_, trying that, then
<alan_g> kgunn: "frontend: Remove the endpoint first when shutting down. Fixes: https://bugs.launchpad.net/bugs/1235159." and "Merge with trunk" should be fine
<ubot5> Ubuntu bug 1235159 in mir (Ubuntu) "Mir fails to start if there's a stale socket" [Medium,Triaged]
<alan_g> kgunn: and we now have -r1120 "client: use lock_guard as it is simpler than unique_lock." - which is also safe
<kgunn> alan_g: thanks...
<kgunn> alan_g: i'll propose a dev branch merge to trunk
<alan_g> kgunn: I'll drink to that. ;)
<alan_g> kgunn: we should also merge trunk to dev. (C.f. https://code.launchpad.net/~cjwatson/mir/arm64-no-valgrind/+merge/190051)
<kgunn> alan_g: should i do that first?
<kgunn> or...guess it doesn't matter
<kgunn> order
<alan_g> Nope, it can wait
<kgunn> alan_g: ok...ready i think https://code.launchpad.net/~mir-team/mir/development-branch/+merge/190142
<alan_g> kgunn: approved
<ricmm_> alf_: approved
<alf_> ricmm_: thanks!
<kgunn> lool: mir trunk  now has the 2 mp's on it (1 cleanup change to help osk and 2 the removing endpoint)
<kgunn> lool: in the past, didrocks would approve the 3 mp's on unity-mir, u-s-c, platform-api....
<kgunn> lool: in order to bump the api properly on the build
<kgunn> lool: so am i ok to assume you will do the approval of those ? (i'll add you as specific reviewer)
<alan_g> kgunn: I don't see that on trunk yet
 * alan_g knows we're in different timezones but...
<kgunn> alan_g: sorry...lool he is right...waiting on merger https://code.launchpad.net/~mir-team/mir/development-branch
<alan_g> kgunn: if you're in a hurry we can merge "by hand"
<Saviq> alf_, approved
<alf_> Saviq: Great, thanks. I guess that applying the second patch fixed the issue then?
<Saviq> alf_, no, but I just don't have all the bits - and the code makes sense
<alf_> Saviq: no = it didn't fix it, or no = you didn't try?
<Saviq> alf_, didn't fix, I'm trying one more thing, though
<Saviq> alf_, with the platform-api and the qtubuntu fixes, it should not crash client-side?
<Saviq> alf_, what about server-side?
<alf_> Saviq: the server side is not (or rather, should not be) affected by these patches
<Saviq> alf_, yeah, but that's the thing - if it crashes server-side anyway
<Saviq> alf_, k, building packages from qtubuntu and platform-api again, then
<alf_> Saviq: right, I am already using the server side fix locally...
<Saviq> alf_, yeah - that's why I'm saying I'm missing the server-side piece
<Saviq> alf_, let me get that, actually
<alf_> Saviq: yeah, if the server crashes all bets are off...
<Saviq> alf_, why is https://code.launchpad.net/~robertcarr/mir/hold-surface-alive/+merge/189400 not approved yet, btw?
<alf_> Saviq: More information is need by some engineers about the why and how.
<Saviq> alf_, k
<alf_> Saviq: for the server side fix you also need the latest unity-mir trunk (actually r106)
<Saviq> alf_, r106?
<alf_> Saviq: I mean r106 contains the change we care about
<Saviq> alf_, ah unity-mir
<Saviq> alf_, sorry, read that as "mir"
<lool> kgunn: I can approve the mps
<lool> kgunn: which one do I need to approve still?
<kgunn> lool: so when mir trunk is ready (e.g. this one is merged https://code.launchpad.net/~mir-team/mir/development-branch)
<kgunn> lool: these will be the additional ones needed approval/merging
<kgunn> unity-mir
<kgunn> https://code.launchpad.net/~kgunn72/unity-mir/bump-mir-dep14/+merge/190010
<kgunn> platform-api
<kgunn> https://code.launchpad.net/~kgunn72/platform-api/bump-mir-dep14/+merge/190011
<kgunn> unity-system-compositor
<kgunn> https://code.launchpad.net/~kgunn72/unity-system-compositor/bump-mir-dep14/+merge/190012
<rsalveti> kgunn: kdub_: with latest image on grouper you should have mir running by default
<rsalveti> so people can still test mir related stuff with n7
<kgunn> alan_g: can you manually merge - i believe autolanding is off
<kgunn> brb
<alan_g> kgunn: Sure
<alf_> kgunn: and qtubuntu
<dholbach> hiya
<lool> kgunn: the three mps look good obviously
<lool> kgunn: ping me when mir is merged
<dholbach> I get quite a bit of flickering and slowness and almost freezing on grouper (r89) - is this a known issue? https://bugs.launchpad.net/mir/ and https://bugs.launchpad.net/unity-mir/ have a few critical issues, but none of them look like what I'm seeing
<tvoss> dholbach, grouper is n7, right?
<dholbach> yep
<tvoss> dholbach, mir won't work correctly with the nvidia driver due to a hybris issue
<ogra_> tvoss, thats fixed
<tvoss> ogra_, really? well then it should work
<ogra_> tvoss, 89 should work fine (despite BT eating your CPU)
<tvoss> ogra_, how so?
<ogra_> udev rule fixes afaik
<ogra_> made Mir work
<ogra_> ask rsalveti details, i only saw the upload pass by
<tvoss> ogra_, would really surprise me
<ogra_> permissions fo rteh graphics devices were all wrong
<tvoss> ogra_, hmmm .. let's check with kdub
<tvoss> kdub_, ping
<alan_g> lool: kgunn mir has landed
<rsalveti> tvoss: had to disable hwcomposer and fix a few deps
<rsalveti> dholbach: that's because latest image is using mir
<rsalveti> a lot slower when comparing to sf
<rsalveti> and still having some crashes
<dholbach> rsalveti, do you know if there's a bug for it?
<tvoss> rsalveti, how did we solve the issue with the nvidia driver using shared mutexes on n7?
<lool> pete-woods: can't top approve this one, would you do it for me please?
<pete-woods> lool: which one?
<rsalveti> tvoss: hwcomposer requires shared mutex, that's I had to disable it
<kdub_> tvoss pong, but in a standup atm
<rsalveti> dholbach: not that I know, we just enabled it
<dholbach> rsalveti, ok I'll file a bug
<rsalveti> dholbach: look for crashes at /var/crash as wlel
<dholbach> is there any additional information I could put in there?
<dholbach> like a log
<lool> pete-woods: sorry EPASTE
<lool> pete-woods: https://code.launchpad.net/~kgunn72/unity-mir/bump-mir-dep14/+merge/190010
<pete-woods> EPASTE!
<pete-woods> I dont know why that made me laugh
<dholbach> rsalveti, doesn't look like it
<rsalveti> dholbach: then just a bug with the behavior should be good
<dholbach> yep
<dholbach> popey, rsalveti, tvoss: I filed bug 1237465 about it
<ubot5> bug 1237465 in Mir "[grouper] Mir adds flickering, it's slower and almost freezes" [Undecided,New] https://launchpad.net/bugs/1237465
<rsalveti> thanks
<olli_> 105412
<olli_> 453699
<olli_> my daughter says hi, ignore
<dholbach> :-)
<dholbach> popey, does /usr/bin/brcm_patchram_plus use lots of CPU on your N7 too?
<popey> dholbach:   702 1002      20   0  1192  256  176 R  98.9  0.0 124:18.24 brcm_patchram_p
<popey> yes
<dholbach> ah yes, ogra_ mentioned it above
<dholbach> hum, you can't turn it off in the indicator
<dholbach> and can't kill or stop it
<lool> mir building in ubuntu-unity/daily-build PPA
<kdub_> tvoss, re-pong (standup is over)
<dholbach> popey, mhall119: maybe you can confirm bug https://bugs.launchpad.net/mir/+bug/1237465?
<ubot5> Ubuntu bug 1237465 in Mir "[grouper] Mir adds flickering, it's slower and almost freezes" [Undecided,New]
<dholbach> ogra_, do we have a bug about BT using all CPU?
<mhall119> dholbach: confirmed
<dholbach> ah yes, bug 1217865
<ubot5> bug 1217865 in bluetooth-touch (Ubuntu) "/usr/bin/brcm_patchram_plus chews 100% cpu on nexus 7" [Undecided,Confirmed] https://launchpad.net/bugs/1217865
<alf_> Saviq: Should I just merge the approved MPs myself into platform-api and qtubuntu, or do we need extra permission?
<mhall119> tvoss: kgunn: what's going on with Mir and Unity 8?
<tvoss> mhall119, not sure what you mean?
<mhall119> tvoss: there seem to be a lot of problems for this late in the cycle
<tvoss> mhall119, well, maguro and mako are our target devices, grouper only recently started to work
<mhall119> is it still just integration issues, or something more fundamental
<tvoss> mhall119, integration issues, and grouper is not a targeted device right now
<mhall119> is it significantly better on mako?  Because I couldn't use it if it's anything like grouper
<tvoss> mhall119, we pass a large chunk of autopilot tests and yes, it is significantly better on mako
<mhall119> how about launching apps?  Right now a lot of them seem to crash on launch on grouper, is that device-specific too?.
<Saviq> alf_, merge
<alf_> Saviq: ok
<tvoss> mhall119, sure
<tvoss> unfortunately, but we need to workaround certain limitations of libhybris together with the nvidia driver and disable the hardware compositor there
<mhall119> "there" meaning on grouper or on mako?
<tvoss> on grouper
<mhall119> ok
<tvoss> mhall119, anything else I can help with?
<mhall119> tvoss: is the latest mako build stable enough to be my daily-driver?
<mhall119> assuming I'm okay with some amount of bugs which I will report
<tvoss> mhall119, best to wait for an officially promoted image
<mhall119> tvoss: are there people using the -proposed images to find and report bugs on them?
<mhall119> using them on actual devices that is
<tvoss> mhall119, for sure, the unity team and the phonedation team for sure
<mhall119> ok
<kgunn> alf_: since you were wondering what you might work on...
<kgunn> alf_: curious...so, we have this stale socket issue with AP tests...sometimes unity8 will crash, but then orphan the mir_socket...then the whole stack fails to start
<kgunn> alan_g: ^ is that actually corrected by the "delete endpoint" code change ?
<alan_g> kgunn: Most cases, yes
<tvoss> kgunn, we just need a post-stop script for the upstart job
<kgunn> Saviq: ^
<alan_g> tvoss: I'd recommend pre-start too
<kgunn> alan_g: ; ) prestart way more effective
<tvoss> alan_g, perfectly fine :)
<Saviq> tvoss, we're not starting unity8 with upstart for ap tests
<Saviq> tvoss, but yeah, that would fix the actual *run unity8* issue - assuming this will happen on restart too?
<tvoss> Saviq, yup, you can fine-tune upstart in that respect quite heavily
<Saviq> tvoss, *I* can't ;P
<Saviq> tvoss, MIR_SOCKET, btw?
<tvoss> Saviq, ENOCONTEXT
<tvoss> Saviq, neither can I :) I'm just citing the manual here
<Saviq> tvoss, the env var for the mir socket
<Saviq> alan_g, MIR_SOCKET, right? â
<alan_g> Saviq: If it's there, yes
<Saviq> alan_g, yeah, and /tmp/mir_socket by default
<alan_g> Saviq: until the next build lands.
<Saviq> alan_g, will there be a default then?
<alan_g> Saviq: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1236912
<ubot5> Ubuntu bug 1236912 in apparmor-easyprof-ubuntu (Ubuntu Saucy) "please use XDG_RUNTIME_DIR instead of /tmp for mir_socket" [High,Triaged]
<Saviq> alan_g, right, thanks
<kgunn> Saviq:  and that is in the process of landing (like lool is literally trying to get it in archive now i believe)
<alan_g> "Please import music and restart the app" - now how do I do that?
<tvoss> alan_g, usually by attaching your phone via usb and just copying a song over
<alan_g> tvoss: I managed it - just didn't feel it was a good user experience
<tvoss> alan_g, true
<tvoss> alan_g, let's tackle that after v1
<alan_g> tvoss: what does "switch back to the music scope" mean?
<alan_g> I can get a screen titled "Music" - but that doesn't show anything I dumped in "Music"
<dandrader> kdub_, ping
<kdub_> pong.
<dandrader> kdub_, I get this regularly when I try to restart unity8 http://paste.ubuntu.com/6208867/
<dandrader> kdub_, any ideas?
<kdub_> which device?
<dandrader> kdub_,  maguro (galaxy nexus)
<kdub_> does it happen during a crash? iirc, that device has problems letting go of the framebuffer
<kdub_> rather, does it happen on the restart right after a crash
<dandrader> it always work when started durring boot up. but if I "stop unity8" and then try to start it from console later on there's a good change it will fail with that message
<kdub_> dandrader, i'll see if i can repro, it seems like something that might happen, given the maguro hal
<dandrader> kdub_, this time for instance. I did "stop unity8". and some 10 minutes later lanched my own "./unity8" from console. it worked. after some testing I killed it with ctrl+C
<dandrader> kdub_, when I tried "./unity8" again I got the error
<dandrader> and consistenly after that
<kdub_> yeah, i think it just ignores my 'free the fb' request
<kdub_> and something later on frees it
<dandrader> kdub_, can I force it to be freed from command line?
<kdub_> not any way i know of... i'll poke around
<dandrader> :(
 * dandrader reboots his device
<dandrader> kdub_, is it worth filing a bug?
<kdub_> dandrader, sure, we can file a bug
<dandrader> kdub_, ok, will do so
 * kdub_ flashes maguro
<tvoss> kdub_, ping
<kdub_> pong
<kdub_> tvoss,
<tvoss> kdub_, are you looking into https://launchpad.net/bugs/1235190
<tvoss> ?
<ubot5> Ubuntu bug 1235190 in mir (Ubuntu Saucy) "[mako] Unity8 on Mir got slow" [High,Confirmed]
<kdub_> there's quite a few issues today :) that's on the plate
<kdub_> i'm not quite synced up to the latest on that one though, just trying to understand more about what's going on
<tvoss> kdub_, ack, we bisected it to changes introduced on the 25th or 26th, which includes the mega revision 1083
<kdub_> tvoss, reviewing
<kdub_> i think that included turning default ipc thread pool count down
<kgunn> racarr: ping
<kdub_> tvoss, nevermind, made a bad diff
<kdub_> one minute
<kdub_> one day i'll learn how to use bzr
<kgunn> racarr: so...what happens if this "hold surface alive" isn't landed for mir yet...but this has already landed https://code.launchpad.net/~afrantzis/unity-mir/fix-1236898/+merge/189894
<kgunn> alf_: in case you're still on...do you  know the answer to my query ^
<tvoss> kdub_, ?
<kdub_> tvoss, i'm a bit confused which slowness this bug is about really
<tvoss> kdub_, hmmm, can you reproduce the issue with image 89?
<kdub_> i'll give it a try... i'm on 89
<kdub_> but i've installed the latest unity/mir stuff by building it
<tvoss> please reflash a clean 89 then
<tvoss> kdub_, ^
<kdub_> tvoss, i can do that, but i feel like there's some fundamental sync i missed out on with this bug
<kdub_> the cpu performance stuff i mentioned in that bug, was that transferred to: https://bugs.launchpad.net/powerd/+bug/1233257
<ubot5> Ubuntu bug 1233257 in powerd "[mako] waking from deep sleep, phone is pretty slow, takes a few seconds to get back to normal speed" [High,In progress]
<Saviq> tvoss, progress (?): only one unity8 test passes in each run, 'cause the next one loses input
<Saviq> lool, â but that means with the "remove socket" branch unity8's dashboard should look much better
<Saviq> ricmm_, â
<Saviq> ricmm_, remember those? ;)
<Saviq> kgunn, ââ
<ricmm_> next one loses input?
<kgunn> Saviq: is that with image 89 + packages from ubuntu-unity/daily-build ?
<Saviq> kgunn, no, think anything related got fixed?
<kgunn> Saviq: well, at least, loic said the latest mir is in the dialy-build ppa
<kgunn> so it would have alan_g's remove socket
<kgunn> you'd have to pull....libmir*'s and unity-mir and platform-api
<Saviq> kgunn, I'm building that stuff locally to have other fixes, so will know in a few
<tvoss> Saviq, ack
<tvoss> Saviq, could you check the webbrowser tests?
<Saviq> tvoss, am building
<Saviq> tvoss, it *really* takes some time
<Saviq> tvoss, especially since unity-mir trunk requires mir > 0.14 now
<Saviq> or something
<tvoss> Saviq, ack
<Saviq> so I need to build mir (I needed to anyway, to verify another fix)
<Saviq> 80% there
 * Saviq wants proper cross-build
<racarr> kgunn: Probably alfs branch landing alone
<racarr> improves things
<racarr> but its hard to be sure
<kgunn> racarr: so i guess...only thing
<kgunn> racarr: only thing keeping yours from landing is
<kgunn> racarr: a satisfactory answer to alan
<kgunn> ?
<racarr> maybe yeah
<racarr> hmmm
<racarr> kgunn: Tried to prod the conversation along
<racarr> oh hey there is going to be
<racarr> a qt developer days in San Francisco
<kgunn> racarr: sure...qt dev days (as long as its after oct :)
<kgunn> racarr: and you can get that mp landed (at least i am assuming it still fixes one of the crashes)
<racarr> Yeah in november XD, its only two days
<racarr> ill roll over and loudly make calls on my ubuntu phone
<racarr> "HEY! YEAH. IM CALLING YOU FROM MY UBUNTU PHONE. IT'S A GREAT PLATFORM TO DEVELOP APPS IN QT YEAH"
<racarr> :p um
<kgunn> hey...so alan's comment "However, I've yet to convince myself that resources are released in a timely manner (i.e. shortly after the surface is destroyed by the client"
<racarr> right so I am not
<kgunn> seems crazy...surely we should "guarantee"
<kgunn> not hope things happen timely enough ?
<racarr> sure what exactly we mean
<racarr> well ok, the previous model
<racarr> is as soon as the client disconnects
<racarr> the underlying surface resources are destroyed
<kgunn> ok...makes sense so far
<racarr> the wrapper object might stay around but it will throw exceptions when ever you use it
<racarr> the new model, is
<kgunn> who's using him in this "tranisiton state" of gone client/destroyed surfaces ?
<kgunn> him=wrapperobj
<racarr> Well, that's the problem, lots of people! in mir it's only the focus mechanism
<racarr> but the shell has, std::shared_ptr<msh::Surface> in many places
<racarr> or more correctly, std::weak_ptr<msh::Surface>
<kgunn> ah..basically, shared buff/surf obj
<racarr> and the problem is, it wants to promote them to shared_ptr<msh::Surface>
<racarr> and then use it a little if the object is still around
<racarr> the problem is, you promote it, then WHILE you are holding the shared_ptr, the underlying surface can be destroyed
<racarr> the wrapper stays alive
<racarr> you get exceptions
<racarr> so the new model, is holding the shared_ptr to the shell surface actually keeps the
<racarr> underlying surface alive
<racarr> so, hypothetically some component grabbing on to the surface besides the client
<racarr> could keep surfaces alive beyond hte client lifespan
<racarr> actually I think this is behavior we need eventually, for some like shell animations, etc.
<racarr> but mostly it's about very small races
<racarr> I guess Alan is concerned
<racarr> with a situation where
<racarr> basically we just leak memory because
<racarr> we end up holding the shared_ptrs indefinitely
<racarr> but
<racarr> hmm I don't think so
<racarr> because we would have been leaking the
<racarr> msh::Surface anyway before (just not the underlying resources)
<racarr> so we would have gotten some valgrind
<racarr> errors
<racarr> alan may be conceerned about something else "released in a timely manner"
<racarr> is a strange choice of words
<kgunn> so what triggers the eventual release of these surfaces (if they're shared, and the traiditional owner...the client is gone...but they're alive)
<kgunn> is there like a surface death pool
<kgunn> like...this hasn't been used in a while...i should probably kill it?
<kgunn> or...??
<kgunn> i guess alan might rightly be worried this might depend on the shell behaving very hygenically
<kgunn> racarr: ^
<racarr> kgunn: I mean normally the release is immediate because the shell
<racarr> shouldn't hold a shared_ptr
<racarr> just the weak_ptr, which will allow the object to die
<racarr> then it should promote it, and it might hold the object alive then for a little while
<racarr> but when the last shared_ptr to it goes out of scope the surface is released
<kgunn> racarr: ah, ok
<racarr> unity-mir is actually doing something a little strange now...in that it IS holding a shared_ptr, but it is removing it
<kgunn> racarr: but it does depend a litle on shell having good hygene
<racarr> in the "surface destroyed" callback from
<racarr> the session listener
<racarr> yes
<racarr> thats what alf went through and
<racarr> found the one fix
<kgunn> ok
<racarr> and it seems fine now but its certainlly a concern
<racarr> I think, I mean
<kgunn> racarr: right concern in theory...but should be fixed
<racarr> right and in theory
<kgunn> racarr: and...your fixes squelches all the exception bitching it might do
<racarr> well, the shell is always going to be
<racarr> capable of leaking memory somehow
<racarr> XD
<kgunn> of course...ok.. racarr i have the feeling we should promote
<racarr> eh, that's not really a useful thought. there is some case that we should make it really hard
<racarr> but I think
<racarr> weak_ptr does it
<kgunn> or merge
<racarr> kgunn: I think it's safe...but unless it's a race, lets wait an hour or two I started
<kgunn> racarr: what are we waiting on  ?
<racarr> I am thinking about
<racarr> potential races
<racarr> that could cause the surface to be held alive for a little while (thinking maybe thats what Alan was getting at)
<kgunn> racarr: ok..i'll let you think...only reason i am pushing is lool is willing to pull this in (since we broke api anyway)
<racarr> ok what is the timeline on that?
<kgunn> altho..he will need to sleep eventually :)
<tvoss> kgunn, 40 minutes until meeting
<racarr> ok well I think we should just do it then
<racarr> I mean I ran it for like
<racarr> about 4-5 hours of actual
<racarr> use
<racarr> no crashes at all
<racarr> I installed apps, and used them and everything
<racarr> it was a whole phone experience
<kgunn> racarr: ok, that makes me feel good
<tvoss> racarr, go for it :) you will never find out otherwise
<kgunn> i say let's do it and apologize to alan tomorrow :)
<racarr> boom
<kgunn> lool we're gonna go for it ^
<racarr> alf_: What were the client side issues around destroying surfaces you mentioned finding
<kgunn> racarr: can you do the manual merge on dev branch
<racarr> alf_: I did some testing again a few days ago, and I think with hold-surface-alive, all the server side issues are fixed for mir-stress test
<racarr> but the problem is 1 or 2 clients (out of say 10,000) dont end up seeing surface released responses
<racarr> and hang
<racarr> (ADD...just want to connect the dots while I remember)
<racarr> kgunn: ...err like...
<racarr> kgunn: What is our process there
<racarr> merge branch, commit, push to dev branch
<kgunn> racarr: yes...
<kgunn> racarr: then...we mp to trunk...same thing, branch, merge, comit, push
<racarr> oh man it's been a long time since I got to merge and push myself
<racarr> the good old days, where if you were drunk at 2am and wanted to rewrite a compiz plugin there was no "Jenkins" to stop you.
<lool> racarr: so this new branch, did we confirm the bug is fixed with it?
<lool> IIRC, it was triggering rendering glitches and a crash
<lool> could we reproduce and it's gone?
<lool> I dont need the gory details of the bug, just confirmation it's doing what it's expected to do  :-)
<lool> then we can land it in PPA, I can test Mir with it, and we can push to archive
<kgunn> lool:  he ran for 5 hours, full phone experience, and didn;t get crashes
<lool> cool, but did he get the crashes before?
<racarr> Yes
<racarr> but with
<racarr> small scientific error :p
<lool> Eh, what do you mean? :)
<racarr> in that there is 1 day of commits, I guess everything that landed in the 24 hours prior to yesterday morning
<racarr> which I did not reproduce the crashes on
<racarr> so I haven't ruled out
<racarr> that they are already all fixed
<racarr> and the branch does nothing
<kgunn> lool:  i thnk with all the effort to kill the crashes...its harder to repro
<kgunn> lool: so its an "in theory" fix due to the stability that has recently gone in
<racarr> well, no I mean
<racarr> lol
<racarr> science is hard. I think it fixes a few crashes :p
<lool> so possibly the branch does nothing, but it's 100% sure it's not hurting either
<lool> if you guys are more confortable fixing other things with ths in place, then let's go ofor it
<kgunn> lool: yep...
<lool> if you have merge proposals up, I can trigger ci runs or upstream merger depending on status
<racarr> Oh right
<racarr> *alt tabs back to terminal to push toi dev branch*
<kgunn> lool: racarr is gonna manual merge onto dev...
<kgunn> lool: then we can mp onto trunk...at that point, that'd be a good ci trigger
<racarr> Ok pushed to dev branch
<kgunn> racarr: ok...mp for trunk here... https://code.launchpad.net/~mir-team/mir/development-branch/+merge/190224
<kgunn> can you approve
<kgunn> then lool can you trigger a ci run on that ^
<kgunn> lool: and note, it'll require rebuild of unity-mir, unity-system-compositor, platform-api again
<kgunn> in your packages
<racarr> kgunn: Approved? do I need to top approve?
<lool> looking
<kgunn> racarr: either...i can t.a.
<kgunn> lool racarr ok...top approved
<lool> running
<lool> ci part
<kgunn> (and no ones even drunk)
<lool> speak for you young man!
<kgunn> :)
<racarr> lol
<racarr> ok going to take a ten minute stroll to stretch my legs
<racarr> will be back for hangout
<kgunn> lool so as its running ci, will it autoland/jenkins merg too ? (or just spit results?..e.g. do we still have to manual merge)
<lool> kgunn: that's another thing I need to run next
<kgunn> ok
<lool> kgunn: but I can also land it
<lool> in theory
<tvoss> Saviq, you still around?
<Saviq> tvoss, yup
<tvoss> Saviq, did your local build finish?
<Saviq> tvoss, almost
<Saviq> tvoss, building unity-mir now
<Saviq> everything else is built, so will know soon
<kgunn> lool its also worth pointing out...2 other trunks were updated with crash fixes...qtubuntu & unity-mir
<tvoss> Saviq, ack
<kgunn> lool: updating ask sheet now
<lool> kgunn: I have one for unity-mir + hud that pete-woods prepared
<lool> in plan
<racarr> ...
<racarr> for about five minutes I've been trying to figure out what is happening on my phone because it looks like the screen is kind of flickering in a weird really fast way
<racarr> lightbulb is going out
<racarr> lol
<racarr> phone is fine :D
<lool> kgunn: can we land qtubuntu standalone?
<racarr> I think so
<lool> kgunn: and where's the qtubuntu stuff?  I see one change in trunk
<racarr> 186. By Alexandros Frantzis 3 hours ago
<kgunn> lool: ^ that's the one
<lool> Just FYI, device didn't come up after boot with the Mir packages in PPA
<lool> or I can't unblank the screen
<racarr> ...gulp
<racarr> wait do you have
<racarr> new unity-mir too?
<lool> yes
<lool> racarr: everything prior to your landing
<lool> ah it fainlly turned up
<racarr> new platform-api mirserver?
<lool> basically I preseed power button
<lool> screen went on but black
<lool> remained so for ~1mn
<lool> then unity8 came up
<lool> I think it crashed
<lool> now it's there
<tvoss> lool, will be 5 minutes late to the hangout
<robert_ancell> racarr, I remarked your surface alive branch as approved - heisen test failure
<racarr> robert_ancell: We manually
<racarr> merged it to dev branch
<robert_ancell> oh, ok
<racarr> thanks though :D
<racarr> Lunch lunch
<lool> kgunn, racarr: I was actually expecting a round of build-dep bumping for the second branch merge, but I guess you guys wanted me to rebuild everything against mir in PPA?
<kgunn> lool: how do you want it done....if you rebuilt it'd be easier i would thikn....but let me know
<kgunn> it'd take about 45 min to get the mp's all queued and mir trunk updated (at best)
<lool> kgunn: I think it's less tracking if we dont rebump
<lool> but I need to be careful in PPA
<lool> I might have to force stuff in PPA, but I think I know the flag, just never used it so far
<lool> will try that way, will see if I manage
<kgunn> lool thanks and let me know if we need one
<lool> ok
<lool> racarr, kgunn: I tried qtubuntu-android from PPA with the Mir I had before the last racarr landing, but the test cases from alf crashes for me even after reboot
<lool> Can you guys think of another change that would be needed?
<lool> racarr: if you could confirm it also happens with your tip, that would also clarify whether we want the qtubuntu change or not
<lool> well, I guess it's not a regression since it crashes before and after, still would like to know if it works  :-)
<kgunn> lool: just to confirm...the only thing crashing is the standalone additino of qtubuntu ?
<lool> kgunn: the bug has a testcase close.qml
<lool> kgunn: this is supposed to fix a crash on the testcase
<lool> kgunn: I get the crash with old and new qtubuntu
<kgunn> lool: ah...so it was something already broken ?
<kgunn> ah sorry...i'm loosing it
<kgunn> i see...it doesn't fix what it says
<lool> right
<kgunn> lool: hmm, well....w/o alf_ we can't say for sure...up to you if you prefer to reject, team seemed confident it would help crashers
<racarr> back nice and relaxed...lets see what can get me wound up again :p
<racarr> lool: Hmm. What do you need me to test?
<racarr> if this close.qml is crashing on the client side
<racarr> hold-surface-alive, etc
<racarr> wont help it
<racarr> I think alf was speaking of both some qt ubuntu bugs and some interelated stuff perhaps in mir client
<racarr> so this may just be a partial fix
<lool> racarr: could you check with your latest packages, just to confirm?
<racarr> lool: You mean trunk of everything
<racarr> lool: XD...ok it will take a while though because I just wiped away my phone image with latest trunk of everything
<racarr> to test the last image...
<lool> well ok, I'll just punt it for now
<lool> I'll see how the rest go
<lool> it's easy to take it in
<racarr> ok
<racarr> I should be able to test within 1 hour
<lool> or I can just suck it in, I mean it's not regressing more
<lool> I'm pushing it
<racarr> lool: I think thats what I would od, suck it in
<racarr> the thing is it fixes some memory corruption
<racarr> so even if that memory corruption is not the crash
<racarr> it gives us a more stable playing field
<racarr> to iterate on next time
<lool> gosh, mir finally merged
<racarr> :D
<kgunn> bbiab
<lool> racarr, kgunn: https://launchpadlibrarian.net/153261612/buildlog_ubuntu-saucy-amd64.mir_0.0.14%2B13.10.20131009.4-0ubuntu1_FAILEDTOBUILD.txt.gz
<lool> FTBFS on amd64
<lool> [  FAILED  ] 2 tests, listed below:
<lool> [  FAILED  ] ServerShutdown/OnSignal.removes_endpoint_on_signal/0, where GetParam() = 3
<lool> [  FAILED  ] ServerShutdown/OnSignal.removes_endpoint_on_signal/1, where GetParam() = 6
<bschaefer> does mir handle clipboards? (cut/copy/paste?) As I don't see it mentioned in the api anywhere :)
<kdub_> not that i know
<bschaefer> thanks
<RAOF> bschaefer: No; one of the things for a (hopefully upcoming?) architecture sprint :)
<bschaefer> that would be nice :)
<racarr> lool: Looking
<racarr> lool: I can't derive anything useful from the log
<racarr> its probably a test race
<racarr> its a new test
<racarr> so I dont know much about it
<racarr> its probably only intermittent
<lool> racarr: do you pass the tests on amd64?
<racarr> lool: Let me do a clean build of tyrunk
<racarr> almost got phoen ready to test too
<kdub_> racarr, compile the world? :)
<racarr> everyones FAVORITE GAME
<racarr> ive gotten good at pipelining the network intensive cpu intensive and io intensive tasks though
<racarr> definitely faster at it
<racarr> lol
<kdub_> haha
<racarr> lool: ancdetotally startup seems faster...
<racarr> close.qml is still segfaulting on close
<racarr> lool: Where areall the keyboard changes...I need um
<racarr> well I built mirserver, qtubuntu, unity-mir and platform API
<racarr> but there is some keyboard weirdness
<racarr> but guessing I just need dandraders patch
<lool> racarr: ubuntu-keyboard is up in PPA
<lool> racarr: rebuild worked for mir
<racarr> lool: There is something wrong with this test though
<racarr> I've been hung on it for like 1 minutes...
<lool> racarr: could you log a bug on it?
<racarr> lool: https://bugs.launchpad.net/mir/+bug/1237710
<ubot5> Ubuntu bug 1237710 in Mir "Intermittent (frequent) acceptance test failure on OnSignal.removes_endpoint_on_signal" [Undecided,New]
<lool> thx
<racarr> lool: I am looking at it...havent found out whats going on yet
<racarr> but also seems pretty low risk
<racarr> if anything real is broken, its just aboiut server shutdown (and potentially the server coming back up because the socket file might have been left creating problems)
<racarr> but, it seems like it was already broken as well
<lool> racarr: FIY https://launchpad.net/~lool/+archive/ppa/+build/5089424
<lool> racarr: I'm not too worried about the test and code, it's more a pain to deal with when we're uploading stuff
<racarr> lool: Ok just confirmed with new ubuntu-keyboard things are working better
<racarr> also not getting an issueI was getting yesterday with
<racarr> some keys giong through to the dash when using the search box :)
<lool> cool
<racarr> um ok ugh another failed build?
<lool> racarr: it was a copy in my PPA to rebuild
<lool> racarr: https://launchpad.net/~lool/+archive/ppa/+build/5089423 also has fails
<lool> so very flaky tests
<racarr> mm :/
<racarr> the server shutdown tests are new and im not sure what's up
<racarr> just fiddled with the build a bunch on my phone...lots of input quirks gone
<lool> getting the dreaded   what():  Could not unblank display
<lool> hmm I dont see the socket
<kdub_> lool, push the power button and try again
<lool> I did  :-/
<lool> unity8 was restarting in a loop
<lool> screen is on
<lool> I pressed power, it retried but didn't come up
<lool> I also tried powerd-cli display on
<lool> now I've rebooted and it's the same
<lool> ah no it's starting still
<lool> now it's looping
<lool> but differently
<lool> unity8 crashes on startup now
<lool> ok, reflashing, taking just these
<racarr> Got to run out for an hour
#ubuntu-mir 2013-10-10
<lool> so I reinstalled
<lool> I got the same bug, but eventually it started
<lool> the timing for pressing power button might matter
<lool> racarr, kgunn: Pretty good news
<lool> racarr, kgunn: It was borderline unstable, but now that I have hud with it, unity8 doens't crash anymore and boot is much more stable
<lool> and everything is going in archive, one at a time
<kgunn> lool: thanks man!
<lool> kgunn: we have an issue with Hud
<lool> kgunn: it's likely regressing the desktop
<lool> kgunn: who would be able to help this?
<lool> kgunn: I can land without it, but the results will be crappy
<kgunn> lool: i assume its likely backend ?? ted would be best
<kgunn> but doesn't seem on
<lool> ted isn't up til 10 hours
<lool> at least
<kgunn> i know the issues were around the backend....
<lool> kgunn: So they added a platform-api backend
<lool> kgunn: but on desktop I think we still want bamf
<lool> but we dropped the bdep
<kgunn> olli_: you on ?? ^
<kgunn> lool: thostr_ will be our best bet euro am
<lool> ok
<lool> I might try just adding the bdep
<kgunn> you could get some sleep man and hit it in the morning
<lool> yeah that too
<kgunn> ricmm_: know anyone who knows about hud backend ?? ^
<racarr> back
<racarr> seems like we definitely need bamf on desktop
<racarr> lool: Good to hear image is working better with hud :D
<racarr> is boot faster now too?
<racarr> unity mir boot has been really slooow
<racarr> and ive kind of suspected it has to do with errors about hud timeouts :p
<olli_> kgunn, yep
<ricmm_> kgunn: what happened?
<ricmm_> lool: I explicitly remember them saying "we both tested on desktop and phone and all works fine"
<ricmm_> lool: how did the MR land to trunk if it didnt have the bamf build dep?
<ricmm_> oh that was 3 hours ago
<ricmm_> crap
<ricmm_> his fix looking good
 * ricmm_ -> zzz
<ricmm_> kdub_: btw if you are still around
<ricmm_> kdub_: timings show that unity8 is busy blocking on buffer swap for about ~50ms per frame every other frame or so
<ricmm_> when rendering intensively
<ricmm_> racarr: kind of suspected? its a known thing since ever!
<racarr> ricmm_: I guess I didnt know it was known because the one or two times I mentioned it no one said anything
<racarr> and I was just like
<racarr> ok move on!
<RAOF> Ok. How have I managed to break egl-platform-mir?
<duflu> RAOF: If you expect either a useful or amusing answer, I can't comment
<duflu> racarr: (1) log off, else (2) Should bug 1233245 have Mir task?
<ubot5> bug 1233245 in Mir "[mir] key events not working through input devices (aka volume up/down)" [Critical,Triaged] https://launchpad.net/bugs/1233245
<ricmm_> that bug is done afaik
<duflu> ricmm_: BTW, the "50ms per frame", what device?
<ricmm_> mako
<duflu> Oh. Mako should be better than that already
<ricmm_> theres a whole bug going on since the fencing was introduced to remove the tearing
<ricmm_> of course it *should* be
<ricmm_> but it hasnt been for a while
<duflu> ricmm_: Yeah I was going to point you at that bug
<tvoss> ricmm_, do you know if kdub tried switching to triple buffering while I was sleeping?
<ricmm_> tvoss: he didnt because apparently its not trivial to do
<duflu> It occurs to me we have a significant bottleneck for touch with only one Android person on mir-team
<RAOF> Dear bandwidth: where have you gone? :(
<tvoss> didrocks, salut :)
<didrocks> hey tvoss!
<alf_> lool: Which PPA contains the packages you used to test the fix to the close.qml crash (or have the packages reached the archive now)?
<alf_> lool: FWIW, with latest packages from the archive, I can't reproduce the crash anymore
<RAOF> Bah! How was mesa mis-built?
 * mlankhorst looks at excuse calendar
<mlankhorst> high pressure system failure
<RAOF> Current theories include: cosmic rays, and clang.
<mlankhorst> well a computer generated my excuse, so it's more reliable
<duflu> But did cosmic rays affect the computer's output?
<mlankhorst> we're not in space
<duflu> Yes we are
 * duflu goes to close the pod bay doors
<lool> alf_: it's all in #90 now
<lool> alf_: racarr also gets the crash with latest tip
<lool> alf_: I haven't tried again though
<lool> alf_: maybe we landed something else from archive in image that we were lacking in testing
<alf_> lool: are you tests with mako or maguro
<alf_> ?
<lool> alf_: haven't retried yet
<lool> alf_: but if you're not seeing it with latest image great
<lool> alf_: mako
<alf_> lool: ok, please give it another try when you can and let me know
<lool> yup
<lool> breakfast first
<duflu> Hey I got my phone back!... How do I tell the image number (like "90")?
<alf_> duflu: cat /etc/media-info gives you some information, which you can use to find the image number
<duflu> Ta
<alf_> duflu: of course, if you upgrade packages then this is not accurate any more
<duflu> None seem to need upgrading...
<tvoss> duflu, just reflash 90 :)
<duflu> Did we kill off /tmp/mir_socket for unity8?
<alf_> duflu: look in $XDG_RUNTIME_DIR
<alf_> tvoss: a great problem with reflashing is that it deletes your development environment on the phone... it's a big waste of time to set it up again (get all the build-deps and -dbg(sym) packages, tools etc)
<alan_g> alf_: +1
<alan_g> alf_:  (and every time I think I understand it well enough to write a script something changes)
<mlankhorst> hm anyone got something for me to look at? :P
<alf_> duflu: since you have a fresh image, do you have a moment to try https://bugs.launchpad.net/qtubuntu/+bug/1237052 ?
<ubot5> Error: Could not gather data from Ubuntu for bug #1237052 (https://launchpad.net/bugs/1237052). The error has been logged
<duflu> alf_: Just put it away. I'll get back to it soon
<tvoss> alan_g, https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags/+merge/190316
<alf_> duflu: ok, btw you don't need to build anything, all fixes are in the archive now (check my last comment in that bug)
<alan_g> tvoss: ack
<tvoss> alan_g, waiting for CI to produce a testable package
<alf_> mlankhorst: nested Mir EGLImage support is still pending if you are interested ;)
<mlankhorst> hm fine :P I'll poke it a bit more
<alf_> mlankhorst: I know that RAOF also took another look recently, but I am not sure if there was any progress
<alf_> RAOF: ^^
<alf_> mlankhorst: (or at least that he wanted to take a look)
<alan_g> tvoss: see https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags/+merge/190316/comments/436722
<tvoss> alan_g, duflu: it's about our own usage of pthread
<duflu> tvoss: Can you detail the findings in the MP?
<tvoss> duflu, the linked bug points to a very weird issue when a client tries to access the display configuration. Same happens for maliit server, which results in a lot of crashes during test automation
<duflu> tvoss: Ah yes, spent time staring at those crashes today
<tvoss> duflu, alan_g was able to reproduce the issue with a simple program using a std::unique_lock and not adding -pthred
<tvoss> -pthread
<alan_g> tvoss: the maliit server definitely pulls in pthreads
<tvoss> alan_g, but: our client library is not compiled with that flag
<tvoss> alan_g, and that's where the exception is thrown
<duflu> tvoss: It's a theory, but I'm not convinced the Mir code is in need of any more "-pthreads", because it would be crashing immediately in the same way (which it doesn't)
<alan_g> tvoss: what duflu said
<tvoss> duflu, anyway, I'm only sticking to what the pthread manual suggests: add -pthread
<tvoss> alan_g, duflu I'm basically waiting for jenkins to produce a testable package, thus the mp
<alan_g> duflu: I don't think it hurts to try this
<duflu> AFAIK -pthread just defines some macros and adds -lpthread to LDFLAGS
<tvoss> duflu, implementation defined
<tvoss> duflu, usually REENTRANT is set, but could be more complex for arm for example
<duflu> alan_g: It's likely unnecessary bloat to link libraries not all binaries need. Though I suspect all Mir binaries do :/
<tvoss> duflu, if you have got a better idea to solve it -> go for it :) as long as the maliit server crashes are down to 0 in http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/90:20131010:20131010/4644/
<alan_g> duflu: If it fixes the problem that is a useful data point
<tvoss> duflu, library bloat -> micro optimization, let's save that for later
<duflu> Not worth arguing...
<tvoss> duflu, ack
<duflu> tvoss: Worth a try. Linked bug 1233988 too
<ubot5> bug 1233988 in platform-api (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Confirmed] https://launchpad.net/bugs/1233988
<tvoss> duflu, thx
<tvoss> duflu, can you give the package a spin, too, once ci spits it out?
<duflu> tvoss: Sure but I think I'll be gone before then.
<tvoss> duflu, ack :)
<mlankhorst> alf_: huh? this is messed up
<mlankhorst> oh nm :P
<mlankhorst> alf_: so I assume the problem is in the nested mir somewhere, what is the image supposed to be for empty server, is it cleared?
<alf_> mlankhorst: yes, it's glClear()-ed, and then surfaces are composited
<alf_> lool: any luck with https://bugs.launchpad.net/qtubuntu/+bug/1237052 ?
<ubot5> Ubuntu bug 1237052 in qtubuntu "Apps that close themselves crash trying to use deleted EGL resources" [Undecided,Fix committed]
 * duflu goes to play with vegetables
<tvoss> alan_g, https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/831/console
<tvoss> alan_g, is that known?
<alan_g> tvoss: it wasn't to me - but https://bugs.launchpad.net/mir/+bug/1236698
<ubot5> Ubuntu bug 1236698 in Mir "The following tests FAILED: 99 - memcheck(unit-tests.PublishedSocketConnector.*) (Failed)" [High,Triaged]
<tvoss> alan_g, are you on it?
<alan_g> tvoss: I'll add it to my list
<lool> alf_: sorry didn't have time so far, but I do now
<lool> alf_: and it worked!
<lool> alf_: So I didn't have all the in distro changes when I tried that yesterday; I definitely had updated qtubuntu, and had an intermediate update of the mir packages, but not anything else
<alf_> lool: \o/
<lool> alf_: but now with image #90 it passed
<lool> alf_: sorry for the delay in confirming
<mlankhorst> alf_: huh..
<mlankhorst> why is dri2_create_image_khr_pixmap never called? :P
<lool> alf_: I'm glad it's fixed after all, I almost didn't take qtubuntu in because of this
<lool> alf_: updated bug too
<alf_> lool: thanks
<mlankhorst> oh nm
<alf_> mlankhorst: :)
<mlankhorst> alf_: hm if you use the native platform allocator for allocating buffers, what do you use for allocating the main window for nested?
<alf_> mlankhorst: the host mir allocates that and sends us the buffer (host mir uses platform_drm)
<mlankhorst> yeah where's the code for importing that?
<alf_> mlankhorst: in mesa mir_advance_colour_buffer()
<alf_> mlankhorst: it uses the prime_fd from the buffer package
<alf_> mlankhorst: i.e. the host mir essentially sends the nested mir the prime fd for the "main window" surface, and nested mir passes that to mesa
<mlankhorst> alf_: yeah but if the nested mir has no clients, does anything clear the contents of the bo?
<alf_> mlankhorst: yes, it is made current, and glClear() is called
<alf_> mlankhorst: prime_fd -> EGLSurface -> make_current -> glClear()
<alf_> mlankhorst: (at least this is what should be happening)
<mlankhorst> can I somehow enable the spam from mir?
<alf_> jibel: I am checking the Mir Testing Notes document for bugs to look into... is bug 1237900 still private?
<ubot5> Error: Launchpad bug 1237900 could not be found
<alf_> jibel: or is it a typo?
<alf_> jibel: It's the last bug in Image 90:20131010:20131010 list
<jibel> alf_, it is public now but invalid
<asac> racarr: alf_: any news on the crashers front?
<asac> Saviq: ^^ (unity8 crashes in particular i think)
<alf_> asac: Most of the crashes caused by the interaction with Mir have been fixed in the latest image
<asac> we still see unity8 crashing http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/91:20131010.1:20131010/4658/webbrowser-app-autopilot/
<asac> this doesnt happen with SF
<asac> just run webbrowser autopilot
<alf_> asac: that seems like https://bugs.launchpad.net/ubuntu/+source/platform-api/+bug/1233988, which is in progress from what I can see
<ubot5> Ubuntu bug 1233988 in platform-api (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Confirmed]
<ogra_> can someone tell me where Mir gets the VSYNC info from ?
<asac> alf_: there is maliit and unity8 crash
<asac> alf_: you say that unity8 crash goes away if maliit doesnt crash?
<mlankhorst> bleh stupid thing, glClear being ignored;S
<asac> alf_: _usr_bin_unity8.32011.crash
<alf_> asac: I am not saying anything :)
<asac> hehe
 * ogra_ is fiddling with bug 1234743 and moving the VSYNC event from a uevent to a sysfs node makes Mir choke while surfaceflinger still starts
<ubot5> bug 1234743 in linux (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus" [Undecided,Incomplete] https://launchpad.net/bugs/1234743
<asac> well, you said its in progress most likely... but that smells like the maliit fix
<asac> not the unity8
<asac> alf_: the unity8 goes away on SF as well
<asac> i wouls suggest embracing that as a crash that is caused by MIR interactions
<mlankhorst> oh you've got to be kidding me
<alf_> asac: not how I diplomatically said that *most* of the crashes... have been fixed ;)
<alf_> asac: s/not/note/
<asac> right
<asac> are you on this one?
<alf_> asac: I am now
<asac> any leads/hopes?
<asac> nice :)
<alf_> mlankhorst: ?
<mlankhorst> nah was hoping for a more logical explanation, meh
<mlankhorst> I'll try without radeon, and use intel, at least it has dri2 support. :P
<mlankhorst> alf_: but that code was working with android right?
<alf_> mlankhorst: yes
<mlankhorst> alf_: only thing i found so far is that linuxvirtualterminal should probably not be created in nested, meh
<alf_> tvoss: What's the problem in maliit with bug 1233988? I have found a problem in platform-api related to this, too...
<ubot5> bug 1233988 in maliit-framework (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Fix committed] https://launchpad.net/bugs/1233988
<alf_> lool: ^^
<alan_g> alf_: tvoss is exploring the theory that because we've not linked the Mir client library against pthreads maliit blows up. (I don't know if the theory has been tested yet)
<tvoss> alan_g, issue is solved, it wasn't that in the end
<tvoss> alan_g, but: -pthread is still a good idea
<alan_g> tvoss: then what was it?
<tvoss> alan_g, maliit trying to access mir, without mir running :)
<tvoss> alan_g, working on a fix to the platform api
<tvoss> alan_g, it should handle that situation more graceful
<alan_g> tvoss: "mir running" == there's a Mir connection?
<alf_> tvoss: lool: alan_g: see my latest comment and MP in https://launchpad.net/bugs/1233988
<ubot5> Ubuntu bug 1233988 in platform-api (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,In progress]
<mlankhorst> alf_: meh I'll try what happens if I always enable gbm, ran out of other ideas :P
<alan_g> alf_: tvoss I see. But Mir is also behaving badly - it ought to fail operations, not crash. (One reason for returning an "Error" connection is that it can provide sensible error mode behaviour)
<alf_> alan_g: agreed
<tvoss> alan_g, true. I won't find time to fix that part, though
<mlankhorst> alf_: ah excellent, if I force the gbm path to be always taken it corrupts too, that makes it a lot easier to debug..
<mlankhorst> http://paste.debian.net/55230/
<mlankhorst> to the best of my knowledge, it should behave identically right?
<alf_> mlankhorst: when you have some time please check https://code.launchpad.net/~hikiko/mir/mir.fix-in-session-leader/+merge/190353 (also see my comment there)
<asac> alf_: did your crash investigation give reason for hope :)?
<alf_> asac: got caught up in https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1233988, wanted to fix the strange crash to ensure it's not involved somehow with the ap failures/maliit
<ubot5> Ubuntu bug 1233988 in platform-api (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,In progress]
<alf_> asac: so no direct progress there yet
<racarr> good mirning
<hikiko> alf_, I replied just now
<kgunn> racarr: mornin'
<lool> alf_: looking
<lool> alf_: platform-api change to detect whether connection is truly good seems a good idea
<lool> alf_: but I'd rather not confirm the exact semantics of the functions you're calling etc.
<lool> alf_: would someone else review this?  then we can add this to landing plan
<racarr> trying out new image :)
<alf_> racarr: want to review https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378 ? :)
<tvoss> alf_, did you remove the anon namespace in the header file? :)
<racarr> alf_: only somewhat happy :p
<racarr> alf_: +1
<alf_> racarr: thanks
<racarr> image seems really good
<racarr> I'd really like to fix the
<racarr> screen unblank buffer
<racarr> bla
<racarr> actually now
<alf_> tvoss: no, why?
<asac> any luck on unity8 crashers? :)
<asac> lol
<racarr> asac: Autopilot you mean?
<asac> unity8 crashes
<asac> during autopilot its easy to reproduce yes
<asac> just run webbrowser AP
<asac> and it will crash
<asac> 5 out of 6 times
<racarr> ok I guess I can work on autopilot failures today
<tvoss> alf_, an anonymous namespace in a header file is usually a bad idea
<asac> racarr: note that its not really autopilot failures... its just the best and easiest to reproduce crashers we have right now :)
<asac> we see loads of crashers that are hard to reproduce in QA
<asac> so we can start here and hopefully the world will improve :)
<racarr> asac: :D
<asac> anyway. let me know ifyou need something
<asac> those are real crashers ... we dont start unity with special instrumentation flags or anythig
<asac> if we run application autopilots
<asac> thanks!
<alf_> tvoss: sure, "why" == is it related to the 1233988 problem in some way?
<tvoss> alf_, nope
<alf_> racarr: btw, keep in mind that running the tests one by one seems to work just fine, which give a hint to what the problem is...
<alf_> tvoss: ok :)
<asac> alf_: you talk about webbrowser?
<asac> there are two things:
<asac> a) webbrowser tests fail and make unity super slow after they finish
<lool> racarr: didn't top approve?
<asac> b) webbrowser tests crash unity8 more or less relliably
<racarr> asac: I...lost the bug that someone put autopilot instructions in. Is there a summary somewhere?
<lool> ah right, two reviews I guess
<lool> alf_: so once that's top approved ping me to get it in PPA for testing
<racarr> lool: Hmm no someone could top approve I guess
<asac> racarr: https://wiki.ubuntu.com/Touch/Testing#Testing_your_Ubuntu_Touch_Code_before_submission
<asac> give that a shot
<kgunn> racarr: for running AP tests run 'phablet-click-test-setup' to download all the test cases
<kgunn> 'phablet-test-run <suite>'...e.g. unity8
<lool> to run tests:
<alf_> racarr: apt-get install webbrowser-app-autopilot, autopilot run <test>
<lool> a) touch /userdata/.writable_image
<asac> alf_: dont do that
<lool> b) reboot
<racarr> tvoss: Want to double sanity check the papi branch and top approve?
<lool> c) unlock screen
<asac> alf_: use the isntructions above
<lool> then run:
<lool> ./phablet-test-run -p webbrowser-app-autopilot webbrowser_app
<lool> or for unity8:
<tvoss> racarr, feel free
<lool> ./phablet-test-run -n -p unity8-autopilot unity8
<asac> otherwise we will argue until we are blue about not seeing the same things
<alf_> asac: why not?
<lool> alf_: use the phablet-test-run interface
<asac> alf_: doesnt matter... just strictly follow the instructionms
<lool> alf_: so that we all do the same thing
<asac> alf_: people dont get it right and do stuff to their device
<racarr> *parsing* XD thanks all
<asac> and then claim the tests succeed and move on
<ogra_> make sure to reboot after the unity8 tests ... never run an app test after unity
<asac> and i have to argue for 2 days with them until they finally see that they didnt do it the same way
<asac> lool: please refer to these isntructions: https://wiki.ubuntu.com/Touch/Testing#Testing_your_Ubuntu_Touch_Code_before_submission
<kgunn> racarr: what do you need top approved ?
<asac> so we start consolidating it at one place
<racarr> kgunn: https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378 I did it though
<kgunn> lool: can we get a CI run & landing on https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378
<tvoss> kdub, ping
<kdub> hello
<kgunn> Saviq: just to make sure we don't have people running round duplicating effort.... racarr is going to look into crashes associated with webbrowser AP tests
<kgunn> shout if someones already working
<kdub> tvoss, going to try to shift waiting to the compositor side, should make unity wait less
<lool> kgunn: autolanding actually -- ci ran
<tvoss> kdub, sounds good, had the same idea.
<kdub> tvoss,  i'll let you know once i've tested it... just getting my phone all put together
<lool> kgunn: was waiting for the top approve  :-)
<tvoss> kdub, I will grab a quick bite and be back after that
<mlankhorst> argh I don't see why this should give different results..
<kgunn> lool: so we are back to normal everywhere ? (no more manual merges)
<Saviq> kgunn, tvoss, racarr, maliit loops on unity8 exit with https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1238107
<ubot5> Ubuntu bug 1238107 in maliit-framework (Ubuntu) "maliit-server crashed with SIGSEGV in poll()" [Undecided,New]
<lool> kgunn: running
<Saviq> tvoss, I saw the copy_on_client DisplayConfiguration somewhere before
<Saviq> tvoss, today, that is
<lool> kgunn: Only on some projects; Francis sent a list; I dont know for yours, but you sometimes have to wait 15mn for a run, so pinging might still be useful when urgent
<kgunn> ack
<lool> asac: I've updated the AP instructions with my own additions for other testsuites and for Click instructions
<tvoss> Saviq, something went out of scope too early
<tvoss> Saviq, racarr the DisplayConfiguration is NULL
<Saviq> tvoss, I expect unity8 hanging at the same time to be very much related, correct?
<alf_> Saviq: copy_on_client problem, essentially means that the connection to the server failed for some reason (no server, connection rejected), and platform-api wasn't handling this well, see https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378
<Saviq> alf_, yay, so that's fixed
<Saviq> alf_, I knew I saw that somewhere
<racarr> Does mthis looks like
<racarr> ...
<racarr> what alf said
<Saviq> alf_, racarr yes, it does
<racarr> the mutex is null which can only happen if the mirconnection pointer
<Saviq> yay, sorted
<racarr> is invalid
<tvoss> Saviq, not entirely sure, could be
 * Saviq pushes unity8's crash on exit
<asac> lool: yeah. all this know how should be somewhere in phablet-tools i believe
<asac> lool: would be great if phablet-test-run unity8-autopilot would just do the rigth thing
<asac> :)
<alf_> Saviq: note, that's this only explains crashes for new connection attempts. If you see this for an existing connection then it's something else.
<Saviq> alf_, ah, that's on unity8 exit
<Saviq> alf_, so unity8 + maliit were connected, but unity8 was shutting down, pushed maliit over the edge into spinning, unity8 stuck
<racarr> So what is expected to happen with the webbrowser ap tests?
<racarr> I dont see a unity8 crash
<racarr> but eventually the tests themselves crash...  File "/usr/lib/python2.7/socket.py", line 303, in flush
<racarr>     self._sock.sendall(view[write_offset:write_offset+buffer_size])
<racarr> error: [Errno 32] Broken pipe
<tvoss> asac, ^
<racarr> though it seems like they are still running lol because stuff is still going on on my phone
<asac> racarr: what device are you on?
<Saviq> tvoss, that looks like a Qt bug https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238116
<ubot5> Ubuntu bug 1238116 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV in QIcon::~QIcon()" [Undecided,New]
<racarr> asac: mako
<Saviq> tvoss, unity8 crashes shutting down on Mir
<tvoss> Saviq, hang on
<Saviq> tvoss, hanging
<asac> racarr: so not sure. you might be struck by something flaki :)
<asac> lol
<asac> so sometimes MTP is funny and takes over adb and you disconnect
<asac> in those cases, just reboot and try again
<asac> it doesnt happen all of the times :) ... wait until you have MTP seen mounted i guess
<racarr> mm
<racarr> going to try unity8 next...
<racarr> I have to run soon though, one more dental filling :( (they couldn't quit finish last time)
<racarr> ill be back before too long though
<alan_g> alf_: I think your issues with this are addressed? https://code.launchpad.net/~robertcarr/mir/socket-messenger-race/+merge/187647
<lool> tvoss: I tested adding a rm to unity8 upstart job; then unity8 crashed and when I used it again, the keyboard would show up when entering an input field, but its window would disappear each type I type letter
<lool> tvoss: so I think it was still using the old socket
<tvoss> lool, do you have both pre start and post stop?
<tvoss> Saviq, looking at it, need to debug
<tvoss> Saviq, what did you do?
<tvoss> Saviq, gut feeling tells me: qt
<lool> tvoss: no
<lool> tvoss: also didn't check whether maliit indeed restarted
<Saviq> tvoss, that's just unity8 exiting
<lool> tvoss: I'm running out of time for today
<Saviq> tvoss, 100% reproducible
<racarr> got unity8 autopilot running at least. um
<tvoss> lool, sure, no problem ... got your current pushed to a branch?
<racarr> some tests seem to be running
<lool> need to get some sleep tonight, might not be able to test this further today
<Saviq> tvoss, let me see if another one will be the same trace
<tvoss> Saviq, ack
<racarr> its a little confusing XD.
<racarr> will dig deepeer on crashes when I get back
<Saviq> racarr, they're all running, more or less
<Saviq> racarr, but only the first one in a run gets input
<ogra_> lool, tvoss https://code.launchpad.net/~mterry/session-manager-touch/socket/+merge/186391
<ogra_> not sure if that helps anything
<ogra_> (i had it on my MP monitoring list)
<Saviq> racarr, maybe you'd have an idea about that? or could help tracking it down?
<Saviq> racarr, if you run two or more unity8 tests within one autopilot run, only the first one will get input
<lool> ogra_: I commented on the branch
<alf_> alan_g: yes, approved
<lool> tvoss: did you send the -pthread thing to trunk?
<tvoss> lool, nope
<lool> tvoss: we have a slot for it FYI
<tvoss> lool, ah okay ...
<tvoss> there was some discussion on the mp
<lool> looking
<lool> tvoss: I miss the devel mp?
<lool> tvoss: only have the trunk one
<lool> tvoss: In any case -lpthread is wrong and should be fixed to -pthread
<lool> even if it didn't fix whatever we were seeing
<lool> tvoss: this is how I had changed unity8.conf upstart job: http://paste.ubuntu.com/6218716/
<tvoss> lool, hang on
<tvoss> lool, https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags/+merge/190316
<lool> thanks
<tvoss> alan_g, removed the linked bugs
<lool> will add to tracking
<lool> tvoss: oh that's against trunk again
<lool> isn't it?
<lool> tvoss: that's the one I had
<tvoss> lool, yup, that's against trunk, want me to resubmit against devel?
<lool> tvoss: Just send it against devel branch?
<lool> tvoss: I think that's mir process
<lool> tvoss: first land in devel, then merge devel in trunk
<lool> tvoss: but others here are more knowledgeable on this
<alan_g> tvoss: yes
<alan_g> lool: "
<alan_g> lool: @"In any case -lpthread is wrong and should be fixed to -pthread" - comment against the MP. chat gets lost
<tvoss> alan_g, lool resubmitted
<alan_g> tvoss: spurious changes: debian/changelog
<om26er> kdub, btw if you need any help testing something. I am at service
<kdub> thanks om26er
<mlankhorst> alf_: but the diff I posted is the smallest way to reproduce the problem, if you apply it it happens with normal mir clients too and not just nested :P
<mlankhorst> and I have no explanation as to why
<pete-woods> but I'll keep looking
<jono> really nice job on Mir on the N4 :-)
<jono> working pretty good for me :-)
<ogra_> jono, just because your last name isnt -autopilot
<ogra_> ther test results are still pretty bad (but we're getting there)
<tvoss> lool, alan_g|EOD https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags-2/+merge/190432
<lool> tvoss: approved but not top approved; leaving that to mir folks
<tvoss> lool, ack, sorry, took me a while, my bzr foo was lacking
<lool> tvoss: np, added to landing plan too, but will need this to go to trunk too
<lool> alf_: You might have expected me to test your branch; I just made sure it went to PPA and someone else will try it in landing plan; might be good to provide some instructions on testing it
<lool> alf_: sorry, not staying long tonight, otherwise would have tried it out
 * lool  off  &
<tvoss> lool.sleep()
<tvoss> lool.force_to_sleep();
<tvoss> lool, awesome job, dude
<jono> ogra_, yeah, seems like a good integration result
<jono> and now everyone can focus on bugfixing
<ogra_> well, first on getting the tests to work again
<ogra_> then on bugfixing
<jono> :-)
<racarr> Back
<ogra_> Front
<racarr> :p
<davmor2> kgunn: or any one else.  The logs in /home/phablet/.cache/upstart  are they only for the current session?  i.e. if I say pull the battery out to get back to a working system does it start the log afresh?
<kgunn> davmor2: good question...i think it can be a mix....for unity i suspect new everytime...for things that maybe dont get autolaunched on boot, i suspect they're old
<kgunn> davmor2: i say this because i see diff timestamps when i look
<kgunn> just noticed  earlier myself :)
<davmor2> kgunn:  that'll possibly be why I can't see anything obvious for this lock up issue that maguro has then
<davmor2> kgunn: in order to get back to a working system to pull the logs I need to pull the battery
<kgunn> davmor2: weird...so when it locks up, you can't even adb shell in ?
<davmor2> kgunn: Nope and macslow confirmed too
<davmor2> kgunn: the only thing you can do is pull the battery, even pressing and holding the power button does nothing
<davmor2> kgunn: thankfully it doesn't seem to be hitting mako's
<davmor2> kgunn: I also tried getting around it by running top in adb shell so the connection was live when it died,  but that just kicks you out of the adb session when it locks up and you can't get back in
<davmor2> kgunn: I've been trying to get some reproducible steps, but there don't seem to be any.  You can have lots of apps open, 1 app open, be swiping between scopes, or pulling down the indicator bar
<kgunn> davmor2: mmmm....that actually sounds kernel-ish
<davmor2> kgunn: only happen on mir, on SF I could run it all day no hangs
<tvoss> kdub, which buffers and how many do we hand out to internal clients?
<kdub> tvoss, internal and external have the same type of buffers and same count
<kdub> so, gpu buffers (not fb's or flagged for hwc usage) and 3
<tvoss> kdub, hmmm, why would the shell ever block then?
<kdub> tvoss, my branch linked to that slowness bug helps the speed
<kdub> i messed up something having to do with snapshotting in that branch though, have to figure out what
<tvoss> kdub, mind pinging me the link?
<kdub> https://code.launchpad.net/~kdub/mir/android-buffer-syncfence
<tvoss> kdub, awesome
<kgunn> i swear i think dash decelerates ....
<kgunn> render times are pretty quick...then get large when you take your finger off
<tvoss> kdub, I like what I see
<tvoss> kdub, is the performance improvement tangible?
<kgunn> woohoo go kdub
<kdub> tvoss, haven't measured
<kdub> trying to track down why when you click 'recent apps' you get a white snapshot frame in there in that branch atm
<tvoss> kdub, ack
<thomi> morning
<tvoss> kdub, go ahead
<racarr> morning thomi
<thomi> o/
<tvoss> o/
<thomi> hey tvoss, up late?
<tvoss> thomi, yup, as usual during this week
<thomi> :(
<tvoss> thomi, all good :) it's actually quite a lot of fun
<thomi> I suppose. I've not been feeling well for the last couple of weeks - mostly I'm always tired. Can hardly keep my eyes open, even after my numerous coffees
<tvoss> thomi, oh, sounds like you should go and see a doctor
<tvoss> thomi, do you have enough water with your coffee?
<thomi> tvoss: I would, but it's not that bad - I'm just tired, no other symptoms
<thomi> tvoss: actually, that reminds
<thomi> me
 * thomi goes to find his water bottle
<kgunn> kdub: that's freakin' awesome....
<kgunn> just tried your sample "make it go fast"
<kdub> thanks :)
<kgunn> kdub: you do realize when you do things like this people will just keep expecting miracles
<tvoss> kdub, awesome !!!
<kgunn> davmor2: you still on ?
<davmor2> kgunn: I am
<kdub> :D
<kgunn> davmor2: wanna try something on maguro ?
<davmor2> kgunn: just doing a flash at the minute but I'm happy to try after
 * kdub doesnt know if that will fix maguro
<tvoss> kdub, no worries, we will try ;)
<davmor2> kdub: I'm as happy to break your code as anyone elses I wouldn't want you to fell left out :)
<kgunn> kdub: mmm....it should be  indep of hwc1.0 vs 1.1 right ?
<tvoss> kgunn, screw it, let's just try
<tvoss> :)
<kdub> well, i think the omap drivers are using the deprecated native window hooks, which don't do anything with fencing
<kgunn> yeah...omap efforts pre-dated the butter activity
<kgunn> kdub: so just to confirm...i was taking data just before copying over your fix
<kgunn> kdub: and the qml render numbers are back down to where they were weeks ago
<tvoss> \o/
 * tvoss goes to get alcohol
<kgunn> kdub: like...roughly ~27ms todays image....copy your *.so's....i'm getting ~8ms
<ricmm> yea
<ricmm> renders are back to near-SF numbers
<ricmm> swap time went down in half too
<ricmm> all we need is screenshots now
<kgunn> kdub: a few spikes of 19/20 ms....but not completely abnormal....plus I am certain...unity/qt does something funky to decelerate
<kgunn> when you lift a finger or come to a stop
<kgunn> kdub: not only that....i'm convinced the quality is actually better than SF...since they had some serious flickering you could easily witness
<kgunn> kdub: btw, i do not see the white full screen render...did you already fix that pre-herion sample
<ricmm> the white frames are when tapping on a running app
<ricmm> the screenshot should slide in from the right
<ricmm> however it is an empty frame thats doing it
<kgunn> ricmm: btw...i didn't try your powerd deb yet...i was having trouble getting the latest image to exhibit the "can't unblank" upon a unity8 stop/start
<kgunn> i wanted to ensure i could easily repro the problem....
<kgunn> i did just get one...but had been doing this many times
<kgunn> ricmm: do you still want me to try that deb ?
<ricmm> what deb?
<ricmm> the powerd one?
<ricmm> they are already testing it for tests
<ricmm> kdub: so I see a difference now with screenshots
<kgunn> ricmm: yeah...ok....
<ricmm> kdub: less screenshotting issues, before most of the times the surface wouldnt be ready for screenshotting
<ricmm> so it would use an old screenshot instead of refreshing
<ricmm> kdub: now with this patch the surface is allowing the screenshot
<ricmm> which is actually making it lag behind a bit while its mapped to sheet coming in from the right
<ricmm> kdub: tvoss kgunn worse comes to worse I prefer this over the choppiness
<ricmm> I can live with a couple frames of white
<tvoss> ricmm, +1
<tvoss> ricmm, kdub http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/92:20131010.2:20131010/4662/
<ricmm> not bad
<racarr> I am going to work on this...extra characters showing up from real keyboards/autopilot keyboard http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/92:20131010.2:20131010/4662/calendar-app-autopilot/474291/
<kdub> yeah, getting better
<racarr> should be pretty easy to isolate
<racarr> and probably just a problem in qtubuntu or our xkbcommon mapper
<ricmm> I've seen it happen in normal apps with OSK
<ricmm> as soon as you bring up or focus a text field
<ricmm> garbage char will be delivered
<ricmm> once I had the filter branch for the hardware keys that didnt happen
<racarr> ah I havent seen ti happen with osk I dont believe
<racarr> ok. quick lunmch before an afternoon of digging autopilot failures
<davmor2> kgunn: it's feels faster initially, however it is also glitchier here. So for example I opened to the camera app and there was lots of flashing that wasn't there before, if you tap on the flash for example.   I'll have a proper go at it after I log off in a bit and I'll double check that I have put files in the right places too
<davmor2> I'll let you know tomorrow ;)
<davmor2> night all
<kgunn> davmor2: cool...
<kgunn> davmor2: yeah...mainly curious about the dash app lens full of icons scrolling
<racarr> Back
<rsalveti> hey, need help with mir specific crash
<rsalveti> getting the following after linking to ubuntu_application_api_mirclient
<rsalveti> gst-codec-info loads libandroidmedia, which depends on libubuntu_application_api_mirclient, probe for video caps, and then crashes when trying to unload the library
<rsalveti> not using any platform-api or mir specific call at this point
<rsalveti> http://paste.ubuntu.com/6219717/
<rsalveti> the crash
<rsalveti> ricmm: racarr: ^
<racarr> rsalveti: I am thinking
<racarr> rsalveti: So, static deinitialization segfault is almost certainlly
<racarr> some sort of linking error
<racarr> so the first thought is
<racarr> https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags-2/+merge/190432
<racarr> but I don't know exactly how
<racarr> that would produce this
<rsalveti> racarr: would that branch help?
<rsalveti> tvoss: ^
<rsalveti> not sure how would be related
<rsalveti> wonder why this wasn't causing any issue before we tried this
<tvoss> rsalveti, nope, looks like something different
<rsalveti> same code was working fine when linking against ubuntu_application_api
<rsalveti> as all it's doing at this point is loading & unloading it
<tvoss> rsalveti, my brain is fried tbh :/
<rsalveti> seems a common issue around here this week lol
<racarr> rsalveti: I dunno...I would ldd things and look for any conflicts but I am not sure...what could show up
<rsalveti> racarr: ldd seems sane http://paste.ubuntu.com/6219825/
<racarr> rsalveti: Mm
<racarr> maybe valgrind or something
<racarr> can give hints
<racarr> at earlier corruption
<racarr> rsalveti: There may be interesting stuff with LD_DEBUG=all (don't know LD_DEBUG well enough to suggest better flags)
<racarr> It seems liek its probably either some sort of linking problem or
<racarr> some sort of memory corruption
<rsalveti> let me check
<rsalveti> racarr: not much with valgrind: http://paste.ubuntu.com/6219845/
<rsalveti> checking linker
<ChickenCutlass> rsalveti: is there any static init going on that might be failing
<rsalveti> ChickenCutlass: we're not doing that in this lib directly
<rsalveti> at this point we're just linking at it
<ChickenCutlass> rsalveti: so linked at compile time with -l
<rsalveti> the code that uses platform-api: https://github.com/jhodapp/gst-plugins-bad/blob/master/sys/androidmedia/gstamchybris.c
<ricmm> rsalveti: wheres the code that does it
<ricmm> ok
<rsalveti> and how we're linking to it: https://github.com/jhodapp/gst-plugins-bad/blob/master/sys/androidmedia/Makefile.am
<ricmm> and this isnt being used?
<ricmm> why do you say its only loading and unloading
<rsalveti> ricmm: nops, because gst-codec-info loads the lib, calls a function to get caps and close itself
<rsalveti> ricmm: at this point nothing is calling platform-api
<rsalveti> ricmm: I know because even when using mir, and calling with the older library, it works just fine
<ricmm> do you have a bt ?
<rsalveti> http://paste.ubuntu.com/6219870/ the build log
<rsalveti> ricmm: bt?
<rsalveti> ricmm: http://paste.ubuntu.com/6219717/
<ricmm> what the hell
<racarr> rsalveti: Can you try the log from running it
<racarr> with LD_DEBUG
<rsalveti> racarr: uploading, but nothing really useful it seems
<rsalveti> 37mb of logs
<ChickenCutlass> rsalveti: could this be a missing hybrid hook?
<ChickenCutlass> rsalveti: sure looks like it
<ChickenCutlass> hybris
<ChickenCutlass> but why?
<ChickenCutlass> on just loading the lib
<racarr> rsalveti: ><
<rsalveti> ChickenCutlass: it's not
<rsalveti> ChickenCutlass: all gst is doing is calling plugin_init
<rsalveti> even if I put a simple return FALSE right after that, it crashes
<rsalveti> ChickenCutlass: and works fine with the old platform-api lib
<rsalveti> this is a crash at the class destructor it seems
<ricmm> yea but at which class
<ricmm> if you arent creating anything fro mplatform-api in there
<rsalveti> I'm not
<ricmm> I dont get why there would be a mention to mir in those logs
<ChickenCutlass> ricmm: are there any static init's in there
<rsalveti> ricmm: commented out all the platform-api related function calls and it worked now
<rsalveti> will get them back one by one
<ricmm> thought you said it wasnt being used!
<rsalveti> ricmm: it's not
<ricmm> then why would commenting them out screw it?
<ricmm> err fix it
<rsalveti> ricmm: this is what I added back: http://paste.ubuntu.com/6219951/
<rsalveti> ricmm: and it's not called!
<rsalveti> and it's already enough for the crash
<ricmm> ok
<ChickenCutlass> rsalveti: so should you not use sizeof (session)
<ChickenCutlass> rsalveti: not *session
<rsalveti> ChickenCutlass: ricmm: http://paste.ubuntu.com/6219958/
<rsalveti> this is already enough for the crash
<rsalveti> phablet@ubuntu-phablet:/tmp/test$ gcc test.c -o test -lubuntu_application_api_mirclient
<rsalveti> phablet@ubuntu-phablet:/tmp/test$ ./test
<rsalveti> Testing
<rsalveti> Segmentation fault (core dumped)
<ChickenCutlass> rsalveti: ah ok -- so ricmm bug
<ricmm> give me some minutes
<rsalveti> racarr: ^
<sarnold> does argv ever get passed to execve(2)? argv[argc] is expected to be a NULL pointer, and there's no trailing ascii NUL after \n in the first array element
<rsalveti> works fine on the desktop
<ricmm> that test.c is not crashing for me
<ricmm> phablet@ubuntu-phablet:~$ ldd ./test libubuntu_application_api_mirclient.so.1 => /usr/lib/arm-linux-gnueabihf/libubuntu_application_api_mirclient.so.1 (0x401da000)
<ricmm> phablet@ubuntu-phablet:~$ ./test
<ricmm> Testing
<ricmm> phablet@ubuntu-phablet:~$
<rsalveti> ricmm: latest image and everything?
<ricmm> always
<rsalveti> this also crashed with jhodapp|bbiab
<ricmm> are you sure your mirclient platform-api and your mir are not somehow out of sync?
<rsalveti> ricmm: unless I got a partial update with apt, no
<ricmm> im resetting all my versions to saucy for mir and platform-api
<ricmm> to make sure we have the same
<ricmm> as I'm pretty sure I had trunk mir
<rsalveti> ricmm: you did build your own mir, right?
<ricmm> yea
<ricmm> for the other bug
<ricmm> sec still installing
<rsalveti> yeah, have latest of everything
<rsalveti> just did apt-get update & upgrade
<rsalveti> just reproduced with maguro
<rsalveti> let me reflash it with latest
<rsalveti> might be fixed in trunk then
<ricmm> uh yea it breaks
<rsalveti> \o/
<ricmm> lemme push trunk again
<rsalveti> ricmm: trunk of mir or platform-api?
<ricmm> mir, I havent rebuilt platform-api
<jhodapp> so there's some issue with a version of the mir platform-api then?
<rsalveti> jhodapp: mir
<jhodapp> ah
<rsalveti> jhodapp: http://paste.ubuntu.com/6219958/ is already enough to get the crash
<jhodapp> wow
<rsalveti> yeah, bad stuff
<jhodapp> that's basic
<ricmm> yea with my local build it seems to be fine
<ricmm> trunk mir
<rsalveti> let me build mir from trunk
<ricmm> but I dont see anything in trunk that would cause this...
<RAOF> mlankhorst: I was poking at nested-gbm yesterday, but mostly finding out that I'd misbuilt mesa in some way and so the egl platform was crashing after _glapi_get_proc_address returned garbage for glFlush
<mlankhorst> RAOF: oh did you see my pastebin from earlier?
<mlankhorst> I can reproduce the garbage with a normal client if I force a gbm device to be created and use the screen from that
<RAOF> mlankhorst: Hm, no.
<ricmm> racarr: trunk has nothing special in it, however having built it from my machine with the cross-compile script and deployed to phone makes it not fail
<ricmm> racarr: what the hell?
<mlankhorst> so just the fact that gbm is used is messing things up
<mlankhorst> and i have no idea how
<racarr> ricmm: Thiiiinking
<mlankhorst> to the best of my knowledge the paths appear to be identical, at least after the gbm proxying :s
<RAOF> mlankhorst: Could you repost your pastebin?
<mlankhorst> http://paste.debian.net/55230/
<rsalveti> ricmm: does it fail if built natively?
<rsalveti> well, it's a different toolchain
<rsalveti> I'm building mir trunk locally to see
<mlankhorst> RAOF: with that patch normal mir clients fail too, that should at least make it easier to debug :P
<racarr> Does this just mean we broke client ABI somehow?
<racarr> err no that doesn't quite make sense...
<racarr> building trunk without rebuilding everything else reportedly fixes it
<rsalveti> could be a toolchain/linker issue
<racarr> maybe
<rsalveti> well, ricmm cross-built it
<racarr> something happened in say...
<racarr> that introduces ABI breaks
<racarr> err...in say hybris
<racarr> or something else
<racarr> and just mirclient
<rsalveti> not a hybris issue
<racarr> needed to be rebuilt against it
<racarr> but wasn't
<racarr> *shrug* it could be, if memory is getting stomped on in static initialization
<rsalveti> rebuilding trunk locally ti see
<Saviq> hey guys, here's another nice one... https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1238296
<ubot5> Ubuntu bug 1238296 in maliit-framework (Ubuntu) "maliit-server crashed with SIGABRT in raise()" [Undecided,New]
<ricmm> Saviq: thanks
<Saviq> ricmm, /me got retracing powers now ;D
<rsalveti> maybe similar issue?
<rsalveti> no, looks different
<ricmm> different trace
<ricmm> racarr: rebuilt platform-api against my local build and it still works
<ricmm> is it possible that something went wrong in the recent archive build?
<rsalveti> ricmm: well, if rebuilding the current version fixes it, then it could
<rsalveti> still waiting trunk here
<racarr> I think if it does work, (rsalvetis build)
<racarr> then probably Mir and <SOME PACKAGE> were buitl against different versions of <SOME PACKAGE>
<racarr> err
<racarr> <SOME OTHER PACKAGE> lol
<ricmm> rsalveti: get that system76 already
<ricmm> geez
<rsalveti> ricmm: dude, building locally
<rsalveti> == mako
<ricmm> wow
<ricmm> see you tomorrow then
<racarr> rsalveti: Build from
<racarr>  build/src/
<racarr> and make install from there
<racarr> skip tests
<racarr> save lifetimes
<rsalveti> ricmm: I need to confirm if this is not a toolchain issue
<rsalveti> just build, will test now
<rsalveti> ricmm: racarr: crashed still
<rsalveti> just built and installed trunk
<ricmm> well that sucks
<ricmm> can you uh
<ricmm> one sec
<ricmm> merge lp:~kdub/mir/android-buffer-syncfence
<ricmm> I know it makes no sense, but just try
<ricmm> thats the only other change in my branch
<rsalveti> sure
<racarr> hmmm
<rsalveti> shit, huge merge
<ricmm> its pretty large yea but it shouldnt touch anything related to this
<rsalveti> ricmm: replacing libmirclient.so is enough, right?
<ricmm> should be as its talking about the connection
<ricmm> but you never know with this beast
<ricmm> replace it all
<ricmm> as im doing so as well
<rsalveti> yes sr
<ricmm> im building a clean trunk, cross built
<ricmm> I'll put the binaries up somewhere for you
<ricmm> you put your locally built ones somewhere
<rsalveti> ricmm: booom, no
<ricmm> still failing?
<ricmm> try http://people.canonical.com/~ricmm/mir-fixed/
<rsalveti> ricmm: where is the mir socket now?
<rsalveti> trying to see if unity8 is still working
<ricmm> I'm not sure, alan_g moved it
<rsalveti>  /run/user/32011/mir_socket
<ricmm> right xdg runtime
<rsalveti> ricmm: this shit is fast now
<ricmm> super pro
<rsalveti> ricmm: so yeah, using the right ones
<rsalveti> let me try with yours
<rsalveti> people.c is super slow for me today
<rsalveti> I believe this issue might be happening with unit8 as well
<rsalveti> it's crashing during shutdown
<ricmm> sounds terribad
<rsalveti> ricmm: no crash with yours
<rsalveti> smells like toolchain
<ricmm> well thats odd
<rsalveti> let me open a bug
<rsalveti> ricmm: bug 1238312
<ubot5> bug 1238312 in Mir "Segfault when closing apps that link against ubuntu_application_api_mirclient" [Critical,Confirmed] https://launchpad.net/bugs/1238312
<rsalveti> ricmm: please add that it works with your lib, when cross-built
<racarr> kdub: sync fence is fast :D
<ricmm> done
<racarr> tested it out
<rsalveti> ricmm: how can I cross build mir?
<ricmm> rsalveti: thres a script right in trunk
<rsalveti> ricmm: want to cross build the same version used by the image
<ricmm> ./cross-build-...
<ricmm> something like that
<rsalveti> great
<kdub> racarr, yay
<ricmm>  * Authored by: Thomas Guest <thomas.guest@canonical.com>
<ricmm> tvoss: is that you? lol
<racarr> no
<rsalveti> ricmm: creating phablet-compatible armhf partial chroot for mir compiles in directory /tmp/mir/mir-0.0.14+13.10.20131010/partial-armhf-chroot
<rsalveti> E: No packages found
<rsalveti> might be missing something still
<ricmm> oh yea
<ricmm> racarr: do you have the cross compile instructions list at hand?
<ricmm> nvm
<ricmm> rsalveti: http://unity.ubuntu.com/mir/building_source_for_android.html
<ricmm> you need to add armhf sources to your apt
<ricmm> its bad
<rsalveti> haha, this is not for android
<rsalveti> that's fine
<ricmm> yea I dont know why its called that
<rsalveti> this if for ubuntu dudes
<racarr> at one point
<racarr> it literally
<racarr> was for android
<racarr> in mirs case :p
<rsalveti> right
<rsalveti> not anymore :P
<slangasek> rsalveti: :P
<slangasek> rsalveti: can you reproduce this by linking directly to libmirclient?
<rsalveti> one more :-)
<rsalveti> trying, was just cross-building the same version to confirm
<ricmm> rsalveti: soooo
<ricmm> racarr:
<ricmm> http://paste.ubuntu.com/6220225/
<ricmm> thats how it looks when it dies
<ricmm> http://paste.ubuntu.com/6220219/
<ricmm> thats how it looks when it works
<ricmm> the later hits the destructor of the hash table
<ricmm> makes me believe that when it fails the hash table has bogus data and it attempts to clear the set
<ricmm> which fails, probably guesses a wrong size
<rsalveti> ricmm: slangasek: works fine when linking against libmirclient directly
<rsalveti> but I know the platform-api one links to a bunch of mir related libs
<ricmm> are you actually pointing to a function somewhere?
<ricmm> if so, what mirclient func
<rsalveti> ricmm: was trying mir_connection_is_valid, but checking if it's really part of that lib
<rsalveti> src/client/mir_client_library.cpp:int mir_connection_is_valid(MirConnection * connection)
<rsalveti> yup
<rsalveti> ricmm: why is it trying to clear the hash table?
<rsalveti> at that point, is it valid at all?
<ricmm> it shouldnt be
<ricmm> the compiler is generating different paths tho
<ricmm> one is perhaps initializing it to null while the other is leaving it uninitialized, or something
<ricmm> just guesses here
<rsalveti> right
<rsalveti> ricmm: slangasek: working with the cross-built based libs, same src version
<ricmm> yea
<ricmm> can you check cxflags?
<ricmm> cxx
<ricmm> perhaps there are some things different to the default way of building debs
<rsalveti> probably
<ricmm> optimization or other specific flags
<rsalveti> ricmm: not sure because the cmake files are shared
<rsalveti> ricmm: wonder why it seems to be fine If I link against it directly
<rsalveti> maybe a different lib
<rsalveti> linking against mir brings the entire universe
#ubuntu-mir 2013-10-11
<RAOF> mlankhorst: Hey, what's the expectation of buffer lifecycle vis-a-vis dma-buf? It's entirely up to us, isn't it?
<racarr> rsalveti: ricmm: I have roughly zero ideas :(
<racarr> afk for a little bit soon
<racarr> why can qtubuntu
<racarr> link succesfully against papi mirclient?
<racarr> if the gstreamer codec cant
<slangasek> rsalveti: possibly also worth noting that the cross-compiler in saucy hasn't been updated since July...
<ricmm> well but even natively exhibited the issue
<ricmm> sorry, building natively by hand didnt show the issue
<ricmm> building with dpkg did, and I do see a couple differences
<ricmm> racarr: still there? when building the deb pkg it uses -DBoost_COMPILER=-gcc
<duflu> robert_ancell: I assume you didn't want a chat yesterday?
<robert_ancell> duflu, nope, I'm good if you've got nothing
<duflu> The usual...
<duflu> Which is nothing not already mentioned on Wed
<slangasek> ricmm: so by hand vs. packaging could be gcc-4.7 vs. gcc-4.8; and native vs. cross, the cross-compiler for gcc-4.7 actually hasn't been updated since April, even.  I'm going to try updating it now.
<slangasek> for the 4.8 cross-compiler, I was mistaken, it is up-to-date wrt the native compiler
<racarr> ricmm: Still around
<ricmm> yea
<racarr> hmm I remember that flag used to be necessary to build on android
<ricmm> asking me? or answering
<racarr> but don't know the etymology
<racarr> more answering
<racarr> than asking :p
<ricmm> right
<ricmm> racarr: alright so I see the issue, not sure how to fix it
<ricmm> src/client/mir_client_library.cpp has a global std::unordered_set<MirConnection*> MirConnection::valid_connections;
<ricmm> but thats a static member var of MirConnection
<ricmm> when building Debug (unoptimized), the internal unordered_set's Hashtable has a correct address (_M_buckets)
<ricmm> when release, the address is set to the next field's value (bucket_count), both to 0x17/23
<ricmm> obv when it goes to clear it in the destructor and it memsets at 0x17 it goes boom
<ricmm> it feels like a compiler bug
<racarr> ricmm: Maybe break during initialization and set
<racarr> a watch on the pointer
<racarr> to see if it gets overwritten due to memory corruption
<racarr> or if it really is a compiler bug
<racarr> well you don't even need a watch right? I guess just
<racarr> is it set incorrectly at initialization
<ricmm> yea trying to get there
<ricmm> its just templates and templates
<ricmm> sec
<slangasek> so you think the miscompile is in libmirclient, not in platform-api?
<ricmm> wtf !
<ricmm> racarr: ping
<ricmm> http://paste.ubuntu.com/6220619/
<ricmm> _M_buckets is changing
<ricmm> and whatever is doing it is happening in mirclient p-api
<ricmm> sigh
 * ricmm rebuilds papi with symbols
<d-snp> hey, do you guys know if steam os is going to run mir?
<racarr> ricmm: What is your test case? I mean
<racarr> opening a connection
<racarr> oh well I guess it shouldnt change the address
<ricmm> theres no test case
<ricmm> loading the library is enough, as it creates the static set of MirConnection*
<racarr> oh its literally just an empty program?
<ricmm> yea
<ricmm> racarr: https://launchpad.net/bugs/1238312
<ubot5> Ubuntu bug 1238312 in mir (Ubuntu) "Segfault when closing apps that link against ubuntu_application_api_mirclient" [Critical,Confirmed]
<ricmm> the empty example is there
<racarr> ok well hopefully papi debug symbols should be enlightening
<ricmm> poor gdb
<ricmm> not easy to watch for expressions ina c++ heavy stack
<ricmm> nvm its stuck
<ricmm> sigh
<ricmm> oh no its not, just taking 100x times to run
<ricmm> racarr: http://paste.ubuntu.com/6220667/
<ricmm> looks like when error_connections is created, valid_connections goes to hell
<racarr> ricmm: Hrm :/
<racarr> it smells like compiler bug, but compiler bug smells like...probably not :p
<racarr> ricmm: So wait why does qtubuntu work
<racarr> I just built everything on device today, and clients seem fine, ran a bunch of autopilot tests, etc
<ricmm> it works when we use the library
<ricmm> at which point valid_connections will grow
<ricmm> and it will most likely fix itself
<racarr> lol
<racarr> mm
<racarr> ricmm: so it only happens when you link to ubuntu-application-api-mirclient
<racarr> which also pulls in hybris
<racarr> I wonder if its some sort of hybris wizardry gone wrong
<racarr> seems as likely as a compiler bug
<ricmm> seriously doubti ts hybris
<ricmm> we are nowhere near nadroid at that point
<racarr> but hybris has some
<racarr> pthread
<racarr> wizardy right
<racarr> and the valid connections set is
<racarr> potentially right next to a mutex
<ricmm> hmm which one?
<racarr> std::mutex MirConnection::connection_guard
<ricmm> oh that one of course
<ricmm> lol
<ricmm> thats not a bad guess
<ricmm> I could get a dbg hybris and check if we are hitting something weird
<racarr> Seems worth figuring out
<racarr> Dinner just showed up and I will be finished soon and start working more focused on this too...
<racarr> now I am puzzled XD
<racarr> ricmm: Err so
<ricmm> I'm gonna move that thing to be initialized *after* error_connections
<ricmm> and see what happens
<ricmm> heh
<racarr> on my phone, which...I flashed this afternoon, latest image I believe, then proceeded to build mir, platform-api (mirclient+mirserver), qtubuntu and unity-mir on
<racarr> the test program doesnt segfault?
<ricmm> how did you build mir
<ricmm> Debug or Release?
<racarr> Ah
<ricmm> it has to be optimized
<ricmm> otherwise it works
<racarr> ok rebuilding
<ricmm> sigh...
<ricmm> racarr: swapping order of init with the mutex fixes it
<ricmm> perhaps you are right with hybris and the mutex
<robert_ancell> duflu, what does "this is the one" mean?
<duflu> robert_ancell: As in the rules don't allow us to roll any more...?
<robert_ancell> the one for?
<robert_ancell> i.e. the final version for saucy?
<duflu> robert_ancell: Yes. Unless we have exceptions?
<ricmm> racarr: I dont like it at all :)
<ricmm> racarr: im gonna eat and stuff its kinda late here maybe ill sleep
<ricmm> I'll work early tomorrow to look at hybris and whats going on there
<ricmm> for the time being....
<ricmm> racarr: https://code.launchpad.net/~ricmm/mir/lp-1238312/+merge/190524
<duflu> robert_ancell: I suspect we had an exception since everything against phone-v1-freeze hasn't hit lp:mir or the archive yet
<robert_ancell> duflu, in a perfect world, but we might have things due to 1) or 2) in https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-October/001064.html
<robert_ancell> duflu, I believe the plan is for the phone to switch straight to t-series, so new work will go in there
<duflu> robert_ancell: Yeah of course. I'm just curious where saucy maintenance branches from. Looks like lp:mir r1096
<robert_ancell> duflu, that seems likely
<robert_ancell> duflu, your email lacks a little context there :)
<duflu> robert_ancell: The point is Mir got released, or soon will be. One of them
<robert_ancell> brb
<racarr> ricmm: Ok so the risk is
<racarr> if its not a compiler bug and something really is overwriting the mutex
<racarr> then moving it
<racarr> just defers
<racarr> issues
<ricmm> I know
<ricmm> dont happrove that just leave it there sitting for now
<ricmm> and im the morning ill look into hybris and pthread mutexes
<racarr> mm
<racarr> ill give it some look over night
<ricmm> alright
<racarr> Thanks for digging :D
<rsalveti> racarr: this is not something with hybris
<rsalveti> otherwise it'd not even work with the O0 version
<rsalveti> hybris just maps function calls, don't change the program stack :-)
<robert_ancell> RAOF, there's no way to tell XMir to look for "no Mir socket" right? I think that's the last piece to fix bug 1211141
<ubot5> bug 1211141 in Unity System Compositor "Unity system compositor allows connections from any Mir client" [Critical,In progress] https://launchpad.net/bugs/1211141
<RAOF> robert_ancell: How do we tell normal clients to do so? XMir does have a -mirSocket <str> option.
<robert_ancell> RAOF, yeah, but I don't set that anymore and it defaults to /tmp/mir_socket
<robert_ancell> the only way it doesn't use /tmp/mir_socket is if I give it something
<robert_ancell> but in this case there is no socket
<robert_ancell> I think we can just drop the default and set it to NULL now
<RAOF> We didn't use URI specifiers for the bare-fd case?
<robert_ancell> RAOF, I guess that might work, but I'd kind of like to just use the environment variable
<robert_ancell> I'll try that
<RAOF> Yeah, looks like you could send -mirSocket fd://4
<RAOF> (For example)
<RAOF> robert_ancell: Looks like the XMir in the archive will pass NULL through to mir_connect if you don't explicitly pass mirSocket; that presumably does what you want.
<robert_ancell> RAOF, I read that it won't due to:
<RAOF> robert_ancell: Or, rather, if libmirclient treats NULL as âlook in an environment variableâ, then that'll do what you want ;)
<robert_ancell> yes mirclient does the right thing, but I think it's impossible for XMir to send NULL
<robert_ancell> due to:
<robert_ancell>    if (mirSocket != NULL)
<robert_ancell>         socket = mirSocket;
<RAOF> That's not in the current code.
<robert_ancell> ah
<robert_ancell> RAOF, what is the correct branch?
<robert_ancell> brb
<rsalveti> bottom approved https://code.launchpad.net/~ricmm/mir/lp-1238312/+merge/190524 as well
<robert_ancell> RAOF, hmm, that didn't work either.
<robert_ancell> [  1247.459] (EE) Failed to connect to Mir: connect not called
<robert_ancell> have to solve that one another time, bye all
<duflu> robert_ancell: Please leave the door open for running native Mir clients in USC. It's frequently a critical way to triage bugs...
<robert_ancell> duflu, it's just a flag that's passed to u-s-c (--no-file)
<duflu> robert_ancell: Yeah OK. Optional is good
<robert_ancell> I would make it the default but mir is a pita in allowing changes like that
<RAOF> Harumph.
<mlankhorst> RAOF: no idea
<RAOF> mlankhorst: Ok. I think I was mistaken, and they're per-drm-fd, which makes the point moot.
<tvoss> duflu, resubmitted
<duflu> tvoss: Already reapproved
<tvoss> duflu, thx
<mlankhorst> RAOF: ;D
<RAOF> mlankhorst: It's a little odd that gem handles are the only thing that *aren't* refcounted, but that's ok :)
<tvoss> alf_, ping
<alf_> tvoss: pong
<mlankhorst> RAOF: the fd isn't either
<tvoss_> alan_g, alf_ I would appreciate if the both of you can make yourself familiar with https://code.launchpad.net/~kdub/mir/android-buffer-syncfence
<tvoss_> alan_g, alf_ it tackles the performance issues on mako and maguro. It's on hold, but I would like to see it in Monday the latest
<alan_g> tvoss_: Rats. Just when I cleared interruptions and got back to "very important"
<tvoss_> alan_g, sorry :) that's life :)
 * alan_g wonder when he'll be allowed to fix the shutdown/restart cycle
<alf_> tvoss_: Does this branch actually fix the issue, or does it prepare the ground for the real fix? According to the description it does the latter, but perhaps I have misunderstood.
<tvoss_> alf_, it actually fixes the issue
<tvoss_> alf_, alan_g also https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238287
<ubot5> Ubuntu bug 1238287 in unity8 (Ubuntu) "unity8 crashed with SIGABRT in raise()" [High,Confirmed]
<tvoss_> alf_, alan_g Saviq is working to get us a better stacktrace
<alf_> tvoss_: alan_g: ok, I will pick that up when I am done with the first pass of kdub's MP
<tvoss_> alf_, thx
<hikiko> mlankhorst, hi
<hikiko> could you get a look at this: https://code.launchpad.net/~hikiko/mir/mir.fix-in-session-leader/+merge/190353 if you have a moment?
<mlankhorst> RAOF: oh btw I patched mir a little too while I was debugging
<mlankhorst> http://paste.debian.net/55897/
<mlankhorst> in nested mode mir shouldn't claim a vt
<mlankhorst> hikiko: actually there was a thing about that..
<hikiko> :) what thing?
<mlankhorst> oh fine just keep it like that if it fixes it :P
<mlankhorst> yeah should be ok
<hikiko> it fixes it, my only obsession was that there might be a case where a session leader has a controlling terminal, but since in the next line you do: openvt it should be fine isnt it? vt == new controlling terminal
<hikiko> could you approve it?
<mlankhorst> sec
<mlankhorst> hikiko: meh obscure posix stuff, I need a moment to read up again..
<duflu> Do we still not have CI running tests on Android?
<hikiko> sure mlankhorst no prob :)
<mlankhorst> hikiko: does being a sesion leader imply we own a process group too?
<mlankhorst> hm I guess
<hikiko> when you become a session leader you also become the leader of a new process group
 * duflu used to know what that meant, but forgot
<hikiko> and you cant become the session leader if you are a pg leader so that's why you break the group there I guess
<hikiko> I think what you do is similar to the double fork trick that leaves one process without controlling terminal
<hikiko> because you want to assign the vt as controlling terminal when you call openvt
<mlankhorst> well good enough, I don't want to worry about it too much
<hikiko> yes, it's a minor change it just fixes the tests
 * mlankhorst instantly forgets everything about posix sessions again
<hikiko> could you approve it so that we merge it?
<hikiko> lol
<alf_> mlankhorst: hikiko: The question is: what's the purpose of the code there. To claim a new controlling terminal, or to ensure we have none?
<hikiko> alf_, since mir usually starts from a tty without being a session leader
<hikiko> it might have a controlling terminal
<mlankhorst> to claim the controlling terminal, but in some circumstances I guess we already own it
<mlankhorst> meh lets see
<hikiko> what we want is that it leaves the terminal and gets the vt
<mlankhorst> we should be session leader to intercept SIGHUP and SIGCONT
<alf_> mlankhorst: hikiko: if the purpose is to be able to claim a new controlling terminal, the code is fine. If it is to ensure we have none, then it is not.
<mlankhorst> then it's fine
<hikiko> alf_, the open vt command right after the if(..)
<hikiko> assigns a controlling terminal (the vt) to the session leader
<hikiko> so we do have a controlling terminal :)
<alf_> hikiko: ok then, approved
<hikiko> thanx
 * alan_g is about to debug stuff that tends to break the graphics stack when it goes wrong
<Saviq> hey folks, any idea about bug #1238645 ?
<ubot5> bug 1238645 in Unity 8 "Shell does not get autopilot keyboard input if maliit isn't running" [Undecided,New] https://launchpad.net/bugs/1238645
<ogra_> Saviq, why would you stop maliit-server ?
<ogra_> Saviq, it is tied to the shell through an upstart job
<Saviq> ogra_, it's "simulating" a crash
<ogra_> Saviq, to guarantee that it is always up
<Saviq> ogra_, doesn't seem to be in some of our autopilot test
<Saviq> s
<ogra_> Saviq, right, the last fix for the upstart job went just in
<Saviq> ogra_, but it should work regardless
<ogra_> how would it work ?
<Saviq> ogra_, it works through uinput
<ogra_> if a test tries to use the not running OSK
<tvoss_> Saviq, might well be that /dev/uinput is left with weird permission/weird state when maliit crashes
<Saviq> ogra_, not through maliit
<ogra_> ah
<Saviq> tvoss_, maliit uses /dev/uinput?
<Saviq> tvoss_, maliit isn't a standard input device is it?
<ogra_> definitely not
<ogra_> hmm, though we ship it by default
<ogra_> root@ubuntu-phablet:/# ls -l  /dev/uinput
<ogra_> crw-rw---- 1 root autopilot 10, 223 Oct 11 14:35 /dev/uinput
<ogra_> with proper permissions even
<ogra_> Saviq, check the permissions during and after the run
<ogra_> probably autopilot breaks them
<Saviq> ogra_, ah interesting
<Saviq> crw-rw---- 1 system bluetooth 10, 223 Oct 11 10:44 /dev/uinput
<tvoss_> hah ;)
<ogra_> lol
<ogra_> so just get a BT keyboatd for your test
<ogra_> *keyboard
<ogra_> and you will be fine
<Saviq> the interesting thing is that it works
<ogra_> (well, you might also need a robot to punch the keys ... but thats a minor detail)
<tvoss_> ogra_, would like to see the branches linked to the bug report for building the robot
<tvoss_> ;)
<ogra_> haha
<ogra_> Saviq, so find out what mangles the permissions
<Saviq> ogra_, tvoss_, chowning :autopilot doesn't matter
<ogra_> nothing in AP should touch them
<Saviq> ogra_, nothing now ;)
<Saviq> ogra_, they're at autopilot now
<ogra_> ?
<ogra_> who is they
<Saviq> ogra_, I've chmod'ed :autopilot
<ogra_> the permissions are set by udev rules
<ogra_> ah
<Saviq> ogra_, and it's still working / not changing
<ogra_> :(
<Saviq> ogra_, and anyway ap wouldn't be able to chmod it would it
<Saviq> ogra_, running as phablet
<ogra_> hmm
<Saviq> or chown
<ogra_> try to chgrp it to android_input
<ogra_> phablet is in that group
<Saviq> ogra_, but it *does* work when maliit is running
<Saviq> ogra_, and perms don't change
<Saviq> ogra_, I doubt it's so low level an issue
<tvoss_> Saviq, is qt expecting an input method to run to process key events?
<tvoss_> Saviq, at least on mobile platforms?
<Saviq> tvoss_, no, I can use python + autopilot to type in there
<Saviq> tvoss_, when maliit isn't running
<Saviq> tvoss_, just it doesn't happen when ran through tests
<tvoss_> Saviq, so what is the actual problem then?
<tvoss_> Saviq, ah
<tvoss_> :)
<Saviq> tvoss_, so we need someone to track where the events get lost
<Saviq> tvoss_, and/or if they're even delivered at all
<tvoss_> asac, ^ we might need someone from your team here
<Saviq> tvoss_, reproducible locally as the bug describes
<Saviq> tvoss_, so someone just needs to look at the events from autopilot all the way up to unity8
<Saviq> tvoss_, to see where they disappear
<asac> wait
<asac> Saviq: thats the problem? group getting changed on /dev/uinput?
<Saviq> no
<Saviq> tvoss_, asac, it's nothing infrastructural
<tvoss_> Saviq, okay
<Saviq> tvoss_, the events just don't get through the whole stack
<tvoss_> Saviq, but you can manually send events from autopilot?
<Saviq> tvoss_, yes, with autopilot.input.Keyboard - yes
<asac> ok let me know if it turns out a premission problem on /dev/uinput in the end
<tvoss_> asac, can someone from your team look if autopilot is having issues during the test run?
<Saviq> tvoss_, tried under different scenarios of maliit stopping after / before autopilot creates the Keyboard object
<Saviq> but everything worked fine no matter what I tried
<asac> during which test run?
<asac> sorry i lack context
<tvoss_> asac, https://launchpad.net/bugs/1238645
<ubot5> Ubuntu bug 1238645 in Unity 8 "Shell does not get autopilot keyboard input if maliit isn't running" [Undecided,New]
<asac> tvoss_: and you guys say you cant reproduce it?
<asac> e.g. its always working for you? :)
<tvoss_> asac, it's reproducible every time. However, when running autopilot manually and injecting key events, everything works
<Saviq> guys, seen anything like https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1236251 already?
<ubot5> Ubuntu bug 1236251 in ubuntu-system-settings (Ubuntu) "system-settings crashed with SIGABRT in raise()" [High,Confirmed]
<Saviq> let me upload a better .crash
<Saviq> since lp/apport decided to drop everything, 'cause it's a duplicate of a private bug :P
<seb128> Saviq, those Mir guys are mean to system settings
<Saviq> seb128, yeah, can you access https://bugs.launchpad.net/bugs/1234930 ?
<ubot5> Error: ubuntu bug 1234930 not found
 * Saviq hates private crashers
<seb128> Saviq, yes, make it public for you
<Saviq> seb128, thanks
<seb128> not that it's useful...
<Saviq> useless
<Saviq> ok /me uploads a better crash
<tvoss_> alf_, where is alan_g?
<alf_> tvoss_: I don't know, last I saw was "* alan_g is about to debug stuff that tends to break the graphics stack when it goes wrong"
<alf_> tvoss_: didrocks: please ensure that lp:mir and lp:development-branch stay in sync, i.e. commit to development-branch first and then merge into lp:mir manually, even when in a hurry
<didrocks> alf_: we discussed that with duflu, the dev branch should contains it as well
<alf_> didrocks: it doesn't and tracking changes can get confusing, as I am sure you know
<alf_> didrocks: hmm, sorry it does, but that shows that these back and forth merges are difficult to track...
<didrocks> alf_: I don't understand why your team recreated trunk somewhere else
<didrocks> but that's another discussion I can't tackle now
<mhall119> hey guys, I have the new mir-enabled builds for the phone, how can I take a screenshot now?
<mhall119> /system/bin/screencap doesn't work anymore
<kdub> mhall119, i don't know that there's a way at the moment
<mhall119> :( that will put a serious dent in my Google+ postings
<alf_> didrocks: tvoss_: fixed typo and synchronized lp:mir and development-branch
<didrocks> alf_: thanks!
<tvoss_> alf_, thanks
<robotfuel> is there a way to run mir headless? like Xvfb does?
<robotfuel> mhall119:  you might want to try this for screencap with mir http://people.canonical.com/~j-lallement/touch/mirfbdump
<mhall119> robotfuel: thanks, balloons gave me that and it works perfectly
<racarr> Saviq: WSeems like probably there is a switch
<racarr> errr
<racarr> ...whoops. IRC was stuck about 2 pages up
<kgunn> kdub: no pressure - just curious....when do you think you might MP the "Ricky Bobby" patch
<kdub> kgunn, working on it right, now, i'm hoping by eod
<kgunn> kdub: cool...i was just asking that way if you did...i could queue it up for Monday
 * greyback eod
<kdub> unit tests are... 103mb
<rsalveti> does anyone knows why the autobuilder is not producing armhf binaries?
<rsalveti> looking at https://code.launchpad.net/~kdub/mir/android-buffer-syncfence/+merge/189717
<rsalveti> seems it's not even building for armhf
<kdub> i think we had some trouble with jenkins?
<kdub> something i heard from alf_ during the daily mir standup
<rsalveti> hm, ok
<popey> kgunn: https://bugs.launchpad.net/ubuntu-clock-app/+bug/1238798
<ubot5> Ubuntu bug 1238798 in Ubuntu Clock App "Clock app doesn't work on mir on maguro" [High,Confirmed]
<popey> clock core app renders black under mir, fine in sf
<kgunn> popey: huh...which image
<popey> I'm using 93
<kgunn> popey: any other apps doing that ?
<kgunn> popey: and specifically on 93, you deleted .display-mir and it worked ?
<popey> lemme try that to confirm
<popey> kgunn: sorry, stand down - black on sf too
<kgunn> popey: ;)
<jono> popey, I wonder if that is related to https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1229287
<ubot5> Ubuntu bug 1229287 in Ubuntu UI Toolkit "Drawing apps show only a black screen where drawable component should be" [High,Confirmed]
<popey> jono: its new, sergio was looking at it in -touch
<jono> popey, aha!
#ubuntu-mir 2013-10-12
<snadge> im new to all this.. but i support it.. read a bit about wayland / mir and the reasons etc
<snadge> ive been forced to use fedora at my most recent place of employment
<snadge> i honestly get the impression that its redhat's intention to destroy the concept of desktop linux
<snadge> along with gnome.. they're in it together
<snadge> its just horrible.. there's no other way to put it.. keep up the good fight :)
<snadge> i just realised how fanboish that sounds.. but its the truth
<snadge> also sounds rather overdramatic.. ifyou think so, install fedora 19.. have a play with it, then get back to me
<snadge> then carry on with the good work ;)
#ubuntu-mir 2013-10-13
<snadge> no bites.. a respectful bunch of engineers who aren't into irrelevant drama.. or its bed time :P
#ubuntu-mir 2014-10-06
<duflu> Oh, that's fun. Just got a double-free in a Mir demo for the first time
<alan_g> curious.
<duflu> alan_g: I also (happily) discovered that loading a Mir server till it drops to 30 FPS has nothing to do with either CPU usage or compositor render time (because both are low, as expected).
<duflu> We have something being overloaded without overloading the CPU or GPU
<duflu> Hmm, happens very quickly when double buffered. Sounds again like something in the stack is holding buffers too long
<alan_g> Is this on both driver stacks or just the phone?
<duflu> alan_g: Only the desktop I'm playing with right now. But if it is buffer-holding or some other non-power-consuming roadblock then it could apply to both
<duflu> I'm glad I found that, because my quad-core i7 should not reasonably be dropping back to 30Hz that quickly. It has to be a bug
<duflu> I'm clearly not running out of power
<alan_g> duflu: ack. It has to be contention of some sort.
 * duflu suspects we're someone holding two buffers for the frame duration instead of 0 or 1
<duflu> *we're somehow
<duflu> Lysdexic keyboard TWF
 * alan_g wonders why DefaultInputConfiguration
<duflu> alf__: Here's a fun one :) ... https://bugs.launchpad.net/mir/+bug/1377853
<ubot5> Ubuntu bug 1377853 in Mir "Nested Mir server crashes on exit ("corrupted double-linked list")" [High,New]
<duflu> Might be the new Mesa to blame actually
<alf__> duflu: ack, I will take a look
<anpok> alan_g: why it still exists?
<alan_g> anpok: why it was ever perpetrated too
<duflu> One step forward, two steps back.
<duflu> But that was only Monday
<anpok> alan_g: it would otherwise spill ugly droidinput adapter code into serverconfiguration..
 * duflu runs off
<alan_g> It is the cause of LL635-645 in https://code.launchpad.net/~alan-griffiths/mir/fix-libmirserver-symbols/+merge/237101 (where overriding the_event_hub() is all that is really needed)
<anpok> that is the case now
<anpok> before it had a lot of more pieces it stiched together
<alan_g> anpok: I know you have cleaned it up a lot
<anpok> alan_g: but I also dislike the consequence (even though it is better than before)
<alan_g> But it is still ugly
<anpok> we have odd items inside the configuration class we only need to support the implementation details of the android input reading and dispatching
<alan_g> anpok: sure. And we have problems with DefaultSeverConfiguration too. (From the API/ABI stability front)
<anpok> which is only relevant now because we expose that.. if we wouldnt.. i wouldnt care..
<anpok> yes
<alan_g> If it were all neat it would be easy to tidy up. ;)
<anpok> hehe
<alan_g> anpok: alf__ - do either of you feel a need to review this before I TA? https://code.launchpad.net/~alan-griffiths/mir/fix-libmirserver-symbols/+merge/237101
<alf__> alan_g: Feel free to TA, unless you strongly feel that we should take a look.
<alan_g> alf__: Thanks. I don't feel a need for your approval on this one.
<mardy> hi! Is there a way to know if a given PID has a mir connection open (what I need to know, is if I can open a trust session having this PID as initiator)?
<alan_g> mardy: as a prompt provider? Or as a shell?
<alan_g> The shell could iterate over all sessions looking for the PID. But why would it matter if there's a connection open?
<mardy> alan_g: asa  prompt provider
<alan_g> mardy: not through a Mir API
<mardy> alan_g: would mir_connection_create_prompt_session_sync() return NULL if the initiator pid does not have a mir connection open?
<alan_g> mardy: IIRC it ought to return an error object. I.e. mir_prompt_session_is_valid will return false
 * alan_g can't see a test for that scenario but thinks there should be one.
<mardy> alan_g: thanks
<alan_g> yw And thanks for highlighting a gap in our test coverage.
<alan_g> mardy: While I (and dednick) think mir_connection_create_prompt_session_sync() should fail as I described, the current code doesn't (it creates a prompt session and then silently doesn't add the non-existent participant to it - ugh!)
#ubuntu-mir 2014-10-07
<duflu> alf__: If you're hacking Mesa, probably best to check you really have the latest branch. I know anpok_ has made fixes to our Mesa patch still waiting for release
<duflu> I assume its all in git somewhere and you guys know this, but just in case
<alf__> duflu: Thanks, I will sync with anpok
<duflu> alf__: In other news unity8 (for utopic at least) is much faster today
<duflu> .. if you update fully
<alf__> duflu: great, can't wait to try
<duflu> The update is only in utopic though. Not rtm
<alf__> duflu: not even rtm-proposed?
<duflu> Not sure.
<alan_g> dednick: would you re-review https://code.launchpad.net/~alan-griffiths/mir/fix-1377968/+merge/237287? Thanks
<duflu> Why does consuming one frame per vsync yield 120FPS?
<duflu> Who is consuming my frames?
<anpok_> maybe that is your refresh rate?
<duflu> anpok_: I wish
<alan_g> Silly question #1: have you counted the number of times you consume on "vsync"?
<dednick> alan_g: approved.
<alan_g> dednick: thanks.
<alan_g> kdub_: this work for you? https://code.launchpad.net/~alan-griffiths/mir/fix-libmircommon-symbols/+merge/237255
<kdub_> alan_g, yep
<alan_g> :)
<qengho> Hey all. In the toolkit, what might cause  mir_connect_sync("/tmp/mir_socket", "appname")  to hang (for at least 10 seconds)?
<qengho> MIR_SOCKET=/tmp/mir_socket mir_demo_client_multiwin   # works
<alan_g> qengho: having the server stopped in the debugger?
<qengho> alan_g: :)  Right. Anything else?  Only client has a debugger attached, sometimes, here.
<qengho> ...and the other client works.
<alan_g> what sever are you using?
<alan_g> *server
<qengho> mir_demo_server_basic
<alan_g> you are running all clients from the same user?
<qengho> alan_g: yes, same user.  Server is sudo-ed, and socket set to writable.  One mundane user used to run demo client and my own.
<alan_g> That server doesn't care what the client is, so if there are differences then they are between the clients
<alan_g> You could try setting the server  mir_connect_sync report and/or the msg-processor-report to log and see if the connect attempt is detected
<racarr> greyback:
<racarr> Err...whoops lol
<racarr> greyback: Anyway....re: the extra build deps...Ithink they are either needed or we have to disable building qtmir-desktop on armhf
<racarr> via other mechanisms...
<racarr> was qtmir-desktop being built on armhf before?
<racarr> it seems like it...
<racarr> it looks like it was
<racarr> I dont understand though
<racarr> there is no opengl build dep
<racarr> in lp:qtmir as it stands...
<racarr> I also dont understand how mir uses a build dep on libgles-mesa but doesnt get
<racarr> a runtime dep from ${shlib:Depends}
<racarr> but
<racarr> qtmir does whenaddingthe buld dep
#ubuntu-mir 2014-10-08
<duflu> Woo, tearing! I haven't seen that in a while ;)
#ubuntu-mir 2014-10-09
<duflu> Mir 0.8.0 is now tagged and released.
<duflu> Mir 0.9 already underway :)
<anpok_> ah
<anpok_> the issue i had yesterday ..
<anpok_> i cannot connect clients to nested servers if the nested server is not running on the current vt
<anpok_> while i can do that for none nested servers
<duflu> anpok_, yay
<duflu> anpok_: Hey were you expecting i915 to work in that latest Mesa? My i945 doesn't
<duflu> ... still
<anpok_> no not yet
<anpok_> duflu: 10.3.1 is all i can say .. it was review about three weeks after i posted that patch..
<anpok_> *reviewed
<duflu> anpok_: OK, I was confused. Looks like Ubuntu's getting Mesa fixes in non-chronological order
<duflu> Maybe not
<anpok_> hm the last update was a fix of mir egl platform
<duflu> anpok_: Yes, which is much newer than your i915 fix :)
<alan_g> alf__: @a-simpler-server-setup any thoughts on L257?
<alf__> alan_g: looking
<alf__> alan_g: Better to throw IMO
<alan_g> OK
<alf__> alan_g: anpok_: duflu: RAOF: We have three test utility classes doing the same thing(WaitCondition, WaitObject, Signal). I am going to keep one of them. Please vote on which *name* you prefer (I will keep the WaitObject/Signal (same thing) implementation in any case).
<duflu> alf__: Event ;)
<duflu> or something
<duflu> alf__: Well we don't have predicates like real conditions do, so not WaitCondition. Not WaitObject because "object" is too general a word for a class name. And not "Signal" because signal is a verb -- a method name really.
<duflu> Need a new name I think
 * alan_g goes to look what they actually do...
<duflu> I was joking about Event, but maybe it's a good idea. Not sure and am not about to review the classes in detail
<alf__> duflu: alan_g: Actually perhaps we should just get rid of all the classes and use std::future
<duflu> alf__: I believe C++ should provide everything we need, one way or the other
<duflu> Not std::future though. That's an ugly one
<duflu> alf__: Tell you what; I will close my eyes for now because too many opinions always slow us down
<alan_g> alf__: have you seen mt::Signal?
<duflu> And I have work to try and finish before too long
<alan_g> Sorry, thinko
<alan_g> mt::Barrier is similar too.
<alan_g> alf__: I think there are three relevant idioms "latch", "barrier" and "future". WaitCondition, WaitObject & Signal all look like latches to me.
<alan_g> This doesn't describe a wait_for(time-out) function, but seems sane: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3666.html
<alf__> alan_g: It could be that I am not familiar with the term 'latch' in this context, but I don't find it to be a very intuitive name for a mechanism providing inter-thread notification. When I see 'latch' I think 'flip-flop', for which the emphasis is on state storage rather than notification.
<alan_g> alf__: ak
 * alan_g rediscovers the joy of pre-processor macros
<greyback> alan_g: can I pick your brain on a linker rpath issue I'm having?
<alan_g> greyback: sure, but I'm no expert
<greyback> alan_g: here's my notes: https://docs.google.com/document/d/1d0Djaz0T9OXJVK1wNToj4eYIgkd2N-68T-p7EPZYZJo/edit - the problem is mentioned there
<alan_g> greyback: paraphrasing: you can set the rpath either for in-tree or for installed but have trouble handling both?
<greyback> alan_g: essentially yes
<greyback> alan_g: I had expected that the rpath specified in the executable would take precedence over those in the linked libraries, but it appears not
<alan_g> I know CMake relinks stuff it installs, so maybe you can use that mechanism
 * alan_g knoes even less about cmake
<greyback> qmake doesn't - yet another reason to use racarr's cmake work asap
<greyback> but that is good to know about cmake - soundsl ike it would fix this problem for me
<greyback> I've spent too long fighting qmake over this, so think most sensible option is indeed cmake
<greyback> ok, that's a good enough solution for me, thanks alan_g
<alan_g> greyback: yw
<mardy> alan_g: about that mir_connection_create_prompt_session_sync() not failing if the initiator is not a valid PID, is it on the radar? Do you have a bug for it?
<alan_g> mardy: lp:1377968
<mardy> alan_g: oh, that was quick! Thanks! :-)
<robotfuel> https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1365673 kgunn can we bump the priority of this bug to critical?
<ubot5> Ubuntu bug 1365673 in unity8 (Ubuntu) "/usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene:6:qt_message_fatal:QMessageLogger::fatal:UbuntuClientIntegration::UbuntuClientIntegration:UbuntuMirClientIntegrationPlugin::create:loadIntegration" [High,Triaged]
<robotfuel> kgunn: it's a top crasher every day
<robotfuel> kgunn: we thought that fixing 20141008.1 would fix the issue but it did not
<robotfuel> oops
<robotfuel> kgunn: we thought that fixing bug #1368101 would fix the issue but it did not
<ubot5> bug 1368101 in qtmir (Ubuntu) "Stopped apps don't restart when launched from another app" [Critical,Fix committed] https://launchpad.net/bugs/1368101
<kgunn> robotfuel: per pmcgowan & jfunk in managers channel they want to address the OOM killer issues first
<robotfuel> kgunn: ok is there a bug number for that? so I can ask for the bug to be critical instead of high when that is fixed?
<kgunn> robotfuel: according to pat & asac they don't have one yet, gonna log one
<kgunn> i'll let you know when i know
<RAOF> alf__: I (unsurprisingly, as I chose the name originally âº) vote Signal. Unlike duflu, I'm aware of signal, the noun :)
#ubuntu-mir 2014-10-10
<slvn> Hello !
<slvn> I am developping an application for Ubuntu Touch that is native
<slvn> it talks directly to mir, and use open gl
<slvn> I would like to get it fullscreen
<slvn> it works correctly in fullscreen with MIR-only
<slvn> but with the launcher (.click package), there is the "appmenu" (status bar with clock, battery, wifi)
<slvn> how to hide this AppMenu ?
<slvn> I was told that CameraApp was totally fullscreen ... it seems, (though it also reboot my Nexus10)
<greyback> slvn: are you using Qt?
<slvn> greyback, no !
<greyback> slvn: mirclient?
<slvn> C/C++ + MIR Client
<slvn> yes, through SDL
<greyback> ah ok. I'm not sure if SDK wraps this correctly, but mirclient has a mir_surface_set_state(MirSurface *surface, MirSurfaceState state) method where you can set the state to mir_surface_state_fullscreen - and that will make it fullscreen
<greyback> slvn: ^
<greyback> s/SDK/SDL/
<slvn> yes, mir/sdl works correctly
<slvn> it sets the surface to fullscreen
<slvn> it actually works when I run the application with mir only
<slvn> ( I did that a few month ago)
<slvn> but, when the app is package with click
<slvn> and started with the launcher (upstart?)
<slvn> there is this status bar
<slvn> so my "fullscreen" windows is shifted
<slvn> I need : either to hide the status bar, or to have it sizes
<greyback> I don't know of any reason why it being packaged in a click package would stop it being fullscreen. This Mir API is the only way to do it
<greyback> if the surface has the fullscreen property set, then unity8 will hide the status bar at the top (camera app & gallery succeed in doing this)
<slvn> Hmm, maybe this property has then so be set before some transaction with unity
<alan_g> slvn: as a way of narrowing the problem: have you checked with "mir only" recently?
<slvn> alan_g, after reflexion, "mir only" needs me to do "initctl stop unity8" + start mir_demo_server_shell
<slvn> I haven't tried it recently
<slvn> but that's almost sure ...
<slvn> before it just start mir
<alan_g> slvn: there are three bits of software that may have the problem mir, unity and your program. If we can eliminate unity...
<slvn> I fine to try !
<slvn> my "mir only" configuration is in fact with the "mir_demo_server_shell"
<slvn> but I can find this tool anymore
<slvn> can't
<alan_g> slvn: mir_demo_server_basic should suffice
<slvn> how can I turn on the "apt-get" packages system ? and which package should I get ?
<alan_g> slvn: don't bother. After a quick grep there's no code in Mir that cares about the mir_surface_state_fullscreen attribute - it is passed on to unity.
<slvn> And as you said "Gallery"  is correctly hiding the status bar
<slvn> reading the headers files
<slvn> I might have to call "mir_wait_for"
<slvn> after "mir_surface_set_type
<alan_g> greyback said that. (But it looks like it works to me)
<alan_g> slvn: yes, that's an async call
<duflu> slvn_: FYI: the state and type attributes are not implemented in mir_demo_server_*
<duflu> they won't do anything there
<duflu> yet
<duflu> Which is why our demo clients fake fullscreen by just sizing themselves
<duflu> It's on the list of things to do :)
 * duflu -> weekend
<slvn_> alan_g, greyback : So I have found :)
<slvn_> this is a typo error : calling mir_set_type() on a "State" wont work ..
<slvn_> I will report the bug + path to SDL
<greyback> slvn_: aha, good catch!
<alan_g> slvn_: excellent!
<slvn_> :) SDL has macros to load the shared library. and then is may "skip" the type. so there was no warning from the compiled
<slvn_> compiler.
<slvn_> then I have my issue :o)
<slvn_> I want to use the mir surface
<slvn_> in landscape or portrait
<slvn_> I don't really to how to explain that, but here it is.
<slvn_> I have a game that always plays in *vertical*. (like  a tetris ! you need to play in portrait, not in landscape)
<slvn_> If I use a tablet Nexus10 for instance,  I want the game to be display in the portrait direction
<slvn_> both ios and android has a way to do that
<alan_g> slvn_: as things are right now Mir doesn't really deal with orientation beyond mir_surface_get_orientation() - and that's under the control of unity. greyback may know if apps can lock the orientation
<greyback> slvn_: on your portrait/landscape issue - I suggest you read the width & height of the surface you get from Mir, and orient your view to always be portrait
<greyback> slvn_: so on phones, you'll have height > width, so that's portrait by default
<greyback> on tablet, it'll be width > height, so you'd need to rotate your game view somehow to suit
<slvn_> yep but how to rotate my game view ?
<greyback> slvn_: we've not fully implemented the proper way for an app to specify orientations
<greyback> that I can't answer, I don't know SDK at all
<greyback> SDL
<greyback> grr, muscle memory
<slvn_> hmm, I will see what can I do with the internals of SDL
<slvn_> I think I would need a "mir_surface_SET_orientation", like the "get" that exists...
<greyback> slvn_: that won't happen. It's not the application's decision to say what it's orientation should be. Instead the shell dictates that.
<greyback> you're right though, shell should rotate and resize the surface to suit the app
<greyback> we're just not there yet
<greyback> so the plan is for app to specify what orientations it supports, in the desktop file probably
<greyback> and shell will respect that
<slvn_> greyback,  but in the end, this is the application that choose :) either by a .desktop, or a call to mir api
<greyback> slvn_: yep in the end, the app chooses what it prefers
<slvn_> you say the plan is to specify the orientation in the desktop file for instance. Is there a Ticket issue ?
<greyback> slvn_: I've failed to locate one, so I made one https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1379777
<ubot5> Ubuntu bug 1379777 in unity8 (Ubuntu) "Allow applications to specify the orientations supported" [Undecided,New]
<slvn_> greyback, great, perfect, you make it understandable !
<kdub> jenkins has a mystical ability to generate strange errors: "virtual memory exhausted"?
<greyback> slvn_: I've no idea of time-scale when we can deliver that. But I'll update that bug when we start working on it
<slvn_> I believe this important when creating an application that cannot react to all orientation, and that require a specific orientation
<greyback> totally
<anpok> alf__: regarind the vt switching issues..
<anpok> regarding
<anpok> hmm what is causing the failure?
<alf__> anpok: In the nested case we create an auth fd, get the magic cookie in the nested server and ask the host to auth it. However, the magic cookie that is returned by drmGetMagic is tied to the currently active drm master, but in this particular use case, there is no active master ([1]), so the cookie is useless, the host server can't auth it.
<alf__> anpok: [1] That's not exactly true, it could be that the master is the auth fd created by the nested server, but that's another bug
<alf__> anpok: in any case, things fail
<anpok> oh
<alf__> anpok: one solution is to introduce a new client function mir_connection_drm_get_auth_fd() so that the host server can perform the GetMagic/AuthMagic calls in one place
<anpok> alf__: why would that solve the issue?
<anpok> ah
<mterry> Does https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1379848 look like anything people have seen before?
<ubot5> Ubuntu bug 1379848 in mir (Ubuntu) "Crash in mir::compositor::BufferQueue::give_buffer_to_client" [Undecided,New]
<anpok> on a closing application? could this be https://bugs.launchpad.net/bugs/1376324
<ubot5> Ubuntu bug 1376324 in mir (Ubuntu) "/usr/sbin/unity-system-compositor:*** Error in `unity-system-compositor': free(): invalid pointer: ADDR ***" [High,Triaged]
<anpok> ^ mterry
<mterry> anpok, the crash seems to be happening between two pages of the wizard.  But the indicators and maliit-server are being restarted when this crash happens.  So clients are closing and reconnecting, yeah
#ubuntu-mir 2014-10-11
<Nothing_Much> Nvidia's gonna support Mir 100%!
#ubuntu-mir 2015-10-05
<RAOF> Fun fact! mg::DisplayConfigurationOutput will be full of unititialised values if connected=false!
<bschaefer> RAOF, yup ran into that before
 * bschaefer just assumed it was undefined behavior 
<anpok> alan_g: the needs fixing in https://code.launchpad.net/~andreas-pokorny/mir/probe-libinput-platform/+merge/273046 was for the update of the symbols.map, the not yet existing am-i-root check or the mircommon pormotion discussion?
<alan_g> anpok: the "Needs Fixing" one was the the symbols.map comment. The others are just comments.
<dandrader> alan_g|lunch, "[...] probably better to call override_the_cursor() [...]" you mean overriding mir::Server::the_cursor()?
<alan_g> dandrader: I mean calling mir::Server::override_the_cursor()
<dandrader> alan_g, mir::Server doesn't have a override_the_cursor() method (at least not in version 0.16).
<alan_g> dandrader: oh. (It takes so long for a release to hit archive I sometimes lose track)
<alan_g> dandrader: BTW the only reason hide() is working for you at all is that you're bypassing Mir input and as a result that doesn't e.g. update the cursor position.
<dandrader> alan_g, well, I see the mir cursor moving around
<dandrader> alan_g, any way I can override the cursor in mir 0.16?
<alan_g> not with the published APIs. You need -c 2953
<alan_g> dandrader: I'll have a think. But we may want to roll a 16.2 with -c 2953 (and some other stuff)
<dandrader> alan_g, ok, thanks
<alan_g> dandrader: I was wrong. The reason it seems to work is that the cursor never changes (e.g. by mouse over a surface that has set the cursor) - there's an optimization that avoids the show() I was thinking of. Not quite sure why your hot-plugging scenario leads to an update. Calling hide() again might be a workaround.
<dandrader> alan_g, pushed a workaround for it some minutes ago. I call hide() on compositor::start()
<dandrader> alan_g, which happens everytime you connect or disconnect a monitor
<dandrader> alan_g, or so it seems
<alan_g> dandrader: yes. we (currently) restart compositing on display config changes.
<alan_g> dandrader|afk: on a related point, why can't you use the Mir cursor? Is there functionality missing?
<alan_g> greyback: do you know? ^
<greyback> alan_g: missing functionality. Not major things, but a bunch of minor things we'd like, e.g. pointer barrier, better rotation support, pointer trapped on a single screen in multimonitor case...
<greyback> we had thought to implement pointer acceleration ourselves too, but libinput will fix that
<anpok> greyback: will you really need to imeplement pointer barrier .. or added friction to screen boundaries?
<greyback> anpok: not in the recent future
<alan_g> greyback: so that leaves "better rotation support" and "pointer trapped on a single screen" as the key issues currently?
<greyback> alan_g: yes, those are only things coming to mind short-term
<greyback> dandrader: did I forget anything? ^^
<dandrader> sound ok
<dandrader> sounds
<alan_g> What does "better" mean for rotation support?
<alan_g> 90 degree rotations to match orientation?
<dandrader> alan_g, when shell ui rotates, mouse pointer should rotate accordingly (rotate image and movement axes)
<dandrader> alan_g, we get it for free and pretty neatly when the mouse pointer is just another qml item in shells scene
<dandrader> alan_g, but with he mouse pointer being an extraneous element, it's a bit of a pain
<greyback> rotating mouse in mir right now requires display configuration update, which is hard for unity8 to deal with at runtime
<greyback> as it resizes the scene
<alan_g> OK, I'm not yet familiar with all the issues, but have something to go on.
<anpok> dandrader, alan_g: afaik rotation does not work with drm/mesa... while with android the cursor is done as a scene element so there rotation should work..
<anpok> (rotation of the cursor ..)
<dandrader> anpok, so on android mir does not provide a hardware cursor?
<dandrader> anpok, (or android doesn't have hardware cursors)
<anpok> dandrader: it is using overlay hardware for the cursor when possible
<anpok> it is just already present as scene content.. hence the scene rotation will take care of the detail.. (either by rotating when falling back to gl, or by applying the attributes to the overlays)
<anpok> for mesa drm it is just something separate.. but yes some day we will switch to drm planes and the same will be true there
<robert_ancell> Saviq, what video card did you have for bug 1501941?
<ubot5`> bug 1501941 in xserver-xorg-video-intel (Ubuntu) "Screen turned off after X server exits" [High,Triaged] https://launchpad.net/bugs/1501941
<robert_ancell> olli, also for you?
<olli> robert_ancell, we have the same XPS12
<robert_ancell> olli, can you paste the result of "grep Intel /var/log/Xorg.0.log"
<robert_ancell> olli, thanks. You have a 4400 like me.
#ubuntu-mir 2015-10-06
<RAOF> So, *of course* I'm unable to reproduce the failures on https://code.launchpad.net/~mir-team/mir/surface-output-events/+merge/272698 locally.
<RAOF> That would be too easy.
<duflu> RAOF: -"just landed" +"about to land"
<RAOF> I guess technically top-approved â  landed, but it's pretty close :)
<duflu> What could possibly go wrong? :)
<RAOF> Oh, hah.
<RAOF> Android tests fail because Android is hilariously unprepared for being sent disconnected displays.
<duflu> Fixes are pending
<duflu> Also, Marshmallow images now exist. If you're into such things.
<RAOF> Huh.
<RAOF> Have we managed to make Mir fail to build without precompiled headers?
<anpok> it happens now and then that headers are missing from tests
<RAOF> Yeah.
<anpok> i believe we dont have a slow build ci job..
<RAOF> One of our amd64 builds would be a good idea.
<RAOF> Jenkaas.
<anpok> hm which drm headers should we use?
<anpok> only one got updated with the new cursor cap enums.. but I believe that one is inherently c++ unfriendly
<RAOF> xf86drm.h is the right one, no?
<RAOF> (And friends)
<anpok> it pulls in <drm.h> ..
<anpok> hm which with our config then pulls in libdrm/drm.h I believe
<RAOF> Hm.
<RAOF> I think it's going to be a multi-hundred-line diff to make Mir build without precompiled headers :)
<alan_g> alf: what's the ETA for branching 0.17? (I'd like to sneak an API tweak through beforehand to avoid breaking in 0.18)
<alf> alan_g: A couple of days. I am still waiting for a few required fixes/improvements to land.
<alan_g> alf: perfect. :)
 * guest42315 waiting for xmir :(
 * anpok just thinks about the 32k lines change he wants to sneak in
<alan_g> anpok: I want that one too. Just need a bit of time to check it
<anpok> hm the krillins we have in ci seem to behaving different..
<anpok> or is that caused by my mps..
<shiznix> hi all, apologies if this is the wrong forum or if it's an FAQ already, but is Xmir supposed to work in Wily desktop for either Unity7 or Unity8 sessions?
<alan_g> shiznix: there are a lot of problems with Xmir. They're across a range of dependencies and I doubt they'll all land in Wily now it has hit feature freeze. duflu is probably best informed.
<duflu> shiznix: No, the new incarnation of Xmir is not ready for general consumption
<anpok> why does clang prefer initializing members over just using the default copy constructor in template contexts when it parsers something{something_of_the_same_type}
<shiznix> ok thanks, i'll hold off on bug reports re. Black Screen of Death then ;)
<anpok> -r
<alan_g> alf: the MP I want to sneak into 0.17: https://code.launchpad.net/~alan-griffiths/mir/tweak-cursor-configuration/+merge/273512
<alf> alan_g: ack
<dandrader> alan_g, should I be able to see the mir cursor on a nexus 7?
<dandrader> alan_g, I'm trying to debug something and being able to see what the mir cursor is up to would help a lot
<alan_g> dandrader: I thought you had code to hide it?
<dandrader> alan_g, that's with a nexus 7 I just flashed. my code to hide mir cursor hasn't landed yet
<dandrader> alan_g, I can see mir cursor on my laptop just fine
<dandrader> alan_g, and that's what I've been using for development
<dandrader> alan_g, but now I started testing things on the nexus 7
<dandrader> alan_g, and there's a problem where, unity8 stops receiving mouse events from usc
<dandrader> alan_g, likely because the mir mouse pointer is not over any of unity8'
<dandrader> s surfaces
<alan_g> dandrader: I don't know of any special case code. But whether it works on N7 I don't know
<alan_g> Something, somewhere hides the cursor on phablet (or maybe it is not detecting the mouse?)
<dandrader> alan_g, unity8 is getting mouse events and its ui is responding to them. I just don't see the mir mouse pointer on the screen. not a big deal. just wanted a visual clue of mir cursor whereabouts to help with my debugging. can achieve the same result but with some more work.
<dandrader> hmmm..... thinking better about it. I think I know what's the problem with mouse events when I connect an external monitor
<dandrader> I have unity8 drawing its shell on the external monitor and I draw a full screen notice on the built-in display
<dandrader> the qml mouse in the shell moves fine
<dandrader> up to a point
<alf> dandrader: alan_g: I don't know if it's related to your setup, but USC explicitly disables the cursor
<dandrader> if I go anywhere near the left edge (I mean x less than 1/4 of the screen width)
<dandrader> the mouse stops moving
<dandrader> I guess it's because the mir mouse moved away from the external monitor area onto the built-in display
<dandrader> since the mir cursor has acceleration it moves faster the qml one (relative movement that the qml cursor consumes is not accelerated atm)
<dandrader> alf, only on android, right?
<alf> dandrader: yes (AFAIK)
#ubuntu-mir 2015-10-07
<hikiko> hello
<hikiko> I have a question, it's not mir related but since you write gles you might know
<hikiko> I've fixed an issue in compiz using shaders
<hikiko> and I want to test that these shaders work in gles
<hikiko> (atm I just avoided fixed function calls and I tested it works)
<hikiko> is there a way to make compiz use gles on desktop?
<hikiko> (GLES2)
<RAOF> We did have a GLES build at one point, I recall.
<hikiko> I can build it (configure cmake to use gles)
<hikiko> but I don't know how to run it
<RAOF> /path/to/build/tree/compiz --replace should work, I think?
<hikiko> I only speculate it works now :)
<hikiko> really?
<RAOF> Worth a try!
<hikiko> thanks RAOF :D
<hikiko> RAOF, it doesn't seem to use the GLES2
<RAOF> hikiko: Ah, then I don't know. Sorry.
<hikiko> no prob RAOF thanks :)
 * alan_g wonders whether to go looking for the mesa source
<anpok> http://cgit.freedesktop.org/mesa/mesa/ and http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/mesa/wily/files
<anpok> alan_g: ^
<alan_g> anpok: Now I can wonder whether to look at them.  ;)
<anpok> :)
<anpok> alan_g: what was your initial motivation/
<alan_g> anpok: lp:1503450 (and fix) but I've got distracted by worms crawling out of the tin.
<anpok> ah that one
<alan_g> There are also mirclient headers that #include <mir_toolkit/mir_native_buffer.h> - so we either need a "Requires.private mircommon" in mirclient.pc or to "fix" those headers.
<alan_g> And mir_buffer_stream_get_current_buffer(..., MirNativeBuffer **buffer_package) disagrees between parameter type and parameter name. (Should it be MirBufferPackage** buffer_package?)
<alf> greyback: Hi! I am trying to debug a qml app (ubuntu-system-settings). I have changed the installed qml source code to console.warn() a message, but I don't see any output in the log. Is there a way to get some debugging output from qml? (or perhaps the qml code is cached and I need to refresh the cache?)
<greyback> alf: console.log("hi") or simply print("hi") should be enough
<greyback> cache should not interfere
<greyback> cache is smart enough to notice qml file changed and drop the cac
<greyback> alf: any problems, ask in #ubuntu-unity (I'm at conference, my connectivity is poor)
<alf> greyback: ack, thanks
#ubuntu-mir 2015-10-08
<RAOF> On the plus side, I'm maybe a third of the way into making QtMir handle multiple bufferstreams.
<RAOF> Oh, yeah.
<RAOF> Lots of QSimulcrumOfStl, but it's all slightly worse.
<RAOF> Although I guess CoW is pretty cool.
<anpok_> simulcrum?
<RAOF> Sumulcrum?
<RAOF> Simulcrum?
<anpok_> Q?
<RAOF> My standard misspelling of simulacrum.
<RAOF> https://www.wikiwand.com/en/Simulacrum
<RAOF> For those not familiar with the obscure brand of English I sometimes spout.
<anpok_> oh I thought of something like simula cruft..
<anpok_> which didnt really fit
<duflu> RAOF: Recently discovered Qt logging doesn't understand std::string, but instead requires construction of QString from std::string first. That was odd
<anpok_> test
<alan_g> greyback: does the CI failure mean anything to you? It doesn't seem related and I've not reproduced (but not tried to set up identical environment yet). https://code.launchpad.net/~alan-griffiths/qtmir/test-harness-for-MirWindowManager/+merge/267369
<greyback> alan_g: looks unrelated yes. Something else is broken in CI
<Saviq> hey guys, there's an email thread on phone ML, someone's having issues with DPI not being reported by QScreen, so likely it's not set by... and now the question - by what? graphics driver?
<Saviq> (the subject is "help with touchscreen configuration...")
<Saviq> tvoss, you might know â
<greyback> Saviq: qtmir/qtubuntu supply it if they can, but they don't currently. Qt will calculate it from physical and logical screen size
<greyback> which again may not be accurate
<greyback> I think I may have improved the situation in the multimonitor work actually
<greyback> ah no, it was there before
<Saviq> greyback, still, those values should come from the graphics driver, if they're bad, not much we can do (other than saying: ok, these are dumb, we'll just invent some values that make more sense)
<Saviq> greyback, can you please reply on the ML?
<greyback> sure
 * guest42315 EWWWW mailing lists 
<anpok> oh
<anpok> but we dont calculate the physical size through the touchscreen..
<ogra_> how would you "calculate" that ?
<anpok> i believe we get that info from hwc..
<ogra_> you dont know how physically big a pixel actually is
<ogra_> could be 0.01mm or could be 3cm ...
<anpok> well as already said hwc provies dpi in both directions .. I thought the above was related to touch screens.
<anpok> .. and so far I havent found a single touch screen driver that provides that info..
<ogra_> right
<ogra_> usually you get the resolution boundaries only
<ogra_> (for touch)
<ogra_> and if you are lucky an offset
<seb128> is anyone looking at landing mir 0.16.1 to wily to fix the current build issue?
<guest42315> uuu mir 0.18
<alan_g> seb128: I thought 0.16.1 landed a while ago. What is "the current build issue"?
<seb128> alan_g, it landed in vivid-overlay, not wily
<seb128> alan_g, and the build issue is basically what is described in the fix, http://bazaar.launchpad.net/~mir-team/mir/0.16/revision/2951
<alan_g> Oh, I thought that was duel landed (before FF).
<seb128> CI team changed dual landing to go to the ppa for wily rather than the archive
<seb128> so maybe that's where it went
<seb128> in which case somebody need to copy it over to wily
<alan_g> I though 0.16.1 was before that, but I expect you're right that it didn't.
<alan_g> vogons: can anyone clarify^^?
<kgunn> alan_g: seb128 is this the mesa build fix ?
<seb128> kgunn, yes
<kgunn> that was actually 16.2 i thot
<kgunn> which didn't quite make it
<kgunn> i bet
<kgunn> on the hairy edge
 * alan_g wonders if https://bazaar.launchpad.net/~mir-team/mir/0.17/revision/3005 would be useful too?
<alan_g> kgunn: we haven't done a 16.2 (yet)
<seb128> kgunn, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5473299/+listing-archive-extra
<seb128> kgunn, that suggests it's 0.16.1
<alan_g> "Copied from ubuntu wily"
<seb128> https://launchpad.net/ubuntu/+source/mir
<alan_g> seb128: so in answer to your original question: no. ;)
<seb128> k
<seb128> can we get something assigned to sort that out? ;-)
<kgunn> seb128: do you need it in a rush ?
<seb128> kgunn, no, but this week or next I guess
<seb128> before wily is out
<kgunn> eh
<alan_g> seb128: do you want a fix for lp:1503450 too?
<alan_g> Or is 16.1 enough?
<kgunn> alan_g: yeah, wondering, should we just punch mir0.17 in as the final for wily ?
<seb128> bug #:1503450
<alan_g> kgunn: if someone can get us a FFE
<seb128> bug #1503450
<ubot5`> bug 1503450 in Mir "mesa FTBFS due to missing Requires in mirclient" [High,Fix committed] https://launchpad.net/bugs/1503450
<seb128> I think that would be worth including
<alan_g> So we either cherry pick -c 3005 to make 16.2 or add wily to the current "duel" release of 0.17
<seb128> dual landing don't land to the distro anymore though
<seb128> but you can probably pocket copy over
<alan_g> seb128: ack.
<kgunn> yep, doubles testing altho vs risk of mir0.17 hitting some bumps and taking longer
<alan_g> alf: opinion? ^^
<alf> kgunn: alan_g: Can we release to wily independently? That is land in overlay (v+w) first, then try for wily, and if we have problem we can think about 0.16.2?
<kgunn> alf: we should do dual landing regardless...yes, and then try to poke the whole thing into wily with FFE
<kgunn> alf: so mzanetti currently has his phone in the state where is will not screen blank
<kgunn> with the ota7 candidate
<kgunn> is there any debug to be had ?
<kgunn> basically this bug https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1502145
<ubot5`> Ubuntu bug 1502145 in unity-system-compositor (Ubuntu) "rc-proposed r140, krillin: screen does not blank after timeout expires" [Undecided,Confirmed]
<alf> kgunn: not really, I guess we could get a backtrace, but previous backtraces in this situation didn't provide any info (everything seemed normal). I need to find a way to reproduce this, so I can run with a special USC build with extra logging to figure out what's going on (e.g. if some other process has asked USC to keep the screen on, or there is some strange bug in USC)
<kgunn> alf: do you have a special usc available ? since mzanetti is trying to repro he may as well load it
<alf> mzanetti: ^^ Any information about how you got into this state? Any other apps open etc
<alf> kgunn: No, I wanted to build one but was too busy with the release
<mzanetti> alf, no... just doesn't turn off any more ever since I did an OTA last night
<alf> mzanetti: so it doesn't turn off consistently or is this a one-off?
<anpok> something like powerd-cli list/stats..
<mzanetti> and for faenil that seems to be the case too since monday (I didn't do the update earlier because I was travelling)
<mzanetti> alf, consistently, sometimes it even turns itself on and doesn't go off any more
<alf> mzanetti: ok, which device is this?
<alf> mzanetti: I guess pressing the power button turns the screen off, right?
<mzanetti> alf, krillin, yes power button works
<alf> mzanetti: how do I flash OTA7 on the phone?
<alf> mzanetti: I mean to which revision in the stable channel does it correspond? The latest stable?
<kgunn> alf: latest rc-proposed
<kgunn> well....
<kgunn> landings are open (but damn close)
<alf> mzanetti: kgunn: I wonder if there is a difference in flashing clean vs updating... perhaps there could be an incompatibility in settings when updating
<alf> mzanetti: ah, one thing to try...
<alf> mzanetti: gsettings get com.ubuntu.touch.system activity-timeout
<alf> mzanetti: and gsettings get com.ubuntu.touch.system dim-timeout
<mzanetti> alf, this is the OTA-7 channel ubuntu-touch/rc/bq-aquaris.en
<mzanetti> alf, it will become stable when we finally release it
<alf> mzanetti: ack
<mzanetti> alf, should be *very* similar to rc-proposed atm, but that is opened for new landings again
<mzanetti> so rc-proposed might have additional stuff on top already
<kgunn> yeah but nothing landing frmo us
<alf> mzanetti: when you get the chance please get the gsettings mentioned above
<alf> mzanetti: I want to check if we are ok on the settings side of things
<mzanetti> oops. missed that... getting it now
<mzanetti> alf, uint32 60
<mzanetti> and uint32 45
<alf> mzanetti: ok, these look sensible
<mzanetti> so far can't repro on mako
<mhall119> does Mir recognize mouse-wheel scrolling and pass it on to Unity 8?
<mhall119> I have a bluetooth mouse connected to my N4, and it all works except the scroll wheel
<anpok> mhall119: it should
<anpok> mhall119: https://code.launchpad.net/~lukas-kde/qtmir/wheelEvent/+merge/273150
<mhall119> anpok: ok, so it's not landed yet, but the implementation has been done
#ubuntu-mir 2015-10-09
<duflu> It's kind of nice that no matter how many times Xmir crashes in a day, Mir itself does not
<alan_g> duflu: you must try harder. ;)
<duflu> alan_g: Well, between us we fixed the two ways Xmir can crash a vanilla Mir server
<duflu> It still does crash if you're on old Mir 0.16
 * alan_g can still crash Mir many times in a day
<duflu> alan_g: Via a broken client though?
<alan_g> I concede that point.
<alan_g> Weird, today animated cursor on a nested server works if the host is mesa-drm but gives a black square if the host is mesa-x11
<alan_g> Has mesa just been updated?
<duflu> alan_g: Yeah wily mesa is broken with lots of blackness today (https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1504387)
<ubot5`> Ubuntu bug 1504387 in mesa (Ubuntu) "[regression] Software client windows appear all-black on wily desktop" [Critical,Triaged]
<zzarr> hello! do anyone know how long nVidia have come with development of a MIR driver?
<anpok_> the have come...
<anpok_> a long way..
<anpok_> hm  why do we provide ProgramOption to the probe function of graphics platforms instead of just options::Option?
<Saviq> hey folks, in silo 22 (multimonitor), when disconnecting an external screen, mir aborts with http://pastebin.ubuntu.com/12723726/
<Saviq> is that known? anything more I could provide to help fix?
<greyback_> Saviq: AlbertA has done a lot of work improving mir's handling of plug/unplug in mir 0.17 - I did a test a week ago and it was much more stable
<Saviq> greyback_, ok, so not worth investigating
<greyback_> Saviq: nope
<greyback_> bschaefer: you have a branch of SDL2 with mir support somewhere, no?
<greyback_> could you please share?
<bschaefer> greyback_, yeah
<bschaefer> greyback_, https://code.launchpad.net/~brandontschaefer/+junk/SDL2-new-mir-ABI
<greyback_> bschaefer: great, thanks
<bschaefer> np! Let me know if it works :) should be up to 0.16
<alan_g> greyback_: did you happen to discover why CI hates https://code.launchpad.net/~alan-griffiths/qtmir/test-harness-for-MirWindowManager/+merge/267369?
<greyback_> alan_g: no, is mystery to me still
<alan_g> np. I'll make a note to look again on Monday
 * kdub wonders how qtmir learns of a display off event
#ubuntu-mir 2016-10-10
<alan_g> greyback: happy yet? https://code.launchpad.net/~alan-griffiths/miral/encapsulate-mir-PromptSession/+merge/307823
<greyback> alan_g: there is still style mismatch in promptsessionmanager.cpp
<greyback> and its header
 * alan_g tries again
<greyback> alan_g: can you repro this bug 1631958 ?
<ubot5> bug 1631958 in MirAL "Crash after closing Qt dialog" [Undecided,New] https://launchpad.net/bugs/1631958
<alan_g> greyback: will check shortly
<greyback> thanks
<alan_g> looking at the line of code in the backtrace it seems that there's a recursive parent-child relationship. What fun!
<alan_g> greyback: confirmed
<greyback> alan_g: thanks. Been a while since i've seen a stack overflow :)
<alan_g> greyback: I want to add a test before proposing, but you can preview: lp:~alan-griffiths/miral/fix-1631958
<greyback> on it
<greyback> alan_g: yep that fixes it
<greyback> it is made clear anywhere exactly what events are passed through the mir_surface_event_callback ?
<greyback> ever mind
<greyback> never
<alan_g> greyback: MP'd
<greyback> ack
#ubuntu-mir 2016-10-11
<alan_g> anpok_: is there a good way to find the default keymap? Do I have to parse /etc/default/keyboard?
<anpok_> alan_g: that file might not be there .. but yes
<anpok_> other option might be to have a udev property
<anpok_> but we dont expose enough information to get the syspath of a device - and from there to udev
<greyback> alan_g: hey, I'm trying to get tooltips working with qtubuntu and miral. I appear to be hitting an api change, where mir0.25 has a placement_hint attribute, but 0.24 (I'm using) does not. Miral with mir 0.24 doesn't place the tooltip correctly at all as a result
<alan_g> anpok_: thanks. I think I'll avoid that.
<greyback> suggest I wait for mir 0.25?
<alan_g> greyback: it should look the same to WM, but prior to 0.25 there was poor client-side support.
<alan_g> greyback: Gotta go to lunch now, will try to help when I'm back
<greyback> alan_g: ack
<greyback> I'll log a bug with what I'm doing
<greyback> just to get the info in one place
<greyback> alan_g: bug 1632325 shows what I get
<ubot5> bug 1632325 in MirAL "tooltips positioned wrong with mir0.24" [Undecided,New] https://launchpad.net/bugs/1632325
<alan_g> greyback: ack
<alan_g> greyback: try using mir_connection_create_spec_for_tip()
<greyback> alan_g: that also arrived in mir 0.25, no?
 * alan_g looks
<greyback> I don't have that with my mir0.24
<alan_g> Ack
<alan_g> OK, I suspect mir_connection_create_spec_for_tooltip() isn't joined up right.
<alan_g> Next on my list
<greyback> thanks
<alan_g> anpok_: Could you sanity check? https://code.launchpad.net/~alan-griffiths/miral/Keymap/+merge/308121
<anpok_> yup looks sane
<alan_g> anpok_: thanks
<alan_g> greyback: https://code.launchpad.net/~alan-griffiths/miral/fix-1632325/+merge/308127
<greyback> ack
<greyback> alan_g: seems to do the job, I suspect qtubuntu needs more work to move the tooltip when it is reused
<alan_g> greyback: it just needs to apply a spec with the updated position
<greyback> yep
<greyback> I see that code is missing
#ubuntu-mir 2016-10-12
<alan_g> greyback: I was wondering about doing another miral release. Do you think we're ready? If so, should it be a pure bugfix cherry-pick (0.2.1) or what we have on trunk (0.3.0 with the new ABIs)?
<greyback> alan_g: there are a couple of ABI breaking changes qtmir needs, I think trunk is more suitable
<alan_g> greyback: ABI isn't *breaking*!!! Just additions.
<greyback> err, yes, ABI changes, sorry bad phrasing
<alan_g> ;)
 * alan_g is a bit over-sensitive as not breaking ABI was (and is) the original point of miral
<alan_g> greyback: any thoughts on the active reviews?
<greyback> alan_g: not yet, on my list for after lunch
<alan_g> np. will leave them for you
<greyback> alan_g: can you do a quick sanity check for me. In the mir client api, is there an api to modify an existing MirSurfaceSpec to adjust the surface position (aka edit rect the surface should attach to)
<greyback> instead the only way I see to do that is to create a new spec with mir_connection_create_spec_for_{menu,tip}
<alan_g> 0.25
<greyback> bah
<greyback> release it already! :)
<alan_g> But creating a new spec works
<alan_g> that's what anpok did in gtk-mir
<greyback> it does, it's just a bit more work (have to remember parent & pixelformat)
<greyback> I mir_surface_spec_set_placement has appeared
 * alan_g doesn't like how long it takes to release mir functionality
<alan_g> greyback: would you cast a proofreading eye over this? https://code.launchpad.net/~alan-griffiths/miral/changelog-0.3.0/+merge/308245
<greyback> ok
<greyback> alan_g: looks fine
<alan_g> thanks
<greyback> alan_g: quickie I missed: https://code.launchpad.net/~gerboland/miral/fix-miral-qt-ftbfs/+merge/308273
<alan_g> greyback: Approved
<greyback> thanks
#ubuntu-mir 2016-10-13
<greyback> alan_g: are you aware of a bug like this lp:1633052
 * alan_g looks
<alan_g> greyback: I was not aware of that
<greyback> far from critical anyway
 * alan_g will try to investigate this afternoon
<alan_g> greyback: I've not been able to reproduce (yet). Your 0.25 compatibility code is wrong. (See comments.) Going to try with Mir-0.24.0 next.
<alan_g> greyback: https://code.launchpad.net/~alan-griffiths/miral/fix-1633052/+merge/308397
<greyback> alan_g: that again? :)
<alan_g> Mir stupidly has two structures to specify surfaces - one for create, one for modify
<greyback> so I see. That's unfortunate
<alan_g> I only fixed the "create" version and was too stupid to check "modify"
<alan_g> It probably all comes back to trying not to break existing APIs
<greyback> *nod*
<alan_g> BTW your code is wrong https://bugs.launchpad.net/miral/+bug/1633052/comments/3
<ubot5> Ubuntu bug 1633052 in MirAL "Tip surfaces not being repositioned on client request" [Medium,In progress]
<greyback> alan_g: yep, I've seen that
<greyback> thanks
<greyback> working on testing it with trunk mir, just to make sure
<alan_g> Cool, I won't bother to do that
<alan_g> If you're finding stuff like this then there must be a lot else working OK?
<greyback> alan_g: well there's little funny things I cannot reliably reproduce. Sometimes when a surface is destroyed, it doesn't trigger a redraw to show the surface is gone
<greyback> but making a testcase for it, I can't reproduce
<greyback> I'm also seeing the way Qt does menus does make miral decide teh focused surface strangely, but Qt can jut work with it
<alan_g> greyback: I've seen that occasionally with Xmir - but wasn't sure (yet) which was to blame.
<greyback> in general, it's working well. Some crashiness when running on X, so am focusing more on actual hardware
<greyback> I'm still getting drawing bugs with Qt, which I need to sort out
#ubuntu-mir 2016-10-15
<wam> Hi, I'm trying out mir/unity8 on a convertible. Looks good so far, but I have an inverted x-axis on the touchscreen and would like 1.5 pixels per pixel due to hidpi. I'm unable to find anything on google about mir and such things. Any hints would be welcome!
#ubuntu-mir 2017-10-09
<jsgrant_> What is the last version of Mir, before it started to transition to (as I understand it) somefactor of 'just another compositor' for Wayland?
<RAOF> jsgrant_: Mir 1.0 is about to be released.
<RAOF> But what, specifically, do you want?
<RAOF> Because Mir has been able to present a Wayland socket for quite some time (I believe my branch guess back to 2015?)
<RAOF> And Mir has always been designed to support multiple client frontends, right back to the time when there was a Binder frontend.
<jsgrant_> RAOF: Ah, so this is a secondary function? The way I've heard people phrasing this -- is that it was being wholesale rebranded/shifted as a wayland-compositor.
<jsgrant_> This was Reddit ... so take that for what it's worth. :^P
<RAOF> We'll probably drop our own client protocol sometime in the distant future ð
<RAOF> And we'll be unlikely to add much to it - it's much less work to use the existing Wayland backends that toolkits, EGL, Vulkan, Firefox, etc have.
<RAOF> So now that there aren't as many people working on it, focusing on the server bit is a more valuable use of time.
<RAOF> Also, now that we don't have a requirement for convergence the fact that the existing Wayland window manager protocols aren't suitable for that is less of an issue ð
 * jsgrant_ is academically interested in Mir; Not too sure if he'll end up using it for anything sans that -- kinda sad I can't find even a toy tiling-wm implemented on it. 
<jsgrant_> RAOF: Also sad, about the convergence bit.
<RAOF> jsgrant_: there's a toy tiling wm in the demo server!
<jsgrant_> :^D
 * jsgrant_ pokes around.
<RAOF> miral-shell is the relevant bit.
<RAOF> (in trunk, which is soon to be 1.0)
<jsgrant_> Yeah, just found http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/examples/miral-shell/tiling_window_manager.cpp :^)
<jsgrant_> Not too chunky-either.
#ubuntu-mir 2017-10-10
<jsgrant_> Ubuntu the only 'supported' platform right-now, I'm assuming?
<RAOF> There are Fedora packages now, too!
<RAOF> Not in the main archive, but in a Fedora developer's copr
<RAOF> (we need to fix a few things so that he can run the tests as a part of package build)
<jsgrant_> Ha, I just literally (past two-days (counting today)) switched back to Fedora on all-but-one (NixOS Dev/Toy) Box. :^)
<RAOF> You won't get EGL support for clients using libmirclient on Fedora, but Wayland clients should work fine.
<jsgrant_> Is it anything specific to Fedora, or is it an implementation thing at this point?
<RAOF> It's that Fedora doesn't have the Mesa patches adding the Mir EGL platform.
<jsgrant_> Is it Ngompa's copr repo?
<RAOF> Yup
 * jsgrant_ will add to all main boxes-- for at the very least a reminder.
<jsgrant_> Ah, no F27 build-target yet. :^)
<alan_g> RAOF @"You won't get EGL support for clients using libmirclient on Fedora, but Wayland clients should work fine." there's the problem Neal found with some example servers using an EGL spinner.
