[08:02] <tsdgeos> mzanetti: did you see the header being broken in your 1.3 apps?
[08:03] <mzanetti> tsdgeos, I did before my time off, reported a bug, seems working fine now
[08:03] <tsdgeos> our 1.3 branch has lost the headers
[08:03] <tsdgeos> file:///home/tsdgeos_work/phablet/unity8/sdk1.3_newUbuntuShape/qml/Dash/PageHeader.qml:243:13: QML PageHeadStyle: Binding loop detected for property "config"
[08:03] <tsdgeos> seems may be the culprit
[08:03]  * tsdgeos investigates
[08:04] <mzanetti> oh, I remember timp saying something
[08:04] <mzanetti> but that's a while ago
[08:04] <mzanetti> he should be able to help you if it turns out tricky
[09:00] <tsdgeos> cimi: ping
[09:00] <cimi> tsdgeos, pong
[09:00] <tsdgeos> cimi: if you run all the ui tests on your branch some more will fail
[09:00] <tsdgeos> but they also fail on my branch
[09:00] <tsdgeos> so i'm fixing those
[09:01] <cimi> tsdgeos, bzr pull for the previewheader
[09:01] <tsdgeos> just saying in case you run them and think "oh albert didn't see these ones, i'll fix them too"
[09:01] <cimi> ok
[09:01] <tsdgeos> cool, so i'll fix these ones and then tell you so you remerge
[09:01] <tsdgeos> there's a scary one though
[09:01] <tsdgeos> in DirectionalDragArea
[09:01] <tsdgeos> QFATAL : tst_DirectionalDragArea::withdrawTouchOwnershipCandidacyIfDisabledDuringRecognition(invisible) reached maximum number of OpenGL contexts supported by UbuntuShape
[09:02] <tsdgeos> :S
[09:06] <greyback>             // Don't bother with a dynamic array, let's just set a high enough maxShapeTextures and
[09:06] <greyback>             // increase the static array size if ever needed.
[09:06] <greyback>             qFatal("reached maximum number of OpenGL contexts supported by UbuntuShape");
[09:06] <greyback> :(
[09:12] <tsdgeos> the thing is
[09:12] <tsdgeos> it seems to me something is forgetting to delete something
[09:12] <tsdgeos> because it's at the end of the test
[09:12] <tsdgeos> maybe not
[09:56] <tsdgeos> cimi: please merge my branches to yours to see what's missing if anything
[09:56] <tsdgeos> from the tests i mean
[09:57]  * tsdgeos fixed the SDK so that tst_DirectionalDragArea passes :)
=== alan_g is now known as alan_g|lunch
=== vesar is now known as vesar_lunch
[10:47] <tsdgeos> cimi: test is still failing in your branch for me :S
[10:47] <cimi> argh ok
[10:48] <tsdgeos> cimi: make sure you merge my branch first too, so everything is more up to date
[10:48] <cimi> yeah will do
[10:48] <cimi> actusally will/did
[11:12] <tsdgeos> mzanetti: what do you think of a branch that changes all our connects from using SIGNAL() and SLOT() to using the C++11 way of connecting the signals?
[11:13] <mzanetti> tsdgeos, wfm
[11:14]  * tsdgeos does
[11:23] <cimi> from adb shell in recovery can I see what is going on with my system?
[11:23] <cimi> my arale keeps rebooting after wizard ended
[11:23] <cimi> flashed multiple times always same issue
=== vesar_lunch is now known as vesar
=== vesar is now known as vesar_
=== vesar_ is now known as vesar__
[11:33] <ltinkl> tsdgeos, fwiw, definitely a good idea imo, note there's a respective refactoring feature in the recent Qt Creator to achieve this
[11:35] <tsdgeos> ok
=== alan_g|lunch is now known as alan_g
[11:48] <cimi> tsdgeos, fixed the tests for previewheader
[11:48] <cimi> tsdgeos, and merged el trunko
[12:36] <tsdgeos> cimi: cool
[12:49] <dandrader> mzanetti, so lp:unity8 now needs lp:unity-api/trunk-15.04 instead of lp:unity-api?
[12:49] <mzanetti> probably...
[12:50] <mzanetti> sounds about right
[12:54] <dandrader> mzanetti, so I should resubmit https://code.launchpad.net/~dandrader/unity-api/mirSurface/+merge/264921 to point to this other branch instead, right?
=== tedg is now known as ted
[12:55] <greyback> pstolowski: can you answer ^^
[13:01] <pstolowski> dandrader, mzanetti, greyback correct trunk-15.04 is for vivid overlay. and you should prepare separate MP against lp:unity-api trunk for wily
[13:02] <dandrader> pstolowski, so lp:unity8 is for vivid overlay then. then which unity8 branch is for wily?
[13:04] <pstolowski> dandrader, greyback and tsdgeos decided not to branch off for vivid overlay and use trunk for the moment, then resolve it somehow for wily
[13:05] <dandrader> pstolowski, so I can just ignore lp:unity-api for now
[13:05] <dandrader> pstolowski, and work with lp:unity8 + lp:unity-api/trunk-15.04
[13:05] <pstolowski> dandrader, no, please have MP for lp:unity-api anyway so that we don't forget
[13:06] <dandrader> pstolowski, it doens't make any sense if there's no accompanying unity8 branch for it
[13:07] <pstolowski> dandrader, will it break anything if it's merged in wily without unity8 changes?
[13:07] <tsdgeos> pstolowski: we'll fix unity8 for wily when there's a unity-shell-scopes that is usable :D
[13:07] <tsdgeos> well probably not
[13:07] <tsdgeos> but it's at least a pre-requisite :D
[13:07] <dandrader> so the vibe is to ignore wily for now. fine for me
[13:10] <pstolowski> dandrader, can you at least have a MP set to work-in-progress for now?
[13:11] <pstolowski> tsdgeos, it will soon
[13:13] <dandrader> pstolowski, sure
[13:15] <tsdgeos> pstolowski: :)
[13:36] <tsdgeos> Mirv: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1484914
[13:36] <ubot5> Ubuntu bug 1484914 in qtdeclarative-opensource-src (Ubuntu) "Memory leak in ThumbnailGenerator" [High,In progress]
[13:38] <kgunn_> mzanetti: looks like we're going for the MirSurface branches ?
[13:38] <mzanetti> kgunn_, for me, josh's branch doesn't seem to fix the issue
[13:39] <ltinkl> dandrader, https://code.launchpad.net/~lukas-kde/unity8/globalshortcuts have a look again please, I think I've addressed all the issues you'd pointed out
[13:40] <Mirv> tsdgeos: thanks, took a note!
[13:40] <mzanetti> kgunn_, I think it's a bit risky to add all the MirSurface stuff for OTA-6
[13:40] <mzanetti> kgunn_, in a hangout about letterboxing atm
[13:40] <kgunn_> ack
[13:54] <dandrader> mzanetti, no, it's not. it's great! :)
[13:55] <mzanetti> the MirSurface?
[13:55] <dandrader> yeah
[13:56] <mzanetti> I'm sure it's great, but also late to test it properly
[13:59] <tsdgeos> ltinkl: do you want to do this one https://code.launchpad.net/~aacid/unity8/c++11connects/+merge/268483 ?
[13:59] <ltinkl> tsdgeos, sure, why not
[14:04] <ltinkl> tsdgeos, looks good, could you also please cover QSignalSpy signals connections?
[14:04] <ltinkl> tsdgeos, like QSignalSpy spy(lvwph, SIGNAL(contentYChanged()));
[14:04] <tsdgeos> ah right, i only grepped for SLOT
[14:04] <ltinkl> tsdgeos, that is also nice to have imo
[14:04] <tsdgeos> sure
[14:05] <tsdgeos> fixing
[14:05] <ltinkl> tsdgeos, ye well, not only QSignalSpy then, signal-to-signal connections too, I'd say even SIGNAL() to lambda (if there's any)
[14:05] <tsdgeos> yeaj
[14:06] <tsdgeos> i missed stuff like
[14:06] <tsdgeos> connect(GSettingsControllerQml::instance(), SIGNAL(usageModeChanged(const QString &)),
[14:06] <tsdgeos>             this, SIGNAL(usageModeChanged(const QString &)));
[14:06] <ltinkl> tsdgeos, oh ye, beware then there's a small gotcha, you can't connect to a slot having the same name as a signal
[14:07] <ltinkl> tsdgeos, you'd have to rename the slot
[14:07] <tsdgeos> sure
[14:07] <tsdgeos> that's not this case
[14:12] <mzanetti> dandrader, https://ci-train.ubuntu.com/job/ubuntu-landing-023-1-build/90/console
[14:19] <mzanetti> dandrader_, https://code.launchpad.net/~dandrader/unity-api/mirSurface-15.04/+merge/268484
[14:19] <mzanetti> erm... wrong link
[14:19] <mzanetti> dandrader_, did you see the conflicts I pasted?
[14:20] <mzanetti> https://ci-train.ubuntu.com/job/ubuntu-landing-023-1-build/92/console
[14:20] <mzanetti> I'm building a silo with your branches, testing if it fixes the issues and if we can land it
[14:20] <dandrader_> mzanetti, yeah, looking into it now.
[14:20] <cimi> tsdgeos, remaining tests to fix?
[14:20] <mzanetti> afaict the code is approved by gerry already, except unity8, which looks ok to me at a first glance
[14:21] <tsdgeos> cimi: i think none
[14:21] <tsdgeos> cimi: runs fine if you merge my branch again
[14:21] <greyback> mzanetti: I'm reviewing the unity8 code currently
[14:21] <mzanetti> ah, perfect
[14:21] <cimi> tsdgeos, I did
[14:21] <tsdgeos> cimi: i just pushed some fixes
[14:22] <greyback> mzanetti: should we make a silo? Ease testing, and get more eyes looking at it
[14:22] <mzanetti> greyback, on it
[14:22] <greyback> nice
[14:22] <mzanetti> have a merge conflice atm, daniel is fixing
[14:22] <mzanetti> will prepare the -gles branch now
[14:24] <tsdgeos> ltinkl: pushed
[14:26] <mterry> I'm getting errors building unity8 on wily due to unity-api and scopes not having a category_id field for activate() and preview() calls anymore.  Does that sound familiar?
[14:26] <mterry> dandrader_, ^ you were last to touch unity-api, but I don't know how far back that change goes
[14:27] <dandrader_> mterry, see the backlog
[14:27] <mterry> oh
[14:27] <mterry> hah
[14:27] <dandrader_> mterry, "lp:unity8 now needs lp:unity-api/trunk-15.04 instead of lp:unity-api"
=== dandrader_ is now known as dandrader
[14:28] <tsdgeos> mterry: i.e. don't use wily :D
[14:28] <tsdgeos> or feel the pain
[14:28] <tsdgeos> or help fixing it :D
[14:29] <mterry> dandrader, tsdgeos: so... what about dual landings?
[14:29] <dandrader> mterry, we are not landing to wily for now
[14:30] <dandrader> mterry, that's what I understood at least
[14:30] <mterry> that seems silly  :(
[14:30] <tsdgeos> mterry: we can't dual land
[14:31] <tsdgeos> and since we don't use wily for anything
[14:31] <tsdgeos> we've prioritized the thing we actually ship
[14:31] <mzanetti> greyback, https://code.launchpad.net/~mzanetti/qtmir/gles-sync/+merge/268488
[14:32] <greyback> mzanetti: just ot be safe, you need https://code.launchpad.net/~dandrader/unity-api/mirSurface-15.04/+merge/268484 instead of the unity-api branch you've in there
[14:32] <mzanetti> already replaced
[14:33] <mzanetti> F5 :)
[14:33] <mterry> tsdgeos, yeah...  but no Desktop Next work then?  And no love for any unity8 developer that wants to be on an actual release of Ubuntu Desktop?
[14:33] <greyback> mzanetti: reassign?
[14:33] <mterry> Surely the unity-api thing is fixable
[14:33] <mzanetti> greyback, shows this branch for me
[14:33] <greyback> mzanetti: I refreshed. Anyhoo
[14:34] <mzanetti> mterry, yeah... it's fixable, but as we can't dual-land, we lack manpower to do cherry-picking all day long
[14:34] <tsdgeos> mzanetti: standup?
[14:34] <mterry> mzanetti, I thought we had been dual landing.  Maybe I missed something.  Is this because CI jobs were running on wily, not vivid?
[14:35] <mzanetti> mterry, yeah, we've been dual landing until last week
[14:48] <mzanetti> mterry, so... what you could do, is to prepare a patch-set to make unity8 compile on wily...
[14:48] <mzanetti> mterry, then we could sync the vivid stuff over and re-apply that patchset
[14:49] <mzanetti> and sometimes release some binary to wily to unblock other people
[14:50] <mterry> mzanetti, I'm not sure I followed your sync-and-reapply bit.  But I believe in this case it just means copying the overlay version of unity-api over to wily, along with unity8, right?
[14:50] <mterry> mzanetti, I also have a spare vivid laptop here that I can use for unity8 development
[14:50] <mterry> mzanetti, so it's not like I'm blocked
[14:51] <mterry> mzanetti, I just expected us to care more about wily for Desktop Next purposes
[14:51] <mterry> :)
[14:51] <mterry> But no big deal if Desktop Next is a few releases behind either
[14:51] <mzanetti> mterry, so the main issue right now I think is that the codebase doesn't build on wily (unity-api driftet and whatnow)
[14:51] <mterry> mzanetti, right
[14:51] <mzanetti> mterry, so in order to build on both, our codebase needs to drift
[14:52] <mterry> mzanetti, or keep unity-api in sync?
[14:52] <mterry> unless there are other problems too..
[14:52] <mzanetti> yeah... I would have done that, not sure why pstolowski didn't want that
[14:53] <mterry> mzanetti, oh really?  so basically the unity-api patch was rejected "upstream"?
[14:54] <mterry> Maybe that's not a good characterization
[14:54] <mzanetti> well, I didn't really investigate what the exact bits and pieces are... but long story short, even if we fix unity-api, one of our other deps will bring us into the same situation soon
[14:54] <mterry> I mean that trunk doesn't actually want the vivid change?
[14:54] <pstolowski> mzanetti, mterry we had issues with c++ symbols in all our projects, which are completely different with gcc5. we have a solution for unity-scopes-api that will allow for a single source tree, but that required quite some changes
[14:55] <mterry> pstolowski, OK, so you didn't want to straight sync the binaries.  But there are actual API differences now between vivid and wily, with vivid having the newer changes
[14:55] <pstolowski> mterry, yes, but I've MPs to bring wily up to date
[14:55] <mterry> pstolowski, ah perfect!
[14:55] <dandrader> mzanetti, ok, merged trunk in lp:~dandrader/qtmir/mirSurface
[14:56] <mzanetti> dandrader, ta
[14:56] <pstolowski> mzanetti, mterry here is a glimpse what needed changing for single tree https://code.launchpad.net/~michihenning/unity-scopes-api/single-tree/+merge/268433
[14:57] <mterry> pstolowski, sure, it can get complicated for a library.
[14:58] <mterry> But unity8 is a dumb application, it usually just needs to recompile, as long as the API hasn't changed out from under it
[15:00] <tsdgeos> mzanetti: it's dependency names that are problematic
[15:00] <tsdgeos> err, mterry ↑
[15:01] <mterry> tsdgeos, those shouldn't have changed in the wily churn... right?
[15:01] <tsdgeos> mterry: not yet, but might in the future, which will make it impossible to dual land then
=== dandrader is now known as dandrader|afk
[15:02] <mterry> tsdgeos, sure...  It could happen.  But since both ubuntu tip and overlay tip are in our control, we can make them sync package names
[15:02] <mterry> And I'm struggling to think of why that would happen without our knowledge, unless some core library up and changes its package name
[15:02] <tsdgeos> i can see mir doing it for example
[15:03] <mterry> tsdgeos, well wouldn't it do that in wily too?
[15:03] <tsdgeos> i mean i can see them doing it in wily only
[15:03] <tsdgeos> once you're branched is easy to go wilder on wily
[15:03] <mterry> tsdgeos, ah fair.  Not everyone is dual landing like us
[15:03] <tsdgeos> right, almost noone is
[15:04] <tsdgeos> or that's my understanding
[15:04] <mzanetti> well, we're not any more either
[15:04] <mterry> We're just single landing  :)
[15:04] <mzanetti> the difference is, everything we do, is expected to end up in the customer devices asap
[15:04] <mzanetti> while noone (customer-wise) will be using our wily code in the next year at least
[15:04] <mzanetti> so... our priorities are clear
[15:05] <mterry> mzanetti, I'm on board with vivid being more important.  But you make it sound like wily is zero importance, and that doesn't seem like a fair characterization
[15:06] <mzanetti> another difference is, that other projects have like 2 branches in average for every landing
[15:06] <mzanetti> we mostly have around 10
[15:06] <mzanetti> that makes it significantly more complex to cherry-pick landings around
[15:07] <mterry> mzanetti, maybe wily is zero importance, if we only care about Phone and Personal, neither of which would track the dev cycle, right?
[15:07] <mterry> mzanetti, I still had it in my head that we were trying to support Desktop Next
[15:08] <mzanetti> mterry, what do you mean with "support Desktop Next"?
[15:09] <mterry> mzanetti, the idea that we'd want to let users run unity8 on the desktop.  That we ship an image with unity8 on it
[15:09] <mterry> mzanetti, seb128 worked on that a bunh
[15:10] <mterry> mzanetti, but that was down the "unity8 on desktop for 16.04" road
[15:10] <mzanetti> yeah... I'm not saying we don't want that... but I think it's low enough in priority that I'd rather hope for tooling to help us dual-land again
[15:10] <mzanetti> mterry, I've been brainstorming with sil2100 about a second debian/ repository to land over to wily
[15:10] <sil2100> Yeah, it's a possibility
[15:11] <sil2100> I suppose something like this should be possible and not super hard to do, but still... would require developer time anyway
[15:12] <mterry> mzanetti, I'll just use my vivid laptop for unity8, no biggie
[15:13]  * mterry waits for everyone to rebase on Snappy
[15:13] <mzanetti> mterry, I agree with your concerns tho... if we can't figure something to dual-land again soonish, we'll probably do some code-syncing with the patchset that I proposed before
[15:13] <mzanetti> mterry, I want to avoid merging and testing every single branch, because that requires a dedicated person for that
[15:13] <mzanetti> mterry, so I'd rather sync the tested code as is over to wily, and reapply a small patch every time that makes it build
[15:14] <mterry> mzanetti, yeah but you know that it may not work on wily like it works on vivid  :)
[15:14] <mterry> mzanetti, which is fine if it's a best-effort release situation
[15:15] <mzanetti> exactly... if bugs are reported we can fix that and include those in that patch-set (until that patch-set grows to big that starting to cherry-pick gets less efforts)
[15:19] <mterry> mzanetti, anyway, sorry to rehash a discussion it sounds like you've had plenty already  ;)
[15:21] <mzanetti> mterry, no worries
=== dandrader|afk is now known as dandrader
=== alan_g is now known as alan_g|EOD
[17:25] <mzanetti> dandrader, hey, testing silo 23 I have a feeling that the rendering performance dropped
[17:26] <mzanetti> actually it's more than a feeling by now
[17:28] <dandrader> ok...
[17:50] <mzanetti> dandrader, what are the child sessions we have? so far only trust-prompts or is there something else too?
[17:50] <mzanetti> oh, online accounts
[17:51] <mzanetti> can we identify trust-prompts in unity somehow?
[17:52] <dandrader> mzanetti, you mean visually? don't think so.
[17:52] <dandrader> mzanetti, actually I think they have a different animation to come in and go away
[17:53] <dandrader> mzanetti, but, well, the whole point is that you shouldn't be able to notice them
[17:53] <mzanetti> dandrader, trying to find a workaround to not move focus to the trust prompt (given there's 2 buttons only and we don't officially support plugged keyboards yet) but without breaking focus in e.g. online accounts
[17:54] <mzanetti> dandrader, no, not visually, programmatically. I'd like to distinguish trust-prompts from other sessions
[17:55] <dandrader> mzanetti, in unity8? well, look at SessionContainer code...
[17:55] <mzanetti> yes, that's where I'm atm
[17:56] <mzanetti> there is onFocusedChildChanged: { focusedChild.focus = true; }
[17:56] <mzanetti> this is the one that moves the focus over to the trust-prompt, breaking the camera-app
[17:58] <dandrader> mzanetti, so you don't wanna merge mirSurface?
[17:58] <dandrader> mzanetti, you sure it has a performance drop?
[18:00] <mzanetti> yes
[18:00] <mzanetti> hmmm
[18:10] <dandrader> mzanetti, yes for the first or for the second question?
[18:11] <mzanetti> both, I'm afraid
[18:11] <mzanetti> well, kgunn is giving it a try, maybe I'm just too sensitive and it is still good enough
[18:12] <dandrader> mzanetti, if you confirm it, do comment on the MP
[18:12] <mzanetti> ack
[18:12] <kgunn> what was the context ? i was knocked off irc for a bit
[18:12] <mzanetti> kgunn, I see a perf drop in 23
[18:12] <kgunn> mmm
[18:12] <kgunn> mzanetti: on what action ?
[18:13] <mzanetti> it does fix the issue, it does not seem to introduce new issues, but overall rendering seems worse
[18:13] <mzanetti> spread mostly...
[18:13] <kgunn> i literally took numbers a few days ago, should be easy to compare
[18:13] <mzanetti> but not even flicking the spread, even selecting an app
[18:13] <mzanetti> that was always smooth for me, seems stuttering now...
[18:13] <kgunn> so launching specifically ? or selecting an already launched app in the spread
[18:14] <mzanetti> the latter
[18:14] <mzanetti> but just give it a play, to see if you think it's good enough. maybe compare the numbers you have
[18:14] <mzanetti> I need some food now... starving
[18:16] <kgunn> go eat mzanetti , i'll profile virgin for that case then do the silo
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader