[08:24] <sil2100> jibel, vila, Mirv, asac: hi!
[08:24] <sil2100> jibel, vila, Mirv, asac: I see that the otto cu2d check jobs are failing again with the Could not resolve 'archive.ubuntu.com' error
[08:24] <sil2100> Do anyone of you know what's up with that again? New DNS issues?
[08:24] <sil2100> retoaded: ^
[08:25] <vila> sil2100: url ?
[08:25] <sil2100> For instance, http://10.97.0.1:8080/job/autopilot-trusty-daily_release/396/label=qa-intel-4000/console
[08:25] <sil2100> On both nvidia and intel
[08:26] <Mirv> sil2100: hi!
[08:26] <sil2100> (so http://10.97.0.1:8080/job/autopilot-trusty-daily_release/396/label=autopilot-nvidia/console as well)
[08:26] <vila> /var/log/syslog: Nov  4 00:08:25 trusty-i386-20131104-0008 kernel: [86262.203773] type=1400 audit(1383523705.376:356): apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 parent=26433 profile="/sbin/dhclient" name="etc/ld.so.cache" pid=26437 comm="dhclient" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[08:26] <Mirv> sil2100: I don't know what's up this time, but the archive.ubuntu.com is not (again) reachable from magners either so maybe some firewall reconfiguration again?
[08:27] <sil2100> Mirv: yep, apparmour issues again...
[08:27] <sil2100> vila: what did we do last time to fix this actually...? ;)
[08:27] <vila> Mirv: wget archive.ubuntu.com works
[08:28] <vila> Mirv: works from magners, that's the only reliable check I know of, forget the others
[08:28] <sil2100> As we had this before, exactly the same issue I gues
[08:28] <Mirv> vila: ah, you're right, the firewall apparently just blocks ping
[08:28] <vila> Mirv: yes, for unknown IS reasons (probably good ;)
[08:28] <Mirv> vila: ping works from my own machine so I didn't think it'd be different. but right, so apparmor agian.
[08:28] <vila> Mirv: yes, I learned it the hard way too
[08:28] <sil2100> Everything is crimson red because of this sadly
[08:29] <vila> sil2100: probably not exactly the same, related to apparmor again though
[08:29] <vila> sil2100: same root cause as far as CI is concerned: a user job breaks the infrastructure because otto *requires* host and lxc to be up to date
[08:32] <sil2100> vila: *sighs*
[08:33] <vila> sil2100: yeah, don't tell me ;-/
[08:33] <vila> sil2100: not to mention all upstream-merger are stucked :-/
[08:34] <vila> sil2100: so, back to what was done last time: ping stgraber, he's the most efficient to diagnose the lxc/apparmor issues lately
[08:35] <veebers> vila: another question for you. I'm getting this error on the generic-mediumtest-runner-mako: qmlscene: could not find a Qt installation of ''
[08:35] <vila> sil2100: may be check if some updates occurred on apparmor or lxc ?
[08:35] <vila> veebers: you want to talk to autopilot devs to provide us a better error message ;)
[08:36] <vila> veebers: that's not the first time I see this undecipherable one
[08:36] <veebers> vila: heh, what I'm wondering is why /usr/bin/qmlscene doesn't work on that device?
[08:36] <veebers> that is the direct error message from running /usr/bin/qmlscene -testability /path/to/qml/file
[08:36] <vila> veebers: I didn't track what caused it the previous times sorry :-(
[08:36] <veebers> it works find on my device after a phablet-flash
[08:37] <sil2100> vila: will do ;)
[08:37] <vila> meh
[08:37] <vila> sil2100: not to mention all upstream-merger *maguros* are stucked :-/
[08:54] <jibel> vila, sil2100 from networking.log dhclient: error while loading shared libraries: libc.so.6: cannot open shared object file: Permission denied
[08:54] <vila> jibel: even worse ;)
[08:56] <jibel> vila, can you downgrade the kernel and see it makes the error go away?
[08:56] <jibel> on the host
[08:59] <vila> jibel: not yet, I'm restoring access to upstream merge maguros
[09:03] <jibel> vila, sil2100 this problem start on Nov. 1rst with kernel 3.12.0-1, rebooting with 3.11.0-12.19 should work. If it does ping the kernel team
[09:05] <didrocks> good morning
[09:31] <didrocks> sil2100: Mirv: psivaa: popey: meeting time!
[09:31] <psivaa> didrocks: joining
[09:32] <didrocks> sil2100: just waiting for you now ;)
[09:40] <didrocks> sil2100: not around? you shouldn't suffer from jet lag
[09:42] <sil2100> Crap!
[09:42] <sil2100> I got used to NOT having the meetings
[09:43] <Mirv> didrocks: the build probs should be have a mention at https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dHFtUmlPOUtCRk8zR2dtaEpIbUVhMmc#gid=3
[09:44] <sil2100> jibel, vila: we had the same issue last time with dhclient
[09:44] <sil2100> jibel, vila: I remember dhclient had problems also loading libc
[09:45] <jibel> sil2100, right but can you try to boot kernel 3.11, the incident began with 3.12 then notify the kernel team?
[09:46] <Mirv> sil2100: vila: I checked the other uploads and there are no dbus/lxc/apparmor uploads, so as jibel says downgrading the kernel would seem the first thing to try
[09:51] <ogra_> [09:52] <didrocks> \o/
[09:52] <ogra_> popey, promoted  10/20131031.1
[09:52] <ogra_> [09:53] <didrocks> great!
[09:54] <ogra_> hmpf ... compiz doesnt get the layer ordering right anymore ... funny ... all menus, tooltips and popups are behind all other windows ... even pulldowns in the browser
[09:58] <sil2100> \o/
[10:00] <popey> ogra_: super
[10:02] <didrocks> vila: hey! I tried to get in touch with doanac and it seems you didn't tell him that the execution test service should use the same parameters than the otto jobs?
[10:02] <didrocks> vila: do you take care of explaining what every parameters do or should I?
[10:20] <vila> didrocks: err, surprising...
[10:21] <didrocks> vila: you meant, you talk about them with him?
[10:21] <vila> didrocks: unless you mean the parameter *names* were different, I'm pretty sure the discussions mentioned them all
[10:21] <didrocks> vila: names and syntax are different
[10:21] <didrocks> like the tests is not the command running autopilot tests
[10:22] <vila> right, but the features are there right ? So it should be a matter of adapting both sides to agree no ?
[10:23] <didrocks> vila: well, that's what I discussed with you. That we can quickly plug that in and so adapt the parameters to what we have for now
[10:23] <didrocks> the semantic for some parameters are unfortunately different, I see a bigger road block on that one
[10:25] <vila> didrocks: right, so, since I don't know enough of the specifics on both sides to act as a proxy, better get in touch directly. In the midlle/long term though, I think we want to better separate setting up the environment and running the tests, it seems weird to have to implement the later differently in different tools
[10:25] <didrocks> vila: interesting, not sure why we had that meeting where I needed to explain to you all parameters though. Will talk with him directly then
[10:26] <vila> didrocks: so that I start to understand how cu2d works, I didn't have the same one with doanac and I thought the parameters and their intent were clear enough for him to ensure it will be providing the same semantic
[10:27] <didrocks> no worry, I'll fix that with him directly. I may have misunderstood the goal of this meeting apparently
[10:27] <vila> didrocks: I reported that meeting to the whole team and we even had a session were we discussed it...
[10:35] <vila> didrocks: correction, wasn't the whole team but only doanac and fginther
[10:35] <didrocks> ok
[10:38] <vila> didrocks: notes here https://docs.google.com/a/canonical.com/document/d/1ISclO4aN2CQ2vJ5PeryF2gt81lqX-5_-mmGADNrK04o/edit#heading=h.3nv3w86usggi but further work hasn't been tracked there :-/
[10:41] <vila> didrocks: so the overall feedback *I* got was that the features were ready or almost ready and my understanding was that some tweaks were required to have matching parameters. But I wasn't involved in the testing/coding so I din't (still don't) know the exact state.
[10:42] <didrocks> vila: I just opened the proposed job that was told ready and didn't see any evolution on the parameters
[10:42] <didrocks> compared to when we first discussed about it
[10:42] <vila> :-/
[10:56] <ogra_> [10:59] <didrocks> greatness!
[10:59] <didrocks> sil2100: http://bazaar.launchpad.net/~ubuntuone-hackers/ubuntu-download-manager/trunk/revision/151 can you SRU just that commit please?
[10:59] <didrocks> to saucy
[10:59] <didrocks> this is to avoid getting people on saucy in trouble
[10:59] <didrocks> (for the next 2 weeks)
[10:59] <didrocks> sil2100: old landing ask 266 (it's the short term fix)
[11:04] <sil2100> didrocks: ACK
[11:07] <sil2100> didrocks: ok, I see it's in saucy's trunk, so I guess I can use cu2d to get it in, right? There is only this commit in saucy trunk waiting for release
[11:07] <popey> ogra_: #11 I can't make phone calls. I can receive though
[11:07] <ogra_> popey, ouch
[11:08] <popey> hmm, cant send texts either, wonder if I have run out of credit
[11:08] <sil2100> didrocks: anyway, taking care of that this instance
[11:11] <didrocks> sil2100: just do what you prefer :)
[11:14] <vila> sil2100: qa-intell-4000 back to previous kernel, seems like otto is happy (minus the fact that it's supposed to always run in sync with the latest kernel....)
[11:14] <sil2100> vila: \o/
[11:14] <vila> sil2100: I tweak /etc/default/grub and that will need to be reverted when you have a fix
[11:15] <vila> *tweaked
[11:15] <sil2100> vila: well, at least we have tests running, too bad that with not the latest kernel but we'll switch to that once it's fixed properly
[11:15] <vila> sil2100: or otto_setup is run and breaks again... I think my tweak is not robust enough against that
[11:27] <popey> ogra_: phew, credit ran out
[11:28] <ogra_> phew
[11:33] <popey> ogra_: #11 seems good on mako
[11:34] <ogra_> great, still upgrading here
[11:37] <vila> sil2100: dx-autopilot-nvidia also reverted (with a better tweak also applied to qa-intel-4000)
[11:38] <sil2100> vila: will it still get broken again when otto_setup is ran?
[11:38] <vila> sil2100: a job spontaneously triggered on qa-intel-4000 which served as a test, can you trigger one for nvidia ?
[11:39] <vila> sil2100: it should stay on the same kernel but hey, we're in production, I couldn't test as much as I'd like there
[11:39] <sil2100> Let me trigger a quick one
[11:39] <vila> sil2100: so we'll need to revert the line added in /etc/default/grub, I've put a comment there so that should be easy
[11:40]  * vila lunches &
[11:40] <sil2100> Thanks! :)
[11:40] <sil2100> Running the test run in the meantime
[12:08] <ogra_> popey, maguro seems fine on image 11
[12:08] <ogra_> (well SMS and calls do)
[12:29] <sil2100> vila: all works ok it seems \o/
[12:30] <ogra_> BAH !
[12:30] <ogra_> all unity8 tests fail again on mako
[12:30] <ogra_> this is getting tiring :(
[12:31] <sil2100> Mirv: https://code.launchpad.net/~sil2100/cupstream2distro-config/click_stack_for_saucy/+merge/193753 <- can you take a look? We created a saucy branch for this one
[12:32] <psivaa> ogra_: i think plars pushed a fix for turning the screen on for unity8, still failing, the reason appears different. could be temp, i am rerunning
[12:33] <ogra_> psivaa, yeah, i remember the fix worked in image #10
[12:34] <psivaa> ogra_: yes, the error message is different this time compared to the failures pre image 10
[12:35] <psivaa> ohh no some of them are the same :(
[12:35] <ogra_> the pattern looks the same at least
[12:36] <psivaa> yea
[12:40] <psivaa> there is a powerd crash in the runs with image 11 that i dont remember seeing with 10
[12:41] <psivaa> and the fix is using powrd-cli so that may explain why that dint work
[12:42] <ogra_> yeah
[12:42] <ogra_> do you run powerd-cli as root ?
[12:42] <ogra_> iirc you need to
[12:46] <Mirv> sil2100: ok
[12:50] <psivaa> ogra_: powed-cli is running in the device now, but not sure if that was running whilst unity8 tests were running. will watch that
[12:51] <sil2100> hmmmm
[13:04] <sil2100> Mirv: good catch! Modified
[13:23] <Mirv> sil2100: top-approved now.
[13:36] <sil2100> Mirv: thanks!
[13:49] <plars> psivaa: odd, I got it to pass just fine on Friday
[13:49] <ogra_> plars, yeah, i wonder if the code was reverted or somethign
[13:50] <psivaa> plars: i think the issue is powerd crash this time but still yet to rerun
[13:50] <plars> I'll take a look
[13:50] <psivaa> waiting for all the tests to complete
[13:50] <psivaa> plars: ack
[13:50] <plars> ugh, more rain
[14:07] <sil2100> didrocks: do you know if we're dropping powerpc support in overall?
[14:07] <sil2100> Like, completely?
[14:08] <fginther> morning
[14:08] <sil2100> Morning
[14:09] <cjwatson> sil2100: No
[14:09] <sil2100> cjwatson: ok
[14:09] <sil2100> Then I guess I'll have to revert robru's change in libunity-webapps
[14:09] <cjwatson> Uh
[14:10] <cjwatson> You said "completely" which is a very broad question
[14:10] <cjwatson> It may be correct to drop it in specific cases where it wouldn't be buildable anyway
[14:10] <sil2100> cjwatson: well, here it would mean that suddenly unity7, bamf, and many many unity components would have to disappear for powerpc ;)
[14:11] <cjwatson> I don't know about the case of libunity-webapps
[14:11] <cjwatson> It's generally best to keep things Architecture: any unless there's a strong reason otherwise
[14:12] <cjwatson> Do you mean the webbrowser-app dependency?
[14:13] <cjwatson> You could always make that architecture-specific
[14:13] <cjwatson> i.e.  Depends: webbrowser-app [amd64 armhf i386]  Suggests: webbrowser-app [!amd64 !armhf !i386]
[14:14] <cjwatson> Or actually just drop the Suggests part of that, I guess, since it's unsatisfiable anyway
[14:14] <sil2100> Actually, we were already Suggests webbrowser-app to workaround this
[14:14] <cjwatson> Yeah, but now you want to hard-depend on it on architectures where it's available
[14:15] <cjwatson> Just Depends: webbrowser-app [amd64 armhf i386] would be fine for that
[14:15] <sil2100> Right, or webbrowser-app [!powerpc] I guess?
[14:16] <cjwatson> No
[14:16] <cjwatson> We have more than four architectures
[14:16] <cjwatson> It's more correct to specifically enable it on the architectures where we know webbrowser-app is available
[14:16] <sil2100> Yes, but we only ban it from this one particular?
[14:16] <cjwatson> But that would be wrong!
[14:16] <sil2100> Ok ok
[14:16] <cjwatson> webbrowser-app | 0.22+13.10.20131011.1-0ubuntu1 |        trusty | source, amd64, armhf, i386
[14:16] <cjwatson> Which does not include arm64 ...
[14:17] <cjwatson> Nor the further architecture we'll be adding in the next couple of months
[14:17] <sil2100> Right, but I guess it will be supported as soon as it's possible, so then we'll have to update the package again, right?
[14:17] <cjwatson> arm64 doesn't work right now for the same reason powerpc doesn't work
[14:17] <cjwatson> i.e. v8 not ported
[14:18] <cjwatson> No particular reason to expect either one to work before the other AFAIK
[14:18] <sil2100> Ok, I'm fine with any solution, just wanted to find the one that would be less troublesome to maintain :)
[14:18] <sil2100> But I guess this will be the correct one here
[14:18] <cjwatson> It makes more sense from an archive point of view to enable the dependency only where it's specifically available
[14:18] <cjwatson> Hopefully the v4 interpreter in Qt 5.2 will be more portable
[14:21] <sil2100> Thanks for the pointers!
[14:21] <cjwatson> (It's supposed to be, from what I hear)
[14:22] <plars> ogra_, psivaa: given how good the custom image looked at http://10.97.0.1:8080/view/Touch/view/Ubuntu%20Touch%20Master%20Jobs/job/trusty-touch_custom-mako-smoke-master/ I'm surprised unity8 and webbrowser had problems on the mako image. I'm rerunning now, expect they will pass
[14:22] <plars> unity8 is looking fine for me locally so far
[14:23] <ogra_> well, lets see how the next image behaves ... probably a temporary glitch
[14:24] <plars> ogra_: is 12 building now?
[14:25] <plars> ogra_: I just restarted some tests on 11
[14:25] <ogra_> plars, nope
[14:25] <ogra_> earliest after the next meeting
[14:25] <plars> ogra_: ok, I'll keep pushing on 11 then :)
[14:39] <plars> ogra_, popey: unfortunately we started having to handle a LOT of extra device-not-found errors, which mostly seem to be attributed to the mtp/adb conflict
[14:40] <ogra_> plars, the lxc-android-config package with the new upstart job from sergiusens is the first step towards fixing this
[14:40] <sil2100> cjwatson: could you maybe review this branch (if you have a minute and the permissions), since the upstream dev is not around right now: https://code.launchpad.net/~sil2100/libunity-webapps/webbrowser-app_depends_arch/+merge/193785
[14:40] <ogra_> (uploaded today)
[14:40] <plars> popey: but if you look at the results of filemanger, it seems to always be up and down between 3 or 4 failures and 19 or 20 failures
[14:40] <plars> ogra_: that's good to hear :)
[14:44] <cjwatson> sil2100: I added an Approve review, but it shows as "(community)" so it probably doesn't count for landing
[14:44] <cjwatson> It can serve as your core-dev +1 though :)
[14:46] <sil2100> ;)
[14:46] <sil2100> Thanks!
[15:19] <doanac> vila, didrocks: let me know how we should resolve the parameters for this thing. I think we are already close to a 1-to-1 mapping of the parameters, but i need to know if theres something big missing
[15:22] <didrocks> doanac: sure, want to chat about it?
[15:22] <doanac> didrocks: sounds good. how about in 8 minutes? (half past the hour)
[15:22] <didrocks> doanac: good for me as well :)
[15:28] <vila> Mirv: <mlankhorst> vila: enjoy, I found a fix for glamor-egl :P
 https://bugs.freedesktop.org/attachment.cgi?id=88619
