| === greyback__ is now known as greyback | ||
| Cimi | Saviq, tsdgeos what's the difference between openScope and gotoScope? | 09:45 |
|---|---|---|
| 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:46 |
| 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 | 09:47 |
| === timon_ is now known as t-mon | ||
| 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:07 |
| 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:08 |
| Saviq | :) | 10:09 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| Cimi | thought was running in parallel | 10:23 |
| 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:24 |
| 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:25 |
| Cimi | we could unset the variable in unity8-dash start | 10:26 |
| Cimi | after the binary ran | 10:27 |
| 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:28 |
| 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:29 |
| mzanetti | Saviq: wouldn't it make more sense to make the dash not start at all with ./run.sh ? | 10:33 |
| 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:34 |
| 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:35 |
| Saviq | sure, we could refactor all that | 10:36 |
| Saviq | and do away with .sh in the process ;P | 10:39 |
| tsdgeos | Cimi: Saviq: can you reproduce https://launchpadlibrarian.net/194886158/bug.png ? | 10:54 |
| 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:55 |
| Saviq | tsdgeos, do you have the "Lugares emblemátic..." category? | 10:56 |
| tsdgeos | yeah | 10:56 |
| tsdgeos | it fits just fine | 10:56 |
| tsdgeos | http://i.imgur.com/QalsvMJ.png | 10:57 |
| Saviq | oh that's interesting | 10:58 |
| 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? | 10:59 |
| 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:01 |
| tsdgeos | because victor mentions it's fine and just wrong after scrolling | 11:02 |
| tsdgeos | and the height of the icon is set to gu(2) | 11:03 |
| 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:16 |
| Saviq | MacSlow, you can always just copy-paste the qmltestrunner line, too | 11:17 |
| MacSlow | ok | 11:18 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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* | 11:59 |
| mzanetti | dandrader: do you perhaps have some rtm packages with that enabled? | 12:02 |
| dandrader | mzanetti, I don't | 12:02 |
| mzanetti | I don't even know how to enable it... | 12:03 |
| === 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 | ||
| 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:44 |
| 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:45 |
| greyback | so now that fix landed, can now try land this! | 14:46 |
| Saviq | yeah, let's | 14:46 |
| tsdgeos | Saviq: you taking care or want me to have a look? | 14:52 |
| Saviq | tsdgeos, feel free, /me nursing silos still | 14:53 |
| tsdgeos | ok | 14:53 |
| kgunn | mterry: so rick said he never saw the poweroff dialog, but did experience the busy/slow resume | 15:12 |
| Saviq | kgunn, looks like the same that mterry experienced then https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1410830/comments/2 | 15:20 |
| ubot5 | Launchpad bug 1410830 in unity8 (Ubuntu) "Shutdown dialog appears on resume, after a long delay in screen turning on" [Undecided,In progress] | 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 | 15:20 |
| Saviq | <kgunn> 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:21 |
| 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:22 |
| 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:25 | |
| kgunn | mterry: yep, +1, i saw we get that code reviewed (just a couple of lines) and landed | 15:30 |
| Cimi | tsdgeos, any improvements on mem or CPU usage with your dash branches? did you measure that? | 15:41 |
| === dandrader is now known as dandrader|lunch | ||
| tsdgeos | Cimi: there's less mem usage, but wouldn't say it's noticeable | 15:44 |
| Cimi | sorry I dropped | 15:51 |
| Cimi | tsdgeos, any improvements on mem or CPU usage with your dash branches? did you measure that? | 15:51 |
| Saviq | <tsdgeos> Cimi: there's less mem usage, but wouldn't say it's noticeable | 15:51 |
| 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:52 |
| 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:53 |
| sil2100 | j ubuntu-meeting | 15:54 |
| sil2100 | Crap... | 15:55 |
| dednick | Saviq: fixed. | 15:55 |
| tsdgeos | Cimi: hmm openScope sends signals to what? | 15:55 |
| Saviq | dednick, fast ;) | 15:57 |
| dednick | just forgot to remove a include :) | 15:57 |
| Cimi | tsdgeos, nevermind might be wrong on that | 15:58 |
| Cimi | tsdgeos, seems like was some debugging leftover | 15:58 |
| tsdgeos | greyback: do we still need the QTimer::singleShot(0, this, SLOT(create())); in https://code.launchpad.net/~gerboland/unity8/initialSurfaceGeometry/+merge/231726 ? | 16:10 |
| greyback | tsdgeos: no, that shouldn't be needed. Will remove | 16:11 |
| greyback | tsdgeos: pushed | 16:15 |
| tsdgeos | tx | 16:15 |
| Saviq | dednick, "modelactionrootstate.cpp: multiple new lines at end of file"... | 16:27 |
| dednick | Saviq: fixed | 16:30 |
| Saviq | dednick, thanks | 16:30 |
| 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:39 |
| Cimi | mmm | 16:40 |
| tsdgeos | yeaj | 16:40 |
| Cimi | yeah get scope | 16:40 |
| * Cimi tries | 16:40 | |
| tsdgeos | that may only return fav scopes though | 16:41 |
| tsdgeos | Cimi: getScopeFromAll | 16:41 |
| === dandrader|lunch is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| 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:21 |
| 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:22 |
| Saviq | greyback, 1.5s, got the lower timeout in that silo as well ;) | 18:25 |
| greyback | Saviq: ah ok | 18:25 |
| Saviq | ok, done | 18:27 |
| 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:29 |
| greyback | Saviq: I'll add it to my list ;) | 18:30 |
| greyback | Saviq: em, where do I see it? | 18:31 |
| Saviq | greyback, https://code.launchpad.net/~saviq/qtmir/add-autopkgtest/+merge/246625 | 18:33 |
| greyback | Saviq: oh thanks | 18:34 |
| Saviq | greyback, to test: `adt-run .// --- schroot vivid-amd64-shm` | 18:41 |
| Saviq | vivid-amd64-shm being an available schroot | 18:42 |
| Saviq | note bug #1396955 if you use byobu | 18:43 |
| ubot5 | bug 1396955 in autopkgtest (Ubuntu) "adt-run fails if sourcing ~/.profile fails" [Medium,Triaged] https://launchpad.net/bugs/1396955 | 18:43 |
| === alan_g|afk is now known as alan_g | ||
| 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? | 19:08 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
