[08:21] <Saviq> pstolowski, the "search" part from https://wiki.ubuntu.com/Process/Merges/TestPlan/Unity8%20-%20Manage%20Dash can go away now, right?
[08:21] <pstolowski> Saviq, right, I forgot to update
[08:22] <Saviq> pstolowski, nw
[08:24] <pstolowski> thanks
[09:01] <tsdgeos> pstolowski: can you update the silo with my new branch? it has merges from trunk
[09:03] <pstolowski> tsdgeos, sure
[09:27] <Saviq> greyback, I kinda hijacked your qtmir branches for cmake, might wanna look through the latest changes
[09:27] <Saviq> greyback, also adding cmake-extras to the silo
[09:27] <greyback> Saviq: so I've observed
[09:28] <Saviq> greyback, seems -gles was really behind on debian/control changes, too...
[09:28] <Saviq> we need to do a better job there
[09:32]  * tsdgeos does evil eyes to unity-scopes- click for not using -j10 even if told to
[09:33] <tsdgeos> Saviq: Cimi: who is reviewing https://code.launchpad.net/~aacid/unity8/moreAsyncDash/+merge/241524 ?
[09:33] <greyback> Saviq: your OCD in debian/control showing :)
[09:33] <Saviq> greyback, wrap-and-sort -at
[09:33] <Saviq> greyback, but yeah, there's some of that
[09:34]  * greyback learns new command
[09:34] <Saviq> greyback, unfortunately it breaks comments
[09:34] <Saviq> greyback, so some manual love is needed afterwards
[09:34] <Saviq> but once it's done it's easy to keep sorted
[09:34] <Cimi> tsdgeos, I can
[09:35] <tsdgeos> Cimi: cool :)
[09:39] <Saviq> tsdgeos, see you found a scapegoat
[09:40] <tsdgeos> pstolowski: there?
[09:41] <Cimi> greyback, found an issue with shell rotation
[09:41] <pstolowski> tsdgeos, yes
[09:41] <greyback> Cimi: go on
[09:41] <Cimi> greyback, open gallery that is a fullscreen app
[09:41] <Cimi> greyback, power button to lock screen
[09:42] <Cimi> greyback, power to wake
[09:42] <Cimi> greyback, unlock
[09:42] <tsdgeos> pstolowski: i've tested that branch you gave me yesterday
[09:42] <Saviq> greyback, ok all that looks promising
[09:42] <Cimi> see a slow animation from greeter to gallery fullscreen
[09:42] <tsdgeos> and yes, if dash is in "utilities" and i go to the store, it ends in in "all" not in "utilities"
[09:42] <tsdgeos> but that's what scope.currentNavigationId is saying
[09:43] <greyback> Cimi: please add to our bug-tracking spreadsheet: https://docs.google.com/a/canonical.com/spreadsheets/d/140Icn5zcZwMvg1SONrwRKXYip-Pie7jtbEARpWwgxfw/edit#gid=0
[09:43] <tsdgeos> pstolowski: maybe scopes-shell needs changing? or the scope? how do i debug what the scope think it's returning as current navigation id?
[09:45] <greyback> Saviq: thanks for the help there.
[09:45] <pstolowski> tsdgeos, the scope get current nav id with search request (and you can tell it's ok looking at the search results). i think what's important is what shell thinks is the current nav id. I think you can get it via a property of Scope
[09:46] <Saviq> greyback, pleasure
[09:46] <tsdgeos> pstolowski: that's exactly what i am sayiing
[09:46] <tsdgeos> pstolowski: that property says it's all
[09:46] <pstolowski> tsdgeos, ah sorry, missed one sentence
[09:47] <pstolowski> tsdgeos, hmm, maybe plugin has a bug then
[09:47] <pstolowski> tsdgeos, ok, i'll debug the plugin and see
[09:47] <pstolowski> tsdgeos, thanks for looking at it
[09:48] <tsdgeos> no worries :) tell me if you need me to have a look at it again or something
[09:51] <Cimi> tsdgeos, added a comment
[09:51] <Cimi> greyback, added bug
[09:55] <greyback> Cimi: thanks
[09:55] <tsdgeos> Cimi: answered
[09:55] <greyback> Cimi: that's on phone, right?
[09:56] <Cimi> greyback, mako
[09:56] <greyback> Cimi: we have that bug on trunk right now actually
[10:09] <Cimi> tsdgeos, if cacheBuffer is int, shouldn't setCacheBuffer accept int and not qreal?
[10:10] <tsdgeos> Cimi: that sounds sensible
[10:10] <tsdgeos> let me fix it
[10:12] <Cimi> tsdgeos, also, when we add a negative cacheBuffer, shall we set 0 or not? what qt does when properties are set wrongly?
[10:12] <tsdgeos> the same
[10:12] <tsdgeos> ./qquickitemview.cpp:458:        qmlInfo(this) << "Cannot set a negative cache buffer";
[10:12] <Cimi> ok
[10:43] <pstolowski> tsdgeos, i'm getting plenty of "QGridLayoutEngine::addItem: Cell (0, 0) already taken" messages in unity8-dash.log; known?
[10:43] <Cimi> greyback, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1398770
[10:45] <tsdgeos> pstolowski: yeah, i've seen them too, don't seem to cause problems tbh
[10:45] <tsdgeos> but may be worth investigating more
[10:46] <greyback> Cimi: thank, but I marked as duplicate of bug 1398770
[10:46] <pstolowski> tsdgeos, ack
[10:46] <tsdgeos> pstolowski: i'll make a note here to investigate it
[10:48] <pstolowski> tsdgeos, k, thanks
[11:03] <Saviq> greyback, hmm I broke -gles somehow
[11:04] <Saviq> can't get the build deps resolved
[11:04]  * greyback looks
[11:06] <Saviq> huh
[11:06] <tsdgeos> Cimi: ok, pushed
[11:07] <Saviq> greyback, ok it's the libqt5gui5-gles dep
[11:07] <greyback> you removed it?
[11:07] <Saviq> greyback, yeah, and I tried that first
[11:07] <Saviq> greyback, but somehow sbuild still couldn't resolve ¿?
[11:07] <Saviq> but apt-get build-dep did
[11:07] <greyback> huh
[11:09] <Saviq> greyback, the test dep seems not needed though
[11:09] <Saviq> no wait, checking again
[11:09] <Saviq> yeah
[11:10] <Saviq> verifying
[11:11] <Saviq> ok that's not good, apt-get seems to resolve everything fine, but not sbuild
[11:14] <facundobatista> Holas
[11:17] <greyback> Saviq: doesn't sbuild use an apt-based resolver to determine dependencies (by default)?
[11:17] <Saviq> greyback, yeah, but not build-dep, but a dummy package (what mk-build-deps does)
[11:18] <greyback> ah
[11:19] <Saviq> greyback, hmm, TBH I might've broken something locally, can't get it to work on trunk either...
[11:20] <Saviq> *or* something broke with qt
[11:21]  * Saviq adds the dep blindly
[11:56] <mzanetti> tsdgeos: I don't think this conflicts, if you merge it with the prereq, not with trunk: https://code.launchpad.net/~mzanetti/unity8/buttons-in-panel/+merge/242644
[11:57] <mzanetti> anyways... merge it neverthelles
[11:57] <mzanetti> -l+s
[11:58] <mzanetti> ok. let's try again:
[11:58] <mzanetti> anyways... merged it nevertheless
[11:58] <mzanetti> :)
[12:03] <pstolowski> tsdgeos, i've found the issue with current department id in shell plugin which could be reset to default depending on timing (we had a race); i've a fix, with it looks correct now, but i don't see any siblings (my modified scope now reports all departments all the time now)
[12:04] <pstolowski> tsdgeos, so it can be now another issue with navigation models in the plugin (i'm not familiar too much with that yet), or uniyt8
[12:09] <Cimi> tsdgeos, when you calculate displayMarginBeginning and End, you use a lot of - signs
[12:09] <Cimi> tsdgeos, looks like it can be simplified
[12:10] <Cimi> mmm maybe not because they are min and max...
[12:11] <Cimi> I got the logic after
[12:19] <Saviq> greyback, ok yeah, libqt5gui5-gles and libqt5quicktest5 are indeed required, it's building in the PPA now
[12:20] <Saviq> greyback, don't ask me why it didn't work in my sbuild :/
[12:20] <greyback> Saviq: ok good. /me was also fighting with my sbuild
[12:20] <Saviq> and would be nice if we understood why those are needed, and maybe get rid of them (or at least comment)
[12:21] <Saviq> Mirv, hey, if you look at the build failures in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-001/+sourcepub/4600234/+listing-archive-extra
[12:21] <Saviq> Mirv, I had to add libqt5gui5-gles and libqt5quicktest5 to B-Ds for the builder to resolve deps
[12:22] <Saviq> Mirv, any idea why's that and what could we do about it (or do we just wait for runtime GL detection instead?)
[12:47] <Mirv> Saviq: hmm, no, I don't know why it would change in any way from what it used to be in the past. but it would look like to me the previous landing also already had them both? https://launchpadlibrarian.net/191126103/qtmir-gles_0.4.4%2B15.04.20141124-0ubuntu1.diff.gz
[12:48] <Saviq> Mirv, oh yeah, it was like that for a while
[12:48] <Saviq> Mirv, I was just doing some clean up
[12:48] <Saviq> and was wondering if we know where this comes from
[12:54] <Mirv> Saviq: r_salveti understands the gles packages best. my simple guess is that the "or" dependencies cause the need to specify some -gles package separately even when compiling against qtbase5-gles-dev. for example UI Toolkit depends on qt5-qmake-gles, qt5-qmake-gles, qtbase5-private-gles-dev and libqt5quick5-gles
[12:54] <Mirv> and that has been since the first gles version of that https://launchpadlibrarian.net/175113669/ubuntu-ui-toolkit-gles_0.1.46%2B14.10.20140502.6-0ubuntu2.diff.gz
[12:55] <Mirv> Saviq: maybe if you depended on qt5-qmake-gles, qt5-qmake-gles, qtbase5-private-gles-dev, you wouldn't need the libqt5gui5-gles
[12:55] <Mirv> but that isn't any cleaner
[12:55] <Saviq> Mirv, yeah
[13:59] <tsdgeos> mzanetti: i think the issue was that the prereq didn't merge, and thus all the dependents didn't either
[14:00] <tsdgeos> mzanetti: failing qmluitests in https://code.launchpad.net/~mzanetti/unity8/wallpaper/+merge/242461 ?
[14:30] <kgunn> bug 1367822
[14:35] <mterry> Cimi, the wizard is basically ready to go in a silo -- you can test it if you like, vivid silo 3 -- just needs an approve on the tests branch
[14:37] <mzanetti> tsdgeos: there isn't much chance that its related to that branch though
[14:38] <tsdgeos> mzanetti: no?
[14:38] <tsdgeos> mzanetti: seems the only branch with this failure i could find
[14:38] <mzanetti> tsdgeos: doesn't touch neither that code, nor that test
[14:39] <tsdgeos> let me see if i can repro
[14:39] <mzanetti> tsdgeos: I had fixed some flakyness of that test yesterday in another branch though
[14:40] <mzanetti> let me see if it got merged yet
[14:40] <mzanetti> yeah, it's merged
[14:40] <mzanetti> with the reversible-spread branch... exactly this was failing too
[14:42] <mzanetti> actually its a bit different
[14:42] <mzanetti> yesterday it was failing in <position1, now it's failing in >position3
[14:42] <mzanetti> will dig into it, but I'm sure it's not related to that wallpaper branch
[15:40] <balloons> mzanetti, I noticed the desktop-next iso allows you to install from the store without issue. And in general it's a bit different than the unity8 vm setup . .  Any idea why this is? I assume there is an RTM branch of unity8 as well as a vivid branch (perhaps more), but I would expect the image and installed versions to line up
[15:41] <mzanetti> balloons: I think it's related to some packagekit plugin/config which differs on a standard desktop
[15:42] <mzanetti> but I'm not exactly sure what it is
[15:45] <balloons> hmm... I'll try the latest lxc version as well. Might be a bit confusing to folks. I'm anxiously waiting for your desktop-stage branch to land
[15:51] <mzanetti> hah! I love to see one high-dpi fix coming in after another :D
[15:51] <mzanetti> as of today my screensaver is full screen again :D
[16:18] <mterry> Cimi, I made vivid silo 3 with all the wizard stuff, if you want to test again.  Just needs the tests branch to be approved and we can land
[16:19] <Cimi> mterry, yup, saw
[16:19] <mterry> Cimi, ok I thought I sent that earlier, but couldn't find it in my scrollback
[16:19] <Cimi> mterry, you did yup
[16:19] <mterry> :)
[16:19] <mterry> my damn internet connection has been crazy today, thought IRC ate it
[16:19] <Cimi> mterry, was having lunch then we had standup
[16:20] <Cimi> mterry, so I didn't reply
[16:20] <mterry> sure
[16:20] <Cimi> mterry, but I was already having a look earleir to the code
[16:51] <mzanetti> balloons: the branches are approved by now
[16:51] <mzanetti> balloons: so unless I messed up and broke something that'll be caught in the silo review, they should go in with the next batch
[16:52] <balloons> mzanetti, excellent. That will be a big boost to using it on the desktop. I'm sitting on a post waiting for it
[16:53] <mzanetti> O_o
[16:53] <mzanetti> I hope that post says that it's not finished yet, but rather a start of a long process
[16:54] <balloons> basically yes. I want to push people to using it on the desktop. I'd like to personally run it as a daily driver this cycle and convince some others to do the same. No pressure :-)
[16:54] <balloons> for now, it's just testing
[17:10] <Cimi> mterry, still one test to fix
[17:11] <mterry> cimi, uh oh which one?
[17:11] <Cimi> mterry, test_locationHereTerms
[17:11] <Cimi> mterry, could be for the " " check?
[17:13] <mterry> cimi, I don't get that failure.  is that local or in jenkins?
[17:14] <Cimi> mterry, jenkins
[17:14] <mterry> cimi, ah!  I only noticed the PhoneStage::test_enterSpread  failure
[17:14] <Cimi> https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/187/testReport/(root)/qmltestrunner/Wizard__test_locationHereTerms/
[17:15] <mterry> cimi, yeah I see it now
[17:15] <mterry> cimi, am looking, thanks.  duh
[17:15] <mterry> cimi, I bet it's because assigning 1i8n.language = "fr" doesn't do what I want if the french locale isn't setup
[17:16] <Cimi> ok..
[17:18] <mterry> oh actually, it's because Ubuntu.Web isn't installed
[17:23] <mterry> cimi, done
[17:23] <Cimi> mterry, let's wait jenkins then we can approve
[17:23] <mterry> cimi, yeah definitely, it's catching dep stuff that I wouldn't notice  :)
[18:13]  * mterry goes afk for a bit
[19:01] <mterry> Cimi, looks like wizard tests passed, yay!  (I was worried there would be some other dep needed)
[19:07] <Cimi> mterry, i'll approve soon
[22:49] <veebers> Saviq: What do you know about the edge demo? I have some queries, mainly can I start it with testability :-)
[22:50] <Saviq> veebers, not really, it's being redesigned, so will get a rework
[22:50] <Saviq> veebers, mterry knows best
[22:51] <veebers> Saviq: ok cool, so that's both first boot wizard and the edges demo that's getting reworked? (I'll ping mterry too)
[22:51] <Saviq> veebers, to some extent, yes, wizard is being moved into the unity8 tree right now
[22:52] <veebers> Saviq: ok, one more question :-) Any idea of when the rework for the edges demo will be complete/usable
[22:52] <Saviq> veebers, https://code.launchpad.net/~mterry/unity8/wizard-import/+merge/242245 and https://code.launchpad.net/~mterry/unity8/wizard-plugin/+merge/241912 and https://code.launchpad.net/~mterry/unity8/wizard-tests/+merge/242525
[22:52] <Saviq> veebers, there's no final design yet, so dunno
[22:52] <veebers> Saviq: cool, thanks for the info
[22:53] <Saviq> veebers, if you want to have a look, here's the design docs, but WiP still https://sites.google.com/a/canonical.com/apps-and-platform-team/3-platform/6-greeter
[22:56] <veebers> Saviq: fyi, we're looking at automating some of the sanity tests. I'm keen to get something for the demo, even if it's getting changed in the future.
[22:56] <Saviq> veebers, I understand, just saying don't spend much time on getting them Right™, clean and everything
[22:57] <Saviq> veebers, for now dirty is good enough
[22:58] <veebers> Saviq: heh, ack :-)