[15:29] <doanac> didrocks, vila: i'll create a hangout for us
[15:36] <doanac> vila, didrocks: http://10.97.9.20:8080/job/trusty-touch-mako/17/
[15:37] <doanac> vila, didrocks: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/302/parameters/
[15:43] <didrocks> doanac: vila: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/201/label=autopilot-nvidia/console
[15:56] <balloons> ping fginther
[16:25] <tedg> It seems that dbus-test-runner is configured to do CI on Quantal as well as Trusty.
[16:25] <tedg> Does anyone know why that could be?
[16:25] <tedg> http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/view/head:/stacks/head/qa.cfg#L98
[17:05] <plars> didrocks: no landing meeting?
[17:05] <tedg> ev, Where should I file the bug that errors.u.c misspells "optimized" in "optimized out" ?
[17:05] <didrocks> plars: oh sorry, we told no meeting today, will resume tomorrow afternoon
[17:05]  * ogra_ will be late, running meeting is running over 
[17:05] <plars> didrocks: I missed that I guess, sorry
[17:05] <ogra_> oh, cool
[17:05] <didrocks> plars: I missed to ping you, my fault, sorry ;)
[17:05] <didrocks> I pinged the others :)
[17:40] <psivaa> plars: are you doing anything with the smoke maguro in the lab, can i rerun filemanager and gallery?
[17:41] <psivaa> balloons: we are still seeing filemanager test failures due to too many entries in /home/phablet/ .
[17:41] <plars> psivaa: go for it, I've mostly been focusing on mako at the moment
[17:42] <psivaa> plars: ack
[17:42] <balloons> psivaa, we're still trying to land a couple mp's to work on this..
[17:42] <balloons> psivaa, https://code.launchpad.net/~vthompson/ubuntu-filemanager-app/fix-carlos-model/+merge/193783
[17:42] <psivaa> balloons: ack, thanks :)
[17:42] <balloons> psivaa, the paste bug is fixed by that.. then I can land my big branch
[17:43] <balloons> and then hopefully it's all fixed :-)
[18:01] <cjwatson> FYI: publisher down pending investigation of I/O errors
[18:39] <fginther> josepht, any vanguard work I should know about?
[18:43] <josepht> fginther: not a thing
[18:50] <fginther> balloons, pong
[18:52] <fginther> alesage, do you know why dbus-test-runner is still configured to build on quantal?
[18:52] <alesage> fginther, no sir
[18:52] <alesage> fginther, propose to amend
[18:52] <fginther> alesage, ack, I'll drop it, tedg is hitting build failures to do it
[18:52] <alesage> fginther, thank you
[18:54] <balloons> fginther, https://code.launchpad.net/~vthompson/ubuntu-filemanager-app/fix-carlos-model/+merge/193783. qt5-proper ppa doesn't have a trusty build, but the virtual test enviroment is using it
[18:56] <fginther> balloons, looking
[18:57] <tedg> fginther, thanks!
[19:33] <fginther> tedg, your dbus-test-runner MP is passing now
[19:34] <fginther> balloons, https://code.launchpad.net/~vthompson/ubuntu-filemanager-app/fix-carlos-model/+merge/193783 is passing now
[19:35] <balloons> fginther, ty sir :-)
[19:36] <tedg> Great!  Thanks fginther!
[20:12] <veebers> fginther: hey how are you, query: Would you know why `/usr/bin/qmlscene` works on my local device but doesn't on the jenkins devices? i.e. I'm getting this error: qmlscene: could not find a Qt installation of ''
[20:13] <fginther> veebers, hi, it could be missing a qt plugin dependency
[20:13] <fginther> veebers, what job is this?
[20:16] <veebers> fginther: this is an example: http://10.97.0.26:8080/job/generic-mediumtests-runner-mako/2987/artifact/results/autopilot/sudoku_app_results.xml
[20:28] <fginther> veebers, when you run them on your device are you using the deb packages to install and test?
[20:37] <veebers> fginther: In my test last night yes. But I've just re-flash my device so I'm going to try something
[20:45] <veebers> fginther: on my locally freshly flashed device when running `/usr/bin/qmlscene` I don't get that error
[20:51] <fginther> plars, is there a reason sudoku_app tests are not run for the smoke testing?
[20:52] <plars> fginther: I think just nobody asked for them
[20:52] <plars> fginther: Are there tests that work?
[20:53] <fginther> plars, so far they don't
[20:53] <plars> fginther: then that's probably why nobody asked for them :)
[22:51] <plars> popey: can't seem to get filemanager down under 10 failures on mako, but on maguro it only had 3 today
[22:52] <plars> also weather app is considerably worse under mako for some reason
[23:02] <xnox> is there a bug tracker for CI infrastructure issues?
[23:02] <xnox> (bug reports / wishlist items / etc?)
[23:02] <robru> fginther, can you check why jenkins didn't run here? https://code.launchpad.net/~justinmcp/unity-chromium-extension/mediaplayer-init-fix/+merge/193549 guy's a new employee, might need to be added to some kind of whitelist?
[23:04] <fginther> robru, yep, that's probably the case, I'll get the list updated
[23:04] <robru> fginther, thanks
[23:09] <robru> fginther, what's the recommended way of handling community-submitted branches? obviously jenkins can't run on them by default, but is there some one-off way of saying 'jenkins should run for this one branch'?
[23:10] <robru> or do i have to steal the branch and take all the credit with my own MP?
[23:10] <fginther> robru, the only way to do this right now is to manually trigger the job from the jenkins UI
[23:10] <robru> fginther, hrm, can you link me to that part of the jenkins maze?
[23:16] <fginther> robru, you need to find the ${lp_project}-ci job here: http://10.97.0.26:8080/
[23:16] <fginther> robru, for example: http://10.97.0.26:8080/job/unity-chromium-extension-ci/
[23:17] <robru> fginther, ahhhh, that's a different jenkins! I don't have a login to be able to kick jobs there
[23:18] <fginther> robru, if you create one, I'll add build permission
[23:19] <robru> fginther, oh, hrm, it says 'robru' is taken, but doesn't have any kind of password recovery button...
[23:19] <fginther> robru, I can reset it
[23:20] <robru> fginther, ok, thanks. for the cu2d jenkins that one just lets me sign in with SSO...
[23:21] <fginther> robru, you should be setup now
[23:22] <robru> fginther, great, thanks!
[23:22] <fginther> robru, when building the -ci job, you'll need to supply the landing_candidate (the lp:blah branch name) and the merge_proposal (the URL of the MP in launchpad)