[07:09]  * tsdgeos waves
[07:46] <tsdgeos> Saviq: Cimi: r1151 is confusing
[07:47] <tsdgeos> "Fix anchor in PreviewListView.qml. "
[07:47] <tsdgeos> and then all it does is remvoe two properties?
[07:52] <tsdgeos> Saviq: r1170 looks confusing too, i was told explicitely we didn't want previews in overview, did that change?
[07:53] <tsdgeos> also i'm not sure i understadn the change in the tests for r116
[07:53] <tsdgeos> r1169 i mean
[08:04] <Saviq> tsdgeos, lemme look
[08:04] <Saviq> tsdgeos, r1151 just got fixed in a prerequisite branch
[08:05] <Saviq> tsdgeos, or well, a previous merge
[08:06] <Saviq> tsdgeos, in r1140
[08:06] <tsdgeos> ah
[08:06] <Saviq> tsdgeos, it does add a test to verify that fix though ;)
[08:07] <tsdgeos> oki
[08:08] <Saviq> tsdgeos, we don't want previews in overview *except* for scopes
[08:08] <tsdgeos> ok
[08:09] <Saviq> tsdgeos, we might actually enable it completely
[08:10] <tsdgeos> Mirv: Saviq: we may want to get https://codereview.qt-project.org/#/c/91828/
[08:10] <Saviq> tsdgeos, r1169 test changes → they don't hardcode an expected height, but just rely on the real height of the card as laid out
[08:10] <tsdgeos> Saviq: but why not use expected height?
[08:10] <Saviq> tsdgeos, because it might change
[08:11] <Saviq> tsdgeos, as we change designs of the card
[08:11] <tsdgeos> right
[08:11] <tsdgeos> but has the benefit of you having to double check why it changed
[08:11] <tsdgeos> if the height is not expected to change with this particular design chang
[08:11] <tsdgeos> it's a bit like the card creator test
[08:11] <tsdgeos> it's a pita to maintain
[08:12] <tsdgeos> but makes you think if that change was exppected or not
[08:12] <Saviq> tsdgeos, sure
[08:13] <tsdgeos> but not complaining
[08:14] <Saviq> tsdgeos, yeah, that's an approach that other tests in that same suite use, if we decide to change it - fine
[08:23] <Saviq> @unity, so, we actually *can* get green ci now, please start looking closely at any failures and if you don't know where they're coming from, let me know so we can find out
[08:35] <Cimi> yay
[08:38] <Saviq> tsdgeos, so, because I probably won't be able to focus on this here
[08:39] <Saviq> tsdgeos, there's a bunch of segfault failures in our CI (like 3 in alt_nav_support)
[08:39] <Saviq> tsdgeos, could you please have a look at those
[08:39] <tsdgeos> sure, let me finish deleting email and i'll do that
[08:39] <Saviq> tsdgeos, might that even be the thing you linked?
[08:40] <tsdgeos> may be
[08:40] <Saviq> tsdgeos, one thing I realized is that waitForRendering on null is SIGSEGV
[08:42] <tsdgeos> yep
[08:42] <tsdgeos> that's been like that for a while
[08:43] <Saviq> so we should always verify() stuff that might not be there
[08:45] <Cimi> Saviq, can you give me more insights on the in line diff?
[08:48] <Saviq> Cimi, where?
[08:49] <Cimi> starting from the first  readonly property bool settingsShown: item ? item.settingsShown : false - Maybe move up to group?
[08:49] <Cimi> in dashContent
[08:49] <Cimi> that property needs to be in the loader I think
[08:53] <Saviq> Cimi, you should've started with "Saviq, about settings review..."
[08:53] <MacSlow> Saviq, what's needed to run ap-test for unity8 on the desktop currently... I get lots of "CalledProcessError: Command '['/sbin/initctl', 'stop', 'unity8-dash']' returned non-zero exit status 1"
[08:54] <Cimi> Saviq, ECIMIFORGETSCONTEXT
[08:55] <Saviq> MacSlow, install unity8
[08:55] <Saviq> MacSlow, or copy data/unity8-dash.conf to ~/.config/upstart
[08:56] <Saviq> MacSlow, but it's safer to just install it to not have outdated jobs
[08:56] <MacSlow> Saviq, certainly did that
[08:56] <Saviq> MacSlow, `initctl start unity8-dash` and `initctl stop unity8-dash` after?
[08:59] <tsdgeos> run.sh still brken?
[09:00] <tsdgeos> mzanetti: can you still reproduce this ? https://bugs.launchpad.net/unity8/+bug/1348108
[09:01] <tsdgeos> Saviq: is anything for alt_nav missing besides those crashes you mention?
[09:04] <Saviq> tsdgeos, yeah, Cimi's 3D effect on the divider that needs to switch between background and nav background color...
[09:04] <tsdgeos> oh fancy :D
[09:06] <tsdgeos> Saviq: hmmmm, testShell is also segfaulting in https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-utopic/977/? but not shown in there
[09:06] <tsdgeos> fginther`: ↑
[09:07] <Saviq> tsdgeos, yeah, but isn't it segfaulting *after* the test there?
[09:08] <Saviq> tsdgeos, yeah, the test completed
[09:08] <tsdgeos> Saviq: yep, that's still a bug
[09:08] <tsdgeos> something is crashing on shutdown
[09:08] <Saviq> tsdgeos, is that current?
[09:08] <tsdgeos> it's the latest run of alt_nav
[09:09] <Saviq> tsdgeos, http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/1175 should've fixed that
[09:09] <tsdgeos> ok, let me remerge then
[09:09] <Saviq> tsdgeos, waait
[09:09] <Saviq> tsdgeos, it's, header, preview, table, seeLess, alt...
[09:10] <Saviq> tsdgeos, let me remerge in that order
[09:10] <tsdgeos> ok
[09:10] <Saviq> and we should make sure that the qmluitest job actually works off of trunk
[09:11] <tsdgeos> yep
[09:16] <tsdgeos> FAIL!  : qmltestrunner::ShellWithPin::test_wrongEntries() property text
[09:16] <tsdgeos>    Actual   (): Enter your password
[09:16] <tsdgeos>    Expected (): Enter your passcode
[09:16] <tsdgeos>    Loc: [/home/tsdgeos_work/phablet/unity8/unity8/tests/qmltests/tst_ShellWithPin.qml(205)]
[09:16] <tsdgeos> didn't we fix that?
[09:16] <tsdgeos> or am i the wrong branch?
[09:23] <Saviq> tsdgeos, LC_ALL=C
[09:23] <tsdgeos> Saviq: LC_ALLC=C is fixing that?¿
[09:23] <Saviq> tsdgeos, yeah, I know
[09:24] <tsdgeos> Saviq: testShell crashed in unity8 trunk
[09:24] <tsdgeos> after some looping
[09:24] <tsdgeos> same shutting down problem
[09:24] <Saviq> tsdgeos, ok, looks like a different crash then
[09:24] <tsdgeos> let me attach gdb
[09:24] <Saviq> or maybe I didn't fix it right :P
[09:24] <Saviq> dednick, can you please sanity-check the ApplicationInfo change in http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/1175
[09:25] <dednick> Saviq: sure
[09:30] <Saviq> dednick, there's also something confusing in setSurface() that it registers nullptr with SurfaceManager (maybe that's expected?) but then it tries to connect() to it, which is fortunately just a warning, but confusing nevertheless
[09:30] <dednick> Saviq: i've fixed this all in my model branch.
[09:31] <Saviq> dednick, oh ok
[09:31] <dednick> Saviq: as for your code, doign setFurcace(nullptr) will call surfaceManager::unregisterSurface which will emit the destroySurface signal
[09:31] <dednick> so you can remove that from the MirSurface destructor
[09:31] <dednick> Saviq: but yeah. it's all a bit twisted at the moment.
[09:32] <dednick> my branch makes it a bit more straight forward.
[09:32] <Saviq> dednick, ok, I'll leave it to you :)
[09:35] <Saviq> dednick, it did fix the immediate crash, so unless it's crazy stupid, let's leave it in
[09:36] <dednick> Saviq: should be ok.
[09:36] <dednick> Saviq: crash on exit?
[09:36] <Saviq> dednick, yeah
[09:37] <dednick> Saviq: yup. seen that. fixed in my branch as well, but could take a little time before MP approved.
[09:37] <Saviq> dednick, it was deleting ApplicationInfo, which resulted in a deferred deletion of the surface, which called setSurface(nullptr) on the in-process-of-being-deleted ApplicationInfo
[09:37] <Saviq> that crashed because it went appId() on itself
[09:37] <Saviq> for the logging
[09:37] <dednick> Saviq: yup
[09:38] <dednick> i removed the deferred delete shizzle.
[09:42] <Saviq> Cimi, ok, not entirely sure any more what I meant by the settingsShown comment...
[09:42] <Saviq> Cimi, aah
[09:42] <Saviq> Cimi, just 2 lines up :)
[09:42] <Saviq> Cimi, hit me for more
[09:45] <tsdgeos> Saviq: i'd totally disagree with that "you on't reboot" tbh
[09:45] <tsdgeos> it's the only thing i do with my blackberry
[09:45] <Saviq> tsdgeos, yeah, why?
[09:45] <tsdgeos> it's the only way to get the email program to behave again when it goes into dumb mode
[09:46] <Saviq> tsdgeos, yeah, fix the email program ;)
[09:46] <Saviq> tsdgeos, the only reason to reboot a *working* phone is to upgrade, which happens automagically
[09:46] <Saviq> tsdgeos, for other cases, just power off and back on
[09:46] <tsdgeos> Saviq: ok, so we'll have no bugs on release, awesome :)
[09:47] <Saviq> tsdgeos, having a reboot option in the dialog is not a way for fighting bugs
[09:47] <tsdgeos> world is not black and white, if you can alleviate people's live a bit by having a reboot option i think it's worth it
[09:47] <tsdgeos> would make me much happier
[09:48] <Saviq> tsdgeos, just to back my stance up, both the main mobile OSs on the market don't have a reboot option
[09:48] <tsdgeos> yeah
[09:48] <tsdgeos> and android has flight mode on the shutdown button
[09:48] <tsdgeos> worst place ever
[09:48] <Saviq> yeah
[09:49] <Saviq> well we don't ;)
[09:49] <tsdgeos> so don't use them as an example of good UX ;)
[09:56] <Cimi> why airplane in shutdown is bad?
[09:56] <Cimi> in power button
[09:56] <Cimi> I find it quite handy
[09:59] <Saviq> tsdgeos, can I use iOS an example of good UX? they don't have a reboot either :P:
[10:00] <tsdgeos> Saviq: i have not used ios at all, can't comment
[10:01] <tsdgeos> Cimi: because i don't want to shut down the freaking thing, i just want to toggle the radios
[10:01] <tsdgeos> so it should be in network
[10:01] <tsdgeos> at least, i don't mind it being in shutdown in addition
[10:01] <tsdgeos> it not being in networks is weird
[10:01] <Saviq> tsdgeos, well, plane mode is there in the indicators on android too
[10:01] <tsdgeos> ok, maybe i've never used a newer android D:
[10:03] <Saviq> ;)
[10:04] <Saviq> tsdgeos, it's just a shortcut under the power button
[10:08] <Cimi> Saviq, there is no color property for listitems, right?
[10:08] <Saviq> Cimi, no idea
[10:08] <Cimi> Saviq, I think those settings might not work with different themes
[10:09] <Cimi> dednick, you know about theming of listitems?
[10:09] <dednick> Cimi: nope. don't think they are themed.
[10:10] <Cimi> dednick, I was wondering if I can set colors and such
[10:10] <Cimi> Saviq, I think it can be complicated
[10:10] <Cimi> Saviq, shall we keep scope settings with the normal plain look?
[10:11] <dednick> Cimi: hm. imo the colours are a bit wacked in sdk. we seem to have gone the route of. explicit colour setting.
[10:12] <Saviq> Cimi, yeah, there's barely a scope that changes those TBH
[10:12] <Saviq> Cimi, or not even "barely a" but rather "there is none"
[10:12] <dednick> Cimi: i think theming will change text color and such.
[10:12] <Cimi> Saviq, I'll remove scopestyle and such from settings
[10:12] <Saviq> Cimi,
[10:12] <Saviq> don't, file bugs with SDK instead
[10:12] <Saviq> dednick, yeah but that's theming as in Theme, global, we need it per component in here actually
[10:13] <dednick> Saviq: i c
[10:13] <Saviq> unless we get theming that we can override for a certain hierarchy
[10:13] <Cimi> Saviq, but if they read scopestyle, colors will be broken
[10:13] <Cimi> Saviq, there is no way also to theme switch buttons
[10:13] <Cimi> Saviq, or the text fields
[10:13] <dednick> qss shizzle.
[10:13] <Cimi> checkbutton
[10:13] <Cimi> etc
[10:14] <Cimi> Saviq, we canot use scopestyle...
[10:14] <Cimi> if we have a black theme, for example, all will look broken
[10:14] <dednick> can't we use qss with qml?
[10:16] <Saviq> dednick, qss?
[10:16] <dednick> qt style sheets
[10:16] <Saviq> dednick, not with plain QtQuick, maybe with Controls
[10:16] <Saviq> dednick, but since we have our own Theming engine...
[10:18] <dednick> yeah... don't get me started.
[10:19] <Saviq> dednick, yeah, but even with Controls there's a special thing http://qt-project.org/doc/qt-5/qtquick-controls-styles-qmlmodule.html
[10:24] <Cimi> sorry had connection dropped
[10:24] <tsdgeos> Saviq: crash still happening on 5.3 tip
[10:25] <tsdgeos> going to try to figure it out
[10:25] <tsdgeos> backtrace is insanely long
[10:25] <Cimi> sorry had connection dropped
[10:25] <Cimi> Saviq, what was last message you received?
[10:25] <dednick> your last message: <Cimi> if we have a black theme, for example, all will look broken
[10:26] <Cimi> ok
[10:26] <Cimi> if we want theming using scopestyle, I have to not use listitems and implement mines, and even then I will have issues with the button textures not adapting to colors
 if we have a black theme, for example, all will look broken
 Cimi, don't, file bugs with SDK instead
[10:31] <Mirv> tsdgeos: are we seeing the bug #1358169 in the wild, ie would it be a needed item for RTM?
[10:31] <tsdgeos> Mirv: not that i know
[10:32] <tsdgeos> Mirv: but the fact that you don't see it doesn't mean it's not there
[10:32] <Cimi> Saviq, so I should keep reading scopestyle and have things look broken?
[10:32] <Mirv> in a month or so we could have 5.3.2 too (depending a bit on how it can be scheduled to fit in...)
[10:32] <Cimi> it does not make sense to me
[10:32] <Cimi> Saviq, part of the scope setting will look themed, part will look of a different color
[10:32] <Saviq> Cimi, for now things won't look broken because there isn't a scope that sets background or foreground
[10:32] <Mirv> tsdgeos: true. ok, I'll try to see to its landing to 5.3.0.
[10:32] <Cimi> Saviq, but there might be in months time
[10:33] <Saviq> Cimi, file critical bugs with the SDK
[10:33] <Cimi> Saviq, and RTM code will contain bugs
[10:33] <Saviq> Cimi, and *if* they don't get fixed in time
[10:33] <Saviq> Cimi, we'll work around it then
[10:33] <Cimi> Saviq, we can't add bugs hoping they will get fixed in time IMHO
[10:33] <Cimi> we don't add bugs period
[10:33] <Saviq> Cimi, we have to ;)
[10:34] <Saviq> Cimi, that's not "adding bugs"
[10:34] <Cimi> that's "add code that now is broken"
[10:34] <Saviq> Cimi, that's an incomplete feature, dependant on SDK
[10:34] <Cimi> I don't agree with you on that
[10:34] <Saviq> Cimi, please just file bugs against unity8 and sdk and let's talk to them
[10:34] <Saviq> Cimi, what we don't have the time
[10:34] <Saviq> for
[10:35] <Cimi> it works for cards are headers because we are responsible for their style
[10:35] <Saviq> Cimi, untrue
[10:35] <Cimi> but if we use listitems in scope settings, we know that they are broken
[10:35] <Saviq> Cimi, header got fixed with icons
[10:35] <Cimi> yes, by you
[10:35] <Saviq> no
[10:35] <Cimi> weeks ago
[10:35] <Saviq> by SDK team
[10:35] <Cimi> ah ok
[10:35] <Saviq> Cimi, and it was broken initially, which just got it more attention
[10:39] <Cimi> Saviq, so you are asking me to add something that is broken?
[10:40] <Cimi> as soon as someone will use foreground color it will break
[10:41] <Saviq> Cimi, let's just make sure the bug gets fixed first
[10:42] <Cimi> Saviq, I don't care of sdk now, I want to fix the branch and get it approved
[10:42] <Cimi> we can submit a bugreport but I believe what the answer will be
[10:44] <Saviq> Cimi, I'm annoyed enough already by the chat in -touch about assumptions, presumptions and all that, please don't get me even more annoyed by it here
[10:44] <Cimi> Saviq, eh??
[10:45] <Saviq> Cimi, "I believe what the answer will be"
[10:45] <Cimi> Saviq, the all SDK theming is "if you don't like default, redo the style component"
[10:45] <Cimi> Saviq, even buttons don't have text color property
[10:46] <Cimi> Saviq, there is no themeability of fb/bg in sdk...
[10:46] <Saviq> Cimi, which is a bug that I filed with the SDK
[10:46] <Cimi> sometimes there is fg (label), sometimes only bg (button)
[10:47] <Saviq> Cimi, but going "eh, they're not gonna do it anyway" is not getting us anywhere
[10:47] <Cimi> Saviq, I don't think they are going to fix this by RTM, one week time
[10:47] <Saviq> Cimi, we need bugs and escalate them
[10:47] <Cimi> Saviq, I am on lp with the bug page opened
[10:48] <Cimi> Saviq, just sharing my concern with you...
[10:48] <Cimi> Saviq, we are both on the same line of thoughts about SDK stuff...
[10:48] <Cimi> Saviq, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1358241
[10:53] <mzanetti> Saviq: hmm... do we actually even want the AP lockscreen tests?
[10:53] <tsdgeos> meh
[10:53] <tsdgeos> http://paste.ubuntu.com/8079042/
[10:54] <Saviq> tsdgeos, a beauty
[10:54] <Saviq> what's Moth :D
[10:55] <tsdgeos> no clue tbh
[11:24] <Cimi> how do I write this? validator: root.mode == "number" ? DoubleValidator {} : undefined
[11:27] <Cimi> Saviq, ?
[11:31] <mzanetti> Saviq: ping
[11:31] <Cimi> ok had to declare it anyway outside
[12:02] <facundobatista> Holas
[12:25] <Saviq> mzanetti, pong
[12:26] <mzanetti> Saviq: https://code.launchpad.net/~dandrader/unity8/lifecycle/+merge/230090/comments/562134
[12:30] <Saviq> mzanetti, https://code.launchpad.net/~dandrader/unity8/lifecycle/+merge/230090/comments/562138
[12:32] <mzanetti> thanks
[12:34] <mzanetti> dandrader: good morning
[12:34] <dandrader> mzanetti, morning
[12:34] <mzanetti> I see you started working on the lifecycle again :)
[12:34] <mzanetti> dandrader: I'll push the stuff into the right-edge ppa so we can test on devices
[12:35] <dandrader> mzanetti,  just fixing as per https://code.launchpad.net/~dandrader/qtmir/lifecycle/+merge/230092/comments/561458
[12:35] <mzanetti> ah, I see
[12:36] <mzanetti> dandrader: so seems you broke the MockApplicationManager for tablet mode :/
[12:36] <mzanetti> that's probably a bit more efforts to get fixed again
[12:36] <mzanetti> I hope to be finished with a proper test run on the phone/tablet by the time you have fixed that
[12:37] <dandrader> mzanetti, will check you unity-api/lifecycle comment now
[12:37] <dandrader> your
[12:42] <tsdgeos> Saviq: some good news
[12:42] <tsdgeos> i know how to workaround the crash
[12:42] <tsdgeos> the luminance: is making it crash
[12:42] <tsdgeos> http://paste.ubuntu.com/8079669/ makes it go away
[12:43] <tsdgeos> now i need to find out why
[12:43] <tsdgeos> or at least find a better workaround :D
[12:50] <dandrader> mzanetti, fixed all your latest finding I think
[12:50] <dandrader> findings
[12:50] <mzanetti> dandrader: in unity8 too?
[12:50] <mzanetti> I find that hard to believe :) let me test
[12:50] <dandrader> mzanetti, the version thing?
[12:50] <mzanetti> dandrader: the make tryShell in tablet mode?
[12:51] <dandrader> mzanetti, oh, there's a bunch of new stuff... I said that too soon :)
[12:51] <mzanetti> :)
[12:55] <dandrader> mzanetti, so a qml Tansition is also a QtObject?
[12:56] <mzanetti> dandrader: yes
[12:56] <dandrader> mzanetti, ah, good. so it's doable indeed
[12:56] <mzanetti> dandrader: but it's not contained in "item.children" but only in "item.data"
[12:56] <dandrader> right
[12:56] <mzanetti> dandrader: that's the difference between findChild() and findInvisibleChild()
[13:13]  * greyback_ stumbled across that last week
[13:13] <mzanetti> ?
 dandrader: that's the difference between findChild() and findInvisibleChild()
[13:13] <mzanetti> dandrader: your qtmir branch doesn't build in the ppa: https://launchpadlibrarian.net/182617174/buildlog.txt.gz
[13:13] <mzanetti> greyback_: ah :)
[13:14] <greyback_> mzanetti: I was writing a test to call a function inside q private QtObject, and took me ages to figure out why findChild couldn't find the object
[13:14] <mzanetti> greyback_: heh, yeah, walking through data always takes ages when doing that on the shell object
[13:15] <mzanetti> greyback_: that's why findChild normally only walks through children
[13:15] <greyback_> mzanetti: gotcha
[13:27] <mzanetti> Saviq: fyi: https://bugs.launchpad.net/unity8/+bug/1357321/comments/2
[13:28] <Saviq> mzanetti, yeah, note Victor could still browse the web and all
[13:29] <mzanetti> Saviq: yeah, but he most likely restarted the browser after the roaming step
[13:29] <mzanetti> (actually I'm not sure if the browser suffers from this)
[13:29] <mzanetti> I noticed it with other apps
[13:37] <Saviq> mzanetti, ah
[13:41] <Saviq> tsdgeos, mzanetti, help me out here... remove transition not triggered if the last item in a model is removed... ideas?
[13:42] <mzanetti> hmm...
[13:42] <tsdgeos> random stuff: model reset vs model propery removing stuff?
[13:42] <Saviq> tsdgeos, it works on all the other removals
[13:42] <Saviq> tsdgeos, just the last item is affected, and ListView.onRemove is triggered on it
[13:42] <tsdgeos> Saviq: model may be doing different code for last?
[13:43] <Saviq> tsdgeos, doesn't look like it
[13:43] <tsdgeos> ok
[13:46] <tsdgeos> no other random ideas other than a bug
[13:50] <mzanetti> Saviq: so there is the thing that delegate0 is never destroyed (for example by cachebuffer)
[13:51] <mzanetti> don't know why... but maybe that affects this too
[13:51] <Saviq> mzanetti, no, I didn't mean last as in the last remaining one, just the last one from the end
[13:51] <mzanetti> ah ok
[13:56] <dandrader> mzanetti, have you ever looked for a Transition in one of your qmltests?
[13:56] <Saviq> mzanetti, tsdgeos, confirmed, no remove on removing the last item: http://paste.ubuntu.com/8080113/
[13:57] <mzanetti> dandrader: I did that with Animations, not sure about Transition itself
[13:57] <Saviq> a behavior on contentX doesn't help
[13:57] <mzanetti> meh
[13:58] <tsdgeos> Saviq: seems that http://paste.ubuntu.com/8080133/ made the crash go away :/
[13:59] <Saviq> tsdgeos, ugh
[13:59] <dandrader> mzanetti, findInvisibleChildren doesn't seem to find them :(  Maybe I should try to get the transitions array of the StateGroup instead
[13:59] <tsdgeos> Saviq: let the loop run for a bit more, but it seems that doesn't crash anymore now
[13:59] <Saviq> tsdgeos, yeah ok
[13:59] <Saviq> tsdgeos, we probably should just move the luminance method into C++ anyway
[14:00] <mzanetti> dandrader: hmm... maybe worth a try... but if this is giving you a major headache let me know... I thought it should be rather simple to move it over
[14:00] <tsdgeos> Saviq: yeah but that change fixing the crash makes me very unhapy
[14:00] <Saviq> tsdgeos, yeah, it does suggest a nasty bug
[14:06] <mzanetti> mterry: updated the lockscreen branch
[14:07] <mterry> mzanetti, OK finishing up something but will re-look today
[14:07] <mzanetti> mterry: all tests passing now and the autoconfirm mode is back
[14:07] <mterry> mzanetti, I asked Olga/Esti about device unlock autoconfirm UI.  we'll see
[14:08] <mterry> It was part of another thread, forgot to cc you
[14:08] <mzanetti> ah ok...
[14:08] <mzanetti> well... I still think its wrong to limit the pin to 4 digits
[14:08] <mzanetti> if you *really* don't want to press more than 4 buttons you should set a 3 digits pin :D
[14:10] <tsdgeos> Saviq: 10 minutes of looping and working, so do i commit that workaround with a todo? do we have time to properly investigate why this happens? given that i have no clue of that code it may take ages
[14:11] <Saviq> tsdgeos, yeah, just commit the workaround
[14:14] <tsdgeos> Saviq: confused, i'm in tryCard, have selected "Art, header - grey background", now i go and add     "card-layout": "horizontal", to the template
[14:14] <tsdgeos> why is the grey background gone?¿
[14:23] <tsdgeos> Saviq: commit to alt_nav or some other branch?
[14:42] <mzanetti> dandrader|lunch: please let me know when you fixed the build issues with your branches (or kick the ppa yoursef)
[14:43] <Saviq> tsdgeos, I think one of the previous branches actually introduces this
[14:43] <Saviq> tsdgeos, header-customizations
[14:43] <Saviq> tsdgeos, so put it there
[14:43] <tsdgeos> ok
[14:44] <tsdgeos> Saviq: can't it's yours
[14:44] <tsdgeos> Saviq: and i've already put it in alt_nav fwiw
[14:45] <Saviq> tsdgeos, yeah, please undo and I'll put it in mine and remerge up
[14:45] <tsdgeos> Saviq: ok
[14:46] <tsdgeos> Saviq: i also have https://code.launchpad.net/~aacid/unity8/more_stable_overview_tests/+merge/231173 that we should integrate somewhen somehow
[14:47] <tsdgeos> Saviq: want me to chain it after some branch
[14:47] <tsdgeos> ?
[14:48] <Saviq> tsdgeos, I think it doesn't conflict with anything else no
[14:48] <tsdgeos> ok
[14:48] <Saviq> tsdgeos, but truth be told..
[14:48] <Saviq> tsdgeos, maybe instead we should make tryCompareFunctions catch?
[14:49] <tsdgeos> Saviq: ?
[14:49] <Saviq> tsdgeos, right, wouldn't help in that case anyway
[14:49] <Saviq> 'cause it'd catch and fail() anyway
[14:49] <Saviq> tsdgeos, yeah, is good like it is now
[14:49] <Saviq> gaaaah
[14:50] <Saviq> and ListView.onRemove causes removeDisplaced to not happen
[14:50] <Saviq> REALLY?!
[14:52] <Saviq> WAAAAT
[14:52] <Saviq> mzanetti, tsdgeos please tell me I'm blind or something
[14:52] <Saviq> http://paste.ubuntu.com/8080481/
[14:53] <Saviq> remove 5, 4, 3
[14:53] <mzanetti> Saviq: you're blind or something
[14:53] <Saviq> fooking 3 gets a remove transition !?!?!?!?!
[14:53]  * mzanetti tries
[14:54] <mzanetti> :D
[14:55] <Saviq> but if you overshoot it
[14:55] <Saviq> it doesn't
[14:55] <Saviq> like remove 5, 4
[14:55] <mzanetti> yeah
[14:55] <Saviq> drag to overshoot
[14:55] <mzanetti> just figured the same
[14:55] <Saviq> WTF
[14:56] <mzanetti> Saviq: well, what's weird is this:
[14:56] <mzanetti> scroll to bottom, click on 5, 4
[14:56] <mzanetti> or, well, one step back
[14:56] <mzanetti> click on 5, you'll see 4
[14:56] <mzanetti> then click on 4, you'll see 3
[14:56] <mzanetti> then click on 3, you'll see 0
[14:56] <mzanetti> (unless you overshoot)
[14:57] <Saviq> mzanetti, yeah, related to the lack of transition
[14:58] <tsdgeos> looks weird yeah
[14:58] <Saviq> mzanetti, HAH
[14:58] <Saviq> originY
[14:59] <mzanetti> aha!
[14:59] <mzanetti> that sucker again
[14:59] <Saviq> that's completely stupid
[15:00] <Saviq> http://paste.ubuntu.com/8080531/
[15:00] <Saviq> on remove of 3 originY changes
[15:00] <Saviq> which is probably why it decides to do the remove transition for that one
[15:00]  * Saviq files a QTBUG
[15:21] <Saviq> mzanetti, what's also worrying
[15:21] <Saviq> mzanetti, is that they get index: -1
[15:22] <Saviq> regardless of delayRemove
[15:22] <mzanetti> yeah
[15:22] <mzanetti> noticed that too
[15:37] <Saviq> tsdgeos, mzanetti, https://bugreports.qt-project.org/browse/QTBUG-40846 https://bugreports.qt-project.org/browse/QTBUG-40847 https://bugreports.qt-project.org/browse/QTBUG-40848
[15:45] <mzanetti> lol... 3
[17:28] <dandrader> mzanetti you have to add qtmir to the right-edge ppa as well
[17:29] <dandrader> mzanetti because it's not building. let me see that :-D
[17:29] <mzanetti> dandrader: yes. I know
[17:30] <mzanetti> dandrader: what's the question?
[17:30] <mzanetti> dandrader: https://code.launchpad.net/~dandrader/qtmir/lifecycle/+merge/230092/comments/562209
[17:30] <dandrader> mzanetti nevermind. I noticed that there's no qtmir there but only later I saw you telling me about the qtmir build failure in the irc backlog
[17:31] <mzanetti> ah ok
[17:35] <dandrader> mzanetti, fixed
[17:35] <mzanetti> ack
[17:35] <dandrader> mzanetti hopefully it's all covered now
[17:36] <mzanetti> lets see... I started the build
[17:39] <mzanetti> dandrader: looking better
[17:41] <dandrader> mzanetti it's funny that due to the missing antialiasing in the spread, the screenshots look way better than the live surface there
[17:42] <mzanetti> yeah...
[17:42] <mzanetti> we need to get antialiasing enabled
[17:42] <mzanetti> greyback_: have you had any success with that? ^
[17:43] <greyback_> mzanetti: I know how to do it, I just have other things to do first
[17:43] <mzanetti> ack
[17:43] <mzanetti> that sounds good... knowing how to do is the hardest part :)
[17:45] <mzanetti> Saviq: do you know a way around if unity8 is hanging here and won't die when I try to kill it?
[17:45] <mzanetti> I don't want to reboot again
[17:46] <mzanetti> uninterruptable sleep
[17:46] <mzanetti> hmm
[17:59] <Saviq> mzanetti, kill -9 still no go??
[18:07] <mzanetti> Saviq: nope
[18:07] <mzanetti> I attached gdb and now that's hanging too :D
[18:07] <mzanetti> ok. I could kill gdb with -9 again
[18:08] <mzanetti> but unity8 won't stop...
[18:08] <mzanetti> ps says Dsl, and the man page says uninterruptable wait (usually hardware) :/
[18:09] <mzanetti> first time I see this tbh
[18:10] <mzanetti> dandrader: still no good: https://launchpadlibrarian.net/182633531/buildlog_ubuntu-utopic-i386.qtmir_1%3A0.4.1%2B14.10.20140817-0~234%2B201408181736~ubuntu14.10.1_FAILEDTOBUILD.txt.gz
[18:15] <dandrader> mzanetti hmmm that virtual method came from mir 0.6.0 release...
[18:16] <dandrader> back in a bit
[20:52] <mterry> bregma, hello!  So I saw your pam branch go by.  Do you know why we're seeing two simultaneous prompts on desktop?
[20:52] <bregma> no, if I did I would have tackled it that way
[20:52] <bregma> although the reentrancy problem would still be there
[20:53] <mterry> bregma, are you saying that pam_* isn't reentrant?
[20:53]  * mterry thought they were
[20:54] <bregma> well, the second conversation never happens
[20:56] <bregma> mterry, the first authentication() call happens after Shell::Lockscreen::Component.onCompleted, the second appears to happen as a result of handling the password prompt in the PAM conversation, but taht's not entirely clear
[20:57] <mterry> bregma, ah...  you have only one account on your machine?
[20:57] <bregma> certainly not
[20:57] <mterry> one account that shows up in the unity8 list anyway?
[20:57] <mterry> ok
[20:57] <mterry> hmm
[20:57] <bregma> all of my fictitious friends have accounts too
[20:57] <mterry> :)
[20:58] <bregma> it's a test machine, and a certain class of bugs involve signing in on different acocunts (as in, don;t kill all compiz instances when a single user logs out, that's bad)
[20:59] <Saviq> debatable
[20:59] <bregma> but I see no list of users in the unity 8 greeter, only in the LightDM greeter
[20:59] <bregma> it would be even better if I didn't see the Unity 8 greeter as soon as I authenticate through LightDM, but oe problem at a time
[21:01] <mterry> bregma, yeah that change can be easily made once I make the greeter an optional split again
[21:01] <mterry> bregma, a quick google indicates PAM is *supposed* to be reentrant.  And I believe unity7 treats it as such
[21:01] <mterry> Well, I mean, it treats handles as sharable between threads
[21:02] <mterry> I suspect unity7 doesn't start simultaneous conversations though
[21:02] <bregma> mterry, I think the problem actually may be the future not getting deleted
[21:03]  * bregma hopes his own future does not get deleted
[21:04] <mterry> heh
[21:04] <mterry> bregma, the future sitting in the futureWatcher object?
[21:04] <mterry> i.e. the one for the previous QtConcurrent::run()?
[21:09] <mterry> bregma, at any rate, I don't think your branch as-is will work, because if you switch users in the greeter, we'd need a way to stop old PAM conversation and begin a new one with the new user
[21:09] <mterry> bregma, but!
[21:09] <mterry> bregma, I bet you do see only one user in the unity8 list
[21:10] <mterry> hrm
[21:10] <mterry> no that hunch doesn't make sense
[21:12] <bregma> well, the observed facts are that the current code never comes back from authenticating through the Unity 8 greeter, and my patched code does
[21:13] <bregma> and switching users brings up the LightDM greeter again
[21:34] <mterry> Saviq, mzanetti: at some point, we made it so that when running ./run.sh we don't see console output.  Is there a way to get that back?
[21:34] <Saviq> mterry, you should still get it
[21:34] <Saviq> mterry, not from dash though
[21:34] <Saviq> mterry, as that's a separate job and all (not difficult to bring back, just we didn't yet)
[21:35] <mterry> Saviq, hrm.  I don't see console.log() output
[21:35] <Saviq> mterry, do you see *any* output when you start it (does it start, for that matter?)
[21:35] <mterry> unity8 start/running, process 16798
[21:35] <mterry> MirSurfaceItem::MirSurfaceItem()  "Unity 8 Mock Dash"
[21:35] <mterry> Application::setSurface - appId= "unity8-dash" surface= MirSurfaceItem (this = 0x1dadf90 , name= "" , parent = 0x0 , geometry = QRectF(0,0 0x0) , z = 0 )
[21:35] <mterry> ** (unity8:16798): WARNING **: Unable to register app: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Invalid application ID
[21:35] <mterry> Saviq, ^
[21:36] <Saviq> mterry, well looks good
[21:36] <Saviq> mterry, check in ~/.cache/upstart/unity8.log ?
[21:36] <mterry> Saviq, ah of course, it's there
[21:37] <mterry> Saviq, I thought we redirected that to console or something
[21:37] <Saviq> mterry, but still, if it's there, should be on your console...
[21:37] <Saviq> mterry, we just do ftail on that file
[21:37] <Saviq> tailf that is
[21:37] <mterry> oh...
[21:37] <mzanetti> I don't see output from run.sh most of the times either
[21:37] <mzanetti> works sometimes
[21:37] <mzanetti> but tail -f on the log works
[21:39] <Saviq> wfm
[22:27] <dandrader> mzanetti, qtmir should build fine on the ppa now (already triggered the new build)
[22:37] <Saviq> tedg, hey, in need of a pointer
[22:37] <Saviq> tedg, we need to ping unity8 on app upgrade / uninstall to update the launcher
[22:37] <Saviq> tedg, the click hook doesn't know about the session dbus or upstart or anything