| tsdgeos | mzanetti: did you see the header being broken in your 1.3 apps? | 08:02 |
|---|---|---|
| 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:03 | |
| 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 | 08:04 |
| 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:00 |
| 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:01 |
| tsdgeos | :S | 09:02 |
| 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:06 |
| 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:12 |
| tsdgeos | cimi: please merge my branches to yours to see what's missing if anything | 09:56 |
| tsdgeos | from the tests i mean | 09: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 | ||
| tsdgeos | cimi: test is still failing in your branch for me :S | 10:47 |
| cimi | argh ok | 10:47 |
| 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 | 10:48 |
| 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:12 |
| mzanetti | tsdgeos, wfm | 11:13 |
| * tsdgeos does | 11:14 | |
| 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 | 11:23 |
| === vesar_lunch is now known as vesar | ||
| === vesar is now known as vesar_ | ||
| === vesar_ is now known as vesar__ | ||
| ltinkl | tsdgeos, fwiw, definitely a good idea imo, note there's a respective refactoring feature in the recent Qt Creator to achieve this | 11:33 |
| tsdgeos | ok | 11:35 |
| === alan_g|lunch is now known as alan_g | ||
| cimi | tsdgeos, fixed the tests for previewheader | 11:48 |
| cimi | tsdgeos, and merged el trunko | 11:48 |
| tsdgeos | cimi: cool | 12:36 |
| dandrader | mzanetti, so lp:unity8 now needs lp:unity-api/trunk-15.04 instead of lp:unity-api? | 12:49 |
| mzanetti | probably... | 12:49 |
| mzanetti | sounds about right | 12:50 |
| dandrader | mzanetti, 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 | ||
| greyback | pstolowski: can you answer ^^ | 12:55 |
| 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:01 |
| dandrader | pstolowski, so lp:unity8 is for vivid overlay then. then which unity8 branch is for wily? | 13:02 |
| 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:04 |
| 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:05 |
| dandrader | pstolowski, it doens't make any sense if there's no accompanying unity8 branch for it | 13:06 |
| 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:07 |
| pstolowski | dandrader, can you at least have a MP set to work-in-progress for now? | 13:10 |
| pstolowski | tsdgeos, it will soon | 13:11 |
| dandrader | pstolowski, sure | 13:13 |
| tsdgeos | pstolowski: :) | 13:15 |
| 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:36 |
| 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:38 |
| 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:39 |
| 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:40 |
| dandrader | mzanetti, no, it's not. it's great! :) | 13:54 |
| mzanetti | the MirSurface? | 13:55 |
| dandrader | yeah | 13:55 |
| mzanetti | I'm sure it's great, but also late to test it properly | 13:56 |
| 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 | 13:59 |
| 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:04 |
| 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:05 |
| 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:06 |
| ltinkl | tsdgeos, you'd have to rename the slot | 14:07 |
| tsdgeos | sure | 14:07 |
| tsdgeos | that's not this case | 14:07 |
| mzanetti | dandrader, https://ci-train.ubuntu.com/job/ubuntu-landing-023-1-build/90/console | 14:12 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| tsdgeos | ltinkl: pushed | 14:24 |
| 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:26 |
| 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" | 14:27 |
| === dandrader_ is now known as dandrader | ||
| 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:28 |
| mterry | dandrader, tsdgeos: so... what about dual landings? | 14:29 |
| dandrader | mterry, we are not landing to wily for now | 14:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| mzanetti | mterry, yeah, we've been dual landing until last week | 14:35 |
| 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:48 |
| mzanetti | and sometimes release some binary to wily to unblock other people | 14:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| mterry | mzanetti, oh really? so basically the unity-api patch was rejected "upstream"? | 14:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| mterry | pstolowski, sure, it can get complicated for a library. | 14:57 |
| 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 | 14:58 |
| tsdgeos | mzanetti: it's dependency names that are problematic | 15:00 |
| tsdgeos | err, mterry ↑ | 15:00 |
| 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 | 15:01 |
| === dandrader is now known as dandrader|afk | ||
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| mzanetti | mterry, what do you mean with "support Desktop Next"? | 15:08 |
| 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:09 |
| 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:10 |
| sil2100 | I suppose something like this should be possible and not super hard to do, but still... would require developer time anyway | 15:11 |
| mterry | mzanetti, I'll just use my vivid laptop for unity8, no biggie | 15:12 |
| * 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:13 |
| 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:14 |
| 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:15 |
| mterry | mzanetti, anyway, sorry to rehash a discussion it sounds like you've had plenty already ;) | 15:19 |
| mzanetti | mterry, no worries | 15:21 |
| === dandrader|afk is now known as dandrader | ||
| === alan_g is now known as alan_g|EOD | ||
| mzanetti | dandrader, hey, testing silo 23 I have a feeling that the rendering performance dropped | 17:25 |
| mzanetti | actually it's more than a feeling by now | 17:26 |
| dandrader | ok... | 17:28 |
| 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:50 |
| mzanetti | can we identify trust-prompts in unity somehow? | 17:51 |
| 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:52 |
| 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:53 |
| mzanetti | dandrader, no, not visually, programmatically. I'd like to distinguish trust-prompts from other sessions | 17:54 |
| dandrader | mzanetti, in unity8? well, look at SessionContainer code... | 17:55 |
| mzanetti | yes, that's where I'm atm | 17:55 |
| 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:56 |
| dandrader | mzanetti, so you don't wanna merge mirSurface? | 17:58 |
| dandrader | mzanetti, you sure it has a performance drop? | 17:58 |
| mzanetti | yes | 18:00 |
| mzanetti | hmmm | 18:00 |
| dandrader | mzanetti, yes for the first or for the second question? | 18:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| kgunn | go eat mzanetti , i'll profile virgin for that case then do the silo | 18: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!