[06:37]  * duflu suspects we'll be landing things by hand again :/
[07:02] <RAOF> Wow. I think I may have found a case where g++'s error message is better than clang's.
[07:05] <RAOF> Huh. Tell a lie.
[07:08] <RAOF> Bah!
[07:08] <RAOF> C++11, why does “GLContext(GLContext const&) = delete;” delete all subclass' move constructors?
[08:00] <RAOF> Ah, ok.
[08:00] <RAOF> So, nested worked on android by accident *anyway*.
[08:03] <RAOF> (It selects an EGLConfig supporting EGL_WINDOW_BIT and then proceeds to create a pbuffer surface with that config)
[08:26] <RAOF> Man, we have *far* too many EGLContext wrappers.
[08:30] <duflu> Code duplication... to be sure to be sure
[08:40] <alf_> RAOF: kdub wanted to deduplicate, but it seems you got there first
[08:41] <RAOF> Yup.
[09:16] <anpok> duflu: i meant the methods of DefaultServerConfiguation are spread accross multiple cpp files
[09:17] <duflu> anpok: It's not a class or a method. I think you're confusing default_configuration with DefaultServerConfiguration. They're unrelated
[09:20] <anpok> oh .. too many files named default_configuration.cpp
[09:22] <alf_> anpok: That's so that we can keep implementation details internal to the components that provide them. Each component implements part of the DefaultServerConfiguration in the default_configuration.cpp file located in its source directory.
[09:33] <alan_g> duflu: did we figure out what causes the CI test failures?
[09:33] <duflu> alan_g: No, haven't looked very deeply. They commenced failing again as soon as I said they were passing
[09:34] <duflu> alan_g: Just got a full pass a second ago!
[09:34] <alan_g> There's a lesson in that! ;)
[09:34] <duflu> This is way too erratic and unreliable
[09:34] <alan_g> +10
[09:35] <tvoss> didrocks, can you help alan_g and duflu track down the test flakiness?^
[09:50] <didrocks> tvoss: isn't that the CI team role or the QA team one?
[09:51] <didrocks> tvoss: FYI, all known flaky tests are summarized in my last emails
[09:51] <didrocks> if you see more failure, it's either:
[09:51] <didrocks> - working with the other upstreams to get their new revealed flakyness fixed
[09:51] <didrocks> - or fix a real bug
[09:52] <didrocks> (too many bugs are excused as flakyness, where they are flaky behavior in reality)
[09:52] <tvoss> didrocks, fair, just trying to identify a POC
[09:53] <alan_g> didrocks: I was discussing it with ChrisGagnon yesterday - we're getting inconsistent (and not locally reproducible) results on the phone hardware that's just been switched on.
[09:54] <didrocks> alan_g: will be interesting to have all debug infos for the other teams to fix it (can be autopilot, can be the app or can be a real issue)
[09:54] <didrocks> anyway, I think it's QA/CI team that you want
[09:55] <didrocks> to help identifying the cause
[09:56] <alan_g> didrocks: I guess you've been too helpful to tvoss in the past. ;)
[09:57] <didrocks> ahah, no, he still has credits on my help card :p just I think I won't be able to help reliably (especially with all the meetings I'm in)
[09:57] <didrocks> and I think some people need to fulfill and own their role now ;)
[09:58]  * duflu is paranoid and assumes he has not credits left
[09:58] <duflu> Although I don't think we need didrocks help on this issue yet
[10:08] <alan_g> greyback: are you subscribed to mir-devel and the "Shell communication channel: simple, half-assed or fully-arsed?" discussion
[10:08]  * alan_g wonders why his keyboard just switched to US layout
[10:08] <greyback> alan_g: I am. I see your thread, I'll add my 2cents shortly
[10:11] <RAOF> EOD for me.
[10:11] <alan_g> Goodbye RAOF, have a nice evening
[10:15] <tvoss> RAOF, o/
[10:36]  * duflu isn't sure using one's full arse is in fact better than half thereof
[10:36] <duflu> And on that thought, good night
[15:32] <mterry> kgunn, when might we see a new mir drop? (resending, because I think IRC timed out on me)
[15:33] <seb128> mterry, one day you need to get a stable internet connection ;-)
[15:33] <kgunn> mterry: i'd like to say next week
[15:33] <seb128> mterry, or an IRC proxy
[15:33] <mterry> seb128, naw, anything important is logged  :)
[15:33] <seb128> ;-)
[15:33] <mterry> kgunn, :(  ok
[15:34] <kgunn> mterry: we've got wonky integration tests right now on the dev branch that alf is trying to sort thru
[15:34] <kgunn> as soon as those stabilize we can update
[15:34] <kgunn> mterry: is there a feature on dev you really need pulled thru ?
[15:35] <mterry> kgunn, yeah, this is the bug racarr fixed at the sprint, blocking nested mode
[15:35] <mterry> kgunn, I can wait
[15:35] <mterry> kgunn, just wanted to see it land
[15:35] <kgunn> mterry: well...me too
[15:35] <kgunn> mterry:  i was ready to promote it this week...but we started seeing flaky ci
[15:36] <kgunn> mterry: what's bothering me...we've been chasing for a few days...and its nothing easy...we're starting to think stuff like...toolchain deltas or low level arm diff between calxeda vs n4
[15:37] <kgunn> calxeda being the big arm server where the build is done
[15:37] <kgunn> so its native...but not to the same arm core
[15:38] <kgunn> and its the classic...only the auto ci will fail...no local attempts fail
[15:38] <mterry> kgunn, yikes
[17:07] <mterry> greyback, so I've heard that scenegraph will make animating stuff in USC easier.  Is that because I'll be more easily able to use Qt stuff or what?
[17:09] <greyback> mterry: essentially with QML, any application surface will be added to the QML context as an Item. So you can animate it with the usual QML animation system
[17:10] <mterry> greyback, hmm, OK.  And the USC would be able to do the same with session surfaces
[17:10] <greyback> mterry: as an example, see http://bazaar.launchpad.net/~gerboland/+junk/qpa-mirserver/view/head:/qml-demo-shell/qml-demo-shell.qml
[17:10] <greyback> mterry: when a new surface appears, its x coordinate is animated in. When it is destroyed, it scales to zero.
[17:11] <greyback> mterry: yep
[17:11] <greyback> mterry:  to USC, the unity8 user session is just a surface
[17:12] <mterry> greyback, awesome.  I want to play with that.  What is rough ETA for landing?
[17:13] <alan_g> greyback: once you start using hardware overlays that won't be true
[17:14] <greyback> alan_g: sure, once hardware overlays are happening, QML won't be drawing the surface (hardware will), but it will still manage the surface
[17:15] <greyback> mterry: oh January, maybe later. It's in demo condition still. I'm still learning the ins and outs.
[17:15] <alan_g> greyback: usc is in the path to hardware - so the unity8 session becomes a set of surface
[17:17] <greyback> alan_g: sure, but unity8 will decide what surface(s) to be overlaid, send that to USC which will either hardware draw it, or fallback to GL. But that still requires unity8 to manage the surface properties
[17:17] <mterry> greyback, OK, so not baked enough for me to try and use?
[17:18] <greyback> mterry: let me send you some bits and pieces so you can play.
[21:02] <kgunn> racarr: btw, i meant to tell you earlier... mterry was chatting with me yesterday and was indicating that
[21:02] <kgunn> the whole seperate queue for differing events was going to be more critical sooner that later
[21:02] <kgunn> because it wasn't just an annoyance of that stale frame showing on screen-on
[21:04] <kgunn> mterry cmiiaw...but you're effectively  needing to render prior to the screen coming on
[21:05] <kgunn> mterry: and i can't remember...was there some other reason it was going to be critical ?
[21:08] <mterry> kgunn, just that it was an ugly enough regression when splitting the greeter that it would likely block landing
[21:08] <mterry> kgunn, the problem being that Mir freezes the greeter early in its startup, so it can't queue up what the screen will look like for when the screen does come back on
[21:37] <anpok_> hm my connection is getting bad again
[23:07] <kdub> kgunn, ping
[23:07] <kdub> if its not your eod
[23:07] <kgunn> yo
[23:07] <kgunn> kdub:
[23:08] <kdub> i've wandered above mir in looking for that bug...
[23:09] <kgunn> kdub: ok...do we need gerry to pick it up ?
[23:09] <kdub> might be something I want to look at with him
[23:10] <kdub> because I see in unity-mir the sequence coming off of dbus is on, off, on, on
[23:10] <kdub> and the double on causes us problems
[23:10] <kdub> and from powerd's perspective, i just see  on, off, on, off repeated
[23:10] <kdub> i don't know what dbus can or cannot do with message ordering
[23:14] <kgunn> greyback: you really on ?
[23:14] <greyback> kgunn: yes, but only because I forgot to turn off IRC :)
[23:15] <greyback> kgunn: what's up?
[23:15] <kgunn> greyback: oh, sorry...but if you're tempted ^
[23:15] <kgunn> what kdub is looking at....2 "on" msgs
[23:15] <kgunn> causing screen to stay off
[23:15] <kdub> greyback, could dbus send out of order messages?
[23:16] <greyback> kdub: dbus guarantees order of messages
[23:16] <greyback> well as long as there's 1 source & 1 destination
[23:17] <kdub> could it send a message twice?
[23:17] <greyback> kdub: so you get "on off on on" all over dbus? From powerd?
[23:17] <kdub> yes, from powerd
[23:17] <greyback> kdub: nope, never heard of that happening
[23:17] <kdub> but looking through powerd, looks like it should never do that
[23:17] <kdub> i'll keep poking around
[23:18] <greyback> if you've no luck, mail me before you EOD, and I'll take it up in the morning
[23:18] <kgunn> greyback: thank you
[23:19] <kdub> alright, thanks
[23:20] <greyback> kdub: it's strange as I thought this line in unity-mir would prevent it asking Mir for a double-on:
[23:20] <greyback>         if (displayConfigOutput.power_mode != newPowerMode) {
[23:20] <greyback> dbusscreen.cpp:69
[23:21] <kdub> that would stop the blank/unblank, but not the compositor stop/start
[23:34] <greyback> oh
[23:34] <greyback> hmm