[05:20] <skrishna> I am not finding VLC menu in ubuntu unity... can anyone please tell me how to fix it ?
[08:05] <davidcalle> didrocks, salut! I'd like some Jenkins wizardry on server scopes branches, do you know how I could make that happen?
[08:05] <didrocks> davidcalle: ah, here you are :) you want to have upstream merge on those branches, right?
[08:06] <didrocks> davidcalle: like merging to trunk?
[08:06] <davidcalle> didrocks, indeed
[08:06] <didrocks> davidcalle: this is for mmrazik ^
[08:07] <sil2100> pstolowski: hi, officially something needs to be done with that timeout test, as it even failed on powerpc now
[08:08] <mmrazik> davidcalle: can you create a merge proposal for this file/branch: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/view/head:/stacks/head/unity.cfg ?
[08:08] <mmrazik> davidcalle: it should be as easy as appending the name of the projects to the file
[08:08] <pstolowski> sil2100: hmm, ok
[08:08] <mmrazik> davidcalle: assign the mp to me then (mrazik is my launchpad id)
[08:08] <mmrazik> I'll approve and create the respective jenkins jobs out of that config
[08:09] <davidcalle> mmrazik, didrocks, sounds good, thanks :)
[08:26] <sil2100> pstolowski: since powerpc failed twice already now with: ERROR:test-scope.c:4078:main_scope_tester_preview_result: assertion failed: (run_with_timeout (ml))
[08:27] <pstolowski> sil2100: ok, looking at this test
[08:29] <sil2100> pstolowski: thanks!
[08:51] <davidcalle> mmrazik, https://code.launchpad.net/~submarine/cupstream2distro-config/server-scopes/+merge/165308
[08:52] <mmrazik> didrocks: is the stack above (^^^) ok or shall we rather create something like unity-server.cfg?
[08:54] <didrocks> mmrazik: I would prefer a separate release and file
[08:54] <didrocks> mmrazik: as this is never going to be for daily release
[08:55] <mmrazik> didrocks: so even release? i.e. out of head?
[08:59] <didrocks> mmrazik: yeah, it's not something that will follow releases
[08:59] <didrocks> mmrazik: maybe call it server/ ?
[08:59] <didrocks> or online/ ?
[08:59] <mmrazik> didrocks: ok
[09:00] <mmrazik> davidcalle: I'll take your MP and do what needs to be done
[09:00] <davidcalle> mmrazik, thanks :)
[09:02] <mmrazik> didrocks: can you have a look on this (stack membership primarily): https://code.launchpad.net/~mrazik/cupstream2distro-config/dbus-cpp/+merge/165310
[09:04] <didrocks> mmrazik: hum, let's wait for launchpad to answer and show your branch, but platform (from the description) sounds good to me :)
[09:04] <mmrazik> mhm.. takes ages to generate it
[09:04] <mmrazik> I'm going to add one more revision anyway... (coverage hooks)
[09:04] <nic-doffay> Saviq, you around?
[09:05] <Saviq> nic-doffay, here
[09:05] <didrocks> mmrazik: no daily release yet, right?
[09:05] <mmrazik> didrocks: I don't know. Why would we want to opt out from daily release?
[09:06] <didrocks> mmrazik: is it cleaned? checked for daily release?
[09:06] <mmrazik> tvoss: ^^^ (aboud dbus-cpp)
[09:06] <nic-doffay> Saviq, cool. Quick question, I have an animation which needs to be used in a SequentialAnimation and alone. Can I call it from the SequentialAnimation without triggering the next animation?
[09:06] <nic-doffay> by it's id
[09:06] <mmrazik> didrocks: what do you mean by cleaned?
[09:06] <didrocks> I think we should first ensure that's it's fine and ready for it, checked and released :)
[09:06] <mmrazik> ok
[09:06] <mmrazik> didrocks: I'll add daily_release: False then
[09:06] <didrocks> mmrazik: remember that if it's failing, the whole stack is blocked
[09:06] <Saviq> nic-doffay, I don't see why not, but feels funky :)
[09:06] <didrocks> hence the sanity checking
[09:06] <didrocks> I can add it to our list of things to do
[09:07] <didrocks> but needs to be properly done first :)
[09:07] <didrocks> mmrazik: thanks!
[09:07] <didrocks> commented
[09:07] <nic-doffay> Saviq, you think I should copy and paste it over?
[09:07] <Saviq> nic-doffay, you'd need to make sure the state of the Sequential one after you've ran the one inside is sane
[09:08] <Saviq> nic-doffay, it just feels funky, but should be fine :)
[09:08] <mmrazik> didrocks: thanks
[09:08] <Saviq> nic-doffay, after all a SeqAnim is just a wrapper around other Anims
[09:08] <mmrazik> tvoss: I'll create a dummy MP to lp:dbus-cpp just to see if coverage works as expected in jenkins
[09:08] <Saviq> nic-doffay, so it should be possible to control them independently when the SeqAnim isn't doing it
[09:09] <Saviq> nic-doffay, did you try already?
[09:10] <tvoss> mmrazik, ack
[09:11] <nic-doffay> Saviq, hadn't tried already, but figured I'd ask your opinion on the better way to achieve it so I wouldn't have to go back during the MP review
[09:11] <Saviq> nic-doffay, I'm good either way, really
[09:16] <mmrazik> davidcalle: noticed you added daily_release: False to unity-scope-imdb
[09:16] <mmrazik> should it be also in the online part?
[09:17] <mzanetti> nic-doffay: ping
[09:18] <nic-doffay> mzanetti, what's up
[09:18] <davidcalle> mmrazik, yes, it's being completely removed client side, it might come back online.
[09:18] <mzanetti> nic-doffay: hey. any news on the Blur?
[09:18] <nic-doffay> mzanetti, yeah. I've done a shader.
[09:18] <mzanetti> nic-doffay: how's performance on the phone?
[09:18] <nic-doffay> It scales the image by a multiple.
[09:18] <nic-doffay> mzanetti, haven't tried it yet, been busy putting finishing touches on the infographics
[09:19] <mzanetti> nic-doffay: ok. where's the branch?
[09:19] <nic-doffay> mzanetti, no branch yet, I'll push one if you'd like.
[09:19] <mzanetti> nic-doffay: yes please
[09:20] <nic-doffay> mzanetti, my suggestion would be to copy and paste the existing GaussianBlur shader code which Qt uses and add the code from my vertex shader to it.
[09:20] <nic-doffay> Call it ScaleWithGaussianBlur
[09:20] <nic-doffay> Or something.
[09:21] <tvoss> mmrazik, got a url for me for dbus-cpp?
[09:21] <nic-doffay> Since it can be done in pass, it will make it faster then calling the Scale shader separately and then doing the blur.
[09:21] <mzanetti> nic-doffay: hmm... I still think that's too slow. even if scaled down. but lets try
[09:21] <mmrazik> tvoss: url for what? a jenkins job?
[09:21] <nic-doffay> mzanetti, ok I have another idea if it's still too slow.
[09:21] <nic-doffay> I'll push to a branch now.
[09:21] <tvoss> mmrazik, yup
[09:21] <mmrazik> its not ready yet. There is some weird problem with coverage. Just looking into ti
[09:21] <mmrazik> tvoss: https://jenkins.qa.ubuntu.com/job/dbus-cpp-raring-amd64-ci/3/console
[09:22] <mmrazik> I don't understand why I'm getting permission denied
[09:24] <tvoss> mmrazik, you sure that gcovr is available?
[09:24] <tvoss> mmrazik, the packaging setup only installs lcov
[09:24] <mmrazik> tvoss: yup. gcovr is in the base image as we use it for most projects
[09:24] <Saviq> mzanetti, how did the recursive one cope?
[09:24] <mmrazik> tvoss: even these hooks are used in other projects
[09:25] <tvoss> mmrazik, okay ...
[09:25] <tvoss> interesting
[09:25] <tvoss> mmrazik, seems like it is not even able to access the coverage-xml.cmake due to permission denied
[09:25] <Saviq> mzanetti, a small one https://code.launchpad.net/~unity-team/unity/phablet.fix-run-device-mousetouch/+merge/165321
[09:25] <mmrazik> tvoss: I don't think so. gcovr is apparently executed
[09:26] <mmrazik> and its gcovr that throws the OSError
[09:26] <MacSlow> Saviq, mzanetti: Is implicitHeight meant to work with expanding/changing layouts? Expanding works, but shrinking does not.
[09:26] <mzanetti> MacSlow: should work I'd say
[09:26] <tvoss> mmrazik, ah
[09:26] <Saviq> MacSlow, yeah, it should be used in stead of height
[09:26] <mmrazik> tvoss: so it looks like the result can't be saved
[09:26] <mzanetti> Saviq: ack (on the review)
[09:26] <mmrazik> or something like tht
[09:27] <mzanetti> Saviq: let me test the recursive one. not much hope tho...
[09:27] <Saviq> MacSlow, what's your usecase? column with expanding/shrinking things?
[09:30] <Saviq> MacSlow, http://pastebin.ubuntu.com/5693130/ works, so I'd say yes
[09:32] <mzanetti> hey. I've just apt-get upgraded and now the shell segfaults with: Settings schema 'com.canonical.Unity.Dash' does not contain a key named 'home-lens-ordering'
[09:32] <mzanetti> I did merge with trunk
[09:34] <mzanetti> Saviq: any ideas? ^
[09:35] <Saviq> mzanetti, hum, sounds like some version mismatch
[09:36] <mzanetti> ok... just wiped unity_build and currently rebuilding. lets see
[09:36] <mzanetti> nope... still crashing
[09:37] <Saviq> mzanetti, ah, you mean the qml shell crashes?
[09:37] <MacSlow> mzanetti, Saviq: hm... I see... that's the issue at work btw... http://ubuntuone.com/0Eh6U1vGofYb6sHQjF3sl6
[09:37] <mzanetti> Saviq: yes
[09:38] <mzanetti> is it about the overall height of the notification?
[09:38] <mzanetti> I wouldn't use implicitHeight there tbh
[09:38] <Saviq> mzanetti, apt-cache policy unity-common
[09:39] <mzanetti> Saviq: http://paste.ubuntu.com/5693149/
[09:39] <Saviq> MacSlow, that's unrelated to implicitHeight
[09:39] <Saviq> MacSlow, it worked in my example after all
[09:39] <Saviq> mzanetti, yeah, daily-build-next
[09:39] <mzanetti> Saviq: not good?
[09:40] <Saviq> mzanetti, evidently not
[09:40] <mzanetti> f*** those ppas
[09:40] <Saviq> mzanetti, looks like you got 100scopes
[09:41] <Saviq> mzanetti, why wouldn't you use implicitHeight? isn't that exactly what it's there for?
[09:41] <mzanetti> Saviq: I'd say no. but I know that our opinion on that differs ;)
[09:41] <Saviq> ;)
[09:43] <Saviq> didrocks, does daily-build-next raring build unity7 off of trunk?
[09:43] <didrocks> Saviq: yeah
[09:44] <Saviq> didrocks, that on purpose? ;)
[09:44] <didrocks> Saviq: why shouldn't it? :)
[09:44] <didrocks> Saviq: that's how daily build works :p
[09:44] <mzanetti> Saviq: works again. thanks
[09:44] <Saviq> didrocks, well, it's never going to land in raring, is it
[09:44] <Saviq> didrocks, but yeah, I get it
[09:44] <didrocks> Saviq: yeah, daily-build-next is while we can't upload to saucy
[09:44] <didrocks> so normally until saucy opens
[09:44] <didrocks> but the issue is that you had a lot of transitions in touch
[09:45] <didrocks> like autopilot 1.3
[09:45] <Saviq> got it
[09:45] <didrocks> and all is interelated
[09:45] <didrocks> so we'll have to land everything at once in saucy :)
[09:45] <Saviq> not the desired behaviour, then
[09:45] <didrocks> which is next week I guess
[09:45] <didrocks> well, desired behaviour… until saucy opens
[09:45] <didrocks> now, converging with touch made it hard…
[09:45] <Saviq> yeah, I get it
[09:49] <mzanetti> Saviq: RecursiveBlur is another order of magnitude slower than the Gaussian one :/
[09:49] <Saviq> mzanetti, yeah, expected that
[09:49] <mzanetti> +1
[09:53] <Saviq> MacSlow, got a fix for you
[09:53] <Saviq> MacSlow, use "contentColumn.height" instead of "childrenRect.height" in line 33
[09:54] <MacSlow> Saviq, already tried that... but then I've have issues with bottom margins not being correct
[09:54] <Saviq> MacSlow, still, that gets you closer, doesn't it ;)
[09:55] <tvoss> mmrazik, any luck?
[09:55] <MacSlow> Saviq, sure... but it's trading one issue with another :)
[09:55] <Saviq> MacSlow, childrenRect is difficult like that
[09:56] <Saviq> MacSlow, height: implicitHeight + spacing * 2
[09:56] <Saviq> MacSlow, line 57
[09:56] <mmrazik> tvoss: not really. I think there is something broken in dbus-cpp as I'm unable to run coverage-xml locally as well
[09:56] <mmrazik> but don't know what it is yet
[09:56] <MacSlow> Saviq, and when I did the expansion/collapsing once the bottom margin is correct for the collapsed snap-decision... *sigh*
[09:57] <Saviq> MacSlow, the two changes above fix everything for me, no?
[09:57] <MacSlow> Saviq, let's see that second change...
[09:58] <MacSlow> Saviq, ah indeed... interesting
[09:59] <Saviq> MacSlow, only thing now is there's a spacing-high jump at the beginning and end
[09:59] <Saviq> MacSlow, and actually, get rid of the height of the column altogether
[09:59] <MacSlow> Saviq, yeah... that's what I'm seeing here too
[09:59] <mmrazik> tvoss: oh
[09:59] <mmrazik> I think I start to know what it is
[09:59] <Saviq> MacSlow, and go for "implicitHeight: contentColumn.height + contentColumn.spacing * 2" for the UbuntuShape
[10:00] <mmrazik> give me a sec
[10:01] <Saviq> MacSlow, that jump is because of spacing :/
[10:01] <MacSlow> Saviq, ok... the height jump is still there... but since this is just a temp. solution for the expansion until we've the proper UI-element in the toolkit I can live with this
[10:02] <Saviq> MacSlow, I'll fix it, gimme a chance ;)
[10:02] <tvoss> mmrazik, coverage-html not working either ... seems like a parsing issue
[10:02] <MacSlow> Saviq, ok... go wild! :)
[10:02] <mmrazik> tvoss: oh. ok. For a second I thought it is because of non-existing directories from --exclude (copy&pasted from mir)
[10:02] <mmrazik> but it is not that
[10:03] <tvoss> hmm
[10:03] <tvoss> mmrazik, might be the case, too
[10:03] <mmrazik> mhm
[10:03] <mmrazik> maybe it is in the end
[10:03] <mmrazik> I'll create a branch and will see if it works in jenkins
[10:04] <mmrazik> tvoss: oh... I think its the missing CMAKE_GCOV variable
[10:04] <mmrazik> its not defined anywhere AFAICS
[10:05] <tvoss> mmrazik, nope, issue is that I'm running the tests under dbus-test-runner by default
[10:05] <tvoss> mmrazik, are you building in a chroot?
[10:05] <mmrazik> tvoss: yes
[10:05] <mmrazik> tvoss: but the tests are passing
[10:08] <tvoss> mmrazik, sure, but that's not the issue. the coverage files are not placed in the right directory
[10:10] <MacSlow> Saviq, I'll keep going at the test to work again
[10:18] <Saviq> MacSlow, here's a diff against your current branch http://pastebin.ubuntu.com/5693233/
[10:19] <MacSlow> Saviq, ok... trying it now...
[10:22] <Saviq> MacSlow, I'd also do http://pastebin.ubuntu.com/5693239/ to reduce the opacity change weirdness
[10:23] <Saviq> MacSlow, as QML by default applies the opacity to all the underlying objects
[10:23] <Saviq> MacSlow, which results in the avatar and the red button, for example, apparently disappear later than the other elements
[10:24] <MacSlow> Saviq, never noticed that before
[10:25] <Saviq> MacSlow, do you see the difference, though?
[10:26] <Saviq> MacSlow, you can use --slow-animations to qmlscene to notice it more
[10:27] <Saviq> MacSlow, you can read about layers here http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-item.html#layer.effect-prop
[10:28] <Saviq> mzanetti, btw, re implicitHeight, "Setting the implicit size is useful for defining components that have a preferred size based on their content, for example"
[10:28] <Saviq> mzanetti, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-item.html#implicitWidth-prop ;)
[10:29] <mzanetti> Saviq: yes
[10:29] <mzanetti> Saviq: but the notifications don't have a preferred size, they have a definiteve size
[10:29] <mzanetti> definitive... its not that they would like to be sized like this. they _have to_ be sized like this
[10:29] <Saviq> mzanetti, not necessarily, whoever uses them can decide otherwise
[10:29] <Saviq> because they want to
[10:30] <mzanetti> Saviq: they are not components to be used somewhere else
[10:30] <mzanetti> at least not the way they are now
[10:30] <Saviq> mzanetti, yeah, well, I just like the property there to be noticed, I think
[10:31] <MacSlow> Saviq, using the --slow-animations switch makes the interactive test act all weird here
[10:33] <MacSlow> Saviq, but I see now what you mean regarding the opacity of avatar-icons and the tinted button... although it's just a very subtle difference
[10:33] <Saviq> MacSlow, it's still there, even if subtle :D
[10:33] <Saviq> MacSlow, I can see it without --slow-animations, so ;)
[10:34] <MacSlow> Saviq, no doubt... thanks for the heads up... I'll keep that change and will remember the --slow-animations switch for visual debugging in the future
[10:34] <Saviq> MacSlow, we should probably make more use of layers when animating opacity on complex components
[10:34] <Saviq> mzanetti, WDYT ^?
[10:34] <Saviq> mzanetti, http://pastebin.ubuntu.com/5693239/
[10:35] <mzanetti> makes sense to me. BUT: its not something that one should do without understanding what happens
[10:35] <mzanetti> Saviq: ^
[10:36] <MacSlow> Saviq, I added a comment to that, so one (me) doesn't forget why it's there :)
[10:36] <mzanetti> because it can slow down things if used wrong
[10:36] <Saviq> mzanetti, yeah, of course, but should actually speed up in that case
[10:36] <mzanetti> I'd say, yes
[10:36] <mzanetti> is it that much of a problem tho?
[10:37] <mzanetti> Notifications don't seem that complex to me that it would require this already
[10:37] <sil2100> didrocks: uuuh oooh, nooo~! Something happened and unity tests did not run
[10:37] <Saviq> MacSlow, add populate.running || there, too
[10:37] <Saviq> mzanetti, I can see the visual difference between the two
[10:37] <mzanetti> how can I test?
[10:37] <Saviq> mzanetti, when you apply the opacity animation without the layer
[10:37] <Saviq> mzanetti, merge lp:~macslow/unity/phablet-snap-decision-action-expansion
[10:38] <didrocks> sil2100: mind checking with the QA people?
[10:38] <Saviq> and $ qmlscene --slow-animations -I builddir/tests/utils/modules/ tests/qmltests/Notifications/tst_Notifications.qml
[10:38] <Saviq> damn ^W
[10:38] <mzanetti> :D
[10:38] <dednick> Saviq: ping
[10:38] <Saviq> dednick, pong
[10:38] <Saviq> mzanetti, it's easiest to see with the snap decision
[10:39] <Saviq> mzanetti, the buttons / avatar "disappear" at a different rate than the rest
[10:39] <Saviq> due to the contrast between them
[10:39] <sil2100> didrocks: actually, it seems unity got removed before the test, huh
[10:40] <dednick> Saviq: re this indicator-client move. I've moved everything into unity, and also done first pass of the indicator file monitoring. But until we have those .indicator files, we cant really remove the plugin framework that was done (because that's how it determined which indicators to load). unless i just hardcode them to load manually.
[10:40] <Saviq> mzanetti, it's not about the speed in this case, it's about the transition
[10:40] <dednick> Saviq: or i can export the files from unity for the time being
[10:41] <Saviq> larsu, ^ any comment on when the .indicator files will be available?
[10:41] <Saviq> dednick, I think it's fine if we "ship" the .indicator files in the mean time
[10:42] <Saviq> dednick, and then just flip the switch to read from the real place
[10:42] <Saviq> dednick, when they're there
[10:42] <Saviq> dednick, assuming we know its format
[10:42] <dednick> Saviq: cool. thats what i was hoping we could do.
[10:42] <mzanetti> hmm... can't really see any difference here
[10:42] <didrocks> sil2100: is the ppa in a consistent state?
[10:42] <MacSlow> Saviq, mzanetti: pushed the fixes sofar... thx for the help!
[10:44] <mzanetti> Saviq: hmm... can't really see any difference here
[10:44] <mzanetti> MacSlow: found a bug
[10:45] <mzanetti> MacSlow: click 10 times on "add a snap-decision"
[10:45] <mzanetti> MacSlow: click 10 times on "remove f1st"
[10:45] <mzanetti> MacSlow: add some snap decisions again => they are not on top any more
[10:46] <mzanetti> MacSlow: repeat that a couple of times and notifications stop showing up at all
[10:47] <MacSlow> mzanetti, the model doesn't seem to get cleared correctly
[10:47] <sil2100> didrocks: I just dist-upgraded from it and it's ok here locally, I'll look into what's going on
[10:48] <didrocks> sil2100: it's still wrong that it's trying to install everything :/
[10:48] <MacSlow> mzanetti, using clear model seems to fix it again
[10:48] <mzanetti> MacSlow: no... that works around it
[10:48] <mzanetti> :P
[10:48] <mzanetti> MacSlow: but yes. clearing the model restores a good state
[10:49] <MacSlow> mzanetti, :)
[10:49] <MacSlow> mzanetti, first I need to get rid of warnings and get the tests to work again
[10:51] <Saviq> mzanetti, let me make a video ;d
[10:55] <Saviq> MacSlow, btw, the "delay behavior until opacity == 1" is a hack, but we don't have a good solution for such delays
[10:56] <sil2100> Ah ha
[10:56] <sil2100> didrocks: I think I found something, let me take a closer look
[10:56] <MacSlow> Saviq, I guessed
[10:56] <didrocks> ok ;)
[10:56] <pstolowski> sil2100: fyi, I hope https://code.launchpad.net/~stolowski/libunity/fix-test-timeout/+merge/165343 to fix the issue with occasional test failures
[10:58] <andrewebdev> morning all. Am in a spot of trouble here: http://askubuntu.com/questions/298881/13-04-unity-graphics-suddenly-broken-for-no-reason
[11:00] <andrewebdev> since my home folder is on a separate partition, I was wondering if it might have stored a faulty setting somewhere. where are these settings stored (if in home) and am I safe to delete the entire folder etc?
[11:06] <greyback> andrewebdev: should be able to reset compiz settings with "dconf reset -f /org/compiz/" (you might need dconf-tools package installed first)
[11:07] <sil2100> pstolowski: thanks! Will review
[11:08] <greyback> andrewebdev: handy way to check if it's a setting issue: log in as a guest user and see how things look there.
[11:08] <pstolowski> sil2100: please don't globally approve, I'd like jamesh to take a look as well;
[11:09] <pstolowski> sil2100: and can you run these tests locally?
[11:09] <Saviq> mzanetti, http://pastebin.ubuntu.com/5693352/ should work, no? or am I missing something obvious?
[11:11] <mzanetti> Saviq: can't see anything obvious. Does it print any errors?
[11:11] <Saviq> mzanetti, no, it just doesn't work
[11:12] <Saviq> mzanetti, I tried a Connection { ListView.view.add; onRunningChanged } < that fails with
[11:12] <Saviq> Cannot assign to non-existent property "onRunningChanged"
[11:12] <sil2100> uuuu
[11:13] <Saviq> mzanetti, but ListView.view.add is the Transition object alright
[11:13]  * greyback bbiab
[11:13] <andrewebdev> greyback, YES! Guest session works perfectly!
[11:13] <mzanetti> Saviq: how I read the docs, yes. But those tansitions are implemented a bit weird
[11:14] <andrewebdev> greyback, nooo wait... spoke too soon
[11:15] <andrewebdev> the moment I set up the dual monitors in the guest session, unity crashes and I lose all window decorations etc.
[11:15] <Saviq> mzanetti, obviously that's a poor-man's solution as there's nothing to say that the transition wouldn't relate to some other delegate
[11:15] <Saviq> mzanetti, so in that sense the opacity solution is better
[11:16] <mzanetti> Saviq: oh.... might be that the Notification is constructed and the implicitHeight changed _before_ it's actually hooked into the listview and the add-transition triggered on it
[11:17] <Saviq> mzanetti, well, I could actually get access to the running property in onOpacityChanged
[11:17] <Saviq> mzanetti, and it held the correct value
[11:17] <Saviq> mzanetti, but it seems there's no NOTIFY onit
[11:18] <mzanetti> Saviq: I would add a bool property to Notification like "animationsEnabled: false" and bind it in the listview
[11:18] <Saviq> mzanetti, still, that would be global, not per-delegate, which we're after
[11:18] <mzanetti> Saviq: opacityChanged is triggered by the add-transition. so most likely later
[11:19] <Saviq> mzanetti, ah you mean the binding fails?
[11:20] <Saviq> mzanetti, because the ListView.view attached prop isn't there yet? certainly was there in Component.onCompleted
[11:20] <Saviq> mzanetti, anyway, that's a slightly scientific discussion ;)
[11:20] <mzanetti> Saviq: I mean by the time the binding is evaluated its not in the listview yet and thus evaluates to true. The animation is triggered and only then the binding starts working
[11:20] <mzanetti> yes, it is
[11:20] <Saviq> mzanetti, enabled never changes
[11:20] <mzanetti> hmpf...
[11:20] <Saviq> on the behaviour
[11:21] <Saviq> anyway
[11:34] <sil2100> didrocks: ok, so it seems that Brandon's latest nux commit bumped the ABI version and he didn't bump the changelog upstream version
[11:34] <sil2100> didrocks: yesterday's commit ;/
[11:42] <tsdgeos> yay, 1 bugfix for ListView in!
[11:42] <tsdgeos> https://codereview.qt-project.org/#change,56583
[11:43] <tsdgeos> now to bother Mirv :D
[11:47] <Mirv> :D
[11:48] <sil2100> didrocks: so, we'll need to rebuild all reverse-depends of nux now
[11:48] <sil2100> didrocks: and probably get this one in: https://code.launchpad.net/~sil2100/nux/bump_version_due_to_abi/+merge/165352
[12:16] <didrocks> sil2100: ok, please take care of that :)
[12:17] <didrocks> sil2100: also keep brandon updated about it. Everything is explained in the FAQ… They should start to know it
[12:17] <didrocks> bregma: can you pass the message in your team about it ^
[12:17] <didrocks> sil2100: maybe add a message to the changelog as you are bumping it?
[12:18] <didrocks> sil2100: this is what made the installation failing?
[12:18] <sil2100> didrocks: ok, will add an entry
[12:19] <sil2100> didrocks: well, it was because components were built in wrong order, unity was built against the older nux and then nux got built, so when we're fetching the newer nux, it uninstalls unity as the abi-version mismatches
[12:19] <didrocks> sil2100: makes sense, so you need to bump the build-dep on the unity side
[12:19] <didrocks> sil2100: and then, we rebuild the stack
[12:19] <larsu> Saviq: we already have some, but we can't land them until the current (gtk) panel properly loads them (so that we don't have regressions). I'm working on that this week, hopefully it lands early next week
[12:19] <didrocks> (as per the FAQ ;))
[12:19] <sil2100> didrocks: also, we'll have to take care of one thing... as indicators are not releasing, I asked cyphermox yesterday to maybe manually release indicator-appmenu
[12:19] <sil2100> didrocks: we need the new indicator-appmenu for unity-gtk-module to work
[12:20] <didrocks> sil2100: yeah, but with jenkins shutting down yesterday… I think cyphermox will redo it today?
[12:20] <sil2100> didrocks: but neither daily-build-next nor next have the new indicator-appmenu there as well
[12:20] <sil2100> didrocks: ok
[12:21] <greyback> Saviq: mzanetti: I've pulled out the window management stuff in shell into a separate component ready for testing. I think it makes sense to rename SideStage directory to something like Stages, and move Components/Stage.qml and the new WN component in there too. Opinions?
[12:22] <greyback> it centralizes all the window management related code into one directory
[12:22] <mzanetti> greyback: +1
[12:23] <didrocks> sil2100: ping me once you have the unity branch
[12:23] <didrocks> sil2100: approved that one
[12:23] <mzanetti> greyback: do you already have information about running apps etc from Mir?
[12:24] <mmrazik> didrocks: could you have a look, please: https://code.launchpad.net/~mrazik/cupstream2distro-config/online/+merge/165355
[12:25] <didrocks> mmrazik: approved
[12:25] <mmrazik> didrocks: thanks
[12:25] <didrocks> mmrazik: I think I'll add a hook to cu2d-update-stack with a general config file in a directory
[12:25] <mmrazik> didrocks: oh..
[12:25] <didrocks> mmrazik: just to prevent deploying this directory
[12:25] <mmrazik> wait a second
[12:25] <mmrazik> didrocks: it will not land
[12:26] <didrocks> mmrazik: sent back to "needs review"
[12:26] <mmrazik> there is duplicate target_branch... forgot to remove the imdb scope from head
[12:26] <didrocks> ah ok :)
[12:30] <greyback> mzanetti: not yet, the platform api needs to be stabilized, but it should be soon
[12:30] <sil2100> didrocks: https://code.launchpad.net/~sil2100/unity/change_libnux_req/+merge/165357
[12:30] <sil2100> didrocks: but I guess CI will fail on this one due to libnux 4.0.2 not being available in the PPA, right?
[12:34] <sil2100> Lunch
[12:35] <mmrazik> didrocks: new diff finally generated: https://code.launchpad.net/~mrazik/cupstream2distro-config/online/+merge/165355
[12:37] <didrocks> sil2100: they have a local repo, so it should work, not sure it will depwait, so just tell me once the nux merge is… merged :)
[12:37] <didrocks> mmrazik: are you sure imdb won't be client side?
[12:38] <didrocks> sil2100: do you know? ^
[12:38] <sil2100> didrocks: from what David said, no...
[12:38] <sil2100> If I remember correctly
[12:39]  * sil2100 gone
[12:39] <mmrazik> didrocks: this is what davidcalle says:
[12:39] <didrocks> ok :)
 mmrazik, yes, it's being completely removed client side, it might come back online.
