[00:01] <doanac> 2) PACKAGES="PACKAGES=python-autopilot autopilot-touch libautopilot-qt libautopilot-gtk python-gi ubuntu-ui-toolkit-autopilot friends-app-autopilot" ./scripts/run-smoke -P ppa:ci-train-ppa-service/landing-006 -a friends_app
[00:01] <doanac> thomi: ^ that's a simplified version of whats running, but should be a little quicker and still result in the unlock_screen failures
[00:02] <thomi> ok.. do I really need 'PACKAGES=' twice?
[00:02] <doanac> thomi: oops -typo
[00:02] <doanac> just once
[00:02] <thomi> ok :)
[00:02] <thomi> will that flash my device?
[00:02] <doanac> yes.
[00:02] <thomi> cool - will give that a whirl
[00:04] <thomi> doanac: ERROR: NETWORK_FILE, /home/ubuntu/magners-wifi, not found
[00:05] <doanac> ah - you have to specify the "-n <path to your network-manager wifi config>"
[00:05] <doanac> sorry
[00:05] <thomi> where is that?
[00:05] <thomi> in /etc somewhere?
[00:05] <doanac> thomi: /etc/NetworkManager/system-connections/<your ap name> I think
[00:06] <thomi> doanac: run-smoke doesn't have an -n option, or any network-related options AFAICS
[00:08] <doanac> thomi: apologies. i've been rushing. you have to set NETWORK_FILE=.... in your environment
[00:09] <thomi> ahh ok
[00:09] <doanac> i was about to leave for the day and am not being helpful.
[00:09] <thomi> no worries
[00:10] <thomi> well, it's downloading things, so that's a good start
[08:12] <thostr_> sil2100: didrocks: is the ci spreadsheet broken?
[08:12] <didrocks> thostr_: I'm seeing 2 ERRORS, not sure what was done yesterday though
[08:12] <didrocks> thostr_: anything else you note?
[08:13] <thostr_> well, I'm just wondering what silo 1 and 3 is right now?
[08:13] <thostr_> can I click merge and clean there?
[08:15] <didrocks> thostr_: interestingly, if I copy the spreadsheet, there is no more timeout
[08:15] <didrocks> like https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dDFGQ1dGNmR1Qy04YmxWQ0pwTEszdEE#gid=1
[08:15] <didrocks> (yeah, you can clean the silo anyway)
[08:21] <Mirv> didrocks: welcome, did you recover well?
[08:21] <didrocks> Mirv: hey! yeah, still catching up though, but everything's fine. How was your flight back?
[08:22] <Mirv> sil2100 should be able to fill in the problems of yesterday and what he tried with those
[08:22] <Mirv> didrocks: excellent, I didn't even get redirected to Sweden or anything. there was a risk of that because of extreme fog.
[08:22] <Mirv> that'd have ruined the weekend, but now instead I could actually spend a weekend :)
[08:23] <Mirv> although the subway took really long, it was good that I left the office 3h before flight
[08:23] <didrocks> oh?
[08:23] <didrocks> no strike at least?
[08:23] <didrocks> (I know they are used to that in that country… hem :p)
[08:31] <Mirv> no strike, this time I even get to eat in the plane unlike the last time when catering was striking
[08:35] <jibel> hi ci-train people, http://162.213.34.102/job/landing-002-1-build/26/console says it committed r134 and it looks successful to me, now what needs to be done to have r134 really pushed to trunk where it is still r131?
[08:36] <didrocks> jibel: they need to have it published and then click on merge and clean
[08:36] <didrocks> jibel: this is up to the lander to finish the transaction that way
[08:37] <didrocks> jibel: on that case, this one is not even published
[08:37] <jibel> didrocks, I don't understand, publish what to where? which click on merge and clean?
[08:38] <jibel> didrocks, there is nothing that can be done until Bill wakes up?
[08:38] <didrocks> jibel: this is exactly why we teach people how to use CI Train :)
[08:38] <didrocks> jibel: yeah, he even didn't test the build, so it's not in distro
[08:38] <didrocks> (and so, not in trunk)
[08:39] <jibel> hm, well integration doesn't seem really continuous :/
[08:39] <jibel> I'll wait for him then
[08:39] <didrocks> jibel: trunk == ubuntu
[08:39] <didrocks> this is the CI Train
[08:39] <didrocks> as long as it's not in ubuntu
[08:39] <didrocks> it's not in trunk
[08:41] <jibel> didrocks, give it the definition you want, but the thing is that we are blocked until this rev is in trunk because conflicts cannot be resolved without last rev
[08:41] <jibel> anyway...
[08:42] <didrocks> jibel: maybe checking why the tests didn't pass for bfiller (and so avoiding having the trunk broken) would be a first step
[08:43] <didrocks> rather than "continously breaking trunk, even if tests don't pass"
[08:46] <jibel> didrocks, np, I'll check with Bill
[08:47] <didrocks> thostr_: have you run M&C finally (you didn't answer)?
[08:47] <thostr_> didrocks: sorry, yes I did the M&C
[08:47] <didrocks> ok, thanks thostr_
[08:47]  * didrocks starts to be frightened by the google times out
[08:59] <Mirv> oh, right, I need to flash back to Qt 5.0.2 since I heard a rumor I'll be releasing ubuntu-ui-toolkit today :)
[09:00] <Mirv> didrocks: can you evaluate if ^ that can be added to the landing plan? apparently bzoltan had heard from ogra that I'll handle it.
[09:01] <didrocks> Mirv: let's discuss that in ~30 minutes? they are green to release today?
[09:02] <ogra_> err what ?
[09:02] <ogra_> i told zoltan that i would mention his landing in the meeting ...
[09:02] <ogra_> nothing more
[09:02] <ogra_> your name was never mentioned
[09:04] <didrocks> interesting deformation of infos ;)
[09:07] <Mirv> didrocks: ok. they're green from their point of view and have reportedly run a lot of AP tests too. I'd naturally rerun all.
[09:07] <Mirv> let's discuss it in the meeting, meanwhile I'm preparing my phone
[09:07] <Mirv> ogra_: :D
[09:07] <ogra_> :)
[09:23] <didrocks> thostr_: you're right, someone broke the spreadsheet, looking deeper
[09:23] <didrocks> (btw, your scopes landing is in NEW I guess)
[09:24] <sil2100> didrocks: we had some strange problems with the spreadsheet yesterday already
[09:25] <didrocks> sil2100: seems someone changed data validation first on the pending spreadsheet, I wonder if not other things were changed
[09:25] <sil2100> didrocks: like, google was offsetting all rows by 1 once, then we reached the limit of number of landings, then something else etc.
[09:26] <didrocks> I guess there was a bad copy/paste
[09:26] <didrocks> I would have maybe to lock down the cells
[09:26] <didrocks> but then, results will be unreadable :/
[09:27] <didrocks> getSiloMatrixRange() returns null
[09:27] <didrocks> weird
[09:27] <didrocks> did someone touched the metadata spreadsheet?
[09:28] <sil2100> didrocks: I didn't, although I was hiding unhiding it when looking for things
[09:28] <sil2100> didrocks: but essentially I had nothing to change in the metadata spreadsheet
[09:28] <didrocks> ss.getRangeByName("siloMatrix"); returns null… why?
[09:29] <sil2100> didrocks: all I did is change the other 2 ranges that were defined
[09:29] <didrocks> the range name still exists though…
[09:29] <didrocks> 2 ranges?
[09:29] <sil2100> didrocks: to increase the number of rows being considered in the main spreadsheet
[09:29] <didrocks> ah, don't change the range
[09:29] <sil2100> SiloAssignment and PendingUID
[09:29] <didrocks> just expand a blank line
[09:29] <didrocks> that should consider everything
[09:30] <sil2100> Well, someone was adding new landings and things weren't working ;p
[09:30] <sil2100> Since the range didn't expand and things were broken
[09:30] <didrocks> interesting, all formulas changed
[09:30] <didrocks> not sure, someone really changed something :p
[09:30] <didrocks> ok, I'll need to look
[09:30] <didrocks> in the call in 2 minutes
[09:32] <didrocks> hum
[09:32] <didrocks> didn't get the link
[09:32] <sil2100> https://plus.google.com/hangouts/_/calendar/Y2Fub25pY2FsLmNvbV91cTRvNmQyMWJvNmJ0bm1mcW9xZWtsNTdnOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.us2orfbhb8ssqjui2u15tajj3s
[09:32] <sil2100> ;)
[09:33] <didrocks> thx!
[09:54] <seb128> Laney, plars: btw, I talked to thomi yesterday, he found the issue with u-s-s/u-d-m/utf/autopilot and he fixed it (just confirmed that the current version in the landing silo works), that was another bug that the one fixed earlier
[09:54] <seb128> the log was coming from syslog
[09:54] <Laney> seb128: woot
[09:55] <seb128> not stdout/stderr
[09:55] <Laney> a missing decode somewhere else then?
[09:55] <seb128> Laney, http://bazaar.launchpad.net/~thomir/autopilot/trunk-fix-non-unicode-app-output/revision/429
[09:55] <seb128> that's the fix
[09:55] <Laney> O_O
[09:56] <seb128> Laney, the fix was added to https://code.launchpad.net/~thomir/autopilot/trunk-fix-non-unicode-app-output/+merge/205522
[09:56] <seb128> that might have more context ;-)
[09:57] <bzoltan> hello gents ... I have heard that somebody had an idea not to release the UITK :)
[09:57] <seb128> Laney, mandel also said he has a landing pending which fixes the service outputing non unicode chars in the logs
[09:57] <bzoltan> didrocks^
[09:57] <seb128> so it should be fixed for good
[09:58] <Laney> seb128: cool, hopefully we can get them in soon
[09:58] <didrocks> bzoltan: we can do it on Monday
[09:58] <didrocks> once you are bootcamped
[09:58] <bzoltan> didrocks: too late
[09:59] <didrocks> so that you are self-servicing
[09:59] <didrocks> bzoltan: how too late? you didn't release for 2 months
[09:59] <bzoltan> didrocks: I need the UITK this week
[09:59] <didrocks> and now, you need to release in the 2 days?
[09:59] <bzoltan> didrocks: that is past, now is now
[09:59] <bzoltan> didrocks: I need it today
[09:59] <didrocks> bzoltan: this is quite an assertion
[09:59] <didrocks> bzoltan: without any first-notice
[10:00] <didrocks> you know that people prepare their landings
[10:00] <didrocks> and ask for it
[10:00] <bzoltan> didrocks: I did prepare and I did ask
[10:00] <didrocks> not sure why uitk needs something *NOW*
[10:00] <didrocks> bzoltan: when, and where?
[10:00] <bzoltan> didrocks: in the landing asks?
[10:00] <didrocks> when?
[10:00] <bzoltan> didrocks: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc&usp=drive_web#gid=1
[10:01] <didrocks> sorry to repeat, but when?
[10:01] <bzoltan> didrocks: sorry.. I have checked the doc history -> Feb 10, 4:00 pm EET
[10:01] <didrocks> ok, so 1 day and half ago
[10:02] <popey> didrocks: #176 dogfooding done, looks good
[10:02] <bzoltan> didrocks: yes ... a
[10:02] <didrocks> popey: \o/
[10:02] <didrocks> bzoltan: that's quite ackward, we have to do a lot of work for you, any reason you need it asap?
[10:02] <didrocks> and not Monday?
[10:04] <bzoltan> didrocks: because for the app Showdown  the SDK need to be released this week
[10:04] <didrocks> sad that was really not planned in advance
[10:04] <didrocks> and we have to rush 2 months of work
[10:04] <didrocks> bzoltan: I'm happy to help you release it asap even if you are not transitioned, but please coordinate in the future with both asac and pat so that this ackward situation doesn't reproduce again.
[10:04] <didrocks> bzoltan: however, I'll ask you doing the testing
[10:04] <didrocks> if Mirv has some free slots
[10:05] <bzoltan> didrocks: I do not find the situation awkward
[10:05] <didrocks> which is unsured
[10:05] <ogra_> bzoltan, are you prepared for nightshifts in case it gets decided to rip it out again because it has failures ?
[10:05] <didrocks> bzoltan: I do find it horrible, you are not the only one busy
[10:05] <didrocks> we are as well
[10:05] <bzoltan> ogra_: you can see the test output attached to the landing ask from Monday
[10:05] <didrocks> bzoltan: yeah, you will have to rerun the tests though with the final products
[10:05] <bzoltan> didrocks: I am sorry
[10:06] <ogra_> bzoltan, if it has failures or regressions inm real life, the order from asac is to rip out the landing, have it fixed and to land it again
[10:06] <bzoltan> didrocks: no prblems with any sort of testing. I am here to do any kind of work needed at any time
[10:06] <asac> so why dont we go through CI train with this?
[10:06] <bzoltan> ogra_: whatever it takes :)
[10:06] <ogra_> bzoltan, you should really plan a week at least for landing such a big thing the next time
[10:06] <bzoltan> asac: do we have the CI train?
[10:06] <didrocks> asac: I propose that sil2100 or Mirv to "push buttons"
[10:06] <Mirv> bzoltan: didrocks: I'm taking time off from Qt 5.2 to run all tests against the new UI Toolkit. the only potential problem so far (if all AP:s pass) is that cu2d shows a lot of failures on desktop side, but maybe there's something wrong with cu2d/autopilot/daily-buildPPA
[10:06] <didrocks> having bzoltan running the tetss
[10:07] <didrocks> and then we publish for them
[10:07] <bzoltan> ogra_: we had a Sprint last week ...
[10:07] <asac> didrocks: also fine
[10:07] <ogra_> asac, Kaleo told me he doesnt want to ... i guess you need to convince him
[10:07] <asac> doesnt want to do what?
[10:07] <asac> not land?
[10:07] <asac> :)
[10:07] <ogra_> bzoltan, we do sprints too :)
[10:07] <Mirv> I do like to see device AP tests with my own eyes, and it mostly just takes away my device for a bit to assure of that
[10:07] <ogra_> bzoltan, thats no reason to not warn the landing team in advance
[10:07] <Mirv> bzoltan: didrocks: it's good anyhow that SDK Team is assuring to have made tests on their own
[10:08] <bzoltan> ogra_: I know :)
[10:08] <asac> did you guys test the binaries that are in the daily-build ppa?
[10:08] <asac> bzoltan: ?
[10:09] <ogra_> asac, kaleo said the MP tests that run during merges would be enough for him
[10:09] <ogra_> seems they run some AP tests there or some such
[10:09] <asac> ogra_: sure, but thats not enough to land
[10:09] <asac> so he can deliver into trunk, but not image
[10:09] <ogra_> i tried to tell him ... but it was late and i gave up at some point :)
[10:09] <bzoltan> asac: I tested against the devel-proposed image on nexus4
[10:09] <asac> bzoltan: but which .debs did you install?
[10:09] <asac> bzoltan: where did you take them from?
[10:10] <bzoltan> asac: what deps?
[10:10] <asac> debs
[10:10] <asac> debian packages
[10:10] <bzoltan> asac: I flashed the device...I did not take any debs... only the UITK deb
[10:10] <asac> bzoltan: where from?
[10:10] <asac> :)
[10:10] <asac> where did you download that UITK deb from
[10:10] <bzoltan> asac: https://launchpad.net/~ubuntu-sdk-team/+archive/testing
[10:11] <asac> bzoltan: if your stuff is in trunk, the right debs are in the daily-unity ppa
[10:11] <Mirv> the current toolkit in daily-build is https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3907912/+listing-archive-extra - I also now cancelled the next run (no changes in bzr trunk) so that those deb:s stay
[10:11] <bzoltan> asac: I made a source package, dput it there and installed on the device
[10:11] <didrocks> anyway
[10:11] <didrocks> so what I propose
[10:11] <didrocks> we assign bzoltan a silo
[10:11] <didrocks> build for him
[10:11] <asac> anyway, let didrocks explain
[10:12] <asac> right
[10:12] <didrocks> then, he can test all AP running
[10:12] <didrocks> turn it to yes once ok
[10:12] <didrocks> and we publish
[10:12] <didrocks> this is for this time
[10:12] <asac> also manual testing the device :)
[10:12] <didrocks> and we'll track
[10:12] <didrocks> yeah
[10:12] <asac> basic smoke tests
[10:12]  * Mirv takes a note and goes back to qt 5.2
[10:12] <didrocks> Mirv: can you add a line for bzoltan?
[10:12] <didrocks> we'll need an empty MP to flush trunk
[10:13] <Mirv> didrocks: ok
[10:13] <didrocks> Mirv: don't assign yet, let me debug the issue on the spreadsheet first
[10:13] <didrocks> thanks!
[10:14] <didrocks> ok, spreadsheet fixed
[10:14] <didrocks> rerunning the script, thanks google :)
[10:16] <cking> hi, is there any reason why the boot speed tests don't seem to have been updated since last year? http://ci.ubuntu.com/bootspeed/arch/amd64/
[10:18] <vila> cking: (use cihelp to raise ci team awareness i, I almost missed your query ;) No, I don't think that's expected, let me check some bits
[10:18] <asac> cking: yeah, its operationally hard for us to ensure those happen until the overall success/fail gets fed into the main dashboard (if you remember that discussion)
[10:19] <asac> same as with mem event etc.
[10:19] <asac> ev had taken that on during core sprint
[10:19] <asac> think he is back tomorrow
[10:19] <cking> asac, ok, thanks
[10:19] <vila> cking: asac knows more than me :-}
[10:20] <asac> cking: just ping him tomorrow so we ensure this didnt get dropped
[10:20] <cking> asac, i'll add it to asana
[10:20] <asac> yeah
[10:20] <asac> thats good
[10:20]  * asac still isnt really good at asana
[10:20] <cking> it can be a pain, but it's OK once one gets the hang of it
[10:20] <vila> cking: paste me the url when you're done
[10:21] <bzoltan> didrocks: are we done? Is there anything I need to do to help landing the UITK?
[10:21] <vila> asac: thanks for stepping up
[10:22] <bzoltan> didrocks:  I am running all the available app autopilot tests right now
[10:22] <ogra_> bzoltan, read the backlog ?
[10:23] <Mirv> bzoltan: you need to wait there's a landing PPA you can test from
[10:23] <Mirv> it will be (as an example) https://launchpad.net/~ci-train-ppa-service/+archive/landing-004
[10:24] <bzoltan> Mirv: how different it will be from the PPA we land the UITK now?
[10:24] <bzoltan> Mirv: Whatever... I am fine with  it
[10:24] <thostr_> didrocks: ooops, just setting testing to green (combobox) gave me "The action you're trying to perform is causing a fatal error and cannot be performed."
[10:26] <Mirv> bzoltan: it's different in the way that it's an ensured version that will be directly copied to the archives when ready
[10:26] <Mirv> didrocks: so now a fake merge against UI toolkit?
[10:27] <cking> vila, I added you onto the follower of that task, you will get automatic emails. I can't figure out how to share the URL (bah, asana)
[10:27] <vila> cking: just copy/paste it
[10:27] <vila> cking: but it's ok, I got it via notifications
[10:30] <Mirv> sil2100: was empty merge enouh, was it tested, or do I need to do some whitespace change? https://code.launchpad.net/~timo-jyrinki/ubuntu-ui-toolkit/trunk_bzr935/+merge/205925
[10:31] <didrocks> Mirv: yes please
[10:31] <didrocks> thostr_: yeah, something is broken in the spreadsheet, I'm looking at it. it was in which landing?
[10:32] <sil2100> Mirv: empty is enough ;)
[10:32] <didrocks> bzoltan: you will need to rerun all the AP test with the debs that we'll provide to you + dogfooding
[10:32] <didrocks> bzoltan: and ensure that there is no failure
[10:32] <didrocks> bzoltan: we'll keep you posted
[10:32] <bzoltan> didrocks: thanks, i will do that
[10:34] <Mirv> didrocks: the line 77 would need some love so that the status formula would work (and I guess line 76 too)
[10:35] <sil2100> Mirv: we're fighting the spreadsheet right now
[10:35] <Mirv> sil2100: ok, I'll wait, thanks
[10:35] <Mirv> sil2100: and yes thanks, empty merge it is then :)
[10:43] <psivaa> didrocks: so, maguro reruns still have failures, but different ones than earlier one and 175. error/fail count is also confusing.
[10:44] <psivaa> i'll let doanac know about that
[10:44] <didrocks> psivaa: ok, so usual apps not starting you think on the failures?
[10:46] <psivaa> didrocks: not sure. i think it was a qmlscene crash that was causing the apps not to start. but this crash has now been fixed. so not sure why the failures are
[10:53] <didrocks> psivaa: I explained that qmlscene crash was a consequence
[10:53] <didrocks> not the cause
[10:53] <didrocks> psivaa: we still need to know why some apps are not starting sometimes
[10:56] <psivaa> didrocks: ok, the logs dont say anything about apps failing to start:
[10:56] <psivaa> http://ci.ubuntu.com/smokeng/trusty/touch/maguro/176:20140212:20140115.1/6553/address_book_app/761857/
[10:57] <didrocks> psivaa: can you check with osomon by any chance? maybe he would have an idea
[10:58] <psivaa> didrocks: ack
[10:58] <didrocks> thanks!
[10:58] <didrocks> davmor2: please dogfood latest image on mako :)
[10:59] <didrocks> maguro*
[11:06] <ogra_> both !
[11:06] <ogra_> :P
[11:08] <psivaa> balloons: could you take a look at the clock app failures on maguro pls: http://ci.ubuntu.com/smokeng/trusty/touch/maguro/176:20140212:20140115.1/6553/ubuntu_clock_app/
[11:09] <psivaa> renato_:  could you take a look at the clock app failures on maguro pls: http://ci.ubuntu.com/smokeng/trusty/touch/maguro/176:20140212:20140115.1/6553/address_book_app/
[11:10] <psivaa> didrocks: for unity8, osomon said to contact Saviq, who does not seem to be online
[11:10] <thostr_> didrocks: that was landing silo 10 but now it seems to work again
[11:13] <didrocks> psivaa: sure
[11:13] <didrocks> thostr_: yeah, all should be good spreadhseet-wise
[11:13] <didrocks> (well, we have some backend warning from google, weird)
[11:13]  * sil2100 is scared of the spreadsheet
[11:19] <popey> hmm, getting this again http://popey.com/~alan/phablet/device-2014-02-12-111914.png
[11:23] <davmor2> didrocks: welcome back
[11:24] <davmor2> didrocks: I'm kinda stuffed for mako at the minute because it is being used for the 4.4.2 testing I can test the latest on maguro though?
[11:26] <didrocks> davmor2: popey did the mako testing, maguro is enough
[11:27] <asac> so something is noisy on our images since yesterday
[11:27] <davmor2> didrocks: cool I was playing with 175 with the nested mir on it last night it seems to all be working but I'll grab the latest now
[11:27] <asac> settle showing up here and there
[11:28] <popey> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1279298  technically a regression since 174
[11:30] <ogra_> asac, yes, seems unity-system-compositor keeps a few cycles after testing, i'll talk to kgunn once he shows up so his team can take a look
[11:30] <ogra_> (thought its also indicator-power ... they seem to hand off to each other, looking at the logs)
[11:35] <ogra_> (though here it seems to rather be ofono-phonesim https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/30/artifact/clientlogs/unity8/topafter.log/*view*/)
[11:37] <ogra_> i wonder if it would just need some timout adjustments of the settle_after test since it might take more time to quiet down now
[11:39] <asac> right, but only if we have an explanation i feel
[11:39] <asac> and its confirmed to be a feature
[11:41] <ogra_> well, i wouldnt call it "a feature" :) but its a factthat there is one process more in the graphics layer with nested
[11:42] <ogra_> i wonder if powerd needs adjustment for nested though ... given that indicator-power is one of the three processes i can see in the log keeping the system busy
[11:42] <ogra_> but thats just wild guesswork
[11:46] <asac> didrocks: can you see if and what the autopilot guys did last night? did they manage to flush their silo?
[11:46] <didrocks> asac: they were not published yet
[11:47] <didrocks> asac: we'll do that as soon as we can get back to production
[11:47] <didrocks> debugging o nfire right now
[11:47] <didrocks> (spreadsheet <-> google)
[11:47] <sil2100> Googleeee!
[11:47] <asac> didrocks: ok... spreadsheet problems? i wont bother you then :)
[12:04] <sil2100> asac: yeah, we're trying to resolve it somehow...
[12:05] <cjwatson> w-bi
[12:05] <cjwatson> sigh
[12:06] <cjwatson> (that was a fragment of a shell command eaten by focus stealing, if anyone's wondering ...)
[12:06] <vila> cjwatson: ;)
[12:19] <didrocks> asac: I fear it's a google deployement issue…
[12:22] <asac> grrr
[12:22] <asac> didrocks: whats the issue? nothing works?
[12:26] <didrocks> asac: yeah, it has some very bad side-effects
[12:26] <didrocks> like can't free silos, nothing
[12:28] <davmor2> didrocks:  you looking to promote 176 or did you just want the tyres kicking due to the new mir stuff landing (I'm assuming)
[12:28] <ogra_> davmor2, yes
[12:29] <davmor2> ogra_: you know there are 2 parts to that question :P
[12:29] <didrocks> davmor2: we are looking forward to promote the image
[12:30] <didrocks> but so, that includes evaluating the Mir stuff as well :p
[12:31] <davmor2> didrocks: as a general quick tyre kicking everything looks good although the movement on the system seems slower but nothing has died yet.  And I will start filling in the Spread Sheet now
[12:32] <didrocks> ok
[12:33] <didrocks> asac: even executing a script is slow, it seems they are getting a breakdown, do we have support for that?
[12:36] <didrocks> asac: and everything is working without any error if I copy the spreadsheet
[12:41] <davmor2> popey: can you try this again https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1262711  I've only got 1 album on currently plus some additional tracks and this is working fine for me, I'll double check how many I have in a second and add it to the bug
[12:42] <asac> didrocks: forget about support. we have support, but that doesnt give you anything :)
[12:43] <popey> davmor2: crashes #174
[12:43] <asac> we had that with linaro as well... you can file a support ticket
[12:43] <asac> :)
[12:43] <didrocks> asac: well, I'm stuck for 3 hours into this now, and it really seems to be backend related
[12:43] <didrocks> asac: I don't have any solution/workaround at hand
[12:43] <asac> didrocks: did you try to reset your cookies and get a new IP?
[12:43] <didrocks> asac: it's not just me, it's everyone
[12:43] <didrocks> and the backend scripts in particular
[12:44] <didrocks> waow, the spreadsheet is reverting to older state even
[12:44] <didrocks> like 8 hours ago
[12:44] <asac> ok asking on #is if there is a support escalation path
[12:45] <asac> but i wouldnt hope much. i know what kind of support you get: you can file a ticket and thats it
[12:45] <asac> you can only hope they see statistical indication that there is a problem
[12:45] <davmor2> popey: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1240408 again here this is working for me on Happy(preview from u1Music) and from local music
[12:45] <didrocks> asac: ok, we lost some tickets I guess
[12:45] <didrocks> asac: and I won't continue on this, just hoping this will get fixed
[12:45] <didrocks> Mirv: can you set your ticket in again?
[12:46] <asac> yeah. google usually knows about these things unless its really just us
[12:46] <davmor2> popey: this is on 175 for me
[12:46] <didrocks> asac: I'm more afraid that we lost some status and that doesn't match reality anymore
[12:46] <popey> davmor2: why are you on 175?
[12:46] <davmor2> popey: 176 even
[12:46] <didrocks> which is the case for some already
[12:47] <popey> davmor2: my 176 phone is busy, will test in a mo
[12:47] <davmor2> popey: no worries
[12:47] <Mirv> didrocks: you mean the UITK line that's seemingly removed from CI Train spreadsheet?
[12:47] <asac> didrocks: so making a copy doesnt help you to workaround? thought you said that
[12:47] <didrocks> Mirv: right
[12:47] <ogra_> popey, davmor2, i think i have seen that with some 16* image on maguro
[12:47] <Mirv> ok
[12:48] <didrocks> asac: well, what is lost is already lost, and people are not going to use the new one
[12:48] <Mirv> didrocks: done
[12:48] <davmor2> ogra_: yeah I'm pretty sure it was happening before but on 176 it isn't :)
[12:49] <ogra_> oh
[12:52] <cjohnston> cking, vila afaik bootspeed tests are still owned by the qa team. Max was looking into it.
[12:53] <didrocks> bzoltan: please try https://launchpad.net/~ci-train-ppa-service/+archive/landing-001/ to run all AP tests
[12:53] <didrocks> bzoltan: and some dogfooding
[12:53] <didrocks> that on latest proposed image
[12:53] <didrocks> (176)
[12:53] <didrocks> if all pass, just tell us
[12:53] <didrocks> on mako and a tablet
[12:53] <didrocks> if there is any failure, (even flaky) ensure they are already known
[12:54] <bzoltan>  didrocks: Tablet I do not have, I will use Nexus4
[12:54] <bzoltan> didrocks: thanks for setting up the silo
[12:54] <didrocks> bzoltan: yw
[12:54] <bzoltan> didrocks: do you have a list of AP tests you usually do? I have one good set.
[12:55] <didrocks> bzoltan: all those: http://ci.ubuntu.com/smokeng/trusty/touch/mako/176:20140212:20140115.1/6550/
[12:55] <bzoltan> didrocks: half of them fails on a device test
[12:55] <bzoltan> didrocks: ona stock image
[12:56] <didrocks> bzoltan: this is a stock image on device test
[12:56] <didrocks> bzoltan: you can check with the CI team, but they are testing real things
[12:56] <didrocks> :)
[12:56] <bzoltan> didrocks: started from a desktop with phablet-test-run?
[12:56] <ogra_> following the wiki
[12:57] <ogra_> they use the exact same tests
[12:57] <didrocks> yeah
[12:57] <ogra_> https://wiki.ubuntu.com/Touch/Testing
[12:57] <didrocks> https://wiki.ubuntu.com/Touch/Testing#Testing_your_Ubuntu_Touch_Code_before_submission even! :)
[12:57] <ogra_> yeah
[12:57] <ogra_> details :P
[12:58] <bzoltan> ogra_: didrocks: I did that and 1 out of 4 it fails
[12:59] <ogra_> bzoltan, thats an ubuntu-system image and you did all the described preparation stuff ?
[13:00] <bzoltan> ogra_: I did not disable the edges-intro and used the SDK PPA, but besides that yes
[13:01] <ogra_> did you make the image writable and all ?
[13:01] <ogra_> phablet-config writable-image --ppa ppa:ubuntu-unity/daily-build
[13:02] <davmor2> didrocks: 176 is looking pretty good
[13:02] <didrocks> ogra_: bzoltan: use the right ppa without
[13:02] <bzoltan>  ogra_:  of course ... without RW the tests never start :)
[13:02] <didrocks> (not the daily-build one, the one I pointed above ^)
[13:02] <didrocks> davmor2: great!
[13:03] <bzoltan> didrocks: yes, I got that
[13:03] <didrocks> asac: the spreadsheet is keeping being reverted back
[13:04] <ogra_> didrocks, there is a different PPA ? then the wiki needs updating, i thought the individual tests come from there
[13:04] <bzoltan> ogra_: my ppa is this -> https://launchpad.net/~ci-train-ppa-service/+archive/landing-001/ with the UITK only
[13:04] <ogra_> didrocks, i copy pasted the line from the wiki
[13:05] <didrocks> ogra_: we are using silos, so ppas are dynamic
[13:05] <ogra_> didrocks, again, where do the tests come from ? i thought the line in the wiki is to enable the ppa to pull the autopilot tests for apps
[13:06] <didrocks> ogra_: which tests?
[13:06] <ogra_> # make image RW and reboot; only do this for testing debs, if only testing
[13:06] <ogra_> # click packages this can be skipped.
[13:06] <ogra_> phablet-config writable-image --ppa ppa:ubuntu-unity/daily-build
[13:06] <didrocks> yeah
[13:06] <didrocks> so the --ppa address is now dynamic
[13:06] <didrocks> it's the silo
[13:06] <didrocks> so it depends where your silo are attributed
[13:06] <didrocks> for ci train
[13:06] <ogra_> hmm, i thought the -p option of phablet-test-run always needed that ppa for pulling the packages for the tests
[13:06] <ogra_> but that might have changed
[13:07] <ogra_> in any case someone should update the wiki if thats not the case anymore
[13:08] <ogra_> (it doesnt say anywhere if and why the PPA is needed in that line)
[13:08] <mandel> sil2100, did you manage to get a look at landing udm, is blocking other stuff and people are rushing me :-/
[13:08] <didrocks> ogra_: I would be greatful if someone can explain or document that
[13:08] <mandel> sil2100, not that I want to rush you hehe, such info to let them know
[13:08] <didrocks> not like I'm not rushing since this morning
[13:08] <ogra_> didrocks, well, would be helpful if it was someone who knows about this
[13:09] <ogra_> mandel, a landing usually takes a few days, tell that to the people rushing you :P
[13:09] <didrocks> thostr_: so, as the spreadsheet reverted its state, can you check that there is not "test done" that was reverted for your slots?
[13:09] <didrocks> thostr_: I'm thinking in particular of landing-010
[13:09] <mandel> ogra_, he, will do I needed someone with more authority and knowledge about this to let me know
[13:09] <didrocks> IIRC, it was testing done, as AP
[13:12] <thostr_> didrocks: will check
[13:19] <ogra_> didrocks, sil2100, can we get a silo for mandel ?
[13:19] <popey> davmor2: #176 expanding music still crashes unity
[13:20] <davmor2> popey: cool I might look at adding a track a time and retrying in the mean time I'll make a note on the bug for the number of tracks I have
[13:20] <didrocks> ogra_: who will do the landing for them? they are not trained yet?
[13:20] <ogra_> ah, hmm
[13:21] <ogra_> dunno
[13:21] <ogra_> (i'm not trained either)
[13:21] <didrocks> I can see that, you are not even testing the right ppa :)
[13:21] <ogra_> :P
[13:21] <didrocks> popey: davmor2: so, we do have a blocker?
[13:21] <popey> no
[13:22] <asac> didrocks: if you still want someone to at least escalate to google, please join #is
[13:22] <davmor2> didrocks: no blocker I was checking through the old bugs as went :)
[13:23] <mandel> didrocks, is that landing trained thing related to me?
[13:24] <mandel> didrocks, also I need to get udm to that CI train but I have not had any training or things like that
[13:24] <didrocks> mandel: related to upstream yeah
[13:24] <didrocks> mandel: yeah, will be next Monday for the last wave
[13:25] <mandel> didrocks, ok, do I need to jot my name somewhere?
[13:25] <mandel> didrocks, does that mean no landing of udm in the img 'til monday?
[13:25] <didrocks> mandel: seems it will be ralsina for you: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c&usp=drive_web#gid=0
[13:26] <mandel> didrocks, yes, that I knew, that is why I was surprised :)
[13:26] <didrocks> mandel: yeah, no landing until monday, it's already hard to keep up the current speed, and add to that the google spreadsheet going crazy
[13:30] <didrocks> sil2100: still not back?
[13:42] <plars> vila, cking, asac: bootspeed has known problems that the qa team is working to fix in the test. Same for memevent
[13:42] <cking> plars, what are the "known" problems, 'cos I'm not up to speed with that
[13:43] <plars> vila, cking, asac: at least on the bootspeed front, I did see a recent merge go by that was supposed to improve things, but was not a complete fix
[13:43] <plars> cking: nuclearbob is the best person to talk to on that one, he's the one working on it
[13:45] <plars> cking: I got most of those extra power test runs you wanted squeezed in yesterday, but it looks like one failed oddly on i386. Will investigate shortly, but I need to run my son to school
[13:45] <cking> plars, ok, thanks
[13:45] <plars> cking: just a quick glance looks like some issue with the fluke again
[13:46] <plars> or maybe cobbler
[13:46] <plars> will take a better look when I have more than 30 seconds :)
[13:46] <cking> plars, well, if it's the fluke I can read the man manual and see if there is a way of kicking it into sense
[13:46] <didrocks> thostr_: I'm pretty sure you did test it, I'm publishing for now (I remember from this morning)
[13:46] <didrocks> (it was the hud)
[13:47] <thostr_> didrocks: yes, test was green for hud
[13:47] <didrocks> ok doing the publication
[13:47] <didrocks> autopilot first
[13:47] <didrocks> then, the hud
[14:01] <sil2100> I'm here, just had some problems around - what's up? How can I help?
[14:01] <sil2100> Tell me what to land and I'll do that, while fighting here at home as well
[14:02] <sil2100> asac, didrocks: ^ at your service, should I land things?
[14:03] <didrocks> sil2100: so, I landed AP (the test status was reverted by the spreadsheet, but I think that was tested)
[14:03] <didrocks> sil2100: I'm rebuilding the hud, just for the changelog sake
[14:03] <didrocks> as we got the fix
[14:03] <didrocks> it needs landing then
[14:03] <sil2100> Ok
[14:04] <didrocks> I guess, it's high time to assign silos though
[14:04] <sil2100> Doing in 5 min
[14:04] <didrocks> for some, like kgunn's one, I just added comments
[14:04] <didrocks> (we have branches instead of MPs)
[14:05] <kgunn> didrocks: sil2100 ...ack, you want the lp:
[14:05] <kgunn> instead ?
[14:06] <didrocks> kgunn: we want the https://code.launchpad…/+merge/<id>
[14:06] <didrocks> as in all other cells
[14:06] <kgunn> didrocks: sorry
[14:07] <didrocks> kgunn: no worry, feel free to remove my comment once fixed!
[14:14] <om26er> sil2100, Hey! any news on ubuntu-integration-tests ?
[14:17] <sil2100> om26er: give me a moment
[14:19] <sil2100> kgunn: give me a sign once the MPs are fixed ;)
[14:20] <kgunn> sil2100: ack
[14:23] <didrocks> sil2100: you can assign others meanwhile, let's try one?
[14:23] <didrocks> sil2100: like click scope into CI, was it removed from cu2d?
[14:24] <sil2100> didrocks: I'm doing the old thostr_ one now, but I need to disable some projects from cu2d
[14:24] <sil2100> Since some are still not disabled
[14:25] <didrocks> sil2100: ok, I'm doing robru's one to check the sync back
[14:25] <didrocks> at least, the association worked
[14:25] <sil2100> phew...
[14:26] <didrocks> let's see if the sync worked
[14:26] <didrocks> yeah
[14:26] <didrocks> sil2100: seems only the removal doesn't work now
[14:28] <sil2100> ;/
[14:28] <didrocks> sil2100: oh, I'm running the backend manually and no error
[14:28] <sil2100> What?!
[14:29] <didrocks> and I can show/hide column without any error either
[14:29] <didrocks> asac: seems the transiant issue is gone ^
[14:29] <sil2100> That's bullshit, maybe indeed something on google side?
[14:29] <didrocks> and was really… google-side
[14:29]  * didrocks lost 5h30 of his life :p
[14:31] <didrocks> and the "last edit" is now sensible again
[14:31] <didrocks> tsdgeos: FYI ^ we can hope to not have spreadsheet rollback
[14:32] <tsdgeos> that'd be nice
[14:32] <sil2100> :|
[14:32] <didrocks> bfiller: hey, you are aware that on two of your requests, the Ready? is set to know
[14:32] <didrocks> no*
[14:32]  * sil2100 lost only 2.5h of his life, not so bad!
[14:32] <didrocks> sil2100: at least, you know a little bit more how the code works on the backend…
[14:33] <didrocks> bfiller: also, landing-002 isn't tested yet, it's on purpose?
[14:34] <sil2100> Indeed! I already had some fun looking at it yesterday, and it's really smart - just fragile
[14:34] <bfiller> didrocks: it's on my list, haven't had time to do my release engineering tasks yet
[14:34] <didrocks> bfiller: ok, was just checking as the process is still quite new that it was on purpose. No rush!
[14:34] <bfiller> didrocks: :)
[14:39] <didrocks> ogra_: did you get more infos on u-s-c?
[14:39] <ogra_> didrocks, not yet, no, i have to run some errands (back in ~1h) and will then take care of that
[14:40] <didrocks> ok
[14:43] <didrocks> thostr_: hud published
[14:43] <thostr_> didrocks: excellent, thanks
[14:43] <didrocks> yw
[14:44] <didrocks> thostr_: published == I push the published button, not "it's in the release pocket"
[14:44] <didrocks> (but no worry, you have my funny message now :p)
[14:44] <thostr_> didrocks: ok
[14:45] <sil2100> ;)
[14:45]  * sil2100 configures a silo for thostr_ 
[14:45]  * sil2100 crosses fingers
[14:46] <sil2100> geh, it simply works now indeed!
[14:46] <sergiusens> sil2100, can you silo me row 78
[14:46]  * didrocks registers tosilo.com
[14:48] <sil2100> sergiusens: ;) Sure, let me take a look
[14:48] <sil2100> Looks safe, let me assign
[14:49] <sil2100> sergiusens: silo is being prepared, you can build in a moment
[14:50] <sergiusens> ty
[14:51] <sil2100> kgunn: so, is the unity8 landing ready now?
[14:51] <kgunn> sil2100: yes...sorry, entered into stanup :)
[14:52] <sil2100> didrocks, bfiller: I'll also assign a silo for the dialer-app + url-dispatcher thing
[14:52] <sil2100> To flush out the old starving landings
[14:53] <didrocks> sil2100: sounds good to me
[14:54] <bfiller> sil2100: thanks
[14:54] <popey> davmor2: open apps lens, search for an app, keep searching, backspacing, searching, backspacing without letting it finish.. can you crash unity?
[14:56] <davmor2> popey: not on maguro
[14:59] <davmor2> popey: that might just be down to the slower speed of the maguro though
[14:59] <didrocks> ok, really going for a run now
[15:00] <davmor2> didrocks: I don't believe you
[15:00] <didrocks> davmor2: when I told that, pings just started again
[15:00] <didrocks> it's a curse, I tell you, a curse!
[15:01] <davmor2> didrocks: just do /away running  instead of telling people you are going away ;)
[15:01] <davmor2> oh and then run
[15:01] <didrocks> heh
[15:01]  * didrocks is always far far
[15:02] <sil2100> ;)
[15:03] <sil2100> kgunn, tsdgeos: unity8 silo assigned \o/
[15:03] <tsdgeos> sil2100: \o/
[15:05] <plars> didrocks: didn't I see somewhere that the fix for the dialer_app crash had already gone in? or am I dreaming that?
[15:05] <plars> sil2100: ^
[15:06] <kgunn> plars: i thot i saw that too
[15:06] <plars> ah
[15:06] <plars> sil2100's email said "fixes for dialer-app AP test flakyness " were in 174, but maybe that didn't include the crash?
[15:08] <sil2100> plars: it wasn't the fix for the crash, it was just for a new flaky test satdly
[15:08] <sil2100> *sadly
[15:08] <sil2100> Are there no more crashes there or what?
[15:09] <plars> sil2100: no, it's still there
[15:09] <plars> sil2100: I was just hoping it wouldn't be after I saw that in your email :)
[15:10] <sil2100> plars: sorry to put on false hope ;p
[15:10] <plars> np
[15:14] <sil2100> thostr_: will you take care of the click scope as a lander?
[15:15] <thostr_> yes, but wait on this for sec...
[15:15] <thostr_> or rather for now
[15:15] <sil2100> ACK
[15:15] <sil2100> I just disabled it from cu2d just now
[15:15] <thostr_> can you set the readiness to "no" for now
[15:15] <thostr_> oh, ok then let's start landing
[15:16] <thostr_> or, can you reactivate cu2d?
[15:18] <sil2100> thostr_: I can reactivate it for cu2d if needed - is it crucial?
[15:22] <kgunn> sil2100: any love for a mir silo ?
[15:22] <sil2100> kgunn: hah ;) But indeed, might be a good time to assign one, just give me some moments so I can assess everything relates
[15:23] <sil2100> *related
[15:42] <sil2100> om26er: ok, looking into u-i-t now ;)
[15:43] <om26er> sil2100, thanks, can we still keep daily release for it ?
[15:45] <sil2100> om26er: well... daily-release is such a non-fitting name right now ;p Keeping it under cu2d would mean that it would be not really released frequently
[15:45] <sil2100> om26er: we'll have to ask asac and didrocks if we're allowed to keep it under cu2d still
[15:46] <om26er> sil2100, because I assume we are not going to put it on the image and at the same time we may have a few frequent additions to the source as well, only then we will run those tests on smoke testing
[15:47] <sil2100> om26er: sounds legit
[15:49] <ogra_> kgunn, hey ho
[15:50] <ogra_> kgunn, so it seems since we use unity-system-compositor the system load does not get to zero as fast as it did before anymore, could someone of the mir team possibly take a look at that ?
[15:51] <kgunn> ogra_: can do....altho maybe not super immediately....is that ok ?
[15:51] <ogra_> i.e. if you look at http://ci.ubuntu.com/smokeng/trusty/touch/mako/176:20140212:20140115.1/6550/ubuntu_calculator_app/
[15:51] <ogra_> kgunn, i guess it is
[15:51] <kgunn> ogra_: you got a bug? if not i'll file one....
[15:52] <ogra_> i think worst case we can even set the timeout differently for the test, i expect it to be normal that it takes a bit longer with an additional layer in the stack
[15:52] <kgunn> ogra_: ah...annoying
[15:52] <ogra_> kgunn, no bug, only test results
[15:52] <ogra_> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/33/artifact/clientlogs/ubuntu_calculator_app/topafter.log/*view*/ is a "systemsettle" top log
[15:53] <ogra_> it runs top in a 5 min loop ten times iirc
[15:53] <ogra_> (plars may correct me, not sure we still use exactly these values)
[15:56] <plars> ogra_: let me double-check what it's set to
[15:56] <kgunn> ogra_: https://bugs.launchpad.net/mir/+bug/1279391
[15:56] <kgunn> just for reference
[15:56] <ogra_> kgunn, perfect, thanks !
[15:59] <plars> ogra_: so the way it seems to work, is it goes through up to 10 iterations of 5 loops of top, with a 6 second delay between each until it either falls out (fail) or sees that the system has gone to  97.5% idle or above
[16:04] <ogra_> plars, ah i thought the dealys were longer
[16:04] <ogra_> *delays
[16:25] <sergiusens> retoaded, fginther can you increase the timeout for unity-scope-click? https://jenkins.qa.ubuntu.com/job/unity-scope-click-trusty-armhf-ci/162/console
[16:25] <sergiusens> alecu, ^^
[16:26] <fginther> sergiusens, that looks like a bad run, the passing tests take about 20 minutes
[16:28] <sergiusens> fginther, really? this mr brings in more tests
[16:29] <fginther> sergiusens, I suspect a bad test then, only that MP is having problems. and only on armhf
[16:29] <didrocks> sil2100: om26er: no, everything needs to move to citrain. We are not going to maintain a jenkins and code just for few projects
[16:29] <didrocks> it's a big overhead
[16:30] <alecu> fginther, sergiusens: I suspect something wrong with qt or gcc in arm. This only happens when using "new style" connections to qt signals, and only sometimes. Old style connections work every time.
[16:31] <sil2100> ;)
[16:31] <sil2100> om26er: ^
[16:31] <alecu> fginther, sergiusens: we'll try with crosscompiling; is jenkins doing crosscompiling too?
[16:31] <didrocks> bzoltan: testing not over yet?
[16:31] <fginther> alecu, no, jenkins only does natvie
[16:31] <didrocks> bzoltan: we are going to kick an image, so won't be before tomorrow now
[16:32] <sergiusens> alecu, cross compiling for tests won't work
[16:32] <alecu> fginther: ah, great. And is there a way to get shell access to an arm server that's configured just like jenkins? (canonistack, for instance)
[16:32] <alecu> sergiusens: ack
[16:33] <alecu> fginther: because we've tried compiling locally on one device, and we can't reproduce this issue. It only happens when jenkins runs
[16:34] <fginther> alecu, I don't know of any resources available for this outside of our jenkins nodes, hmmm
[16:35] <mmcc> alecu: sorry, I was afk, just joined and I don't have any backlog.
[16:35] <sil2100> Damn, it's so nice to see the spreadsheet work correctly again
[16:37] <fginther> alecu, I'll have to get back to you, maybe I'll think of something soon
[16:37] <alecu> fginther: thanks
[16:38] <om26er> sil2100, didrocks do I get to be the owner of this package in CITrain ? so that whenever I want a new package uploaded I can get it. or does that need to be a manager
[16:39] <sil2100> om26er: you can be a lander no problem I guess, we just need to train you about the basic of CITrain usage then
[16:39] <sil2100> didrocks: btw. we don't need the bootstrapping commit for new projects in CITrain?
[16:39] <sil2100> (in changelog)
[16:40] <om26er> sil2100, ok, makes sense. So please upload it to then ?
[16:40] <om26er> -to
[16:40] <sil2100> om26er: finishing the packaging review just now
[16:41] <sil2100> om26er: we can use this merge for bootstrapping to citrain even I guess
[16:43] <didrocks> sil2100: no, nothing needed, it will collect commits from rev 1
[16:43] <didrocks> om26er: I guess it will make sense for you to be a lander
[16:43] <didrocks> om26er: mind coming to next Monday bootcamp?
[16:44] <om26er> didrocks, I am at QA sprint next week, I will try to be there if we dont hit a timezone issue
[16:45] <didrocks> om26er: ah true, let's see
[16:45] <om26er> didrocks, where does it take place ? bootcamp i mean
[16:46] <didrocks> om26er: 3PM UTC IIRC
[16:46] <om26er> didrocks, is that a hangout ? or IRC ?
[16:47] <didrocks> om26er: hangout
[16:47] <didrocks> pitti should be in as well
[16:47] <om26er> didrocks, can you invite me, please ?
[16:48] <om26er> 7am Oakland, awesome. probably I will be up at that time with jet lag
[16:49] <didrocks> om26er: I'll send that email tomorrow with a lot more infos. Yeah adding you :)
[16:49] <didrocks> om26er: I'm sure jetlag will help! :)
[16:49] <om26er> didrocks, great, thanks :)
[16:50] <didrocks> om26er: but I know we can ask you anything at anytime now as I guess you don't plan to sleep during night for some months (congrats btw :p)
[16:50] <om26er> didrocks, heh, thanks. My work times are already odd, so whatever ;)
[16:51] <didrocks> heh
[17:01] <didrocks> sil2100: coming?
[17:01] <didrocks> cyphermox_: coming *back*?
[17:01] <sil2100> AaaaaaAaa
[17:01] <sil2100> Meeting!
[17:01]  * sil2100 panic
[17:02] <didrocks> balloons: I think starting today, you are a permanent guest as well?
[17:02] <sil2100> hm, hangout problems
[17:03] <sergiusens> didrocks, sil2100 is ubuntu-download-manager in the ci train?
[17:03] <om26er> sil2100, branch merged.
[17:03] <didrocks> sergiusens: not yet
[17:03] <didrocks> should be on Monday
[17:03] <didrocks> sergiusens: if you want to take it meanwhile, we can put it in, is it blocking you?
[17:03] <sergiusens> didrocks, talked to mandel and I can be the PoC
[17:06] <sergiusens> didrocks, but we can start Monday; not blocking me
[17:08] <didrocks> sergiusens: ok, we have multiple things to land, so tomorrow if pressing, otherwise I would prefer mandel to have something to experience the CI Train
[17:08] <sergiusens> didrocks, then let him do it ;)
[17:09] <sergiusens> didrocks, I just need fixes in trunk for the go bindings so if the old mechanism is in it's fine
[17:17] <sil2100> om26er: cool ;)
[17:18] <sil2100> om26er: the automerger is disabled now since we switch to CITrain, let's try releasing it on Monday maybe?
[17:19] <om26er> sil2100, is it possible to release it in this week ? maybe on friday ?
[17:22] <thostr_> can anybody reconfigure silo 11?
[17:23] <mandel> didrocks, just ping me and I'll experience :)
[17:24] <didrocks> sil2100: robru: I'll let you coordinate on Mir :)
[17:24] <robru> sil2100, ok, i'm ready
[17:26] <sil2100> \o/
[17:27] <sil2100> robru: give me a moment
[17:27] <sil2100> om26er: I think we can, we can do it together before the bootcamp and simply starting next week you'll be the one filling the requests
[17:27] <sil2100> om26er: can we do that tomorrow then?
[17:28] <thostr_> sil2100: robru: can anybody quickly reconfigure silo11?
[17:28] <om26er> sil2100, yes tomorrow sounds fine, I'll ping you tomorrow then :)
[17:28] <sil2100> robru: in the meantime ^ ? ;)
[17:28] <sil2100> om26er: thanks! ;)
[17:28] <robru> thostr_, on it
[17:29] <robru> thostr_, done
[17:29] <thostr_> robru: thanks
[17:30] <sil2100> robru: ok, so actually you can do it in any order you want, but I usually tend to do it like that - you first assign a silo, writing MR's in MR's and xorg-server as the source package
[17:30] <didrocks> ogra_: promotion in progress btw?
[17:30] <sil2100> robru: the process of assigning is the same
[17:31] <ogra_> didrocks, on it
[17:31] <didrocks> thanks!
[17:31] <robru> sil2100, oh ok right right
[17:31] <robru> sil2100, i wasn't sure what you were talking about in the hangout. forgot about the source package thing
[17:31] <sil2100> robru: once it's done, we need to prepare xorg-server package - usually it should be upstream doing that though
[17:32] <robru> sil2100, so what's the significance of these source packages? why aren't they just MPs? is it because we aren't upstream?
[17:33] <sil2100> robru: yes
[17:34] <sil2100> robru: there are no bzr branches for those, we cannot enforce those to be there
[17:34] <ogra_> [17:34] <robru> sil2100, ok, so why aren't we prepping the packages then? I don't understand the reason why upstreams do it for us
[17:35] <sil2100> robru: usually I do it for them, but it should be upstream doing that as well
[17:35] <sil2100> robru: is the silo ready?
[17:36] <ogra_> kgunn, wrt your mail: "performance improvements for N7" ... is that 2012 or 2013 ?
[17:36] <robru> sil2100, which one?
[17:36] <kgunn> 2013
[17:37] <ogra_> ah, thx
[17:37] <robru> sil2100, ok, silo 13
[17:39] <sil2100> robru: check your e-mail - you can take that source package and upload it to the silo 13's PPA
[17:39] <sil2100> robru: it's a simple xorg-server bump of the build-deps
[17:39] <robru> sil2100, ok, one sec
[17:40] <sil2100> robru: after you dput to the PPA and notice it appearing in the PPA, you can then ask kgunn to press the build button
[17:40] <sil2100> robru: xorg-server should dep-wait for the new mir to build and then build itself
[17:40] <sil2100> And tadah ;)
[17:40] <sil2100> robru: so the order is: assign silo -> dput source package -> run build
[17:41] <kgunn> sil2100: robru and we need to tell mlankhorst when we begin
[17:41] <sil2100> robru: this way the build job notices instantly that there's also a source package building
[17:41] <sil2100> kgunn: ok
[17:41] <kgunn> so he doesn't magically upload a new xserver :)
[17:41] <kgunn> in the middle
[17:41] <sil2100> kgunn: robru is your guide in this matter ;) Robert knows packaging so he can cherry-pick upstream changes into the PPA if needed as well
[17:42] <sil2100> robru: I think you have can handle it from here, right?
[17:42] <robru> sil2100, probably
[17:43] <kgunn> robru: oh man...you're being put in charge of me and my stuff
[17:43] <kgunn> means they must hate you :)
[17:44] <sil2100> ;D It's not that bad!
[17:44] <robru> kgunn, haha, learning to swim by jumping in the middle of the ocean ;-)
[17:45] <didrocks> robru: publishing unity8 meanwhile? :)
[17:45] <robru> didrocks, if you say so!
[17:46] <robru> didrocks, ack these packagng changes? http://162.213.34.102/job/landing-009-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity8_7.84+14.04.20140212-0ubuntu1.diff
[17:47] <didrocks> robru: +1
[17:47] <robru> kgunn, ok, xorg uploaded, go ahead with your build
[17:48] <kgunn> robru: rock on! thanks
[17:48] <robru> kgunn, my pleasure
[17:53] <kgunn> sil2100: you still there
[17:54] <robru> kgunn, looks like build failed due to a merge conflict.
[17:56] <robru> kgunn, looks like you'll want to rebase https://code.launchpad.net/~mir-team/unity-system-compositor/usc-mir0.1.5-bump (or potentially drop it, since it looks redundant)
[17:57]  * kgunn checks
[17:57] <robru> kgunn, there are two MPs that do the same version bump, conflicting in debian/control. they're not quite the same, but close
[17:59] <kgunn> robru: i should abandon the other
[17:59] <kgunn> robru: but how do it know?....
[18:00] <kgunn> e.g. i didn't add that MP to the landing
[18:00] <robru> kgunn, somebody must have added it...
[18:00] <robru> kgunn, there's no algorithm that goes out and adds extra MPs... ;-)
[18:01] <kgunn> robru: i only see 4 mp's....1 for mir, 1 for unity-mir, 1 for platform-api, 1 for u-s-c
[18:01] <robru> sil2100, why does line 46 say landed?
[18:01] <robru> wait, i'm lost
[18:03] <robru> kgunn, oh, my mistake, i didn't notice that https://code.launchpad.net/~kgunn72/unity-mir/um-mir0.1.5-bump and https://code.launchpad.net/~mir-team/unity-system-compositor/usc-mir0.1.5-bump were merges against different projects
[18:03] <robru> names are so similar
[18:03] <kgunn> robru: and you confused me b/c i had a similar one...not listed against u-s-c :)
[18:03] <robru> kgunn, ok, in that case, take the latter MP and do a "bzr merge lp:unity-system-compositor" and then push back to the same branch. then a rebuild should fix it
[18:03] <kgunn> robru: yeppers, doing it now
[18:04] <kgunn> robru: huh...it said "nothing to do" upon merge
[18:05] <kgunn> do i just do an empty comit to make it happy ?
[18:05] <robru> kgunn, that's bizarre.
[18:05] <kgunn> robru: aptly names
[18:05] <kgunn> named
[18:06] <robru> kgunn, hurr durr. not awake yet. it's unity-mir that has the conflict.
[18:07] <kgunn> robru: hey no worrries..i should've looked at build log instead of being lazy :)
[18:08] <kgunn> relying on you
[18:08] <robru> kgunn, trunk makes reference to a google-mock package that isn't listed in the diff, so I guess somebody did a trunk commit, or otherwise you started your branch with an old copy of trunk
[18:08] <robru> kgunn, anyway 'bzr merge lp:unity-mir' should fix this one: https://code.launchpad.net/~kgunn72/unity-mir/um-mir0.1.5-bump/+merge/205246
[18:09] <kgunn> robru: yep...ahead of you...on its way
[18:09] <kgunn> ag...if i could type
[18:09] <asac> sil2100: can you help bzoltan to run his tests?
[18:11] <robru> kgunn, ok, once you push that fix, you should be able to rebuild. let me know if anything explodes in your face
[18:11] <kgunn> robru: specifically in my face... lol
[18:11] <robru> kgunn, crack this new... it could shoot deadly beams into your eyes and then explode!
[18:18] <sil2100> asac: I'm finishing up some things right now, let me see in a moment
[18:19] <asac> sil2100: ok. ogra is covering
[18:24] <kgunn> robru: lol
[18:24] <kgunn> chances are high
[18:25] <kgunn> bbiab
[18:39] <robru> kgunn, ah shit... looks like a typo in the package name (xorg-server vs xorg-xserver caused a problem here. I'll have to reconfigure.
[18:40] <kgunn> robru: was that my fault?...tell me and i'll note that for future
[18:41] <robru> kgunn, dunno, are you the one who wrote "xorg-xserver" in the spreadsheet? because the package is actually called xorg-server
[18:41] <kgunn> guilty...
[18:41] <kgunn> noted
[18:41] <kgunn> won't happen again
[18:41] <robru> kgunn, hehe, no worries
[18:42] <robru> kgunn, ok, it's reconfigured. so this time kick a build, but check the 'watch_only' box and see what happens. that should make it happy with the package names now
[18:47] <robru> kgunn, around? I'm heading out for lunch soonish, but I'll be back to help out with this soon.
[18:50] <robru> kgunn, i'll just kick that build for you to see what happens before i go...
[18:53] <robru> kgunn, ok, so one thing I see in the PPA is that certain things failed to build due to being uploaded in the wrong order (eg, they all depend on mir 0.1.5 which isn't there yet). so you might have to kick yet another build. but as far as I can tell things are falling into place
[19:16] <thostr_> robru: can you check what's wrong with silo 11? it's building since ages...
[19:45] <seb128> thostr_, you can click on the ppa link at the top to see the ppa status
[19:45] <seb128> thostr_, https://launchpad.net/~ci-train-ppa-service/+archive/landing-011/+packages
[19:45] <seb128> thostr_, those builds are waiting on  libubuntu-download-manager-common-dev which doesn't exists
[19:51] <thomi> robru or rsalveti: could one of you fine gentlement please click the 'Merge and clean' button on landing silo 6 for me please?
[19:51] <seb128> thomi, hey
[19:51] <thomi> hey seb128
[19:51] <thomi> seb128: or perhaps you could do that for me :)
[19:52] <thomi> also, does anyone know why my line from the 'pending' tab in the self-service spreadsheet was deleted?
[19:53] <seb128> thomi, I can press the button for you, sure ... who was handling that landing and pressed the buttons before?
[19:53] <seb128> thomi, thanks for the autopilot test, I confirmed that the landing today, which includes your recent fix, resolves the issue
[19:53] <thomi> seb128: veebers, but he's on holiday today. He and asac agreed that cgoldberg and I should be given permissions, but it hasn't happened
[19:54] <thomi> now I have two releases to get out the door before friday, and I don't have permissions for one, and for some reason my line from the 'pending' tab was deleted last night
[19:54] <thomi> so... yeah... kind of frustrating.
[19:55] <thomi> seb128: should I re-add my pending line? If so, are you able to allocate me a silo, or do I need to wait for didier?
[19:55] <seb128> thomi, they had some issues with the google doc, people doing edits and creating issues in the formulas, timeout and such as well
[19:55] <thomi> ugh
[19:55] <thomi> that sucks
[19:55] <thomi> I'll re-add my line
[19:56] <seb128> thomi, I'm not in the CI team, for silos you need somebody there
[19:56] <seb128> thomi, https://lists.launchpad.net/ubuntu-phone/msg06404.html
[19:56] <seb128> thomi, that lists people that should be online in that timeslot
[19:56] <thomi> sweet, thanks
[19:57] <seb128> thomi, I pressed the clean button on silo 6 for you (I've access to the commands, I just can't assign silos)
[19:57] <thomi> seb128: I see the job running - thanks man
[19:58] <asac> thomi: ok. i talk again tomorrow. sorry. lots of things came in today on didrocks, so...
[19:59] <thomi> asac: no worries. For today I'll bug other people to click buttons for me
[19:59] <asac> thomi: use robru and folks in the US timezone to help you
[19:59] <asac> thanks dont hesitate to ping around
[20:00] <asac> thomi: do you have the MP ready with test?
[20:00] <asac> thomi: afaik the silo was landed (but it was not really you guys pushing that over the line)
[20:00] <seb128> asac, seems like people in the US tz are not that responsive yet ;-)
[20:00] <thomi> asac: huh?
[20:00] <thomi> asac: we spent all of yesterday running the tests. veebers asked didier to push the button late last night
[20:01] <thomi> asac: now I'm just trying to get another silo allocated
[20:01] <asac> thomi: ah ok so it took longer
[20:01] <asac> didrocks pushed the button
[20:01] <asac> thought we wanted to do that after 2-3 hours
[20:01] <asac> and try to prep the other patch already
[20:01] <thomi> right - now I need another silo allocated for row 82
[20:01] <asac> robru: cyphermox_: ^^
[20:01] <asac> thomi needs  your helop i guess
[20:02] <thomi> this message (https://lists.launchpad.net/ubuntu-phone/msg06404.html) says Toykeeper or balloons should be able to do it, but apparently no one told them about it, so...
[20:02] <asac> rsalveti: ^^ can you allocate a silo for thomi?
[20:02] <asac> thomi: selene and balloons have a dogfooder role in the US shift
[20:02] <asac> they dont have powers to allocate silos right now (which might need change)
[20:02] <thomi> asac: ahhhh
[20:03] <asac> so the mail was not very precise :/
[20:03]  * balloons waves a wand
[20:03] <asac> robru: cyphermox_: can allocate
[20:03] <asac> also rsalveti with some luck
[20:03] <thomi> asac: yeah, the email suggested otherwise :)
[20:03] <seb128> asac, none of those seem to be around though :p
[20:04] <kgunn> robru: yep...and unity-mir & platform-api depend on each other...so i always have kick again (just targeted)
[20:04] <thomi> *sadface*
[20:05] <asac> thomi: they will show up... if not, you can mup them
[20:05] <asac> in 15 minutes :)
[20:05] <thomi> will do
[20:06] <asac> i cna do that ... just ping me if they haven't shown up in 15
[20:06] <asac> thanks
[20:06] <asac> :)
[20:08] <thomi> ok
[20:14] <cyphermox_> looking into it
[20:14] <rsalveti> alright, let me know if you still need help from my side
[20:18] <cyphermox_> rsalveti: you can assign silos?
[20:18] <rsalveti> cyphermox_: yup
[20:18] <cyphermox_> ah
[20:18] <rsalveti> never did, but I can
[20:18] <cyphermox_> well it's not doing anything here
[20:18] <cyphermox_> I'll try again in a second
[20:18] <cyphermox_> oh, wait
[20:18] <cyphermox_> I know why :)
[20:21] <cyphermox_> urgh
[20:21] <cyphermox_> thomi: you just added another MP?
[20:21] <thomi> cyphermox_: yes, sorry, I thought no one had gotten to it yet :)
[20:21] <cyphermox_> nevermind, I actually got it, it seems
[20:21] <thomi> thanks cyphermox_
[20:21] <cyphermox_> but it was close, my initial copy I had only one
[20:22] <thomi> heh
[20:22] <cyphermox_> wait, no
[20:22] <cyphermox_> it's not good
[20:22] <cyphermox_> let me reconfigure this to add the other merge
[20:23] <thomi> cyphermox_: I wonder if I should add a blank MP as well, so I can fix things without having to tack them on to an existing MP... in case anything is broken
[20:23] <cyphermox_> bah, it's quick enough to update, no trouble really
[20:23] <thomi> ok
[20:23] <cyphermox_> and anything broken probably belongs still in the same MP
[20:24] <thomi> well, sometimes :)
[20:24] <thomi> cyphermox_: how long before your EOD?
[20:24] <cyphermox_> I will be mostly online until very late
[20:24] <cyphermox_> let's say at least 5 hours
[20:25] <cyphermox_> just ping, and wait I may take a bit to answer
[20:25] <thomi> awesome, thanks
[20:25] <cyphermox_> should be good to go now
[20:25] <thomi> thanks!
[20:25] <cyphermox_> let me know if anything is broke
[20:26] <thomi> cyphermox_: ugh.. I don't have permissions to click the 'build' button. I wonder if you could do that for me please?
[20:26] <thomi> (or give me permissions, if you can)
[20:28] <cyphermox_> I don't know where those permissions are
[20:28] <cyphermox_> I can hit it
[20:28] <thomi> thanks
[20:28] <thomi> this is going to get tiresome for both of us :-/
[20:28] <cyphermox_> ah
[20:28] <cyphermox_> yeah
[20:28] <robru> kgunn, back, just reading scrollback
[20:28] <cyphermox_> who maintains this jenkins? you should ask them for the permissions
[20:29] <cyphermox_> thomi: what you're looking for is access to http://162.213.34.102/job/landing-006-1-build/build?delay=0sec
[20:29] <thomi> cyphermox_: yeah
[20:29] <cyphermox_> fginther: poke ^
[20:29] <thomi> cyphermox_: and for the 'merge & clean' step
[20:29] <cyphermox_> yup
[20:30] <thomi> fginther: while you're in there, perhaps you can also give cgoldberg permissions.
[20:30] <thomi> he's our US timezone representative
[20:31] <fginther> thomi, cyphermox_, this is not the CI teams'. It belongs to the integration team: didrocks, sil2100, Mirv, robru, kenvandine, etc.
[20:31] <fginther> I don't have access
[20:31] <fginther> cyphermox_, do you just need to know how to give permission to thomi?
[20:32] <robru> cyphermox_, thomi: i think it's up to didrocks to grant that access.
[20:32] <thomi> ok
[20:32] <thomi> don't worry about it guys
[20:33] <kgunn> robru: ack...gonna let it run to completion(failure)
[20:33] <kgunn> then i'll rekick just for unity-mir
[20:38] <robru> so, wow, this really exploded while I was on lunch. does anybody need me to do anything at this point? hard to tell how much of the scrollback still needs to be handled and how much was done already
[20:48] <thomi> doanac: bad news: you found a regression in the latest AP. Good news: I've managed to reproduce it with a functional test, and there's an MP and a fix already. bad news: now I have to release it, which takes *ages* :(
[20:48] <thomi> doanac: fix is: https://code.launchpad.net/~thomir/autopilot/trunk-fix-autopilot-subunit-output/+merge/206043
[21:03] <thomi> cyphermox_: I think something is broken inmy silo: "In silo landing-006. Can't merge: wrong status or parameters for job."
[21:03] <cyphermox_> what tells you that?
[21:03] <thomi> cyphermox_: the pending tab
[21:04] <thomi> cyphermox_: status column, row 82
[21:05] <robru> thomi, that was my fault, I was responding to something you said earlier, without realizing that somebody already did it. so doing it twice made that error. but I don't think it's a real problem; just continue with your work. should still be possible to use the silo and publish properly later
[21:05] <thomi> robru: oh ok
[21:05] <thomi> thanks :)
[21:05] <robru> thomi, ping me if anything concrete actually explodes and I'll fix it, but as far as I can see it's ok now
[21:19] <doanac> thomi: thanks.
[21:33] <mmcc> ping robru - we have a test suite that's failing in the ARM jenkins but not in the amd64 one, and I'm told to pick your brain for ideas. The symptom is that Qt signal/slot connections are failing to connect, causing timeouts as code waits for signals that won't come.
[21:34] <mmcc> here's one example: https://jenkins.qa.ubuntu.com/job/unity-scope-click-trusty-armhf-ci/165/console - see "QObject::connect: signal not found" about 10 lines up from the end
[21:34] <robru> mmcc, so basically arm is too slow?
[21:34] <mmcc> robru: I'd be surprised if it was timing-related
[21:35] <robru> mmcc, reading...
[21:37] <robru> mmcc, ok, so the errors I'm seeing are "failed to load" and "no such file". my first instinct on that would be a dependency issue, like some package is available on amd64 but not armhf. did you check into the deps yet?
[21:37] <mmcc> specifically, on ARM , calls to QObject::connect() (which hooks up signal and slot methods between qt objects) fail - returning a null Connection - when on x86, they don't
[21:38] <mmcc> robru: yes, the deps are correct. it runs successfully with the same configs on x86. for example http://jenkins.qa.ubuntu.com/job/unity-scope-click-trusty-amd64-ci/165
[21:38] <mmcc> that's from the same revno
[21:38] <robru> mmcc, this is pretty far outside my area of expertise. unless the problem can be idenfied as some dependent component failing on arm, then most likely I'd ping fginther about an infrastructure issue
[21:38] <mmcc> robru: ack, will do. thanks for taking a look!
[21:38] <robru> mmcc, no worries
[21:39] <mmcc> so, ping fginther: do you have a minute to brainstorm about an arch-specific Qt issue?
[21:40] <fginther> mmcc, I can try
[21:41] <fginther> mmcc, alecu pinged me about this earlier and I don't have too many great ideas...
[21:42] <fginther> mmcc, he mentioned that debugging on armhf hardware might help
[21:43] <mmcc> fginther: well, if I could manually run the tests on the same setup that jenkins is having, that'd accelerated debugging a bit. I do have an old n7 on my desk, so I've already got "misc arm hardware" covered
[21:44] <alecu> the weird thing being that on the n7 it works just fine :P
[21:45] <mmcc> alecu: yes, sort-of... on the n7, some workarounds are required. on jenkins, none of the  workarounds fix the issue
[21:53] <mmcc> fginther: so, it's calls to QObject::connect(), which are Qt's inter-object communication setup calls, and they don't touch any IO or do anything async
[21:53] <mmcc> just for background...
[21:54] <mmcc> so sometimes working on n7 but not in jenkins is very unexpected
[21:54] <tsdgeos> hi guys, is anything I can do to help fix the error at https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=27 ?
[21:54] <fginther> mmcc, are you testing with binary packages or just building and test locally?
[21:54] <mmcc> actually working in x86 but not arm is very unexpected
[21:54] <mmcc> fginther: on the n7 I'm building and testing locally. same on my dev desktop of course
[21:56] <fginther> mmcc, if I can provide the binary packages from the jenkins build, would that be something you could test?
[21:58] <mmcc> fginther: I'm willing to try
[21:58] <fginther> mmcc, ok, I'll set it up
[21:58] <mmcc> thanks
[22:03] <thomi> robru: cyphermox_: sorry about this, but A thord autopilot change has become available, and I'd like to roll it into this release. Could one of you please re-provision the silo for me? row 82 on the SS
[22:03] <robru> thomi, is there a new MP? or just new commits on existing MPs?
[22:03] <thomi> robru: there's a new MP
[22:04] <robru> thomi, ok, will do
[22:04] <thomi> thanks
[22:04] <thomi> robru: if you could fire off the build step as well, that'd be great :)
[22:04] <robru> thomi, sure I guess. who is supposed to normally?
[22:05] <thomi> robru: well, veebers, but he's on holiday. I'm also supposed to have permissions, but it didn't happen last night.
[22:05] <thomi> hopefully tomorrow I'll be able to do it myself
[22:05] <robru> thomi, ok, no worries. I'm personally happy to do it but I've been told not to... ;-)
[22:05] <thomi> really?
[22:05] <thomi> I wonder why
[22:06] <robru> thomi, yeah, the 'lander' (usually "your manager") is supposed to. there's some big reason involving ownership of the stack, they're supposed to take an active role by both building, and merge/cleaning.
[22:06] <robru> thomi, text conflict:
[22:06] <robru> http://162.213.34.102/job/landing-006-1-build/21/console
[22:07] <thomi> robru: thanks, I'll sort it out
[22:07] <robru> thomi, first guess would be that you added the MPs in the wrong order in the spreadsheet. if so it needs a reconfig with the right order. if not, you just need to rebase your branch and then rebuild. ping me when you're ready
[22:08] <thomi> robru: yup, will do - thansk
[22:30] <fginther> mmcc, this is the correct MP? https://code.launchpad.net/~mikemc/unity-scope-click/dlmgr-add-udm/+merge/205733
[22:31] <thomi> robru: merge conflicts fixed - if you could re-build, that'd be great
[22:32] <robru> thomi, building
[22:32] <thomi> thanks
[22:33] <robru> thomi, ok looks good. I gotta step out and run a quick errand, but I'll be back in 30 if you need anything else
[22:34] <thomi> thanks
[22:35] <fginther> ChrisTownsend, ping
[22:37] <ChrisTownsend> fginther: Hi
[22:38] <fginther> ChrisTownsend, regarding your last email. you mention the overlapping monitor setup should be fixed. 'What' needs to be fixed? is this a setup issue, a unity issue, something else?
[22:38] <ChrisTownsend> fginther: I believe it's a setup issue.
[22:39] <ChrisTownsend> fginther: Sorry for being vague:)
[22:39] <fginther> ChrisTownsend, do you know how that is resolved?
[22:41] <ChrisTownsend> fginther: I honestly don't know how it gets in that state.  I know it can manually set up the monitors in System Settings->Displays
[22:41] <ChrisTownsend> fginther: But even there, you can't overlap monitors.
[22:42] <fginther> hmmm
[22:43] <fginther> ChrisTownsend, oh my, that is bad
[22:44] <ChrisTownsend> fginther: Did you find something or just commenting on the overlapped monitors?
[22:45] <fginther> ChrisTownsend, sorry, just commenting on the overlap, just watched one of the videos
[22:45] <ChrisTownsend> fginther: Yeah...
[22:46] <ChrisTownsend> fginther: Anything else I can help with?  Not sure what else I can help with though.
[22:48] <fginther> ChrisTownsend, nope, that it. thanks.  I'll kick off another test
[22:48] <ChrisTownsend> fginther: Ok, cool, and thanks!
[23:04] <tsdgeos> robru: any idea of what's wrong in https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=27 ?
[23:04] <kgunn> robru or cyphermox_ ....as new landing buddies ^ any ideas ?
[23:08] <cyphermox_> kgunn: unity8 was still in proposed at the time
[23:08] <cyphermox_> I'd say nothing is wrong, unity8 has landed by now
[23:09] <cyphermox_> kgunn: was is only just unity8?
[23:09] <tsdgeos> cyphermox_: has it? all the branches that were part of that mp are not in unity8 trunk
[23:09] <cyphermox_> oh, right
[23:10] <cyphermox_> I guess the merges didn't all get landed since the package couldn't be seen as landed
[23:11] <cyphermox_> tsdgeos: kgunn: did you run that yourself? I think it could simply be re-run
[23:14] <tsdgeos> hmmmm, no idea what that means. kgunn?
[23:15] <kgunn> cyphermox_: so i thot didrocks was gonna merge...but i suppose i can hit merge button if those are really in archive
[23:16] <cyphermox_> tbh I have no idea
[23:16] <cyphermox_> that line is usually for you's
[23:16] <kgunn> cyphermox_: right...i think he hit early
[23:16] <cyphermox_> unless there is something special for this particular merge
[23:16] <kgunn> hence the can't merge msg
[23:16] <kgunn> nope
[23:18] <kgunn> so tsdgeos cyphermox_ if the packages aren't there...it'll gripe again and keep the spreadsheet cell red
[23:18] <kgunn> but i bet they are there now
[23:18] <cyphermox_> correct
[23:18] <kgunn> i just hit merge, let's see
[23:19] <tsdgeos> lots of stuff merged \o/
[23:20] <tsdgeos> tx all
[23:20]  * tsdgeos leaves for some sleep