[06:36] <jibel> didrocks, when I run autopilot on Saucy with Otto, I often get http://paste.ubuntu.com/5673206/ for nearly all the tests, do you know what it means ?
[06:36] <jibel> and in dbus.log http://paste.ubuntu.com/5673216/
[06:39] <didrocks> jibel: sounds like zeitgeist is crashing, but mhr3 is on holidays…
[06:39] <didrocks> or can't create its database
[06:39] <didrocks> activity.sqlite doesn't exist I guess?
[07:30] <boynux> \q
[08:41] <boynux> Does anybody knows how can I contribute to UnityNext project?
[08:44] <Saviq> boynux, hey
[08:44] <Saviq> boynux, it's a slightly difficult time as everything is so fluid right now
[08:44] <boynux> hi
[08:45] <Saviq> and we definitely need to get better in enabling you guys to do so
[08:45] <Saviq> but we have a list of TODOs and FIXMEs some of which are bite-size
[08:45] <Saviq> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AoGvOYxwuvpFdEJ5dURFb3Y0cnlKeEcxc0piNDZrWXc#gid=0
[08:45] <boynux> so, is there any list or irc channel just to have an idea how to start?
[08:45] <Saviq> IRC is here
[08:46] <boynux> ok, thanks
[08:46] <Saviq> and we don't have a specific ML, and ubuntu-phone is a good enough place (as you've noticed)
[08:48] <boynux> yes, I understand. and is there any possibility to take some of the tasks in that google doc?
[08:48] <Saviq> boynux, there's an "owner / assigned" column
[08:48] <Saviq> boynux, just drop yourself in there
[08:49] <boynux> ok, fine.
[08:49] <boynux> but there is no time frame for tasks!
[08:50] <Saviq> boynux, the "Difficulty" should be an indication
[08:51] <Saviq> boynux, if by time frame you mean how time consuming a task is
[08:51] <Saviq> boynux, there's also the set of blueprints you can reach from https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-iteration-0
[08:52] <Saviq> boynux, where, if you find a TODO item (even if it's assigned to someone) that you'd like to work on, ping me about it
[08:53] <boynux> Saviq, thanks for all information.
[08:53] <boynux> ok!
[08:53] <boynux> and the code base is the one from bzr? right?
[08:53] <boynux> also can you tel me how to send out patches afterward?
[08:53] <Saviq> boynux, lp:unity/phablet
[08:54] <Saviq> boynux, https://dev.launchpad.net/UsingMergeProposals is our process
[08:58] <boynux> Saviq, OK, I think now I have enough info to to digest for the moment :) thank you.
[08:58] <Saviq> boynux, cheers, feel free to ping me or just hang out here if I'm unavailable
[08:59] <boynux> Saviq, sure, thank you.
[09:14] <Saviq> biab
[09:15] <tsdgeos> greyback: oh man, can't get the lvwph test to pass once i move from the broken tryCompare to the non broken one :/
[09:15] <tsdgeos> i mean, they pass locally
[09:15] <tsdgeos> but not in jenkins :D
[09:15] <greyback> tsdgeos: I sympathize. One fail in particular, or several?
[09:15] <tsdgeos> several :/
[09:16] <greyback> point me to a branch, I might be able to help
[09:16] <tsdgeos>  lp:~aacid/unity/fix_tryCompare
[09:17] <tsdgeos> latest failures http://10.97.2.10:8080/job/unity-phablet-qmluitests/913/
[09:17] <tsdgeos> after billion of different permutations :/
[09:31] <greyback> tsdgeos: weird thing I found while reading source to qtquickcontrols, specifically the ScrollView code, it always adds a non-zero arguments to the flick call
[09:31] <greyback> with a comment "flick() does not work with 0 yVelocity"
[09:32] <greyback> tsdgeos: also I'm not convinced the mouseFlick function always works well
[09:32] <tsdgeos> greyback: we need it
[09:33] <tsdgeos> flick doesn't want to flick up
[09:33] <tsdgeos> when you're up
[09:33] <tsdgeos> so either we kill that test
[09:33] <tsdgeos> or
[09:33] <greyback> I see
[09:36] <greyback> tsdgeos: I think we need a better solution for testing Flickables then. I don't think we can reliably manipulate them via JS
[09:36] <greyback> so I would vote for disabling the tests which we suspect are unreliable, and look for a better solution. Probably C++ based
[09:37] <greyback> tsdgeos: just a random thought, what GU size is set on jenkins?
[09:37] <tsdgeos> not sure
[09:37] <tsdgeos> mzanetti: ?
[09:38] <mzanetti> none
[09:38] <mzanetti> which defaults to 10 afaik
[09:38] <mzanetti> greyback: tsdgeos ^
[09:38] <tsdgeos> may be
[09:39] <dednick> TO ALL: i've just accidentily overwritten lp:unity/phablet. :( please noone pull latest until we get it resolved
[09:39] <greyback> tsdgeos: yep that caused a fail
[09:39] <dednick> anyone know how to get the latest good revision back?
[09:39]  * mzanetti wonders how that would happen
[09:39] <mzanetti> dednick: depends on what you did
[09:39] <tsdgeos> i have 675, anyone has anything newer?
[09:40] <mzanetti> same here
[09:40] <dednick> mzanetti: i pushed with overwrite instead of pull.
[09:40] <greyback> me too
[09:40] <mzanetti> dednick: can you bzr uncommit && bzr revert && push?
[09:41] <tsdgeos> we can ask jenkins what's the last branch it autolanded
[09:41]  * tsdgeos checks
[09:41] <dednick> mzanetti: no. the version is a few days old.
[09:41] <mzanetti> let me pull
[09:41] <tsdgeos> so https://code.launchpad.net/~macslow/unity/phablet-notification-renderer/+merge/155512 is the last thing merged
[09:41] <tsdgeos> so 675 is fine as "last" rev
[09:41] <tsdgeos> wonder if when http://s-jenkins:8080/job/unity-phablet-autolanding/327/console autolands
[09:42] <tsdgeos> what will happen :D
[09:42] <mzanetti> if we're luck it causes a merge conflict and fails
[09:42] <mzanetti> otherwise... hmm. need to remerge I'd say
[09:42] <tsdgeos> then we just need to push overwrite 675 again and accept that change to autoland again
[09:42] <tsdgeos> should not be that "bad"
[09:43] <mzanetti> no... no biggie right now... but really interesting that this can happen...
[09:44] <mzanetti> so the revisions 655 - 675 are gone forever? there's no history or anything left any more?
[09:44] <greyback> didrocks: can this be locked down? We had an accidental push directly to trunk
[09:44] <tsdgeos> mzanetti: well,  you just push --overwrite and they'll be back
[09:44] <greyback> indeed
[09:45] <mzanetti> sure... but if we wouldn't have a local copy we'd be quite screwed?
[09:45] <greyback> probably yes :)
[09:45] <tsdgeos> possibly
[09:45] <mzanetti> wow...
[09:45] <greyback> which is why I thought bzr was locked down that we couldn't directly push, only the tarmac/jenkins could
[09:46] <mzanetti> so... who will push 675?
[09:46] <tsdgeos> mzanetti: i'd wait until the autolanding thing finishes
[09:46] <mzanetti> tsdgeos: why? if your fast enough it won't be noticed by the job
[09:46] <tsdgeos> ah it finished
[09:46] <dednick> but the 675 MP doesnt have the full history does it?
[09:46] <tsdgeos> and it merged
[09:47] <tsdgeos> :S
[09:47] <greyback> let's just push overwrite, and re-propose the merge
[09:47] <mzanetti> ack. I'm on re-proposing the merge... you guys push in the meantime
[09:48] <greyback> but I'd like didrocks ' opinion before proceeding, just in case there's something subtle
[09:48] <mzanetti> oh wait
[09:48] <mzanetti> https://code.launchpad.net/~saviq/unity/phablet.release-176/+merge/164192
[09:48] <mzanetti> this was merged too
[09:48] <mzanetti> 676
[09:48] <tsdgeos> you sure?
[09:48] <tsdgeos> does that skip unity-phablet-autolanding ?
[09:48] <mzanetti> it says in the MP at least
[09:48] <dednick> plus that one has full history.
[09:49] <tsdgeos> can't see it's job
[09:49] <didrocks> greyback: I'm debugging stuff in a hangout?
[09:49] <greyback> didrocks: ah sorry, when you have time let us know
[09:49] <didrocks> greyback: is it urgent?
[09:50] <mzanetti> tsdgeos: I think there is some special case for changelog-only changes
[09:50] <tsdgeos> i see
[09:50] <mzanetti> tsdgeos: might not go through regular autolanding
[09:50] <tsdgeos> so we need to push 675, and then reapprove that one and the https://code.launchpad.net/~mzanetti/unity/phablet-tease-launcher/+merge/163906 one
[09:50] <tsdgeos> sounds like a plan?
[09:50] <greyback> didrocks: kinda. We accidentally bzr push --overwrite to our trunk. We want to restore it back to a last known revision by doing the same, and then re-proposing any merges that happened in the mean time. See any problem with that?
[09:50] <mzanetti> why not just pushing this: lp:~saviq/unity/phablet.release-176 ?
[09:51] <tsdgeos> mzanetti: that works too
[09:51] <greyback> mzanetti: if that did indeed merge, then yeah
[09:51] <didrocks> greyback: no, sounds good to me :)
[09:51] <didrocks> that will still work even with dailies
[09:52] <greyback> didrocks: ok cool, thanks. We should chat later to see if we might want to lock down us pushing directly to trunk
[09:52] <tsdgeos> ok, so who pusehs  lp:~saviq/unity/phablet.release-176 ?
[09:52] <didrocks> yep :)
[09:52] <mzanetti> tsdgeos: feel free
[09:52] <tsdgeos> ok, doing, give me 5 min
[09:53] <mzanetti> oh... this one failed to merge: https://code.launchpad.net/~mzanetti/unity/phablet-tease-launcher/+merge/163906
[09:53] <tsdgeos> yep
[09:53] <tsdgeos> that's "good"
[09:53] <mzanetti> so we just push Saviq's branch and set that one to Approved again and we're fine
[09:53] <tsdgeos> i guess :D
[09:53] <greyback> yep, agreed
[09:54]  * dednick purges push --overwrite from .bash_history
[09:54] <mzanetti> hehe
[09:55] <mzanetti> better, yes :D
[09:55] <mzanetti> tsdgeos: you better do so too afterwards :D
[09:56] <tsdgeos> how does one do that?
[09:56] <mzanetti> dednick: ?
[09:56] <tsdgeos> ok, we're all set
[09:56] <tsdgeos> https://code.launchpad.net/~unity-team/unity/phablet
[09:56] <tsdgeos> 676 is back
[09:56] <tsdgeos> and i just reapproved https://code.launchpad.net/~mzanetti/unity/phablet-tease-launcher/+merge/163906
[09:56] <dednick> tsdgeos: edit ~/.bash_history
[09:56] <mzanetti> tsdgeos: cheers
[09:57] <mzanetti> dednick: huh? isn't that a binary file?
[09:57] <dednick> thanks all!
[09:57] <dednick> nope
[09:57] <mzanetti> wow... its not in ubuntu
[09:57] <mzanetti> crazy
[09:57] <tsdgeos> mzanetti: never been one afair
[09:58] <mzanetti> all the distros I've used before stored the history in some binary/encrypted format
[09:58] <tsdgeos> really?
[09:58] <tsdgeos> interesting
[09:58] <mzanetti> now I'm confused... just checked my Archlinux based TV
[09:58] <mzanetti> also plaintext
[09:58] <mzanetti> but I'm 100% sure I've seen that encrypted already
[10:01] <mzanetti> dednick: first time my highlight filter on "all:" was useful :D
[10:01] <mzanetti> usually it only produces false positives on dh_install: pastes etc
[10:01] <dednick> mzanetti: ahha
[10:12] <Saviq> oh boys, oh boys
[10:13] <mzanetti> haha
[10:17] <mzanetti> tsdgeos: what exactly is the reason why we need to depend on the fonts?
[10:17] <tsdgeos> mzanetti: it's expplained in the commit log ;-)
[10:17] <mzanetti> not really...
[10:17] <mzanetti> it says otherwise a test fails
[10:17] <mzanetti> but I would like to understand why
[10:18] <tsdgeos> "install the ubuntu font since we use it and otherwise the test
[10:18] <tsdgeos> does not pass because font sizing is different"
[10:18] <tsdgeos> font is different
[10:18] <mzanetti> sure... but why would a slightly larger/smaller font mess up the test?
[10:18] <tsdgeos> pageHeader label is different
[10:18] <tsdgeos> so instead of "active"
[10:18] <tsdgeos> it goes into "narrowActive"
[10:19] <tsdgeos> because there's not enough space
[10:19] <mzanetti> oh... I see
[10:19] <tsdgeos> and the size comparison fails
[10:19] <Saviq> tsdgeos, so the test should be made better
[10:19] <Saviq> tsdgeos, i.e. grow the window until it goes into "active"
[10:19] <tsdgeos> Saviq: well, tell whoever made the test
[10:19] <Saviq> ;)
[10:20] <tsdgeos> anyway we should depend on the font
[10:20] <tsdgeos> since we use it
[10:20] <tsdgeos> what's the point otherwise
[10:20] <Saviq> true
[10:20] <Saviq> the theme should depend on it, btw
[10:21] <mzanetti> yeah... fine with that... Just wanted to understand what exactly is happening
[10:22] <Saviq> mzanetti, gimme a sec
[10:22] <mzanetti> ?
[10:23] <mzanetti> not sure for what... but sure... take your time
[10:23] <Saviq> mzanetti, for tsdgeos's branch
[10:23] <mzanetti> ah
[10:23] <Saviq> mzanetti, but go for it, we're explicitly using Ubuntu as the font family in a few places
[10:23] <Saviq> which we shouldn't, but that's another story
[10:27] <Saviq> mzanetti, remember the bug about buttons going through transparent when hovering? you did report it didn't you?
[10:27] <Saviq> yeah
[10:27] <mzanetti> Saviq: when, clicking, not howering
[10:27] <Saviq> mzanetti, yea
[10:27] <Saviq> howering
[10:27] <Saviq> hmm
[10:28] <mzanetti> :D
[10:28] <Saviq> how how, I'm howering
[10:28] <nic-doffay> pete-woods, some changes with the colours in the circle.
[10:28]  * mzanetti needs to actually pay attention to the spell checker when talking to Saviq
[10:28] <nic-doffay> the outer circles I mean.
[10:29] <mzanetti> Saviq: you need that bug or did you find it?
[10:29] <Saviq> mzanetti, I _am_ the spell checker
[10:29] <Saviq> mzanetti, #1115071
[10:32] <pete-woods> nic-doffay: have these changes been pushed?
[10:32] <nic-doffay> No pete-woods busy talking about them still.
[10:32] <pete-woods> okay
[10:33] <didrocks> greyback: ok, available now :)
[10:34] <greyback> didrocks: all's good, we're back to normal.
[10:34] <greyback> Saviq: would you consider locking down bzr a little to stop us pushing directly to trunk?
[10:34] <didrocks> great :)
[10:35] <Saviq> greyback, not sure it's worth it, it's the first time this happened, and with bzr there's loads of copies lying around
[10:35] <Saviq> greyback, it's not like it was the end of the world, just some panicking
[10:37] <Saviq> greyback, and if we actually lock it down we might end up in a bigger conundrum when there's noone around that can push to it
[10:38] <Saviq> greyback, unless it becomes a recommendation that trunks are owned by pspmteam or something
[10:38] <tsdgeos> Saviq: actually, we might just limit overwrite pushes, if that's possible
[10:38] <greyback> Saviq: well's it handy for crisis prevention, we're just lucky there's lots of copies around. But yes it ties us down a little
[10:39] <Saviq> tsdgeos, I don't think it ise
[10:39] <Saviq> -e
[10:39] <tsdgeos> :-/
[10:39] <tsdgeos> that'd be handy
[10:39] <Saviq> tsdgeos, you either have write access or you don't
[10:39] <Saviq> we'd just have to change the owner to a team that we're not all member of
[10:39] <tsdgeos> sure, but does bazaar has hooks?
[10:39] <tsdgeos> i mean a pre-commit hook might reject overwrite pushes
[10:40] <tsdgeos> in my theorical mind
[10:40] <tsdgeos> not saying that's possible at all
[10:40] <Saviq> tsdgeos, would have to be manually installed, I think
[10:40] <Saviq> tsdgeos, and then again, not worth it, IMO
[10:40] <tsdgeos> ok
[10:40] <Saviq> I myself have 5 copies lying around every other time
[10:40] <Saviq> and backed up daily
[10:40] <greyback> http://doc.bazaar.canonical.com/latest/en/user-reference/configuration-help.html#append-revisions-only
[10:40] <Saviq> as my whole home dir
[10:41] <Saviq> greyback, read the doc, that would not help with overwriting
[10:41] <Saviq> really guys, not the end of the world :D
[11:09] <dednick> Saviq: there seems to be a dependency break in the new qtdeclarative5-ubuntu-ui-toolkit-plugin. it's requiring qt5.0.2 while we only have 5.0.1 in raring
[11:09] <Saviq> dednick, yeah, 5.0.2 is in ppa:canonical-qt5-edgers/qt5-proper
[11:09] <dednick> Saviq: ah
[11:09] <dednick> thanks
[12:09] <pete-woods> nic-doffay: just pulled some new changes from you regarding the dot sizes, and they look a bit screwed now
[12:09] <nic-doffay> Try it on the phone pete-woods
[12:09] <nic-doffay> No idea what it looks like on the tablet sadly pete-woods
[12:10] <nic-doffay> Basically it looks screwed on the desktop but great on the phone.
[12:10] <pete-woods> nic-doffay: is that because of the screen resolution or something?
[12:10] <nic-doffay> No idea why.
[12:10] <nic-doffay> pete-woods, that would be my first guess. Can't say for sure though.
[12:12] <pete-woods> nic-doffay: it's gotta be screen resolution - looks okay on the tablet too
[12:12] <nic-doffay> pete-woods, ok great.
[12:12] <dandrader> Saviq, what's the reasoning behind using "#include <QtQuick/QQuickItem>" instead of "#include <QQuickItem>"?
[12:12] <Saviq> dandrader, explicit
[12:12] <nic-doffay> pete-woods, as long as it looks cool on the tablet too :)
[12:12] <Saviq> dandrader, and/or consistent
[12:13] <pete-woods> nic-doffay: it's bad if we have resolution-dependent code, though
[12:13] <Saviq> dandrader, obviously it doesn't matter that much 'cause qt5_add_modules adds the include dir anyway
[12:14] <pete-woods> remember this is going to be the desktop login screen, too, with unity next
[12:14] <pete-woods> nic-doffay: also, the arrow icon is too low resolution, it looks pretty pixelated on the tablet
[12:16] <dandrader> Saviq,  Qt documentation also omits the module dir in its include. I mean, what problem can arise from omitting the module directory? I doubt there can be a conflict (otherwise Qt docs would tell you to put the module dir when you include smthing). But ok, I'll do it as it seems to be the project's coding style (consistency) although I still don't see the point in it
[12:16] <nic-doffay> pete-woods,  going to commit a change, can you let me know if it makes a diff?
[12:16] <pete-woods> of course :)
[12:16] <kgunn> pete-woods: nic-doffay isn't it because the assetts are 1:1 on the phone...but scaling on desktop ?
[12:16] <nic-doffay> pete-woods, pushed.
[12:17] <nic-doffay> kgunn, nope. Something else that I didn't think through properly :P
[12:17] <Saviq> nic-doffay, pete-woods, kgunn, we just need to provide multiple @px versions of those assets, probably
[12:18] <nic-doffay> Saviq, it looks fine as long as it's being scaled down.
[12:18] <Saviq> nic-doffay, it should never be scaled up :)
[12:18] <nic-doffay> So we just need to provide one large asset.
[12:18] <kgunn> nic-doffay: actually no
[12:18] <kgunn> nic-doffay: cause then you spend processing time :)
[12:18] <Saviq> kgunn, that's fine
[12:18] <pete-woods> Saviq: I think it's more than that - the relative positions of the inner dots seems to be affected by the resolution
[12:18] <nic-doffay> kgunn, what's the largest px?
[12:18] <Saviq> nic-doffay, 30
[12:19] <Saviq> kgunn, we're going to rescale once and cache
[12:19] <Saviq> kgunn, we can even prescale them on the servers somewhere
[12:19] <kgunn> Saviq: that's cool
[12:19] <pete-woods> nic-doffay: at desktop resolution, the dots are too close to the centre of the circle
[12:20] <Saviq> kgunn, so the workflow is: provide @30 and only provide others if scaling down doesn't work
[12:20] <nic-doffay> pete-woods, yeah do we have to account for this though?
[12:20] <kgunn> Saviq: nic-doffay it'll certainly work for now, and oem
[12:20] <kgunn> 's can tweak for 1:1
[12:20] <kgunn> when that day comes
[12:21] <Saviq> yup
[12:23] <pete-woods> nic-doffay: I don't think that the icon sizes are so important - as Saviq says, we can provide correctly sized ones, it's more the positioning that I think should be fixed
[12:23] <nic-doffay> pete-woods, you mean for the desktop?
[12:23] <pete-woods> well, generally - there must be some mistake if the dots are going in the wrong place
[12:24] <pete-woods> as it should just be some proportion of the size of the circle
[12:25] <Saviq> nic-doffay, pete-woods it's a regression, too, it was fine on desktop before
[12:25] <nic-doffay> Saviq, yeah but it wasn't on the phone.
[12:26] <nic-doffay> Saviq, the phone looks perfect now, but the desktop is screwed.
[12:27] <Saviq> nic-doffay, that's weird, 'cause if you go GRID_UNIT_PX=16 on the desktop
[12:27] <kgunn> Saviq: just curious...do you know if scaling is it relying on gpu to scale ? or cpu sw ?
[12:27] <Saviq> nic-doffay, you should get exactly what you would get on the phone
[12:27] <Saviq> kgunn, GPU right now, AFAIK, they're not cached yet
[12:27] <nic-doffay> Saviq, yeah not entirely sure what is influencing the drastic differences though. At the moment I scale the object by the radius of the circle.
[12:27] <Saviq> kgunn, when they're going to be prescaled for caching, CPU, and then nothing ;)
[12:27] <kgunn> Saviq: so potentially you wouldn't get the same thing on phone as desktop
[12:28] <nic-doffay> Sorry let me be more specific I scale the dot by the radius of the centre circle.
[12:28] <Saviq> nic-doffay, scale it?
[12:28] <Saviq> nic-doffay, it should always be the same size, no?
[12:28] <Saviq> in GUs I mean
[12:28] <nic-doffay> Saviq, if that's the case then we'll need those multiple assets.
[12:29] <Saviq> nic-doffay, I think you're missing something here
[12:29] <Saviq> nic-doffay, the size of the dot should be static in GUs, right?
[12:29] <Saviq> nic-doffay, i.e. 1x1 GU
[12:29] <Saviq> nic-doffay, that will mean 10x10px on desktop
[12:29] <Saviq> 16x16px on phone
[12:29] <Saviq> 20x20px on tablet
[12:30] <Saviq> and QML will take care of that scaling regardless of what you give it as your asset
[12:30] <Saviq> if there's only a @30.png asset
[12:30] <Saviq> it will get scaled down
[12:30] <Saviq> you just don't worry about it
[12:30] <Saviq> your asset will be 30x30
[12:30] <Saviq> because it's 1x1 gu @ 30 px per gu
[12:31] <Saviq> nic-doffay, you could provide prescaled @10.png @16.png @20.png, but that's unnecessary
[12:31] <Saviq> nic-doffay, as a dot @30 will scale down just fine
[12:31] <Saviq> as will the arrow
[12:32] <Saviq> nic-doffay, what's more they get cached after being scaled down
[12:32] <nic-doffay> Saviq, so I shouldn't perform any scaling on the image at all?
[12:32] <didrocks> Mirv: did you see the sdk issue?
[12:33] <Saviq> nic-doffay, it should just be "width: units.gu(1); height: units.gu(1)"
[12:33] <nic-doffay> Saviq, got it.
[12:33] <Saviq> nic-doffay, nothing else
[12:33] <didrocks> Mirv: on the daily release
[12:33] <Saviq> kgunn, to clarify - IIRC they are currently cached for a single run, just not pre-cached and stored
[12:34] <kgunn> Saviq: got it....i was following....so really, once nic-doffay goes pure gu's it should be cached by the engine
[12:34] <Saviq> yes
[12:34] <Saviq> re-scaled on each run
[12:35] <nic-doffay> Saviq, improvement already, nice one!
[12:35] <kgunn> right-o, i follow
[12:35] <nic-doffay> Just have to fiddle around with the positioning maths a bit to compensate.
[12:37] <Saviq> kgunn, and the end goal is that it should be pre-cached and installed in the image on a per-device basis and ad-hoc for stuff that's added to the device later
[12:37] <Saviq> but still kept in a cache so that it's only re-scaled when needed
[12:38] <kgunn> Saviq: sounds good...oem's will care about launch times, that'll help
[12:38] <Saviq> yup
[12:40] <Mirv> didrocks: yes, briefly, but I then had more urgent issues. there's a version number conflict from somewhere.
[12:40] <nic-doffay> Saviq, kgunn, pete-woods fixed.
[12:41] <nic-doffay> Position and size are good on desktop & phone.
[12:41] <nic-doffay> Assuming tablet will be fine too.
[12:41] <nic-doffay> pushing now...
[12:41] <kgunn> nic-doffay: woohooo
[12:41] <didrocks> Mirv: it means that a publish happened, but then, the merge back branch either wasn't merged or was reverted
[12:41] <Saviq> nic-doffay, thought you already pushed, didn't look fixed ;D
[12:41] <didrocks> Mirv: you will fix it before your EOD? so that we don't block next daily?
[12:41] <Mirv> didrocks: I think I see the issue, now fixing
[12:41] <didrocks> Mirv: thanks :)
[12:41] <didrocks> Mirv: you can look at the publish
[12:42] <didrocks> rev 16
[12:42] <didrocks> it referts to https://code.launchpad.net/~ps-jenkins/ubuntu-ui-toolkit/latestsnapshot-0.1.46daily13.05.14ubuntu.unity.next-0ubuntu1/+merge/163696
[12:43] <nic-doffay> Saviq, that was a small experiment to see what the pointer looked like on the tablet ^_^
[12:43] <Mirv> didrocks: there was actually erronous changelog manual change in the trunk, so reverting that..
[12:45] <didrocks> Mirv: ah ok ;)
[12:45] <pete-woods> nic-doffay: nearly there
[12:45] <Saviq> nic-doffay, you can just go « ./run -- -fullscreen » to see how stuff looks
[12:45] <didrocks> Mirv: at least, the daily release is defensive in that regard, so that we don't overwrite :)
[12:45] <pete-woods> you've now got the arrow as being the same size as all the dots again
[12:46] <Saviq> nic-doffay, and « GRID_UNIT_PX=16 ./run » to see the phone in full-resolution on your desktop
[12:47] <pete-woods> nic-doffay: the dots seem to be the same size all the time now - shouldn't their size be relative to the size of the circle somehow?
[12:48] <pete-woods> i.e. if I run it in tablet mode, the dots look tiny
[12:48] <pete-woods> (but are the same size as in phone mode)
[12:48] <Saviq> pete-woods, look fine here
[12:48]  * Saviq gets a few shots
[12:48] <Saviq> pete-woods, apart from the arrow being too small, it looks fine
[12:49] <pete-woods> Saviq: I'm just running it fullscreen with no overriding resolution set, and the dots are really small
[12:50] <Saviq> actually they look too big on the phone ;)
[12:50] <pete-woods> looks good on the actual tablet, though
[12:54] <Saviq> pete-woods, nic-doffay, so... I assumed the infographics would be static size in GUs
[12:55] <Saviq> which it doesn't seem to be the case now
[12:55] <Saviq> and I based my "dots should always be 1x1 GU" on that assumption
[12:56] <pete-woods> Saviq: I don't really know about GU's or anything, but I think that the dots should be some proportion of the size of the infographic circle
[12:56] <Saviq> pete-woods, just treat GUs as a kind of "big pixels"
[12:56] <Saviq> pete-woods, so yeah, they should definitely be a proportion of the big circle
[12:57] <Saviq> pete-woods, but I assumed that the big circle would always be 50x50 GUs or something
[12:57] <Saviq> which isn't the case now
[12:57] <Saviq> the big circle scales according to the available size
[12:57] <Saviq> and I don't know whether that's the designed behaviour or not
[12:59] <pete-woods> I thought it was the behaviour we wanted?
[13:00] <Saviq> I dunno, design would need to say
[13:00] <Saviq> pete-woods, btw, just noticed something
[13:01] <pete-woods> ?
[13:01] <Saviq> pete-woods, when switching between "Guest" and "Lola Chang"
[13:01] <Saviq> pete-woods, the circle shows up for a split second
[13:02] <pete-woods> Saviq: yes, that's because the lightdm is being told that lois is selected, briefly
[13:02] <pete-woods> I don't know what the API can do about that
[13:03] <Saviq> pete-woods, probably nothing, we need to make sure that's not the case in the UI
[13:03] <pete-woods> it feels like the UI should only tell the API the user has changed once the selection has settled for some kind of grace period
[13:03] <Saviq> yup
[13:04] <pete-woods> is there some proper way of doing that in QML world?
[13:04] <Saviq> pete-woods, still hiccups when switching users, did you have time to investigate that?
[13:04] <pete-woods> I changed it to use a signal
[13:04] <pete-woods> and then subscribed to that signal
[13:04] <pete-woods> I've not spent any time performance tuning the inside of the mock implementation
[13:05] <Saviq> that's fine
[13:05] <Saviq> just asking
[13:05] <pete-woods> it does seem to stutter, though, yes
[13:05] <pete-woods> possibly the animations are starting too early
[13:06] <pete-woods> and it's loading in a background picture at the same time as triggering the animations
[13:06] <Saviq> pete-woods, the background picture is loaded async
[13:06] <pete-woods> loading images still seems to hurt the shell quite a bit (presumably some sort of pre-loader type thing hasn't been implemented yet)
[13:07] <pete-woods> for example with the video previews, you get a delay each time you look at one you've not seen before
[13:07] <pete-woods> probably not related to this, though
[13:07] <Saviq> pete-woods, it doesn't happen when there's no infographics, so ;)
[13:07] <pete-woods> indeed :)
[13:08] <pete-woods> it's strange how it's exactly halfway between each user it stutters each time
[13:10] <pete-woods> we need to be triggered at the same time as the shell background changes, that seems to be doing the right thing
[13:10] <Saviq> pete-woods, background doesn't change between "empty-name" and "Anna Olson" here
[13:11] <Saviq> pete-woods, still stutters
[13:11] <Saviq> pete-woods, anyway, the signal thing must not've helped 'cause it's just created a synchronous signal-slot connection, so it will still wait for the slot to finish
[13:12] <Saviq> pete-woods, but anyway, it might not be that, even
[13:12] <Saviq> pete-woods, it might be just the creation of Infographics
[13:13] <pete-woods> Saviq: yeah, quite possibly
[13:13] <Saviq> pete-woods, there's like 100 objects created at that point
[13:13] <pete-woods> yep
[13:16] <pete-woods> Saviq: I was planning for the real implementation for it to produce a minimal set of change notifications
[13:17] <pete-woods> so it could update the circles as necessary
[13:17] <Saviq> yup
[13:31] <tedg> bregma, So I'm realizing from the Unity8 session we didn't decide what the name of the session would be.
[13:31] <tedg> bregma, Do you have thoughts on that?  "ubuntu-touch" ?
[13:31] <bregma> how about a nice simple Unity 8?
[13:32] <bregma> 'cos most people don;t have a touchscreen, so they;d be sonfused
[13:32] <bregma> like my typing
[13:32] <kgunn> bregma: +1
[13:32] <kgunn> on the name not your typing :)
[13:33] <mzanetti> dednick_: standup
[13:33] <dednick_> mzanetti: on my way
[13:33] <dednick_> as soon as i can get mumble to work that is
[13:33] <mzanetti> :)
[13:38] <pete-woods> Saviq: I've changed the timing of the animation for the infographic - it's only triggered on the proper signal for when we've stopped moving now - so hopefully the stutter isn't (as) visible :)
[13:38] <Saviq> pete-woods, cheers :)
[13:40] <Saviq> pete-woods, yeah, much better
[13:40] <pete-woods> :)
[13:43] <tedg> bregma, Don't think it can have a space, no?  So "unity8" ?
[13:44] <tedg> bregma, I don't care about the human readable name... humans are messy.
[13:44] <tedg> FYI, the current session is "ubuntu"
[13:46] <kgunn> paulliu: just curious, your crash on the people lens test...is it on desktop or phone ?
[13:47] <paulliu> kgunn: on desktop.
[13:47] <kgunn> paulliu: have you tried it on phone ?
[13:47] <paulliu> kgunn: That's unit test.
[13:47] <kgunn> i know it shouldn't matter
[13:47] <kgunn> paulliu: ah!
[13:48] <paulliu> kgunn: No, didn't tried that on phone. But make testLensView also very strange.
[13:48] <paulliu> kgunn: It doesn't get the fake lens right now.
[13:48] <paulliu> kgunn: I'm still tracing.
[13:48] <paulliu> kgunn: the fake Unity plugins are currently strange.
[14:06] <dednick_> didrocks: ping
[14:07] <didrocks> dednick_: pong
[14:08] <dednick_> didrocks: hi. so unity smart-scopes is landing right? but seems to be failing?
[14:11] <Saviq> dandrader, I assigned you a WI to allow dismissing close mode in running apps when tapping outside of app
[14:12] <dandrader> Saviq, ok. by "app" you mean "app thumbnail"?
[14:12] <Saviq> dandrader, yes
[14:12] <dandrader> Saviq, and is the work item in a blueprint?
[14:12] <Saviq> dandrader, yeah, just put it in the dash blueprint
[14:12] <Saviq> dandrader, (that's where I assigned it to you)
[14:13] <dandrader> Saviq, ah, this one is ready to go now: https://code.launchpad.net/~dandrader/unity/phablet_touchEventsInQmlTests/+merge/164244
[14:13] <Saviq> dandrader, k, will try and go through it today
[14:17] <didrocks> dednick_: right, sync with pstolowski, only half of the things landed first…
[14:17] <didrocks> dednick_: where everything needed to be landed at the same time
[14:20] <tsdgeos> guys, when someone has some free time
[14:21] <tsdgeos> can you visit https://bugs.launchpad.net/touch-preview-images/+bug/1180511 and check that
[14:21] <tsdgeos> a) it crashes
[14:21] <tsdgeos> b) installing the beta-ppa packages no longer crashes
[14:21] <tsdgeos> and comment on the bug?
[14:21] <tsdgeos> Mirv wants at least two people confirming it
[14:26] <kgunn> greyback: just doing the weekly...when you say "hacks" to make it all work...you mean in the qt plugin ?
[14:27] <tedg> Trevinho, andyrock, so what do we do with this icon_free() thing.  I was trying to be helpful, but it seems like it's turning into something crazy :-)
[14:28] <Trevinho> tedg: Oh, I didn't read your comments (if you did) yet... But in my tests I was getting crashes
[14:28] <greyback> kgunn: yep, one hack in particular forcing gles2, but qts code uses gles1. In fact the driver reports EGL version 1.4, so I understand why Qt does what it does.
[14:28] <tedg> Trevinho, Are you on raring or saucy?
[14:28] <Trevinho> tedg: raring...
[14:28] <tedg> I think this is related to the new GTK in Saucy
[14:28] <Trevinho> tedg: ah, ok...
[14:29]  * tedg looks for the downgrade button
[14:29] <tedg> Is there a way to remove the deprecation warning for a function?
[14:29] <tedg> It seems like going back to image_info_free() and ignoring the deprecation for now seems sane.
[14:30] <Trevinho> tedg: mh, I don't think it's possible just for one
[14:30] <tedg> I bet if there is a gcc option for it, bregma would know it.  :-)
[14:30] <Trevinho> tedg: probably using an #ifdef is the best thing here
[14:31] <bregma> -Wno-deprecated ??
[14:31] <Trevinho> more than #ifdef, the gtk macro for version
[14:31] <Trevinho> bregma: yes, but that's general
[14:32] <Trevinho> bregma: and I think we want it for most of code
[14:33] <bregma> well, considering they've probably annotated the code with __attribute__((deprecated)),  you're probably out of luck
[14:33] <bregma> but deprecated just means it will be removed at some unspecified point in the future, so it should be OK to disable the warning in productionmode
[14:34] <tedg> Yeah, we're just compiling with -Werror
[14:34] <tedg> So it "breaks" the compile.
[14:34] <tedg> In general, I think that's a good thing, but it'd be nice to handle it for this one case.
[14:36]  * tedg wants __attribute__((i_know_that_its_deprecated))
[14:36] <bregma> it's generally a bad idea to have -Werror during packaging builds, because it causes much pain due to minor change in dependencies with little to no benefit, but that's my experience
[14:47] <nic-doffay> Saviq, I tried scaling the component down with some maths. It doesn't look good, I think we're going to opt for the multiple asset approach.
[14:47] <nic-doffay> It was the correct size, but it didn't look good.
[14:51] <Saviq> nic-doffay, sure, that might happen (as I said we're not pre-scaling them in HQ yet)
[14:51] <Saviq> nic-doffay, and we'll be able to revert to a single asset when that happens
[14:55] <Saviq> mzanetti, I just noticed a small bug on the launcher hint on a tablet... it doesn't hint when you press anywhere around the user list
[14:56] <Saviq> mzanetti, but does, when you press to the right of the user list...
[14:59] <Saviq> mzanetti, nic-doffay, about the blur, doesn't the stock Qt blur work?
[14:59] <nic-doffay> Saviq, too slow.
[14:59] <Saviq> nic-doffay, for a screenshot, even?
[15:00] <mzanetti> Saviq: yes. the List is on top... need to check with design what to do there
[15:00] <mzanetti> Saviq: re bur: no. it works fine on the desktop but is very slow on the phone
[15:00] <mzanetti> Saviq: the FastBlur doesn't work on the phone at all
[15:01] <mzanetti> Saviq: and the GaussianBlur is slow as hell ( >1s for one frame)
[15:01] <Saviq> mzanetti, uh
[15:01] <mzanetti> yep. exactly my reaction
[15:02] <mzanetti> Saviq: also. the GaussianBlur needs _a lot_ of iterations to achieve that much blurring.
[15:02] <Saviq> mzanetti, what about the recursive one?
[15:02] <mzanetti> Saviq: so if we downscale first and blur with 1/4 iterations it should already help
[15:02] <Saviq> mzanetti, k
[15:02] <mzanetti> Saviq: which recursive?
[15:02] <Saviq> mzanetti, http://qt-project.org/doc/qt-5.0/qtgraphicaleffects/qml-qtgraphicaleffects1-recursiveblur.html
[15:03] <mzanetti> oh... missed that one
[15:03] <Saviq> "takes more time"
[15:03] <mzanetti> ah ok
[15:03] <mzanetti> well if it does so with less iterations... will give it a shot to learn the difference
[15:03] <Saviq> k
[15:18] <nic-doffay> Saviq, could you pull from the infographic branch and test it on tablet?
[15:19] <nic-doffay> It looks small on desktop but fine on the phone.
[15:21] <Saviq> nic-doffay, screenshot coming right up
[15:21] <Saviq> nic-doffay, http://ubuntuone.com/5g8LsQ5CiBztSJKXbJGHxP
[15:21] <nic-doffay> Saviq, link doesn't seem to be workin
[15:21] <Saviq> hum
[15:22] <Saviq> nic-doffay, http://ubuntuone.com/5RY0CzR13IOe53TRAf6R3N
[15:22] <Saviq> nic-doffay, dots too big it seems
[15:22] <nic-doffay> Saviq, yeah sorted!
[15:23] <Saviq> nic-doffay, you can always go `GRID_UNIT_PX=20 ./run` after setting "tablet" to true in Shell.qml
[15:23] <Saviq> nic-doffay, that should get you the exact same result
[15:23] <nic-doffay> Saviq, awesome.
[15:30] <dednick_> mzanetti: ping
[15:33] <mzanetti> dednick: pong
[15:34] <dednick> mzanetti: hey. trying to figure out autopilot for UnityNext. anything special you need to get it working?
[15:35] <mzanetti> dednick: hmm. no, not really. install all depenedencies of qml-phone-shell-autopilot and then run "make autopilot" in the builddir
[15:37] <Trevinho> tedg: this should work everywhere https://code.launchpad.net/~3v1n0/unity/gtk-wrapper-icon-info/+merge/164434
[15:38] <nic-doffay> mzanetti, so I have a data model for the Infographics test. Should I just compare strings of the label when an animation has changed?
[15:39] <mzanetti> yeah. but more important are the bubbles radius etc
[15:45] <tedg> Trevinho, You've got conflicts :-)
[15:45] <Trevinho> tedg: yes, I'm fixing them :)
[15:45] <Trevinho> tedg: but the idea is that...
[15:46] <tedg> Sure, makes sense to me.
[15:46] <tedg> Grabbing the branch, I'll build it on Saucy.
[15:47]  * tedg will have results in 3 days
[15:47] <Trevinho> tedg: thanks, builds here, but crashes of course :P
[16:32] <tedg> Trevinho, So that branch crashes for me, but it seems to be in Nux, not anything Image Info related.  Perhaps?
[16:34]  * greyback eow
[16:34] <greyback> good weekend guys!
[16:35] <Trevinho> tedg: have you installed all the textures in proper path? It has changed..
[16:36] <tedg> Trevinho, I installed the packages...
[16:36] <tedg> http://paste.ubuntu.com/5674559/
[16:37] <tedg> Though that certainly looks like the issue.
[16:37] <Trevinho> tedg: mhmh
[16:37] <tedg> Trevinho, Which package has the textures?
[16:37] <Trevinho> tedg: unity-common should
[16:37] <Trevinho> tedg: the crash is weird though
[16:38] <Trevinho> tedg: new textures should be in /usr/share/unity/icons
[16:38] <tedg> This is the contents of my unity-common: http://paste.ubuntu.com/5674563/
[16:39] <tedg> It seems like they're in /usr/share/unity/6/ ?
[16:39] <Trevinho> tedg: that was before the 100 scopes landed...
[16:39] <tedg> It's your branch man ;-)
[16:39] <tedg> Do I need to repull it?
[16:40] <tedg> I must have grabbed it before you merged with trunk.
[16:40] <chiluk> Mirv for the compiz package in https://launchpad.net/~unity-team/+archive/sru/+packages that you uploaded can you tell me if a fix for https://bugs.launchpad.net/compiz/+bug/763148 is included?
[16:41]  * tedg is building again
[16:45] <tedg> Oh my, I now need libunity 7, which requires a new libdee
[16:49] <Trevinho> tedg: yes, and new nux
[16:49] <tedg> Oh, my, I'm not at that point yet.  Don't spoil the fun!
[16:49] <tedg> :-)
[16:49] <Trevinho> ehehe
[16:49] <Trevinho> tedg: well, not much changed on it, but there's a version mismatch since the daily ppa
[16:50]  * Trevinho loved the times of the staging ppa for these cases
[16:50] <Trevinho> using jhbuild is a solution, but also a waste of time for most of situations... I always prefer to build the minimum binaries  can...
[16:51] <tedg> Yeah, jhbuild I don't find to be that useful.
[16:52] <tedg> bregma, Yes, I think it has regressed.
[16:52] <tedg> bregma, But I don't think it should block daily releases.
[16:52] <bregma> agreed
[16:53] <bregma> Trevinho, was there any plan for a library transition with all these 100-scopes changes?  I didn't see one....
[16:53] <bschaefer> should we create a new bug to get it down 'formally'
[16:54] <Trevinho> bregma: I don't know.. andyrock ^
[16:54] <bregma> bschaefer, https://bugs.launchpad.net/hud/+bug/1180903
[16:57] <bschaefer> bregma, awesome then
[16:58] <Trevinho> tedg: fyi I resolved the conflicts in https://code.launchpad.net/~3v1n0/unity/gtk-wrapper-icon-info/+merge/164434 and added some more cleanups
[16:59] <bschaefer> bregma, I thought that bug would be marked as fixed when sil2100_ merged branch
[17:02] <tedg> Trevinho, Cool, I'm building the deps now, then I'll test.
[17:07] <bregma> bschaefer, his merge commit message does not close he bug, so the merge will only fix the AP failures and unblock the daily releases
[17:07] <bregma> the actual regression still needs to be fixed
[17:07] <bregma> at which point we may want to back out his timout changes
[17:09] <bschaefer> bregma, right, which makes sense
[17:17] <sil2100_> bregma: that's right
[17:39] <sil2100> hmmm
[18:47] <tedg> Trevinho, So this looks good.  Do we have to wait for Jenkins to top approve?
[18:49] <tedg> Jenkins said that it started 3 hours ago :-)
[18:54] <kgunn> mterry: ping
[18:55] <Trevinho> tedg: not strictly needed, we it will run everything before landing anyway
[18:57] <tedg> Trevinho, okay, then I'll top approve.
[20:49] <sil2100> fginther: ping
[20:50] <fginther> sil2100, what's up?
[20:50] <sil2100> fginther: hello Francis :)
[20:51] <sil2100> fginther: not sure who to ping regarding that, but some of the *scope* branches in CI add the prevalidation PPA, but I would need them to add the daily-build-next PPA instead now
[20:51] <sil2100> For instance, like in this MR
[20:51] <sil2100> https://code.launchpad.net/~submarine/unity-scope-audacious/bump-unity-deps/+merge/164364
[20:52] <fginther> sil2100, should they be in their own head/scopes.cfg stack now?
[20:53] <sil2100> fginther: oh, wait, hm... actually I added them to the head/unity.cfg stack
[20:53] <sil2100> fginther: so we should have a separate stack for those?
[20:53]  * sil2100 checks the docs
[20:53] <fginther> sil2100, no, adding to the unity stack may be the right answer
[20:54] <sil2100> fginther: since I added them to unity stack already, the branch landed and the stack is redeployed
[20:54] <fginther> sil2100, but we need to be notified to redeploy the upsteam jobs
[20:54] <fginther> s/upstream jobs/upstream merger jobs/
[20:55] <fginther> sil2100, until then, the ci/autolanding will still build against the old stuff
[20:56] <sil2100> fginther: since we're doing the switch now, with all the bits-and-pieces ready, I think we'll need the scopes branches start using upstream
[20:56] <sil2100> fginther: the scopes are now in the cu2d config and redeployed
[20:57] <fginther> sil2100, what file did you say they are in?
[20:58] <sil2100> head/unity.cfg
[20:59]  * fginther forgot to bzr pull
[20:59] <fginther> sil2100, sorry, it makes sense now
[21:00] <fginther> sil2100, I should just need to redeploy and it will switch to the -next ppa
[21:01] <fginther> sil2100, should be done in a minute
[21:01] <sil2100> fginther: thanks!
[21:01] <fginther> sil2100, we also need to restart the jenkins service, so it might be a while before the new jobs pick up branches
[21:02] <sil2100> fginther: ok, so clicking /rebuild will not work?
[21:04] <fginther> sil2100, no, since the ppa's changed the hook parameter will be wrong
[21:04] <fginther> sil2100, you can do a rebuild, but you would need to patch in the right name
[21:08] <sil2100> fginther: if not, the CI will pick up those branches and re-run by itself in some time, yes?
[21:08] <fginther> sil2100, the CI would only automatically run again if there was a new revision
[21:09] <sil2100> fginther: in the case of the scopes branches, there won't be new commits for now
[21:09] <fginther> sil2100, I'll scan those jobs for failures and restart any MPs I see when jenkins is back online
[21:10] <fginther> sil2100, shouldn't be too much of an issue
[21:10] <fginther> sil2100, gotta go
[21:10] <fginther> have a good weekend :-)
[21:14] <sil2100> Have a good weekend as well, thanks!
[21:14] <sil2100> Oh, btw!
[21:14] <sil2100> fginther: will this get done now?
[21:15] <sil2100> I mean, will that happen automatically?
[21:17] <sil2100> kenvandine: approved!