tsdgeosmzanetti: did you see the header being broken in your 1.3 apps?08:02
mzanettitsdgeos, I did before my time off, reported a bug, seems working fine now08:03
tsdgeosour 1.3 branch has lost the headers08:03
tsdgeosfile:///home/tsdgeos_work/phablet/unity8/sdk1.3_newUbuntuShape/qml/Dash/PageHeader.qml:243:13: QML PageHeadStyle: Binding loop detected for property "config"08:03
tsdgeosseems may be the culprit08:03
* tsdgeos investigates08:03
mzanettioh, I remember timp saying something08:04
mzanettibut that's a while ago08:04
mzanettihe should be able to help you if it turns out tricky08:04
tsdgeoscimi: ping09:00
cimitsdgeos, pong09:00
tsdgeoscimi: if you run all the ui tests on your branch some more will fail09:00
tsdgeosbut they also fail on my branch09:00
tsdgeosso i'm fixing those09:00
cimitsdgeos, bzr pull for the previewheader09:01
tsdgeosjust saying in case you run them and think "oh albert didn't see these ones, i'll fix them too"09:01
tsdgeoscool, so i'll fix these ones and then tell you so you remerge09:01
tsdgeosthere's a scary one though09:01
tsdgeosin DirectionalDragArea09:01
tsdgeosQFATAL : tst_DirectionalDragArea::withdrawTouchOwnershipCandidacyIfDisabledDuringRecognition(invisible) reached maximum number of OpenGL contexts supported by UbuntuShape09:01
greyback            // Don't bother with a dynamic array, let's just set a high enough maxShapeTextures and09: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
tsdgeosthe thing is09:12
tsdgeosit seems to me something is forgetting to delete something09:12
tsdgeosbecause it's at the end of the test09:12
tsdgeosmaybe not09:12
tsdgeoscimi: please merge my branches to yours to see what's missing if anything09:56
tsdgeosfrom the tests i mean09:56
* tsdgeos fixed the SDK so that tst_DirectionalDragArea passes :)09:57
=== alan_g is now known as alan_g|lunch
=== vesar is now known as vesar_lunch
tsdgeoscimi: test is still failing in your branch for me :S10:47
cimiargh ok10:47
tsdgeoscimi: make sure you merge my branch first too, so everything is more up to date10:48
cimiyeah will do10:48
cimiactusally will/did10:48
tsdgeosmzanetti: 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:12
mzanettitsdgeos, wfm11:13
* tsdgeos does11:14
cimifrom adb shell in recovery can I see what is going on with my system?11:23
cimimy arale keeps rebooting after wizard ended11:23
cimiflashed multiple times always same issue11:23
=== vesar_lunch is now known as vesar
=== vesar is now known as vesar_
=== vesar_ is now known as vesar__
ltinkltsdgeos, fwiw, definitely a good idea imo, note there's a respective refactoring feature in the recent Qt Creator to achieve this11:33
=== alan_g|lunch is now known as alan_g
cimitsdgeos, fixed the tests for previewheader11:48
cimitsdgeos, and merged el trunko11:48
tsdgeoscimi: cool12:36
dandradermzanetti, so lp:unity8 now needs lp:unity-api/trunk-15.04 instead of lp:unity-api?12:49
mzanettisounds about right12:50
dandradermzanetti, so I should resubmit https://code.launchpad.net/~dandrader/unity-api/mirSurface/+merge/264921 to point to this other branch instead, right?12:54
=== tedg is now known as ted
greybackpstolowski: can you answer ^^12:55
pstolowskidandrader, mzanetti, greyback correct trunk-15.04 is for vivid overlay. and you should prepare separate MP against lp:unity-api trunk for wily13:01
dandraderpstolowski, so lp:unity8 is for vivid overlay then. then which unity8 branch is for wily?13:02
pstolowskidandrader, greyback and tsdgeos decided not to branch off for vivid overlay and use trunk for the moment, then resolve it somehow for wily13:04
dandraderpstolowski, so I can just ignore lp:unity-api for now13:05
dandraderpstolowski, and work with lp:unity8 + lp:unity-api/trunk-15.0413:05
pstolowskidandrader, no, please have MP for lp:unity-api anyway so that we don't forget13:05
dandraderpstolowski, it doens't make any sense if there's no accompanying unity8 branch for it13:06
pstolowskidandrader, will it break anything if it's merged in wily without unity8 changes?13:07
tsdgeospstolowski: we'll fix unity8 for wily when there's a unity-shell-scopes that is usable :D13:07
tsdgeoswell probably not13:07
tsdgeosbut it's at least a pre-requisite :D13:07
dandraderso the vibe is to ignore wily for now. fine for me13:07
pstolowskidandrader, can you at least have a MP set to work-in-progress for now?13:10
pstolowskitsdgeos, it will soon13:11
dandraderpstolowski, sure13:13
tsdgeospstolowski: :)13:15
tsdgeosMirv: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/148491413:36
ubot5Ubuntu bug 1484914 in qtdeclarative-opensource-src (Ubuntu) "Memory leak in ThumbnailGenerator" [High,In progress]13:36
kgunn_mzanetti: looks like we're going for the MirSurface branches ?13:38
mzanettikgunn_, for me, josh's branch doesn't seem to fix the issue13:38
ltinkldandrader, https://code.launchpad.net/~lukas-kde/unity8/globalshortcuts have a look again please, I think I've addressed all the issues you'd pointed out13:39
Mirvtsdgeos: thanks, took a note!13:40
mzanettikgunn_, I think it's a bit risky to add all the MirSurface stuff for OTA-613:40
mzanettikgunn_, in a hangout about letterboxing atm13:40
dandradermzanetti, no, it's not. it's great! :)13:54
mzanettithe MirSurface?13:55
mzanettiI'm sure it's great, but also late to test it properly13:56
tsdgeosltinkl: do you want to do this one https://code.launchpad.net/~aacid/unity8/c++11connects/+merge/268483 ?13:59
ltinkltsdgeos, sure, why not13:59
ltinkltsdgeos, looks good, could you also please cover QSignalSpy signals connections?14:04
ltinkltsdgeos, like QSignalSpy spy(lvwph, SIGNAL(contentYChanged()));14:04
tsdgeosah right, i only grepped for SLOT14:04
ltinkltsdgeos, that is also nice to have imo14:04
ltinkltsdgeos, ye well, not only QSignalSpy then, signal-to-signal connections too, I'd say even SIGNAL() to lambda (if there's any)14:05
tsdgeosi missed stuff like14:06
tsdgeosconnect(GSettingsControllerQml::instance(), SIGNAL(usageModeChanged(const QString &)),14:06
tsdgeos            this, SIGNAL(usageModeChanged(const QString &)));14:06
ltinkltsdgeos, oh ye, beware then there's a small gotcha, you can't connect to a slot having the same name as a signal14:06
ltinkltsdgeos, you'd have to rename the slot14:07
tsdgeosthat's not this case14:07
mzanettidandrader, https://ci-train.ubuntu.com/job/ubuntu-landing-023-1-build/90/console14:12
mzanettidandrader_, https://code.launchpad.net/~dandrader/unity-api/mirSurface-15.04/+merge/26848414:19
mzanettierm... wrong link14:19
mzanettidandrader_, did you see the conflicts I pasted?14:19
mzanettiI'm building a silo with your branches, testing if it fixes the issues and if we can land it14:20
dandrader_mzanetti, yeah, looking into it now.14:20
cimitsdgeos, remaining tests to fix?14:20
mzanettiafaict the code is approved by gerry already, except unity8, which looks ok to me at a first glance14:20
tsdgeoscimi: i think none14:21
tsdgeoscimi: runs fine if you merge my branch again14:21
greybackmzanetti: I'm reviewing the unity8 code currently14:21
mzanettiah, perfect14:21
cimitsdgeos, I did14:21
tsdgeoscimi: i just pushed some fixes14:21
greybackmzanetti: should we make a silo? Ease testing, and get more eyes looking at it14:22
mzanettigreyback, on it14:22
mzanettihave a merge conflice atm, daniel is fixing14:22
mzanettiwill prepare the -gles branch now14:22
tsdgeosltinkl: pushed14:24
mterryI'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
mterrydandrader_, ^ you were last to touch unity-api, but I don't know how far back that change goes14:26
dandrader_mterry, see the backlog14:27
dandrader_mterry, "lp:unity8 now needs lp:unity-api/trunk-15.04 instead of lp:unity-api"14:27
=== dandrader_ is now known as dandrader
tsdgeosmterry: i.e. don't use wily :D14:28
tsdgeosor feel the pain14:28
tsdgeosor help fixing it :D14:28
mterrydandrader, tsdgeos: so... what about dual landings?14:29
dandradermterry, we are not landing to wily for now14:29
dandradermterry, that's what I understood at least14:30
mterrythat seems silly  :(14:30
tsdgeosmterry: we can't dual land14:30
tsdgeosand since we don't use wily for anything14:31
tsdgeoswe've prioritized the thing we actually ship14:31
mzanettigreyback, https://code.launchpad.net/~mzanetti/qtmir/gles-sync/+merge/26848814:31
greybackmzanetti: 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 there14:32
mzanettialready replaced14:32
mzanettiF5 :)14:33
mterrytsdgeos, 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
greybackmzanetti: reassign?14:33
mterrySurely the unity-api thing is fixable14:33
mzanettigreyback, shows this branch for me14:33
greybackmzanetti: I refreshed. Anyhoo14:33
mzanettimterry, yeah... it's fixable, but as we can't dual-land, we lack manpower to do cherry-picking all day long14:34
tsdgeosmzanetti: standup?14:34
mterrymzanetti, I thought we had been dual landing.  Maybe I missed something.  Is this because CI jobs were running on wily, not vivid?14:34
mzanettimterry, yeah, we've been dual landing until last week14:35
mzanettimterry, so... what you could do, is to prepare a patch-set to make unity8 compile on wily...14:48
mzanettimterry, then we could sync the vivid stuff over and re-apply that patchset14:48
mzanettiand sometimes release some binary to wily to unblock other people14:49
mterrymzanetti, 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
mterrymzanetti, I also have a spare vivid laptop here that I can use for unity8 development14:50
mterrymzanetti, so it's not like I'm blocked14:50
mterrymzanetti, I just expected us to care more about wily for Desktop Next purposes14:51
mterryBut no big deal if Desktop Next is a few releases behind either14:51
mzanettimterry, so the main issue right now I think is that the codebase doesn't build on wily (unity-api driftet and whatnow)14:51
mterrymzanetti, right14:51
mzanettimterry, so in order to build on both, our codebase needs to drift14:51
mterrymzanetti, or keep unity-api in sync?14:52
mterryunless there are other problems too..14:52
mzanettiyeah... I would have done that, not sure why pstolowski didn't want that14:52
mterrymzanetti, oh really?  so basically the unity-api patch was rejected "upstream"?14:53
mterryMaybe that's not a good characterization14:54
mzanettiwell, 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 soon14:54
mterryI mean that trunk doesn't actually want the vivid change?14:54
pstolowskimzanetti, 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 changes14:54
mterrypstolowski, 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 changes14:55
pstolowskimterry, yes, but I've MPs to bring wily up to date14:55
mterrypstolowski, ah perfect!14:55
dandradermzanetti, ok, merged trunk in lp:~dandrader/qtmir/mirSurface14:55
mzanettidandrader, ta14:56
pstolowskimzanetti, mterry here is a glimpse what needed changing for single tree https://code.launchpad.net/~michihenning/unity-scopes-api/single-tree/+merge/26843314:56
mterrypstolowski, sure, it can get complicated for a library.14:57
mterryBut unity8 is a dumb application, it usually just needs to recompile, as long as the API hasn't changed out from under it14:58
tsdgeosmzanetti: it's dependency names that are problematic15:00
tsdgeoserr, mterry ↑15:00
mterrytsdgeos, those shouldn't have changed in the wily churn... right?15:01
tsdgeosmterry: not yet, but might in the future, which will make it impossible to dual land then15:01
=== dandrader is now known as dandrader|afk
mterrytsdgeos, sure...  It could happen.  But since both ubuntu tip and overlay tip are in our control, we can make them sync package names15:02
mterryAnd I'm struggling to think of why that would happen without our knowledge, unless some core library up and changes its package name15:02
tsdgeosi can see mir doing it for example15:02
mterrytsdgeos, well wouldn't it do that in wily too?15:03
tsdgeosi mean i can see them doing it in wily only15:03
tsdgeosonce you're branched is easy to go wilder on wily15:03
mterrytsdgeos, ah fair.  Not everyone is dual landing like us15:03
tsdgeosright, almost noone is15:03
tsdgeosor that's my understanding15:04
mzanettiwell, we're not any more either15:04
mterryWe're just single landing  :)15:04
mzanettithe difference is, everything we do, is expected to end up in the customer devices asap15:04
mzanettiwhile noone (customer-wise) will be using our wily code in the next year at least15:04
mzanettiso... our priorities are clear15:04
mterrymzanetti, 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 characterization15:05
mzanettianother difference is, that other projects have like 2 branches in average for every landing15:06
mzanettiwe mostly have around 1015:06
mzanettithat makes it significantly more complex to cherry-pick landings around15:06
mterrymzanetti, maybe wily is zero importance, if we only care about Phone and Personal, neither of which would track the dev cycle, right?15:07
mterrymzanetti, I still had it in my head that we were trying to support Desktop Next15:07
mzanettimterry, what do you mean with "support Desktop Next"?15:08
mterrymzanetti, the idea that we'd want to let users run unity8 on the desktop.  That we ship an image with unity8 on it15:09
mterrymzanetti, seb128 worked on that a bunh15:09
mterrymzanetti, but that was down the "unity8 on desktop for 16.04" road15:10
mzanettiyeah... 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 again15:10
mzanettimterry, I've been brainstorming with sil2100 about a second debian/ repository to land over to wily15:10
sil2100Yeah, it's a possibility15:10
sil2100I suppose something like this should be possible and not super hard to do, but still... would require developer time anyway15:11
mterrymzanetti, I'll just use my vivid laptop for unity8, no biggie15:12
* mterry waits for everyone to rebase on Snappy15:13
mzanettimterry, 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 before15:13
mzanettimterry, I want to avoid merging and testing every single branch, because that requires a dedicated person for that15:13
mzanettimterry, so I'd rather sync the tested code as is over to wily, and reapply a small patch every time that makes it build15:13
mterrymzanetti, yeah but you know that it may not work on wily like it works on vivid  :)15:14
mterrymzanetti, which is fine if it's a best-effort release situation15:14
mzanettiexactly... 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:15
mterrymzanetti, anyway, sorry to rehash a discussion it sounds like you've had plenty already  ;)15:19
mzanettimterry, no worries15:21
=== dandrader|afk is now known as dandrader
=== alan_g is now known as alan_g|EOD
mzanettidandrader, hey, testing silo 23 I have a feeling that the rendering performance dropped17:25
mzanettiactually it's more than a feeling by now17:26
mzanettidandrader, what are the child sessions we have? so far only trust-prompts or is there something else too?17:50
mzanettioh, online accounts17:50
mzanettican we identify trust-prompts in unity somehow?17:51
dandradermzanetti, you mean visually? don't think so.17:52
dandradermzanetti, actually I think they have a different animation to come in and go away17:52
dandradermzanetti, but, well, the whole point is that you shouldn't be able to notice them17:53
mzanettidandrader, 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 accounts17:53
mzanettidandrader, no, not visually, programmatically. I'd like to distinguish trust-prompts from other sessions17:54
dandradermzanetti, in unity8? well, look at SessionContainer code...17:55
mzanettiyes, that's where I'm atm17:55
mzanettithere is onFocusedChildChanged: { focusedChild.focus = true; }17:56
mzanettithis is the one that moves the focus over to the trust-prompt, breaking the camera-app17:56
dandradermzanetti, so you don't wanna merge mirSurface?17:58
dandradermzanetti, you sure it has a performance drop?17:58
dandradermzanetti, yes for the first or for the second question?18:10
mzanettiboth, I'm afraid18:11
mzanettiwell, kgunn is giving it a try, maybe I'm just too sensitive and it is still good enough18:11
dandradermzanetti, if you confirm it, do comment on the MP18:12
kgunnwhat was the context ? i was knocked off irc for a bit18:12
mzanettikgunn, I see a perf drop in 2318:12
kgunnmzanetti: on what action ?18:12
mzanettiit does fix the issue, it does not seem to introduce new issues, but overall rendering seems worse18:13
mzanettispread mostly...18:13
kgunni literally took numbers a few days ago, should be easy to compare18:13
mzanettibut not even flicking the spread, even selecting an app18:13
mzanettithat was always smooth for me, seems stuttering now...18:13
kgunnso launching specifically ? or selecting an already launched app in the spread18:13
mzanettithe latter18:14
mzanettibut just give it a play, to see if you think it's good enough. maybe compare the numbers you have18:14
mzanettiI need some food now... starving18:14
kgunngo eat mzanetti , i'll profile virgin for that case then do the silo18:16
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!