[00:06] bs=4M vs. leaving it off entirely has dramatic effects for me. It speeds up flashing by at least twice, probably multiple times. [00:40] i also discovered that the hdmi0 port of my rpi argon case is faulty :( [01:47] -queuebot:#ubuntu-release- New: accepted rust-derive-more [riscv64] (kinetic-proposed) [0.99.11-1] [02:03] -queuebot:#ubuntu-release- New binary: rust-crdts [amd64] (kinetic-proposed/universe) [7.2.0+dfsg-1] (no packageset) [02:03] -queuebot:#ubuntu-release- New binary: rust-crdts [ppc64el] (kinetic-proposed/universe) [7.2.0+dfsg-1] (no packageset) [02:03] -queuebot:#ubuntu-release- New binary: rust-crdts [armhf] (kinetic-proposed/universe) [7.2.0+dfsg-1] (no packageset) [02:03] -queuebot:#ubuntu-release- New binary: rust-crdts [s390x] (kinetic-proposed/universe) [7.2.0+dfsg-1] (no packageset) [02:04] -queuebot:#ubuntu-release- New binary: rust-crdts [arm64] (kinetic-proposed/universe) [7.2.0+dfsg-1] (no packageset) [02:10] hellsworth: rpi-imager is really nice too and does an extra verification step at the end [02:11] plars: the snap? [02:12] -queuebot:#ubuntu-release- New: accepted rust-crdts [arm64] (kinetic-proposed) [7.2.0+dfsg-1] [02:12] -queuebot:#ubuntu-release- New: accepted rust-crdts [s390x] (kinetic-proposed) [7.2.0+dfsg-1] [02:12] -queuebot:#ubuntu-release- New: accepted rust-crdts [ppc64el] (kinetic-proposed) [7.2.0+dfsg-1] [02:13] -queuebot:#ubuntu-release- New: accepted rust-crdts [amd64] (kinetic-proposed) [7.2.0+dfsg-1] [02:13] -queuebot:#ubuntu-release- New: accepted rust-crdts [armhf] (kinetic-proposed) [7.2.0+dfsg-1] [02:17] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity riscv64 [Kinetic Final] has been updated (20221019.1) [02:17] nice [02:17] bdmurray: yes, works great and also allows using "custom" (downloaded) images [02:22] should only be a couple more rounds of britney before all packages are in release that need to be [03:56] plars: good point [05:22] ETA 2h for Ubuntu and Kubuntu image respins [06:20] marking the to-be-respun images as disabled now as the respins will be starting soon [06:21] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Kinetic Final] has been disabled [06:21] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64+raspi [Kinetic Final] has been disabled [06:21] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Kinetic Final] has been disabled [06:31] hey there. I'm just starting my day, is that the respin decided yesterday evening UTC which has just been taking a while to be ready or was there another issue found? [06:31] o/ [06:31] We're still waiting for the l-r-m packages to fully migrate [06:32] It should be any minute now [06:32] Problem was that the rebuild of linux-restricted-modules and its migration takes AGES [06:32] So even though the work was started around yesterday afternoon, only now we get *something* [06:38] part of it was affected by a 4-hour launchpad-induced delay of a 5-minute oracle-signed package build that nobody caught earlier [06:43] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64+raspi [Kinetic Final] has been updated (20221018.1) [06:45] huh, a respin of raspi desktop? [06:45] What was that about [06:45] hm, no, not respin [06:46] Ah, it was Steve just changing the status, ok [06:46] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Kinetic Final] has been marked as ready [06:48] yeah, per our discussion about me being confused and thinking ubiquity being seeded on it mattered for an nvidia-only respin [06:48] anyway, 'night [06:55] Goodnight vorlon and thanks for all your work! ;) [06:55] Okay, rmadison seems to see 5.19.0-21.21+1 now [07:02] Ok, I see the packages on the cdimage mirror [07:02] Kicking builds and going for coffee [07:25] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Kinetic Final] has been updated (20221020) [07:25] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Kinetic Final] has been updated (20221020) [07:25] \o/ [07:27] sil2100: apw: fwiw the "new" 515 driver did fix the issue on my setup :) [07:27] schopin, great news. [07:27] schopin: excellent [07:27] sil2100: I'm guessing you'd like me to test the image now? :P [07:27] schopin: can you give the new images a spin anyway? [07:28] I'm also downloading for a quick check on my Nvidia machine [07:28] In the meantime prepublishing (...since why not) [07:36] Argh, I think Graham and Brian didn't commit the publish set commands from the Beta [07:37] I'll fix that in master in a moment [07:38] sil2100: most ISOs have the right volume labels, that is, right architecture and release. [07:38] most = all the ones I tested [07:38] \o/ [07:38] utkarsh2102: thanks! [07:39] Let's mark that item as done then [07:39] awesome! [07:39] something else that needs help? [07:40] I think the only part that's doable now is helping with the isotesting of Ubuntu and Kubuntu, since we're really tight on time [07:41] fair, will do [07:42] seb128: ^ can your team help with testing the desktop images as well? [07:42] I'm dding the image to my usb drive for a spin on my Nvidia laptop [07:42] sil2100, yes, but not on nvidia since I don't have hardware [07:47] Any tests would be great! Since we want to make sure there's no regressions introduced by the respin [07:47] right [07:47] btw. images prepublished, mirrors synced, source images building [08:08] Ok, the image seems okayish, saw some minor things that I didn't see before but I think those were just 'unlucky' [08:12] schopin: any luck so far..? [08:13] Ah, I see your test results [08:13] yay [08:14] sil2100: I encountered a variety of gnome-related apport crashes right after filing my report though :-/ [08:15] seb128: ^ [08:15] schopin: did you check what generated those errors? [08:15] do you have bug or e.uc references? [08:19] I'm looking into it rn :) [08:33] schopin shared the error references, there is a shell crash which is unfortunate, it didn't seem retraced or matched to a known report yet [08:34] the apport crashes and probably the g-t one seem side effect of having the session going away, probably similar to bug #1842439 [08:34] -ubottu:#ubuntu-release- Bug 1842439 in apport (Ubuntu Focal) "apport-gtk crashed with SIGSEGV in _gtk_settings_get_screen(settings=0x0) from gtk_css_value_icon_theme_compute() from gtk_css_static_style_compute_value()" [High, Triaged] https://launchpad.net/bugs/1842439 [08:34] or said differently not a new problem nor an issue for the release [08:35] wrt the shell crash it might be because I switch to tty3 and then went to tty1 instead of 2. In any case, not something your typical user does. [08:35] and I didn't notice the crash, only the apport prompt afterwards. [08:38] schopin, are you using an Xorg session? [08:38] on wayland a shell crash should lead to the session closing and go back to gdm [08:38] I was on a fresh install, so on whatever the default is for Kinetic+nvidia. [08:38] also switching to tty shouldn't crash the shell, but that doesn't seem a release blocker. if you find out trigger steps please let us know [08:39] on nvidia you should get xorg yes [08:44] -queuebot:#ubuntu-release- Builds: Ubuntu Core amd64 edge [Kinetic Final] (20221020) has been added [08:48] philroche: hey hey! How are things from the CPC side? [08:49] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Kinetic Final] has been marked as ready [08:50] sil2100: \o I have not been fully tracking this time round. simpoir is release shepherd on CPC side. I believe we are currently discussing waiting for a new kernel before release cloud image build [08:50] ACK [08:56] Okay, putting on the block-all in place [09:23] -queuebot:#ubuntu-release- Builds: Ubuntu Unity Desktop amd64 [Kinetic Final] has been marked as ready [09:47] woot! [09:48] What's in the way of Ubuntu Desktop? The missing mandatory tests? I can help with those. === arraybolt3_ is now known as arraybolt3 [09:56] arraybolt3: yes please! [09:57] I think seb128 has some of the desktop peeps working on those as well, but the more the better [09:57] :) ISO just finished zsyncing. [09:57] Wow, I see Kubuntu is going lightning fast [10:02] sil2100: bdmurray: https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1991725 [10:02] -ubottu:#ubuntu-release- Launchpad bug 1991725 in dkms (Ubuntu) "fails to sign kernel modules" [Undecided, Confirmed] [10:02] looking into that [10:15] :-( [10:17] xnox: Shoot. I think I just verified that bug. [10:18] Secure Boot installation on a system with Broadcom WiFi. Choosing to install the proprietary drivers and configure Secure Boot did result in MOK showing up, but the WiFi isn't turning on. [10:18] s/MOK/mokutil/ [10:29] I see it was already verified now, but I do see it's a problem on the final ISO. At any rate, I've now thrown in my "This affects me too" and mentioned I could manually sign my driver and get it to work. [10:33] hmm [10:34] i don't like the proposed patch, will try to review it and upload something. [10:35] Sucks that we missed this, as it was reported 15 days ago [10:35] I wouldn't want to rebuild the world right now [10:35] eh [10:36] I submitted a failed test result as a result of the driver problem, on the lvm+encryption testcase. Is that correct, or should I change that to a passed test with a non-critical bug? [10:38] The firefox snap in Ubuntu software has the generic icon. Is that known? Where should that be reported? [10:41] xnox, arraybolt3: does this mean that all dkms drivers right now are busted on kinetic? What's the severity? [10:42] sil2100: Well it certainly borks my Broadcom driver, that's for sure. Probably messes with NVIDIA. [10:42] The bug doesn't say much about what is broken and why. The debdiff implies that the paths changed for the keys? [10:43] sil2100: Basically, install Ubuntu on any system with Secure Boot and proprietary drivers. Your drivers won't work when you boot into the newly installed system. That's my experience so far. [10:43] That's *what's* broken for me, from an end user perspective at least. [10:44] Nvidia worked fine for me and schopin, but I don't think those are related [10:44] sil2100: With Secure Boot? [10:45] Ohhh, because NVIDIA isn't DKMS. My bad. [10:49] -queuebot:#ubuntu-release- Builds: Ubuntu WSL [Kinetic Final] has been updated (3288827692) [10:50] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Kinetic Final] has been marked as ready [10:52] apw: I'd really not want to respin, but at least now this feels respin-worthy? ^ [10:52] Literally HOURS before release. Frustrating. [10:52] Did we ever have a release with broken dkms? Assuming it's just broken *period* [10:52] The fix from the linked PR looks so uh, weird [10:53] As if the exit codes changed or it was broken always? [10:53] Guess broken since 3.0.6? [10:54] is the issue that it doesn't sign them or that it doesn't enrol the key in mok? [10:54] The key is enrolled in MOK, the drivers just aren't getting signed. [10:55] I was able to use the enrolled key to manually sign the driver and get it to work. [10:56] sil2100, would a "fixed" dkms in updates make this tollerable? do we have any dkms package on media? [10:56] Also see here https://github.com/dell/dkms/commit/3ca52f8769bdf7ebdc83735355fff7c5c0664152 [10:56] -ubottu:#ubuntu-release- Commit 3ca52f8 in dell/dkms "Fix signing on ubuntu & debian (#244)" [10:56] apw: It would not. WiFi driver installation done by the ISO would still fail silently. [10:56] After all, there has to be some way to download the fixed package for it to work. [10:56] arraybolt3, so we have dkms packages on the media; damn. [10:57] I mean, if the fixed DKMS SRU automatically rebuilt and signed the driver, then that might work (connect to the Internet some other way and then sudo apt update && sudo apt upgrade), but it's a regression still. [10:57] Actually, hmm, how does this work, I don't see the broadcom driver in the pool [10:58] sil2100: It's in there, I just looked at the .deb package a few minutes ago. [10:58] Under restricted/b. [10:58] http://cdimage.ubuntu.com/daily-live/20221020/kinetic-desktop-amd64.list don't see it here weirdly, or am I just blind? [10:58] Aaa [10:58] Ok, I see it [10:58] :) Was just about to paste the line with it [10:58] I was just blind ;) [10:59] On the bright side Firefox isn't broken with an OEM install, so that's good. [11:04] Oh dear, it gets worse. Looks like an OEM install fails to save the Secure Boot keys that it enrolls into MOK :-/ [11:04] Bug report incoming. [11:06] I think we all need to get better at scanning LP for bugs, you know, doing bug triaging - and also in testing our images more frequently! Guess the problem was the new dkms was I guess accepted after the beta? [11:06] xnox, apw: ^ [11:06] sounds like another gap in the testplans, one autocome should be to add a mandatory dkms testcase [11:06] (what arraybolt3 says) [11:06] Shoot, I can't even file a bug against oem-config. [11:07] seb128: +1 on that [11:07] the only secureboot test we have atm is the nvidia one [11:07] which of course doesn't cover dkms with the current nvidia drivers... [11:07] shim-signed isn't recognized as an official Ubuntu package?! We need to also work on ubuntu-bug. [11:08] * arraybolt3 gives up and just files the bug via the web UI, I can provide any log files needed after the fact [11:09] sil2100, dkms came to us mid september, that is before the beta right? [11:10] yes [11:11] sil2100: hey, is anybody else testing kylin? [11:14] https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1993646 [11:14] -ubottu:#ubuntu-release- Launchpad bug 1993646 in shim-signed (Ubuntu) "MOK-enrolled Secure Boot keys are not saved on the installed system when doing an OEM installation" [Undecided, New] [11:15] weird, mounting some FS and chroot’ing in them segfaults Chrome. [11:16] Wow, today is just brimming with weird bugs! /o\ [11:16] I can’t find logs but at least the good thing is that Chrome isn’t a .deb [11:16] doesn’t happen w Firefox [11:17] doesn’t happen w Chrome on Debian so now the odd bits come into play [11:17] arraybolt3: hah, totally! [11:17] utkarsh2102, do you mean chromium as a snap? because chrome should be a deb no? [11:18] arraybolt3, your oem bug there doesn't indicate that it tried to enroll a key? [11:18] apw: Ah, I'll edit that it. It does enroll a key in MOK (I have to go through the mokutil screens), but the files just aren't there on the disk. [11:19] arraybolt3, i assumed it must have, but the report doesn't mention it, so it might leads people in the wrong direction. [11:19] seb128: sorry, chrome’s unofficial deb. I just installed that from Google itself [11:19] utkarsh2102, ah, makes more sense, thanks [11:20] apw: Report updated. Thanks for catching that! [11:20] I'm doing another OEM install, same computer, same everything, but new USB drive with a fresh flash just in case it's my drive's fault (it behaved weirdly earlier). [11:33] utkarsh2102: we don't release kylin for 22.10 :) [11:34] apw: as for the dkms thing, hm, indeed, the sync from debian was in september [11:35] i will prepare dkms upload soon. [11:35] omg, my bad 😭 [11:35] * sil2100 was looking at the ubuntu1 version [11:35] testing the build here, there are lots of regressions [11:35] xnox: adt regressions? Or regressions in actually building dkms packages? [11:36] kubuntu [11:36] I’ll get Kubuntu [11:36] wrt the bug with the Secure Boot keys not being saved, I have successfully reproduced it a second time with a newly flashed ISO. [11:36] Thanks! Sadly, we'll be respinning things [11:37] Going to do a non-OEM install and see if the files are generated again. [11:47] With a non-OEM install, the MOK.der and MOK.priv files exist. Shoot. [12:18] Ok everyone! Status update re: 22.10 - the dkms 3.0.6 version we have in kinetic is basically busted. xnox tried to cherry pick .7 fixes to get it working, but the .7 fixes seem to 'not be enough' actuall, and it's a bit of changes as well [12:19] So he will attempt reverting to 3.0.3 most probably [12:19] :( [12:19] and another respin thereafter? [12:19] That being said, as the only dkms driver we ship on the iso from what I see is the broadcom wifi driver, I'm starting to lean towards release noting this and... leaving it at that [12:20] It's a tough call to make, which is why I want to consult other release team members, but seeing that no one reported this during Beta testing and the only bug we saw was from 5th October about this, I get the feeling that having dkms fixed as a 0-day SRU is *feasible* [12:20] At least to some extent [12:21] sil2100, do we have any clue what % of users might have hardware that require that driver? [12:21] Reverting dkms is a safe option IMO, but it would require a respin of the whole world [12:21] seb128: I'm trying to figure that out. Actually, could you maybe help me out with this? Is this by any chance something we gather with ubuntu-report? [12:22] Or maybe the handy system info sent to Canonical? (Is that waht ubuntu-report is?) [12:22] sil2100, we don't have it as part of the metrics afaik [12:22] didrocks, jibel, ^ right? [12:23] arraybolt3, that's ubuntu-reports yes [12:23] sil2100, would reverting dkms work as it is or does it need change anyway? the newer upload mention fixes for gcc-12, unsure if that would need to be applied to the previous version if we consider reverting? [12:23] we don’t collect packages that are installed or not [12:24] (too intrusive, biased on our default, and if we wanted that, it’s basically popcon :p) [12:24] If it has hardware info it should report if a Broadcom card is installed, no? [12:24] didrocks, I think the question was rather network cards specs and/or loaded dkms drives [12:24] drivers [12:25] Crud, I just did "ubuntu-report show" and it's not showing my Broadcom card, so :( [12:25] checking my local reports they don't have network devices details at least [12:25] yeah, that was not requested IIRC [12:26] ack, thanks for confirming [12:26] sil2100, no luck there for you then [12:26] seb128: oh well, thanks! ;) I'll try to dig some more [12:26] Maybe error reports [12:40] -queuebot:#ubuntu-release- Unapproved: dkms (kinetic-proposed/main) [3.0.6-2ubuntu1 => 3.0.6-2ubuntu2] (i386-whitelist, ubuntu-desktop) [12:42] sil2100, just as a side note on what you said a bit earlier, lack of report doesn't always correlate with impacting a low number of users. Our testing is skewed toward intel hardware and devices that don't required non free drivers because that's what most of us pick. That's the same issue than we have with nvidia where we almost always find the issue in the release week... [12:43] sil2100: seb128: dkms upload that i did test of no key available; key generated and enrolled as part of dkms module installation; and if existing key is enrolled, one can sign with it; and load the module. the full cycle. [12:43] seb128: sure, I agree [12:44] it is upstream cherrypicks + one-liner to unbreak the wrong assumptions they made. [12:44] brrr [12:44] it is in the unapproved queue now. [12:54] -queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (kinetic-proposed) [3.0.6-2ubuntu2] [13:50] scrolling back, little lost on current. is the plan for dkms to be a 0-day or a respin? [14:05] pretty likely a re-spin given there are network card drivers you might need at install time [14:08] jchittum: as dkms is not shipped on cloud images, do you care? =) [14:09] i care more for a timing reason :) [14:09] jchittum: it’s still being decided but I think we’re leaning towards 0-day SRU. [14:09] Hah [14:09] jchittum: do you? [14:12] I'd think this should be a respin. For instance, you're on a laptop with a Broadcom chipset and the only way you can get connected is via WiFi, no wired connection available. You need that driver, and a dkms failure is a bad thing. 0-day SRU isn't going to cut it in that scenario. [14:12] Okay, I think we might just go [14:12] Just GO [14:13] Eickmeyer: we are aware of that [14:14] sil2100: Well, you know I'm a stickler for UX and public perception. :) [14:14] If we 0-day SRU it, we should test to make sure that upgrading the system makes the driver start working immediately. Otherwise... [14:14] (I'll be happy to test, btw) [14:15] arraybolt3: yep, we have a plan! [14:18] Eickmeyer: yeah, so eh, sometimes tough calls need to be made. I discussed it with other release team members, and the number of affected users is (from the overview we have) low, and this is an interim release. We already ship with ZFS+encryption disabled, so our images anyway aren't super crisp, but we can't keep respinning into eternity [14:20] A respin would require a lot of time from both us and the community, as we'd have to respin quite a few images. We just have to make this decision based on the proportion of how much time will be needed per the impact this has on our users [14:21] sil2100: I understand that. However, as stated earlier, I think the estimate of Broadcom chipsets is remarkably low and we're bound to see some severe community backlash from this. The #ubuntu support channel is likely to light-up like a Christmas tree (for lack of a better analogy). I think this will be more time-consuming in the long run, tbh. [14:23] .... [14:24] if they're so widely used, why did no one catch the issue until the last hour [14:24] those that have broadcom chipset will be guided to use Jammy installer media; and upgrade to kinetic [14:24] to get a working system, with internet, either during installer, or post install. [14:24] (same situation as zfs thing) [14:24] xnox: Is that good for the community? Is that good PR? [14:25] (to be fair, one answer is that most of our milestone testing is done in VMs. But anyway, if people consider this an important use case that should've been respun for, the best thing to do is to help put in place automated testing, with VMs using faked-up PCI IDs, so that going forward this is caught automatically) [14:25] also this works correctly with secureboot off [14:25] (actually if the problem is dkms can't sign modules, tests for that don't even need to be image tests) [14:25] vorlon: To answer that, because people aren't testing until they get excited about RC's. It's weird, I know. [14:26] i don't know how many machines have that broadcom chip and actually ahve secureboot, cause that package is for very old broadcom chips (?!) [14:26] The workaround is also just signing the modules manually, right? [14:26] Non-ideal, but at least doable [14:26] https://autopkgtest.ubuntu.com/packages/d/dkms/kinetic/amd64 maybe that shouldn't say 'pass'! [14:26] sil2100: It can be done, true. [14:26] As said, it's all about the cost->merits equation, and to me this here is not looking great [14:27] "sudo dpkg-reconfigure bcmwl-kernel-source", followed by a tricky signing command. [14:27] arraybolt3: Could you add the exact process to the bug report? [14:27] Not sure if that will persist across kernel updates though. [14:27] bdmurray: In just a bit, sure. [14:35] bdmurray: Bug report updated with full workaround instructions. [14:35] Also, I just verified that the workaround survives a reboot. Still not sure how it will behave in the face of a kernel update though. [14:36] 22.10 building going on? [14:37] bittin: Patience, please. [14:37] Eickmeyer: sorry [14:37] was just curious [14:37] (and patience in all the other channels you posted this too 🙂 ) [14:37] sure [15:05] -queuebot:#ubuntu-release- New source: chatty (kinetic-proposed/primary) [0.7.0~rc0-1~build1] [15:07] ^ do we still accept new sources at this point? [15:15] Hey I should be testing that dkms in -proposed, huh? [15:18] Eickmeyer: One thing to keep in mind is that it is not just all systems with broadcom chipsets but broadcom and secure boot. [15:18] bdmurray: Agreed, which would be people dual-booting with Windows, a very wide use-case. [15:21] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Kinetic Final] has been marked as ready [15:21] \o/ [15:21] Please mark all the images as ready! [15:21] o/ [15:21] I am starting the release process, one final look at the isotracker [15:21] Eickmeyer: Only Win11 requires Secure Boot, right? [15:21] arraybolt3: And win 10. [15:21] Thought it would work without it but OK. [15:21] arraybolt3: Win 11 requires TPM 2.0. [15:22] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Kinetic Final] has been marked as ready [15:23] I'm telling you all, this is going to be a support nightmare and a PR blunder for these users. Meeting a deadling !> quality. [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Kinetic Final] has been marked as ready [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Kinetic Final] has been marked as ready [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Kinetic Final] has been marked as ready [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Kinetic Final] has been marked as ready [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Base riscv64 [Kinetic Final] has been marked as ready [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Kinetic Final] has been marked as ready [15:24] *deadline [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Kinetic Final] has been marked as ready [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Kinetic Final] has been marked as ready [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Kinetic Final] has been marked as ready [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity riscv64 [Kinetic Final] has been marked as ready [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Kinetic Final] has been marked as ready [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+licheerv [Kinetic Final] has been marked as ready [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+nezha [Kinetic Final] has been marked as ready [15:24] Eickmeyer: We'll survive. I only have one laptop that uses Broadcom. Also, Google says Secure Boot *can* be disabled on Windows 10. I know that it probably can't on Windows 11, but it might not be that awful. [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+unmatched [Kinetic Final] has been marked as ready [15:24] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+visionfive [Kinetic Final] has been marked as ready [15:24] arraybolt3: You're not who I'm addressing. [15:25] sil2100, what do you mean ? https://ubuntu.com/blog/canonical-releases-ubuntu-22-10-kinetic-kudu ... seems you can go home, someone has released it already :P (i can not really believe that we nw start sabotaging us ourselves during release day) [15:26] ogra: :p [15:26] yeah saw that linked on Phoronix [15:26] yeah, sigh [15:26] The Web team really needs to get on the same page. [15:26] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64+raspi [Kinetic Final] has been marked as ready [15:26] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Kinetic Final] has been marked as ready [15:26] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Kinetic Final] has been marked as ready [15:26] Well, press releases are always timed, and apparently that can't be changed [15:26] this is insane [15:26] Yeah [15:28] Eickmeyer: we'll deal with things as they go, we have options in case people will be really really bothered by this. But we'll see how things will look naturally - sometimes we have to do tough calls, and this was one of it, sadly! [15:29] sil2100: That's reactivism as opposed to proactivism. We, as a community and as developers, need to do better. [15:30] Agreed. That's why we're hopefully going to be fixing the testcases. [15:31] This shouldn't have happened, but it's done now. Lubuntu lived with BTRFS being problematic, we'll live with Broadcom being problematic. On the bright side, for Lubuntu and Studio, all that's necessary is apt update and apt upgrade before installing the drivers. And I'm sure we can streamline the process for the Ubiquity-based flavors with some bash-fu. [15:32] (This is me trying to be encouraging and think of solutions, if I'm just being annoying tell me to shut up and I will.) [15:34] arraybolt3: being encouraging and thinking of solutions is helpful [15:35] Alright! Installing the new DKMS and reinstalling bcmwl-kernel-source resulted in WiFi turning on! [15:35] crazy ! [15:37] given bcmwl-kernel-source isn't on the images, presumably that's good enough [15:38] tumbleweed: bcmwl-kernel-source is on the images. [15:39] tumbleweed: it's on the pool [15:39] aah, restricted, right [15:39] s/on/in/? [15:57] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Kinetic Final] has been marked as ready [16:03] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Kinetic Final] has been marked as ready [16:09] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.48.3 => 2.57.5] (desktop-core, ubuntu-server) [16:10] -queuebot:#ubuntu-release- Unapproved: snapd (kinetic-proposed/main) [2.57.4+22.10ubuntu1 => 2.57.5+22.10] (desktop-core, ubuntu-server) [16:10] -queuebot:#ubuntu-release- Unapproved: snapd (focal-proposed/main) [2.55.5+20.04 => 2.57.5+20.04] (core) [16:11] -queuebot:#ubuntu-release- Unapproved: snapd (jammy-proposed/main) [2.57.4+22.04 => 2.57.5+22.04] (desktop-core, ubuntu-server) [16:11] -queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.55.5+18.04 => 2.57.5+18.04] (desktop-core, ubuntu-server) [16:12] OK, I'm going to go recover now. I've not had any sleep yet in the flurry of testing and debugging yesterday and today. Thanks everyone, and see you soon! [16:12] cheers arraybolt3 ! [16:13] :) [16:15] arraybolt3: As usual, thanks for everything! [16:16] Eickmeyer: Thank you! (I'm not going to bed, just getting some coffee and food and maybe a slice of cake. First releace cycle survival celebration!) [16:17] arraybolt3: You really should sleep, friend! :D [16:21] sil2100: I see you in flavors but you can't see me :) yes to confirm we're good for 22.10 [16:33] Eickmeyer: Eh, $PERSONAL_LIFE has other ideas. That's what dark roast coffee is good for. [16:45] FWIW: collected some distro-info-data dates for L, just need a name now: https://salsa.debian.org/debian/distro-info-data/-/commit/e52bd46647e625f7ccbf4c89000000cefba37c82 [16:45] -ubottu:#ubuntu-release- Commit e52bd46 in debian/distro-info-data "Add dates for Ubuntu L series (NO NAME YET) (LP: #1993667)" [16:46] Okay everyone, images are published, mirrors will be syncing - will take a while though, so uh, it's still not 'officially released' [16:47] This can take 1-2 hours from now [17:01] sil2100: we just marked the ubuntu desktop as ready. i think you maybe already knew that since chatting with seb128 in ubuntu-desktop. still wanted to point it out in case it was needed :) [17:05] \o/ Yeah, I marked it myself already after the message seb128 sent o/ [17:06] cool cool :) [17:08] * fnordahl fires up the torrents [17:23] -queuebot:#ubuntu-release- New source: inky (kinetic-proposed/primary) [1.4.0-0ubuntu1] [17:33] -queuebot:#ubuntu-release- New: accepted inky [source] (kinetic-proposed) [1.4.0-0ubuntu1] [17:36] -queuebot:#ubuntu-release- New: accepted chatty [source] (kinetic-proposed) [0.7.0~rc0-1~build1] [17:39] -queuebot:#ubuntu-release- New binary: inky [amd64] (kinetic-proposed/none) [1.4.0-0ubuntu1] (no packageset) [17:40] -queuebot:#ubuntu-release- New binary: chatty [amd64] (kinetic-proposed/none) [0.7.0~rc0-1~build1] (no packageset) [17:40] -queuebot:#ubuntu-release- New binary: chatty [armhf] (kinetic-proposed/none) [0.7.0~rc0-1~build1] (no packageset) [17:40] -queuebot:#ubuntu-release- New binary: chatty [arm64] (kinetic-proposed/none) [0.7.0~rc0-1~build1] (no packageset) [17:40] -queuebot:#ubuntu-release- New binary: chatty [s390x] (kinetic-proposed/none) [0.7.0~rc0-1~build1] (no packageset) [17:41] -queuebot:#ubuntu-release- New binary: chatty [ppc64el] (kinetic-proposed/none) [0.7.0~rc0-1~build1] (no packageset) [18:05] -queuebot:#ubuntu-release- New: accepted chatty [amd64] (kinetic-proposed) [0.7.0~rc0-1~build1] [18:05] -queuebot:#ubuntu-release- New: accepted chatty [armhf] (kinetic-proposed) [0.7.0~rc0-1~build1] [18:05] -queuebot:#ubuntu-release- New: accepted chatty [s390x] (kinetic-proposed) [0.7.0~rc0-1~build1] [18:05] -queuebot:#ubuntu-release- New: accepted chatty [arm64] (kinetic-proposed) [0.7.0~rc0-1~build1] [18:05] -queuebot:#ubuntu-release- New: accepted inky [amd64] (kinetic-proposed) [1.4.0-0ubuntu1] [18:05] -queuebot:#ubuntu-release- New: accepted chatty [ppc64el] (kinetic-proposed) [0.7.0~rc0-1~build1] [18:13] -queuebot:#ubuntu-release- New binary: chatty [riscv64] (kinetic-proposed/universe) [0.7.0~rc0-1~build1] (no packageset) [18:28] -queuebot:#ubuntu-release- New: accepted chatty [riscv64] (kinetic-proposed) [0.7.0~rc0-1~build1] [19:04] Ubuntu 22.10 is now listed on ubuntu.com [19:29] Yes! [19:29] All done? [19:30] Nice! === sil2100 changed the topic of #ubuntu-release to: Released: 22.10 Kinetic Kudu, 22.04.1 Jammy Jellyfish, 20.04.5 Focal Fossa | Archive: Pre-Release Freeze | Highlight ubuntu-archive for archive admin help | Kinetic Release Coordination | We accept payment in cash, cheque or whiskey | melius malum quod cognoscis | infinity, you will be missed [19:30] \o/ === sil2100 changed the topic of #ubuntu-release to: Released: 22.10 Kinetic Kudu, 22.04.1 Jammy Jellyfish, 20.04.5 Focal Fossa | Archive: Post-Release Freeze | Highlight ubuntu-archive for archive admin help | Kinetic Release Coordination | We accept payment in cash, cheque or whiskey | melius malum quod cognoscis | infinity, you will be missed [19:30] ...it was a tough release [19:30] Thank you everyone for all your hard work! [19:30] thanks for doing the hard wark :) [19:36] -queuebot:#ubuntu-release- Builds: 27 entries have been added, updated or disabled [19:42] \o/   congrats ! [19:42] Hey where would I suggest a name for the new 23.04 release? Me and my best friend are thinking "Limpid Llama". Limpid meaning essentially "clear, unclouded, easily understandable". Like we want every release of Ubuntu to be. [19:48] arraybolt3: Mark decides the name and I've never heard of him taking suggestions on it in any meaningful way :) [19:49] besides 'limpid limpet' is right there! [19:49] cjwatson: Ah well. His Wiki page said "we'll consider them" or something like that, but oh well. [19:49] He picks good names anyway. [19:50] well, his wiki page does link to a list you can edit [19:50] but I have no idea whether he actually looks at those. in practice we wait a bit and maybe prod him a few times and eventually a name falls out [19:50] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (kinetic-proposed/main) [2.06-2ubuntu12 => 2.06-2ubuntu13] (core, i386-whitelist) [19:52] sometimes the suggestions function as anti-suggestions. It varies! [19:53] -queuebot:#ubuntu-release- Unapproved: grub2-signed (kinetic-proposed/main) [1.185 => 1.186] (core) [19:53] sometimes people make terrible suggestions as jokes and then he threatens to follow them [19:53] though to be fair I don't think I've heard of that actually happening since breezy [19:53] (Scott suggested "Bendy Badger" as a joke and for a while it was looking like that might actually be the name) [19:55] -queuebot:#ubuntu-release- Unapproved: grub2-signed (kinetic-proposed/main) [1.185 => 1.186] (core) [19:59] -queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (kinetic-proposed) [1.186] [20:14] Wasn't "jackalope" meant as a joke? [20:20] I don't remember any more, 2008 was a long time ago [20:20] -queuebot:#ubuntu-release- Unapproved: accepted mysql-8.0 [source] (focal-proposed) [8.0.30-0ubuntu0.20.04.3] [20:25] 2008 was right when I started playing around with it while trying to come up with a cheap videoconferencing solution for my boss. [20:33] as long as the adjective is shortish, and unlikely for me to misspell in changelogs, I will be happy withy whatever LL happens to be ;) [20:33] linear lickitung [20:33] (As in, wait until you say the word to publish release notes and update download links? :) ) [20:34] Simon Quigley: Bridge is being slow, he said that 4 hours ago. Release is out. [20:34] Niceee. Thanks. [20:38] https://wiki.ubuntu.com/DevelopmentCodeNames or am I old? :P [20:39] lol [20:40] Simon Quigley: Bridge is in snail mode, just FYI. You're seeing something I wrote minutes ago. [20:40] sarnold: Heh. We wrote that almost 15 minutes ago I'd reckon. [20:41] Okay, I think I'll give it a few hours. :P [20:41] arraybolt3: oh I didn't realize tsimonq2 was stuck on the slow side of the bridge, too :( a dude in #rhel was an *hour* behind things [20:41] Yeah, all of Matrix has gone into race to the starting line apparently mode. [20:42] that's the nicest description of where they're racing to I've read in a while :) [21:41] hello ubuntu-archive, Debian has removed ppc64el from the list of supported architectures for luajit2. could you please make sure this change is also reflected in Ubuntu? the package is currently blocked on -proposed because of that. thanks [21:42] uh I did a whole bunch of luajit-related removals on ppc64el weeks ago [21:43] so what grew back or what did I miss? [21:43] the package has been there for 36 days, so I think you may have missed it [21:44] sergiodj: also no it's not currently blocked in -proposed because of that it's blocked in -proposed because we've released and the kinetic release pocket is frozen, so I can't actually fix this for you today :) [21:45] you have to wait until licentious lizard is open [21:45] sure, I understand that there's the freeze going on, but the lack of a ppc64el binary is listed as one of the reasons for the blockage [21:46] I'm not expecting the package to migrate today or anything like that, btw. [21:46] yes - but it is simply impossible for the archive team to take any action here today [21:46] so the above ping is likely going to get lost [21:46] no problem. as I said earlier in the week, I understand that you may not be able to act right away [21:47] I will also write about the package in my email report [21:48] (why not bug?) [21:48] I can do that too, I suppose [21:49] I usually don't associate "requests to ubuntu-archive" with "bug against the package". not sure why [21:50] anyway, let me file it [21:51] i'm more curious for me, I like learning :) but it's nice and durable, anyway [21:51] sergiodj: you can subscribe ubuntu-archive to the bug [21:52] jbicha: yep [21:53] btw, https://changelogs.ubuntu.com/meta-release is not yet updated; someone in #ubuntu wants to upgrade immediately and is surprised it's not available yet ;) [21:54] is that on the todo list? [21:56] it is in the release checklist yes and assigned to bdmurray [21:57] sarnold: are you sure its not up to date? [21:57] hah looks like bdmurray beat me by seconds :) [21:57] in fact it's in progress [21:57] ;-) [21:57] 21:52:38 vs 21:53:59 [21:57] an entire minute! :D [21:57] s/in progress/done/ [22:03] sarnold: you can see our todo list here https://git.launchpad.net/~ubuntu-release/ubuntu-release-tools/+git/templates/tree/jira-milestones/devel-release/final-release.yaml [22:08] sarnold: Also people wanting to upgrade will need to set Prompt=normal vs Prompt=lts [23:13] bdmurray: ooo, nice, thanks