[00:01] -queuebot:#ubuntu-release- New binary: aspectc++ [ppc64el] (lunar-proposed/universe) [1:2.3+git20221129-1] (no packageset)
[00:02] <teward> ddstreet: mapreri: took the uploader long enough can one of you approve ipmctl in the backports queue for focal?  i just lost my primary internet due to carrier level issues
[00:10] -queuebot:#ubuntu-release- New binary: rust-prometheus [ppc64el] (lunar-proposed/universe) [0.13.3-1] (no packageset)
[00:14] -queuebot:#ubuntu-release- New binary: qcoro [ppc64el] (lunar-proposed/universe) [0.7.0-3ubuntu1] (no packageset)
[00:17] -queuebot:#ubuntu-release- New binary: abseil [s390x] (lunar-proposed/main) [20220623.1-1] (i386-whitelist, ubuntu-desktop)
[00:20] -queuebot:#ubuntu-release- New binary: rust-prometheus [arm64] (lunar-proposed/universe) [0.13.3-1] (no packageset)
[00:21] -queuebot:#ubuntu-release- New binary: rust-prometheus [armhf] (lunar-proposed/universe) [0.13.3-1] (no packageset)
[00:21] -queuebot:#ubuntu-release- New binary: rust-prometheus [s390x] (lunar-proposed/universe) [0.13.3-1] (no packageset)
[00:27] -queuebot:#ubuntu-release- New binary: aspectc++ [s390x] (lunar-proposed/universe) [1:2.3+git20221129-1] (no packageset)
[00:27] -queuebot:#ubuntu-release- New binary: qcoro [s390x] (lunar-proposed/universe) [0.7.0-3ubuntu1] (no packageset)
[00:36] -queuebot:#ubuntu-release- New binary: qcoro [arm64] (lunar-proposed/universe) [0.7.0-3ubuntu1] (no packageset)
[00:41] -queuebot:#ubuntu-release- New binary: abseil [armhf] (lunar-proposed/main) [20220623.1-1] (i386-whitelist, ubuntu-desktop)
[00:41] -queuebot:#ubuntu-release- New binary: qcoro [armhf] (lunar-proposed/universe) [0.7.0-3ubuntu1] (no packageset)
[00:47] -queuebot:#ubuntu-release- New binary: aspectc++ [armhf] (lunar-proposed/universe) [1:2.3+git20221129-1] (no packageset)
[00:49] -queuebot:#ubuntu-release- New binary: aspectc++ [arm64] (lunar-proposed/universe) [1:2.3+git20221129-1] (no packageset)
[00:51] -queuebot:#ubuntu-release- New binary: qbs [s390x] (lunar-proposed/universe) [1.24.0+dfsg-2] (no packageset)
[01:14] -queuebot:#ubuntu-release- New binary: qbs [riscv64] (lunar-proposed/universe) [1.24.0+dfsg-2] (no packageset)
[01:43] -queuebot:#ubuntu-release- New binary: qbs [armhf] (lunar-proposed/universe) [1.24.0+dfsg-2] (no packageset)
[07:32] -queuebot:#ubuntu-release- Unapproved: accepted ipmctl [source] (focal-backports) [03.00.00.0423-1~bpo20.04.1]
[07:35] -queuebot:#ubuntu-release- New binary: ipmctl [amd64] (focal-backports/universe) [03.00.00.0423-1~bpo20.04.1] (no packageset)
[09:12] <bdrung> ubuntu-archive: regarding tzdata 2022g update (LP: #1998321): There is now a ICU data update available. Should I wait for the SRU to finish or upload another version to update the ICU data to 2022g?
[09:12] -ubottu:#ubuntu-release- Launchpad bug 1998321 in tzdata (Ubuntu) "tzdata 2022g release" [Critical, New] https://launchpad.net/bugs/1998321
[09:26] <seb128> bdrung, that's a question for SRU team rather than archive team I think
[09:27] <bdrung> seb128, is there a separate channel for the SRU team?
[09:28] <seb128> no, I don't think they have an official contact point or alias, which is a problem imho but I haven't see interested from them in getting that resolved
[09:28] <seb128> I would recommending to nag the person on duty today which according to https://wiki.ubuntu.com/StableReleaseUpdates is Lukasz (but he's not online atm)
[09:29] <bdrung> thanks. I'll poke him.
[09:45] <rbasak> bdrung: either is fine in principle. It just affects latency in getting updates out, or forcing users to update twice, and risking regression (eg. a mistake during review or verification) twice. We usually leave it up to the uploader to lead on that decision.
[09:48] <rbasak> bdrung: the autopkgtest failures need looking at though?
[09:58] <bdrung> rbasak, IIRC those autopkgtest failures happened in the last tzdata update as well and are false positives
[10:00] <rbasak> bdrung: that's fine, but please explain in the bug. Feel free to link to old comments to save typing!
[10:01] <rbasak> The key is that we aren't experts in every package. We expect the uploader or sponsor to know all the details and tell us, since that's way quicker than trying to figure it out ourselves on every single SRU.
[10:03] <rbasak> Oh, and if you do want to upload on top of the existing proposed upload without releasing it, please upload but do tell us in the bug, so we are sure that's your intention and that will save us asking :)
[10:04] <rbasak> seb128: official contact point is this channel or #ubuntu-devel. I'm not sure that having a keyword will help - we're all swamped already. Sorry about that, but we are working on it!
[10:11] <seb128> rbasak, right, I'm not convinced that's an efficient way or that most of the SRU team members will keep up with the channel activity and backlog. Like I asked a question yesterday which might be not trivial and which I would really like to get an answer to but I didn't, maybe I should just use the devel mailing list
[10:12] <seb128> but same, it's unclear to me that every SRU team members is actively watching devel.u.c
[10:13] <seb128> rbasak, I'm ready to bet that nobody from SRU is going to dig the channel history to go back and answer my question (or would have without the current discussion)
[10:14] <seb128> not to mention that I was disconnected by the time some of the members could have reply or that some members like Lukasz aren't even connected atm so will probably have no chance to see the conversation
[10:15] <rbasak> seb128: I thought you meant on IRC. The MLs should also be fine to ask questions. What change do you think would help?
[10:18] <seb128> rbasak, if ubuntu-devel@ is the recommended way to reach out to the SRU group in a way which is less flaky than IRC (for the reasons mentioned before) maybe documenting that on https://wiki.ubuntu.com/StableReleaseUpdates and ensuring SRU teams members do watch the list at least (which I've no idea if they all do)
[10:19] <seb128> rbasak, or having a contact-this-team enabled on https://launchpad.net/~ubuntu-sru (which might need a mailing list to be defined for the team?)
[10:20] <rbasak> seb128: I think ubuntu-devel@ or ubuntu-release@ would be fine, and IMHO it's a problem if SRU team members aren't reading it. I thought they all were, but if not, I'd be in favour of making it mandatory.
[10:21] <seb128> rbasak, k, let me post there and see I have more luck than by asking on IRC :)
[10:21] <seb128> thanks
[10:21] <rbasak> seb128: I think other SRU team members probably expect ubuntu-release@ to be the "official" ML contact point for the SRU team, and I'm happy to document that right now.
[10:21] <seb128> rbasak, should I pick release instead of devel for my email then?
[10:23] <rbasak> https://wiki.ubuntu.com/StableReleaseUpdates needs a major refactor and cleanup, which is on my TODO (but fixing the current backlog issues comes first!). Should I just add a new top level heading at the bottom for now? "Contacting the SRU team"? I suppose I could move the current bit embedded into Publishing down there as well. Will that be acceptable do you think?
[10:23] <seb128> yes, that would be acceptable
[10:23] <rbasak> seb128: I suggest ubuntu-release@, but I don't think it should make much of a difference!
[10:31] <seb128> rbasak, ack, sent now
[10:38] <rbasak> seb128: wiki updated. https://wiki.ubuntu.com/StableReleaseUpdates#Contacting_the_SRU_team is new, and https://wiki.ubuntu.com/StableReleaseUpdates#Publishing has info moved to the new section with a hyperlink from the old place. I hope that's helpful.
[10:40] <rbasak> seb128: on your question, I've seen it done, but I don't know the details. I think it's between the MIR team and AAs - the SRU team aren't really involved. But ubuntu-release@ is still the right place to ask, and hopefully one of those people will respond :)
[10:40] <seb128> rbasak, thanks for the wiki edit, that's a welcome improvement imho
[10:43] <rbasak> seb128: np. It wasn't at all obvious to me that relevant people didn't know how to contact us. So it was good feedback and good to get it documented :)
[11:08] -queuebot:#ubuntu-release- New binary: rustc [i386] (lunar-proposed/main) [1.63.0+dfsg0ubuntu1-0ubuntu1] (i386-whitelist)
[11:24] -queuebot:#ubuntu-release- New binary: rust-criterion [amd64] (lunar-proposed/universe) [0.3.6-2] (no packageset)
[11:35] -queuebot:#ubuntu-release- New binary: rustc [amd64] (lunar-proposed/main) [1.63.0+dfsg0ubuntu1-0ubuntu1] (i386-whitelist)
[11:41] -queuebot:#ubuntu-release- New binary: rust-criterion [riscv64] (lunar-proposed/universe) [0.3.6-2] (no packageset)
[12:07] -queuebot:#ubuntu-release- Unapproved: python-apt (bionic-proposed/main) [1.6.5ubuntu0.7 => 1.6.6] (core)
[12:10] <juliank> Getting around to doing python-apt releases a proper upstream way for this bug
[12:11] <juliank> Things will be a bit awkward in jammy as that'll move from 2.3.0 to 2.4.0 as that's the stable release series versioning, just forgot to close the 2.3 development branch
[12:23] <juliank> It's a bit annoying because of those mirror lists being updated at each point release which really shouldn't be in there
[12:42] <juliank> I think we accidentally end up with binutils installed in our autopkgtest images when tests should be depending on that
[12:43] <juliank> Because I see that now that I'm using autopkgtest ... -- podman ubuntu:<release> - running tests in those minimal images they fail because binutils are missing
[12:43] <juliank> same if I manually bootstrap a container with essential + apt
[12:45] -queuebot:#ubuntu-release- Unapproved: python-apt (focal-proposed/main) [2.0.0ubuntu0.20.04.8 => 2.0.1] (core, i386-whitelist)
[12:46] -queuebot:#ubuntu-release- Unapproved: python-apt (bionic-proposed/main) [1.6.5ubuntu0.7 => 1.6.6] (core)
[12:48] -queuebot:#ubuntu-release- Unapproved: rejected python-apt [source] (bionic-proposed) [1.6.6]
[12:48] -queuebot:#ubuntu-release- Unapproved: rejected python-apt [source] (bionic-proposed) [1.6.6]
[12:50] -queuebot:#ubuntu-release- Unapproved: tzdata (kinetic-proposed/main) [2022g-0ubuntu0.22.10.0 => 2022g-0ubuntu0.22.10.1] (core)
[12:55] -queuebot:#ubuntu-release- Unapproved: tzdata (jammy-proposed/main) [2022g-0ubuntu0.22.04.0 => 2022g-0ubuntu0.22.04.1] (core)
[12:57] -queuebot:#ubuntu-release- Unapproved: tzdata (focal-proposed/main) [2022g-0ubuntu0.20.04.0 => 2022g-0ubuntu0.20.04.1] (core)
[13:01] -queuebot:#ubuntu-release- Unapproved: python-apt (bionic-proposed/main) [1.6.5ubuntu0.7 => 1.6.6] (core)
[13:02] <juliank> I guess jammy gets 2.4.0 and kinetic gets 2.4.0+22.10
[13:02] <juliank> should make sure it builds in kinetic
[13:02] <juliank> We never built python-apt in kinetic, it was copied from lunar release at archive opening and received 0 updates :(
[13:03] <juliank> might as well upload 2.4.0 and binary copy it up to kinetic-proposed after it built in jammy-proposed
[13:22] -queuebot:#ubuntu-release- Unapproved: cargo (kinetic-proposed/universe) [0.62.0ubuntu1-0ubuntu2 => 0.64.0ubuntu0.libgit2-0ubuntu0.22.10] (i386-whitelist)
[13:44] <schopin> Could someone drop this cargo upload ^ ? I momentarily forgot that I'm supposed to go through the security PPA for those -_-
[13:58] -queuebot:#ubuntu-release- Unapproved: rejected cargo [source] (kinetic-proposed) [0.64.0ubuntu0.libgit2-0ubuntu0.22.10]
[14:01] <seb128> schopin, ^
[14:01] <schopin> thx :)
[14:01] <seb128> ahasenack, hey. I'm unsure if someone replied to your question yesterday, but checking https://autopkgtest.ubuntu.com/packages/g/gnss-sdr/lunar/s390x your retry had version =  0.0.17-1ubuntu2 , despite the trigger, I'm unsure why but that's the reason the status was still on failed
[14:02] <ahasenack> yeah, I was just checking on that
[14:02] <ahasenack> and see that when using ubuntu3, it's indeed failing
[14:02] <ahasenack> core dump
[14:02] <seb128> ahasenack, also I did retry and it picked the right version but it's failing to feels there is probably a real issue there
[14:02] <ahasenack> agreed
[14:02] <seb128> correct
[14:56] -queuebot:#ubuntu-release- Unapproved: accepted tmux [source] (jammy-proposed) [3.2a-4ubuntu0.1]
[15:10] <fnordahl> Anyone have a moment for openvswitch jammy 2.17.3-0ubuntu1? Now that the point release update to kinetic has been released it would be good to continue the process for jammy
[15:14] -queuebot:#ubuntu-release- New binary: rustc [ppc64el] (lunar-proposed/main) [1.63.0+dfsg0ubuntu1-0ubuntu1] (i386-whitelist)
[15:16] -queuebot:#ubuntu-release- New binary: rust-criterion [ppc64el] (lunar-proposed/universe) [0.3.6-2] (no packageset)
[15:48] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (kinetic-proposed) [2022g-0ubuntu0.22.10.1]
[16:01] -queuebot:#ubuntu-release- New: accepted golang-1.18 [source] (bionic-proposed) [1.18.1-1ubuntu1~18.04.1]
[16:01] -queuebot:#ubuntu-release- New: accepted golang-1.18 [source] (focal-proposed) [1.18.1-1ubuntu1~20.04.1]
[16:08] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (lunar-proposed/main) [2.06-2ubuntu15 => 2.06-2ubuntu15] (core, i386-whitelist)
[16:10] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (jammy-proposed) [2022g-0ubuntu0.22.04.1]
[16:10] -queuebot:#ubuntu-release- New binary: golang-1.18 [amd64] (bionic-proposed/none) [1.18.1-1ubuntu1~18.04.1] (no packageset)
[16:10] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (lunar-proposed/main) [2.06-2ubuntu15 => 2.06-2ubuntu15] (core, i386-whitelist)
[16:11] -queuebot:#ubuntu-release- New binary: rust-criterion [s390x] (lunar-proposed/universe) [0.3.6-2] (no packageset)
[16:12] -queuebot:#ubuntu-release- New binary: golang-1.18 [amd64] (focal-proposed/none) [1.18.1-1ubuntu1~20.04.1] (no packageset)
[16:13] -queuebot:#ubuntu-release- New binary: golang-1.18 [i386] (bionic-proposed/none) [1.18.1-1ubuntu1~18.04.1] (no packageset)
[16:17] -queuebot:#ubuntu-release- New binary: rust-criterion [arm64] (lunar-proposed/universe) [0.3.6-2] (no packageset)
[16:17] -queuebot:#ubuntu-release- New binary: rust-criterion [armhf] (lunar-proposed/universe) [0.3.6-2] (no packageset)
[16:18] -queuebot:#ubuntu-release- New binary: golang-1.18 [ppc64el] (bionic-proposed/none) [1.18.1-1ubuntu1~18.04.1] (no packageset)
[16:18] -queuebot:#ubuntu-release- New binary: golang-1.18 [ppc64el] (focal-proposed/none) [1.18.1-1ubuntu1~20.04.1] (no packageset)
[16:20] -queuebot:#ubuntu-release- New binary: golang-1.18 [s390x] (bionic-proposed/none) [1.18.1-1ubuntu1~18.04.1] (no packageset)
[16:22] -queuebot:#ubuntu-release- New binary: golang-1.18 [s390x] (focal-proposed/none) [1.18.1-1ubuntu1~20.04.1] (no packageset)
[16:24] <juliank> sil2100: If you can accept the grub2-unsigned upload in lunar, that'd be great. It's a bit annoying as we only need it because grub2 declares >= ${binary:Version} dependencies, but oh well. We'll resign everything with the new 2022 keys when they become available.
[16:25] <juliank> This does include all the CVE fixes which is nice
[16:26] <juliank> And some more fixes in the -unsigned bits we inherit from ubutnu14
[16:28] <sil2100> o/
[16:29] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (focal-proposed) [2022g-0ubuntu0.20.04.1]
[16:29] <ricotz> I have cancelled the retried libreoffice/kinetic builds for amd64/arm64, they require https://launchpad.net/ubuntu/+source/tiff/4.4.0-4ubuntu3.2
[16:29] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [amd64] (lunar-proposed) [2.06-2ubuntu15]
[16:29] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [arm64] (lunar-proposed) [2.06-2ubuntu15]
[16:33] <juliank> sil2100: thanks!
[16:40] -queuebot:#ubuntu-release- New binary: golang-1.18 [arm64] (bionic-proposed/universe) [1.18.1-1ubuntu1~18.04.1] (no packageset)
[16:47] -queuebot:#ubuntu-release- New binary: golang-1.18 [armhf] (bionic-proposed/universe) [1.18.1-1ubuntu1~18.04.1] (no packageset)
[16:49] -queuebot:#ubuntu-release- New binary: golang-1.18 [armhf] (focal-proposed/universe) [1.18.1-1ubuntu1~20.04.1] (no packageset)
[16:50] -queuebot:#ubuntu-release- New binary: golang-1.18 [arm64] (focal-proposed/universe) [1.18.1-1ubuntu1~20.04.1] (no packageset)
[17:18] <falcojr> ahasenack: cloud-init has an SRU for Bionic, Focal, Jammy, and Kinetic per https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1996645 . We have completed testing and would like to get a final review on it. We're aware that the current upload has not been through the full aging time, but we would like an exception to the normal aging process because this SRU contains a crucial fix to a regression preventing MAAS from updating to latest...
[17:18] -ubottu:#ubuntu-release- Launchpad bug 1996645 in cloud-init (Ubuntu) "sru cloud-init (22.3.4 to 22.4.2) Bionic, Focal, Jammy, Kinetic" [Undecided, New]
[17:18] <falcojr> ... images. Prior to the current upload, the previous upload aged appropriated and passed all tests. The current upload only has two additional commits that are targeted to specific scenarios that have been verified by their submitters.
[17:42] <ahasenack> falcojr: I'll look into it
[17:44] -queuebot:#ubuntu-release- New binary: rust-zstd [amd64] (lunar-proposed/none) [0.11.2-1] (no packageset)
[17:44] <ahasenack> falcojr: it's one day young?
[17:47] <falcojr> ahasenack: it was uploaded Tuesday, but there's only two additional commits that haven't aged
[17:47] <ahasenack> I thought it would be like just below the limit, like 5 or 6 days
[17:47] <ahasenack> but one day :)
[17:47] <ahasenack> I'll look at it, but I don't know if I have enough senioriry in the SRU team to tweak the rules like that
[17:48] <falcojr> thanks, we thought that since the original went through the aging, this wouldn't be a problem, but maybe it is
[17:49] <ahasenack> I can still count in my hand the number of SRU packages I have released into updates ;)
[17:50] <falcojr> I'm just trying to keep things interesting :)
[17:50] <ahasenack> I want to avoid the "Andreas pressed the button that broke the clouds" scenario ;)
[17:51] <ahasenack> "he died so young"
[17:59] -queuebot:#ubuntu-release- Unapproved: accepted swtpm [source] (kinetic-proposed) [0.6.3-0ubuntu4.1]
[18:24] -queuebot:#ubuntu-release- New binary: rust-zstd [riscv64] (lunar-proposed/universe) [0.11.2-1] (no packageset)
[18:26] -queuebot:#ubuntu-release- New binary: rust-zstd [s390x] (lunar-proposed/universe) [0.11.2-1] (no packageset)
[18:26] <ahasenack> falcojr: is that regression that affects maas from 22.4.0, or earlier? And which bug is it specifically?
[18:26] <ahasenack> is it the cloud-init status --wait one?
[18:26] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (kinetic-proposed) [2.23.0-0ubuntu1.1]
[18:28] <bdmurray> falcojr: What's the pressing reason for releasing it today as opposed to Monday?
[18:29] -queuebot:#ubuntu-release- New binary: rustc [i386] (lunar-proposed/main) [1.63.0+dfsg0ubuntu1-0ubuntu2] (i386-whitelist)
[18:30] <falcojr> https://bugs.launchpad.net/maas/+bug/1993836 is the one that affects maas...part of the original upload
[18:30] -ubottu:#ubuntu-release- Launchpad bug 1993836 in maas-images "Libvirt VM host provisioning never completes with image revision 20221018" [Critical, Triaged]
[18:30] -queuebot:#ubuntu-release- Unapproved: s390-tools (kinetic-proposed/main) [2.23.0-0ubuntu1 => 2.23.0-0ubuntu1.1] (core)
[18:31] <ahasenack> falcojr: at some point you decided to step on the breaks of the original 22.4.0 SRU (which aged properly) and fix two more bugs
[18:31] <ahasenack> and the MAAS bug is fixed in the original 22.4.0 upload
[18:32] <ahasenack> ("you decided": cloud-init team, not you you :)
[18:32] <ahasenack> so you made a choice to have the maas bug fix on hold because of the two new bugs you wanted to fix?
[18:33] <falcojr> Yes, we thought it'd be easier to roll our new fixes into the current SRU rather than start a new one. The Azure one (https://bugs.launchpad.net/cloud-init/+bug/1844191) came as a high priority customer request, so we thought we could move things along faster this way...but...maybe that was wrong
[18:33] -ubottu:#ubuntu-release- Launchpad bug 1844191 in cloud-init (Ubuntu) "azure advanced networking sometimes triggers duplicate mac detection" [Undecided, In Progress]
[18:34] <blackboxsw> ahasenack: the cloud-init status --wait bug was a regression discovered during  our SRU verification of 22.4.0 which meant we couldn't release 22.4.0.  Since we needed the fix for cloud-init status --wait we also folded in the high-priority fix for duplicate mac address failures for Azure.
[18:35] <bdmurray> So you discovered the regression when the package was still in -proposed? If that's correct I guess that speaks to your level of testing of things in -proposed.
[18:37] <blackboxsw> bdmurray,  this bug was discovered  by subiquity integration test runners on lunar for the same release we published to lunar before starting the SRU verification process. So it as an accolade for their test coverage that happened to give us a signal during our -proposed validation window
[18:37] <blackboxsw> so thanks ogayot for the bug during SRU verification^
[18:37] <bdmurray> And everything is passing now?
[18:38] <blackboxsw> yes, ogayot confirmed we are clear on that early boot status --wait race condition yesterday
[18:38] <bdmurray> and they didn't find anything else wrong? ;-)
[18:39] -queuebot:#ubuntu-release- New binary: rust-zstd [armhf] (lunar-proposed/universe) [0.11.2-1] (no packageset)
[18:39] <dbungert> I'm sure we could take another look
[18:39] <bdmurray> bug 1993836 has been open for months so I'm not clear on why its a rush job now
[18:39] -ubottu:#ubuntu-release- Bug 1993836 in maas-images "Libvirt VM host provisioning never completes with image revision 20221018" [Critical, Triaged] https://launchpad.net/bugs/1993836
[18:39] <blackboxsw> and I added his context to the bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1997559/comments/9
[18:39] -ubottu:#ubuntu-release- Launchpad bug 1997559 in cloud-init (Ubuntu Kinetic) "AttributeError: 'NoneType' object has no attribute 'partition'" [Undecided, Fix Committed]
[18:40] -queuebot:#ubuntu-release- New binary: rust-zstd [arm64] (lunar-proposed/universe) [0.11.2-1] (no packageset)
[18:41] -queuebot:#ubuntu-release- New binary: rust-zstd [ppc64el] (lunar-proposed/universe) [0.11.2-1] (no packageset)
[18:43] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools-signed [source] (kinetic-proposed) [2.23.0-0ubuntu1.1]
[18:43] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (kinetic-proposed) [2.23.0-0ubuntu1.1]
[18:44] <blackboxsw> bdmurray: it doesn't really have to be a rush job, but we would like to at least expedite by Monday if we could. MAAS team has pinned their images at an old cloud image version to prevent regression of deployments due to 1993836. Because those images are pinned they can't release new updates for customers or any critical bug fixes.... so there is time-sensitivity there in general.
[18:45] <blackboxsw> MAAS currently has a customer looking for such an update in image streams , but that update is blocked by the pin protecting MAAS deployments from being exposed to the provisioning bug in cloud-init fixed in 22.4.0/2
[18:51] <bdmurray> Let's play it safe and wait for Monday. If you can't find a European to do it early feel free to ping me.
[18:54] -queuebot:#ubuntu-release- New binary: rustc [amd64] (lunar-proposed/main) [1.63.0+dfsg0ubuntu1-0ubuntu2] (i386-whitelist)
[18:57] <blackboxsw> bdmurray: ahasenack thanks. that makes sense. This was a proposal to see if we are comfortable with the supplemental changeset with lack of aging given the confined nature of the supplemnetal bugs fixed and the manual validation performed. We'll bring this up next week. thanks gents
[18:58] <ahasenack> there is lack of aging, and there is 1 day :)
[18:59] -queuebot:#ubuntu-release- New binary: golang-1.18 [riscv64] (focal-proposed/universe) [1.18.1-1ubuntu1~20.04.1] (no packageset)
[19:04] -queuebot:#ubuntu-release- Unapproved: update-manager (jammy-proposed/main) [1:22.04.9 => 1:22.04.10] (core)
[19:14] -queuebot:#ubuntu-release- New binary: rustc [s390x] (lunar-proposed/main) [1.63.0+dfsg0ubuntu1-0ubuntu2] (i386-whitelist)
[19:17] -queuebot:#ubuntu-release- New binary: rustc [ppc64el] (lunar-proposed/main) [1.63.0+dfsg0ubuntu1-0ubuntu2] (i386-whitelist)
[19:24] -queuebot:#ubuntu-release- New binary: rustc [arm64] (lunar-proposed/main) [1.63.0+dfsg0ubuntu1-0ubuntu2] (i386-whitelist)
[19:25] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.10 => 1:20.04.10.11] (core)
[19:32] -queuebot:#ubuntu-release- Unapproved: sddm (kinetic-proposed/universe) [0.19.0-3ubuntu1 => 0.19.0-3ubuntu1.1] (kubuntu)
[19:41] -queuebot:#ubuntu-release- Unapproved: sddm (jammy-proposed/universe) [0.19.0-2ubuntu2 => 0.19.0-2ubuntu2.1] (kubuntu)
[20:47] -queuebot:#ubuntu-release- Unapproved: accepted tomcat9 [source] (focal-proposed) [9.0.31-1ubuntu0.4]
[20:55] -queuebot:#ubuntu-release- Unapproved: budgie-desktop (jammy-proposed/universe) [10.6.1-1ubuntu2 => 10.6.1-1ubuntu3] (personal-fossfreedom, ubuntu-budgie)
[21:09] -queuebot:#ubuntu-release- Unapproved: budgie-desktop (kinetic-proposed/universe) [10.6.4+git20220830-2 => 10.6.4+git20220830-2ubuntu1] (personal-fossfreedom, ubuntu-budgie)
[23:12] -queuebot:#ubuntu-release- New binary: rustc [armhf] (lunar-proposed/main) [1.63.0+dfsg0ubuntu1-0ubuntu2] (i386-whitelist)
[23:20] -queuebot:#ubuntu-release- New binary: age [amd64] (lunar-proposed/universe) [1.0.0-2] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: tiledb [amd64] (lunar-proposed/universe) [2.13.0-2] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: tiledb [ppc64el] (lunar-proposed/universe) [2.13.0-2] (no packageset)