=== toolz is now known as Daniel
[14:44] <blackboxsw> waldi: faa thanks for the question and resolution there. yes our schema validation is becoming more strict to avoid inconsistencies in general have 2 ways to support the same behavior. cloud-init in general will currently only raise Warnings in logs for schema "infractions" but at some point in a  future release, those warnings will become errors.
[14:45] <blackboxsw> I also want to make sure when we general schema errors, that they are a bit more specific in cases like the above, because it's not too helpful a message currently
[14:45] <blackboxsw> when we "raise " general schema errors
[15:21] <blackboxsw> #cloud-init 22.3 Released! | Bugs: https://bugs.launchpad.net/cloud-init/+filebug | PRs: https://git.io/JeVed | release schedule: https://discourse.ubuntu.com/t/cloud-init-2022-release-schedule/25413
=== blackboxsw changed the topic of #cloud-init to: 22.3 Released! | Bugs: https://bugs.launchpad.net/cloud-init/+filebug | PRs: https://git.io/JeVed | release schedule: https://discourse.ubuntu.com/t/cloud-init-2022-release-schedule/25413
[15:22] <blackboxsw> heh
[15:28] <blackboxsw> in testing uploaded release file status aciba and I can across copr build failures due to SPEC not listing the new clean.d directory at https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/build/4750679/ . I have a PR up for this to make sure copr builds are in good shape https://github.com/canonical/cloud-init/pull/1680
[15:28] <ubottu> Pull 1680 in canonical/cloud-init "rpm/copr: ensure RPM represents new clean.d dir artifacts" [Open]
[15:30] <blackboxsw> also I think, prior to SRU in ubuntu a nice to have PR would be the vmware one that was just put up https://github.com/canonical/cloud-init/pull/1674
[15:30] <ubottu> Pull 1674 in canonical/cloud-init "DataSourceVMware: fix var use before init" [Open]
[15:31] <blackboxsw> checking that bug #1987005 to see if it's a regression
[15:31] <ubottu> Bug 1987005 in cloud-init "ipv6_ready referenced before assignment" [Undecided, New] https://launchpad.net/bugs/1987005
[15:32] <blackboxsw> given the version of cloud-init in the bug cloud-init version: 22.2.2-1.ph3.   this doesn't look like a regression in release 22.3. So not a release-related issue. But a nice bug to fix
[17:14] <blackboxsw> akutz thanks on the unittest coverage in 1674. it's good to have some coverage of that function to alert us to siginificant runtime breakage as we adapt the function in the future.
[17:18] <blackboxsw> falcojr: I'm going through your packaging branches now B/F/J series for ubuntu. I had wanted to get in PR 1674 if you think that's worth it so we have a vmware runtime error fix in our next SRU
[17:19] <blackboxsw> the vmware fix is pre-existing bug prior to our current 22.3 release, but nice to have
[17:22] <falcojr> blackboxsw: sure that's fine 
[17:25] <blackboxsw> https://github.com/canonical/cloud-init/pull/1654 bionic merged
[17:25] <ubottu> Pull 1654 in canonical/cloud-init "Ubuntu/bionic: add expire-on-hashed-users.patch" [Merged]
[17:28] <blackboxsw> bah falcojr I have a followup for bionic and for focal/jammy we need to redact LP bug numbers from debian/changelog.  new-upstream-snapshot should have done this for us automatically on non devel releases. 
[17:28] <blackboxsw> I think we can rebase squash merge on ubuntu/bionic branch  for the changelog fix
[17:32] <blackboxsw> falcojr: https://github.com/canonical/cloud-init/pull/1681
[17:32] <ubottu> Pull 1681 in canonical/cloud-init "changelog: redact LP bug numbers on stable release" [Open]
[17:32] <blackboxsw> the diffs we need to see in your focal/jammy branches too
[17:34] <falcojr> blackboxsw: why are we redacting LP numbers?
[17:35] <blackboxsw> falcojr: we redact LP numbers on all stable releases because of our SRU process bugs. there should only be on LP bug listed in stable Ubuntu releases in the changelog line: `  * New upstream snapshot. (LP: #SRU_BUG_NUMBER_HERE)     `
[17:36] <blackboxsw> on the devel release (kinetic) we list all bugs individually
[17:36] <blackboxsw> the strange things is `new-upstream-snapshot` should have correctly done this for us.
[17:36] <blackboxsw> I'll double check running through focal and jammy locally on my side to see why it is not detecting that we are on a stable release
[17:37] <blackboxsw> I think it's our github packagebuilder integration that isn't detecting this right
[17:59] <blackboxsw> falcojr: it was my tooling change to gbp that introduced the new-upstream-snapshot  regression https://github.com/canonical/uss-tableflip/pull/97
[17:59] <ubottu> Pull 97 in canonical/uss-tableflip "tools/fix stable bug redact" [Open]
[17:59] <blackboxsw> non devel series should always redact LP bug ids, and I missed that in the shuffle
[17:59] <falcojr> blackboxsw: ah, fun
[18:02] <blackboxsw> so that'd 'fix' focal and jammy PRs. can re-run with `new-upstream-snapshot aa59209adfecfcdebc31c59c4f22b6872b47d0d0 --skip-release` plus the git cherry-pick of your two commits for the feature disable
[18:03] <blackboxsw> or we can manually redact the bugs in d/changelog if you prefer
[18:14] <falcojr> might just be easier redacting manually at this point
[18:14] <falcojr> I'll do that real quick
[18:16] <falcojr> blackboxsw: also noticed now trying to new-upstream-snapshot on bionic removes the ' * New upstream snapshot. (LP: #SRU_BUG_NUMBER_HERE)' line entirely. I can add it back in, but another thing I wanna look at
[18:18] <blackboxsw> hrm, I see it on ubuntu/focal   * New upstream snapshot. (LP: #SRU_BUG_NUMBER_HERE) when running with --skip-release. checking bionic.
[18:20] <blackboxsw> confirmed on bionic this'll effect focal/jammy on next new-upstream-release call too for SRU.
[18:20] <blackboxsw> I see a 2nd   * New upstream snapshot. (LP: #SRU_BUG_NUMBER_HERE) ordered below the redacted one
[18:20] <blackboxsw> so the tool is positioning the header in the wrong place
[18:21] <blackboxsw> ... 3rd regression related to my github package builder shift in that code
[18:22] <blackboxsw> I'll put up a PR for that while you are manually fixing focal/jammy I suppose
[18:33] <blackboxsw> the other thing we could do in gbp related config for ubuntu is just provide `--meta-closes-bugnum='MATCHNOBUGS'` to the gbp command, then new-upstream-snapshot wouldn't have to "detect" that state, we would explicitly set it for stable releases in `debian/gbp.conf`and leave it untouched in devel/debian/gbp.conf
[18:34] <blackboxsw> at least that'd be more explicit
[18:56] <blackboxsw> falcojr: focal merged, jammy is missing aa59209adfecfcdebc31c59c4f22b6872b47d0d0
[18:59] <falcojr> blackboxsw: we still have another upstream snapshot to do...these patches don't take us to release yet :/
[18:59] <blackboxsw> falcojr: right, I just mean that the commit sync point for jammy != focal and bionic
[18:59] <falcojr> though...not sure why that specific commit would matter for jammy anyway. It's for centos, right?
[18:59] <blackboxsw> it doesn't really matter
[18:59] <falcojr> oooh, didn't realize that
[19:00] <blackboxsw> yeah it really wont matter as we aren't SRUing yet. but it'll mean daily builds could be different content 
[19:00] <falcojr> gotcha...yeah, I'll make sure I keep them together in the future
[19:00] <blackboxsw> +1 will merge as is
[19:01] <blackboxsw> just finishing review now
[19:07] <blackboxsw> jammy merged thx!
[19:28] <falcojr> blackboxsw: deja vu...bionic is up
[19:29] <blackboxsw> falcojr: this is for SRU right?
[19:29] <falcojr> yes
[19:30] <blackboxsw> cool. I assume manual intervention on d/changelog given new-uupstream-snapshot is ordering poorly on supplemental unreleased runs
[19:31] <falcojr> yes, I did move that manually
[19:34] <blackboxsw> ok falcojr before you go to other release branches: looks like automated line wrapping isn't working in all cases. See Alberto\nContreras and some of the indents of the wrapped lines
[19:35] <blackboxsw> we can manually fix those cases for now. I'll try fixing the wrapped indent in uss-tableflip
[19:35] <falcojr> blackboxsw: whats the expectation? That wrapped lines will be indented to the previous line?
[19:36] <blackboxsw> yes. the text alignment should match the text of the line before (not aligned with the "+") 
[19:37] <blackboxsw> something like this example https://paste.opendev.org/show/bmu8bfkWnzUUUb4PxJKt/
[20:01] <blackboxsw> ok the changelog ordering problem in new-upstream-snapshot is broken when patches are refreshed as it doesn't conform to the expectation that we'd have a "New upstream snapshot" message as the gate before new commit messages.
[20:37] <dave_garvey> Hi, I am trying to build a rhel-7 rpm using the git source and when I run make rpm it complains that rpm's are not available? and of course rhel7 doesn't support these rpm's. python3-httpretty, python3-httpretty, python3-pytest, python3-pytest-cov...  the epel stuff looks old. Please advise, how can i build a rhel7 rpm using pip3?