[00:46] <holmanb> @blackboxsw: I put up a PR to fix a couple of things that cause the ansible integration test to always fail on older systemd&&python versions. Additionally it tweaks the repo setup code in a way that should make it more robust and makes failing assertions more useful for debugging. https://github.com/canonical/cloud-init/pull/1691
[07:37] <tilt> hi :)
[07:38] <tilt> if a vmware instance of ubuntu20 does not use the vmware datasource, what could be wrong / are there specific things to be done to make it use this datasource?
[07:38] <tilt> like, a special boot parameter oslt, can't find it in the docs
[07:53] <tilt> i think we got it, we did not follow the customization steps described in https://williamlam.com/2022/06/using-the-new-vsphere-guest-os-customization-with-cloud-init-in-vsphere-7-0-update-3.html
[13:15] <esposem> if I upgrade cloud-init to a new version and then reboot, is my cloud.cfg file updated too or left intact? I would say intact, as there could be custom settings in it
[13:48] <falcojr> I think that's one of those situations where with apt at least you'd get prompted for which version to use, but it would default to keeping the changed settings
[13:48] <falcojr> not sure about other distros
[14:42] <esposem> falcojr: thanks, I think for RHEL happens the same too
[17:39] <blackboxsw> falcojr: minor changelog omission on https://github.com/canonical/cloud-init/pull/1693 something else the new-upstream-snapshot(git-buildpackage based) needs to fix probably.
[17:39] <blackboxsw> going through focal now
[17:48] <falcojr> blackboxsw: that cherry pick only ever existed in the hotfix branch, so it's not anything new-upstream-snapshot would ever see
[17:50] <blackboxsw> falcojr: ohh right, the whole reason we created the separate hotfix branches to avoid the pulling cherry picks into the base upstream/ubuntu/jammy branch great. I thought it implies another short coming in the new-upstream-snapshot changes
[17:50] <falcojr> based on what we said previously about not including the hotfix changelog info, I wouldn't think it would need to be included
[17:50] <blackboxsw> nevermind nothing to see here.
[17:50] <falcojr> but maybe it should? I guess we just need a consistent way to approach it
[17:54] <blackboxsw> falcojr: I'm on the fence there. the changeset you have currently, for SRU reviewers,  ends up representing this next upload to focal as an aggregation of the previous hotfix22.2-0ubuntu1~20.04.2 being consumed within the 22.3 upstream version  https://paste.ubuntu.com/p/Pp6MW3FBvq/ . 
[17:56] <blackboxsw> so it makes the review of that upload a bit more time-intensive, but I think it's a reasonable representation of the changeset delivered. I guess the problem in SRU review tracking is that if we have a long-lived hotfix branch with multiple releases, eventually we'll lose visibility to those commits/patches and release history in debian/changelog once we new-upstream-snapshot for a full SRU again
[17:57] <blackboxsw> but it is strange to represent adding cherry-picks and removing them in the latest changelog when it didn't really happen in this release branch
[17:58] <blackboxsw> falcojr: I'd stay let's stick with what you have up for review now as policy. undocument the cherry-picks that were applied to hotfix branches as that content is included in the d/changelog as part of the new-upstream-snapshot anyway
[18:02] <blackboxsw> falcojr: actually I'll take the opposite approach I just suggested. I think it'll be easier to review and understand the history of the release debian package if we captured the previously released d/changelog entries and manually recorded the d/changelog sections that were released from any hotfix branches prior to our new-upstream-snapshot section and manually add the dropped patches comment. 
[18:03] <falcojr> blackboxsw: so I think either all or nothing
[18:03] <blackboxsw> reason being SRU reviewer is going to see a debdiff of current upload  vs previous published upload to pkg/ubuntu/focal-proposed in git-ubuntu 
[18:03] <falcojr> if we're not going to record the interim releases, we shouldn't include changes between the interim release and now
[18:03] <blackboxsw> and they'll see the dropped cpick file in that diff and no documentation in d/changelog of actually dropping it
[18:03] <falcojr> if we are going to include the interim release, then we should also document what changed in the changelog
[18:03] <blackboxsw> falcojr: right so I flipped 180. from my prior stance. I think record them all .
[18:04] <blackboxsw> add the d/changelog entries verbatim from upstream/ubuntu/focal-22.2-hotfix prior to our top-most new-upstream-snapshot section
[18:05] <falcojr> blackboxsw: sounds good
[18:05] <blackboxsw> and then manually add the drop cherry-picks line to our new-upstream-snapshot section
[18:05] <blackboxsw> reworking my diff suggestion to see if that makes sense
[18:06] <blackboxsw> and then policy-wise anytime we have a hotfix release, we also need to cherry-pick the release changelog sections into upstream/ubuntu/<release> base branch in preparation for whenever the next SRU is
[18:08] <falcojr> so much time spent on a freakin changelog. It'd be faster if we manually curated it at this point
[18:08] <falcojr> (not a rant at you, just a rant :P )
[18:09] <blackboxsw> diff updated https://github.com/canonical/cloud-init/pull/1693#pullrequestreview-1087280009 and yes I did that manually 
[18:09] <blackboxsw> no cherry-pick please. don't waste your time finding the commitish
[18:09] <blackboxsw> I'm with you on spending too much time on accounting basically
[18:09] <falcojr> blackboxsw: thanks, you're quicker on that than me
[18:10] <blackboxsw> falcojr: my patch was for focal, but I put in on the jammy branch :/
[18:10] <blackboxsw> will add that diff to focal.... updating jammy now
[18:10] <falcojr> heh, all good. I'll get them worked out
[18:10] <blackboxsw> +1
[18:11] <blackboxsw> faster and "wronger"
[18:18] <blackboxsw> patches corrected for focal and jammy
[18:18] <blackboxsw> rebuilding now to confirm no lints
[18:19] <blackboxsw> jammy w/ patch no debian/* diffs unaccounted for in d/changelog https://paste.ubuntu.com/p/sRgddwSsTP/
[18:19] <blackboxsw> and makes our topmost d/changelog section "clean" when reviewing the supplemental diff
[18:23] <falcojr> blackboxsw: actually now I have duplicated changelog entries
[18:24] <falcojr> I should remove the postinst redact from 22.3 since we have it in the hotfix, right?
[18:24] <blackboxsw> falcojr: good pt. yes remove the duplcated lines that show up again in the top-most section. (because they were already officially released via hotfix publish)(
[18:28] <falcojr> blackboxsw: I think all 3 are up to date now
[18:30] <blackboxsw> ok today I'm documenting the hotfix process for uss-tableflip:doc/ubuntu_release_process.md too
[18:30] <blackboxsw> we had a breadcrumb in there, but not enough
[18:31] <blackboxsw> we had a breadcrumb in there, but not enough ... and nothing in cloud-init RTD content... probably want that too
[18:31] <blackboxsw> at least from a tag perspective 
[18:31] <blackboxsw> so others can track whether upstream releases have followup hotfixes
[18:32] <falcojr> blackboxsw: part of it is that we're doing some new things so making it up as we go
[18:32] <blackboxsw> +1
[19:23] <blackboxsw> bionic/focal/jammy uploads good
[19:24] <blackboxsw> PRs & tags pushed to upstream
[19:34] <holmanb> .
[23:03] <falcojr> blackboxsw or holmanb: if either of you are still around we have a request in #ubuntu-release (pinged here because we're all here)