[02:05] <imgbot> [03:24] <imgbot> [03:24] <imgbot> [06:24] <Mirv> indeed
[09:25] <Mirv> ogra_: do you still do the occasional touch seed upload? nik90/bzoltan would like to get the one-liner https://code.launchpad.net/~nik90/ubuntu-seeds/add-qml-connectivity/+merge/237442 in although that branch happens to be against utopic.
[09:25] <ogra_> Mirv, yeah, i saw the comment on the branch
[09:26] <alan_g> cihelp is something broken? We've not seen a run complete since before the weekend. Here: http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-runner-mako/
[09:28] <Mirv> ogra_: ok.
[09:40] <alf__> cihelp: Hi! A lot of Mir jobs have been blocked waiting for makos since Friday. Any idea what is wrong?
[09:40] <alf__> cihelp: e.g., http://s-jenkins.ubuntu-ci:8080/job/mir-ci/
[09:40] <alf__> alan_g: ^^ FYI
[09:46] <ev> hi alf__ and alan_g. We're looking into it now.
[09:46] <alf__> ev: great, thanks
[10:04] <Saviq> trainguards ↑ please :)
[10:05] <Mirv> Saviq: okie
[10:08] <popey> ogra_: bug 1397918
[10:08]  * ogra_ hugs popey 
[10:23] <psivaa> ogra_: does 'Dec  1 10:19:47 heymann kernel: [5817795.697394] usb 1-1.5.2.1: usbfs: USBDEVFS_CONTROL failed cmd fastboot rqt 128 rq 6 len 254 ret -108' ring any bell?
[10:23] <psivaa> this is a kernel log from the adb host
[10:23] <ogra_> hmm, nope
[10:23] <ogra_> looks bad thouh
[10:23] <ogra_> +g
[10:24] <psivaa> yea, i *think the adb host in the lab is somehow messed up.. failing to see how, yet
[10:24] <ogra_> hub issues ?
[11:02] <michi> cihelp: cloud-worker-06 is running ridiculously slowly. It’s been like this since last Friday. I pinged about this back then, but didn’t get a response. The machine usually is still compiling by the time the arm build for the same code has compiled and finished testing.
[11:02] <michi> cihelp: could someone please fix that builder or take it off-line?
[11:17] <Saviq> cihelp, also, looks like makos are dead http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-vivid-mako/
[11:17] <Saviq> they all got stuck flashing
[11:17] <psivaa> Saviq: yea, working on them
[11:17] <Saviq> psivaa, ok
[11:29] <alan_g> ev: is this hung on the same issue? http://s-jenkins.ubuntu-ci:8080/job/qtmir-ci/
[12:02] <michi> cihelp: Our build on cloud-worker-06 has been running for nearly and hour and still hasn’t finished compiling. Can someone PLEASE look at this?
[12:03] <michi> http://s-jenkins.ubuntu-ci:8080/job/unity-scopes-api-devel-vivid-amd64-autolanding/34/console
[12:03] <psivaa> michi: just finishing up some mako device issues in the lab. will take a look after that
[12:04] <michi> psivaa: Thank you, I appreciate it!
[12:14] <psivaa> Saviq: alf__: alan_g: mako devices have a broken image (34) and failing to comeback to fastboot mode. we need someone onsite to take a look and flash them with a newer image. i've reported a ticket for that
[12:15] <Saviq> psivaa, ktx
[12:15] <alan_g> psivaa: thanks
[12:16] <psivaa> michi: cloud-worker-06 has been taken offline now, the job is building now on -11, please let us know if you see that being slow too
[12:16] <michi> psivaa: Awesome, thank you!
[12:16] <michi> Why do these things suddenly start running slowly?
[12:16] <psivaa> michi: haven't digged in to the instances yet, will do in a bit
[12:17] <michi> OK, cool. I’m not trying to be a pain. Just curious.
[12:18] <psivaa> np :)
[12:19] <psivaa> ogra_: wifi in the lab also *appears broken, could not come to any other conclusion, a device with image 38, which was confirmed to be working also now failing to connect to the network. i've reported a ticket for that too with the IS
[12:22] <Saviq> trainguards, Icanhasreconfigure of vivid silo 3, had to add settings because of a missing dependency there
[12:24] <ogra_> psivaa, ouch
[12:33] <Mirv> Saviq: done
[12:34] <Saviq> Mirv, thanks
[12:46] <Ursinha> rsalveti: you might like this: http://lizkeogh.com/2008/09/10/feature-injection-and-handling-technical-stories/
[12:47]  * rsalveti checking
[14:22] <jgdxx> cihelp: Hi there. Any idea what this test failure [1] really means? [1] https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/338/testReport/junit/ubuntu_system_settings.tests.test_sound/SoundTestCase/test_sound_page/
[14:35] <fginther> jgdx, The test runs, but it looks like it couldn't find some widget. I don't have much more advice on this, but if you want to try to reproduce exactly as jenkins runs the job, there are some starter instructions at the bottom of this file: http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/README-cli.rst
[14:46] <jgdx> fginther, thanks
[14:47] <fginther> jgdx, just one note. running those instructions as-is will flash your device (that should be included in the README)
[15:01] <Mirv> ogra_: ^ I guess we're still under no-landings rtm mode until otherwise told?
[15:03] <ogra_> Mirv, if QA signed off i would expect that they chacked there are only ota-1 tagged bugs fixed in the silo ... but yeah, we should wait til we had a bug meeting with mgmt
[15:04] <Mirv> when the gates finally do open, the interesting thing is going through all the non "ota1" but critical rtm bugs
[15:04] <Mirv> ogra_: yep, they probably check that but the official word is indeed closed still
[15:04] <Mirv> like the UITK fixes some critical touch-2014-11-xx bugs but is not ota-1. lots of triaging to do.
[15:05] <ogra_> i would like a separately built image with silo3 landed first ... imho then we can open the gates again
[15:05] <Mirv> makes sense
[15:10] <alex-abreu> Mirv, mmh could you merge L46 & 47 in silo 5 ? :) there is no clear dep between the 2
[15:12] <alex-abreu> Mirv, thx :)
[15:12] <Mirv> alex-abreu: yw :)
[15:17]  * Mirv out
[15:46] <jhodapp> Mirv, how are we handling getting a change that has already landed in vivid into rtm? We need a new rtm silo I'm sure, but then what do I need to do to get the particular revision of my branches into that silo?
[15:46] <ogra_> jhodapp, you need to make sure that your landing *only* closes the rtm ota-1 tagged bug
[15:46] <ogra_> i.e. no bundled fixes
[15:48] <jhodapp> ogra_, right
[15:48] <jhodapp> ogra_, but what needs to happen to do that? request a sync, propose a new MR, what?
[15:49] <ogra_> depends on the code ... if you have an rtm MR ... just request a landing
[15:49] <jhodapp> ogra_, I don't have an rtm MR
[15:49] <ogra_> if a sync is possible (because your fix went in standalone and without any other fixes in vivid) you can surely ask for a sync
[15:50] <jhodapp> ogra_, it did, there's a specific revision number for qtubuntu-camera that only contains my fix
[15:50] <ogra_> jhodapp, right, then a sync should be possible
[15:51] <jhodapp> ogra_, the trickier part is the android/hybris side, but those should have gone in cleanly too (I hope)
[15:51] <ogra_> yeah, that has to go through the normal john-mcaleely approval process
[15:51] <jhodapp> ogra_, right
[15:54] <jhodapp> ogra_, so how would that sync work? there was one change that landed in vivid for qtubuntu-camera after my fix...so how do we sync just my fix and not the revision change after mine?
[15:59] <ogra_> jhodapp, that would be a sil2100 question ... but he is sick today
[15:59] <jhodapp> ogra_, ok, I bet robru could answer too, no?
[15:59] <ogra_> i assume citrain allows syncing a specific version into a silo though
[16:08] <brendand> ogra_, what exactly is wrong with the current vivid image?
[16:08] <ogra_> brendand, nothing that i know about ... do you have an issues ?
[16:08] <ogra_> *any
[16:09] <brendand> ogra_, phablet-click-test-setup is getting stuck
[16:09] <ogra_> ah, havent heard of that one yet
[16:10] <brendand> ogra_, did the tests run in ci today?
[16:10] <ogra_> brendand, nope, there was an issue with the wlan AP in the lab
[16:11] <ogra_> they couldnt finish provisioning due to that
[16:11] <brendand> ogra_, ok
[16:11] <brendand> ogra_, so phablet-click-test-setup hasn't been tested on 39 then
[16:11] <ogra_> do you know where phablet-click-test-setup hangs actually ?
[16:11] <brendand> 'Checking out lp:music-app to /tmp/tmpd0Ftqv/work'
[16:11] <brendand> ogra_, not sure if that's on the device or locally
[16:12] <ogra_> sounds like device
[16:12] <brendand> ogra_, yeah seems to be the device
[16:12] <ogra_> put a "set -x" at the top of the script
[16:12] <ogra_> that should make it a bit more noisy
[16:13] <brendand> ogra_, ah it's python
[16:13] <ogra_> ah, well ...
[16:19] <brendand> ogra_, looks like there was a temporary launchpad issue
[16:21] <oSoMoN> trainguards: hey, can I have silos for lines 48 and 49, pretty please?
[16:25] <ogra_> brendand, phew
[16:28] <sergiusens> can people leave the sheet for a bit? "Wow, this file is really popular! It might be unavailable until the crowd clears. Try again."
[16:29] <sergiusens> ah, there we go
[16:29] <ogra_> it's popular :)
[16:31] <sergiusens> meh, now it can't save... :/
[17:06] <ogra_> robru, are u around ?
[17:28] <robru> jhodapp: ogra_: wut? CI Train's sync code just grabs whatever package is in a distro and rebuilds it for the other distro. If you want to cherry pick only a certain fix you have to grab the specific diff and apply it as a new commit in an MP to thenew distro.
[17:29] <ogra_> robru, oh
[17:29] <ogra_> robru, i thought you could do something like copy-package of a sepcific version from the devel distro
[17:29] <robru> ogra_: well you can totally do that but it has nothing to do with citrain.
[17:29] <ogra_> k
[17:30] <robru> ogra_: so yeah, I can do a manual source upload silo and you can copy-package some older version into it I guess.
[17:31] <ogra_> right, i guess thats what jhodapp needs in his case ...
[17:56] <jhodapp> robru, ogra_: yeah that's what I need
[18:03] <robru> jhodapp: do you have a spreadsheet row?
[18:03] <jhodapp> robru, yeah, 47
[18:04] <robru> jhodapp: what source package do you want synced? camera-app?
[18:04] <jhodapp> robru, it'd be qtubuntu-camera, hybris and the android package
[18:05] <robru> jhodapp: and what versions?
[18:06] <jhodapp> robru, for qtubuntu-camera: http://bazaar.launchpad.net/~phablet-team/qtubuntu-camera/trunk/revision/120
[18:07] <jhodapp> robru, not sure how the android and hybris changes would work
[18:08] <robru> jhodapp: well you'd have to go through the changelog and find the oldest version that has the fix you need
[18:08] <jhodapp> robru, yeah, will have to talk to rsalveti about this one since he always orchestrates these packages for landing
[18:09]  * rsalveti looks
[18:09] <ogra_> will likely be hard to find an android package that doesnt ship any additional fixes
[18:09] <jhodapp> yeah indeed
[18:10] <jhodapp> they're usually paired with several other things
[18:10] <ogra_> right
[18:10] <rsalveti> yup, but should be fine, rtm has a quite recent android version
[18:10] <rsalveti> jhodapp: I can handle this landing
[18:10] <ogra_> we need to find a way to separate them out for future laandings
[18:10] <rsalveti> there's no easy way
[18:10] <jhodapp> rsalveti, ok, I'll be curious to know what you do though just so I can get an idea
[18:10] <rsalveti> but that's for like every project
[18:11] <ogra_> well, cant we shelve them in git or some such
[18:11] <rsalveti> jhodapp: in this case we just need to sync qtubuntu-camera, libhybris and android from vivid into rtm, but we need to rebuild at least libhybris and qtubuntu-camera when doing so
[18:11] <rsalveti> can't necessarily rebuild android that easily
[18:11] <ogra_> so that you can just pull this one commit into an rtm package
[18:11] <robru> rsalveti: ok well you have silo rtm 12, feel free to push whatever packages there
[18:11] <rsalveti> then we need to push the hybris patch at the krillin git repo for rtm, and sync that landing with a device tarball
[18:12] <jhodapp> rsalveti, yeah pretty involved
[18:12] <rsalveti> ogra_: we can, but in this case it's a pita to coordinate
[18:12] <jhodapp> rsalveti, there's a Trello task for this, you can add yourself to it
[18:12] <ogra_> well, it wont pass QA  or management if there is anything else in the package
[18:12] <rsalveti> jhodapp: cool, will do
[18:12] <rsalveti> ogra_: well, that's something we need to check
[18:12] <ogra_> right
[18:12] <rsalveti> once we understand if that will indeed be the case
[18:13] <ogra_> and to plan for the future
[18:13] <jhodapp> ogra_, this is really about change management and is always a hard problem at every company I've worked at
[18:13] <rsalveti> work to cherry-pick sometimes might be more than actually testing an additional fix
[18:13] <ogra_> jhodapp, yeah
[18:13] <rsalveti> there's no silver bullet
[18:13] <rsalveti> only manual work
[18:13] <jhodapp> rsalveti, agreed...for qtubuntu-camera there's only one other fix on top of mine
[18:13] <ogra_> rsalveti, well, in case of android you only brick mako :)
[18:14] <ogra_> the landing for krillin would be a cherry pick in git anyway
[18:14] <rsalveti> jhodapp: right, that might be easy to cherry-pick
[18:14] <jhodapp> should be
[18:14] <rsalveti> but then I need to manually sync that
[18:14] <rsalveti> otherwise the train will bump the changelog
[18:14] <ogra_> so for the android package we could perhaps go as is
[18:14] <rsalveti> and confuse everyone
[18:14] <rsalveti> this is going to be painful
[18:15] <ogra_> but i think we need a general plan for this kind of stuff
[18:15] <ogra_> yeah
[18:15] <rsalveti> (not only this landing, as I know what I'm doing, but coordinating that with everyone)
[18:15] <jhodapp> ogra_, agreed
[18:15] <rsalveti> can't make train to rebuild stuff, etc etc
[18:15] <ogra_> rsalveti, yup ... and it wont get easier :/
[18:15] <ogra_> why cant you ?
[18:15] <rsalveti> and only a few people has access to dput
[18:15] <rsalveti> ogra_: otherwise the version will be mixed
[18:15] <rsalveti> I can have 2 bzr branches, vivid and rtm
[18:16] <ogra_> the train gets an older upstream package than vivid has already ... so it shouldnt break if it attaches rtm1 or whatever it does
[18:16] <rsalveti> and have mrs landing on each one, separately
[18:16] <rsalveti> ogra_: right, but if I rebuild that, it'll bump the changelog
[18:16] <rsalveti> with today's date
[18:16] <rsalveti> which will confuse everyone :-)
[18:16] <ogra_> for the upstream ?
[18:16] <rsalveti> then it'll make it really hard to coordinate cherry-picks
[18:16] <rsalveti> ogra_: no, for the rtm branch
[18:17] <rsalveti> so we can have qtubuntu-camera-(last week) on vivid and qtubuntu-camera-(today) on rtm, after a rebuild
[18:17] <rsalveti> but the content will be different
[18:17] <rsalveti> so the upstream will need to manually coordinate the cherry-picks
[18:18] <rsalveti> or the developer will need to take care of the changelog
[18:18] <ogra_> yeah
[18:18]  * ogra_ prefers the changelog approach 
[18:18] <ogra_> technically we should take rtm packages and just add stuff on top of them
[18:18] <rsalveti> right, but that is only clear for us
[18:18] <rsalveti> it can get messy really fast
[18:19] <ogra_> right, we should have some planning meetings with all parties involved
[18:20] <rsalveti> yup
[18:20] <ogra_> on how to handle your stuff in vivid bset
[18:20] <ogra_> *best
[18:20] <ogra_> so that you dont step on your own toes
[18:20] <robru> is anybody going to land anything in vivid today? I have a from-scratch rewrite of the citrain publisher job I'd like to test out...
[19:57] <robru> sergiusens: vivid 9 and 10
[19:58] <sergiusens> thanks
[21:57] <robru> sergiusens: Saviq: rsalveti: anybody expecting to land silos today?
[21:58] <Saviq> robru, no, tomorrow
[21:58] <robru> Saviq: ok, no worries.
[21:59] <rsalveti> robru: sergiusens might
[21:59] <robru> rsalveti: cool. he can be the guinea pig for the new publish job then ;-)
[23:20] <sergiusens> robru: I will, but need to settle first
[23:22] <robru> sergiusens: no rush