[00:07] <robru> fginther: https://pastebin.canonical.com/128028/ same traceback, different 'juju status', agent-state stuck in 'pending' after an hour
[00:34] <veebers> robru: awesome thanks! Much appreciated :-) nw even the superhumans such as yourself have to eat every now and then
[00:34] <robru> veebers: haha, you're welcome!
[00:39] <cyphermox> robru: highlights in place.
[00:39] <robru> cyphermox: sweet, thanks
[00:39] <cyphermox> (it's early, but still)
[00:39] <robru> cyphermox: you can watch me work tomorrow ;-)
[01:11] <josepht> robru: for 'pending' check 'nova list' and see if you have instances in ERROR state
[01:14] <robru> josepht: https://pastebin.canonical.com/128032/ indeed this looks wrong, there are triple as many machines as there were in the previous deployment.
[01:15] <josepht> robru: you'll need to 'nova delete' the ERROR ones and after a 'juju destroy-environment ...' I'd expect there to be none for juju-engine-machine-X
[01:16] <robru> josepht: I thought I had checked the 'nova list' after the 'destroy-environment' and saw only the 2 sandbox ones in the right state, the ERROR state ones came after 'mojo run'
[01:17] <robru> josepht: so you want me to destroy environment again? there's nothing else to poke at with the current env?
[01:18] <josepht> robru: one thing you can do is 'nova console-log $ID' for one of those instances and see if that tells you anything
[01:19] <josepht> robru: probably not
[01:19] <robru> josepht: bah, just deleted them
[01:19] <josepht> robru: have you updated juju recently?
[01:19] <robru> josepht: well I'm doing this in a trusty sandbox.
[01:20] <robru> 1.20.11-0ubuntu0.14.04.1
[01:20] <robru> $ apt-cache policy juju-core
[01:20] <robru> juju-core:
[01:20] <robru>   Installed: 1.20.11-0ubuntu0.14.04.1
[01:20] <robru>   Candidate: 1.20.11-0ubuntu0.14.04.1
[01:20] <robru>   Version table:
[01:20] <robru>  *** 1.20.11-0ubuntu0.14.04.1 0
[01:20] <robru>         500 http://nova.clouds.archive.ubuntu.com/ubuntu/ trusty-updates/universe amd64 Packages
[01:20] <robru>         100 /var/lib/dpkg/status
[01:20] <robru>      1.18.1-0ubuntu1 0
[01:20] <robru>         500 http://nova.clouds.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
[01:22] <josepht> robru: okay, so for that version of juju I usually have to 'juju add-machine zone=nova' for each machine I'll need as juju will sometimes try to allocate machines on a different availability-zone.  Is this on bootstack?
[01:23] <robru> josepht: yes on bootstack, and I've been doing that as per fginther's instructions.
[01:23] <josepht> robru: the add-machine bit?
[01:23] <robru> josepht: "for i in {1..8}; do juju add-machine zone=nova --constraints="instance-type=m1.smaller"; done"
[01:23] <josepht> awesome
[01:24] <robru> josepht: not sure what happened, the second time around there seemed to be twice as many machines. even though I ran destroy-environment in between
[01:25] <josepht> robru: strange, one thing to check is that your services and relations in your spec (if they are separate files) need to have identical names for the deployment and services
[01:26] <robru> josepht: spec I'm using is lp:~canonical-ci-engineering/canonical-mojo-specs/ci-engine-ts-webui, fginther said he was able to get a successful deployment with it...
[01:26] <robru> josepht: (it is stripped down from the full spec though)
[01:29] <josepht> robru: are you deploying again?  are the RUNNING instances still there?
[01:29] <robru> josepht: oh not yet. one sec
[01:29] <josepht> robru: don't if you aren't
[01:30] <robru> josepht: oh I'm just destroying now
[01:30] <josepht> robru: okay :)
[01:30] <robru> https://www.irccloud.com/pastebin/YUVNcdCf
[01:30] <robru> josepht: getting that again ^
[01:30] <josepht> are the instances still there if you 'nova list'?
[01:31] <robru> josepht: 'nova list' indeed has nothing matching *engine*, just the two *sandbox* ones
[01:31] <josepht> can you do 'nova secgroup-list' please?
[01:32] <robru> josepht: https://pastebin.canonical.com/128033/
[01:33] <josepht> robru: can you try to 'nova secgroup-delete' the engine ones please?
[01:35] <robru> josepht: looks good: https://pastebin.canonical.com/128034/
[01:35] <josepht> robru: cool, I guess you can redeploy then.  I won't be around when it's done though, I'm sorry to say. :)
[01:36] <robru> josepht: heh, either will I. I'll ping ci-help again tomorrow. thanks a bunch!
[01:36] <josepht> robru: np
[01:54] <fginther> robru, hey, I just saw your first pastebin, do you have "default-series: precise" in the .juju/environments.yaml file? Nodes 1-8 were trusty nodes, they should be precise
[01:55] <robru> fginther: oh hrm it might be trusty. copy&paste error. crap
[01:55] <robru> yup, it's trusty
[01:56] <robru> fginther: ok, cancelled that deployment, will try again with precise
[01:56] <fginther> robru, ahh, that should explain that problem.
[01:57] <fginther> robru, yeah, the 'juju add-machine' trick will use whatever is the default-series.
[01:58] <fginther> robru, and since the pre-allocated nodes didn't match what the mojo spec, it tried to create new nodes, which unfortunately doesn't work right :-/
[01:58] <robru> fginther: that explains the extra nodes... doesn't explain why i didn't get extra nodes the first time around though. weird
[02:05] <imgbot> [02:32] <robru> fginther: wait, what? https://pastebin.canonical.com/128036/ is this a success?
[02:33] <robru> i dont even
[02:35] <fginther> robru, yep, looks like it all worked, you can also check 'juju status' and make sure there are no errors (which there shouldn't be as the mojo spec ran the tests)
[02:36] <robru> fginther: very nice. wow. ok, I'm EOD now but I'll poke at this tomorrow.
[02:37] <fginther> robru, see ya
[02:37] <robru> fginther: thanks!
[03:20] <robru> Saviq: no qa on silo 6?
[03:23] <rsalveti> robru: nops, fixing one symbol file and fixing the android build (not affecting the binaries out of this package)
[03:24] <rsalveti> the previous landing broke all the android builds depending on platform-api, including arale
[03:24] <robru> rsalveti: ah, fair
[03:35] <imgbot> [03:35] <imgbot> [05:25] <rsalveti> geez, platform-api will never migrate
[05:50] <Mirv> this time at least the image is not broken..
[08:51] <Mirv> cihelp platform-api claims to be "waiting" for Boottest result, but in fact vivid-boottest-platform-api has not been triggered at all
[08:51] <Mirv> s/waiting/Test in progress/
[08:57] <psivaa_> Mirv: what version is it waiting on.. i see http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/BootTest/job/vivid-boottest-platform-api/5/ having succeeded
[09:04] <Mirv> psivaa_: 20150320 is in proposed
[09:04] <Mirv> psivaa_: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#platform-api
[09:30] <sil2100> popey, ogra_, Mirv, davmor2: I'll be on the meeting today normally
[10:04] <sil2100> I hate this freaking cold
[10:21] <sil2100> huh, where did Dave go now?
[10:22] <ogra_> swallowed by the eclipse :)
[10:24] <sil2100> davmor2: hey! So I updated myself on the channel spec and browsed through the list of available channels and there is one setup now with the custom tarball
[10:26] <davmor2> sil2100: right I'm flashing the phone now I assume I just use devel-proposed still and the tarball should be on there right? or do I need to use a different channel?
[10:26] <sil2100> davmor2: I'm still waiting for some feedback from slangasek as there is a few confusing things going on, but from what I see the ubuntu-touch/devel-proposed/krillin.en channel seems like the devel-proposed for krillin with the right, vendor custom tarball
[10:27] <sil2100> Since the new model encourages having per-device channels if there are difference in their custom bits
[10:27] <davmor2> sil2100: I'll give that a go then
[10:36] <psivaa_> Mirv: the platform-api boottest is now running, will check the excuses in a little bit
[10:52] <davmor2> sil2100: so issue number one clicking on the here T's and C's link crash the welcome wizard
[10:59] <sil2100> huh
[11:00] <popey> sil2100: are you able to remove packages from the archive?
[11:00] <Mirv> psivaa_: thanks
[11:00] <popey> sil2100: specifically https://bugs.launchpad.net/ubuntu/+source/account-plugin-evernote/+bug/1337484
[11:02] <cjwatson> popey: requires ~ubuntu-archive
[11:02] <popey> aha
[11:02] <popey> thanks
[11:03]  * popey asks in -devel
[11:03] <cjwatson> popey: no need
[11:03] <cjwatson> I can do it
[11:03] <popey> \o/
[11:03] <popey> thank you.
[11:03] <cjwatson> only from vivid, I trust
[11:03] <popey> yeah
[11:04] <popey> this isn't an owncloud level of removal
[11:04] <cjwatson> ubuntu-rtm/14.09 doesn't have that source anyway
[11:04] <cjwatson> popey: what's the open reminders-app task for?
[11:06] <popey> cjwatson: reminders-app is the only consumer of that package, I think it was filed against that originally
[11:06] <popey> so it shows up in our tasks for the reminders-app
[11:06] <cjwatson> seems pointless if you have nothing to do, but ok
[11:07] <cjwatson> popey: done
[11:07] <popey> thanks cjwatson
[12:12] <Saviq> Mirv, seems like rsalveti landed the platform-api fix alone, could you upload qtubuntu and -gles no-change rebuilds?
[12:12] <Saviq> cihelp, any reason why makos are flashed with r127 still in -ci jobs?
[12:16] <fginther> Saviq, sorry about that, leftover workaround from the last unbootable image. Should be ok now. Need anything re-run?
[12:16] <Saviq> fginther, I'll manage
[12:17] <Saviq> fginther, is it reset now?
[12:18] <fginther> Saviq, yes, it should default now to the latest image
[12:18] <Saviq> tx
[12:34] <Saviq> Mirv, ah, it actually migrated now, as you were
[12:35] <Mirv> Saviq: oh, ok, so no more additional rebuilds needed?
[12:35] <Saviq> Mirv, https://launchpad.net/ubuntu/+source/qtubuntu
[12:37] <Mirv> okie
[12:41] <Saviq> Mirv, rsalveti, I pushed the changelogs to qtubuntu and -gles btw
[12:45]  * sil2100 lunch
[12:45] <sil2100> brb
[12:46] <Mirv> Saviq: greatness
[13:03] <Mirv> mardy: davmor2: rvr: FYI I've added some test plan to https://trello.com/c/OdkjVMsH/1156-ubuntu-landing-018-signon-plugin-oauth2-dbarth since it's not really a normal landing.
[13:03] <rvr> Mirv: Ack
[13:04] <rvr> Mirv: So that silo, is just to modify a dependency?
[13:05] <om26er> alex-abreu, Hi!
[13:05] <Mirv> rvr: yes https://code.launchpad.net/~mardy/signon-plugin-oauth2/lp1362640/+merge/253494
[13:05] <rvr> bfiller: I approved silo 27. address-book test plan must be updated to include import from sim card.
[13:05] <om26er> alex-abreu, How to test silo 7 ?
[13:05] <rvr> Mirv: Ok.
[13:06] <mardy> Mirv: yep, looks ok
[13:06] <om26er> alex-abreu, I just saw, it doesn't require QA  testing ?
[13:06] <alex-abreu> om26er, ah I marked it as needs QA by mistake, ... I updated the stylesheet
[13:06] <om26er> alex-abreu, ok, thanks :)
[13:06] <alex-abreu> om26er, thx to you :)
[13:21] <bfiller> rvr: ack
[13:21] <bfiller> renatu: can you update the address book test plan with cases to test the sim card import please
[13:22] <bfiller> renatu: see rvr message
[13:32] <rsalveti> Saviq: Mirv: the silo that had platform-api also had a rebuild of qtubuntu
[13:33] <Saviq> rsalveti, yeah, saw that, I pushed changelog bits too
[13:40] <renatu> bfiller, for all cases or only the one that we do not have autopilot?
[13:40] <renatu> rvr, we have autopilot tests for sim card importing
[13:41] <rvr> renatu: Ah, nice, I didn't see them in the diff.
[13:41] <renatu> rvr, let me re-check
[13:42] <renatu> rvr, tests/autopilot/address_book_app/tests/test_import_from_sim.py
[13:42] <rvr> renatu: +1
[14:07] <Laney> what are these -nova- emails I'm getting?
[14:30] <cjwatson> Laney: new system being tested, I've raised that and it's being fixed
[14:30] <cjwatson> thanks for the report
[14:46] <Laney> cheers
[14:47] <Laney> if this is using the cloud for adt runners then I'm in favour
[14:48] <Laney> please arrange for the test log to be catted to the console output though as I'm thoroughly trained to look there by now. :)
[14:52] <cjwatson> ev: ^-
[15:10] <sil2100> o/
[15:10] <sil2100> dbarth__: approval of branches needed:
[15:10] <sil2100> https://code.launchpad.net/~online-accounts/ubuntu-system-settings-online-accounts/master/+merge/250095
[15:11] <sil2100> https://code.launchpad.net/~mardy/account-plugins/lp1429911/+merge/252326
[15:21] <dbarth__> sil2100: sorry
[15:27] <dbarth__> sil2100: done
[16:25] <boiko> trainguards: can I get a reconfigure on vivid silo 24? I added a new component there
[16:25] <sil2100> boiko: on it
[16:26] <boiko> sil2100: thanks!
[16:59] <ogra_> sil2100, i'm stuck in another meeting, wont make LT i fear
[16:59] <sil2100> ogra_: no worries, anything outstanding related to our builds status?
[16:59] <ogra_> apart from glibc ?
[16:59] <ogra_> nope
[16:59] <sil2100> heh ;)
[17:00] <ogra_> (we cant land any initrd chanes currently because the libc breaks it)
[17:00] <ogra_> *changes
[17:43] <om26er> rsalveti, what testplan should I be running except for general testing ?
[17:43] <om26er> rsalveti, will mediaplayer do ?
[17:44] <rsalveti> om26er: for this one? better to coordinate that via email
[17:44] <rsalveti> om26er: basically everything that touches multimedia
[17:44] <om26er> rsalveti, silo20
[17:44] <rsalveti> om26er: oh, right, just mediaplayer
[17:45] <rsalveti> om26er: thought it was the silo 23
[18:35] <sil2100> cjwatson: hey, do we have a place where we have all the past manifests for images built? Or are the http://cdimage.ubuntu.com/ubuntu-touch/* the only ones?
[18:36] <sil2100> cjwatson: since I would need more images into the past
[18:41] <cjwatson> sil2100: They're all saved in the LiveFSBuild objects on Launchpad
[18:41] <cjwatson> sil2100: It's probably easiest to go via https://launchpad.net/+apidoc/devel.html#livefses
[18:41] <sil2100> hm, that's actually a valid point
[18:42] <sil2100> All the time I was using manifests while I could simply fetch it from LP
[18:42] <cjwatson> You'll find it in getFileUrls()
[18:42] <sil2100> cjwatson: thanks!
[18:42] <cjwatson> Well, I mean the manifest is attached to the build on LP
[18:42] <cjwatson> We prune non-text build artifacts quite quickly (after a day or so), but text artifacts are generally small so they're kept around forever
[18:43] <robru> sil2100: oh are you updating the diff scripts to not rely on the spreadsheet in order to determine what landed in each image?
[18:45] <sil2100> robru: no, the scripts are already a bit agnostic to that, I added a feature to generate commitlogs for ranges of images (for OTAs for instance)
[18:45] <sil2100> So I need to have information from the past
[18:45] <robru> sil2100: ooooh fancy
[18:45] <sil2100> I also forgot that the archive sheet got moved to a separate doc ;)
[18:45] <pmcgowan> om26er, the last toolkit landing has no info in the card on what it fixed
[18:45] <pmcgowan> would you know?
[18:45] <robru> sil2100: oh yeah the link to the new archive doc was in the mail i sent out
[18:46] <sil2100> Yeah, I have it :)
[18:48] <om26er> pmcgowan, not really, I do remember it changed the text selection handle to be more accessible.
[18:48] <om26er> sil2100, can you tell silo-13 that landed on 18th march, what it fixed
[18:50] <pmcgowan> would like to know if this was fixed https://bugs.launchpad.net/ubuntu-clock-app/+bug/1422693
[18:52] <om26er> pmcgowan, afaik no that was not fixed. List is here: https://launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/1.2.1450+15.04.20150318-0ubuntu1
[18:53] <pmcgowan> om26er, thanks
[18:53] <pmcgowan> be nice if the card had that info
[18:57] <robru> sil2100: note though that the 'archive landed requests' still dumps into the archive tab in the same spreadsheet. flushing those out to the separate doc is a manual step
[18:58] <nik90> pmcgowan, om26er: Actually that bug you listed and https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1401883 were fixed by an earlier UITK release on the 6th March.
[18:59] <pmcgowan> nik90, thanks
[18:59] <nik90> pmcgowan, om26er: It just so happened that the clock app also needed a fix which was done. But since clock app tests are failing on dashboard, we haven't been able to push out a new clock release
[18:59] <sil2100> robru: ok, can you give me write access to it? Just in case
[18:59] <pmcgowan> nik90, know why they fail?
[18:59] <pmcgowan> and who is working on it?
[19:00] <robru> sil2100: sure
[19:01] <nik90> pmcgowan: The clock app requests for location access which was not testable at the time and caused the tests to be stuck at the prompt. The camera app bypassed that by disabling the location prompt entirely which we didn't do for the clock app.
[19:01] <nik90> pmcgowan: I am trying to fix that at the moment.
[19:01] <pmcgowan> awesome
[19:46] <sil2100> Ok guys, I've got enough for today, need to lay down and rest some
[19:46] <sil2100> Have a nice weekend!
[21:20] <robru> mterry: kenvandine: https://ci-train.ubuntu.com/job/ubuntu-landing-008-2-publish/87/artifact/webbrowser-app_packaging_changes.diff anybody around for a packaging ack?
[21:42] <mterry> robru, sure fine  :)
[21:42] <robru> mterry: thanks!