[02:01] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Lunar Daily] has been updated (20230216) [02:08] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Jammy Daily] has been updated (20230216) [02:25] -queuebot:#ubuntu-release- Builds: Xubuntu Minimal amd64 [Lunar Daily] has been updated (20230216.1) === chris14_ is now known as chris14 [03:19] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Jammy Daily] has been updated (20230216) [05:35] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Jammy Daily] has been updated (20230216) [05:35] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Lunar Daily] has been updated (20230216) [05:35] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Lunar Daily] has been updated (20230216) [05:52] -queuebot:#ubuntu-release- Unapproved: py-macaroon-bakery (jammy-proposed/main) [1.3.1-2 => 1.3.1-2ubuntu0.1] (ubuntu-desktop) [05:52] -queuebot:#ubuntu-release- Unapproved: py-macaroon-bakery (kinetic-proposed/universe) [1.3.1-3 => 1.3.1-3ubuntu0.1] (ubuntu-desktop) [05:55] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Jammy Daily] has been updated (20230216) [06:24] In case it maters, I was able to retry the build failures for the package I was working on earlier (lxqt-policykit) that was failing due to python3, and the builds are succeeding this time, so it looks like things are at least closer to resolved, if not resolved already. [06:36] -queuebot:#ubuntu-release- New: accepted procps [amd64] (lunar-proposed) [2:4.0.2-3ubuntu1] [06:36] -queuebot:#ubuntu-release- New: accepted procps [armhf] (lunar-proposed) [2:4.0.2-3ubuntu1] [06:36] -queuebot:#ubuntu-release- New: accepted procps [ppc64el] (lunar-proposed) [2:4.0.2-3ubuntu1] [06:36] -queuebot:#ubuntu-release- New: accepted procps [s390x] (lunar-proposed) [2:4.0.2-3ubuntu1] [06:36] -queuebot:#ubuntu-release- New: accepted procps [arm64] (lunar-proposed) [2:4.0.2-3ubuntu1] [06:36] -queuebot:#ubuntu-release- New: accepted procps [riscv64] (lunar-proposed) [2:4.0.2-3ubuntu1] [06:36] -queuebot:#ubuntu-release- New: accepted procps [i386] (lunar-proposed) [2:4.0.2-3ubuntu1] [06:36] -queuebot:#ubuntu-release- New: accepted budgie-wallpapers [amd64] (lunar-proposed) [23.04.1] [06:36] -queuebot:#ubuntu-release- New: accepted retroarch [amd64] (lunar-proposed) [1.14.0+dfsg-1] [06:37] -queuebot:#ubuntu-release- New: accepted ghostscript [amd64] (lunar-proposed) [10.0.0~dfsg1-0ubuntu1] [06:37] -queuebot:#ubuntu-release- New: accepted ghostscript [armhf] (lunar-proposed) [10.0.0~dfsg1-0ubuntu1] [06:37] -queuebot:#ubuntu-release- New: accepted ghostscript [ppc64el] (lunar-proposed) [10.0.0~dfsg1-0ubuntu1] [06:37] -queuebot:#ubuntu-release- New: accepted ghostscript [s390x] (lunar-proposed) [10.0.0~dfsg1-0ubuntu1] [06:37] -queuebot:#ubuntu-release- New: accepted ghostscript [arm64] (lunar-proposed) [10.0.0~dfsg1-0ubuntu1] [06:37] -queuebot:#ubuntu-release- New: accepted ghostscript [riscv64] (lunar-proposed) [10.0.0~dfsg1-0ubuntu1] [06:37] -queuebot:#ubuntu-release- New: accepted ghostscript [i386] (lunar-proposed) [10.0.0~dfsg1-0ubuntu1] [06:57] -queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Lunar Daily] has been updated (20230216) [06:57] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Lunar Daily] has been updated (20230216) [06:57] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Lunar Daily] has been updated (20230216) [06:57] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Lunar Daily] has been updated (20230216) [06:57] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+licheerv [Lunar Daily] has been updated (20230216) [06:57] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+nezha [Lunar Daily] has been updated (20230216) [06:57] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+unmatched [Lunar Daily] has been updated (20230216) [06:57] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+visionfive [Lunar Daily] has been updated (20230216) [07:35] -queuebot:#ubuntu-release- New binary: rcheevos [amd64] (lunar-proposed/universe) [10.6.0-1] (no packageset) [07:35] -queuebot:#ubuntu-release- New binary: rcheevos [s390x] (lunar-proposed/universe) [10.6.0-1] (no packageset) [07:35] -queuebot:#ubuntu-release- New binary: rcheevos [armhf] (lunar-proposed/universe) [10.6.0-1] (no packageset) [07:36] -queuebot:#ubuntu-release- New binary: rcheevos [arm64] (lunar-proposed/universe) [10.6.0-1] (no packageset) [07:36] -queuebot:#ubuntu-release- New binary: rcheevos [ppc64el] (lunar-proposed/universe) [10.6.0-1] (no packageset) [07:40] -queuebot:#ubuntu-release- New: accepted rcheevos [ppc64el] (lunar-proposed) [10.6.0-1] [07:41] -queuebot:#ubuntu-release- New: accepted rcheevos [amd64] (lunar-proposed) [10.6.0-1] [07:41] -queuebot:#ubuntu-release- New: accepted rcheevos [armhf] (lunar-proposed) [10.6.0-1] [07:41] -queuebot:#ubuntu-release- New: accepted rcheevos [arm64] (lunar-proposed) [10.6.0-1] [07:41] -queuebot:#ubuntu-release- New: accepted rcheevos [s390x] (lunar-proposed) [10.6.0-1] [07:45] -queuebot:#ubuntu-release- New binary: rcheevos [riscv64] (lunar-proposed/universe) [10.6.0-1] (no packageset) [07:46] -queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Jammy Daily] has been updated (20230216) [07:46] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Jammy Daily] has been updated (20230216) [07:46] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Jammy Daily] has been updated (20230216) [07:46] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Jammy Daily] has been updated (20230216) [07:46] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+licheerv [Jammy Daily] has been updated (20230216) [07:46] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+nezha [Jammy Daily] has been updated (20230216) [07:46] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+visionfive [Jammy Daily] has been updated (20230216) === Eickmeyer5 is now known as Eickmeyer [08:19] LocutusOfBorg: so what do we do with llvm-toolchain-14 failing its autopkgtests? [08:20] (and blocking NBS removals) [08:23] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Lunar Daily] has been updated (20230216) [08:28] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Lunar Daily] has been updated (20230216) [08:28] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Lunar Daily] has been updated (20230216) [08:28] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Lunar Daily] has been updated (20230216) [08:28] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Lunar Daily] has been updated (20230216) [08:29] vorlon, hint them? :) [08:30] they are new tests, tracked in debian bug: #1027013 [08:30] -ubottu:#ubuntu-release- Debian bug 1027013 in src:llvm-toolchain-14 "llvm-toolchain-14 autopkg test fails" [Serious, Open] https://bugs.debian.org/1027013 [08:37] LocutusOfBorg: or remove the broken tests to not regress autopkgtest coverage? [08:37] icingaweb2-module-pdfexport Depends: chromium, wtf² [08:40] -queuebot:#ubuntu-release- Builds: Ubuntu Core amd64 edge [Lunar Daily] has been updated (20230216) [08:42] vorlon, it takes days to build... [08:42] [08:42] and I would like to fix in Debian and then sync [08:42] well, when it's fixed in Debian, great [08:43] in the meantime I've uploaded to disable the broken autopkgtest [08:43] so that it's migratable and I can drop libgrpc10 [08:44] migratable, if autopkgtests wants to run [08:44] yes [08:44] they are running; just have a backlog and the infra is still requiring handholding [08:44] oh... you dropped too much [08:44] did I? [08:44] that qualify-clang.sh was not newly introduced, some content inside that script was :D [08:45] hmm well [08:45] if you want to fix it up I can cancel builds for -10ubuntu2 [08:46] yeah please lets fix [08:46] properly I mean [08:46] I'm doing it after some scrum daily meeting [08:46] ok [09:04] -queuebot:#ubuntu-release- Packageset: Added llvm-toolchain-16 to i386-whitelist in lunar [09:07] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Jammy Daily] has been updated (20230216) [09:07] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64 [Jammy Daily] has been updated (20230216) [09:07] -queuebot:#ubuntu-release- New: accepted rcheevos [riscv64] (lunar-proposed) [10.6.0-1] [09:22] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64+raspi [Lunar Daily] has been updated (20230216) [09:45] Uploading llvm-toolchain-14_14.0.6-11_source.changes [09:50] I let only amd64 and arm64 build [10:07] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64+raspi [Jammy Daily] has been updated (20230216) [10:08] hmmm, why is the daily milestone reporting status here..? [10:09] -queuebot:#ubuntu-release- Builds: 49 entries have been added, updated or disabled [10:13] -queuebot:#ubuntu-release- Builds: 52 entries have been added, updated or disabled [10:24] juliank: hey! I see the shims in proposed have block-proposed tags [10:24] juliank: does that mean we still want to wait with the release of those? [10:24] they have block tags for the kernel waiting [10:24] so I guess they can be removed now [10:26] sil2100: blocks removed [10:27] klebers: hey! Just to be entirely sure: the new-key-signed kernels have landed in kinetic-updates already, right? [10:29] juliank: btw. on https://bugs.launchpad.net/oem-priority/+bug/1842320 I see someone mentioning that the bug isn't fixed for them..? [10:29] -ubottu:#ubuntu-release- Launchpad bug 1842320 in OEM Priority Project "Can't boot: 'error: out of memory.' immediately after the grub menu" [Critical, Triaged] [10:29] well yes they didn't install the fixed version [10:30] pffff [10:30] :D [10:30] Ok, releasing in that case [10:37] I guess we can also unblock and mark the cd-boot-images as good, right? Did you test some of the newer jammy dailies? [10:41] juliank: ^ [10:43] sil2100, hey! Do you mean jammy-updates? [10:44] klebers: no no, kinetic-updates. Since jammy-updates I know we already resolved yesteday, but I wanted to release the new shims for kinetic and others too [10:45] sil2100, I see! Yes, all kinetic kernels that we have signed with the new key are already in kinetic-updates [10:45] \o/ [10:45] Thanks! [10:46] yw! :) [10:50] klebers: also, just to double-make-sure (since I see some kernels in jammy-proposed, but I suppose those are the 'next cycle') - are all the cloud kernels for jammy with the new keys already in jammy-updates? [10:51] I wouldn't want to break someone by releasing shim suddenly. But I think we were only waiting for hwe to have the complete set, so others were already there, right? [10:58] sil2100, we still have two private kernels that were not released to jammy-updates yet (jammy/linux-fips and jammy/linux-intel-iot-realtime). I'm not sure though whether they are signed with the new key, I'll double check with the team [11:11] Ouch, would that block the shim release? [11:11] Since I already released it for jammy [11:22] -queuebot:#ubuntu-release- New binary: kodi-game-libretro [amd64] (lunar-proposed/universe) [20.2.2-2] (no packageset) [11:23] -queuebot:#ubuntu-release- New binary: kodi-game-libretro [arm64] (lunar-proposed/universe) [20.2.2-2] (no packageset) [11:23] -queuebot:#ubuntu-release- New binary: kodi-game-libretro [ppc64el] (lunar-proposed/universe) [20.2.2-2] (no packageset) [11:25] -queuebot:#ubuntu-release- New binary: kodi-game-libretro [armhf] (lunar-proposed/universe) [20.2.2-2] (no packageset) [11:35] sil2100: jammy is not ready for new shim yet! [11:35] hm [11:36] sil2100: KINETIC is ready and you released in kinetic. [11:36] sil2100: lunar and jammy are not ready yet [11:39] -queuebot:#ubuntu-release- New binary: kodi-game-libretro [s390x] (lunar-proposed/universe) [20.2.2-2] (no packageset) [11:40] -queuebot:#ubuntu-release- New binary: kodi-game-libretro [riscv64] (lunar-proposed/universe) [20.2.2-2] (no packageset) [11:42] xnox: that is not what I have been told [11:43] xnox: juliank unblocked shims in jammy, I've been told that the hwe kernels were the last thing blocking the shim updates [11:43] Do I need to revert? [11:43] juliank: ^ [11:44] xnox: what are we waiting for in jammy still? I need to have the new shim there for the point release [11:44] sil2100: where/where you saw juliank speak about jammy? date-time timestamps? [11:44] xnox: what's missing in jammy now? [11:44] xnox: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1996503/comments/25 [11:44] -ubottu:#ubuntu-release- Launchpad bug 1996503 in shim-signed (Ubuntu) "shim 15.7-0ubuntu1" [Undecided, In Progress] [11:44] xnox: you said we're waiting for generic and 5.19 hwe, both are released. [11:46] juliank: kernels are not considered out, until they are replicated to mirrors (mirror dwell) and until they are copied to security. it is being rolled out but it is not out. [11:46] I need to know ASAP if I need to remove jammy-updates shim and get the old one back [11:46] juliank: see our dashboard which doesn't say that hwe-5.19 and lowlatancy-hwe-5.19 is fully out yet. [11:47] sil2100: set phasing to zero % [11:47] xnox: but security and mirrors are irrelevant to us [11:47] juliank: they are not. [11:47] we only waited for the kernels for image building [11:47] juliank: the kernel is not out yet. [11:47] it is in the -updates pocket, where the images are being built from [11:47] juliank: you can brick people [11:47] it's irrelevant to the image building if it is on the mirrors or in security yet [11:47] that's not good. [11:48] juliank: i don't care about your image people =) [11:48] you cannot brick installed systems [11:48] have you met our users?! =) [11:48] because they only install the new shim if their booted kernel and any newer kernel is not revoked [11:49] I phased it to 0 for now, but IIRC from my converstaions with juliank, he made sure that out-of-order upgrades should be handled [11:49] did you miss the entire bit about how it installs the old kernels and sets up an alternative to switch them? [11:49] ...... we have a tonne of people who don't use that to choose what to boot with what [11:49] https://code.launchpad.net/~juliank/shim/+git/shim-signed/+merge/436050 [11:50] juliank: you are not kernel team to decide when all the kernels are out =) [11:52] xnox: it is out to users, is all I say [11:52] juliank: it isn't. [11:52] and users can install shims and kernels in any order and get safe results [11:53] !!!!!! [11:53] sil2100: please revert shim and shim-upgrade in focal [11:53] focal is not ready [11:54] juliank: dude [11:54] xnox: eek, ok [11:56] sil2100: juliank: yesterday it was asked which series are good to go, and the answer was only kinetic. things have not changed dramatically since. so i am very surprised why a non-sru team member, who is not kernel-team member deciding to release shim to jammy and focal. [11:56] that's not ok. [11:58] juliank was the one preparing and verifying the shim updates, so it was obvious to me to ask him about the readiness of the SRUs. I was not aware of having to wait additionally for the jammy kernels, the only information I got was: "we need jammy kernels to be released". The state 'jammy released' is not automatically same to 'fully synced on mirrors' [11:58] sil2100: also i'm not sure if kinetic is fine w.r.t. image building given grub is phased at 59% yet. [11:58] When sil2100 asked me this morning I double checked that the kernels were in the updates pocket publishing [11:58] xnox: It does not matter [11:59] xnox: please understand that image building ignores phasing and that the shim also breaks the old grubs and fwupd-signed, so you can't end up with unbootable images there no matter what you do [12:00] juliank: our image building ignores phasing, sure. but not everyone elses. [12:00] that's where the 2nd part comes in [12:00] also you have to put in a lot of effort to build an image with phasing [12:01] I know it might be 'risky', but as juliank said, users should not be able to brick their device just because they get the new shim without the new kernel [12:01] not really, we have people snapshot live system and do apt download from the live system to force unpack stuff. [12:01] phasing just isn't active in containers, chroots, only systems with an init [12:01] more or less [12:01] that's where people do get versions of installed packges and unapck them. [12:01] Anyway, reverting focal right now [12:01] unfortunately [12:02] then all work is futile, we delay the point release another month and do two kernel SRU cycles [12:02] I mean that's the only realistic way you can ensure safety there by having the kernels out for enough time for everyone to have them [12:03] and that's precisely what we're trying to avoid here [12:03] in the normal world we would have had the signing PPAs ready in October, signed new kernels last year and then went ahead with the shim update in February and everyone would have been happy [12:05] but we had basically 3 months of delays after generating the signing keys and then push to have the shim out ASAP [12:05] Also, as for asking for status and who is to be asked for go/no-go - juliank is the maintainer of shim and was coordinating the release of the new shim, so he feels like the best person to ask for readiness. I could have asked for a really explicit +1 from the kernel team as well, but I did not get a hold-the-line signal at any point up until now after we released the kernels yesterday [12:06] sil2100: yesterday i was asked which kernels were ready, and the answer was only kinetic. [12:06] that's it. [12:06] I have raised the concern of users upgrading things out of order with juliank when he started preparing the shim uploads, and he made sure to do it the best way he could [12:07] sil2100: I mean I thought you were aware of the kernel releases, saw they were all in updates and pinged me asking if anything else is blocking them [12:07] we previously agreed to have kernels in -security pocket, before releasing shim to updates [12:07] i don't see why we are backtracking on that agreement. [12:07] xnox: who was it agreed with? [12:07] xnox: I am not aware of any such agreement [12:07] Then it was not communicated to me [12:07] And I am the lead for 22.04.2 [12:08] Today is the planned date of when we NEED to have everything for .2 ready in -updates [12:08] my awareness regarding kernels is to wait until they are released, which for purposes of SRU ordering, means accepted into -updates. [12:08] it's not like if you accept shim after kernels that they can appear on the mirror before the kernels [12:10] sil2100: hi, seeing talks of .2, is there an SRU freeze in place perhaps that I have missed? [12:10] when we originally planned this I was saying we should have two kernel SRU cycles completed before releasing shim but that didn't work [12:10] ahasenack: I think it was completely forgotten to announce any kind of SRU freeze for jammy, tbh [12:10] klebers, xnox: ok, now I need an explicit information: can the kernels be ready enough for us to have shim fully released today? Since if we're waiting for security as a requirement, this means 'no' and this introduces a serious issue in our timeline [12:10] ahasenack: I'm almost done with the e-mail [12:10] I knew a dot release was/is coming up, and that its date was pushed once or twice, so I've been expecting that sru freeze email, but none so far [12:10] juliank: it was not forgotten [12:11] ah [12:11] juliank: we only send that today [12:11] ah [12:11] sil2100: focal is out of scope, i hope that's clear. [12:11] sil2100: tldr accepting into proposed is still fine, just not updates, is that it? [12:11] I don't care about focal, my bad that I released it. That's entirely on me [12:11] ack. [12:12] But the jammy situation agitates me a lot [12:12] now jammy [12:12] both hwe-5.19 and lowlatency-hwe-5.19 are ready to be copied to security [12:12] can you do that? [12:12] https://bugs.launchpad.net/kernel-sru-workflow/+bug/2004157 [12:12] -ubottu:#ubuntu-release- Launchpad bug 2004157 in Kernel SRU Workflow "jammy/linux-hwe-5.19: 5.19.0-32.33~22.04.1 -proposed tracker" [Medium, In Progress] [12:12] https://bugs.launchpad.net/kernel-sru-workflow/+bug/2006747 [12:12] -ubottu:#ubuntu-release- Launchpad bug 2006747 in Kernel SRU Workflow "jammy/linux-lowlatency-hwe-5.19: 5.19.0-1017.18~22.04.1 -proposed tracker" [Medium, In Progress] [12:14] xnox: so will you commit to removing the block-proposed tags on https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1996503 as necessary then? [12:14] -ubottu:#ubuntu-release- Launchpad bug 1996503 in shim-signed (Ubuntu) "shim 15.7-0ubuntu1" [Undecided, In Progress] [12:14] xnox: because I can't guess when you're happy, sorry [12:14] juliank: yes i will commit to removing block-proposed tags [12:15] -queuebot:#ubuntu-release- Unapproved: shim-signed (focal-updates/main) [1.40.9 => 1.40.7] (core) (sync) [12:16] -queuebot:#ubuntu-release- Unapproved: shim (focal-updates/main) [15.7-0ubuntu1 => 15.4-0ubuntu9] (core) (sync) [12:16] klebers: re: jammy:linux-fips => it's ok, as it fails to boot by itself anyway =) [12:17] haha [12:19] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [sync] (focal-updates) [1.40.7] [12:19] -queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (focal-updates) [15.4-0ubuntu9] [12:19] klebers: re:linux-intel-iot-realtime it is up to date [12:19] where it needs to be [12:21] i see one image build that will be broken for private kernel [12:22] I wasn't aware of those being a blocker. I only knew hwe and ga kernels were still blocking shim [12:23] that was what was communicated, yes [12:24] basically "we need to wait for kernels used in images", "what are those", "ga and hwe" [12:24] the expectation was that one would be have been out by 1st of february but it didn't go out as far as i can see [12:26] xnox: I can release the kernels to -security indeed! But I thought there was always a some-day-ish delay between updates and security due to bandwidth? [12:26] Or is that not a concern anymore? [12:27] sil2100: the dwelling delay has passed, our report says mirrors are sufficiently up to date, so it is ready for security [12:28] sil2100: see https://kernel.ubuntu.com/sru/dashboards/web/kernel-stable-board.html?cycle=2023.01.02 [12:29] previously it said "holding release to security, waiting for replication dwell" or some such [12:30] Ok, then ugh, running the manual release commands! [12:33] xnox: at least we are learning now for when we need to do the whole dance for NX support againb [12:35] sil2100, adding that as a note for after the current fires, but you probably want to release bug #1990368 to J otherwise the ISO will probably start to fail to build once you switch to use updates instead of proposed since that new package is a depends of software-properties-gtk now [12:35] -ubottu:#ubuntu-release- Bug 1990368 in ubuntu-advantage-desktop-daemon (Ubuntu Jammy) "Rename Ubuntu Advantage to Ubuntu Pro" [Undecided, Fix Committed] https://launchpad.net/bugs/1990368 [12:36] xnox: ok, just to confirm - since I see on the tracking bug "promote-to-security: []", I should simply release the set of packages that are in promote-to-updates, right? They're really ready-ready? [12:37] xnox: because all our kernels need whatever the current version of https://lore.kernel.org/linux-kernel/cover.1668958803.git.baskov@ispras.ru/ is for the next shim, sigh. [12:37] sil2100, sorry, I didn't notice that the previous version was moved to updates, so probably not an ISO build issue but still would be nice to get. It was verified ages ago but seems the tag editing failed :/ [12:38] sil2100: it is confusing but yes it is all of them. [12:38] juliank: =)))))))))))))))))))))))))))))))))))))))))))) yeah, nx stuff will be fun. [12:39] xnox: And I need to figure out if the kernel has the patchset from the binary in a bash script so I can adjust my script for revoked kernels to check for non-NX kernels [12:39] sil2100: juliank: i copied a contingency for the remaining private kernel. so once hwe-5.19 and lowlatency-hwe-5.19 are in security, i am happy to have shim / shim-signed in jammy to be phasing normally. [12:39] xnox: or maybe I don't, I don't know if there is firmware out there with NX that boots the shim without NX now [12:40] meanwhile checking focal state [12:40] Whoops on focal ;p [12:40] like maybe the NX shim doesn't need to be ordered after any other NX bits because the firmware that uses the NX bit in the shim wouldn't boot the old one either [12:40] I removed the shims and tried copying in the old ones [12:41] Not sure if it all didn't overly confuse the publisher [12:41] I did phase them to 0 just-in-case before doing the revert dance [12:41] juliank: sil2100: btw there are multiple escalations on snapd side of things, as people have been using shim from proposed / ubuntu archive to build their gadgets with out dated kernel snaps and fail. Especially since the snapstore emailed them saying their stuff is out of date =) [12:41] sil2100: let's wait for a publisher cycle and check with rmadision [12:41] from proposed -> lol [12:41] i know [12:42] updates? it's only been out 2 hours [12:42] that's why i say, our users are amazing [12:42] the details are fuzzy, but they did break themselves [12:42] why would they get alerts that quickly [12:42] i don't trust they are doing anything right [12:43] sil2100: the publishing records look good. [12:44] seb128: phew, I'll get to that eventually! Thanks! [12:46] xnox: Just write them "Thank you for testing our pre-release software. Problems like this can be expected. We value your feedback" [12:47] eh, need to use copy-package directly since the kernels got already removed from -proposed [12:48] juliank: i like it. are you learning your customer phasing writting skills with help of chatgpt? [12:48] *facing [12:48] xnox: yes [12:48] sil2100: yeah -updates to -security [12:49] xnox: But I should pass it through it. [12:50] I asked ChatGPT: [12:50] > Customers had issues installing new 'shim' package. But this is pre-release software. Write a reply saying that we thank them for testing pre-release software and problems are expected. [12:50] xnox: this is the chatgpt version https://paste.ubuntu.com/p/G7jkKDM2yC/ [12:51] love it [12:51] basically I write a bug reply, I jsut tell ChatGPT to reformulate it [12:51] -queuebot:#ubuntu-release- Unapproved: linux-lowlatency-hwe-5.19 (jammy-security/main) [5.19.0-1017.18~22.04.1 => 5.19.0-1017.18~22.04.1] (no packageset) (sync) [12:51] -queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-lowlatency-hwe-5.19 (jammy-security/restricted) [5.19.0-1017.18~22.04.1+1 => 5.19.0-1017.18~22.04.1+1] (no packageset) (sync) [12:51] -queuebot:#ubuntu-release- Unapproved: linux-meta-lowlatency-hwe-5.19 (jammy-security/main) [5.19.0.1017.18~22.04.4 => 5.19.0.1017.18~22.04.4] (no packageset) (sync) [12:51] -queuebot:#ubuntu-release- Unapproved: linux-signed-lowlatency-hwe-5.19 (jammy-security/main) [5.19.0-1017.18~22.04.1 => 5.19.0-1017.18~22.04.1] (no packageset) (sync) [12:52] Can we integrate chatgpt into launchpad? [12:52] "Suggested rewording" [12:52] -queuebot:#ubuntu-release- Unapproved: linux-restricted-signatures-lowlatency-hwe-5.19 (jammy-security/restricted) [5.19.0-1017.18~22.04.1+1 => 5.19.0-1017.18~22.04.1+1] (no packageset) (sync) [12:53] You can give it one statement, it transforms it into a knowledgebase entry, a blog post, and a press release with fake c-level quotes. [12:53] xnox: I guess those look fine ^ ? [12:53] signatures? [12:54] it is there in the queue [12:54] i guess queubot is slow [12:54] Yummy kernels [12:54] sil2100: yes please approve those syncs, they look good [12:55] -queuebot:#ubuntu-release- Unapproved: accepted linux-lowlatency-hwe-5.19 [sync] (jammy-security) [5.19.0-1017.18~22.04.1] [12:55] -queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules-lowlatency-hwe-5.19 [sync] (jammy-security) [5.19.0-1017.18~22.04.1+1] [12:55] -queuebot:#ubuntu-release- Unapproved: accepted linux-signed-lowlatency-hwe-5.19 [sync] (jammy-security) [5.19.0-1017.18~22.04.1] [12:55] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta-lowlatency-hwe-5.19 [sync] (jammy-security) [5.19.0.1017.18~22.04.4] [12:55] -queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-signatures-lowlatency-hwe-5.19 [sync] (jammy-security) [5.19.0-1017.18~22.04.1+1] [12:55] fwiw, I only see linux-generic 5.15.0.60.58 [12:55] on archive.ubuntu.com from my hetzner vps [12:56] above was only lowlatency stuff [12:56] hwe-5.19 is separate [12:57] just src:linux [12:57] ah [12:57] I confuse that and the 66 in proposed is the next cycle [12:58] :D [12:58] I think I should take a break :D [12:58] Get some espresso into me [13:02] -queuebot:#ubuntu-release- Unapproved: linux-hwe-5.19 (jammy-security/main) [5.19.0-32.33~22.04.1 => 5.19.0-32.33~22.04.1] (no packageset) (sync) [13:02] -queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-hwe-5.19 (jammy-security/restricted) [5.19.0-32.33~22.04.1 => 5.19.0-32.33~22.04.1] (no packageset) (sync) [13:02] -queuebot:#ubuntu-release- Unapproved: linux-meta-hwe-5.19 (jammy-security/main) [5.19.0.32.33~22.04.9 => 5.19.0.32.33~22.04.9] (no packageset) (sync) [13:02] -queuebot:#ubuntu-release- Unapproved: linux-restricted-signatures-hwe-5.19 (jammy-security/restricted) [5.19.0-32.33~22.04.1 => 5.19.0-32.33~22.04.1] (no packageset) (sync) [13:02] sil2100: our dashboard is happy with jammy/linux-lowlatency-hwe-5.19 it is now marked as phase: Complete [13:03] sil2100: the hwe-5.19 copies look good but i don't see linux-signed-hwe-5.19 [13:03] https://launchpad.net/ubuntu/jammy/+queue?queue_state=1&queue_text=linux [13:05] Should be there, maybe it lagged a bit [13:05] Heh proposed -> lol from me is strong as I have src:linux src:linux-signed src:linux-meta src:apt src:python-apt pinned up for proposed :D [13:05] -queuebot:#ubuntu-release- Unapproved: linux-signed-hwe-5.19 (jammy-security/main) [5.19.0-32.33~22.04.1 => 5.19.0-32.33~22.04.1] (no packageset) (sync) [13:06] Some days I run kernels directly from o=LP-PPA-canonical-kernel-team-unstable [13:06] o/ [13:06] what about cd-boot-images? [13:06] -queuebot:#ubuntu-release- Unapproved: accepted linux-hwe-5.19 [sync] (jammy-security) [5.19.0-32.33~22.04.1] [13:06] -queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules-hwe-5.19 [sync] (jammy-security) [5.19.0-32.33~22.04.1] [13:06] -queuebot:#ubuntu-release- Unapproved: accepted linux-signed-hwe-5.19 [sync] (jammy-security) [5.19.0-32.33~22.04.1] [13:06] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta-hwe-5.19 [sync] (jammy-security) [5.19.0.32.33~22.04.9] [13:06] -queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-signatures-hwe-5.19 [sync] (jammy-security) [5.19.0-32.33~22.04.1] [13:07] can they be released? [13:08] sil2100: signing tarballs should be rejected [13:08] I think those should be fine, I don't think anyone besides our cdimage/debian-cd infra uses those [13:08] sil2100: nothing may use them =) as they will contiain invalid broken signatures ;-) [13:08] I'm sitting around with half my issues blocked and people looking at me sadly because they haven't moved pulse after pulse [13:08] :D [13:09] sil2100: pending publications all look good. [13:09] xnox: I meant cd-boot-images! [13:09] ah [13:10] xnox: the signing tarballs I'll reject indeed ;p [13:10] I haven't set verfication-done on those, but they are verifying themselves basically [13:10] yes cd-boot-images is fine to release in jammy and kinetic [13:10] I didn't test any of the images on secure-boot though [13:11] But as long as they're built, I guess they're good [13:11] they're the same binaries as in the main archive [13:11] well you know what I mean [13:11] (for secure boot anyway) [13:12] well the cd one is like totally different (smirk) [13:12] Anyhow we'll only find out when we build images [13:12] Normally images build with -proposed enabled but I guess they don't do right now? [13:13] What I know is that they are not revoked [13:13] :D [13:13] All the recent images were built with -proposed, yes [13:14] archive should publish quicker [13:14] well then the packages were tested by iso testing [13:14] :D [13:14] still pending [13:17] hello sru team, I'd like to see if we can get a review of aodh in jammy unapproved and neutron in focal unapproved please [13:18] coreycb: seeded-in-ubuntu aodh [13:18] aodh-doc (from aodh) is seeded in: [13:18] kubuntu: supported [13:18] lubuntu: supported [13:18] ubuntu-budgie: supported [13:18] ubuntu-mate: supported [13:18] ubuntu: supported [13:18] ubuntukylin: supported [13:18] xubuntu: supported [13:18] does not affect images. [13:18] but busy with point release stuff. [13:19] afk to lunch [13:20] xnox: ah, sorry.. is that soft freeze related for jammy? [13:20] I assume so [13:28] New livecd-rootfs incoming, will self-accept it like a terrible person [13:28] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (jammy-proposed/main) [2.765.15 => 2.765.16] (desktop-core, i386-whitelist) [13:33] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (jammy-proposed) [2.765.16] [13:50] linux-hwe-5.19 phase: Complete [13:51] sil2100: juliank: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1996503/comments/33 [13:51] -ubottu:#ubuntu-release- Launchpad bug 1996503 in shim-signed (Ubuntu) "shim 15.7-0ubuntu1" [Undecided, In Progress] [14:06] -queuebot:#ubuntu-release- Unapproved: accepted net-snmp [source] (kinetic-proposed) [5.9.3+dfsg-1ubuntu1.3] [14:07] -queuebot:#ubuntu-release- Unapproved: accepted net-snmp [source] (jammy-proposed) [5.9.1+dfsg-1ubuntu2.5] [14:19] o/ [14:20] I'll resume phasing soon in that case [15:17] sil2100: I see Studio is still very broken due to linux-lowlatency. [15:19] Eickmeyer: it should be good now! [15:19] Eickmeyer: I missed one line in livecd-rootfs, re running the build just now as I see the package is now published [15:20] sil2100: Ok, good to know. I'll keep an eye. I was running out of tears to cry XD [15:25] ;) [15:26] Ok, requested build, fingers crossed! [15:28] * Eickmeyer watches while sipping coffee [15:34] xnox: shenanigans meet? [15:55] -queuebot:#ubuntu-release- Unapproved: shim-signed (focal-updates/main) [1.40.9 => 1.40.7] (core) (sync) [15:56] ... [15:56] -queuebot:#ubuntu-release- Unapproved: shim (focal-updates/main) [15.7-0ubuntu1 => 15.4-0ubuntu9] (core) (sync) [15:56] vorlon: I guess those look correct? https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=shim [16:01] sil2100: that is correct please accept [16:01] sil2100: you put it in unapproved? :) yeah that looks correct to me [16:01] I am extra cautious today ;) [16:02] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [sync] (focal-updates) [1.40.7] [16:02] -queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (focal-updates) [15.4-0ubuntu9] [16:14] -queuebot:#ubuntu-release- Unapproved: base-files (jammy-proposed/main) [12ubuntu4.2 => 12ubuntu4.3] (core, i386-whitelist) [16:15] vorlon, bdmurray: can one of you take a look at base-files? Just pushed it to unapproved ^ [16:16] Eickmeyer: http://cdimage.ubuntu.com/ubuntustudio/jammy/dvd/20230216.1/ \o/ [16:16] \o/ [16:16] Gonna sync that biznezz when I get back from taking my son to school this morning. [16:16] Thanks o/ [16:19] vorlon: short ubuntu queue is running tests from 8 days ago. is there a shorter than short queue please? [16:20] i need kernels, dkms, nvidia out of proposed to start uploading new ones, as the -release pocket has useless stuff at this point. [16:35] also i need dkms to migrate, which does have regression w.r.t. zfs test case handling, so i am thinking to upload dkms again since it shouldn't matter since all the tests are still not running. [16:35] QA team can hack kernel stuff to the top of the queue [16:35] It's a bit annoying [16:36] dump queue in file, requeue the kernel things, and then requeue the others again [16:37] bdmurray: autopkgtest.u.c should use priority queues that would be easier, then we can bump priorities around; and you could penalize failing tests by requueing them with lower priority [16:37] -> https://www.rabbitmq.com/priority.html [16:38] I don't know I might have created the queues priority ready [16:39] there should be like priority = some-function(number of retries, age, base priority) + bump [16:40] ah no the queues had to be recreated from scrach with priorities I don't think I did that [16:40] hello [16:40] xnox: we still aob meeting [16:41] we need to reupload all lrm because of change of nvidia; we need to upload all kernels due to signing change; we need to reupload dkms because it has error codes regressions making zfs-linux false negative. all of the above triggers hundreds of tests each in an explosive matrix. [16:41] and it is useless, as we have tested these things by hand locally, because of the testing lag, hence it would be nice to release dkms things to with skip test [16:42] yeah it sucks that we are time based and don't have priorities right now [16:43] juliank: should i gate crash? [16:43] we're closing [16:43] vorlon: come back =) [16:50] i really want to put dkms into sync blacklist [16:52] xnox: why? It is currently in sync with Debian; do you want to freeze it there? [16:54] ginggs: scipy-triggered tests down from 3170 to 1626 and dropping [16:54] vorlon: thanks! [16:54] vorlon: because 7 in a row uploads syncs from debian caused regressions across all of our dkms and autopkgtest infrastructure generating over 1000+ failed autopkgtests builds in a row, and it is still broken. === andypandy_ is now known as andypandy [16:54] literary new upstream release; and debian revision updates have been a dumpster fire in both debian and ubuntu autopkgtest infra [16:55] and it is still bad [16:55] -queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (jammy-proposed) [12ubuntu4.3] [16:55] and somehow debian maintainers are trigger happy to sync dkms package to ubuntu, which sets back kernel team trying to migrate a kernel. [16:55] LocutusOfBorg: can you stop uploading dkms to ubuntu please? [16:56] as at this point, i sort of on the verge of reverting back to what we currently have in lunar-release. [16:57] I'm in another meeting [17:15] -queuebot:#ubuntu-release- Unapproved: thermald (kinetic-proposed/main) [2.5.1-1 => 2.5.1-1ubuntu1] (core) [17:16] xnox: if dkms has regressions, please do upload it to fix; we can filter stale test requests out of the queue [17:17] xnox: how does a new dkms package in -proposed which is broken and won't pass autopkgtests impact the kernel team's migration? [17:18] -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (jammy-proposed) [12ubuntu4.3] [17:18] bdmurray: why does your python-apt/jammy have regressed autopkgtests for apport and aptdaemon? [17:19] How could it have completed tests? ;-) [17:19] bdmurray: because the jammy queue is shorter [17:20] bdmurray: previous successful autopkgtests in jammy were Jan 18, so not an issue of long-term bitrot in stable release [17:21] bdmurray: I'm retrying them with --no-proposed anyway [17:22] SystemError: E:Failed to fetch http://ddebs.ubuntu.com/dists/focal/main/binary-amd64/Packages.xz File has unexpected size (514024 != 513848). Mirror sync in progress? [IP: 91.189.91.49 80] [17:22] Hashes of expected file: [17:22] Just retry it [17:22] ok [17:22] Or that was apport [17:23] LoL that dbus namehasnoowner error appears in the aptdaemon autopkgtest [17:24] Anyway, I'd just retry both of them. [17:25] xnox, it was buggy autopkgtests for itself. [17:25] and it was uploaded in Debian 3 days ago [17:27] vorlon, please sfepy/i386 hint please? [17:30] also dkms/i386 please... (I'm asking about autopkgtests being uninstallable there) [18:20] Why on earth does lxqt-policykit trigger autopkgtests for riseup-vpn and update-manager? I seriously doubt either depends on lxqt-policykit directly or indirectly, and similarly doubt that it depends on either one of those. [18:31] migrating python3-distutils/3.11.2-2/amd64 to testing makes python3.10-full/3.10.9-1/amd64 uninstallable [18:31] doko, ^^ something didn't work in version relax? [18:32] or maybe it just needs an hint... [18:42] arraybolt3: update-manger does have an alternate dep on lxqt-policykit - verified using apt-cache show update-manager [18:44] Gah, I didn't think about that, because it needs a polkit agent. And so does Riseup it looks like. Sorry. [18:53] I'm keen not to run unnecessary tests so keep your eyes peeled! [19:45] LocutusOfBorg: dkms/i386 badtested. going to look at sfepy [19:45] -queuebot:#ubuntu-release- Unapproved: dovecot (jammy-proposed/main) [1:2.3.16+dfsg1-3ubuntu2.1 => 1:2.3.16+dfsg1-3ubuntu2.2] (ubuntu-server) [19:54] -queuebot:#ubuntu-release- Unapproved: accepted dnsmasq [source] (jammy-proposed) [2.86-1.1ubuntu0.2] [20:15] -queuebot:#ubuntu-release- Unapproved: accepted tcpdump [source] (kinetic-proposed) [4.99.1-4ubuntu0.1] [20:16] -queuebot:#ubuntu-release- Unapproved: accepted tcpdump [source] (jammy-proposed) [4.99.1-3ubuntu0.1] [20:16] -queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.32.21 => 0.96.24.32.22] (desktop-core, ubuntu-server) [20:17] -queuebot:#ubuntu-release- Unapproved: accepted tcpdump [source] (focal-proposed) [4.9.3-4ubuntu0.2] [20:18] -queuebot:#ubuntu-release- Unapproved: accepted tcpdump [source] (bionic-proposed) [4.9.3-0ubuntu0.18.04.3] [20:19] -queuebot:#ubuntu-release- Unapproved: rejected rabbitmq-server [source] (focal-proposed) [3.8.2-0ubuntu1.4] [20:24] bdmurray: aha I think I just figured it out, I've been running amqp-filter in a loop for the huge queues, but due to britney funnypants aggregation of triggers there are a number of tests in the non-huge queues; so I'll iterate over those now too [20:25] bdmurray: in any event, this doesn't *directly* account for rabbit's reported number of queued tests going up and down, though it may be a side effect where rabbit just doesn't do a good job of consistently reporting its queue while things are in flux [20:44] -queuebot:#ubuntu-release- New binary: mosdepth [amd64] (lunar-proposed/universe) [0.3.3+ds-2] (no packageset) [20:50] bdmurray, ginggs: looks like we've finally converged (more or less) - 842 scipy-triggered tests remain [20:54] -queuebot:#ubuntu-release- Unapproved: accepted nmap [source] (jammy-proposed) [7.91+dfsg1+really7.80+dfsg1-2ubuntu0.1] [20:54] -queuebot:#ubuntu-release- Unapproved: accepted nmap [source] (focal-proposed) [7.80+dfsg1-2ubuntu0.1] [21:08] -queuebot:#ubuntu-release- New binary: mosdepth [arm64] (lunar-proposed/universe) [0.3.3+ds-2] (no packageset) [21:10] -queuebot:#ubuntu-release- New binary: mosdepth [armhf] (lunar-proposed/universe) [0.3.3+ds-2] (no packageset) [21:10] -queuebot:#ubuntu-release- New binary: mosdepth [ppc64el] (lunar-proposed/universe) [0.3.3+ds-2] (no packageset) [21:26] -queuebot:#ubuntu-release- New binary: mosdepth [riscv64] (lunar-proposed/universe) [0.3.3+ds-2] (no packageset) [22:48] -queuebot:#ubuntu-release- Unapproved: ubuntustudio-default-settings (jammy-proposed/universe) [22.04.26.2 => 22.04.26.3] (ubuntustudio) [22:52] vorlon: because it appears that dkms is always pulled from proposed. as triggers are getting collated, and i cannot get my dkms and kernels to migrate without using dkms from proposed it seems. [22:55] vorlon: 6611 number of enqued tests on i386 looks wrong, as surely we don't have that many source packages on i386, nor even that many arch:all packages usable on i386? [22:56] we have roughly 40,000 source packages, and the queues in total are for roughly a quarter of them. are we still doing migration reference tests? [23:03] vorlon, sfepy ping? its not built on i386 at all... [23:04] xnox: you know there's a glibc that still has tests in the queue, right [23:04] and how useful is that? [23:05] it's not like any of them will catch a glibc bug [23:06] not interested in you bikeshedding the release policy around testing in response to a service outage [23:06] the glibc testing DOES catch regressions [23:06] you can consider them glibc bugs or not, but they show real package breakage [23:11] xnox: is there a bug ref for the current round of dkms breakage in -proposed? "breaks kernel testing" is sufficient reason to remove it from -proposed rather than letting in cook there, but a bug pointer is useful for documentation [23:24] xnox: I see no open bugs in LP or Debian for breakage of dkms 3.0.10-6. update_excuses shows most tests 'in progress' but passing on armhf [23:43] doing some queue analysis, the current greatest offenders are in fact: numpy, python3-stdlib-extensions, python3.11, nodejs, link-grammar (some of these are spurious because of britney's weird and buggy trigger aggregation) [23:45] pystemd ok this package name is terrible [23:51] bdmurray, ginggs: there's no more obvious low-hanging fruit for stale test triggers. it would be easier to do this analysis if britney consistently set sane triggers in the first place instead of what it does now [23:53] vorlon: ack, thanks for looking [23:53] The autopkgtest cloud workers seem to be in better shape so we should be back to the state we were at before the infrastructure failure