=== guest42345 is now known as o
=== o is now known as Guest57566
[08:13] <cimi> tsdgeos, got dragged on a bricked vegeta last night :D
[08:15] <tsdgeos> k
[08:15] <cimi> tsdgeos, matthieu flashed a krillin image on a vegeta :D
[08:16] <cimi> tsdgeos, trying to recover now
[08:19] <cimi> hey tsdgeos, I don't understand some of your C++
[08:20] <cimi> tsdgeos, in the .cpp you comment out the args of your function like PreviewStack* Scope::preview(QVariant const& result, QString const& /*categoryId*/) but declare them in the header?
[08:20] <duflu> cimi: Then you still have your soul
[08:20] <duflu> Congrats!
[08:20] <cimi> duflu, lol, I am just not very good at C++ :P
[08:21]  * duflu was sure Cimi's name was on a lot of Unity source code
[08:21] <cimi> duflu, because unity had so many bugs? :D
[08:34] <tsdgeos> cimi: what's the question?
[08:34] <tsdgeos> cimi: is the question "why do you have categoryId at all"?
[08:34] <cimi> tsdgeos, why in the cpp the argument is under comment
[08:35] <cimi> tsdgeos, to avoid compile warnings?
[08:35] <tsdgeos> cimi: yes
[08:35] <cimi> tsdgeos, fair enough
[10:35] <cimi> tsdgeos, https://code.launchpad.net/~aacid/unity8/dash_activation_no_special_casing/+merge/264024
[10:38] <tsdgeos> tx
[10:42] <tsdgeos> cimi: it's two times we have the reset code, not three, but whatever, i'll make the function
[10:46] <tsdgeos> cimi: pushed the fixes
[10:47] <cimi> tsdgeos, yeah I realised
[10:59] <cimi> tsdgeos, is it possible that
[10:59] <cimi> 114	+        onPreviewRequested: { // (QVariant const& result)
[10:59] <cimi> 115	+            if (result === scopeView.maybePreviewResult) {
[10:59] <cimi> tsdgeos, result is undefined and if is true?
[11:00] <cimi> tsdgeos, shall we protect against undefined?
[11:01] <tsdgeos> pstolowski: ↑↑↑
[11:01] <tsdgeos> if the lower layers do that it's a bug
[11:01] <tsdgeos> i don't think we out to try to make it invisible
[11:02] <tsdgeos> pstolowski: ↑↑↑↑
[11:03] <cimi> tsdgeos, with your code, we enter the if is result and maybePreviewResult are the same... so not sure we should check for null/undefined
[11:04] <cimi> in case weird weird things happen on the backend
[11:04] <tsdgeos> yes i know
[11:04] <tsdgeos> i understand whta you say
[11:04] <tsdgeos> if the backend is broken
[11:04] <tsdgeos> fix the backend
[11:06] <tsdgeos> cimi: but if you're going to block on this i can change the if to do whatever you want
[11:16] <cimi> tsdgeos, block on this? no
[11:16] <cimi> tsdgeos, it's a question, what shall we do?
[11:16] <tsdgeos> i mean i don't care that much
[11:16] <tsdgeos> honestly i think we should do nothing
[11:16] <tsdgeos> worst thing is
[11:16] <tsdgeos> if the backend is broken
[11:16] <pstolowski> tsdgeos, cimi not it's not possible, we internally use proper Result instances and only wrap them into variant before emiting the signal
[11:16] <tsdgeos> the user gets a empty preview
[11:17] <tsdgeos> he goes back, reports a bug, fixed :D
[11:17] <tsdgeos> and pstolowski says it can't really even happen
[11:22] <pstolowski> tsdgeos, i'm happy with this silo and haven't spotted any regressions. i can mark it ready when the MP is approved
[11:24] <tsdgeos> pstolowski: you'll have to rebuild since i did a minor change because of cimi's comments
[11:25]  * cimi feels guilty
[11:25] <pstolowski> tsdgeos, cimi ok, np
[11:26] <pstolowski> tsdgeos, and is it approved now?
[11:26] <cimi> pstolowski, very soon
[11:35] <pstolowski> cimi, shall i hold on with rebuilding to give you some more time to review?
[11:37] <tsdgeos> pstolowski: it's approved now
[11:37] <tsdgeos> pstolowski: retrigger the build!
[11:37] <pstolowski> thanks
[11:38] <tsdgeos> food
=== alan_g is now known as alan_g|lunch
[12:31] <a1fa> http://i.imgur.com/O7K8KAo.png
=== jhodapp is now known as jhodapp|sick
=== alan_g|lunch is now known as alan_g
[13:21] <greyback> a1fa: what is that showing us? a new terminal instance missing window decoration?
[13:26] <tsdgeos> cimi: come on top approve https://code.launchpad.net/~aacid/unity8/expandable_test_fixes/+merge/266875 and https://code.launchpad.net/~aacid/unity8/testExpandableHeights/+merge/266876 ! :D
[13:26] <tsdgeos> cimi: and if you have time https://code.launchpad.net/~aacid/unity8/more_autotests_dash/+merge/265401 needs reviewing too
[13:27] <a1fa> greyback: existing terminal that i focused to, and menu bar dissapeared
[13:30] <cimi> tsdgeos, forgot to top approve
[13:30] <cimi> tsdgeos, done
[13:31] <cimi> tsdgeos, still no idea why my checked branches have issues with tags, but running the command remotely works
[13:31] <cimi> maybe Saviq ?
[13:32] <greyback> a1fa: well that's something I've never seen. bregma does that look familiar? ^^
[13:32] <a1fa> http://i.imgur.com/O7K8KAo.png
[13:32] <tsdgeos> cimi: if he has time
[13:41] <bregma> a1fa, looks like a bug in the window decorations, you should probably file a bug https://bugs.launchpad.net/unity/+filebug
[14:10] <cimi> preview in order or autotest first?
[14:10] <cimi> ops he quit
[14:21] <cimi> tsdgeos, preview in order or autotest first?
[14:22] <tsdgeos> cimi: test first i'd say
[14:22] <cimi> ojk
[14:22] <tsdgeos> should be easier
[14:22] <tsdgeos> i hope :D
=== dandrader is now known as dandrader|afk
[16:09] <seb128> hey there
[16:09] <seb128>  when moving to another app on the phone, what's the state of bg apps?
[16:09] <seb128>  Qt.ApplicationInactive or Qt.ApplicationSuspended ?
[16:09] <seb128> unsure if that's a qt, sdk, qtmir, unity thing?
=== dandrader_ is now known as dandrader
[16:23] <greyback> seb128: inactive I think
[16:23] <seb128> is that wanted?
[16:23] <seb128> see #sdk discussion
[16:24] <seb128> basically  http://doc.qt.io/qt-5/qml-qtqml-qt.html states
[16:24] <seb128> "Qt.ApplicationSuspended - The application is suspended and not visible
[16:24] <seb128> to the user. On mobile platforms, the application typically enters this
[16:24] <seb128> state when the user returns to the home screen or switches to another
[16:24] <seb128> application."
[16:58] <greyback> dandrader: one final nit with noQtSensors-lp1481389 reported, then is good to go
[17:00] <dandrader> greyback, done
[17:03] <greyback> nice, thanks
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
[19:27] <mterry> lp:unity8/overlay is ftbfs on an overlay phone because it's looking for unity-shell-application=5, but 6 is installed
[19:38] <dandrader> mterry, merge trunk?
[19:39] <mterry> dandrader, trunk being unity8/overlay?  I just branched it now
[19:39] <dandrader> mterry, lp:unity8
[19:39] <mterry> It hasn't changed since 8/1
[19:40] <mterry> dandrader, maybe I don't understand what the various series are used for
[19:40] <dandrader> anyway, I probably don't know what I'm saying. It
[19:40] <mterry> dandrader, I assumed trunk was wily, overlay was vivid+overlay
[19:40] <dandrader> It's the first time I hear about this overlay branch
[19:40] <mterry> https://code.launchpad.net/unity8/
[19:40] <mterry> I don't know what rtm-14.09 is still used for (it's more updated than overlay)
[19:41] <dandrader> don't ask me :)
[19:41] <mterry> :)
[19:41] <dandrader> I always use lp:unity8 and ignore those
[19:42] <mhall119> is ctrl+tab when running `make tryShell` going to be what alt+tab does in actual use?
[19:42] <dandrader> mzanetti would know but he's on leave
[19:42] <dandrader> (about the unity8 branches I mean(
[19:42] <dandrader> mhall119, I think so
[19:42] <mhall119> dandrader: cool, thanks it's looking good
[19:46] <greyback_> mterry: right now lp:unity8 is trunk for both vivid+overlay & wily
[19:47] <mterry> greyback_, really?  it requires libunity-api-dev (>= 7.98) which isn't in vivid+overlay
[19:50] <greyback_> mterry: hmm, I wonder if this is it blocked: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-api
[19:51] <mterry> greyback_, ah ok.  thanks, I should have guessed it was gcc5 nonsense
[19:52] <greyback_> mterry: but I don't understand how a gcc5 thing could impact vivid+o
[19:52] <mterry> (how are people compiling unity8 then?)
[19:52] <greyback_> I've no idea
[19:52] <greyback_> something is wrong
[19:52] <mterry> greyback_, it's not...  I was trying to build for v+o and trying to find the right branch to build from.  lp:unity8 was suggested, but that is borked on gcc5
[19:53] <greyback_> none of our branches have a hard dependency on any gcc version
[19:53] <mterry> greyback_, well unity-api does when built against gcc5
[19:53] <greyback_> yeah, but that shouldn't happen on vivid+o
[19:53] <mterry> greyback_, right.  it's not
[19:54] <greyback_> I'm very confused right now :)
[19:54] <mterry> greyback_, but lp:unity8 does require the wily version of unity-api
[19:54] <mterry> greyback_, I'm just trying to build ANY branch of unity8 on v+o
[19:54] <mterry> greyback_, lp:overlay has a build problem of some sort
[19:54] <greyback_> mterry: yep, but unity-api *should* be released for both v +o& w, usually simultaneously
[19:55] <greyback_> mterry: I've never heard of that overlay branch, ever
[19:55] <mterry> greyback_, lp:u8/rtm-14.09 is NEWER than lp:u8/overlay for some reason (do we still use it?  I'm leery of trying to build it)
[19:55] <mterry> greyback_, OK.  So everyone is just using lp:u8.  got it
[19:55] <greyback_> mterry: that should be the case.
[19:55] <mterry> greyback_, it may be held back on v+o because it's held back on wily
[19:55] <mterry> But that leaves me with a problem building
[19:56] <greyback_> I would have thought unity8 could not migrate then
[19:56] <greyback_> if unity-api couldn't
[19:56] <mterry> greyback_, I'm not building from packaging.  I'm building from trunk
[19:56]  * mterry should try packaging I guess
[19:56] <mterry> older u8, but it will build
[19:56] <greyback_> my unity-api trunk has 7.98
[19:56] <mterry> greyback_, yup.  But I wasn't trying to recompile unity-api trunk
[19:57] <mterry> That might be a way around it too
[19:57] <greyback_> I know. I'm just surprised it has landed for wily, but not for v+o
[19:57] <mterry> greyback_, it hasn't landed in either I don't think
[19:57] <greyback_> ah you're right, it's proposed for wily
[19:58] <mterry> So I either recompile unity-api (and who knows what else) from trunk or just use the version of u8 that's in v+o archive (I'll do that)
[19:58] <mterry> greyback_, thanks for coming with me on this journey  :)
[19:59] <greyback_> unity-api 7.98 is in v+o
[20:00] <greyback_> but stuck in proposed for w
[20:00] <mhall119> mterry: greyback_: I compiled Unity 8 fine on vivid+overlay
[20:00] <mterry> mhall119, now you're just bragging  :)
[20:00] <mhall119> maybe --setup pulls the wily version of that package?
[20:00] <mterry> greyback_, what?!  hmm
[20:01] <greyback_> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?batch=75&memo=75&start=75
[20:01] <greyback_> I see it there
[20:01] <mterry> greyback_, it's not in an apt-cache policy
[20:02] <mterry>  *** 7.97+15.04.20150611-0ubuntu1 0
[20:02] <mterry>        1001 http://ppa.launchpad.net/ci-train-ppa-service/stable-snapshot/ubuntu/ vivid/main armhf Packages
[20:02] <mterry> greyback_, you're using stable-phone-overlay... I have stable-snapshot
[20:02] <mterry> I installed from ubuntu-touch/stable/ubuntu
[20:02] <mterry> I should probably do rc-proposed or some such...
[20:03] <greyback_> mterry: yeah, you're working off the last stable release, which does fall behing
[20:03] <greyback_> rc-proposed the usual channel I use
[20:03] <mterry> greyback_, yeah I didn't consider my need to build when I picked a channel
[20:03] <mterry> :(
[20:03] <mterry> greyback_, OK thanks, I'm sure that will sort me
[20:03] <mterry> thanks mhall119!
[20:03] <greyback_> oh well, tragedy averted :)
[20:04] <mhall119> greyback_: better luck next time :)
[20:04] <greyback_> :)
[20:27] <mhall119> is there a tag for bitesize bugs in unity8?
[20:27] <mhall119> ah,ignore me, I just didn't see it at first
[20:31] <mhall119> hmmm, they don't seem overly bitesized though
[22:27] <hehehehe> is there a way to compile unity without the launcher bar on ubuntu 14.04?
=== Daek_ is now known as Daekdroom