[12:39] <didrocks> perfect, approved! :)
[12:39] <mmrazik> thanks
[13:01] <Saviq> dandrader, huh, wrong channel ;)
[13:02] <Saviq> dandrader, there's an issue with the mouseTouch
[13:02] <Saviq> dandrader, it gets stuck when you try to swipe the dash, for example
[13:03] <dandrader> Saviq, you mean flicking horizontally to switch from dash to dash?
[13:03] <Saviq> dandrader, yes
[13:03] <Saviq> dandrader, the whole UI gets stuck (probably some mouse event does not get converted to touch)
[13:03] <Saviq> dandrader, it's only when mousetouch is enabled, of course
[13:04] <Saviq> dandrader, also I failed the review https://code.launchpad.net/~unity-team/unity/phablet.fix-run-device-mousetouch/+merge/165321
[13:05] <dandrader> ah
[13:09] <dandrader> Saviq, couldn't reproduce the issue so far? How easy is to reproduce it?
[13:09] <dandrader> s/far?/far.
[13:12] <Saviq> dandrader, 100%
[13:12] <dandrader> weird
[13:12] <Saviq> dandrader, just enable mousetouch
[13:12] <Saviq> dandrader, and release your mouse cursor when flicking
[13:13] <Saviq> so yeah, flicking, not swiping
[13:13] <Saviq> dandrader, actually
[13:13] <Saviq> dandrader, flick + click when still moving
[13:14] <Saviq> dandrader, so, grab, drag quickly & release, try and grab again
[13:14] <Saviq> dandrader, like you'd try to speed it up or reverse the movement
[13:14] <Saviq> dandrader, any Flickable, really
[13:14] <dandrader> Saviq, now I got it!
[13:15] <Saviq> dandrader, must be some event that we don't convert to touch or something
[13:15] <Saviq> greyback, +1
[13:15] <dandrader> Saviq, it got stuck into a kind endless stream of MousePress and MouseRelease
[13:15] <greyback> Saviq: cool, almost done by now anyway :)
[13:16] <Saviq> greyback, sorry, been reading backlog
[13:16] <greyback> Saviq: no worries whatsoever
[13:17] <Saviq> greyback, but that wasn't a decision you couldn't have made by yourself, was it ;D
[13:17] <greyback> Saviq: it was more a sanity check I guess
[13:18] <Saviq> greyback, you have my sanity stamp
[13:18] <greyback> but it's good to ask other people for advice, helps the old team spirit :)
[13:18] <Saviq> greyback, use it well
[13:18] <greyback> stampy stamp
[13:18] <Saviq> trump stump ;D
[13:18] <Saviq> stamp
[13:18] <Saviq> fuk
[13:18] <Saviq> ah, it's that time of the week :D
[13:18] <greyback> language:)
[13:19] <greyback> as the Czech's call it, little Friday
[13:21] <Saviq> greyback, Czech's what calls it that?
[13:22] <Saviq> greyback, at least I've an excuse, it's not my native language :P
[13:22] <greyback> yes rogue apostrophe, sue me
[13:23] <Saviq> jeez my launcher completely stopped remembering the docked items... wth?
[13:25] <greyback> it's been getting a bit funky on me too, sometimes getting stuck out, and the count on some of the icons is being drawn in strange places on screen occasionally
[13:25] <Saviq> greyback, bug #1171476
[13:25] <Saviq> greyback, supposedly fixed
[13:26] <Saviq> greyback, it was a combination of urgency and count that confused it
[13:26] <greyback> Saviq: aha, cool. Do you notice it in Alt-Tab too?
[13:27] <Saviq> greyback, nope, didn't see nothing
[13:27] <Saviq> greyback, I'm not looking much at the switcher, though
[13:27] <greyback> Saviq: ok, I'll wait for the update first tho
[13:27] <Saviq> greyback, I rarely have more than 2 windows on any workspace
[13:28] <Saviq> standup time
[13:28] <Saviq> this is mumble style
[13:30] <kgunn> is like a nerdy form of gangnam style
[13:30] <Saviq> kgunn, _not_ _at_ _all_
[13:30] <Saviq> dednick, nic-doffay standup
[13:30] <Saviq> mzanetti, ^
[13:30] <Saviq> MacSlow, ^
[13:32] <cyphermox> sil2100: didrocks: yea, I reran indicators IIRC, but I think the tests still failed. Perhaps I'll just force the publish
[13:32] <cyphermox> (after I install it here and make sure no weird things happen)
[13:32] <didrocks> cyphermox: does it fail for good or bad reason? Should we get larsu looking at it?
[13:33] <cyphermox> just a second, I can't remember
[13:33]  * larsu hides
[13:33] <didrocks> cyphermox: right now, no need to run the tests, it won't be able to install frmo the ppa as Brandon as done an ABI breakage without following the instructions
[13:34] <didrocks> so you can't install from it
[13:34] <cyphermox> I pin packages, no worries
[13:34] <didrocks> cyphermox: hum, in the -check tests?
[13:34] <cyphermox> also, indicators are in ~daily-build, not -next
[13:34] <cyphermox> well, no, not in the -check tests
[13:34] <cyphermox> I see what you mean now
[13:34] <didrocks> cyphermox: ah, they are in daily-build
[13:35] <didrocks> so should be fine :)
[13:36] <cyphermox> yea
[13:36] <cyphermox> http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/466/label=autopilot-ati/console
[13:36] <cyphermox> ^ fun :)
[13:37] <didrocks> mmrazik: is there a queue for nux? https://code.launchpad.net/~sil2100/nux/bump_version_due_to_abi/+merge/165352 the CI took 10 minutes, but for merging, we are waiting for a long time
[13:37] <didrocks> cyphermox: please see with the indicator team, we don't want to publish manually forever ;)
[13:38] <cyphermox> didrocks: no queue for nux that I can see, fyi
[13:38] <cyphermox> it's just not finished yet
[13:39] <cyphermox> didrocks: yeah
[13:39] <didrocks> thanks!
[13:41] <didrocks> sil2100: now that everything's merged, I'm rebuilding nux and unity in the unity stack
[13:48] <bregma> didrocks, sil2100 please do not bump the upstream version part of Ubuntu packages to be ahead of the upstream version, it breaks things outside of Ubuntu
[13:49] <didrocks> bregma: we did bump the upstream version as well
[13:49] <didrocks> bregma: see the MP
[13:50] <bregma> messing with upstream without the correct workflow isn't any better
[13:51] <didrocks> bregma: upstream not following the workflow isn't correct either
[13:51] <bregma> two wrongs do not make a right
[13:51] <didrocks> bregma: and breaking for a day the PPA isn't acceptable
[13:51] <didrocks> bregma: the other answer was to revert?
[13:52] <Saviq> MacSlow, btw, we should transition to https://code.launchpad.net/~fboucault/ubuntu-ui-toolkit/standard_animations/+merge/163205 soon
[13:52] <Saviq> MacSlow, from your custom timings.js
[13:52] <didrocks> bregma: we built a procedure for ABI break: https://wiki.ubuntu.com/DailyRelease/FAQ
[13:52] <didrocks> bregma: we followed it
[13:52] <didrocks> bregma: avoiding to revert
[13:52] <didrocks> bregma: you broke all the testing for a whole day in the ppa
[13:52] <MacSlow> Saviq, yeah... that would be sweet... hate that timings.js
[13:53] <didrocks> bregma: so next time, we'll just revert if you prefer that than us fixing things (and following the procedure)
[13:53] <Saviq> MacSlow, it should already be available
[13:53] <Saviq> MacSlow, from ppa:ubuntu-sdk-team
[13:53] <MacSlow> Saviq, ah... I think I'm not pulling from that PPA yet... let me check...
[13:54] <Saviq> MacSlow, you probably do, otherwise you wouldn't have been able to run shell for some time now
[13:54] <Saviq> MacSlow, due to Panel being introduced post-raring
[13:54] <MacSlow> Saviq, I'll update my MR then
[14:18] <tsdgeos> Mirv: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1183350
[14:21] <MacSlow> tsdgeos, mzanetti: is there something new needed in tests to work with the latest Qt 5.x from our PPA?
[14:21] <MacSlow> tsdgeos, mzanetti: all of a sudden I'm getting "Cannot read property 'children' of undefined" for all my tests
[14:22] <MacSlow> tsdgeos, mzanetti: I remember something about "forceLayout" being menntioned yesterday
[14:23] <tsdgeos> MacSlow: that or more waitForRendering
[14:23] <tsdgeos> MacSlow: didn't Saviq fix them all though?
[14:23] <tsdgeos> or is it new tests?
[14:23] <Saviq> MacSlow, merge trunk
[14:23] <Saviq> MacSlow, https://code.launchpad.net/~saviq/unity/phablet.fix-listview-tests/+merge/165051
[14:24] <MacSlow> Saviq, ah... ok thx
[14:25] <MacSlow> Saviq, got rid of timings.js and switched to UbuntuAnimation
[14:27] <Saviq> MacSlow, cheers
[14:27] <mzanetti> huh? UbuntuAnimation?
[14:28] <mzanetti> is that to be used everywhere?
[14:28] <MacSlow> Saviq, mzanetti: sure... see here :) https://code.launchpad.net/~macslow/unity/phablet-snap-decision-action-expansion/+merge/165370
[14:28] <Saviq> mzanetti, yes, it's the "standard" animation and timings
[14:28] <MacSlow> mzanetti, it's like brand... but for animations :)
[14:29]  * mzanetti whishes such information would be spread through mailing lists
[14:29]  * mzanetti hopes he didn't miss the mail :D
[14:36]  * mzanetti can't work any more because he just scrolls the launcher up and down to watch the folding effect
[14:38] <paulliu> Saviq: https://code.launchpad.net/~paulliu/unity/i18n/+merge/165160
[14:38] <Saviq> paulliu, cheers
[14:55] <tsdgeos> paulliu: Saviq: no msgmerge ?
[14:56] <Saviq> tsdgeos, Gettext is doing that
[14:56] <tsdgeos> Saviq: where?
[14:56] <Saviq> tsdgeos, 255	+GETTEXT_CREATE_TRANSLATIONS(${POT_FILE} ALL ${PO_FILES})
[14:56] <tsdgeos> that's msgfmt, no?
[14:57] <Saviq> tsdgeos, right
[14:57] <tsdgeos> ah no it does msgmerge too
[14:57] <tsdgeos> not sure exactly what it does
[14:57] <tsdgeos> but it has a msgmerge call :D
[14:58] <Saviq> http://cmake.org/gitweb?p=cmake.git;a=blob_plain;f=Modules/FindGettext.cmake;hb=HEAD
[14:58] <Saviq> tsdgeos, yeah
[14:58] <tsdgeos> ok, then :)
[14:59] <Saviq> tsdgeos, I meant "yeah, not sure exactly what it does" ;)
[15:00] <tsdgeos> well, without running it, seems to be doing the correct thing
[15:00] <tsdgeos> i.e. update the .po with the .pot
[15:01] <Saviq> tsdgeos, yeah, and also install to the correct spot
[15:01] <tsdgeos> yeah that the next one :)
[15:01] <tsdgeos> meant the msgmerge line specifically
[15:02] <paulliu> tsdgeos: yeah, I can add a target for that.
[15:03] <tsdgeos> paulliu: the cmake docu says it creates a target already
[15:03] <tsdgeos> "translations"
[15:03] <tsdgeos> not sure if it's working
[15:04] <paulliu> tsdgeos: seems to me that it only do "po -> gmo".. installation works anyway.
[15:13] <tsdgeos> ah
[15:16] <dednick> "phablet-flash -b" = bad idea
[15:17] <dednick> "--bad-idea" in fact
[15:17] <tsdgeos> :D
[15:22] <kgunn> mzanetti: Saviq nic-doffay mterry wrt blur stuff for locked screen
[15:23] <kgunn> i thot folks were very anti-blur
[15:23] <kgunn> (not me)
[15:23] <kgunn> but for perf reasons....there was to be some
[15:23] <nic-doffay> kgunn, no clue. Haven't anything about this.
[15:23] <Saviq> kgunn, yeah, but that's about live blurring, a single-frame blur should be fine
[15:23] <kgunn> other means to an end besides blur per se
[15:24] <kgunn> Saviq: i totally agree
[15:24] <kgunn> was just trying to see if there was some other concern someone had
[15:25] <Saviq> kgunn, mostly performance, a bit of security - when the blur would not be strong enough to allow un-blurring
[15:25] <kgunn> Saviq: granted it won't be "live" but will be "on the fly" right ? due to design
[15:25] <Saviq> kgunn, not necessarily, it can be cached when the app was last stopped
[15:25] <kgunn> e.g. i clicked on FB icon, under the hood takes a screenshot of app, then blurs with pin lock
[15:25] <Saviq> kgunn, what if app isn't running?
[15:25] <kgunn> so you're going to snapshot every runnning app ?
[15:26] <Saviq> kgunn, yes, at least when it's stopped
[15:26] <mzanetti> kgunn: Yes, the architect is very anti-blur, Design is very pro-blur...
[15:26] <kgunn> Saviq: i see...yeah, you kind of have to...snapshot every app upon loss of focus
[15:26] <mzanetti> Saviq: we can't rely on the snapshot
[15:26] <Saviq> kgunn, yup
[15:27] <Saviq> mzanetti, hm?
[15:27] <mzanetti> Saviq: that works sometimes, but not always and for thus a blur effect would need to be performant enough for live blur
[15:27] <Saviq> mzanetti, sure, it should be performant enough, not that we'll use it live :)
[15:27] <Saviq> mzanetti, at least not for the PIN entry case
[15:28] <mzanetti> Saviq: yes...
[15:28] <mzanetti> Saviq: because our phone is so full of animations
[15:28] <mzanetti> Saviq: swipe aside the greeter. the zoom effect would require a live-blur
[15:28] <kgunn> Saviq: mzanetti ...one odd case, what if app has never been launched
[15:28] <mzanetti> kgunn: exactly
[15:28] <mzanetti> that would have been my next example
[15:29] <Saviq> mzanetti, kgunn, splash screen
[15:29] <mzanetti> Saviq: use the launcher on the greeter to launch an app.
[15:29] <mzanetti> Saviq: design wants to see the app blurred
[15:29] <mzanetti> Saviq: the app changes during startup, I have no way of knowing when it stops => live-blur
[15:29] <mzanetti> required
[15:30] <mzanetti> that screenshot hack is a nice idea but really does not work out in our case
[15:30] <Saviq> mzanetti, ok then, make live-blur performant enough to work on the Nexus 10 and we'll be good ;)
[15:30] <Saviq> mzanetti, I'm just afraid we have to cut the corners, that's just too many pixels
[15:30] <mzanetti> Saviq: I've been saying since day 1 it wont work. but our openGL experts tell me it will be performant enough
[15:31] <mzanetti> Saviq: thats why I'm waiting for them to give me a blur effect that does the thing
[15:31] <Saviq> mzanetti, right ;)
[15:31] <Saviq> mzanetti, I was under the impression we're not doing live blur, but if we are - great ;)
[15:32] <kgunn> plus nic-doffay just wants to do some cool shader code :)
[15:32] <mzanetti> Saviq: well, we can do some screenshot hacks. but after playing around for a day with the whole thing I know the screenshot and the actual state would drift that much that its going to look bad
[15:33] <mzanetti> Saviq, kgunn: what I could think of: some combination of screenshots that are updated twice a second with a crossfade or something like that
[15:33] <mzanetti> I will experiment with that once I have a good blur algorithm and can get screenshots via Mir
[15:34] <Saviq> mzanetti, that's still screenshotting, not live blur :P
[15:34] <mzanetti> Saviq: sure
[15:34] <Saviq> mzanetti, I never meant to say "just a single screenshot, never updated"
[15:34] <kgunn> mzanetti: it's like slow mo live :)
[15:34] <Saviq> mzanetti, just I don't see us getting 60fps ;)
[15:35] <mzanetti> but it would need additional tricks like crossfading to make fool peoples eye enough to not know the difference
[15:35] <mzanetti> anyways... once I know what I can expect performance wise I can tell more
[15:36] <Saviq> yup
[15:36] <mzanetti> and I really need to learn some opengl stuff... having some code I don't understand drives me crazy :D
[15:52] <mzanetti> pete-woods, mterry: hey. do I have some possiblity to know when the pinlock schould be shown and when it shouldn?
[15:52] <mzanetti> also do we already have some place I can read the PIN from?
[15:53] <sil2100> cyphermox: hi
[15:53] <cyphermox> sil2100: yo
[15:53] <sil2100> cyphermox: did you try building/publishing indicator-appmenu in the end?
[15:54] <sil2100> bregma: regarding the libnux dependency bump - we changed the libnux version to 4.0.2, as every ABI break requires an upstream version bump
[15:55] <cyphermox> sil2100: I was just finishing up testing it
[15:55] <cyphermox> it can be published
[15:55] <sil2100> \o/
[15:55] <sil2100> Excellent
[15:55] <cyphermox> oh wait
[15:55] <cyphermox> right, was moving unity-gtk-module to indicators to go along with that
[15:56] <sil2100> Oh, so moving out of the unity stack? Well, that would help indeed
[15:57] <sil2100> cyphermox: once you move it to indicators, could you also approve/review this? https://code.launchpad.net/~sil2100/unity-gtk-module/conflicts_appmenu/+merge/165175
[15:57] <cyphermox> ai
[15:58] <sil2100> cyphermox: the short story is - u-g-m will replace appmenu-gtk, and when appmenu-gtk is in the system, u-g-m cannot be used
[16:00] <sil2100> cyphermox: so, you're doing the move right now?
[16:00] <sil2100> cyphermox: I mean, move from unity stack to indicators?
[16:00] <sil2100> cyphermox: since there seems to be an error in the unity stack config related to u-g-m and I'm not sure if I would fix it now or just wait for you to move ;)
[16:01] <cyphermox> yes, I'm about to send the merge request
[16:01] <didrocks> sil2100: hud tests has still one failure
[16:01] <didrocks> sil2100: with latest unity
[16:01] <sil2100> didrocks: let me see, but it's probably the regression I was saying about, let me fill a bug
[16:02] <didrocks> sil2100: ok, should we put the threshold up or not? ;)
[16:02] <didrocks> (ati is archiving the artefacts, give it some time)
[16:02] <didrocks> yeah, same on ati
[16:03] <sil2100> didrocks: yes ;) I think we already poked jibel about that in the morning, right? To 1 failure
[16:03] <sil2100> Ah
[16:03] <sil2100> So on both now?
[16:03] <didrocks> ati and intel got result, one regression
[16:03] <didrocks> oh yeah
[16:03] <didrocks> the treshold had change (or was it me? I don't remember) :)
[16:03] <didrocks> so published
[16:04] <didrocks> sil2100: note to poke about it :)
[16:04] <sil2100> jibel you mean? ;)
[16:04] <didrocks> sil2100: upstream :p
[16:04] <sil2100> Ah, ok, yes yes ;)
[16:04] <didrocks> ok, QA is rerunning now
[16:04] <sil2100> \o/
[16:04] <didrocks> should be easy
[16:04] <didrocks> as unity mismatch is fixed
[16:04] <didrocks> sil2100: latest attempt for unity failed though in the preseed
[16:04] <sil2100> didrocks: I saw unity failed... you aborted one machine and the other had problems, but I see the config is broken ;)
[16:04] <didrocks> sil2100: I'll retry again…
[16:04] <sil2100> didrocks: wait wait
[16:05] <didrocks> sil2100: hum, not sure it's due to the config TBH
[16:05] <sil2100> didrocks: since I noticed a mistake in the config
[16:05] <didrocks> but yeah, better to fix it
[16:05] <sil2100> didrocks: see line tests: unity unity-gtk-module unity-gtk-module-common libunity-gtk3-parser0
[16:05] <sil2100> This should be:
[16:05] <didrocks> yeah yeah, I talked about it with Mathieu :)
[16:05] <sil2100> tests: unity unity-gtk-module
[16:05] <sil2100> But I think he's moving it to indicators now
[16:05] <didrocks> and about moving unity-gtk-module to indicators
[16:05] <didrocks> yep
[16:05] <didrocks> makes more sense I guess?
[16:05] <cyphermox> ugh
[16:06] <cyphermox> yeah, that's what was missing
[16:06] <sil2100> didrocks: this would solve also my problems with it removing appmenu-gtk in the unity stack \o/
[16:06] <didrocks> sil2100: excellent!
[16:07] <dandrader> Saviq, on the MouseTouchAdator: fixed it. The solution is to filter native, xbc, events instead of Qt ones. in order to avoid converting mouse events generated by Qt::AA_SynthesizeMouseForUnhandledTouchEvents
[16:07] <cyphermox> didrocks: sil2100: https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/move-u-g-m-to-indicators/
[16:10] <sil2100> cyphermox: looking good, MP it!
[16:12] <didrocks> cyphermox: yeah, that's fine, once you make the switch, maybe remove the job to the unity head stack? (the unity-gtk-module one)
[16:12] <cyphermox> yeah
[16:12] <cyphermox> https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/move-u-g-m-to-indicators/+merge/165430
[16:13] <sil2100> cyphermox: approved
[16:13] <Saviq> dandrader|lunch, sounds good
[16:14] <cyphermox> ok, I removed the job
[16:17] <cyphermox> and I'll update the indicators jobs now
[16:18] <sil2100> cyphermox: thanks!
[16:24] <cyphermox> and shortly I'll be able a
[16:24] <cyphermox> to start indicators...
[16:25] <cyphermox> and then, forage for safe food in Montreal today :/
[16:28] <didrocks> sil2100: cyphermox: let's publish manually the QA stack: the tests passed on one, but the provisionning failed on the other
[16:28] <didrocks> cyphermox: want to manually publish to test the token? :)
[16:28] <cyphermox> yeah, as soon as it's merged
[16:28] <cyphermox> oh
[16:28] <cyphermox> QA, sure
[16:28] <sil2100> I'm all in
[16:28] <didrocks> let's see if it's working :)
[16:29] <cyphermox> err
[16:29] <cyphermox> already published
[16:29] <didrocks> cyphermox: interesting… in fact, it worked on the second as well
[16:29] <didrocks> despite the UTAH error message :p
[16:29] <cyphermox> right
[16:30] <cyphermox> well i'll be able to test with indicators
[16:30] <didrocks> you will need to find another target to test the token!
[16:30] <didrocks> yep :)
[16:31] <sil2100> cyphermox, didrocks: since the merge got into the config, could you guys also redeploy the unity stack?
[16:31] <sil2100> I think we can re-run it now as well
[16:31] <didrocks> need to stop the unity stack first
[16:32] <didrocks> sil2100: you can do it, as we'll rerun it and the check was stopped
[16:32] <didrocks> (stopping unity)
[16:32] <sil2100> Stopped
[16:33] <didrocks> beautiful stop :)
[16:34] <didrocks> let's wait for cyphermox to redeploy and rerun indicators, and unity (with "foo" for unity :p)
[16:34] <didrocks> if they both pass, every would have published today!
[16:35] <sil2100> ;)
[16:35] <sil2100> \o/
[16:37] <cyphermox> shouldn't be too long, updating the jobs now.
[16:42] <cyphermox> jenkins.JenkinsException: Error in request. Possibly authentication failed [403]
[16:42] <cyphermox> ok, got it with no token...
[16:44] <didrocks> cyphermox: indicators is launched though?
[16:44] <cyphermox> yup
[16:44] <cyphermox> that's what I mean
[16:44] <didrocks> but you get the exception?
[16:44] <cyphermox> with the option checked but no token entered, it psses
[16:44] <cyphermox> no
[16:44] <cyphermox> with the token there as it current is configured, I get the error
[16:44] <didrocks> waow :/
[16:45] <didrocks> so with the correct token
[16:45] <cyphermox> which is pretty much expected given that it's not the token we actually pass
[16:45] <didrocks> it fails
[16:45] <didrocks> hum? you are passing the correct token, no?
[16:45] <cyphermox> with the correct token, it should pass as well
[16:45] <didrocks> ah, better to have one token, and the correct one :)
[16:46] <didrocks> at least, it ensure the check is on, which isn't the case if you don't specify a token in the template
[16:46] <cyphermox> right
[16:46] <cyphermox> so, confirmed
[16:46] <cyphermox> we should make the token match
[16:46] <cyphermox> with... the new token you want to put in?
[16:46] <didrocks> well, they do match now, right? in -config trunk?
[16:47] <didrocks> publish and head have the same, which was the old one
[16:47] <cyphermox> didrocks: no, the token in master-template and publish aren't the same
[16:47] <cyphermox> I can make it the same (the old one) now
[16:48] <didrocks> cyphermox: are you sure? I grepped again, and in trunk from -config, it's the same
[16:48] <cyphermox> I'm positive
[16:49] <cyphermox> the token in daily-release/jenkins-templates/master-config.xml is the one I hacked together when I initially debugged the issue
[16:49] <cyphermox> I can sync it with the old one now
[16:49] <didrocks> argh
[16:49] <didrocks> gree
[16:49] <didrocks> I didn't commit
[16:49]  * didrocks was getting crazy
[16:49] <didrocks> cyphermox: yes, please do, sync to the old one :)
[16:50] <didrocks> cyphermox: have you deployed unity already?
[16:51] <cyphermox> no, doing it now
[16:59] <cyphermox> brb, lunch
[17:00] <didrocks> bon app!
[17:07]  * greyback eod, see you Monday
[17:13] <mterry> mzanetti, when the prompt string is "PIN"
[17:15] <sil2100> cyphermox: unity redeployed? ;)
[17:17] <mzanetti> mterry: I'm not really sure what is there in lightdm already and what isn't. Is there already some bool or something that lets me decide if the lockscreen should be shown at all?
[17:19] <mterry> mzanetti, if you get a showPrompt signal, with the "PIN" string as the prompt string, show it.  But I understand if the current LoginList code doesn't make it clear where to handle it.  I don't think it handles the showPrompt signal at all right now
[17:20] <mterry> mzanetti, I have a branch coming in a few days that will add various login cases that expands the logic, will make it more clear
[17:20] <mterry> mzanetti, or, just always show the pin on a prompt situation and I can clean up for the "PIN" case specificially later...
[17:20] <mterry> mzanetti, oh!
[17:20] <mterry> mzanetti, but LoginList won't even be relevant, because we're not in tablet mode
[17:21] <mterry> mzanetti, so you might need some new logic for this case, indeed
[17:21] <mzanetti> mterry: is the greeter then launched on that signal? and is that the same signal that handles the display dim timeout for example?
[17:21] <mterry> mzanetti, no.  So what happens is, the launcher starts up.  (1) we try to log the user in via PAM
[17:22] <mterry> mzanetti, (2) if successful, we wait for swipe to finish login
[17:22] <mterry> mzanetti, (3) if not, PAM will prompt us.  If the prompt string is PIN, we know that upon a swipe, we need to show pin screen
[17:22] <mterry> mzanetti, (4) else if not PIN, we know we'll need to show keyboard screen
[17:23] <mzanetti> mterry: hmm. what happens while the greeter is half-swiped?
[17:23] <mterry> mzanetti, it's a little hard to see that from the current code in Greeter/, because it doesn't handle all those cases yet
[17:23] <mzanetti> mterry: I guess the signal will only come onces the swipe is complete
[17:23] <mterry> mzanetti, no.  We have the prompt before the swipe starts
[17:23] <mterry> mzanetti, as soon as greeter starts up, we try to login whatever user is selected
[17:23] <mterry> mzanetti, in phone case, that will be trivia;
[17:23] <mterry> trivial
[17:24] <mterry> mzanetti, and we shortly get the prompt string.  Then we have as long as we want to give response to prompt to PAM
[17:24] <mterry> mzanetti, so we wait for swipe, show pin screen beneath, etc
[17:24] <mzanetti> mterry: ok... got it.
[17:25] <mterry> mzanetti, I've got a couple branches that will make it more obvious how to test odd greeter cases
[17:25] <mterry> mzanetti, it's a little awkward right now
[17:25] <mterry> mzanetti, basically, it will make it easier to create multiple fake liblightdms
[17:26] <mterry> mzanetti, so you can create a mock user that prompts for PIN
[17:26] <mzanetti> mterry: ah, I see. sounds great. Thanks!
[17:26] <mterry> mzanetti, I'll point you at them as I post them
[17:26] <mterry> mzanetti, hope to have one today
[17:27] <mzanetti> mterry: awesome. I'm EODing now anyways
[17:27] <mterry> mzanetti, enjoy!
[17:27] <mzanetti> mterry: I'll start with hooking up to that signal tomorrow and emit it somehow. then when you come online we can fix it properly.
[17:27] <mzanetti> thanks again. helps a lot!
[17:29] <mzanetti> mterry: oh... and after everything is unlocked and the user presses the power button to lock again. will I get that signal again?
[17:30] <mterry> mzanetti, yeah
[17:30] <mterry> mzanetti, whole process again
[17:31] <mzanetti> mterry: ok. perfect. see you tomorrow
[17:41] <bschaefer> sil2100, hey, sorry about not updating the upstream version in nux....
[17:42]  * bschaefer thought bumping the ABI version along with bumping unitys debian/control was all that was required...
[17:42] <sil2100> bschaefer: no problem, we sorted it out finally anyway, I saw you bump the version, but only the downstream one
[17:42] <sil2100> bschaefer: this usually breaks things as the daily-build versioning is a bit confusing ;D
[17:42] <bschaefer> sil2100, right, yeah, I am now aware that I have to bump upstream...
[17:43] <sil2100> bschaefer: no problem, I also many times miss things that Didier wrote in the DailyRelease documentation, since there's so much info there actually
[17:44] <bschaefer> sil2100, thanks for sorting it out though, next time ill be sure to let someone know im breaking the ABI next time :)
[18:36] <cyphermox> sil2100: no, tests are running
[18:40] <sil2100> cyphermox: one batch of unity tests finished, I see a lot of failures
[18:40] <sil2100> 25
[18:44] <sil2100> cyphermox: not sure if we should publish manually at this level of failures
[18:44] <sil2100> But let's wait for intel to finish
[18:47] <sil2100> cyphermox: hm, some of those seem like AP failures to me
[18:49] <sil2100> cyphermox: some tests fail as they're not prepared properly for 100scopes
[18:53] <sil2100> cyphermox: ok, I need to jump out now - not sure if we should publish this or not, I'll send an e-mail to the unity guys to take a look
[18:57] <cyphermox> I'll look into it..
[18:57] <sil2100> See you!
[19:02] <kgunn> dandrader: ping
[19:02] <dandrader> kgunn, pong