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