[18:25] <dpb1> powersj: https://jenkins.ubuntu.com/server/job/cloud-init-ci/20/consoleText too many values to unpack?
[18:30] <powersj> hmm a merge on ubuntu/xenial
[18:30] <powersj> let me see what the state of the integration tests is there
[18:33] <smoser> powersj, yeah, was justa about to ask about that
[18:33] <smoser> if i cherry picked your integration fixes
[18:34] <smoser> would that do it ?
[18:35] <powersj> Yes it would. It is due to the new test framework handling error exceptions from pylxd which is missing from the old version
[18:46] <smoser> ok. i'm going to attempt to pull those along
[19:09] <smoser> powersj, bah
[19:09] <smoser> so i got those commits. and didn't fix.
[19:09] <smoser> so i'm going to drop them again and ignore the failure.
[19:09] <smoser> :-(
[19:09] <powersj> ok
[19:09] <powersj> same failure though?
[19:09] <smoser> i grabbed the commits, but they're not in the tree
[19:09] <smoser> yeah
[19:10] <smoser> https://jenkins.ubuntu.com/server/job/cloud-init-ci/21/console
[19:10] <smoser> they're not in the tree, they're in quilt patches in debian/patches
[19:10] <powersj> ah
[19:10] <smoser> so you'd have to 'quilt push' in order to run the intergration tests with them there.
[19:12] <powersj> hmm should I keep the integration tests as a part of CI then?
[19:15] <smoser> yes
[19:15] <smoser> and msot of the time this would work.
[19:17] <powersj> ok as long as you are fine with those odd ball cases :)
[19:35] <smoser> powersj, i wonder...
[19:35] <smoser> i dont have a suffiecntly old lxd anywhere
[19:35] <powersj> ?
[19:35] <smoser> could you easily run integration tests on the xenial deb in https://launchpad.net/~smoser/+archive/ubuntu/cloud-init-dev/+files/cloud-init_0.7.9-153-g16a7302f-0ubuntu1~16.04.2~ppa3_all.deb
[19:39] <powersj> we could; clone master to get latest tests, and pass --deb option to integration tests to put that deb into the images.
[19:39] <powersj> this however, assumes we don't run into a mismatch of tests and features/functionality
[19:44] <dpb1> getting the tests executed will be step 1
[19:44] <dpb1> instead of failure to launch
[19:46] <smoser> powersj, yeah. i was just asking if you could do it locally
[19:48] <powersj> smoser: running...
[19:48] <smoser> i think it will run
[19:49] <powersj> oh it is
[19:49] <powersj> collecting output for tests now
[20:03] <powersj> tests passed
[20:37] <powersj> https://paste.ubuntu.com/24975100/
[20:50] <powersj> hmm CI doesn't seem to be triggering at the moment now...
[20:53] <dpb1> powersj: attach those results to the MP?
[20:56] <powersj> dpb1: done
[20:57] <dpb1> thx
[21:00] <powersj> ok CI is back, sorry about that folks
[21:27] <smoser> [ubuntu/xenial-proposed] cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 (Waiting for approval)
[21:27] <smoser> [ubuntu/yakkety-proposed] cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.10.2 (Waiting for approval)
[21:27] <dpb1> woop dee doo
[21:27] <smoser> [ubuntu/zesty-proposed] cloud-init 0.7.9-153-g16a7302f-0ubuntu1~17.04.2 (Waiting for approval)
[21:31] <smoser> night night
[21:31] <dpb1> smoser: cya
[21:56] <dpb1> rharper: this should be fix released? https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1693939 (for cloud-init project)
[21:56] <rharper> dpb1: hrm
[21:57]  * rharper checks in zesty daily
[21:57] <dpb1> well
[21:57] <rharper> dpb1: no, I don't think so
[21:57] <dpb1> I mean, the cloud-init project bug
[21:57] <dpb1> er
[21:57] <dpb1> task
[21:57] <rharper> 0.7.9-113 is in zesty, so ideally we'd SRU to Zesty
[21:57] <dpb1> not the source package task
[21:57] <dpb1> ok
[21:58] <dpb1> that confuses me
[21:58] <dpb1> why
[21:58] <dpb1> ?
[21:58] <rharper> we don't  strictly have to update zesty
[21:58] <rharper> but it's not nice to have 16.04 up to date but the current release have issues
[21:58] <dpb1> why is zesty involved in the cloud-init project task though
[21:59] <dpb1> there is a separate source package task on there
[21:59] <rharper> well, we upload to each of the current release (devel + any currently supported releases)
[21:59] <rharper> possibly as cloud-init has a branch per release to handle the packaging ?
[21:59] <rharper> I don't know for sure
[21:59] <dpb1> ok
[21:59] <dpb1> the release process stuff is a bit hazy to me
[22:00] <rharper> I'm not too keen on the lp bits, but I do know that we have a branch per release for packaging changes
[22:00] <dpb1> in our source tree (outside of the ubuntu distro)
[22:00] <rharper> yes
[22:00] <rharper> git
[22:00] <dpb1> k
[22:00] <dpb1> that makes sense
[22:01] <dpb1> I'll ask scott when I next think of it.
[22:01] <rharper> ok