[08:59] <mzanetti> o/
[09:09] <tsdgeos> mzanetti: welcome bac
[09:09] <tsdgeos> k
[09:09] <Saviq> mzanetti, \o
[09:20] <MacSlow> mzanetti, hey there
[09:20] <MacSlow> mzanetti, happy new year btw
[09:21] <mzanetti> MacSlow: hey, thanks. happy new year you too
[10:28] <Cimi> tsdgeos, I tested your branches, they seem fine
[10:28] <Cimi> tsdgeos, which tests you said you wanted to add?
[10:29] <tsdgeos> the one i added to https://code.launchpad.net/~aacid/unity8/departmentListHorizontalScroll/+merge/245580
[10:29] <Cimi> ok
[10:29] <tsdgeos> which failed ^_^
[10:29] <Cimi> tsdgeos, yeah saw that
[10:29] <tsdgeos> it should be running again after my last commit
[10:29] <tsdgeos> let's see how it goes
[10:29] <tsdgeos> i couldn't reproduce it failing here even in a loop
[10:30] <Cimi> do uou think is possible to fix the pageheader height instead clipping?
[10:30] <Cimi> on the other branch
[10:31] <tsdgeos> not as the code stands now
[10:32] <Cimi> rebooting router, back in a min
[10:34] <tsdgeos> Mirv: ping
[10:43] <Mirv> tsdgeos: pong
[10:45] <tsdgeos> Mirv: about the qt5.4 issue i was wondering if you could rebuild the stuff with http://paste.ubuntu.com/9686974/ and removing the -reduce-relocations from debian/rules
[10:45] <tsdgeos> since this was one of the things that was causing problems in 5.3 and then our linker got fixed
[10:45] <tsdgeos> but maybe not totally fixed?
[10:46] <tsdgeos> i tried compiling myself but qtdeclarative-opensource-src is failing to dpkg-package for some reason :/
[10:48] <tsdgeos> grrr stupid https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/245/console failed
[10:49]  * tsdgeos hits rebuild
[10:51] <Mirv> tsdgeos: right.. so that paste is actually the manual our patch reverting upstream lines since we got the updated binutils.
[10:51] <Mirv> so I can comment out the patch. plus comment out the configure option.
[10:51] <tsdgeos> right
[10:51] <tsdgeos> see if it helps
[10:51] <Mirv> I'm in a middle of enabling qtbase tests but I can also comment out that..
[10:52] <tsdgeos> oki
[11:04] <tsdgeos> greyback: did you have time to test https://code.launchpad.net/~aacid/qtmir/create_observer_sooner/+merge/244622 ?
[11:05] <greyback> tsdgeos: hey, no I must do that now
[11:05] <greyback> had slipped my mind
[11:05] <Mirv> tsdgeos: 5.4.0+dfsg-4ubuntu1~vivid1~test2 building with http://pastebin.ubuntu.com/9687032/
[11:06] <tsdgeos> oki
[11:09] <tsdgeos> greyback: oki
[11:46] <tsdgeos> MacSlow: how's https://code.launchpad.net/~macslow/unity8/swipe-dismiss-snap-decisions/+merge/233347 going?
[11:46] <MacSlow> tsdgeos, working on it to get to work
[11:46] <tsdgeos> :)
[11:46] <MacSlow> tsdgeos, setting actions is giving me a headache atm
[11:47] <MacSlow> getting segfaults where I didn't expect them... especially since the real (non-mock) implemenation works flawlessly
[11:48] <tsdgeos> :(
[11:52] <MacSlow> tsdgeos, but I'm getting there
[11:52] <MacSlow> two of three segfaults are already eliminated
[12:15] <tsdgeos> MacSlow|lunch: https://code.launchpad.net/~pitti/unity8/notify-api-fix/+merge/245643 is for you, right?
[12:21] <Saviq> tsdgeos, nah, actually for me
[12:21] <tsdgeos> oh ok
[12:21] <Saviq> ACKed
[13:04] <greyback_> tsdgeos: could you add checklist (https://wiki.ubuntu.com/Process/Merges/Checklists/QtMir) to https://code.launchpad.net/~aacid/qtmir/create_observer_sooner/+merge/244622 plz
[13:37] <tsdgeos> greyback_: sure
[13:37] <greyback_> ta
[13:58] <MacSlow> Is MediaPlayer a QML-object defined unity8 or Qt itself?
[13:58] <MacSlow> doh... defined by unity8...
[14:15] <tsdgeos> Mirv: is there a simple way to trigger a rebuild of unity8 and qtdeclarative in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-005/+packages ?
[14:15] <tsdgeos> now that the new qtbase has been built
[14:16] <facubatista> Hola
[14:16] <facubatista> rsalveti, ping; having problems with rest scopes?
[14:19] <Saviq> tsdgeos, Mirv will have to upload bumped versions
[14:19] <Cimi> mterry, test failed on jenkins
[14:20] <Saviq> tsdgeos, you can't rebuild in PPAs as they prevent two different binaries with the same version
[14:20] <mterry> Cimi, yeah I've been looking at that this morning
[14:20] <tsdgeos> makes sense i guess
[14:20] <Cimi> ok!
[14:37] <Saviq> Cimi, please leave a vote on https://code.launchpad.net/~mterry/unity8/wizard-passphrase-osk/+merge/244358 apart from top-approving
[14:37] <Cimi> Saviq, ok
[14:45] <Saviq> greyback_, few more reasons for hash -d ;D → you can type "foo" to `cd ~foo` (where foo is how you named the "shortcut"), but even better - it also works in tab-completion, foo<tab> will autocomplete to files from foo etc.
[14:45] <Saviq> ;)
[14:45] <greyback_> hmmm
[14:46] <greyback_> Saviq: can you use that in a command. e.g. to overwrite a file, can you do "cp thisFile foo<tab>"
[14:46] <Saviq> greyback_, yeah
[14:47] <Saviq> greyback_, zsh expands foo
[14:47] <greyback_> hmm, that is nice
[14:47] <Saviq> greyback_, *might* need to prepend ~ in this case
[14:48] <Saviq> no ~ needed for some built-ins like cd apparently
[14:48] <Saviq> so ~foo<tab>
[14:51] <MacSlow> at least notifications still work on the device... testing unity8's notifications locally on the desktop always fails
[14:54] <mzanetti> hey, I can't ./run.sh any more... anyone knows already what's going on?
[14:54] <tsdgeos> i haven't run run for a long time
[14:54] <tsdgeos> directly the binary i want
[14:55] <mterry> Cimi, ok tests fixed, let's see what jenkins says.  I also filed the MP for the tutorial-new-screens branch yesterday, it's ready
[14:56] <rsalveti> facubatista: the problem I had with the today scopes is that it wasn't adding the weather data, even when I was online (not sure if this is the one you're talking about)
[14:56] <rsalveti> and the remote scopes were also not available, so cwayne1 said that this could be the reason
[14:56] <Cimi> mterry, what shall I review in the tutorial refactor??
[14:57] <facubatista> rsalveti, __lucio__ told me you weren't seeing any remote scopes...
[14:57] <Cimi> mterry, design too? It looks nice but doesn't work well
[14:57] <mterry> Cimi, doesn't work well?
[14:57] <rsalveti> facubatista: yeah, worked after a clean flash, will let you know if I get to reproduce this again
[14:57] <Cimi> mterry, I kept tapping the orange circle to swipe
[14:57] <Cimi> mterry, before I realised I need to swipe from the edge on the ubuntu phone
[14:58] <Cimi> mterry, has this been user tested?
[14:58] <mterry> Cimi, I don't know whether they've user tested
[14:59] <Cimi> mterry, let's wait for user testing
[14:59] <mterry> Cimi, but as for what to review, I'd say just that my code isn't crazy and that it works.  I think design can handle their side
[15:00] <Cimi> mterry, ok, but let's be sure we ask for user test
[15:00] <mterry> Cimi, no let's not wait for user testing... Design will review the MP and sign off or not on whether they like it
[15:00] <facubatista> rsalveti, ok! just let me know about *any* issue with remote scopes, I should be of help :)
[15:01] <Cimi> mterry, I think we should user test, to avoid what happened with the scopes overview
[15:01] <rsalveti> facubatista: great, thanks
[15:01] <Cimi> mterry, so ok, I will approve code wise, but let's make sure we request that before merging
[15:01] <mterry> Cimi, I'm only going to wait for Design to say it's OK.  I don't want to second guess their methods
[15:01] <tsdgeos> Saviq: ok, i know what's going on with the crash on https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/246/consoleFull something is going to slow and it's crashing on a waitForRender
[15:02] <tsdgeos> we should reallly make waitForRender not crash on empty items
[15:02] <Saviq> tsdgeos, sounds like an easy thing to do in UnityTestCase
[15:02] <Saviq> with the exception that it's going to be tricky to call the "upstream" waitForRendering
[15:03] <Cimi> mterry, might go to office tomorrow if my back feels better, I can ask...
[15:09] <tsdgeos> Saviq: nah it's easy too
[15:09] <tsdgeos> i'll add it in and propose the fix upstream, see what they think
[15:09] <Saviq> coolz
[15:14] <mzanetti> tsdgeos: how do you do with the lightdm plugins then?
[15:14] <mzanetti> tsdgeos: you always type the full LD_LIBRARY_PATH thing?
[15:14] <tsdgeos> don't need them for unity8-dash
[15:14] <tsdgeos> don't run unity8 much ^:^
[15:14] <mzanetti> ah
[15:15] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/waitForRenderingNoCrash/+merge/245747
[15:15] <Saviq> tsdgeos, wanna add semicolons?
[15:16] <tsdgeos> Saviq: to where?
[15:16] <Saviq> tsdgeos, to end of lines ;)
[15:16] <tsdgeos> ah
[15:16] <tsdgeos> i just copied from the qt code
[15:16] <tsdgeos> but sure will add
[15:16] <Saviq> it's not like we're consistent about them :/
[15:17] <tsdgeos> added
[15:17] <Saviq> tx
[15:22] <mzanetti> Saviq: so, does ./run.sh work for you?
[15:22] <mzanetti> for me it runs the binary, but it doesn't show up, and it can't be killed any more except with -9
[15:23] <Saviq> mzanetti, same here yeah
[15:27] <Saviq> mzanetti, ah!
[15:28] <Saviq> pkill -SIGCONT unity8
[15:28] <Saviq> hmm wonder why upstart isn't doing it
[15:29] <MacSlow> Saviq, initctl works for me, but takes ages...
[15:29] <mzanetti> ah ok
[15:29] <mzanetti> mterry: hey, do we still need all that lightdm LD path fun? I wonder if this couldn't be dropped at some point
[15:30] <Saviq> mzanetti, there's a branch from dandrader dealing with that
[15:30] <mzanetti> ah, great
[15:31] <mterry> Saviq, mzanetti: except it doesn't drop the LD stuff, just consolidates it a bit.  I think we still want the LD stuff
[15:31] <Saviq> mzanetti, that's unless you want to type your password in every time you start unity8 locally ;)
[15:32] <mzanetti> fair enough
[15:36] <Saviq> mzanetti, so what happens is that we emit SIGSTOP twice for some reason
[15:36] <mzanetti> o_O
[15:37] <Saviq> greyback_, ideas ↑?
[15:37] <mzanetti> greyback_: didn't we change something there before hoidays?
[15:37] <greyback_> yep
[15:37] <mzanetti> we messed up
[15:37] <greyback_> yep
[15:37] <Saviq> ugh
[15:38] <greyback_> yep
[15:38] <mzanetti> lol
[15:38] <Saviq> it's there in main as well as AppMan
[15:38] <mzanetti> I guess we didn't update the fake AppMan, only the real one?
[15:38] <Saviq> who's prepping an MP?
[15:38] <Saviq> and why did we skip standup? :D
[15:38] <mzanetti> we didn't
[15:38] <mzanetti> just you did
[15:39] <mzanetti> :P
[15:39] <Saviq> :P
[15:39] <greyback_> qtmir emits SIGSTOP only if UNITY_MIR_EMITS_SIGSTOP==1
[15:39] <greyback_> I suspect that should not be set in the run script maybe? /doesn't remember
[15:40] <Saviq> greyback_, yeah, but we have another raise in main() as well
[15:40] <greyback_> Saviq: yeah we needed that for when a mock appman was used instead of real
[15:41] <Saviq> greyback_, yeah, but mock appman has raise too now
[15:41] <greyback_> oh
[15:41] <greyback_> then main can drop it
[15:41] <Saviq> yes
[15:42] <Saviq> I just wonder how does it work outside of run.sh...
[15:42] <greyback_> how do AP tests work??
[15:42] <Saviq> indeed
[15:43] <Saviq> ah
[15:43] <Saviq> they're ran on Mir
[15:43] <Saviq> and the main() one only acted on !Mir
[15:43] <Saviq> and we're not running the AP tests on x86 for a while now
[15:43] <greyback_> not all AP tests run on Mir tho
[15:44] <Saviq> they do
[15:44] <greyback_> oh yeah, ignore me
[15:44] <Saviq> greyback_, you MP or do I?
[15:44] <greyback_> some just use mock appman
[15:44] <Saviq> yeah, which is why we needed the raise in mock appman too
[15:44] <greyback_> Saviq: I'm trying ot focus on a critical bug right now, can do after
[15:45] <Saviq> greyback_, I'll do, then
[15:45] <greyback_> ok thanks
[15:45] <Saviq> greyback_, let me know if you need help with the wakelock
[15:46] <greyback_> Saviq: wakelock the easy bit, hard bit making sure it held only when needed
[15:47] <Saviq> greyback_, bird's eye view here ;)
[15:47] <greyback_> a drone more comes to mind...
[15:49] <tsdgeos> Cimi: https://code.launchpad.net/~aacid/unity8/departmentListHorizontalScroll/+merge/245580 passes now
[15:50] <mterry> Ugh, my krillin is Out Of Juice after the holidays
[15:53] <Saviq> mterry, it lasted a whole two weeks of dogfooding? our battery usage improved a lot! ;P
[15:53] <tsdgeos> easy cleanup https://code.launchpad.net/~aacid/unity8/cleanupTypeString/+merge/245756
[15:53] <mterry> Saviq, :)
[15:54] <tsdgeos> Saviq: need to land stuff! https://code.launchpad.net/~unity-team/unity8/trunk/+activereviews is growing :D
[15:54] <Saviq> tsdgeos, yup, was just restarting failed ci jobs earlier today
[15:54] <Saviq> tsdgeos, want a green on every MP
[15:57] <tsdgeos> oki
[15:57] <tsdgeos> we still have unstability
[15:57] <Saviq> mzanetti, https://code.launchpad.net/~saviq/unity8/no-sigstop-main/+merge/245758
[15:57] <Saviq> tsdgeos, yeah, I saw a few weird Mir crashes today, trying to see if I can reproduce locally
[15:58] <Saviq> but stuff's a bit difficult as we're 160 packages behind vivid in latest devel-proposed image :/
[15:58] <mhall119> thostr_: does the Dash cache GPS data for scopes? I noticed while traveling over the holidays that my scopes were getting old GPS data from 30 miles away, where I was over an hour ago
[15:59] <mhall119> it was happening on all scopes that use location data, so I don't think it's the scopes doing it
[15:59] <mhall119> (I would expect at least one of them to not do it if that were the case)
[15:59] <mhall119> even pulling down to refresh didn't change their location-based results
[15:59] <tsdgeos> Saviq: wow 160 :S
[16:00] <Saviq> tsdgeos, yeah
[16:00] <thostr_> mhall119: scopes themselves cannot access location data directly but get that passed on by the scopes FW, that's why all scopes have same location
[16:00] <Saviq> mhall119, I imagine the location service does the caching
[16:00] <thostr_> mhall119: so, question is rather why the location was not updated in either the system or in scopes machinery
[16:01] <thostr_> pete-woods: ^ when do we trigger/request a new location? on every query?
[16:02] <mhall119> thostr_: the sensor status app was showing updated GPS coordinates
[16:08] <pete-woods> thostr_: when any scope that has requested location is active, we start a GPS session
[16:09] <pete-woods> while a session is active the backend is always tracking the current location
[16:10] <pete-woods> however last time I checked, it took quite some time before a real GPS location was received
[16:10] <pete-woods> so we most often fall back to geo IP
[16:11] <pete-woods> each query dispatch we retrieve the current location from the GPS session
[16:11] <pete-woods> so in theory it should be current
[16:35] <kgunn> tsdgeos: so is qt using the disk writes somehow for animations/event handling ?
[16:35] <tsdgeos> something i
[16:35] <tsdgeos> s
[16:35] <kgunn> wrt your bug....it's just weird
[16:35] <tsdgeos> i didn't investigate
[16:35] <kgunn> odd...means there should really be a reserve
[16:36] <Saviq> kgunn, well, the problem with reserve is that your shell is running as you, so if the shell can write, so can you
[16:37] <Saviq> kgunn, we'd have to make sure we're writing outside of /home for whatever we need to be writing
[16:37] <Saviq> and not write at all what we don't actually need to be writing
[16:37] <tsdgeos> yep
[16:37] <mzanetti> don't we cache in ~?
[16:37] <mzanetti> and well, write logs and everything
[16:37] <tsdgeos> mzanetti: qml cache?
[16:37] <mzanetti> tsdgeos: I think we have at least an image cache for unity + dash in there
[16:37] <tsdgeos> mzanetti: not being able to write logs should not make everything not work :D
[16:37] <mzanetti> and yeah, prolly qml caching too
[16:37] <tsdgeos> same for the cache
[16:38] <Saviq> yeah, anything we *really* need write access to should be outside of /home partition
[16:38] <kgunn> tsdgeos: i agree about logs...but i could see cache being an issue
[16:38] <Saviq> and any caches, logging should just fail
[16:38] <mzanetti> sure, the question is if we actually expire the cache
[16:38] <mzanetti> otherwise at some point it'll just stop working, no matter where
[16:38] <Saviq> mzanetti, whether we do or not doesn't matter (for this problem)
[16:39] <Saviq> mzanetti, the cache can stop working
[16:39] <Saviq> mzanetti, the shell can not, even if cache is not writable
[16:39] <mzanetti> sure
[16:39] <Saviq> it's a cache after all
[16:39] <kgunn> mmm yeah, you're right...cache should just fail, i see that
[16:39] <mzanetti> but I would go as far as saying the cache being full with old stuff and not cache new stuff any more is a bug too :)
[16:39] <Saviq> that's not going far
[16:39] <kgunn> ...and could be a bug someone is using cache wrongly
[16:40] <Saviq> mzanetti, in any case, as far as the QML cache goes, it's cleared on upgrade
[16:40] <Saviq> the network cache is max 50MB right now, so old things are expires
[16:40] <Saviq> d
[16:40] <mzanetti> ok
[16:40] <Saviq> (and tsdgeos was on vivid, where the QML cache doesn't exist yet IIRC)
[16:41] <kgunn> really?
[16:41] <Saviq> so anyway, one problem is why it filled up
[16:41]  * Saviq checks
[16:41] <mzanetti> +1. really?
[16:41] <mzanetti> :)
[16:41] <mzanetti> yeah, the other is it should still work somewhat
[16:42] <kgunn> work, just shitty :)
[16:42] <tsdgeos> Saviq: well it filled up because i copied lots of stuff
[16:42] <tsdgeos> that's totally my fault
[16:42] <kgunn> hehe
[16:42]  * kgunn wishes more users were like tsdgeos
[16:43] <Saviq> tsdgeos, sure, but there's other stuff we're writing to $HOME
[16:43] <Saviq> logs are rotated, but only on session start, if your session lasts for a year or something
[16:43] <mzanetti> this seems like a bug that's to be fixed thoughout the system actually
[16:43] <tsdgeos> sure
[16:44] <Saviq> kgunn, yeah, no QML compilation in vivid
[16:44] <kgunn> noted
[16:44] <kgunn> glad to hear, explains poor perf i saw when testing too