[07:48] <Mirv> didrocks: ok desktop tests went fine (one flaky webbrowser on radeon, not on intel), and there are no packaging changes on ui-toolkit. before I publish, could you take a glance on the slightly worrying looking "duplicate" entries of other packages that I'm not going to publish: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-3.0publish/
[07:50] <didrocks> Mirv: ah, it seems just that the cleanup never happened, not important
[07:51] <didrocks> Mirv: I suggest that after publishing the sdk, you quick a full stack build to "clean" this up
[07:51] <didrocks> Mirv: I guess you'll track Mir, just in case there are news? (on your bug, duflu changed the status)
[07:54] <didrocks> Mirv: do you have a slot available for doing upstart-app-launch?
[08:01] <Mirv> didrocks: yeah, will do. and tracking, duflu is looking at it again after I pinged him.
[08:01] <didrocks> thanks!
[08:01] <didrocks> Mirv: I think we'll kick an image build as soon as you confirm that ubuntu-ui-toolkit is in the release pocket
[08:02] <Mirv> didrocks: ok, I can do the upstart-app-launch at some point today
[08:04] <didrocks> great!
[08:15] <Mirv> didrocks: the sdk publish job just keeps on timeouting/stalling
[08:15] <didrocks> Mirv: networking issue?
[08:15] <Mirv> didrocks: maybe, it doesn't say directly http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-3.0publish/297/console
[08:16] <Mirv> and it's still running after 15 mins
[08:16] <didrocks> Mirv: not related but why did you list some services, like telephony-service, address-book-app, content-hub and not the rest of daily-release components?
[08:16] <didrocks> cihelp: any idea? 09:15:05     Mirv | didrocks: the sdk publish job just keeps on timeouting/stalling
[08:16] <didrocks> cihelp: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-3.0publish/297/console
[08:17] <Mirv> didrocks: so I started by listing components that have a QML plugin since I started with the idea of Qt related PPU, but then again most of those have. so in the end it does miss some of the current cu2d packages, and of course any that are added later.
[08:18] <didrocks> Mirv: ok, let's do it in 2 rounds
[08:21] <didrocks> Mirv: ok, I hope my comment for your ppu rights will suit you :)
[08:22] <Mirv> didrocks: thanks a lot, it does :)
[08:22] <didrocks> great, you deserve it ;)
[08:30] <didrocks> Mirv: oh, it's a token issue
[08:30] <didrocks> Mirv: seems the launchpad cred was changed
[08:30] <didrocks> ah, it was, of course, the machine changed
[08:31] <vila> didrocks, Mirv : sounds a lot like the slow network issue has reached q-jenkins. I'm waiting for feedback on that, it's high on the priority list AFAIK if not top
[08:31] <didrocks> cihelp: we need someone having the creds for the ps-jenkins bot
[08:31] <didrocks> vila: well, this one is different
[08:31] <didrocks> as we changed the machine
[08:31] <didrocks> the launchpad cred is invalidated
[08:31] <didrocks> so we need to register this machine for ps-jenkins account
[08:32] <didrocks> Mirv: I'm killing the job btw, it will hang forever I guess
[08:35] <didrocks> Mirv: can you relaunch a publication please?
[08:35] <didrocks> I'm logged in as ps-jenkins
[08:36]  * didrocks tries to unblock production
[08:36] <didrocks> vila: something to add to the list for the migration: ensuring that the launchpad creds (like ps-jenkins) are refreshed
[08:37] <vila> didrocks: from the jenkins user ?
[08:37] <didrocks> vila: ps-jenkins in launchpad
[08:38] <vila> didrocks: lp side yes, but ci side ?
[08:38] <didrocks> vila: ci side is using launchpadlib
[08:38] <didrocks> under jenkins@ on the host
[08:38] <didrocks> when using launchpadlib, we need to use the credential of ps-jenkins
[08:39] <didrocks> for being able to do merge proposal
[08:39] <vila> didrocks: understood
[08:39] <vila> idcan't remember where those credentials are stored though
[08:40] <didrocks> vila: well, cu2d tweaks that
[08:40] <didrocks> but default it's ~/.launchpadlib/
[08:40] <didrocks> we changed it to /var/lib/jenkins/cu2d/launchpad.cache
[08:40] <didrocks> in cu2d
[08:41] <didrocks> (well ~jenkins/cu2d/launchpad.cache)
[08:41] <didrocks> set as an env variable
[08:41] <didrocks> but the issue there is that we changed the host
[08:41] <didrocks> so the cred is found, but doesn't match
[08:42] <Mirv> didrocks: ok, doing
[08:42] <Mirv> (republishing)
[08:43] <didrocks> ok, there is the auth link
[08:43] <didrocks> and done!
[08:43] <didrocks> cihelp: ok, I renewed the creds myself
[08:44] <vila> didrocks: how ?
[08:44] <didrocks> vila: logged in as ps-jenkins on launchpad
[08:44] <didrocks> then following that job: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-3.0publish/298/console
[08:44] <didrocks> there was the authorization link (issued by bzr lp-proposed when using launchpadlib)
[08:44] <Mirv> right, now it went through
[08:44] <didrocks> clicked on it
[08:44] <didrocks> authorized "until I disable it"
[08:45] <didrocks> and then, it went through
[08:45] <Mirv> I also opened the last link, but hesitated on clicking
[08:45] <didrocks> Mirv: yep ;)
[08:45] <didrocks> Mirv: well, you need to be ps-jenkins on launchpad
[08:45] <Mirv> didrocks: yeah, that's what I thought
[08:45] <didrocks> otherwise, the MP will fail :)
[08:45] <vila> didrocks: and who owns the ps-jenkins credentials on launchpad ?
[08:45] <Mirv> nice
[08:45]  * didrocks thinks now about delogging as ps jenkins to not post some "good comments" on lauchpad
[08:45] <didrocks> what I did a year ago :p
[08:46] <didrocks> vila: I guess it's now you. It was mostly francis and I before
[08:46] <didrocks> (you as CI team)
[08:46]  * vila nods
[08:46] <didrocks> vila: IIRC, the creds are on the canonical wiki as well
[08:46] <vila> didrocks: will check with fginther
[08:47] <didrocks> vila: yeah, I have them stored in my browser creds if needed
[08:47]  * didrocks back as "didrocks" in launchpad
[08:48] <vila> didrocks: I am not sure you want to give me access to your browser creds ;)
[08:48] <didrocks> vila: let me think about it… hum… NO ;)
[08:49] <vila> didrocks: as long as q-jenkins is unblocked, I can wait for fginther to sort this out
[08:49] <didrocks> right, I didn't want that we loose half a day because of this
[08:49] <vila> didrocks: what I don't get is why we didn't run into that earlier. First publication ?
[08:49] <didrocks> vila: yeah, first publication
[08:50] <vila> didrocks: are there any other... "operation" that hasn't been tried at least once ?
[08:50] <didrocks> vila: well, copying to distro (passing the 2 firewalls and so on)
[08:50] <didrocks> but it just succeeded
[08:51] <didrocks> vila: https://lists.ubuntu.com/archives/trusty-changes/2013-November/002397.html
[08:52] <didrocks> vila: I think now that Mir is almost fixed and once Mirv finishes upstart-app-launch, we'll start rebuilding everything automatically every 8 hours as we used to
[08:52] <didrocks> that will be the last job to enable
[08:53] <vila> didrocks: aka manualpublish=False ?
[08:53] <didrocks> vila: no, this only impacts publication
[08:54] <didrocks> not building everything
[08:54] <didrocks> building everything is the *build_all jobs
[08:54] <didrocks> which starts building all the stacks in order
[08:57] <vila> didrocks: so still manual publishing. Disabling the *build_all was a q-jenkins only change, nothing to look for in any branch right ?
[08:58] <didrocks> vila: indeed
[08:58] <vila> ok
[08:58] <vila> didrocks: and what was the issue with autopilot-daily-release (sp?) not mentioning the right otto nodes ?
[08:59] <didrocks> vila: not sure to understand, the email I forwarded you or something else?
[09:00] <vila> didrocks: almost, haven't seen this email before you mentioned it, topic.pushed
[09:00] <vila> didrocks: but same job
[09:01] <didrocks> vila: not sure, I didn't look at it. I'll leave it to you guys :)
[09:01] <vila> didrocks: yesterday it wasn't using the right nodes in the config matrix, couldn't understand why
[09:02] <didrocks> vila: not sure I was aware about that one
[09:02] <didrocks> seems the AP tests pass for the sdk here
[09:03] <vila> didrocks: we did look at it in https://wiki.canonical.com/UbuntuEngineering/CI/NewRelease hence my question, something to add to the playbook when handling cu2d otto nodes no ?
[09:04] <didrocks> vila: nothing out the existing instructions as far as I know
[09:05] <vila> didrocks: well, I can of answered myself. I just want you to ack that one so I don't search for some script that is updating that job if there is none ;) (Always hard to find something that doesn't exist ;)
[09:05] <didrocks> vila: that job was setup initialy by Francis, but I guess he did it manually
[09:06] <vila> didrocks: ack, thanks
[09:06] <didrocks> yw
[09:08] <vila> didrocks: thanks for unblocking that ps-jenkins creds issue.
[09:09] <didrocks> yw!
[09:11] <vila> didrocks: if we want to get away from such situations, we need to document them, we have enough in the discussion above to do so. That's my whole point: getting things documented so we don't require human intervention from people in other time zones.
[09:12] <didrocks> not sure what that was about, but "ok"
[09:13]  * didrocks told for that on purpose:
[09:13] <didrocks> 09:36:34 didrocks | vila: something to add to the list for the migration: ensuring that the launchpad creds (like ps-jenkins) are
[09:13] <didrocks>                   | refreshed
[09:13] <didrocks> so that it was getting noted down
[09:13] <vila> didrocks: yup, we're in a violent agreement :)
[09:16] <vila> didrocks: I asked for clarifications as it wasn't clear to me what the implications were. Last time I ran into such an issue, I was blocked at not being able to access to the browser referred to in the message. I didn't think about launching the browser myself (and would have been blocked by the lack of ps-jenkins creds anyway)
[09:17] <vila> didrocks: so I thought there was another way to do that from a script (apparently not)
[09:17] <didrocks> vila: yeah, you would have been blocked by the lack of ps-jenkins creds, but yeah, you can either endure using a local lynx, or use another browser in another machine
[09:17] <didrocks> vila: well, it's creds to be acked by a human, I don't think launchpad will like if we screenscrap
[09:18] <vila> didrocks: yeah, I may have been tainted by how u1 do that, there is a way to get an oauth token for them
[09:18] <vila> didrocks: without using a browser at all, but that's sso not launchpad
[09:19] <didrocks> yeah, it's not oauth2, it's a special auth per machine/apps
[09:30] <sil2100> Damn, the pl archive mirror is slow as hell...
[09:31] <sil2100> Can't upgrade anything
[09:38] <mardy> hi! Can someone please modify this job, and remove the online-accounts-qt5-staging PPA from it? https://jenkins.qa.ubuntu.com/job/accounts-qml-module-trusty-amd64-autolanding/1/console
[09:45] <psivaa> mardy: let me take a look
[10:03] <seb128> does anyone knows why CI is not running on https://code.launchpad.net/~agateau/libdbusmenu-qt/cmake-config/+merge/192895 ?
[10:04] <seb128> there was a landing failed and a commit to fix it then
[10:04] <seb128> but it didn't get retried since
[10:04] <seb128> is that part of the infra supposed to be back?
[10:04] <psivaa> vila: would you mind reviewing the change, https://code.launchpad.net/~psivaa/cupstream2distro-config/remove-online-accounts-qt5-staging-ppa/+merge/195736 for mardy's request above please?
[10:05] <psivaa> this is the first time, so apologies if i made any mistakes :)
[10:06] <mardy> psivaa: however it goes, thanks a lot! :-)
[10:09] <vila> psivaa: done
[10:10] <psivaa> vila: thank you
[10:16] <didrocks> Mirv: ubuntu-ui-toolkit not there yet?
[10:16] <seb128> hello there?
[10:17] <seb128> is that the right channel to ask about CI?
[10:17] <psivaa> seb128: sorry just looking at your issue
[10:18] <seb128> psivaa, hey, thanks!
[10:22] <Mirv> didrocks: autopkgtests still running
[10:22] <didrocks> ok, let's cross fingers :)
[10:23] <Mirv> didrocks: it seems I'm getting this glitch now both for ui-toolkit (which I approved already manually which worked) and now upstart-app-launch: https://code.launchpad.net/~ps-jenkins/upstart-app-launch/latestsnapshot-0.2+14.04.20131119-0ubuntu1/+merge/195732
[10:24] <Mirv> and then for cihelp: can you investigate why http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-2.2check/394/console is marked as failure even though the tests were green? is that result file not existing a clue?
[10:26] <didrocks> Mirv: yeah, check with the CI team I guess (for the glitch as well)
[10:28] <didrocks> ev: can you add those 2 to the list? it's still blocking/slowing down a lot the deliveries ^
[10:28] <didrocks> (understanding the second one, the first one seems a regression since passing on the new infra, and we can't reapprove every failed MP)
[10:28] <psivaa> seb128: i've kicked off the job, http://s-jenkins:8080/job/libdbusmenu-qt-autolanding/11/console for more information
[10:28] <seb128> psivaa, thanks
[10:29] <ev> psivaa: ^ since you're in vanguard mode, would you mind grabbing that one?
[10:29] <psivaa> ev: doing that
[10:30] <Mirv> didrocks: psivaa: ok, thanks for adding.
[10:32] <ev> thanks muchly
[10:40] <psivaa> Mirv: the failure is due to the result file being unavailable, but i'm still looking into why that's unavailable
[10:42] <psivaa> Mirv: it could be a temp issue, thinking of kicking off the master job again if you are ok with it
[10:44] <Mirv> psivaa: ok, feel free to retry
[10:45] <psivaa> Mirv: running again, http://q-jenkins.ubuntu-ci:8080/job/cu2d-sdk-head/443/console
[10:47] <vila> didrocks: back to ps-jenkins creds, the cred file is ~jenkins/.cupstream_cred but launchpad needed to be told that the access should be granted from a new host ? (The cred file itself has not been modified since last year)
[10:48] <didrocks> vila: ~jenkins/.cupstream_cred is the cu2d cred, not the launchpad cred, right?
[10:48] <didrocks> vila: not sure, I don't have access to that file
[10:48] <didrocks> vila: but I know that launchpad have creds per machines
[10:48] <didrocks> vila: and it seems bzr lp-propose needed that cred
[10:49] <didrocks> can only tell you that with the FHS access I have
[10:49] <vila> didrocks: well, not sure, but launchpadmanager.py refers to that file so I'd say that's the cu2d creds to access launchpad
[10:49] <didrocks> vila: again, it's not cu2d but bzr lp-propose
[10:49] <didrocks> at this stage
[10:50] <vila> didrocks: ha, then it may not care about the env var used by cu2d, resuming investigations
[10:51] <didrocks> psivaa: are you working on the second issue that Mirv discussed and sent to ev? I only see you discussing the -check one
[10:52] <psivaa> didrocks: ok, i thought that was the second issue
[10:53] <didrocks> 11:23:04     Mirv | didrocks: it seems I'm getting this glitch now both for ui-toolkit (which I approved already manually which worked) and now upstart-app-launch:
[10:53] <didrocks>                   | https://code.launchpad.net/~ps-jenkins/upstart-app-launch/latestsnapshot-0.2+14.04.20131119-0ubuntu1/+merge/195732
[10:53] <didrocks> that one ^
[10:53] <psivaa> didrocks: i'll take a look at that now
[10:53] <didrocks> thanks
[11:05] <Mirv> didrocks: both ubuntu-ui-toolkit and upstart-app-launch now in release pocket
[11:06] <didrocks> Mirv: \o/
[11:06] <didrocks> ogra_: when you are around, mind kicking a build?
[11:06] <ogra_> sure
[11:07] <ogra_> [11:11] <didrocks> thanks ogra_!
[11:20] <psivaa> seb128: just in case you haven't noticed, the jobs succeeded http://s-jenkins:8080/job/libdbusmenu-qt-autolanding/11/console
[11:20] <seb128> psivaa, I did notice, thanks!
[11:21] <psivaa> seb128: yw
[11:32] <Mirv> cihelp still getting "Unable to connect to naartjie:http:" https://jenkins.qa.ubuntu.com/job/mir-trusty-amd64-autolanding/13/console
[11:32] <Mirv> repeatedly, https://code.launchpad.net/~vanvugt/mir/fix-1252144-v2.trunk/+merge/195718
[11:32] <psivaa> Mirv: similar issue to what we saw yesterday
[11:32] <psivaa> Mirv: i'll take a look at that
[11:33] <Mirv> thanks psivaa
[11:46] <retoaded> Mirv, the node that job was run on should be able to hit naartjie now. Had a static (and old) entry for naartjie in it's /etc/hosts
[11:50] <Mirv> thanks retoaded, trying again
[11:51] <retoaded> Mirv, now as long as the VM doesn't "revert" the /etc/hosts entries right back into place.
[11:51] <psivaa> Mirv: i already kicked one off
[11:51] <Mirv> psivaa: ok
[11:51] <psivaa> and it failed for the same reason..
[11:52] <psivaa> when fginther tried it yetsterday it worked. something flaky.. ill run it again
[11:52] <retoaded> psivaa, did it run on the same host as the previous run?
[11:52] <Mirv> it never succeeded at https://code.launchpad.net/~vanvugt/mir/fix-1252144.trunk/+merge/195547 and I ended up merging it manually yesterday
[11:54] <mardy> psivaa: are you waiting for more reviews, or can you set https://code.launchpad.net/~psivaa/cupstream2distro-config/remove-online-accounts-qt5-staging-ppa/+merge/195736 as approved?
[11:54] <psivaa> Mirv: it was an armhf run but failing to reach naartjie was the issue
[11:54] <psivaa> retoaded: the nodes were different
[11:55] <psivaa> mardy: i think i can top approve it too, and merge it
[11:56] <psivaa> retoaded: the latest amd64 failure to reach naartjie is from ps-precise-server-amd64-smp-2
[11:56] <retoaded> psivaa, my guess would be that the problem is twofold: (1) most of the VMs have an incorrect (old) entry for naartjie in their /etc/hosts file and (2) the VMs that have snapshots will revert back to their original state so removing the entry from a running VM won't necessarily work for the next run
[11:57] <retoaded> psivaa, that would prove point 2 since that was the VM I had just changed.
[11:58] <psivaa> retoaded: ohh, so the vms snapshots need to be changed
[11:58] <retoaded> psivaa, for some of these.
[11:58] <psivaa> quite a job i suppose
[11:59] <retoaded> I'm in ps-precise-server-amd64-smp-2 now and it wasn't reverted and CAN connect to naartjie
[12:00] <psivaa> mardy: i've merged the change, and kicked off another run http://s-jenkins:8080/job/accounts-qml-module-trusty-amd64-autolanding/2/console
[12:00] <Mirv> feel free to try to get https://code.launchpad.net/~vanvugt/mir/fix-1252144-v2.trunk/+merge/195718 merged
[12:09] <psivaa> retoaded: which host are these ps-precise-server-amd64-smp-2 like vms are on?
[12:09] <mardy> psivaa: thanks a lot
[12:14] <ogra_> [12:14] <popey> \o/
[12:15] <mardy> psivaa: mmm... it seems that the PPA is still there :-( https://jenkins.qa.ubuntu.com/view/Trusty/view/All/job/accounts-qml-module-trusty-amd64-autolanding/lastFailedBuild/console
[12:15] <psivaa> mardy: yea, looking why the change dint take into effect
[12:22] <psivaa> Mirv: you might have noticed that http://q-jenkins.ubuntu-ci:8080/job/cu2d-sdk-head-2.2check/396/console is still having the same issue,
[12:22] <psivaa> would need fginther again i'm afraid
[12:23] <psivaa> mardy: http://s-jenkins:8080/job/accounts-qml-module-trusty-amd64-autolanding/4/console
[12:24] <mardy> psivaa: \o/ thanks!!
[12:26] <Mirv> psivaa: yep, please keep that one too on the radar
[12:27] <psivaa> Mirv: ack. that's on my list to discuss this afternoon.
[13:00] <didrocks> ev: vila: Mirv: ogra_: coming?
[13:01] <Mirv> didrocks: aha, the new time
[13:02] <Mirv> yes
[13:02] <cwayne_> Mirv, thanks for getting the upstart-app-launch landed :D
[13:03] <Mirv> cwayne_: you're welcome
[13:50] <fginther> morning
[13:59] <Ursinha> fginther, morning
[13:59] <josepht> good morning
[14:03] <fginther> Mirv, psivaa, I found an old /etc/hosts entry that was breaking the mir-autolanding. Re-testing
[14:22] <sil2100> fginther: hello!
[14:22] <didrocks> cihelp: I can't start http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/All/job/cu2d-build_all-head/, seems the network is timing out
[14:22] <sil2100> fginther: do you know if the merger is enabled for unity-scopes-api?
[14:23] <didrocks> cyphermox: FYI, we are blocked by that ^
[14:23] <cjohnston> didrocks: you can try it again, but we are still having network issues
[14:23] <didrocks> cjohnston: yeah, so it means we can't start cu2d due to that
[14:23] <cjohnston> what's the url it is trying to open?
[14:24] <didrocks> cjohnston: accessing launchpad it seems from the console
[14:24] <didrocks> hum, no jenkins in fact?
[14:24] <didrocks>     response = self.jenkins_open(urllib2.Request(self.server + JOB_INFO%locals()))
[14:24] <didrocks> I bet self.server is refering an old ip
[14:25] <didrocks> cjohnston: are you handling it or should I? ^
[14:26] <cjohnston> didrocks: I'm looking into it, but don't really know what I'm looking at.. jenkins seems to have the correct address setup
[14:26] <cjohnston> is it in one of the config branches?
[14:26] <fginther> Mirv, psivaa, lp:cupstream2distro needs update, it assumes jenkins jobs are archived under “/var/lib/jenkins”. The jenkins root was moved to “/iSCSI/jenkins”
[14:26] <fginther> Mirv, psivaa this is causing the cu2d-sdk-head-2.2check failures
[14:27] <didrocks> fginther: they are still archived in /var/lib/jenkins, right?
[14:27] <vila> fginther: which are both ~jenkins
[14:27] <didrocks> ah
[14:27] <psivaa> fginther: ok, thanks
[14:27] <vila> fginther: or not ?
[14:27] <didrocks> cjohnston: I guess it's in cu2d
[14:27] <fginther> sil2100, ahh, getting to it now
[14:28] <didrocks> cjohnston: in the code referenced in the console
[14:28] <didrocks>         self.jenkins_url = "%s/job/%%s/buildWithParameters?token=%s" \
[14:28] <didrocks>                     % (self.jkcfg['url'], self.jkcfg['token'])
[14:28] <sil2100> fginther: thank youu! Could you also do the same for unity-scopes-shell if you have a moment?
[14:28] <didrocks> built from JKCFG
[14:29] <didrocks>     JKCFG = load_jenkins_credentials(DEFAULT_CREDENTIALS)
[14:29] <xnox> OTA updates should be renamed to "didrocks updates" =)
[14:29] <sil2100> fginther: it's not added to cu2d though yet...
[14:29] <kenvandine> xnox, indeed
[14:29] <didrocks> xnox: heh, seems so ;)
[14:29] <didrocks> def load_jenkins_credentials(path):
[14:29] <didrocks>     cred = yaml.load(file(path, 'r'))
[14:29] <didrocks> DEFAULT_CREDENTIALS = os.path.expanduser('~/.cu2d.cred')
[14:29] <didrocks> ok, so that's what need to be updated
[14:29] <didrocks> vila: cjohnston: so ~jenkins/.cu2d.cred
[14:30] <didrocks> I guess we need to change the url
[14:30] <didrocks> so match the new jenkins instance
[14:30] <didrocks> can one of you do that please? ^
[14:32] <cjohnston> workin on it
[14:32] <didrocks> thanks!
[14:32] <didrocks> cjohnston: then, can you try relaunch the job? it should work then
[14:33] <cjohnston> grr
[14:33] <cjohnston> fginther: do you have sudo on q-jenkins?
[14:33] <fginther> cjohnston, nope
[14:34] <cjohnston> hrm
[14:34] <cjohnston> retoaded: ^
[14:34] <fginther> sil2100, do you have an MP for unity-scopes-shell?
[14:35] <retoaded> cjohnston, on it
[14:36] <retoaded> cjohnston, done
[14:36] <vila> cjohnston: we need to document that, I left a req for fginther about lp credentials for ps-jenkins already but this seems to be a new file (and I'm already knee deep in dx-autopilot-nvidia re-provisioning)
[14:36] <fginther> Mirv, psivaa, filed a bug for the path update: https://bugs.launchpad.net/cupstream2distro/+bug/1252750
[14:37] <cjohnston> retoaded: while your in there could you please give me sudo?
[14:37] <vila> didrocks: how come we're talking about a different creds file  now ? I didn't mention that one this morning because IIRC jibel is mentioned in .cu2d.cred and I thought that was an obsolete file since you unblocked a different job
[14:37] <didrocks> vila: this is the "build all"
[14:38] <didrocks> vila: what we didn't run yet
[14:38] <didrocks> as told this morning
[14:38] <didrocks> vila: this is not a launchpad cred
[14:38] <didrocks> but the cu2d creds
[14:38] <retoaded> cjohnston, done
[14:38] <vila> didrocks: and what about .cu2d.jenkins and .cupstream_cred ?
[14:39] <didrocks> vila: not having access to the file system in read mode, I can't tell you
[14:39] <cjohnston> ta
[14:40] <cjohnston> didrocks: running
[14:40] <didrocks> cjohnston: \o/ let's cross figners
[14:40] <didrocks> fingers*
[14:41] <didrocks> ok, everything triggered now
[14:41] <didrocks> let's see how the network will support that :)
[14:41] <didrocks> cyphermox: FYI (as you are tracking indicators) ^
[14:41] <didrocks> cyphermox: can you ask seb/add yourself a landing task for tracking this request?
[14:44] <cyphermox> alright
[14:44] <didrocks> thanks!
[14:45] <didrocks> cjohnston: thanks for making the change ;)
[14:45] <cjohnston> didrocks: :-)  still need help sometimes, but best way to learn is to do
[14:45] <didrocks> yep!
[14:46] <cyphermox> done
[14:46] <cyphermox> which slot?
[14:46] <didrocks> cyphermox: just add one
[14:46] <didrocks> (but pick a cool one! ;))
[14:47] <cyphermox> 312
[14:47] <cyphermox> but I mean the landing slot or whatever
[14:47] <cyphermox> column two?
[14:48] <didrocks> cyphermox: ah, next image (so 25)
[14:48] <didrocks> if possible
[14:48] <cyphermox> aye
[14:48] <didrocks> cyphermox: of course, needing dogfooding :)
[14:48] <cyphermox> yeah yeah
[14:48] <cyphermox> dogfooding is what I do :)
[14:49] <Mirv> hmm, who started mir stack build? the merge is not yet in.
[14:49]  * didrocks waits for catfooding
[14:49] <cyphermox> nummy
[14:49] <didrocks> Mirv: we restarted to build everything to test the infra
[14:49]  * Mirv notices the queue
[14:49] <didrocks> Mirv: I guess Mir will need to be rebuild once the merge is in
[14:49] <Mirv> alright :)
[14:50] <cyphermox> speaking of catfooding, I need to get breakfast
[14:50] <didrocks> cypherfooding
[14:52] <seb128> didrocks, cyphermox: do you know why those sort of things happen? https://code.launchpad.net/~ps-jenkins/ubuntu-system-settings/latestsnapshot-0.1+14.04.20131119-0ubuntu1/+merge/195787
[14:53] <didrocks> seb128: yeah, vila and fginther are looking at those
[14:53] <seb128> didrocks, should we retry the approval there?
[14:54] <didrocks> seb128: seems we lost a patch in the migration in bzr, fginther will do it in another way
[14:54] <seb128> ok
[14:54] <didrocks> seb128: well, that will work, but that won't help them testing their change I guess
[14:54] <seb128> I'm just going to wait for them to fix it then
[14:54] <didrocks> I think that fginther and vila will relaunch the failing one then ^
[14:55] <fginther> didrocks, seb128, ack. Once we get it sorted we'll process the failed ones
[15:43] <ev> cwayne_: reposting here
[15:43] <ev> 3:42 PM <cwayne_> ev, any idea why nasuka can't get to s-jenkins still?
[15:43] <ev> nope, but I'm trying to coordinate a UDS session, so asking our vanguard, cjohnston
[15:44] <ev> cjohnston: I tried to fix this with https://code.launchpad.net/~ev/canonical-is-puppet/ci-fw-rules but there's apparently something I'm missing :)
[15:46] <cjohnston> cwayne_: can I get more context please?
[15:48] <cwayne_> cjohnston, it needs to poll s-jenkins to get the customization tarball to build customized images
[15:48] <cjohnston> cwayne_: is this a jenkins instance that does this or?
[15:49] <cwayne_> cjohnston, trying to loop in stephane as he knows more than i do
[15:49] <cwayne_> but my understanding is system-image polls s-jenkins to get the latest custom tarball then builds it
[15:52] <cwayne_> cjohnston, it being the image
[15:52] <cwayne_> cjohnston, <stgraber> cwayne_: nusakan can't talk to s-jenkins, I don't have any more detail than that
[16:01] <cjohnston> cwayne_: this appears to be an issue for IS
[16:01] <cwayne_> cjohnston, can you get me some information so that i know what to ask is?
[16:14] <fginther> sil2100, can you also review these 2:
[16:14] <fginther> https://code.launchpad.net/~fginther/cupstream2distro-config/add-mediascanner-v2/+merge/195662
[16:14] <fginther> https://code.launchpad.net/~fginther/cupstream2distro-config/unity-7.1/+merge/195663
[16:14] <sil2100> fginther: looking!
[16:16] <sil2100> fginther: do you know why the saucy support branch changed to /7.1 ?
[16:16] <ev> heads up: we're discussing the new architecture for the CI system in http://summit.ubuntu.com/uds-1311/meeting/22092/core-1311-ci-airline/
[16:16] <ev> right now
[16:16] <fginther> sil2100, I think the unity team started using that w/o knowing lp:unity/saucy was there
[16:17] <sil2100> ah, ok
[16:38] <sil2100> fginther: I'll be approving the unity cu2d merge in a moment :)
[17:05] <Mirv> kenvandine: robru: I updated the landing plan to reflect that the (another) mir fix was now finally merged so it should be possible to try building the chain (although cu2d is now a bit busy)
[17:06] <kenvandine> Mirv, so what needs rebuilding now?
[17:07] <Mirv> kenvandine: first mir, and then platform-api, unity-mir and unity-system-compositor against it. then it should be ready to test.
[17:08] <robru> kenvandine, do you have that under control? I'm on my way out for lunch but I can help test when I get back.
[17:09] <kenvandine> robru, i'm on my way out too
[17:09] <kenvandine> robru, lets sync up after lunch
[17:09] <ev> cjwatson, didrocks: I couldn't find a space you'd both fit in for the CI airline implementation UDS session, so I'll schedule it for after UDS
[17:09] <cjwatson> OK, thanks
[17:09] <didrocks> ev: yeah, my track is full, so after UDS sounds good
[17:44] <vila> didrocks, Mirv: https://code.launchpad.net/~vila/cupstream2distro-config/no-nvidia/+merge/195838
[17:44] <vila> autopilit-nvidia is coming back
[17:44] <didrocks> vila: this time, you are handling the deployment of it right?
[17:45] <didrocks> vila: btw, on your MP, you changed raring
[17:45] <didrocks> this is harmless but useless as well
[17:46] <didrocks> those otto machines won't run raring changes, right?
[17:47] <vila> didrocks: deploying will require me to be part of desktop-team right ?
[17:48] <didrocks> vila: no, you can redeploy with -US
[17:48] <vila> didrocks: I strictly reverted my first proposal
[17:48] <didrocks> vila: you just need the cu2d creds
[17:48] <didrocks> vila: yeah, and I already wrote that on IRC in the first proposal
[17:48] <didrocks> (but it was already merged)
[17:49] <didrocks> vila: please don't deploy stacks that are running, remember the jenkins limitation around running jobs while deploying
[17:49] <vila> didrocks: ha, the ones fginther and I suspect are invalid and not used anymore because your team deploy from their desktop ? ~jenkins/.cu2d.jenkins ?
[17:49] <vila> didrocks: yeah, right, will sync with Mirv tomorrow morning then, safer and easier
[17:49] <Mirv> vila: yes, let's look at it in the morning
[17:49] <didrocks> vila: I only know about ~/.cu2d.cred
[17:50] <didrocks> not .cu2d.jenkins
[17:50] <om26er> fginther, got a minute ?
[17:50] <didrocks> (and it's about running a stack as well, it's not only deploying)
[17:50] <vila> didrocks: ack, thanks, will take the opportunity to investigate a bit then, fginther thought ~jenkins/.cu2d.jenkins was exactly for that: updating jobs
[17:51] <didrocks> not that I know of
[17:51] <vila> didrocks: ack
[17:59] <robru> kenvandine, back yet? I'll be watching a UDS session but can kick a build if necessary
[17:59] <kenvandine> robru, it's building
[17:59] <kenvandine> finishing now :)
[18:19] <robru> kenvandine, so looks like mir built but unity-system-compositor failed, and platform-api is still in progress. just waiting for platform-api then? or do we need u-s-c?
[18:19] <kenvandine> robru, humm... i hadn't built those yet
[18:19] <kenvandine> they needed new mir
[18:19]  * kenvandine starts it
[18:20] <robru> kenvandine, well it looked to me like somebody just kicked the whole mir stack, which includes u-s-c, but that failed
[18:20] <kenvandine> it failed 41m ago though
[18:20] <kenvandine> the mir build wasn't published yet in the PPA
[18:21] <robru> kenvandine, says published 36 minutes ago for me.
[18:21] <kenvandine> right
[18:21] <kenvandine> the failure was 41m ago
[18:22] <kenvandine> 48 now
[18:22] <robru> kenvandine, wait, what? if the build failed 50m ago, then were did the upload in the PPA come from?
[18:22] <kenvandine> from prior to that
[18:22] <kenvandine> i did a run with just mir
[18:22] <kenvandine> not the whole stack
[18:23] <robru> kenvandine, ugh: https://launchpadlibrarian.net/156925071/buildlog_ubuntu-trusty-amd64.unity-system-compositor_0.0.1%2B14.04.20131119-0ubuntu1_FAILEDTOBUILD.txt.gz boost!
[18:24] <kenvandine> robru,  that was from an upload from 3 hours ago
[18:24] <kenvandine> ignore that
[18:24] <robru> heh
[18:24] <kenvandine> crap
[18:25] <kenvandine> now the amd64 upload i just did failed :/
[18:25] <kenvandine> same failure :(
[18:27] <kenvandine> boost1.54 is held in proposed
[18:29] <fginther> om26er, pong
[18:29] <om26er> fginther, here: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/3451/console it seems to not able to install unity8-autopilot. Can you think of a reason why it was not ?
[18:32] <robru> kenvandine, so what then? we have to wait for this boost transition to complete?
[18:32] <fginther> om26er, looking
[18:33] <kenvandine> robru, lets look at why it's held
[18:33] <robru> kenvandine, how?
[18:33] <kenvandine> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[18:33] <kenvandine> look at boost1.54
[18:34] <kenvandine> those are the deps that need transitioning
[18:34] <kenvandine> lets narrow that down by seeing what's already been uploaded to proposed
[18:34] <robru> kenvandine, so what, those need no-change rebuild uploads?
[18:34] <kenvandine> maybe
[18:34] <kenvandine> usually
[18:34] <kenvandine> sometimes they might need build deps changed
[18:35] <kenvandine> like libboost1.53-dev to libboost1.54-dev
[18:35] <kenvandine> but i hope not
[18:35] <kenvandine> boost is annoying
[18:35] <robru> kenvandine, yeah, I've had lots of bad experiences with boost in the past
[18:35] <kenvandine> although
[18:35] <kenvandine> this is just an ubuntu rev
[18:35] <kenvandine> not major version
[18:36] <kenvandine> i just enabled proposed on my laptop, to see what complains
[18:37] <fginther> om26er, ah
[18:38] <fginther> om26er, the unity8 armhf build failed in the PPA
[18:38] <om26er> darn
[18:38] <fginther> om26er, https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?batch=75&memo=225&start=225
[18:38] <fginther> om26er, I'll try to rebuild it
[18:38] <om26er> fginther, thanks :)
[18:39] <fginther> om26er, but I don't have permissions :-( let me find someone who can
[18:39] <fginther> sil2100, kenvandine, cyphermox can one of you look at the unity8 armhf build in the daily PPA? It failed to build, can it be retried?
[18:40] <cyphermox> sure I'll look
[18:40] <sil2100> cyphermox: thanks!
[18:41] <fginther> cyphermox, looks like unity-mir armhf failed also
[18:41] <cyphermox> right
[18:41] <cyphermox> and that's why unity8 failed
[18:43] <cyphermox> I'm retrying unity-mir to see, but I think all of the unity stack needs to be rebuilt now that platform-api has changed / been uploaded to the PPA
[18:51] <robru> kenvandine, something is goofy with the timestamps here. your latest rebuild says mir built fine 30 mins ago, but ppa only has mir from 1hr ago
[18:52] <kenvandine> boost-mpi-source1.54 needs a rebuild
[18:52] <kenvandine> robru, the PPA finished building before cu2d noticed it was built
[18:52] <kenvandine> it checks every 5 minutes
[18:52] <kenvandine> and it only notices after it has been published in the PPA
[18:53] <kenvandine> so a bit after the build finishes
[18:53] <robru> kenvandine, so checking every 5 minutes means that it finished in the PPA 30 minutes before jenkisn notices?
[18:53] <kenvandine> robru, oh... that time is when the package was uploaded
[18:53] <kenvandine> source that is
[18:53] <kenvandine> not when the build finished
[18:53] <robru> kenvandine, it says "Published: 1 hour ago" https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?field.name_filter=mir&field.status_filter=published
[18:54] <kenvandine> this is annoying... the boost-mpi-source1.54 binaries depend on binariers from the boost1.54 package, but $Binary:Version
[18:54] <kenvandine> robru, yeah, that is when the source was published
[18:54] <robru> kenvandine, oh, ok
[18:54] <kenvandine> not when the binary was published
[18:54] <robru> kenvandine, so do you have to distropatch it to be $Source:Version?
[18:56] <cjwatson> boost-mpi-source1.54 requires careful manual handling
[18:56] <cjwatson> ask xnox to help you
[18:58] <kenvandine> robru, he's handling it
[19:04] <cyphermox> fginther: right, unity-mir passed to I'll have unity8 and unity-mir rebuilt now
[19:04] <fginther> cyphermox, thanks!
[19:49] <sergiusens> doanac`, hey, any insight why the clicks failed so badly? They worked fine on yesterday's latest proposed
[19:49] <doanac`> sergiusens: let me take a look. plars have you happened to investigate that already?
[19:50] <plars> doanac`: no hadn't looked yet
[19:51] <doanac`> i'll poke around
[19:53] <sergiusens> doanac`, thanks
[19:53] <doanac`> sergiusens: here's one that looks like a legitimate regression to me: http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/24:20131119:20131111.1/5037/ubuntu-weather-app-autopilot/521212/
[19:54] <sergiusens> doanac`, fwiw, the weather app has more tests now ;-)
[19:54] <sergiusens> doanac`, and the whole swipe to delete thing has caused many apps to be an inconsistent state
[19:55] <doanac`> sergiusens: you mean we should have run more tests for that today?
[19:55] <sergiusens> doanac`, they pass merger I think because fginther has the proposed PPA for testing/building, but the image of course doesn't :-)
[19:56] <sergiusens> doanac`, actually, weather is an improvement :-)
[19:56] <sergiusens> doanac`, http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/23:20131118:20131111.1/5018/ubuntu-weather-app-autopilot/ vs http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/24:20131119:20131111.1/5037/ubuntu-weather-app-autopilot/
[19:56] <doanac`> rss and filemanager seem to have regressed
[19:56] <doanac`> i'm seeing some "StateNotFoundError" for filemanager
[19:57] <sergiusens> doanac`, filemanager has regressed for a while, the ap 1.4 thing never finished for it I think
[19:57] <sergiusens> doanac`, I wrote that in the transition pad
[19:57] <sergiusens> doanac`, this is the one that worries me: http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/24:20131119:20131111.1/5037/notes-app-autopilot/
[19:58] <sergiusens> doanac`, rssreader as well as it had only one fail on my device after multiple runs; and the one on the image had 2 atm
[19:58] <doanac`> sergiusens: ooh, that's no good. I've seen that locally where notes-app takes forever to run
[19:58] <doanac`> its timing out after 30 minutes
[19:59] <sergiusens> hey, I just noticed "Result History"
[19:59] <sergiusens> awesome
[19:59]  * doanac` came up with that :)
[20:00] <sergiusens> doanac`, kudos
[20:02] <sergiusens> doanac`, so this all coincides with a uitoolkit version upgrade as well; might be that some tests need updating.
[20:03] <doanac`> sounds quite possible
[20:50] <robotfuel> rfowler: ping
[21:30] <kenvandine> robru, i'll probably be gone when boost gets promoted
[21:30] <kenvandine> robru, you don't need to run the stack to get it to build, just click rebuild for each of the failed builds in the PPA
[21:30] <robru> kenvandine, no worries. I'm here for hours yet. I'll kick builds soon
[21:31] <robru> kenvandine, or that ;-)
[21:31] <kenvandine> once it's built in the PPA testing can start
[21:31] <kenvandine> and then you could do a stack run so it shows up in the publish job