/srv/irclogs.ubuntu.com/2022/08/22/#cloud-init.txt

=== toolz is now known as Daniel
blackboxswwaldi: 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:44
blackboxswI 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 currently14:45
blackboxswwhen we "raise " general schema errors14:45
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/2541315:21
=== 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
blackboxswheh15:22
blackboxswin 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/168015:28
ubottuPull 1680 in canonical/cloud-init "rpm/copr: ensure RPM represents new clean.d dir artifacts" [Open]15:28
blackboxswalso 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/167415:30
ubottuPull 1674 in canonical/cloud-init "DataSourceVMware: fix var use before init" [Open]15:30
blackboxswchecking that bug #1987005 to see if it's a regression15:31
ubottuBug 1987005 in cloud-init "ipv6_ready referenced before assignment" [Undecided, New] https://launchpad.net/bugs/198700515:31
blackboxswgiven 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 fix15:32
blackboxswakutz 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:14
blackboxswfalcojr: 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 SRU17:18
blackboxswthe vmware fix is pre-existing bug prior to our current 22.3 release, but nice to have17:19
falcojrblackboxsw: sure that's fine 17:22
blackboxswhttps://github.com/canonical/cloud-init/pull/1654 bionic merged17:25
ubottuPull 1654 in canonical/cloud-init "Ubuntu/bionic: add expire-on-hashed-users.patch" [Merged]17:25
blackboxswbah 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
blackboxswI think we can rebase squash merge on ubuntu/bionic branch  for the changelog fix17:28
blackboxswfalcojr: https://github.com/canonical/cloud-init/pull/168117:32
ubottuPull 1681 in canonical/cloud-init "changelog: redact LP bug numbers on stable release" [Open]17:32
blackboxswthe diffs we need to see in your focal/jammy branches too17:32
falcojrblackboxsw: why are we redacting LP numbers?17:34
blackboxswfalcojr: 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:35
blackboxswon the devel release (kinetic) we list all bugs individually17:36
blackboxswthe strange things is `new-upstream-snapshot` should have correctly done this for us.17:36
blackboxswI'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 release17:36
blackboxswI think it's our github packagebuilder integration that isn't detecting this right17:37
blackboxswfalcojr: it was my tooling change to gbp that introduced the new-upstream-snapshot  regression https://github.com/canonical/uss-tableflip/pull/9717:59
ubottuPull 97 in canonical/uss-tableflip "tools/fix stable bug redact" [Open]17:59
blackboxswnon devel series should always redact LP bug ids, and I missed that in the shuffle17:59
falcojrblackboxsw: ah, fun17:59
blackboxswso 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 disable18:02
blackboxswor we can manually redact the bugs in d/changelog if you prefer18:03
falcojrmight just be easier redacting manually at this point18:14
falcojrI'll do that real quick18:14
falcojrblackboxsw: 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 at18:16
blackboxswhrm, I see it on ubuntu/focal   * New upstream snapshot. (LP: #SRU_BUG_NUMBER_HERE) when running with --skip-release. checking bionic.18:18
blackboxswconfirmed on bionic this'll effect focal/jammy on next new-upstream-release call too for SRU.18:20
blackboxswI see a 2nd   * New upstream snapshot. (LP: #SRU_BUG_NUMBER_HERE) ordered below the redacted one18:20
blackboxswso the tool is positioning the header in the wrong place18:20
blackboxsw... 3rd regression related to my github package builder shift in that code18:21
blackboxswI'll put up a PR for that while you are manually fixing focal/jammy I suppose18:22
blackboxswthe 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.conf18:33
blackboxswat least that'd be more explicit18:34
blackboxswfalcojr: focal merged, jammy is missing aa59209adfecfcdebc31c59c4f22b6872b47d0d018:56
falcojrblackboxsw: we still have another upstream snapshot to do...these patches don't take us to release yet :/18:59
blackboxswfalcojr: right, I just mean that the commit sync point for jammy != focal and bionic18:59
falcojrthough...not sure why that specific commit would matter for jammy anyway. It's for centos, right?18:59
blackboxswit doesn't really matter18:59
falcojroooh, didn't realize that18:59
blackboxswyeah it really wont matter as we aren't SRUing yet. but it'll mean daily builds could be different content 19:00
falcojrgotcha...yeah, I'll make sure I keep them together in the future19:00
blackboxsw+1 will merge as is19:00
blackboxswjust finishing review now19:01
blackboxswjammy merged thx!19:07
falcojrblackboxsw: deja vu...bionic is up19:28
blackboxswfalcojr: this is for SRU right?19:29
falcojryes19:29
blackboxswcool. I assume manual intervention on d/changelog given new-uupstream-snapshot is ordering poorly on supplemental unreleased runs19:30
falcojryes, I did move that manually19:31
blackboxswok 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 lines19:34
blackboxswwe can manually fix those cases for now. I'll try fixing the wrapped indent in uss-tableflip19:35
falcojrblackboxsw: whats the expectation? That wrapped lines will be indented to the previous line?19:35
blackboxswyes. the text alignment should match the text of the line before (not aligned with the "+") 19:36
blackboxswsomething like this example https://paste.opendev.org/show/bmu8bfkWnzUUUb4PxJKt/19:37
blackboxswok 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:01
dave_garveyHi, 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?20:37

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!