[00:01] <alecu> robru: I see that the silo12 where ralsina was building unity-scope-click is stuck: Can't merge: One package at least is not available at the destination. unity-scope-click (0.1+14.04.20140220.1-0ubuntu1) is in the proposed pocket.
[00:02] <robru> alecu, yes, that package is stuck in -proposed due to a failed autopkgtest.
[00:03] <alecu> robru: where can I get more info on that failure? Is there any way I can help move it forward?
[00:03] <robru> alecu, https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-unity-scope-click/ARCH=amd64,label=adt/28/console i don't know if you're able to resolve that. i don't know anything about that package or it's tests
[00:03] <alecu> great
[00:03] <robru> alecu, you'd normally find that log by visiting http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and searching for the package name.
[00:04] <robru> alecu, if you can submit an MP that fixes that crash, I can add it to the landing, rebuild it, then you can re-test it, then we can re-publish it, and hopefully then it'll pass -proposed and make it to distro.
[00:06] <mandel> robru, mmcc has a branch that fixes it
[00:06] <robru> mandel, oh, do you have a link?
[00:07] <mandel> robru, I've asked for the MP to review, yes
[00:07] <mandel> robru, give us a few mins
[00:07] <robru> mandel, ok
[00:07] <robru> mandel, alecu: also it's technically ralsina's job to take the new MP and put it in the list, but if he's not around then i can do it too.
[00:08] <mandel> robru, he is not, left a while back
[00:08] <robru> mandel, ok no worries
[00:08] <alecu> robru: that will help us greatly, since he's currently on a plane
[00:09] <alecu> robru: thanks a lot
[00:09] <robru> you're welcome
[00:30] <mandel> robru, as soon as we have the +1 from alecu  we can use https://code.launchpad.net/~mikemc/unity-scope-click/fix-udm-abi-breakage/+merge/207578
[00:30] <robru> ok, alecu ping me when you're satisfied
[00:31] <alecu> robru: +1 to that branch, let's land it on the silo and test it
[00:31] <robru> ok
[00:34] <mandel> alecu, silo num?
[00:34] <alecu> mandel: 12
[00:34] <mandel> ack
[00:35] <robru> alecu, mandel, mmcc: just started building, you can watch the log here: http://162.213.34.102/job/landing-012-1-build/14/console
[00:36] <robru> once that gets to the end you can start testin
[00:39] <alecu> yay!
[00:39] <alecu> I'll test it after dinner
[00:39] <alecu> mandel: you can go get some sleep
[00:39] <mandel> alecu, I want to stay at least until it builds :)
[00:39] <alecu> robru: thanks for working on this
[00:40] <alecu> mandel: I know it builds, because I tested the same steps locally, and both mmcc and you have also
[00:40] <mandel> robru, yes, thx!!! I'm really sorry for forgetting about ABI compatibility :-/
[00:40] <mandel> alecu, nevertheless..
[00:40] <robru> alecu, you're welcome! I'm not even EOD yet... this is why I'm here!
[00:40] <alecu> mandel: and I even got the exact same errors without this fix, so I'm pretty confident it works
[00:41] <mandel> alecu, yes, the errors are clear == ABI because adding virtual methods screws it..
[00:41] <mandel> alecu, worst thing, I have read this http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ several times :-/
[00:41] <mandel> alecu, I was very very very stupid
[00:42] <alecu> mandel: is there a lint tool that can help with these mistakes?
[00:42] <alecu> mandel: if not, food for thought
[00:42] <mandel> alecu, no that I'm aware off.. but you have a point, it would be nice to get a tool that those a diff, checks for changes in headers and screams at you
[00:43] <robru> surely that must exist? you guys can be the first people to steward an ABI.
[00:43] <robru> can't
[00:44] <mandel> robru, we are not, unity has done it a couple of times..
[00:44] <mandel> alecu, robru http://ispras.linuxbase.org/index.php/ABI_compliance_checker
[00:45] <mandel> not ideal.. but is a start
[00:47] <alecu> mandel: why not ideal? it sounds *just* like the thing to avoid these issues
[00:48] <alecu> mandel: it's even been developed for quite some time, and it's also fresh: "last modified on 23 January 2014"
[00:48] <mandel> alecu, I just don't like the xml and I'd like it to be a bzr hook :)
[00:48] <mandel> alecu, but it is a start :)
[00:49] <alecu> mandel: it would have caught this exact issue: "added/removed virtual functions (change of a v-table layout)"
[00:49] <mandel> alecu, yes, it would have, I knew.. so I should have not propose the merge..
[00:50] <mandel> alecu, I'm going to see if it is packaged, if not, do it and later add an automated check in make check
[00:50] <alecu> mandel: so, a bzr hook sounds right. Also, the xml would be generated by the hook, not by you.
[00:50] <mandel> alecu, one should be added as the supported one or something, right?
[00:50] <mandel> alecu, or.. bzr hook and always generate the one from the previous branch
[00:51] <mandel> revno sorry
[00:59] <alecu> mandel: either a bzr hook, or something that gets run by jenkins
[00:59] <mandel> alecu, jenkins is a better approach
[00:59] <mandel> alecu, since it will work for projects that do not use bzr
[00:59] <alecu> mandel: which checks the current version, and the previous version. And that fails if the package major version is not increased
[01:00] <mandel> alecu, or deb packaged updated
[01:00] <mandel> alecu, and talking about that, the getAll methods will have the same issue, I'll have to do an update break thing for that
[01:01] <alecu> mandel: right. Let's do it at some safe point next week
[01:01] <mandel> alecu, exactly, if it not yet needed, lets not do it this week, is risky
[01:01] <alecu> mandel: we need that for a bug that's not critical, so next week is fine
[01:02] <mandel> alecu, yep, I chat with this with mmcc and he mentioned too that is not urgent, the branch is there so it is a matter of deployment
[01:02] <mandel> alecu, the easiest, use the same silo for both projects and fix the deb control file to state a break
[01:03]  * mandel needs to read what exactly has to be written there
[01:03] <alecu> mandel: both in the same silo sounds good
[01:04] <alecu> mandel: what about other packages that depend on this client library? system-updates, perhaps?
[01:04] <mandel> alecu, guarantees that abi will be ok at least for the scope, who is the only known client...
[01:04] <alecu> ah, great
[01:04] <mandel> alecu, system-updates uses python, so it goes bia dbus
[01:04] <mandel> via*
[01:05] <sergiusens> fginther, hey any help here? Build timed out (after 60 minutes). Marking the build as failed.
[01:05] <sergiusens> fginther, https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/2971/console
[01:06] <sergiusens> fginther, but it just dies during env setup it seems
[01:08] <sergiusens> or robru ^^
[01:09] <sergiusens> anyone who knows someone is good :-)
[01:09] <robru> that's fginther territory, sorry
[01:09] <sergiusens> I'd just skip otto :-/
[01:12] <sergiusens> robru, is fginther the only one that knows otto?
[01:14] <robru> sergiusens, probably not, but i don't know of anybody else.
[01:14] <robru> sergiusens, i guess you're supposed to ping cihelp for that
[01:18] <mandel> alecu, robru is the build supposed to take this long?
[01:18] <robru> mandel, it says it's done to me?
[01:18] <alecu> mandel: it is, yes
[01:19] <alecu> mandel: it just finished!
[01:19] <mandel> alecu, robru yeah, I just mentioned and finished... had I known that I would have said it earlier
[01:19] <sergiusens> robru, well no need to hurry as if I land this; I'd still need cihelp to change the test runners :-/
[01:19] <robru> 40 minutes seems normal to me. certain projects take way longer though
[01:19] <mandel> alecu, cwayne can also test it for you
[01:20]  * sergiusens is just randomly ranting
[01:20] <mandel> robru, I suppose, is 2:20 am here, so I was anxious
[01:20] <mandel> sergiusens, quejica!
[01:21] <sergiusens> mandel, me tiene las pelotas llenas! antes tenia mas poder ;-)
[01:21] <mandel> sergiusens, lol
[01:27] <sergiusens> robru, left a comment in the train sheet; hopefully everything can go in in the AM
[01:27] <robru> sergiusens, ok
[01:28] <sergiusens> thanks!
[01:29] <robru> mandel, mmcc alecu: how's silo 12 going? ready to publish that yet?
[01:32] <cyphermox> robru: omg
[01:32] <robru> ?
[01:32] <cyphermox> gonna kick an image before autopilot lands :)
[01:32] <robru> oh, good idea.
[01:32] <robru> ;-)
[01:33] <cyphermox> hehe
[01:33] <mandel> robru, I'm calling it a night (2:30 am) but alecu can give you the green light
[01:33] <robru> mandel, ok thanks
[01:33] <mandel> robru, cwayne in #ferret is also testing it
[01:33] <robru> cyphermox, surely they wouldn't have marked it tested if it wasn't flawless, right?
[01:35] <alecu> I'm reflashing the phone; it will take at least 20 more minutes, and will install the ppa afterwards.
[01:35] <alecu> I'll wait while having dinner
[02:47] <robru> alecu, any word on those tests?
[02:49] <alecu> robru: I just finished installing, will start testing right now
[02:49] <robru> ok
[02:49] <alecu> robru: cwayne has been testing it
[02:49] <robru> I'm past EOD but I'm waiting around just to publish this, then I need to run out
[02:50] <cwayne> right, so it fixes the issue of the scope not loading at all, which is good, but installing apps seems to have some issues
[02:50] <alecu> robru: and this solves the empty scope for him, but the install is not working all of the times
[02:50] <robru> hmmm
[02:50] <cwayne> namely, sometimes installing apps causes unity to crash
[02:50] <cwayne> so overall, it is definitely an improvement over no scope at all :)
[02:50] <robru> cwayne, is that a regression or has it always been like htat?
[02:50] <robru> ah
[02:50] <cwayne> robru, i don't know, because the first version with these installation bits in it wouldn't load at all
[02:50] <robru> just wondering what your acceptance criteria for publishing this is
[02:50] <cwayne> so this is the first i've been able to test
[02:55] <cwayne> i'd be inclined to say this is 100% an improvement over what's in universe right now :)
[02:57] <robru> cwayne, alecu : ok, so I'll publish it with the understanding that fixes are coming?
[02:58] <alecu> I'm unable to add the ppa and install from there, so I manually installed the .deb from the ppa.
[02:58] <alecu> the scope crashes after trying to install something here
[02:58] <alecu> and unity8 sometimes dies too
[02:59] <robru> alecu, so ... i shouldn't publish it? mixed signals ;-)
[02:59] <alecu> robru: I don't like the state, but I agree with cwayne that it's better than not being able to start any app
[03:00] <robru> alecu, ok so i'm publishing then ;-)
[03:00] <alecu> robru: great, thanks
[03:00] <alecu> also, thanks for staying past your EOD for this
[03:01] <robru> alecu, no worries.
[03:01] <robru> alecu, cwayne : ok it's published now.
[03:01] <cwayne> robru, thanks
[03:02] <robru> alecu, I gotta run out and take care of some stuff, but I'll be back in 2-3 hours. if it turns out that you submit a new MP I can assign a new silo for you. After that it has to wait for EU morning, which is ~4 hours from now
[03:03] <robru> cwayne, alecu : you're welcome!
[03:03] <alecu> robru: don't worry: it's 12am here, so I'll just write a mail so somebody on my team on EU morning time can start working on it
[03:04] <robru> ok
[03:05] <robru> ciao!
[03:05]  * cyphermox signs off too
[04:09] <cwayne> and now to wait til it reaches trusty, so that i can kick a build and go to bed...
[04:10] <rsalveti> cwayne: what are you still waiting to land?
[04:11] <cwayne> unity-scope-click
[04:12] <rsalveti> right
[04:13] <cwayne> yeah, its in -proposed now, took awhile last time, for trying to build on arm64 i think
[04:18] <rsalveti> yeah, before FF
[04:18] <rsalveti> we usually get tons of uploads
[04:19] <cwayne> ah, yeah
[04:19] <cwayne> makes sense
[04:19] <cwayne> damn
[04:23] <cwayne> rsalveti, is there an easy way to see where it is in the queue
[04:23] <rsalveti> cwayne: rmadison unity-scope-click
[04:24] <rsalveti> cwayne: that usually tells you if it is already published in our main infra
[04:24] <cwayne> right, that shows its in -proposed
[04:28] <cwayne> rsalveti, i guess i'm just not well-versed on what actually happens to get it from trusty-proposed to trusty-released
[04:29] <rsalveti> if you use trusty-proposed you might get additional dependencies/packages as well
[04:30] <cwayne> yeah, i don't wanna do that
[04:47] <rsalveti> hm, still in proposed
[04:48] <rsalveti> hm, https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-unity-scope-click/
[04:48] <rsalveti> auto package test is failing
[04:49] <cwayne> that seems less than great
[04:49] <rsalveti> yeah, not the same
[04:49] <rsalveti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[04:50] <rsalveti> maybe it might still be running in the private instance
[04:50] <rsalveti> yeah
[04:50] <rsalveti> http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-unity-scope-click/33/console
[04:51] <cwayne> ah
[04:51] <cwayne> so at this point should i just give up and make a new build tomorrow?
[04:52] <rsalveti> yeah, or just get it published in your ppa
[04:52] <cwayne> i dont even think i have upload rights to the ppa, heh
[04:52] <cwayne> ill just wake up early and do it tomorrow
[04:52] <rsalveti> alright
[04:54] <cwayne> unless its almost done, but i dont think it is
[08:07] <ev> robru: thank you for pointing people in the direction of cihelp. We're trying to get to the point where everyone on the team is capable of supporting any part of our infrastructure, and Otto is one area where we've made good progress (because we've had to deal with it a lot ;) ).
[08:17] <sil2100> geh, rat emergency, brb
[08:46] <sil2100> Back
[08:47] <didrocks> sil2100: hey!
[08:47] <sil2100> Damn, that rat just HAD to bite off all her stitches
[08:47] <didrocks> :/
[08:48] <sil2100> They're sewing her up again ;/
[08:48] <didrocks> can you prevent them in any way to do that?
[08:48] <sil2100> I ain't falling for this one again, I'll bandage her up once she's back here, she'll be unhappy but at least not bleeding to death ;)
[08:48] <sil2100> I'll make a mummy out of her
[08:50] <didrocks> heh :)
[08:50] <didrocks> sil2100: now that you've acted on emergency, there is another one I guess
[08:51] <didrocks> sil2100: so, we are seeing a lot of flakyness in the 3 last images
[08:51] <didrocks> sil2100: can you use your phone and rerun all AP tests locally? (or at least, some, to confirm you see that flakyness)
[08:51] <didrocks> then, I guess we'll have to revert one by one http://people.canonical.com/~ogra/touch-image-stats/20140220.2.changes
[08:51] <didrocks> I see 3 potential failures:
[08:51] <didrocks> - sdk
[08:52] <didrocks> - unity-scope-mediascanner/libmediascanner
[08:52] <didrocks> - indicator-datetime
[08:57] <sil2100> Ok, let me see
[08:57]  * sil2100 was trying to resolve one citrain problem in the meantime
[08:58] <didrocks> citrain problem? a bug?
[09:00] <sil2100> hmm, I need to double-check, but maybe it's a bug in the reconfugire
[09:00] <sil2100> Ah
[09:00] <sil2100> No, it seems to have been just robru's small error
[09:01] <sil2100> didrocks: in the meantime, let me upgrade to latest and do the reverts
[09:01] <sil2100> I'll start off with SDK
[09:03] <didrocks> sil2100: hum, first, do you mean starting some applications which fails?
[09:03] <didrocks> to ensure you can reproduce the issue :)
[09:03] <didrocks> mind*
[09:03] <didrocks> (without any revert)
[09:06] <sil2100> Of course ;)
[09:12] <didrocks> sil2100: maybe starts with dialer-app
[09:12] <didrocks> sil2100: it seems to have failed in the past 2 images
[09:12] <sil2100> didrocks: ok, I see webbrowser-app had some problems in one image as well
[09:13] <didrocks> yeah
[09:13] <didrocks> I mentionned dialer-app because it doesn't have a lot of tests
[09:13] <ogra_> whats up ? 199 looks okayish imho
[09:13] <didrocks> so, should be easy to restart
[09:13] <didrocks> ogra_: look at paul's message
[09:13] <didrocks> and the previous image
[09:13] <didrocks> there are quite some flakyness
[09:14] <ogra_> yes, i see that one
[09:14] <ogra_> but it went good again later
[09:14] <didrocks> well
[09:14] <didrocks> it will mean that it will maybe refail
[09:14] <sil2100> Flaky tests are not good in overall
[09:14] <didrocks> yeah
[09:14] <didrocks> if we ignore, it will strike back
[09:14] <ogra_> i didnt say ignore it :)
[09:15] <didrocks> hence the "let's bisect it" :)
[09:15] <sil2100> I would give some time to the responsible upstream (once we know who it is) to fix the test regression before reverting though ;) Like 2 hours or such
[09:16] <didrocks> yeah :)
[09:17] <didrocks> first one is to ensure that you have a small amount of tests reproducing the flaky failure
[09:18] <sil2100> Righto!
[09:19] <sil2100> Upgrade is finishing right now
[09:28] <sil2100> Finally upgraded, proceeding
[09:32] <didrocks> sil2100: joining?
[09:32] <didrocks> sil2100: also, can you join #sdk?
[09:32] <sil2100> Aaaa
[09:32] <sil2100> didrocks: sorry, got sucked into dialer-app, be right here
[09:59] <sil2100> didrocks, ogra_: so, after downgrading dialer-app, the test doesn't fail anymore but unity8 still dies and I can't get it up ;) Trying the session revert
[09:59] <didrocks> ah, excellent!
[10:00] <didrocks> sil2100: so, reverting dialer-app for now
[10:01] <didrocks> sil2100: can you get a bug report while the tests are running for dialer-app?
[10:01]  * didrocks works on the revert meanwhile
[10:06] <sil2100> didrocks: filling
[10:07] <sil2100> didrocks: just to make sure, don't upload the revert yet - just prepare it
[10:07] <didrocks> sil2100: ok
[10:24] <mhr3> sil2100, silo for 59 pls
[10:24] <sil2100> didrocks, ogra_: so, downgrading ubuntu-touch-session didn't really help, but downgrading dialer-app indeed made the one failure go away
[10:24] <ogra_> ohew
[10:24] <sil2100> didrocks, ogra_: I also noticed something regarding that unity8 issue
[10:24] <ogra_> *phew even
[10:25] <sil2100> When the dialer-app test finish, I get a white screen instead of the app
[10:25] <sil2100> Now:
[10:25] <sil2100> - When I swipe it out, unity8 hangs up and crashes, but then restarts and works correctly
[10:26] <sil2100> - When I leave the white screen-app until the screen turns off, unity8 dies and cannot be restarted anymore
[10:27] <ogra_> sounds power related
[10:28] <ogra_> i.e. muddled up powerd communication or so
[10:28] <sil2100> mhr3: one moment ;)
[10:29] <sil2100> Anyway, it's really strange
[10:30] <ogra_> check the dbus and powerd logs i'd say
[10:30] <ogra_> probably there is something obvious
[10:31] <didrocks> sil2100: do you have the bug report number?
[10:35] <sil2100> didrocks: hah, just filled it in, here it is: https://bugs.launchpad.net/dialer-app/+bug/1282981
[10:36]  * sil2100 is reverting further
[10:37] <didrocks> sil2100: so, uploading dialer-app revert
[10:38] <sil2100> didrocks: yes, thanks! It's confirmed at least that the revert helps
[10:38] <didrocks> ok ;)
[10:38] <didrocks> done
[10:38] <didrocks> so, next one :p
[10:38] <didrocks> you are continuing on the sdk now?
[10:39] <sil2100> First I would like to try lightdm, then SDK
[10:43] <sil2100> This problem is really strange
[10:43] <didrocks> sil2100: hum, lightdm wasn't on that list, you think we were just lucky?
[10:45] <sil2100> Because this failure doesn't seem to be related to the SDK, but I'm trying it now
[10:46] <sil2100> Need to reboot my device though, as it's hanged again ;/
[10:48] <mhr3> sil2100, two moments passed :)
[10:48] <sil2100> mhr3: ;)
[10:48] <sil2100> Let me do that while waiting for my device
[10:49] <sil2100> Ooooor wait a little bit longer, since we're still bisecting what caused the problems we're seeing, who know's if it's not YOUR PACKAGE ! :D
[10:50] <mhr3> i know it isn't! :P
[10:50] <psivaa> didrocks: After the findings from sil2100 about dialer app, do you still want me to revert ubuntu-ui-toolkit-theme and qtdeclarative5-ubuntu-ui-toolkit-plugin and run all the tests?
[10:51] <psivaa> didrocks: the failure link mail sent to you btw
[10:52] <didrocks> psivaa: oh, you didn't start yet? please do
[10:53] <didrocks> psivaa: it's only fixing dialer-app, not the rest of the worlds :)
[10:53] <psivaa> didrocks: ack, doing it
[10:53] <didrocks> mhr3: we need to concentrate on getting back to green first :)
[10:53] <didrocks> psivaa: thanks ;)
[10:53] <didrocks> mhr3: you're welcome if you can help us btw :)
[10:56] <mhr3> didrocks, sorry, my prio is to have pretty mwc image :)
[10:56] <didrocks> mhr3: sorry my prio is to keep having a green baseline :)
[10:57] <sil2100> ;p
[10:59] <didrocks> psivaa: thanks a lot for the detailed email, exactly what I needed!
[11:00] <psivaa> didrocks: yw, now installing 199 on a device. (reverting on an earlier device used for smoke might contaminate the dashboard)
[11:00] <didrocks> excellent
[11:08] <ralsina_> sil2100, didrocks: can I get a silo for a very harmless logging branch in row 60?
[11:10] <didrocks> rsalveti: hum
[11:10] <didrocks> ERROR:root:ubuntu-download-manager is already prepared for the same serie and destination in landing-010
[11:10] <didrocks> ERROR:root:One or more projects are already in use for the same destination and series in another silo (see above)
[11:11] <didrocks> and you were the requester :)
[11:11] <ralsina_> didrocks: didn't know I can't have two silos :-)
[11:12] <didrocks> ralsina_: you can't have two silos of the same project
[11:12] <ralsina_> ok, so now I know
[11:12] <ralsina_> ok, removing row 60
[11:12] <didrocks> ralsina_: well, otherwise, it means you can have conflicts in your branch
[11:13] <didrocks> if you prepare in parallel
[11:13] <didrocks> and so, you will have to redo all your work
[11:13] <didrocks> it's to prevent shooting yourself in your feet :)
[11:13] <ralsina_> didrocks: no problem
[11:43] <tvoss> sil2100, around?
[11:43] <sil2100> tvoss: hi!
[11:50] <sil2100> geeh
[11:51] <sil2100> Never before I was so irritated by tests passing
[11:52] <didrocks> :)
[11:53] <sil2100> I found which test failed first in the webbrowser-app test suite and try to run it in a loop now
[11:53] <didrocks> ah ;)
[11:54] <didrocks> not sure if it's just running that test which fails
[11:54] <didrocks> or the previous one creating that one to fail
[11:54] <didrocks> or anything else
[11:55] <didrocks> psivaa: anything failing yet? Not sure if we can have another device running the "raw" environment again
[11:56] <psivaa> didrocks: running the tests after reverting the ui-toolkit stuff. no failures yet. but the candidate apps for the failures have not started to run
[11:57] <psivaa> didrocks: raw environment means?
[11:57] <didrocks> psivaa: like rerunning in parallel every tests again with 199 without any change
[11:58] <psivaa> didrocks: ok, that can be done on the device used for smoke tests. how soon will there be another image?
[11:59] <psivaa> if it's not within another 4 hr, then that's safe to run
[11:59] <didrocks> psivaa: not soon
[11:59] <didrocks> yes :)
[11:59] <didrocks> can you try that at the same time? That would be awesome and give us one more input
[12:00] <psivaa> didrocks: ack, will run that again including the install. ( i earlier noticed some apps start to pass on the second run onwards)
[12:00] <didrocks> psivaa: excellent, thanks!
[12:00] <psivaa> yw :)
[12:04] <didrocks> sil2100: yeah, no failure for me as well on first run
[12:05] <sil2100> didrocks: I was even running 3 subsequent tests (the last one which failed) in a loop -> no failures after 20 runs, now re-running whole webbrowser-app suite again, maybe I'll get lucky
[12:06] <didrocks> I wonder if we would be able to reproduce it at all
[12:06] <didrocks> that's why I guess the "raw" rerun from psivaa will help to say if we should ocntinue or not investigating
[12:07] <sil2100> Indeed
[12:10] <dbarth_> hi
[12:11] <dbarth_> this is to get a silo reconfiged to add an MP to it
[12:11] <didrocks> hey dbarth_, I think there is a silo to reconfigure, sil2100? ^
[12:11] <dbarth_> ppa-005, i've added the MP to the pending tab already
[12:11] <didrocks> sil2100: I would say, let's stop investigation for now, let's assign silos, but not publish
[12:11] <didrocks> until we get more results from psivaa
[12:11] <dbarth_> sil2100: this MP covers friends-app which needs to be updated to work with the OA changes
[12:11] <didrocks> sil2100: everything passed here as well
[12:12] <dbarth_> sil2100: i haven't seen other friends-app landings in parallel, so should be safe and won't lock other changes
[12:12] <sil2100> Ou
[12:12] <sil2100> Looking
[12:12] <sil2100> didrocks: right, my re-run has finished, no failures ;_;
[12:12] <didrocks> sil2100: yeah, third rerun here as well, nothing :/
[12:13] <psivaa> didrocks: sil2100:tests running on 2 devices one raw 199 and the other 199 with ui-toolkit stuff reverted. btw we did not have webbrowser app failures on 199 though
[12:13] <sil2100> dbarth_: reconfiguring
[12:13] <thostr_> didrocks: can we land an updated MP again?
[12:13] <didrocks> psivaa: yeah, but there was no change for it since the failure on previous updates
[12:13] <didrocks> thostr_: so, ok to attribute silos, we don't publish to distro yet though
[12:13] <didrocks> until we get the results we are talking about ^
[12:14] <didrocks> psivaa: excellent that you can even use 2 devices! :)
[12:14] <didrocks> (it's 2 mako?)
[12:14] <psivaa> didrocks: ack, yes
[12:14] <didrocks> perfect ;)
[12:14] <thostr_> didrocks: meaning, MP was landed but then we figured it caused issues and updated the MP. So  can I now just get a new silo with same MP (but different rev)?
[12:15] <thostr_> (old silo was already cleaned)
[12:15] <sil2100> thostr_: just rebuild the silo by mentioning the component you updated
[12:15] <sil2100> Ah
[12:15] <didrocks> thostr_: hum, so the MP was "merged
[12:15] <didrocks> thostr_: yeah, it's not an issue
[12:15] <sil2100> hm
[12:15] <didrocks> you can get a new silo with that
[12:16] <didrocks> (just note that if the MP commit is the same, it will just reput the same one in the changelog)
[12:16] <thostr_> didrocks: can I get one right away then for line 60? it's urgent for mwc demo...
[12:16] <sil2100> thostr_: ok
[12:16] <sil2100> dbarth_: 005 reconfigured
[12:16] <didrocks> sil2100: handling the other one?
[12:16] <sil2100> didrocks: I'll assign for line 60
[12:16] <didrocks> excellent, thanks
[12:20] <sil2100> thostr_: silo assigned
[12:20] <sil2100> mhr3: for you as well
[12:20] <mhr3> thx
[12:20] <dbarth_> sil2100: thanks
[12:21] <thostr_> sil2100: that was fast. thanks!
[12:21] <mhr3> thostr_, wait for the icon mp?
[12:22] <thostr_> mhr3: is that ready?
[12:22] <mhr3> thostr_, i asked alecu to add it to the screenshot one
[12:22] <thostr_> oh, but that I already added to the silo
[12:23] <thostr_> mhr3: that is https://code.launchpad.net/~alecu/unity-scope-click/add-screenshot/+merge/207487
[12:24] <mhr3> yea, although he seems afk
[12:24] <mhr3> i'll make a new one
[12:24] <mhr3> ne wmp
[12:25] <thostr_> mhr3: ok
[12:32] <mhr3> thostr_, https://code.launchpad.net/~mhr3/unity-scope-click/proper-icon/+merge/207636
[12:32] <mhr3> someone should review though
[12:32] <thostr_> mhr3: yeah, let's get it reviewed first
[12:33] <thostr_> and then land separately... need to get the scope fix (blocks right now) in ASAP
[12:40] <psivaa> sil2100: didrocks: if you'd like to see the raw 199 results live: http://ci.ubuntu.com/smokeng/trusty/touch/mako/199:20140221.1:20140115.1/6736/
[12:40] <ogra_> sil2100, did you get anywhere with your research ?
[12:41]  * ogra_ holds back two uploads for the unity8 landing from silo 16
[12:41] <psivaa> i'm sure you'd ignore the queued ones.
[12:41] <didrocks> psivaa: ah great, but what about the seconde device?
[12:41] <didrocks> second*
[12:42] <sil2100> ogra_: no... we didn't find anything ;/ In the end the dialer-app crash was something different, and we couldn't reproduce the flaky issues on any of our local re-runs
[12:42] <ogra_> hmm
[12:42] <sil2100> ogra_: we're waiting for smoke tests
[12:42] <psivaa> didrocks: still running. http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-daily/2/console for results. that wont have dashboard like view though
[12:42] <ogra_> well, 199 seems to be close to done
[12:43] <sil2100> The dialer-app error is fixed by the revert that didrocks made, so I think this one is no longer valid
[12:43] <sil2100> One clock app failure, hm
[12:46] <didrocks> still the same than usual I guess
[12:46] <ogra_> yeah, looksing at 199 it doesnt look bad
[12:47] <ogra_> did we have many give-backs yet ?
[12:47] <didrocks> ogra_: we are trying 2 in // for whole test suite
[12:47] <didrocks> ogra_: all manual ones all passed
[12:48] <didrocks> so maybe 199 is "fixed", but I don't know how
[12:48] <ogra_> heisenbug
[12:48] <didrocks> yeah ;)
[12:48] <ogra_> solar winds ...
[12:48] <ogra_> humidity in the lab
[12:48] <didrocks> well, it's sprint in winter, I won't trust anything anymore
[12:48] <didrocks> spring*
[12:48] <ogra_> not in the lab though
[12:48] <ogra_> that might be it ...
[12:48] <didrocks> who knows? :)
[12:48] <didrocks> did you check? ;)
[12:49] <ogra_> temp difference between the test setup and the viewerr of the dash results ;)
[12:49] <didrocks> ahah
[12:49] <didrocks> maybe, yeah ;)
[12:49] <didrocks> ogra_: maybe worth you give a quick dogfood on image 199?
[12:49] <didrocks> for maguro
[12:49] <ogra_> sure
[12:49] <didrocks> thanks
[12:50] <didrocks> the dialer-app failure shouldn't prevent us for promoting, if it's the only thing
[12:50] <didrocks> as it's an AP failure only
[12:50] <ogra_> yeah
[12:50]  * ogra_ upgrades his maguro
[12:50] <didrocks> great great :)
[12:50] <ogra_> takes ages :/
[12:50] <didrocks> well, seeing the time it's taking on mako, I don't want to imagine on maguro…
[12:51] <ogra_> yeah, looking forward to drop it
[12:52] <ogra_> but we havent got any fix for upgrading the radio fw
[13:03] <Laney> please silo up line 20
[13:03] <asac> did we manage to get image back to green? :)
[13:03] <ogra_> didrocks, maguro testing done ... the camera flickers
[13:04] <ogra_> (teh rest is fine :) )
[13:04] <didrocks> ok, no surprise, good :)
[13:04] <didrocks> asac: we are running full tests again on 199
[13:04] <asac> didrocks: rerun?
[13:04] <didrocks> couldn't reproduce the issues on 196 and 197
[13:04] <asac> http://ci.ubuntu.com/smokeng/trusty/touch/mako/199:20140221.1:20140115.1/6736/
[13:04] <didrocks> asac: look at the syncing and running
[13:04] <asac> dialer and clock still... but guess those have been backed out?
[13:04] <asac> oh
[13:05] <asac> didrocks: was there an infra issue or why do we rerun?
[13:05] <didrocks> dialer is back out
[13:05] <ogra_> backing out didnt change it
[13:05] <didrocks> asac: we couldn't reproduce locally
[13:05] <didrocks> 199 looked fine as well
[13:05] <didrocks> only 196 and 197 were crappy
[13:06] <didrocks> but we started from the latest
[13:06] <asac> didrocks: so we rerun 199 because we think there was something fishy with infra, correct?
[13:06] <didrocks> tried to rerun multiple times
[13:06] <didrocks> asac: right
[13:06] <asac> k
[13:06] <didrocks> there are 2 runs in parallel
[13:06] <didrocks> one visible in the dashboard
[13:06] <didrocks> and another one
[13:06] <didrocks> just to ensure
[13:06] <asac> good
[13:06] <didrocks> asac: dialer-app will refail
[13:06] <didrocks> but that's expected
[13:06] <asac> yeah
[13:06] <didrocks> and it's backed out
[13:06] <asac> guess thats in 200
[13:06] <didrocks> yeah
[13:06] <ogra_> dogfooding looked fine for popey and me btw
[13:07] <didrocks> but it's the test only
[13:07] <asac> so we just check quickly if we can resume landings
[13:07] <didrocks> so not a blocker for promotion
[13:07] <didrocks> yeah
[13:07] <asac> or if there is something else looming
[13:07] <asac> sounds good
[13:07] <asac> thx
[13:07] <didrocks> yw :)
[13:07] <asac> i think tvoss had something important to land
[13:07] <didrocks> (for the record notes-app is flaky for a long time already, nothing new here)
[13:07] <asac> gues she can prep silo and if all goes wrong still can copy from there to the demo ppa
[13:07] <didrocks> yeah
[13:08] <didrocks> needing first a ready line
[13:08] <asac> who is working on notes-app?
[13:08] <asac> balloons: ?
[13:08] <didrocks> nobody
[13:08] <didrocks> I keep repeating it's flaky on the ML
[13:08] <ogra_> well, the community
[13:09] <tvoss> asac, sil2100 is helping me out
[13:09] <tvoss> didrocks, sil2100 https://code.launchpad.net/~thomas-voss/platform-api/remove-assert-on-bridge-to-fix-package-builds/+merge/207640
[13:15] <tvoss> popey, around?
[13:15] <tvoss> popey, if so, can you give https://launchpad.net/~ci-train-ppa-service/+archive/landing-008/ a spin?
[13:16] <popey> hey tvoss
[13:16] <popey> wossat?
[13:16] <popey> i mean, what exactly do you want testing ☻
[13:17] <tvoss> popey, just ten minutes exploratory testing if anything goes havoc
[13:17] <tvoss> popey, have a look at top, too
[13:17] <popey> should i get better location detection or something else magic?
[13:17] <popey> sil2100: can you find someone to review your terminal fix? Would *love* to get that in ASAP
[13:18] <tvoss> popey, nope, just check if nothing goes havoc
[13:18] <popey> ok, will do
[13:19] <sil2100> popey: sure ;)
[13:19] <cwayne> can we actually hit enter in terminal now?!
[13:20] <sil2100> cwayne: yes! I mean, at least locally after testing the fix I made it was working
[13:22] <popey> cwayne: you may need to break that gif out again later!
[13:22] <popey> if we get it in
[13:22] <sergiusens> ogra_, didrocks notes is not community
[13:22] <ogra_> oh ?
[13:22] <ogra_> i thought we had it during the last app days
[13:22] <sergiusens> ogra_, notes is canonical aka bill
[13:23] <ogra_> ok
[13:23] <sergiusens> perhaps; but it's a compiled app and people have issues with compiling ;-)
[13:23] <psivaa> didrocks: so far, on with ui-toolkit reverted, dialer app and notes app failures seen. no webbrowser failures on the raw one either
[13:23] <cwayne> popey, :D
[13:24] <sil2100> popey: I noticed a different problem in the terminal app though recently, thankfully a small one
[13:24] <ogra_> shush !
[13:24] <popey> don't bring me problems, bring me solutions!
[13:24] <sil2100> popey: notice that when you tyle 'k' on the keyboard, you input goes blank ;) It appears after pressing some other letter
[13:24] <popey> make the font bigger
[13:24] <popey> known issue since day 1
[13:24] <sil2100> YAY
[13:24] <sil2100> NOTREGRESSION
[13:24] <popey> BOOM!
[13:24] <sil2100> \o/
[13:26] <sil2100> I afk for a moment to start preparing lunch
[13:32] <Laney> Can someone assign line 20 a silo please?
[13:32] <Laney> then press build for me if you're able to
[13:32] <Laney> important curling based lunch is taking place ;-)
[13:39] <sil2100> Laney: will try
[13:49] <sil2100> tvoss: I'll have to remove all those test-built components from the PPA to proceed - did you/anyone test them on the device?
[13:49] <sil2100> (like dbus-cpp, location-service, indicator etc.)
[13:50] <tvoss> popey, ^?
[13:50] <popey> am doing right now.
[13:50] <sil2100> I mean, I can leave them around for now, but before releasing I'll have to remove those
[13:50] <popey> taking a while to boot, sensorservice doing it's "EAT THE CPU!!" thing
[13:52] <sil2100> Is that known?
[13:53] <popey> yes
[13:54] <popey> well, there's a bug for it
[14:05] <popey> tvoss: Feb 21 14:05:36 ubuntu-phablet com.ubuntu.location[845]: SV status update: [#svs: 21]
[14:05] <popey> is that number of satellites I can see?
[14:05] <popey> 21
[14:06] <tvoss> popey, yup
[14:06] <tvoss> does not mean they are used in calculating the solution, though
[14:06] <popey> details details
[14:07] <popey> seems good to me, not eating my cpu or anything
[14:08] <sil2100> \o/
[14:11] <popey> sil2100: ok, stopped testing now, my phone isn't on fire so I'd say it's okay from that limited testing
[14:13] <tvoss> popey, thanks for giving it a spin
[14:13] <popey> np
[14:25] <sil2100> popey: thank you :)
[14:25] <sil2100> popey: you rock!
[14:31] <popey> sil2100: http://popey.com/~alan/phablet/device-2014-02-21-143108.png
[14:31] <popey> \o/
[14:33]  * ogra_ hugs sil2100 
[14:33] <ogra_> land it ... land it ... land it !!!!
[14:36] <sil2100> AaaaaaAAa!
[14:36] <ogra_> a
[14:36] <sil2100> Too much pressure!
[14:36] <ogra_> :)
[14:36] <sil2100> ;)
[14:37] <sil2100> Well, Daniel made it possible due to his input on the Qt patch
[14:40] <ralsina_> sil2100: can I get a reconfigure in silo 001 please?
[14:41] <sil2100> ralsina_: sure
[14:41] <ralsina_> sil2100: thanks
[14:41] <sil2100> ralsina_: you updated the MR list already, yes?
[14:42] <ralsina_> sil2100: yes
[14:47] <sil2100> ralsina_: reconfigured
[14:48] <ralsina_> sil2100: awesome
[14:53] <sil2100> popey: ok, so Daniel approved my merge - I guess that's enough ;p Let me top-approve it
[14:53] <ogra_> ++
[14:53] <popey> happy days
[14:54] <popey> now.. another bug I just found
[14:54] <sil2100> Oh, hm, actually I don't think I can
[14:54] <popey> i can
[14:54] <sil2100> fginther: hello!
[14:54] <ogra_> doit !
[14:54] <fginther> sil2100, hey
[14:54] <sil2100> Oh
[14:54] <popey> happroved
[14:54] <sil2100> fginther: do you know if lp:ubuntu-terminal-app/plugin will be somehow automagically built and released once approved? (click component)
[14:55] <sil2100> popey: what new bug?
[14:55] <popey> unrelated...
[14:55] <popey> now, the other problem is if you have the typing assistance things on system settings then the terminal shows what you type
[14:55] <popey> even if it's a password prompt
[14:55] <popey> e.g. if you have autocorrect on
[14:56] <balloons> didrocks: asac ping
[14:56] <fginther> sil2100, no, I don't know how that is released. sergiusens, do you know how lp:ubuntu-terminal-app/plugin is released?
[14:57] <sil2100> fginther, sergiusens: it's used by lp:ubuntu-terminal-app somehow ;) It's a bit confusing for me though
[14:57] <sil2100> (upstream developer is not around)
[14:58] <balloons> fginther: it's part of the terminal app.. we need to add it to the cmake build files
[14:59] <sergiusens> fginther, sil2100 that depends on the old PPA push still working
[14:59] <fginther> sergiusens, of the plugin into the core-apps ppa?
[14:59] <sergiusens> fginther, yeah, does that work
[14:59] <sergiusens> ?
[15:00] <sergiusens> if it is, gimmie a sec and I'll do some magic
[15:02] <fginther> sergiusens, https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily/+packages konsole-qml-plugin is there. The source branch hasn't changed since the last dput
[15:02] <sergiusens> fginther, the source for terminal you mean?
[15:03] <fginther> sergiusens, the source for lp:ubuntu-terminal-app/plugin
[15:04] <sergiusens> fginther, what did sil2100 release then?
[15:04] <sil2100> I didn't release anything
[15:04] <sil2100> I have no power over click apps ;)
[15:05] <sergiusens> sil2100, yeah, this is not click though ;-)
[15:05] <sergiusens> as the code merged?
[15:05] <sil2100> sergiusens: it's used by a click app ;) And it's not in any package besides terminal-app
[15:06] <sil2100> sergiusens: the code is not merged yet, it's top-approved though
[15:06] <sil2100> Just hope there's some merger or something
[15:06] <sergiusens> sil2100, well merging and getting it into the ppa was an fginther thing (I think)
[15:07] <fginther> sil2100, ok, there is a job on http://91.189.93.70:8080/ to do that, what's the MP?
[15:08] <fginther> sil2100, nvm, it's just built
[15:08] <sil2100> fginther: https://code.launchpad.net/~sil2100/ubuntu-terminal-app/plugin_fix_enter_backspace/+merge/207463 <- I see it's merged :)
[15:09] <fginther> sil2100, sergiusens, a new trusty package has been uploaded to the ppa
[15:14] <sergiusens> fginther, we use the saucy one though :-0
[15:14] <sergiusens> still framework-13.10
[15:14] <fginther> sergiusens, saucy is also there
[15:14] <sergiusens> fginther, great
[15:15] <sergiusens> fginther, so dpm might be working on integrating that into the terminal app's source tree (to build it like the reminders app)
[15:15] <dpm> sergiusens, fginther, after MWC, though
[15:16] <sergiusens> understandable
[15:18] <psivaa> didrocks: http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-daily/2/ shows 4 failures with ui-toolkit reverted on 199
[15:18] <psivaa> clock, notes and dialer are the main failures with a systemsettle issue after terminal tests
[15:18] <ogra_> why do i see 5 on the dashboard ?
[15:19] <ogra_> (4 errors 1 failure)
[15:19] <psivaa> ogra_: the dashboard only shows the official image results. that one that pasted above is a reverted one
[15:19] <rsalveti> didrocks: sil2100: can you quickly reconfigure silo 4 with the current list of src packages?
[15:19] <ogra_> ah
[15:20] <rsalveti> didrocks: still testing the new android images, but it seems we're good
[15:20] <psivaa> the re-run of the official one (raw 199) is still ongoing
[15:20] <sil2100> rsalveti: let me see that
[15:20] <ogra_> right, i see that
[15:21] <sil2100> rsalveti: so, it's a source-upload only landing, yes?
[15:21] <rsalveti> sil2100: yes
[15:21] <kgunn> sil2100: so if i delete or add an mp to a landing silo..do you need to reconfigure ?
[15:22] <sil2100> kgunn: yes, if the MP list is modified a reconfigure is needed
[15:23] <sil2100> (we hope that soon landers will be able to do it themselves)
[15:29] <kgunn> sil2100: so if i delete or add an mp to a landing silo..do you need to reconfigure ?
[15:30] <sil2100> kgunn: yes :)
[15:31] <kgunn> sil2100: thot so...would you mind to reconfigure silo 11 ?
[15:31] <sil2100> kgunn: no problem
[15:32] <sil2100> kgunn: reconfigured :)
[15:33] <kgunn> thank you sir!
[15:37] <sil2100> yw!
[15:39] <sil2100> rsalveti: I reconfigured the silo some time ago, forgot to mention it
[15:41] <ralsina_> sil2100: can you land silo 1 please?
[15:42] <rsalveti> sil2100: great, thanks
[15:42] <sil2100> ralsina_: I would love to, just I still didn't get a reply from didrocks regarding our landing status - if we're free to land stuff or not
[15:43] <ralsina_> sil2100: oh, ok!
[15:43] <sil2100> asac: do you know anything about didrocks current decision on landing/publishing stuff?
[15:44] <sil2100> asac: are we still supposed to stall landing until the flaky tests are resolved, or did that get invalidated and we can land?
[15:44]  * ogra_ would really start landing again 
[15:45] <ogra_> psivaa's tests have shown nothing unusual ... smoke tests passed ... and landings are piling up
[15:46] <ogra_> s/smoke tests/manual smoke tetst/
[15:46] <psivaa> ogra_: ack, it was didrocks that needed a rerun with raw 199 to see if the infra is behaving funny. i am fine with another image
[15:46] <sil2100> I think we're more or less safe as well, as locally we couldn't reproduce
[15:46] <psivaa> the one that's running currently is also about to finish
[15:47] <ogra_> well, not image... we keep all fixes from landing, holding up MWC work
[15:51] <mhr3_> sil2100, added one more mp to 002, could you reconf?
[15:52] <sil2100> mhr3_: sure
[15:54] <sil2100> ogra_: I think all our decision-making staff is MIA!
[15:54] <ogra_> slackers !!
[15:57] <sil2100> ogra_: ok, I would say, since didrocks and asac are not around, we take decision-making into our hands! So, let's start landing stuff in a moment
[15:58] <ogra_> yeah
[15:58] <ogra_> silo 16 would help me with a pending upload btw :)
[15:58] <sil2100> ogra_: is it tested? ;)
[15:59] <ogra_> i think Saviq ran the tests
[15:59] <ogra_> i did some manual smoketesting
[15:59] <Saviq> ogra_, I ran unity8 and settings tests on mako
[15:59] <Saviq> sil2100, ↑
[15:59] <Saviq> ogra_, if you didn't see anything wrong with flo@18
[15:59]  * ogra_ would think thats sufficient
[15:59]  * Saviq didn't
[15:59] <ogra_> yeah, worked fine after your last fix
[15:59] <Saviq> kgunn, actually is being handled here ↑
[16:01] <sil2100> Saviq, ogra_: if you think it's tested enough and according to the test plans, please set to tested yes ;)
[16:01] <Saviq> sil2100, right!
[16:01]  * Saviq will do one last round, then
[16:02] <sil2100> Thanks!
[16:02] <sil2100> mhr3_: 001 published
[16:04] <mhr3_> sil2100, that's thostr's
[16:04] <sil2100> Ah oh, right ;)
[16:04] <sil2100> thostr_: ^
[16:04] <didrocks> sil2100: did we get all things running ok?
[16:04] <didrocks> in the 2 runs that psivaa did
[16:05] <thostr_> sil2100: thanks!
[16:06] <psivaa> didrocks: camera app test has a new set of failures which we have not seen before. but i bet that will disappear if i rerun the test
[16:06] <didrocks> psivaa: on the 2 makos?
[16:06] <didrocks> it's the only issue?
[16:06] <sil2100> didrocks: camera-app had settle_after and phablet-test-run errors
[16:06] <didrocks> ok, all others are ok (of course, not dialer-app and not notes-app)?
[16:07] <didrocks> on the 2 devices?
[16:07] <psivaa> didrocks: no this was only on raw 199. on the reverted one, there were only clock, dialer and notes ( and systemsettle aftter terminal)
[16:08] <didrocks> ok, sounds ok then, mind rerunning camera-app to ensure?
[16:22] <didrocks> popey: hey, can you reproduce balloons' bug? https://bugs.launchpad.net/ubuntu/+source/camera-app/+bug/1282753
[16:23]  * popey looks
[16:26] <popey> didrocks: i cant reproduce that
[16:28] <balloons> popey: sometimes it required repeating the steps, but engaging the front camera seemed to be required
[16:28] <didrocks> do a selfi!
[16:34]  * sil2100 waits for feedback from popey 
[16:34]  * balloons notes we're both in a team meetin'
[16:34] <popey> sil2100: hmm?
[16:35] <sil2100> didrocks: should I land the gallery-app transition to click?
[16:35] <didrocks> sil2100: is it ready ready? there is an image building right now, maybe we should wait on those results?
[16:35] <sil2100> popey: the balloons bug
[16:36] <sil2100> didrocks: it's ready it seems, just will require updating the seed from the attached branch though once landed
[16:36] <sil2100> didrocks: ok, let's wait ;)
[16:36] <sil2100> didrocks: there's also the properties-cpp and platform-api landing that's ready to land
[16:37] <didrocks> the rest are ok to land
[16:37] <didrocks> I kicked an image FYI
[16:37] <sil2100> o/
[16:37] <sil2100> Aye aye!
[16:37] <sil2100> Captain'
[16:37] <sil2100> ;)
[16:38] <popey> sil2100: didrocks will try balloons bug again, phone is doing autopilot testing right now
[16:38] <didrocks> ok :)
[16:39] <dbarth__> hi sil2100: i need another reconfig on silo 005, we updated another branch
[16:39] <dbarth__> hopefully for good now
[16:40] <sil2100> dbarth__: sure!
[16:40] <sil2100> om26er: thanks!
[16:41] <sil2100> I mean
[16:41] <sil2100> popey: thanks!
[16:41] <om26er> sil2100, hah, thank me as well, I fixed the test that caused revert for dialer-app ;)
[16:41] <om26er> sil2100, when can that get back in ? is that going to take a while ?
[16:44] <sil2100> dbarth__: reconfigured!
[16:44] <sil2100> om26er: oh, excellent! Just prepare a landing with that MP fixing that issue and we'll release it as soon as there is a moment ;)
[16:45] <sil2100> ogra_: landing 16
[16:45] <didrocks> boiko: hey!
[16:46] <ogra_> thanks sil2100
[16:49] <boiko> didrocks: hi
[16:49] <didrocks> boiko: FYI, we had to revert dialer-app
[16:49] <didrocks> one of the AP tests was always failing
[16:50] <didrocks> (at it seems other people are getting CPU issues with it)
[16:50] <didrocks> boiko: how did you run the AP tests? Maybe there is something wrong with your setup
[16:51] <boiko> didrocks: so, I ran on the device, but it probably didn't have the latest version of messaging-app there
[16:52] <didrocks> boiko: it's dialer-app only, not messaging-app
[16:52] <balloons> didrocks: might be a bit late to the landing meeting
[16:52] <didrocks> balloons: ok, thanks for the warning :)
[16:52] <didrocks> boiko: did you think you added the right ppa?
[16:52] <boiko> didrocks: do you have the link to the failure there? cause earlier this morning om26er mentioned one of the dialer-app tests failed (the one that lunches messaging-app)
[16:53] <didrocks> boiko: sure, it's https://bugs.launchpad.net/ubuntu/+source/dialer-app/+bug/1282981
[16:53] <didrocks> it was one of your landings
[16:54] <om26er> didrocks, yes, its a multi-app integration tests so there are multiple stakeholders, i proposed the fix for it
[16:54] <om26er> the problem happened because some property changed in messaging-app that we were relying on
[16:54] <boiko> didrocks: so, I used the dialer-app from the ppa, but the messaging-app from the image, that's probably why I didn't catch this problem, I will start dist-upgrading the device before running the tests
[16:55] <didrocks> ah ok, mid-air collision then?
[16:55] <didrocks> boiko: yeah, always test on latest proposed image
[16:56] <boiko> didrocks: it was the latest on proposed, but there was a newer version of messaging-app released
[16:56] <boiko> didrocks: anyway, why the need to revert that? as opposed to just opening a bug with the failure?
[16:56] <didrocks> boiko: because we need to keep the baseline green
[16:57] <didrocks> boiko: if we didn't do a revert, we'll never have an image we can promote
[16:57] <didrocks> because when you fix something, something else breaks
[16:57] <boiko> okie dokie
[16:57] <didrocks> so same rule for everyone, it even happened for what we personally upload :)
[16:57] <didrocks> boiko: that enables upstream as well to "relax" and take time for the proper fix
[16:58] <boiko> didrocks: got it, no problems
[16:58] <boiko> didrocks: so, should I propose the MRs for releasing again? together with om26er's fix for that?
[16:58] <didrocks> boiko: exactly :)
[16:58] <didrocks> you will have to build with an option
[16:58] <didrocks> but you will discover that :p
[16:58] <didrocks> (it's "ignore version in destination)
[16:59] <boiko> didrocks: ok
[16:59] <boiko> didrocks: so, just for me to understand, the trunk of dialer-app was not reverted, right? just the version of it in the image
[17:00] <didrocks> right
[17:00] <didrocks> only uploaded to distro
[17:00] <didrocks> and so next build will complain
[17:00] <didrocks> that there is a version in distro not in your changelog
[17:00] <didrocks> as it's only a revert, you can ignore it
[17:00] <didrocks> and there is an option to tell "I know what I do"
[17:00] <boiko> didrocks: ok
[17:00] <didrocks> boiko: this is the FORCE_REBUILD
[17:01] <didrocks> Force rebuilding components associated to a MP even if there is no diff with dest or if latest version in destination archive isn't in targeted branches.
[17:01] <didrocks> (second part of the sentence applies to your case)
[17:02] <didrocks> cyphermox: robru: coming?
[17:02] <kgunn> sil2100: one more time, can you reconfig silo 11 ?
[17:04] <sil2100> kgunn: sure!
[17:04] <boiko> didrocks: ok, so just for me not to do anything wrong, now I just need to propose om26er's MR for releasing, right? the other two are already in trunk
[17:05] <sil2100> kgunn: reconfigured
[17:05] <didrocks> boiko: yeah, sounds good
[17:05] <boiko> didrocks: thanks, I will review the MR and then ask for a release
[17:13] <balloons> plars: you will likely see this eds bug in new runs; https://bugs.launchpad.net/ubuntu/+source/qtorganizer5-eds/+bug/1282129
[17:14] <plars> balloons: in image 200?
[17:14] <balloons> plars: yes
[17:14] <plars> balloons: ack, thanks for the heads up
[17:17] <balloons> plars: in general as well there are new core apps that might regress in the image; be on the lookout
[17:18] <balloons> lots of updates for mwc
[17:19] <plars> robru: there was a bug I think about those packages that are moving to click, can you point me at that? or at least remind me which apps it was?
[17:20] <robru> plars, it's gallery-app and camera-app...
[17:21] <robru> plars, i can't find the jenkins failures, you'd have to ask sergiusens i think
[17:22] <sergiusens> plars, robru it's in silo 7
[17:22] <sergiusens> but I'm delaying til monday
[17:22] <sergiusens> too many mwc crits going on
[17:22] <sergiusens> don't want to add an additional pain point
[17:23] <robru> ah ok
[17:24] <plars> robru: ok, so we'll take a look again next week I guess
[17:24] <robru> no worries
[17:24]  * didrocks hugs sergiusens
[17:24] <didrocks> thanks dude :)
[17:31] <sil2100> Ok, I drive now to pick up my patient ;p
[17:34] <didrocks> cgoldberg: can you give more descriptive info than just "autopilot release" for the future landings please?
[17:34] <ogra_> didrocks, the two uploads i just did will shove off 5sec from the boot time (you might probably want to mention that for the upcoming 201 image)
[17:34] <didrocks> ogra_: excellent, yeah, will do
[17:35] <cgoldberg> didrocks, ack
[17:35] <ogra_> (no worries, was all tested the whole day here ... )
[17:35] <didrocks> I have no worry :p
[17:35] <ogra_> :)
[17:35] <didrocks> thanks cgoldberg
[17:35] <didrocks> same tvoss, please, give a descriptive landing infos please :) ^
[17:38] <mhr3_> sil2100, 002 rdy to publish
[17:39] <didrocks> dbarth__: sass support! Oh my. I'm dreaming :)
[17:42] <dbarth__> sass is a css parser, you sure that makes you feel so good ?
[17:42] <dbarth__> ;)
[17:42] <dbarth__> but yeah, sass is cool
[17:43] <didrocks> dbarth__: I'm using sass daily on my personal projects :)
[17:43] <didrocks> dbarth: so yeah, it's music to my ears
[17:43] <dbarth> didrocks: ah cool
[17:43] <tvoss> didrocks, where do I need to add that?
[17:43] <didrocks> (with compass module)
[17:43] <dbarth> didrocks: now i see
[17:43] <didrocks> tvoss: on the spreadsheet (first column)
[17:44] <dbarth> didrocks: join the party, we'll have many more fixes from ant later on with that new sass support
[17:44] <tvoss> didrocks, I meant to ask for which landing
[17:44] <robru> didrocks, can I get you to preNEW lp:cordova-cli?
[17:44] <popey> didrocks: are you seeing jpeg style artifacts on the window buttons in latest trusty?
[17:45] <didrocks> dbarth: excellet, will try once I don't get 4 pings in 13s :)
[17:45] <didrocks> tvoss: "properties-cpp release"
[17:45] <popey> http://i.imgur.com/XNAV67E.jpg
[17:45] <didrocks> robru: hum, you will need a FFe anyway, can you prepare that first?
[17:45] <didrocks> popey: ah, I have another issue
[17:45] <didrocks> popey: http://people.canonical.com/~didrocks/tmp/capure_buttons.png
[17:45] <robru> bah
[17:46] <didrocks> popey: only on the non maximized window
[17:46] <popey> yeah
[17:46] <popey> same
[17:46] <popey> got a bug?
[17:46] <didrocks> not yet
[17:46] <popey> what package is it, I'll file one
[17:46] <didrocks> popey: do you have that in a guest session?
[17:46] <popey> lemme see
[17:46] <didrocks> popey: now, it's unity
[17:46] <didrocks> (I don't have the issue on a guest session)
[17:47] <popey> hmm, i have no guest session
[17:47] <didrocks> ah
[17:47] <popey> in the system menu
[17:47] <didrocks> you don't have lightdm
[17:47] <popey> oh yeah :D
[17:47] <popey> \o/
[17:47] <didrocks> maybe gdm removed the guest session :p
[17:47] <popey> me vs lightdm -> (╯°□°)╯︵ ┻━┻
[17:47] <didrocks> :)
[17:50] <didrocks> robru: hum, it's looping
[17:50] <didrocks> I can't do a licensecheck
[17:50] <didrocks> robru: you don't need   * Automatic snapshot from revision 41 (bootstrap)
[17:50] <didrocks> with ci train
[17:50] <robru> ah
[17:50] <didrocks> it will grab commits until the latest changelog vcs tag
[17:51] <didrocks> Priority: extra
[17:51] <didrocks> -> should be optional
[17:51] <robru> didrocks, yes unfortunately this project contains infinitely looped symlinks. it was unavoidable. the only alternative was to have ten thousand vendored copies of every vendored module.
[17:51] <didrocks> robru: ah, as long as this builds…
[17:52] <robru> didrocks, yeah it builds, I've used it ;-)
[17:52] <robru> didrocks, it's a nodejs thing. it vendors modules by default, so it recursively vendors multiple different copies of various modules. I had to write quite the script to flatten the vendored module tree, saved like 80% duplication in vendored modules.
[17:53] <robru> didrocks, but then you have to recreate the tree with symlinks, and it ends up being cyclic.
[17:54] <didrocks> robru: I don't understand this vendor module thing. It doesn't seem to be cordova code dependant?
[17:55] <robru> didrocks, I'm not sure what you're asking. cordova is written in node, node uses npm to grab it's dependencies, and npm builds this massively duplicated tree of vendored modules inside the package.
[17:55] <didrocks> robru: ack for node, npm… however, not sure to understand the "duplicated tree of vendored modules"
[17:55] <didrocks> what is a vendored module compare to what we can call a module?
[17:57] <robru> didrocks, ok, so lets say cordova-cli depends on node modules called A, B, and C. But then lets say that A also depends on C. npm will create a file heirarchy that contains module C installed at both cordova-cli/node_modules/C and cordova-cli/node_modules/A/node_modules/C even if they are identical.
[17:57] <robru> didrocks, so i wrote a script that just creates one single flat _vendor directory, dumps all modules there, and then symlinks them back to where node expects to find them.
[17:58] <didrocks> ahhhhh
[17:58] <didrocks> much clearer now :)
[17:58] <didrocks> it's the find_dupes.py, right?
[17:58] <robru> didrocks, it cut down on a huge amount of duplication and saves something ridiculous like 80% disk space
[17:58] <didrocks> nice work :)
[17:58] <didrocks> and you do that in you node_modules target
[18:00] <didrocks> robru: so, if you install this…
[18:00] <didrocks> and you start grep -r
[18:00] <didrocks> basically, you are screwed, right?
[18:00] <didrocks> ah no, it knows how to stop…
[18:02] <didrocks> robru: so, in addition to the priority, some remarks:
[18:02] <didrocks> you ship a .gitmodules
[18:02] <didrocks> you probably want to remove this
[18:02] <didrocks> the upstream version is 3.4-pre
[18:02] <didrocks> you can't have two - in a packaging version
[18:02] <didrocks> so 3.4-pre-0ubuntu1 doesn't work
[18:03] <robru> didrocks, yeah, i have a branch that fixes 3.4-pre
[18:03] <didrocks> you should ~ instead :)
[18:03] <didrocks> and finally, why do you depends on nodejs-legacy?
[18:03] <didrocks> you need the node -> nodejs symlink?
[18:03] <robru> didrocks, because nodejs-legacy is *AWESOME*
[18:04] <robru> didrocks, yes, we need that. the entire cordova upstream uses 'node' in the shebang lines and munging those is *incredibly difficult*
[18:04] <cjwatson> robru: vendor symlinks etc.> dh_linktree might be worth a look, perhaps
[18:05] <didrocks> waow, I never used that one
[18:05]  * didrocks installs
[18:05] <didrocks> thanks cjwatson!
[18:05] <robru> cjwatson, checking, but I'm unlikely to want to change what I have since it was hard to get working ;-)
[18:05] <cjwatson> I don't have enough context to know whether it's appropriate in this case, but I've seen it used in quite a few similar cases, and it specifically gets things like dependencies right
[18:06] <robru> cjwatson, well the first line of the manpage says it creates symlink trees of files from other packages, that doesn't seem appropriate. what I have is a pile of files *in my own package* that I'm shuffling around, but then need to symlink back to their original locations
[18:06] <cjwatson> Ah, I see
[18:06] <didrocks> robru: I think you have enough to lookg for/explores, I'll give another look once those are done, nothing else makes my eyes bleeding for now :)
[18:06] <robru> cjwatson, thansk though
[18:07] <didrocks> we should check if the other npm modules are shipped in packages though
[18:07] <cjwatson> I assumed that some of ... yeah, that
[18:07] <didrocks> or the security team will eyebrown for sure ;)
[18:07] <robru> didrocks, you can't fight npm! they just vendor everything! IT'S THE WAY OF THE FUTURE!
[18:08] <robru> didrocks, http://24.media.tumblr.com/6787481b692cfde31d3dda9448d44ea5/tumblr_mrcqmvLqsA1ritc83o1_500.gif
[18:08] <didrocks> robru: ahah, with so *natural* blue eyes, it's even more suspicious!
[18:09] <didrocks> robru: more seriously, those modules worth a check if they are packaged already
[18:10] <robru> didrocks, ok more seriously though, npm has this really delicate dependency chain. doesn't matter if those modules are packaged because they'll likely be the *wrong* versions. npm is very fussy about that. in some cases we ship two different versions of the same module because different modules depend on different things.
[18:10] <didrocks> robru: I guess it worths then that you discuss with the security team about that (it's similar to our python issue)
[18:11] <didrocks> interesting a node module for lru-cache. /me adds to his basket
[18:11] <robru> heh
[18:44] <robru> seb128, you got silos 3 and 6, please build
[18:44] <seb128> robru, thanks
[18:44] <robru> seb128, you're welcome
[19:26] <robru> boiko, you got silo 2, please build
[19:26] <boiko> robru: thanks
[19:26] <robru> boiko, you're welcome!
[20:01] <balloons> found this testing image 200; https://bugs.launchpad.net/indicator-sound/+bug/1283191
[20:01] <robru> boiko, you got silo 12, please build.
[20:02] <boiko> robru: nice, thanks!
[20:02] <robru> boiko, you're welcome!
[20:04] <xnox_> can sillos have direct uploads into them (or src copies from other ppa) to land non-train things together  ci-train things?
[20:05] <robru> xnox_, only if the source package name was specified when the silo was configured.
[20:05] <xnox_> robru: ok, thanks.
[20:07] <robru> xnox_, (the silo can be reconfigured to have that if you need it after the fact)
[20:07] <xnox_> robru:  ok.
[20:49] <fginther> robru, how are the cu2d daily release jobs still used? Are the autopilot tests that run there still meaningful?
[20:50] <robru> fginther, uh. IIRC we are only using those for saucy SRUs at this point. 'head' stack should not be used.
[20:52] <fginther> robru, we're discussing a change to enable python3 autopilot tests, but if autopilot-trusty-daily_release is defunct, that would save us a pile of wokr
[20:52] <robru> fginther, i can't say for sure, you'll have to consult didrocks. but my understanding is that daily_release is verboten, everything should be on citrain now.
[20:53] <fginther> robru, thanks, I'll try to follow up with didrocks on Monday
[20:55] <robru> fginther, ok
[21:05] <plars> balloons: robru: looks like there's a bug with rssreader causing install to fail in CI
[21:05] <plars> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/70/console
[21:06] <balloons> plars: ahh, this is fallout from the rename. It should be nabbing lp:ubuntu-rssreader-app not lp:shorts-app
[21:07] <plars> balloons: yeah, it needs to be fixed in the click manifest I believe
[21:07] <robru> balloons, any reason it can't just be moved to lp:shorts-app? would be more consistent
[21:07] <plars> balloons: I'm guessing that means we're going to need to rename the test also (doing that won't fix this problem though)
[21:08] <plars> robru: +1 that seems much nicer
[21:09] <balloons> plars: robru not sure how easy it is to move, I don't believe we've change the lp branch anywhere even when these have gone on
[21:10] <robru> balloons, well, i've renamed things in the past, you just have to register the new lp project name, then push lp:ubuntu-rssreader-app to lp:~team/shorts-app/trunk, then go to the project and configure lp:shorts-app to point at the new trunk.
[21:12] <plars> actually, to get us past this, all we'd need is lp:shorts-app to contain trunk, nothing official. But if it's not going to be the official branch eventually, then it would just cover this up temporarily.  But meanwhile, it blocks *all* testing on the touch image
[21:12] <balloons> sounds like a good idea; but it's not something I am keen to do on a friday afternoon with no one about
[21:12] <plars> because phablet-click-test-setup fails on this during install
[21:12] <plars> balloons: well, on the downside, we have no results in ci until it's fixed
[21:13] <plars> alternatively, we could pull shorts-app and replace it with the pre-renamed version
[21:20] <balloons> plars: give me a second to go down the lp:shorts-app road
[21:21] <plars> balloons: cool, thanks
[21:31] <fginther> balloons, I'll need to update the jenkins config too for MPs, please let me know when it's ready
[21:32] <balloons> fginther: plars don't get too excitied; I'm not changing it today no matter what. I'm gathering concensus on whether or not we would plan to change it. I think that affects our decision for how to deal with it
[21:32] <fginther> ok, I'll turn off the sirens
[21:33] <balloons> that said, I'm confused why the project_name has to be equal to the branch in lp?
[21:33] <balloons> so I can't have a project_name = my-cool-project with a branch of lp:something-else
[21:33] <fginther> balloons, is it the manifest that is pointing to lp:shorts-app?
[21:34] <fginther> balloons, it appears cmake is doing it
[21:34] <xnox_> balloons: you can have any branches you like, but when building the click the x-source tag should have correct branch name that exists.
[21:35] <xnox_> balloons: at the moment the declared branch in the click is lp:shorts-app, and testing tries to pull tests from there.
[21:35] <balloons> fginther: xnox_ ahh.. so it broke because of cmake.. well, I would say that is the quick fix then
[21:35] <xnox_> balloons: but allas that doesn't exist.
[21:35] <xnox_> balloons: so i think in cmake you pass the branch, or just replace variable in cmake/manifest.json.in
[21:35] <xnox_> balloons: to a real branch for now.
[21:36] <xnox_> balloons: it's a one-liner, do you want me to push a branch?
[21:36] <balloons> xnox_: if you have the branch handy, go for it
[21:36] <sergiusens> no no
[21:36] <balloons> sergiusens: ?
[21:36] <sergiusens> balloons, xnox_ if you change it, change it here: https://code.launchpad.net/~sergiusens/ubuntu-rssreader-app/lp_source/+merge/207745
[21:36] <sergiusens> not in the manifest
[21:36] <sergiusens> t
[21:37] <balloons> lol, it would be an mp to trunk
[21:37] <sergiusens> if you rename the project, that's fine as well
[21:37] <xnox_> sergiusens: ah, you are faster =)
[21:37] <sergiusens> balloons, no I mean, look at where the change is ;-)
[21:37] <xnox_> balloons: sergiusens: reviewed and approved.
[21:38] <sergiusens> xnox_, you have those powers?
[21:38] <balloons> sergiusens: yes I think we will rename, but not today at friday afternoon :-) We'll tackle it next week. Just need to get the tests runnning
[21:38] <xnox_> sergiusens: muahahaha =)
[21:38] <sergiusens> :-)
[21:38] <balloons> perfect sergiusens you are quick
[21:38] <sergiusens> I don't :-P
[21:38] <balloons> sergiusens: yes, I would have changed the cmakelist file
[21:39] <sergiusens> great; because I read manifest.json :-)
[21:39] <sergiusens> wanted to avoid derailings
[21:40] <balloons> I can't speak for xnox, but that was the exact line my brain went to when you mentioned cmake :-)
[21:40]  * sergiusens goes back to figuring out why a=$(mktemp); echo $a prints nothing
[21:41] <xnox_> balloons: please release that branch from sergiusens somehow. or handover to somebody who can.
[21:41] <xnox_> i'm eod
[21:41]  * balloons added commit message so jenkins doesn't fail it
[21:41] <balloons> xnox_: yep, I'll finish it
[21:42] <sergiusens> ah, the eternal request; if commits in branch == 1 -> use as commit message
[21:53] <ralsina_> robru: can I get a silo for row #27 please?
[21:54] <robru> sure
[21:54] <robru> ralsina_, ok you got silo 14.
[21:55] <ralsina_> robru: thanks
[21:55] <robru> ralsina_, you're welcome!
[21:56] <robru> boiko, i just published silo 12, please merge & clean once it hits distro
[21:58] <boiko> ok, I have an appointment now, but in ~3h I'll be back and then I can merge&clean it
[21:58] <robru> boiko, ok no worries thanks
[22:10] <balloons> plars: so the cmake change to fix the rssreader tests from running is in trunk
[22:10] <plars> balloons: ok, so we just need someone to push it through for 201 then?
[22:11] <balloons> plars: yes, so I'll get it pushed through.. you still held up?
[22:12] <plars> balloons: not much I can do about it
[22:16] <balloons> plars: it's building away :-)
[22:17] <plars> balloons++
[22:23] <robru> alright, i'm gonna take (a quite late) lunch, if anybody needs me i'll be back in an hour.
[22:31] <xnox_> do we have weekend coverage for ci?
[22:31] <xnox_> especially ci-train landings?
[22:33] <ogra_> xnox_, thats a good topic to bring up next week ... (no we dont i think)
[22:33] <xnox_> ogra_: i guess dput still works.
[22:33] <xnox_> ogra_: what's next week?
[22:33] <ogra_> xnox_, i'll forward it to the landing team on monday in the meeting
[22:34] <ogra_> (yes, dput indeed works but kind of breaks the concept indeed ... the concept needs fixing if we want to make it the default)
[23:06] <balloons> plars: so the build is failing tests; checking that out now
[23:55] <ralsina_> robru: can I get a reconfigure in silo 14? I got a branch resubmitted
[23:56] <robru> ralsina_, sure
[23:56] <robru> ralsina_, is the spreadsheet updated?
[23:56] <ralsina_> yessir
[23:56] <ralsina_> I always forget column H
[23:57] <robru> ralsina_, ok, reconfigured
[23:58] <ralsina_> robru: thank you
[23:58] <robru> ralsina_, you're welcome!