[06:40] <rharper> https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/373177
[06:40] <rharper> blackboxsw: smoser:  ^^ fixes CI failures
[07:51] <nils_> is there a linter for cloud config?
[13:27] <smoser> nils_: sort of.
[13:28] <smoser> python3 -m cloudinit.cmd.main devel schema
[13:28] <smoser> thats the best we can do
[15:27] <mgerdts> I rebased an old branch, made some changes, force pushed, then resubmitted a merge request.  The diff shows conflicts that don't really exist, seemingly related to the 13 month old version that was previously there.  Would it be easier if I just submitted a fresh merge request rather than trying to make this one happy?
[15:27] <mgerdts> https://code.launchpad.net/~mgerdts/cloud-init/+git/cloud-init/+merge/373171
[16:27] <smoser> rharper: so the upload failed because it tried to re upload
[16:27] <smoser>   cloud-init_19.2-2142-g571f7c3-0ubuntu1+1669~trunk~ubuntu18.04.1.tar.xz
[16:27] <rharper> yeah; I clicked it manually to request the build since nothing was built for 6 days
[16:27] <rharper> but I don't understand the failure
[16:28] <smoser> the recipe build builds the tarball
[16:28] <smoser> and its tar and timestamps so it will happen to differ
[16:28] <smoser> basically it already built this exact thing
[16:28] <smoser> so re-tries will fail
[16:29] <smoser> you could i guess maybe delete the old one from https://code.launchpad.net/~cloud-init-dev/+archive/ubuntu/daily
[16:29] <smoser> and it might re-build
[16:29] <smoser> or just merge something
[16:30] <smoser> or you could change the recipe text to have '0ubuntu2'
[16:30] <smoser> at https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-bionic
[16:33] <rharper> oh, no code changes
[16:34] <rharper> but the build would fail for next commit
[16:34] <rharper> without a fix for the asteroid version / ignoring generated modules on the context manager
[16:35] <smoser> maybe it would. it probably wouldnt fail though
[16:35] <smoser> as the ast dep comes from pip, not archive i suspect. unless they updated it in archive.
[16:35] <smoser> other option looks to b add {time} to the recipe
[16:35] <smoser>  https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[16:36] <smoser> that would mean you could always hit 'build now' (well... once per second)
[16:36] <smoser> err, it looks like per-minute
[16:40] <rharper> interesting
[16:41] <rharper> we must not run tox on builds, I dont think the builder would allow pip install bits, right ?
[16:57] <smoser> right. it runs make test i think. tests still run, but with the package installed dependencies.
[16:58] <smoser> which is what you really want... because you want to test the distro
[17:20] <garrett__> Hi. I'm trying to debug an issue, and I'm wondering if someone might have some ideas. I have some machines with one physical interface and a bunch of virtual interfaces. eth0 and eth0:0, eth0:1, etc. After updating from cloud-init 18.2-1 to 18.5-3, I see that LOCAL_IPV4 in /etc/environment is getting set to the IP bound to eth0:0 instead of eth0. I see some calls to udev settle in the cloud-init logs, and it looks like those changes might have bee
[17:21] <garrett__> Sorry, this is centos. I'm trying to figure out exactly what patchsets are in there as we speak. I'm just wondering if this is an issue someone might have seen before, or if I'm going entirely down the wrong path
[17:38] <smoser> garrett__: cloud-init doesn't do anything with LOCAL_IPV4  in /etc/environment.
[17:38] <garrett__> @smoser: aha! okay
[17:52] <garrett__> smoser: much thanks. you just saved me a bunch of time.
[18:00] <Odd_Bloke> rharper: blackboxsw: smoser: If you have a minute, this fixes the build so we can continue landing stuff: https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/373221
[18:06] <Odd_Bloke> Oh, ha, I see I'm late to this.
[18:06] <Odd_Bloke> Should have fully caught up on my inbox before jumping on it, I guess.  Have Approved Ryan's MP.
[18:17] <Odd_Bloke> I've filed https://github.com/PyCQA/pylint/issues/3137 for the issue we're seeing.
[18:20] <smoser> Odd_Bloke: thank you for doing that.
[18:20] <smoser> (we think it is probably astroid related though... or at least that was the change htat caused it)
[18:28] <Odd_Bloke> Yeah, I mentioned in the issue that we only started seeing it on astroid upgrade, but it looks like pylint is the place to report such things.
[18:29] <Odd_Bloke> (It's the same development team anyway, AFAIK.)
[18:46] <powersj> Summit Agenda: https://docs.google.com/presentation/d/1Ch4QDfK8pd968mfBgnXQK7_0JWAatrkix069sxsVgOs/edit?usp=sharing
[18:48] <powersj> Project Update: https://docs.google.com/presentation/d/1Rfyr7zhWWhijPD1TbF85Z540OXhTLpKeZSSomiYrUlo/edit?usp=sharing
[19:29] <smoser> python3 -m cloudinit.cmd.main devel schema
[19:29] <smoser> oops
[19:30] <Odd_Bloke> blackboxsw: https://github.com/cloud-init/ubuntu-sru/pull/57 <-- the Oracle SRU verification
[19:34] <rharper> Odd_Bloke: thanks
[20:16] <powersj> rharper, blackboxsw does this mean the SRU is done?
[20:16] <blackboxsw> powersj: checking
[20:18] <rharper> no
[20:18] <rharper> waiting on MAAS QA and CDO QA
[20:18] <rharper> I've Xenial, but bionic/disco fail on MAAS, pinged in their channel
[20:18] <blackboxsw> powersj: rharper; right  CDO QA hasn't gotten back yet with SRU results
[20:19] <rharper> https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/372727
[20:28] <blackboxsw> powersj: so per your email back to jog, I'm not sure if they're indefinitely waiting on defining 'what they do' w.r.t. SRU validation as they are radio silent after your followup.
[20:28] <powersj> blackboxsw, I would respond to his last email and ask for an eta. Say that their validation is all we are waiting for
[20:32] <rharper> powersj: a gentle poke to MAAS would be nice as well;
[22:59] <blackboxsw> We just added the community: low-hanging fruit lane to our trello board  where anyone should be able to grab cards  https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin.
[23:01] <blackboxsw> If folks have interest in working any cards in the "Community: low-hanging fruit" lane, we can assign individuals to cards as they are being worked. They generally should represent bite-sized work that is aligned with upstream cloud-init goals for the next development cycle
[23:02] <blackboxsw> we'll touch more on this in next bi-weekly meeting Oct 8th as well to give more context
[23:31] <rharper> smoser: https://code.launchpad.net/~sdhd/curtin/+git/curtin/+merge/371401
[23:31] <rharper> https://code.launchpad.net/~sdhd/curtin/+git/curtin/+merge/371401/comments/972028
[23:45] <blackboxsw> azure manual validation for last sru https://github.com/cloud-init/ubuntu-sru/blob/master/manual/azure-sru-19.2.36.txt
[23:53] <blackboxsw> for cloud-init SRUs, we update this PPA with upcoming cloud-init releases that are under tests https://launchpad.net/~cloud-init-dev/+archive/ubuntu/proposed
[23:54] <blackboxsw> We only update this PPA with a cloud-init version under test during an SRU (stable release update) for Ubuntu. at maximum it may be updated once a month. So, it should be pretty stable