[09:45] <Cimi> Saviq, tsdgeos what's the difference between openScope and gotoScope?
[09:46] <Saviq> Cimi, fav vs. non-fav
[09:46] <Cimi> ok
[09:46] <Saviq> or the other way 'round
[09:46] <Cimi> yeah other way
[09:46] <tsdgeos> yeah
[09:46] <tsdgeos> openscope is non fav
[09:46] <tsdgeos> goto scope is
[09:46] <Cimi> why don't we have a single call for them?
[09:46] <Saviq> Cimi, legacy, really
[09:47] <Saviq> Cimi, and the fact that the dash doesn't directly know whether it's fav or not, so the plugin gives us a hand
[10:07] <Cimi> Saviq, to fix run/run_on_device, shall we restart also unity8-dash or we can pass a variable to unity8 upstart with the bin for unity8-dash?
[10:07] <Saviq> Cimi, no, unity8-dash would need to be restarted, but it didn't work straight away when I tried it
[10:08] <Saviq> tsdgeos, network trouble?
[10:08] <tsdgeos> no, was playing with appmenu-qt5 in my irc client that just got upgraded to qt5
[10:08] <tsdgeos> i have two menus now :D
[10:09] <Saviq> :)
[10:11] <Cimi> Saviq, it does not, because we specify in run.sh just the binary for unity8, not for unity8-dash
[10:11] <Cimi> Saviq, so unity8 job then restarts the dash job which is the system-wide one
[10:11] <Cimi> Saviq, we have two options: restart in run.sh the local dash job
[10:12] <Saviq> Cimi, thanks for explaining, but guess what, I thought of that, and I did restart the dash with the right binary, but it didn't work locally IIRC
[10:12] <Cimi> Saviq, or make the unity8 job look for the local dash build, maybe with a variable or so
[10:12] <Cimi> Saviq, it worked here...
[10:12] <Saviq> Cimi, the unity8 job knows nothing about the dash
[10:12] <Saviq> Cimi, sure, if you solved this, MP it, we'll be sure to review
[10:12] <Cimi> Saviq, yesterday when I tried with restart unity8-dash BINARY=/path/to/your/unity8-dash
[10:12] <Saviq> Cimi, yes, I know that works
[10:13] <Saviq> Cimi, but when I put that in run.sh, it did not work well (either on device or locally, don't remember)
[10:13] <Cimi> Saviq, so my question is how can we tweak unity8 job to run that?
[10:13] <Saviq> Cimi, we don't
[10:13] <Saviq> Cimi, the unity8 job knows nothing about the dash
[10:13] <Saviq> Cimi, we need to tweak the run scripts to restart unity8-dash with the correct binary
[10:14] <Cimi> Saviq, well thje dash job restarts on unity8
[10:14] <Cimi> Saviq, if we could set a variable pointing to the right binary...
[10:14] <Saviq> Cimi, it doesn't restart, it starts and stops
[10:15] <Saviq> Cimi, that's exactly what "restart unity8-dash BINARY=..." does
[10:15] <Saviq> Cimi, but you can't do that in the unity8 job
[10:15] <Saviq> Cimi, because it has no idea about the dash
[10:15] <Saviq> Cimi, you need that in the run scripts, that will start the correct unity8 and then restart dash with the correct binary
[10:16] <Cimi> Saviq, I meant adding something to the unity8 dash job, check if a variable is set ($UNITY8_DASH_BINARY), otherwise run system wide
[10:17] <Saviq> Cimi, you'd have to set a global var like that, not sure we want that
[10:17] <Cimi> Saviq, we set a variable in run.sh, and we unset the variable at stop of unity8
[10:17] <Cimi> Saviq, so the variable is always unset, apart when we run run.sh
[10:18] <Saviq> Cimi, sure, that could work, not much different than going "restart unity8-dash BINARY=..." in the same run.sh script
[10:18] <Saviq> only thing is that the system-wide dash would be started first, but that's not really a problem IMO
[10:19] <Saviq> Cimi, if we did that, we should make the unity8 job itself respect that env var
[10:19] <Saviq> Cimi, but I'm worried it would easily get stale on Ctrl+C and such
[10:21] <Saviq> and then you'd get stuck with the local build until you reset that var manually
[10:21] <Cimi> Saviq, problem is that when we start unity8 in run.sh, this will start the dash
[10:21] <Saviq> Cimi, yes, and then we can restart dash with the right binary
[10:22] <Cimi> Saviq, with a sleep ?
[10:22] <Saviq> Cimi, no, straight away
[10:22] <Saviq> Cimi,
[10:22] <Saviq> unity8-dash starts as soon as unity8 started
[10:22] <Cimi> yeah
[10:22] <Saviq> which initctl start unity8 exits even later than that
[10:22] <Saviq> -which
[10:22] <Cimi> ah ok, cool
[10:23] <Cimi> thought was running in parallel
[10:24] <Cimi> Saviq, doing ctrl-c will not run the stop script of unity8 job?
[10:24] <Cimi> or post-stop
[10:24] <Saviq> Cimi, it will, assuming you actually deliver the ctrl+c
[10:25] <Saviq> Cimi, if you just unplug USB, nothing will happen
[10:25] <Saviq> Cimi, but recovering from that is a simple "restart unity8" away
[10:25] <Saviq> whereas with the global env you'd need to unset that env first
[10:26] <Cimi> we could unset the variable in unity8-dash start
[10:27] <Cimi> after the binary ran
[10:28] <Saviq> Cimi, that's putting more and more test considerations in a real-life job, wouldn't like that
[10:28] <Cimi> Saviq, ok, so let's just restart in run.sh
[10:28] <Saviq> Cimi, I'd rather us put an .override in ~/.config/upstart and remove "itself" in post-stop
[10:29] <Saviq> that could actually work and could mean we don't need to recommend installing unity8 on desktop, and make sure you always use the new job
[10:33] <mzanetti> Saviq: wouldn't it make more sense to make the dash not start at all with ./run.sh ?
[10:34] <mzanetti> you can just run ./builddir/src/Dash/unity8-dash to run the dash alone
[10:34] <Saviq> mzanetti, that depends, it's used on device as well
[10:34] <mzanetti> oh ok... I see the value for the device case
[10:34] <Saviq> mzanetti, run_on_device calls run.sh
[10:34] <mzanetti> but for local runs I think it's not useful
[10:35] <Saviq> dunno, as long as it runs the right one, I'd be happy
[10:35] <Saviq> especially since you have to remember -mousetouch to use the bottom edge etc.
[10:35] <mzanetti> Saviq: I would rather rather have a run-dash.sh
[10:35] <mzanetti> if you only need the shell, it's quite annoying that the dash is always popping up too
[10:36] <Saviq> sure, we could refactor all that
[10:39] <Saviq> and do away with .sh in the process ;P
[10:54] <tsdgeos> Cimi: Saviq: can you reproduce https://launchpadlibrarian.net/194886158/bug.png ?
[10:55] <Saviq> tsdgeos, no, I wonder if it's the Spanish version maybe
[10:55] <tsdgeos> i'm on spanish krillin
[10:55] <tsdgeos> can't either
[10:56] <Saviq> tsdgeos, do you have the "Lugares emblemátic..." category?
[10:56] <tsdgeos> yeah
[10:56] <tsdgeos> it fits just fine
[10:57] <tsdgeos> http://i.imgur.com/QalsvMJ.png
[10:58] <Saviq> oh that's interesting
[10:59] <Saviq> so it got elided
[10:59] <Saviq> so basically the chevron got huge, and the label is right-anchored to it
[10:59] <Saviq> so it elided
[10:59] <Saviq> now why would the chevron get huge?
[11:01] <Saviq> if I had to guess, RowLayout is playing with us
[11:01] <Cimi> sdk sdk sdk! :D
[11:01] <tsdgeos> it's weird
[11:01] <Saviq> Cimi, nope, it's all our components
[11:02] <tsdgeos> because victor mentions it's fine and just wrong after scrolling
[11:03] <tsdgeos> and the height of the icon is set to gu(2)
[11:16] <MacSlow> tsdgeos, mzanetti, Saviq: is there any way to alter the qmltest-makefiles to run uqmlscene under gdb?
[11:16] <mzanetti> MacSlow: make gdbtestFoo
[11:16] <MacSlow> mzanetti, thx
[11:17] <Saviq> MacSlow, you can always just copy-paste the qmltestrunner line, too
[11:18] <MacSlow> ok
[11:45] <tsdgeos> Saviq: how have you tried the new dash branches on rtm? i get errors if i try the branch directly
[11:45] <tsdgeos> http://paste.ubuntu.com/9755298/
[11:45] <tsdgeos> like i guess the sdk is too old or whatver
[11:45] <Saviq> tsdgeos, I cherry-picked
[11:46] <tsdgeos> i see
[11:46] <Saviq> tsdgeos, and depends what you mean "new dash branches"?
[11:46] <tsdgeos> i'll try that
[11:46] <tsdgeos> properVRangesCurrentScope and properRangesHorizontalCategories
[11:46] <Saviq> yeah, in general we can't run trunk on rtm any more, you need to cherry pick onto lp:unity8/rtm-14.09
[11:46] <Saviq> yeah those I didn't try yet
[11:46] <tsdgeos> ah ok
[11:47] <tsdgeos> Saviq: i tried vivid, but rtm krillin has more interesting scopes
[11:47] <Saviq> biab
[11:47] <Saviq> tsdgeos, yeah, definitely worth to try there
[11:59] <dandrader> mzanetti, did you enable the touch logging (TouchRegistry, DirectionalDragArea and TouchGate) in your dogfooding phone?
[11:59] <mzanetti> dandrader: not yet. was quite busy yesterday. wanted to do that *now*
[12:02] <mzanetti> dandrader: do you perhaps have some rtm packages with that enabled?
[12:02] <dandrader> mzanetti, I don't
[12:03] <mzanetti> I don't even know how to enable it...
[14:44] <tsdgeos> what is this thing? https://code.launchpad.net/~gerboland/unity8/initialSurfaceGeometry/+merge/231726
[14:44] <tsdgeos>  Proposed by Gerry Boland on 2014-08-21 ?
[14:44] <tsdgeos> greyback: ↑ ¿
[14:44] <greyback> tsdgeos: yeah, it's taken a while...
[14:45] <greyback> tsdgeos: it's ready to review, that and it's children. Saviq did a review ages ago, but found an issue that AP tests would hang.
[14:45] <greyback> Reason that it hung was because of the dash dbus blocking the mainloop thing
[14:46] <greyback> so now that fix landed, can now try land this!
[14:46] <Saviq> yeah, let's
[14:52] <tsdgeos> Saviq: you taking care or want me to have a look?
[14:53] <Saviq> tsdgeos, feel free, /me nursing silos still
[14:53] <tsdgeos> ok
[15:12] <kgunn> mterry: so rick said he never saw the poweroff dialog, but did experience the busy/slow resume
[15:20] <Saviq> kgunn, looks like the same that mterry experienced then https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1410830/comments/2
[15:20] <Saviq> mterry, do we even want the band-aid then?
[15:20] <mterry> Saviq, I missed kgunn's comment that you are responding to
 mterry: so rick said he never saw the poweroff dialog, but did experience the busy/slow resume
[15:21] <mterry> Saviq, I believe Rick was testing with the band-aid
[15:21] <Saviq> mterry, right, my comment was more about your experiences then
[15:22] <mterry> Saviq, Rick had previously reported being able to reproduce the shutdown dialog even with the MP that landed in rtm.
[15:22] <mterry> Saviq, so the difference now between him not reproducing seems to be the band-aid...  So I'd vote +1 for band-aid since it isn't making anything *worse* and might be helping
[15:22] <Saviq> that is true
[15:25] <mterry> Saviq, I guess the result of my findings in comment2 you linked is that the band-aid should be attached to Rick's bug, not mine
[15:25]  * mterry adjusts the LP connections
[15:30] <kgunn> mterry: yep, +1, i saw we get that code reviewed (just a couple of lines) and landed
[15:41] <Cimi> tsdgeos, any improvements on mem or CPU usage with your dash branches? did you measure that?
[15:44] <tsdgeos> Cimi: there's less mem usage, but wouldn't say it's noticeable
[15:51] <Cimi> sorry I dropped
[15:51] <Cimi> tsdgeos, any improvements on mem or CPU usage with your dash branches? did you measure that?
 Cimi: there's less mem usage, but wouldn't say it's noticeable
[15:52] <Cimi> well. less is good no?
[15:52] <Saviq> dednick, there's FTBFS with your rtm branch, could you have a look please?
[15:52] <Cimi> tsdgeos, one thing I saw when playing with signals, is that we send signals to the whole list of scopes
[15:52] <dednick> Saviq: sure
[15:52] <Cimi> tsdgeos, like a openScope sends stuff to all of them
[15:53] <Cimi> we need to take that into account when we connect to those
[15:53] <Cimi> if we have like 20+ scopes all doing stuff when an event occurs
[15:54] <sil2100> j ubuntu-meeting
[15:55] <sil2100> Crap...
[15:55] <dednick> Saviq: fixed.
[15:55] <tsdgeos> Cimi: hmm openScope sends signals to what?
[15:57] <Saviq> dednick, fast ;)
[15:57] <dednick> just forgot to remove a include :)
[15:58] <Cimi> tsdgeos, nevermind might be wrong on that
[15:58] <Cimi> tsdgeos, seems like was some debugging leftover
[16:10] <tsdgeos> greyback: do we still need the  QTimer::singleShot(0, this, SLOT(create())); in https://code.launchpad.net/~gerboland/unity8/initialSurfaceGeometry/+merge/231726 ?
[16:11] <greyback> tsdgeos: no, that shouldn't be needed. Will remove
[16:15] <greyback> tsdgeos: pushed
[16:15] <tsdgeos> tx
[16:27] <Saviq> dednick, "modelactionrootstate.cpp: multiple new lines at end of file"...
[16:30] <dednick> Saviq: fixed
[16:30] <Saviq> dednick, thanks
[16:39] <Cimi> tsdgeos, Saviq I'd like to call openScope(scope) from tst_Dash.qml to open a non-fav scope, do you know easily how I could get the argument scope?
[16:39] <tsdgeos> Cimi: the fake scopes have a get scope i think
[16:40] <Cimi> mmm
[16:40] <tsdgeos> yeaj
[16:40] <Cimi> yeah get scope
[16:40]  * Cimi tries
[16:41] <tsdgeos> that may only return fav scopes though
[16:41] <tsdgeos> Cimi: getScopeFromAll
[18:21] <Saviq> greyback, testing wakelock here, krillin/vivid, anything special I should test? IIUC the camera and media issues were not visible outside of krillin/rtm?
[18:22] <greyback> Saviq: I could repro the camera issue on stock vivid
[18:22] <greyback> Saviq: the impact is pretty minor otherwise
[18:22] <greyback> keep an eye on "sudo power-cli list" - it should list nothing 3 seconds after display off
[18:25] <Saviq> greyback, 1.5s, got the lower timeout in that silo as well ;)
[18:25] <greyback> Saviq: ah ok
[18:27] <Saviq> ok, done
[18:29] <Saviq> greyback, btw, noticed an interesting hack in unity-scope-click
[18:29] <Saviq> greyback, they added a moot autopkgtest to just go through building the package, which runs the usual unit tests
[18:29] <Saviq> greyback, sounds like qtmir would be a good candidate for that
[18:30] <greyback> Saviq: I'll add it to my list ;)
[18:31] <greyback> Saviq: em, where do I see it?
[18:33] <Saviq> greyback, https://code.launchpad.net/~saviq/qtmir/add-autopkgtest/+merge/246625
[18:34] <greyback> Saviq: oh thanks
[18:41] <Saviq> greyback, to test: `adt-run .// --- schroot vivid-amd64-shm`
[18:42] <Saviq> vivid-amd64-shm being an available schroot
[18:43] <Saviq> note bug #1396955 if you use byobu
[19:08] <dandrader> Saviq, when a process crashes a coredump is automatically generated, right? do you know where it is stored? will this whoopsie thing clean it up?