[07:37] <liuxg> zbenjamin, ping
[07:38] <zbenjamin> liuxg: yes
[07:39] <liuxg> zbenjamin, an armhf click pacakge can only be deployed to a armhf emulator, right?
[07:39] <zbenjamin> liuxg: what else would you do with it
[07:40] <liuxg> zbenjamin, if the developer does not have a phone yet, he can use the armhf emulator to try an armhf click package. is this OK?
[08:23] <tsdgeos> landing \o/
[09:12] <tsdgeos> Saviq: doh, CI still on utopic :/
[09:12] <tsdgeos> FAILURE everywhere
[09:13] <tsdgeos> because libunity-api-dev can't be found
[09:13] <Saviq> tsdgeos, it should switch soon
[09:13] <Saviq> tsdgeos, like tonight
[09:13] <tsdgeos> ok
[09:53] <tsdgeos> Cimi: Saviq-codedive: so i have these changes for the croppedimagesizer to make it more async, question is, do we want it as a third branch on top of the other two (croppedimagesizer->photoscopeimprovements->asyncroppedimagesizer)
[09:53] <tsdgeos> or not?
[09:53] <tsdgeos> because the two branches as we have it are already an improvement
[09:54] <tsdgeos> and this new one introduces more improvements but also more complexity
[09:54] <tsdgeos> wonder if we want it separate just in case we want to eventually only land the first two and this one later
[09:54] <Cimi> tsdgeos, I just want someone to test it
[09:58] <tsdgeos> Cimi: that doesn't asnwer my question :D
[09:58] <Cimi> tsdgeos, if branch works, we can have them together
[09:59] <Cimi> tsdgeos, however, thinking on how management rejects stuff
[09:59] <Cimi> tsdgeos, is probably better to split them, so if async breaks things, we won't revert *all*
[10:05] <tsdgeos> Cimi: that was my thinking
[10:05] <tsdgeos> i'll do a separate branch
[10:37] <Cimi> sorry - back
[10:54] <Saviq-codedive> tsdgeos, separate, yeah
[10:54] <Saviq-codedive> tsdgeos, we might land it all together, but it'll be nice to have some granularity
[10:56] <tsdgeos> can someone remind me how to get the wizard to run again?
[10:57] <tsdgeos> Saviq-codedive: ↑ ?
[10:57] <Saviq-codedive> tsdgeos, phablet-config --help
[10:59] <Saviq-codedive> grr
[11:14] <MacSlow> Is anyone seeing these errors with bzr under vivid ? -> http://pastebin.ubuntu.com/8834245
[11:23] <Saviq-codedive> MacSlow, yes
[11:23] <Saviq-codedive> MacSlow, bug #1366684
[11:25] <Saviq-codedive> MacSlow, you need to downgrade configobj
[11:25] <Saviq-codedive> MacSlow, let me get you a package
[11:30] <Saviq-codedive> MacSlow, it will build soon in https://launchpad.net/~saviq/+archive/ubuntu/ppa/+sourcepub/4552771/+listing-archive-extra
[11:30] <Saviq-codedive> MacSlow, you'll need to downgrade and hold it
[11:31] <MacSlow> Saviq-codedive, ah... thanks
[11:31] <Saviq-codedive> MacSlow, it's because of your surname, and my first name
[11:32] <MacSlow> Saviq-codedive, *sigh* still such issue in 2014
[11:55] <Saviq-codedive> MacSlow, it's built in the PPA now
[12:02] <dandrader> mzanetti, you there?
[12:03] <mzanetti> dandrader: yes
[12:04] <dandrader> mzanetti, so, if I change unity-api, and then unity8 to depend on this newer, unreleased, unity-api. How will that work with recipes in a PPA?
[12:04] <dandrader> mzanetti, ie, how to make the unity8 recipe use this unity-api from another recipe. will that just work as they land on the same PPA? how does that work?
[12:05] <greyback> dandrader: PPA will build against the newest version of the package. If the PPA contains that new version, it'll use that over those in the archive.
[12:06] <greyback> dandrader: so just have unity-api in the PPA (bumped package version), and to be sure, make unity8 depend on that version
[12:07] <dandrader> greyback, so the new unity-api must have been uploaded to the ppa before I trigger the unity8 recipe, right?
[12:07] <mzanetti> yes
[12:07] <mzanetti> dandrader: actually, its clever enough to wait for it
[12:07] <greyback> dandrader: yes. unity8 will sit in a "package dependency wait" until unity-api ready
[12:07] <mzanetti> if the ppa has a older version then the required one
[12:07] <dandrader> greyback, mzanetti hmm, nice. thanks!
[12:08] <tsdgeos> that's because it's based in utopic
[12:08] <tsdgeos> same problem all our CI jobs are having
[13:11] <mzanetti> MacSlow: hey, we're missing you in the team channel
[13:12] <MacSlow> mzanetti, hm... what channel am I missing from?
[13:12] <mzanetti> #unity
[13:12] <facundobatista> Hola
[13:12] <MacSlow> mzanetti, oh... indeed...that's odd...
[13:12] <MacSlow> mzanetti, thanks for the heads-up
[14:12] <mterry> MacSlow|errand, I have questions about how to stop a PIN unlock dialog from appearing in some cases when you get back
[14:24] <greyback> mzanetti: just minor comment on https://code.launchpad.net/~mzanetti/qtmir/sg-imagenode/+merge/240583
[14:24] <mzanetti> greyback: cool, thanks
[14:24] <mzanetti> greyback: what about the jenkins failure? think its a real one?
[14:25] <mzanetti> greyback: some test segfaulted, but I don't really see how it's related
[14:25] <greyback> mzanetti: I didn't check it out, assumed it might be the vivid switch that might screw stuff up
[14:25] <greyback> none of our tests exercise the code you touched anyway
[14:27] <MacSlow> mterry, stop it from appearing? don't trigger the notification! :)
[14:28] <mterry> MacSlow, I'm looking at a situation where we get two SIM unlock dialogs, enter emergency mode via the first one, and thus don't want to see the second one...
[14:30] <mterry> MacSlow, actually, let me confirm whether we get both notifications at same time or serially
[14:31] <mterry> MacSlow, looks like serially.  So yeah, I'd like someway to skip incoming notifications...
[14:34] <MacSlow> mterry, well you can use the close-method
[14:35] <MacSlow> mterry, see lp:unity-notifications/examples/sd-example-incoming-call-canceled.py for an example
[14:58] <mzanetti> greyback: fixed
[14:58] <greyback> mzanetti: ta
[15:04] <greyback> dandrader: hey just trying our your rotation stuff while I wait for desktop to compile, am loving the animation!
[15:04] <greyback> dandrader: panel icons are wrongly placed after the animation though, aware of that?
[15:05] <dandrader> greyback, yes, added a work item to the doc
[15:05] <dandrader> greyback, also, Elleo just fixed ubuntu-keyboard. new package should arrive soon (https://code.launchpad.net/~unity-team/+recipe/ubuntu-keyboard-shellrotation)
[15:06] <dandrader> greyback, if you interact with the indicator panel, the icons shift back to their proper places
[15:08] <greyback_> dandrader: stupid NM - "oh even though you're connected to an AP, I'm gonna move you to another AP for no bloody reason"
[15:53] <pete-woods> hello unity8 people! if I want to do a gradient, e.g. in a scope header, has the syntax / namespace changed?
[15:54] <pete-woods> oh wait
[15:55] <pete-woods> it's just the error message that's confusing
[15:55] <pete-woods> I had gradient:///#aarrggbb/#aarrggbb
[15:55] <pete-woods> and instead of saying the gradient was invalid, it told me the gradient schema was unknown
[16:27] <mterry> MacSlow, what would be the best way to fake notifications in the shell during a test?  I see some tests that use a fake model for a custom Notifications object...  But the actual mock Unity.Notifications plugin seems empty
[16:27] <MacSlow> mterry, need to mock in a qmltest or an autopilot-test?
[16:28] <mterry> MacSlow, I was thinking qmltest
[16:28] <mterry> MacSlow, I *could* do some testing of just the menuitemfactory using a fake model, but had been planning on doing a full shell test
[16:29] <MacSlow> mterry, hm... a full test like that only has been implemented on the autopilot-side
[16:30] <mterry> MacSlow, I've been avoiding autopilot these days  :)
[16:30] <MacSlow> mterry, the mocks (for notifications) on the qmltest-side are just for exercising the pure rendering/layout features
[16:30] <MacSlow> mterry, I totally understand :)
[16:31] <MacSlow> mterry, there are very simplistic action/button-invocation checks on the qmltest-side of things... but nothing is doing full shell-integration testing
[16:31] <mterry> MacSlow, seems like a gap!  But a bit involved for me to implement from scratch for this one small rtm bugfix
[16:32] <mterry> Maybe I'll just go for more targetted testing for now
[16:32] <MacSlow> mterry, well the "gap" is still served by the autopilot-based tests
[16:32] <mterry> MacSlow, right, not that we have no testing.  Just a gap on qmltest side  :)
[16:33] <mterry> MacSlow, fair... I could do an autopilot test anyway
[16:33] <mterry> they won't be dead forever
[16:33] <MacSlow> mterry, you can borrow from lp:unity8/tests/autopilot/unity8/shell/tests/test_notifications.py
[16:35] <robotfuel> mterry: I'd be happy to help you with problems you have when writing autopilot tests, let me know if you'd like a review if you have an issue.
[16:38] <mterry> robotfuel, well it's more about our autopilot test framework giving sketchy results in jenkins
[16:38] <mterry> robotfuel, but will do!
[16:38] <robotfuel> mterry: I am working on fixing the failing tests in the dashboard. so hopefully they will be less sketchy soon
[16:39] <mterry> nice!  :)
[16:56] <dandrader> dednick, hey
[16:56] <dandrader> dednick, how busy are you? working on any RTM task?
[16:56] <dednick> dandrader: howdy
[16:57] <dednick> dednick: none of the uber critical ones at the moment.
[16:57] <dandrader> dednick, I need some help with the indicators in the shellRotation branch
[16:57] <dednick> dandrader: sure
[16:58] <dandrader> dednick, let me push the branch to ~unity-team so that you can work on it as well...
[16:59] <dandrader> dednick, it's here. lp:~unity-team/unity8/shellRotation and this is the ppa: https://launchpad.net/~unity-team/+archive/ubuntu/demo-stuff
[17:00] <dandrader> dednick, the problem is that when unity8 rotates, the icons in the indicator shift to a weird position
[17:00] <dandrader> dednick, they come back into place only once you interact with then again
[17:00] <dednick> dandrader: right
[17:00] <dandrader> dednick, when unity8 rotates it resizes Shell.qml, which resizes the indicators
[17:00] <dednick> dandrader: able to do it on desktop?
[17:01] <dandrader> dednick, unfortunately I couldn't reproduce it in "make tryOrientedShell" :-/
[17:01] <dednick> dandrader: ok. i'll take a look
[17:01] <dandrader> dednick, thanks!
[17:02] <dednick> dandrader: is the ppa for rtm image?
[17:09] <dednick> dandrader: i take it that silo is not for rtm image? ie devel-proposed?
[17:14] <dandrader> dednick, this PPA has packages for both utopic (thus rtm?) and vivid
[17:15] <dandrader> dednick, but the feature is not targeted for RTM at all
[17:15] <dednick> dandrader: i meant 14.09
[17:15] <dandrader> dednick, so it makes sense to use on top of devel-proposed
[17:15] <dednick> dandrader: but nevermind. just using devel
[17:15] <dednick> dandrader: where does unity-shell-launcher come from?
[17:15] <dednick> dandrader: can never remember...
[17:15] <dednick> libunity-api ?
[17:16] <dandrader> dednick, you mean in the cmake files? yeah, comest from unity-api
[17:17] <dednick> dandrader: hm. package 'unity-shell-launcher=5' not found
[17:22] <dandrader> dednick, where do you get it?
[17:22] <dednick> dandrader: on the desktop.
[17:24] <dandrader> dednick, did you "apt-get update && apt-get dist-ugprade"?
[17:24] <dandrader> dednick, is your desktop on vivid?
[17:24] <dandrader> dednick, if all fails, built and install unity-api from trunk
[17:24] <dednick> dandrader: no, still on utopic
[17:24] <dandrader> dednick, that explains it then I guess
[17:25] <dednick> dandrader: but you just said there are packages for both :)
[17:25] <dandrader> dednick, take the leap! :)
[17:25] <dednick> never!
[17:25] <dandrader> dednick, on the PPA there are utopic and vivid packages of the project modified for shell rotation
[17:25] <dandrader> dednick, and unity-api is not one of them yet
[17:26] <dednick> dandrader: ah. the u8 in the ppa does not include your rotation stuff?
[17:26] <dandrader> dednick, it does, of course
[17:26] <dednick> dandrader: well then!
[17:26] <dednick> :)
[17:26] <dandrader> now you confused me
[17:27] <dednick> me too
[17:27] <dednick> it shouldnt build utopic packages for u8 if i can't do it on my utopic machine.
[17:27] <dandrader> dednick, right
[17:27] <Saviq-codedive> we only bumped unity-api overnight
[17:27] <Saviq-codedive> dednick, ↑
[17:28] <dandrader> dednick, now I'm thinking about removing the utopic builds from the recipes. greyback_?
[17:28] <dednick> ah
[17:28] <Saviq-codedive> yeah, utopic is old news!
[17:28] <dednick> dandrader: guess that the silo hasn't rebuilt since then
[17:28] <greyback_> dandrader: if you wish. Can enable it again if we really need them
[17:31] <dednick> fek. i'll do an upgrade in the morning. dont have time now!
[17:33] <dednick> dandrader: ok, i see the problem.
[17:42] <dednick> dandrader: stupid flickable is re-asserting it's control over contentX
[17:42] <dednick> sigh.
[17:42] <dandrader> dednick, are you able to reproduce it in qml tests or only on the device?
[17:43] <dednick> dandrader: only on device now. i havent been able to build on destop
[17:43] <dandrader> ah, right
[17:44] <dednick> dandrader: flickable doesnt really like me messing around with contentX. it's a bit of a hack
[17:44] <mzanetti> mterry: hey, will you add the test here? https://code.launchpad.net/~mterry/unity8/skip-second-sim-unlock/+merge/240737
[17:45] <mterry> mzanetti, I was looking into it, seems we don't have a great framework for adding a qmluitests, but an autopilot test may work.  But then I got distracted by an important ongoing wizard bug and lunch.  I don't want to block the above MP on a test unless reviewers feel it's necessary
[17:48] <dednick> dandrader: i've got to go for the eve. i'll take some more look at it tomorrow
[17:49] <mterry> mzanetti, (I mean, I want to add that test anyway, but just if I don't get to it today, I don't want to block that MP for the next several days just on that)
[17:50] <mzanetti> mterry: https://code.launchpad.net/~mterry/unity8/skip-second-sim-unlock/+merge/240737/comments/592058
[17:50] <mterry> mzanetti, awesome -- yeah as you mention, apparently we don't test the SIM unlock dialog at all right now in our tests, let alone this special case of it
[17:53] <mzanetti> mterry: did you ever notice that weird bug if you use the emergency dialer and then return to normal operation, the first right edge swipe animation is somewhat broken
[17:55] <mzanetti> not sure yet what causes it
[17:58] <mterry> mzanetti, no haven't noticed that
[19:14] <Saviq> om26er, just quick feedback: onClicked: checkBox.checked = !checkBox.checked
[19:15] <Saviq> om26er, not that I like having this in the first place (remember we talked that this should be an SDK feature)
[19:16] <om26er> Saviq, oh, I have probably forgot our last conversation then ;)
[19:17] <om26er> Saviq, also thanks for the simpler version :)