[07:36] <tsdgeos> lol our approved branches to land is really piling up
[07:44] <Cimi> tsdgeos, you can test silo 17!
[07:54] <zbenjamin> Saviq: tell me that it has landed ;)
[07:54] <tsdgeos> Cimi: i centainly can, what needs testing?
[07:55] <Saviq> zbenjamin, you should check your branch's status ;)
[07:55] <Cimi> tsdgeos, seeing if they don't kill each other
[07:57] <tsdgeos> will give it a try, need to reflash the nexus4 first, it's a bit old-image atm
[08:05] <zbenjamin> Saviq: ok
[08:11] <Cimi> Saviq, pushed the comment in scope settings
[08:12] <Saviq> Cimi, tx
[08:13] <Saviq> zbenjamin, url-d unfrozen (we're in beta1 freeze)
[08:13] <zbenjamin> Saviq: ok
[08:16] <Saviq> Cimi, '110	+ pageHeaderLoader.item.resetSearch();' still wrong indent, you really don't want to fix that do you?
[08:19] <Saviq> Cimi, otherwise ACK
[08:21] <tsdgeos> is the scope overview broken on trunk?
[08:21] <tsdgeos> or did i just break it in my branch
[08:21] <tsdgeos> ?
[08:21]  * tsdgeos compiles
[08:22] <tsdgeos> few, just broken on my branch
[08:23] <tsdgeos> Wellark: limitedBandwith means basically 3G vs wifi, right?
[08:24] <tsdgeos> paulliu: can you have a look at https://code.launchpad.net/~aacid/unity8/removeUnusedHasAttributes/+merge/232100 ?
[08:24] <tsdgeos> paulliu: no hurry
[08:24] <Cimi> Saviq, I can't work easily with inline diff
[08:24] <Cimi> Saviq, you miss things
[08:24] <Cimi> when you have such long diff
[08:25] <Saviq> Cimi, Ctrl+F, $reviewer_name
[08:25] <Saviq> Cimi, you actually fixed it already in a revision in the mean time, but then you reverted the fix
[08:25] <Cimi> Saviq, pushed
[08:25] <Cimi> Saviq, doesn't work if you use mail account
[08:26] <Saviq> Cimi, on launchpad, not in email
[08:26] <Cimi> Saviq, yup, I was using email
[08:26] <Saviq> Cimi, yeah, inline + email are totally bad, no comment history, no way to mark a few lines etc.
[08:27] <Cimi> Saviq, I will use lp next time - anyway, ficxed
[08:27] <Cimi> fixed
[08:27] <Saviq> tsdgeos, I think we should consider it a 1:1, but obviously that will probably be the case almost always
[08:27] <Saviq> Cimi, also, if you replied to inline comments, it'd be easier ;)
[08:28] <Saviq> Cimi, did you file a bug on ItemSelector that you can't control foreground color?
[08:29] <Cimi> Saviq, I think you can if you redo the delegate
[08:29] <Saviq> Cimi, it's not just about the delegate, it's the label too
[08:29] <Saviq> Cimi, is it not?
[08:30] <Saviq> Cimi, but anyway, it shouldn't be needed to redo the delegate just to change colours
[08:31] <tsdgeos> Saviq: uhhhm?=
[08:31] <tsdgeos> ¿?
[08:31] <tsdgeos> didn't get that sentence :D
[08:31] <Saviq> tsdgeos, I mean that we should not assume that it's 3G vs. WiFi
[08:32] <Saviq> tsdgeos, but most often that's what it's going to be
[08:32] <tsdgeos> Saviq: ok
[08:37] <Wellark> tsdgeos: pertty much yes
[08:37] <Saviq> tsdgeos, btw noticed recently that you can get to overview from a tmp scope preview, we should have a look
[08:39] <tsdgeos> Saviq: :/
[08:39] <tsdgeos> Saviq: i'll quick prepare a branch
[08:40] <Saviq> tsdgeos, btw, just got https://docs.google.com/a/canonical.com/file/d/0B32jwBcbaPlobF9fc1JXN2ExcUk/edit
[08:40] <Saviq> tsdgeos, but have no idea how that could be our fault...
[08:40] <tsdgeos> lol
[08:41] <tsdgeos> that's weird
[08:41] <tsdgeos> is that a recent image
[08:41] <Saviq> tsdgeos, happened when going to and back from store
[08:41] <tsdgeos> ?
[08:41] <Saviq> tsdgeos, just flashed
[08:41] <Saviq> tsdgeos, resolves itself after I scroll up a bit
[08:41] <tsdgeos> :/
[08:41] <Saviq> tsdgeos, but TBH I'm not even sure why the view scrolls at all when going to store and back
[08:42] <Saviq> tsdgeos, might be some of our reset logic
[08:42] <Saviq> which we should get rid of
[08:45] <tsdgeos> yeah...
[09:01] <Saviq> Cimi, ACK, your turn
[09:04] <Saviq> tsdgeos, we can't *fix* QIcon without amending the spec
[09:04] <tsdgeos> Saviq: well, he's doing lots of stuff other than cater for non square icons
[09:04] <Saviq> tsdgeos, larsu's implementation makes assumption about "size" that the spec does not allow
[09:05] <tsdgeos> but ok
[09:05] <Saviq> tsdgeos, sure, the breadth-first thing could be fixed in QIcon, but we still couldn't use ti
[09:05] <Saviq> it
[09:06] <tsdgeos> it's not even using QICon::themeSearchPaths()
[09:06] <tsdgeos> but i guess once decided you want to go full custom is not that it matters at all
[09:15] <larsu> tsdgeos: themeSearchPaths() == XDG_DATA_DIRS, no?
[09:15] <larsu> ah, I guess you can add custom directories
[09:16] <larsu> I don't know how that would ever be useful, but I can change it if we need it
[09:16] <tsdgeos> larsu: and you probably  want to use qgetenv
[09:18] <larsu> oh interesting. What does it do?
[09:18] <larsu> ah, returns a byte array instead of a char*
[09:18] <larsu> fair enough
[09:22] <larsu> the branch also fixes bug #1349769 (but that could also be fixed upstream obviously)
[09:59] <Saviq> Cimi, you there?
[10:01] <Cimi> Saviq, yup
[10:01] <Cimi> Saviq, I am re-reviewing alt nav
[10:01] <Cimi> Saviq, tested on phone seems fine
[10:01] <Cimi> I used silo 017
[10:03] <Cimi> Saviq, shall we set sourcesize for navigation shadow image
[10:03] <Cimi> ?
[10:03] <Saviq> Cimi, why?
[10:03] <Saviq> Cimi, we own that asset
[10:03] <Saviq> Cimi, it will be scaled according to the @
[10:04] <Cimi> ok
[10:10] <Cimi> Saviq, when you set color with "color:///f5f5f5" do we need the # or not?
[10:11] <Cimi> it's a new notation to me
[10:11] <Cimi> I think we need the # here
[10:14] <Saviq> Cimi, we do
[10:14] <Cimi> Saviq, so add it :)
[10:14] <Saviq> Cimi, where?
[10:15] <Cimi> Saviq, DashNavigation.qml
[10:15] <Saviq> Cimi, found
[10:15] <Saviq> Cimi, pushed
[10:16] <Saviq> push*ing*
[10:16] <Saviq> oh LP died
[10:16] <Cimi> Saviq, another issue
[10:17] <Cimi> the list under the navigation list need elide
[10:17] <Cimi> with amazon you can see super long text
[10:18] <Cimi> *under the navigation buttons
[10:20] <Cimi> Saviq, http://imgur.com/5TVV12Q.png
[10:20] <Saviq> Cimi, italians!
[10:21] <Saviq> Cimi, lemme
[10:21] <Saviq> LP is busted damn
[10:21] <tsdgeos> yep
[10:21] <Cimi> Saviq, guess what it could be in german then :D
[10:21] <tsdgeos> i can't push eitehr
[10:22] <Cimi> Saviq, another issue
[10:22] <Cimi> Saviq, from that menu, try scrolling up touching the area greyed out
[10:22] <Cimi> it jumps few pixels then you see the shadow stopping
[10:23] <tsdgeos> Saviq: i could push now
[10:24] <Cimi> Saviq, http://s14.postimg.org/yq85b5167/amazon_scroll.png
[10:26] <Saviq> Cimi, huh, that should've been fixed
[10:26] <Cimi> Saviq, I am testing silo of midnight last night
[10:26] <Cimi> Saviq, did you fix overnight?
[10:26] <Saviq> Cimi, no I mean it should've been fixed way back
[10:26] <Cimi> it is not here, try
[10:27] <Cimi> unless something got messed up with today image update
[10:27] <Saviq> Cimi, what did you drag by?
[10:27] <Cimi> Saviq, I can drag from the shadow
[10:27] <Saviq> Cimi, ah
[10:27] <Cimi> Saviq, in any scope
[10:28] <Saviq> Cimi, ok, again not a bug with my branch but will fix
[10:30] <Saviq> Cimi, fixed
[10:30] <Cimi> Saviq, how did u fix it?
[10:30] <Cimi> Saviq, blocking inputs?
[10:31] <Cimi> I was wondering what we want to do in this case
[10:31] <Cimi> if allowing scroll or not
[10:33] <Saviq> Cimi, close list on touch
[10:33] <Saviq> Cimi, we had onClicked, changed to onPressed
[10:41] <anpok_> is there a package with debug symbols for qtquick?
[10:41] <greyback> anpok_: qtdeclarative5-dbg
[10:43] <anpok_> thx
[10:48] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/dashOverviewFromTempScopePreview/+merge/232378
[10:49] <Saviq> tsdgeos, tx
[10:51] <Saviq> aand LP down again
[11:02] <Saviq> Cimi, btw, you can try the alt nav out on desktop no problem
[11:03] <Saviq> Cimi, everything needed is already deployed / in distro
[11:03] <Cimi> Saviq, ok
[11:04] <Cimi> Saviq, still I can't pull bzr
[11:04] <Cimi> Saviq, but I suppose the branch is fine
[11:04] <Cimi> cannot see more bugs atm
[11:05] <Cimi> and we want this in
[11:05] <Saviq> Cimi, yeah, would be good, is the last branch blocking silo 17
[11:05] <Saviq> Cimi, but yeah, we need LP to work, can't build without that anyway
[11:05] <Cimi> ok so I'll approve after lunch
[11:06] <anpok_> hm qt quick destroys the egl context when not exposed?
[11:07] <greyback> anpok_: if told it is hidden, yes. But we're not doing that, we just tell it it is occluded
[11:07] <greyback> so it holds onto the egl context, but stops rendering
[11:08] <anpok_> there seems to be another bug in mesa.. on unity8 dash startup it receives an expose event and goes to handleExposure(isEx=false..) and that asserts in the OpenGLContext destructor on eglDestroyContext(..)==true
[11:09] <anpok_> ah so it shouldnt destroy that context?
[11:09] <anpok_> ok then maybe the failure is earlier
[11:13] <greyback> anpok_: this is on startup? In that case, I'm not too familiar with things.
[11:14] <greyback> anpok_: if I were you, I'd compile qtubuntu with debugging on, it might help
[11:15] <greyback> qmake "QMAKE_CXX=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK_SHLIB=arm-linux-gnueabihf-g++-4.9" CONFIG+=debug
[11:15] <tsdgeos> Saviq: pushing still broken, right?
[11:15] <greyback> is here
[11:16] <Saviq> tsdgeos, yes
[11:24] <facundobatista> Holas
[11:27] <Saviq> tsdgeos, managed to push, it seems real slow though
[11:27] <tsdgeos> ok, will keep trying
[11:28] <Saviq> hey facundobatista
[11:28] <facundobatista> hola Saviq :)
[11:30] <Saviq> /food
[11:51] <cwayne> Saviq: any chance of 17 landing today?
[12:34] <Saviq> cwayne, oh sry didn't reply
[12:35] <Saviq> cwayne, yeah, just one last branch needs ACKing
[12:35] <Saviq> cwayne, and we've had launchpad crap out on us intermittently
[12:35] <Saviq> which slowed things down
[12:35] <cwayne> ugh launchpad sucks sometimes
[12:37] <Saviq> cwayne, yeah, there was a real downtime today, ssh on the launchpad branch servers died
[12:37] <cwayne> oh damn
[12:38] <Saviq> cwayne, fortunately it's better now
[12:49] <cwayne> Saviq: cool beans.  is silo 17gonna be targeted against -rtm too?
[12:49] <Saviq> cwayne, yeah, we don't deal with rtm vs. non-rtm, everything goes to utopic then to rtm just after
[12:51] <cwayne> Saviq: ah alright, cool
[12:52] <cwayne> not a big fan of this rtm fork myself
[12:54] <Saviq> cwayne, well, there's reasons for it, we *might* have jumped the gun a bit on when we did it
[12:54] <Saviq> cwayne, but we wanted to protect ourselves against standard distro churn
[12:54] <cwayne> right, i know we need it
[12:54] <Saviq> cwayne, with the most recent approach (packages just get srccopied) from utopic to rtm
[12:54] <Saviq> cwayne, it's minimal overhead on dev
[12:55] <cwayne> yeah, that part is nice
[12:55] <Saviq> cwayne, the real overhead is on QA, as they are supposed to ACK all the rtm silos
[13:05] <mterry> kgunn, hello!  So I'm at the point where I don't have many critical bugs assigned to me, and I am implementing the latest visuals from Design.  At what point should we stop making UI changes?  I mean, we already blew by the UI freeze a while ago.  But that seemed more advisory than real.  Is there a real UI freeze date?
[13:06] <Saviq> mterry, there is none, really
[13:06] <kgunn> mterry: :D
[13:06]  * Saviq finds bugs for mterry :)
[13:06] <mterry> Saviq, no!  I've had these designs on my plate long enough, got to get rid of them
[13:06] <Saviq> mterry, ok ;)
[13:06] <kgunn> mterry: one thing that would be useful imho, is potentially generating "engineering ugly" version of music controls on greeter
[13:07] <kgunn> ....or are we bringing indicators back ?
[13:07] <Saviq> kgunn, http://nooooooooooooooo.com/
[13:07] <mterry> kgunn, we're bringing indicators back
[13:07] <Saviq> yes
[13:07] <mterry> kgunn, MPs all filed
[13:07]  * kgunn succeeded in scaring Saviq for the day....check
[13:07] <Saviq> *crash*
[13:08] <Saviq> ah no, just input got confused ?¿
[13:08] <mterry> kgunn, so we don't care about UI /string changes for the RTM side...  But distro has its own dates for those that we presumably should obey, eh?
[13:08] <kgunn> hey its early...i couldn't remember
[13:08] <kgunn> mterry: yeah...that's a good question
[13:09] <Saviq> mterry, will we even hit distro UXF before RTM?
[13:09] <mterry> Saviq, I'm not sure.  I haven't looked at a calendar recently
[13:09] <mterry> kgunn, is there an RTM google calendar I can add to my calendar?
[13:09] <Saviq> Sep 11th
[13:09] <Saviq> is UIF
[13:10] <Saviq> Sep 18th is doc freeze
[13:10] <Saviq> so in theory we're going past this
[13:11] <Saviq> mterry, but as before, I imagine, we can get a blanket exception
[13:11] <Saviq> mterry, or, we could start only releasing into rtm once devel is frozen...
[13:12] <seb128> I though rtm was design frozen in july?
[13:12] <kgunn> yeah, i'm assuming exception
[13:12] <Saviq> by devel I mean utopic
[13:12] <Saviq> seb128, lol ;)
[13:12] <seb128> Saviq, not joking...
[13:12] <kgunn> seb128: tell that to design
[13:12] <seb128> we are playing whack a mole on translations if we keep changing strings
[13:13] <seb128> especially for bits like the first start wizard
[13:13] <seb128> (which is mterry is sending redesign for)
[13:35] <dandrader> greyback, https://code.launchpad.net/~dandrader/qtmir/missingTouchEnd-lp1295623/+merge/232410
[13:35] <dandrader> greyback, once you have some time for reviews
[13:36] <greyback> dandrader: back at you then :) https://code.launchpad.net/~gerboland/platform-api/exposeOrientation/+merge/232250
[13:36] <greyback> dandrader: https://code.launchpad.net/~gerboland/qtubuntu/exposeOrientation/+merge/232252
[13:36] <dandrader> lovely
[13:37] <greyback> dandrader: "should fix" ? - have you no way to be sure?
[13:37] <dandrader> greyback, there are no sure steps to reproduce the bug. I've never seen it myself. All I know is what makes Qt behave like that
[13:38] <greyback> dandrader: yuk, one of those bug
[13:38] <dandrader> greyback, so I was able to artificially get into the situation that makes qt stop generating mouse events
[13:39] <dandrader> greyback, and that MP ensures that we don't make Qt get into such a state
[13:39] <greyback> dandrader: ok
[13:40] <greyback> dandrader: you have a test here which can repro that artificial situation?
[13:40] <dandrader> oh, forgot the MP checklist
[13:40] <dandrader> greyback, I made a unit test
[13:40] <greyback> dandrader: cool. I can at least run that to see the issue, and then apply your change to see it being fixed
[13:40] <dandrader> greyback, but I also have a toy app to prove it
[13:40] <greyback> do share :)
[13:41] <dandrader> greyback, https://code.launchpad.net/~dandrader/+junk/touchToMouse
[13:41] <dandrader> It captures raw mouse events and send synthesized touch events to the QQuickWindow out of them.
[13:41] <dandrader> - Left button mouse clicks are translated to touch taps.
[13:41] <dandrader> - Middle button mouse clicks are translated to touch taps as well with the difference that it omits the corresponding TouchEnd (thus emulating the bogus situation).
[13:42] <dandrader> greyback, Left-click all rectangles and see that they happily blink. Then middle-click once a MouseArea. From that point onwards no mouse area will *ever* react to any left-click anymore. They get stuck forever. The touch area though will continue working normally.
[13:42] <greyback> dandrader: do add that to the MR in a comment, just so it is all combined
[13:42] <dandrader> greyback, that toy app just proves that the Qt issue exists
[13:42] <dandrader> greyback, ok
[13:42] <greyback> dandrader: sure, but every bit of info helps IMO
[13:51] <Saviq> Cimi, you still lunching?
[13:53] <tsdgeos> today was burger day was it?
[13:53] <tsdgeos> maybe he died of so much fat :D
[13:56] <anpok> mterry: hm any idea why greeter does not like my password
[13:56] <mterry> anpok, in unity8?  On desktop or phone?
[13:57] <anpok> desktop unity8 greeter
[13:58] <anpok> strange thing - it worked this morning..
[13:58] <anpok> are there logs to look for?
[13:59] <anpok> i actually wanted to just debug another mir startup issue in unity-dash
[13:59] <anpok> can i disable it?
[14:03] <Saviq> tsdgeos, makes sense ;)
[14:05] <Saviq> anpok, you can `passwd -d` your password, it will let you in then ;)
[14:06] <anpok> :)
[14:07] <anpok> just tried my wifes account.. it seemed to accept it once..
[14:07] <anpok> then i mistyped it .. and it denied entry
[14:07] <anpok> now it denies it everytime even when i type it properly
[14:08] <tsdgeos> >>> qmltestrunner.PageHeaderLabelTest::test_popover  has started failing in CI from noweere
[14:08] <Cimi> Saviq, I reviewed
[14:09] <Saviq> tsdgeos, indeed
[14:09] <Saviq> tsdgeos, but not locally, yay
[14:09] <greyback> dandrader: since you're compensating for the fact that Mir's/android's input system doesn't always generate touch releases, I think you should log a Mir bug for it and quote it in the MP
[14:09] <tsdgeos> Saviq: and testDash crashing :S
[14:09] <Saviq> tsdgeos, ran it like 30mins in a loop
[14:10] <tsdgeos> Saviq: dash or popup?
[14:10] <dandrader> greyback, or maybe Mir/android-input is doing the right thing but qtmir was messing up
[14:10] <Saviq> tsdgeos, popup
[14:10] <dandrader> greyback, like considering hover events
[14:10] <dandrader> greyback, as touch presses and releases in an unpredictable manner
[14:11] <greyback> dandrader: would be good to be clear on whose fault it really is though.
[14:11] <greyback> dandrader: touch events have hover?
[14:11] <dandrader> greyback, android-input has
[14:11] <greyback> dandrader: is that not for mouse events?
[14:12] <dandrader> greyback, happens a lot in krillin for instance
[14:12] <Saviq> Cimi, pushed
[14:12] <greyback> dandrader: weird. They represent what exactly? finger stationary on the display?
[14:13] <dandrader> greyback, as I understand it, they represent a finger hovering over the screen. depends on hw capability
[14:13] <dandrader> greyback, some touchscreens can detect when a finger is really close but not really touching it
[14:14] <greyback> dandrader: ah that. Don't think we want to enable that right now
[14:14] <dandrader> greyback, others draw a line in the pressure value, to separate hovering from touching
[14:14] <greyback> I see
[14:14] <tsdgeos> Saviq: running in valgrind, now it's failing (in different places though), let me fix those
[14:15] <dandrader> greyback, so for a finger leaving the screen you can get: touch_release,hover_enter,hover_exit
[14:15] <Saviq> tsdgeos, tx
[14:19] <Cimi> Saviq, ap keeps failing on your branch
[14:19] <Cimi> Saviq, but looks unrelated
[14:19] <Saviq> Cimi, not any more, it failed before due to launchpad breakage
[14:19] <Saviq> Cimi, another run is going
[14:24] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/pageHeaderLabelTestValgrind/+merge/232420
[14:25] <tsdgeos> let's see what CI says
[14:28] <Saviq> tsdgeos, verify(recentSearches, "Could not find the popover")?
[14:28] <tsdgeos> Saviq: you got that?
[14:28] <Saviq> tsdgeos, no, can you add that?
[14:28] <Saviq> tsdgeos, we should have a verify per waitForRendering, otherwise *CRASH*
[14:28] <tsdgeos> well
[14:28] <tsdgeos> a crash is good :D
[14:29] <tsdgeos> i mean you'll see something bad happened
[14:29] <Saviq> a faling test is better ;)
[14:29] <tsdgeos> but sure, i'll add it
[14:29] <tsdgeos> added
[14:33] <Saviq> tsdgeos, ?
[14:33] <tsdgeos> ?
[14:33] <Saviq> tsdgeos, there's a trailing ?
[14:33] <Saviq> tsdgeos, after the verify
[14:36] <tsdgeos> lol
[14:51] <MacSlow> dandrader, could you look over https://code.launchpad.net/~macslow/unity-notifications/fix-1348092/+merge/228252 again, mentioned issues were addressed.
[15:02] <dandrader> MacSlow, done
[15:03] <MacSlow> dandrader, great thx!
[15:13] <tsdgeos> Cimi: why do i need to rebase on such branch
[15:13] <tsdgeos> and what is the exact name you want me to rebase on
[15:18] <Saviq> MacSlow, need to pull https://code.launchpad.net/~macslow/unity8/fix-1348092/+merge/228090 from the landing
[15:19] <Saviq> MacSlow, getting https://docs.google.com/a/canonical.com/file/d/0B32jwBcbaPlobmp6eU45aF9mNUE/edit during sim unlock
[15:21] <MacSlow> Saviq, no :/
[15:21] <Saviq> MacSlow, afraid so
[15:21] <MacSlow> Saviq, what the hell is that white bar at the top
[15:22] <Saviq> MacSlow, that looks like it's the actual notification
[15:22] <Saviq> MacSlow, there's text in it
[15:22] <MacSlow> *sigh*
[15:22] <Saviq> MacSlow, that seems to be the thing that dandrader|lunch reported before with getting a fullscreen dark thing with just some text
[15:22] <Saviq> but just got worse
[15:23] <MacSlow> Saviq, I'll try trunk locally... do we have a bug for that yet?
[15:24] <Saviq> MacSlow, no
[15:24] <Saviq> MacSlow, I just commented on the MP
[15:28] <Saviq> MacSlow, the good news is we might actually be able to fix this properly now
[15:29] <MacSlow> Saviq, I first need to get trunk and my branch "side-by-side" to see how/where this issue got introduced
[15:30] <Saviq> MacSlow, I didn't see it before your branch
[15:31] <MacSlow> Saviq, yeah... just running through examples with unity8 trunk... no issues...
[15:35] <Saviq> Wellark, https://docs.google.com/a/canonical.com/file/d/0B32jwBcbaPlobnpTZ1NmRGc5LVk/edit :|
[15:35] <Saviq> Wellark, anything interesting I can get you, or is that known?
[16:04] <MacSlow> Saviq, kgunn: I'd say filing a bug does not make sense for the "white bar over sim-unlock snap-decision", since it's not really in trunk... I've  a first guess what could be causing it (in my branch).
[16:09] <Saviq> MacSlow, yeah, good
[16:09] <Saviq> MacSlow, I think the error message (title? summary?) ended up in that white notification and it wasn't displayed in the pin screen at all
[16:09] <Saviq> when I typed the wrong SIM
[16:09] <Saviq> PIN
[16:45] <tsdgeos> Saviq: testDash crash :/
[16:46] <tsdgeos> http://paste.ubuntu.com/8160868/
[16:46] <Saviq> yay polishItems
[16:46] <tsdgeos> i've seen this backtrace before
[16:46] <Saviq> yeah
[16:46] <tsdgeos> but it was because lvpwh was removing stuff on polish
[16:46] <tsdgeos> that shout not be happening anymore
[16:47] <tsdgeos> maybe something else is :/
[16:47] <tsdgeos> will have a look at it tomorrow
[16:47]  * tsdgeos waves
[18:45] <Wellark> Saviq: hmm..
[18:46] <Wellark> Saviq: that just looks like fallout from the prematurely enabled UnlockAllModems() in the greeeter
[18:46] <Wellark> Saviq: did you land the revert _everywhere_ ?
[18:49] <Saviq> Wellark, I did land it on that phone (phone's not rtm)
[18:49] <Saviq> Wellark, but in any case it landed in rtm now, too
[19:17] <cwayne> Saviq: so i noticed the silo is for rtm now, so i imagine itll be srccopy'd back to ubuntu then?
[19:37] <plars> Saviq: sorry, got distracted by some other things earlier, but mterry says I should coordinate landing of his MP through you? - https://code.launchpad.net/~mterry/unity8/unlock-via-dbus/+merge/232428 is the MP
[19:38] <mterry> Saviq, oh yeah, this is blocking plars, so I was curious which other unity8 merges we've got going on, if we can land this one faster (once approved of course)
[20:00] <Saviq> mterry, go for it
[20:01] <mterry> Saviq, is any other silo close enough to landing that it's worth rolling it in?
[20:01] <Saviq> mterry, you'll have to coord with kgunn rather than me, I don't have nothing in store right now (you and kgunn have)
[20:01] <mterry> Ah whoops
[20:01] <mterry> kgunn, same questions ^ :)
[20:02] <Saviq> mterry, his just failed to merge
[20:02] <Saviq> mterry, so it's really between you and plars :)
[20:05] <kgunn> mterry: you need that landed ? looks like we can just get a silo for it
[20:05] <kgunn> all on its lonesome
[20:05] <mterry> kgunn, yeah i think plars made a silo
[20:06] <plars> mterry: well, I asked, but there are too many things out there for unity8 so robru is reluctant to make one for this, wanted to see if it could be combined
[20:06] <plars> mterry: otherwise, if it looks like those are a ways off, and it won't cause problems for others, maybe we can jump the line :)
[20:07] <mterry> plars, my silo is close to being landable -- just needs the unity8 branch approved, the other two are
[20:07] <kgunn> plars: mterry ....so silo2 is a ways off, that's just prep for dednick's
[20:07] <mterry> plars, so we either land yours alone or with mine how abouts?  Depending on when the MP approvals hit
[20:08] <plars> mterry: well they're both really yours, I'm just trying to get a feel for the process :) probably easier to just combine it with your other one then if you are comfortable with that. That way we don't have to complicate it even further with more people waiting
[20:34] <mhall119> is there a way to access a scope's config values from it's .ini from within the scope's code?
[21:05] <Saviq> mhall119, its
[21:05] <Saviq> mhall119, might wanna try and grab michi for that