[07:21] -queuebot:#ubuntu-release- Unapproved: accepted xubuntu-default-settings [source] (hirsute-proposed) [21.04.2] [07:28] -queuebot:#ubuntu-release- Unapproved: base-files (hirsute-proposed/main) [11ubuntu18 => 11ubuntu19] (core, i386-whitelist) [07:38] -queuebot:#ubuntu-release- Unapproved: ddtp-translations (hirsute-proposed/universe) [20201019.1 => 20210416.1] (no packageset) [07:39] -queuebot:#ubuntu-release- Unapproved: accepted ddtp-translations [source] (hirsute-proposed) [20210416.1] [07:44] -queuebot:#ubuntu-release- Unapproved: mosquitto (hirsute-proposed/universe) [2.0.10-1 => 2.0.10-2~build1] (no packageset) [07:44] -queuebot:#ubuntu-release- Unapproved: accepted mosquitto [source] (hirsute-proposed) [2.0.10-2~build1] [08:02] I know we ignored the apport test failures for some packages. are we going to do that for the remaining ones as well? [08:03] Laney: base-files for the release in the queue, if you have a moment! [08:04] tjaalton, Laney: xwayland needs a bug subscriber, to promote it ... xorg-server had desktop [08:04] -queuebot:#ubuntu-release- Unapproved: rejected ddtp-translations [source] (groovy-proposed) [20210416.1] [08:07] -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (hirsute-proposed) [11ubuntu19] [08:08] sil2100: done [08:08] doko: yeah [08:09] \o/ [08:20] -queuebot:#ubuntu-release- Unapproved: dogtag-pki (hirsute-proposed/universe) [10.10.2-1 => 10.10.2-3] (no packageset) (sync) [08:21] -queuebot:#ubuntu-release- Unapproved: accepted dogtag-pki [sync] (hirsute-proposed) [10.10.2-3] === Laney changed the topic of #ubuntu-release to: Released: Archive: Final Freeze | 21.04 release prep: https://discourse.ubuntu.com/t/hirsute-hippo-21-04-release-status-tracking/21700/2 | Highlight ubuntu-archive for archive admin help | Hirsute Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis | infinity, you will be missed [08:34] juliank, https://autopkgtest.ubuntu.com/running#pkg-llvm-toolchain-12 looks like bogus running state [08:35] doko: looking [08:37] clang: error: unable to execute command: Segmentation fault (core dumped) [08:37] clang: error: linker command failed due to signal (use -v to see invocation) [08:37] autopkgtest [08:32:55]: ERROR: testbed failure: testbed auxverb failed with exit code 254 [08:37] doko: ^ seeing crashes a lot [08:38] doko: it just retries all the time [08:39] doko: you can see it just started again, "running for 0h 2m 10s" whereas it has been running for 50 minutes when you asked [08:39] but it's an outdated trigger [08:40] doko: we're talking about the dpkg/1.20.9ubuntu1 trigger, no? [08:40] that was the one at the top when you asked [08:40] and that's the dpkg version in proposed [08:41] ahh, ok [08:41] Also I'm not sure we cleanup triggers if they become obsolete [08:41] Anyway, I think all llvm-toolchain-12 runs are failures [08:41] anyway, it's not important now [08:41] They just retry all the time, wasting resources [08:42] because autopkgtest thinks they're temporary testbed failures because compiler crashes usually ar [08:44] juliank: you can add a string to one of thoes lists in worker/worker [08:44] I think this run is obsolete: ['llvm-toolchain-12/1:12.0.0-1ubuntu1'] [08:44] do that, and then HUP them and eventually those things will fail out properly [08:46] Laney: doing that [08:48] hmm, ok. never saw these because they always failed on !amd64 [08:49] They should now fail once the worker restarted === pieq_ is now known as pieq [08:56] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-libinput (hirsute-proposed/main) [0.30.0-1build1 => 0.30.0-1ubuntu1] (desktop-core) [08:59] ^ would be nice to get that one in if possible, it's not an installer issue but it's an xorg crash fix, which means session closing and potential data loss. It has several reports on launchpad and errrors [09:32] would be great if we can get the synced gwenview in for ISO. has a fix for exif metadata being lost for users, so I think quite important to have that [09:38] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987063 [09:38] Debian bug 987063 in gwenview "gwenview: looses image metadata on jpg rotation" [Important, Open] [09:46] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Hirsute Final] (20210419) has been added [09:46] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Hirsute Final] (20210419) has been added [09:46] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+unleashed [Hirsute Final] (20210419) has been added [09:46] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+unmatched [Hirsute Final] (20210419) has been added [09:59] hello is publisher dead? [09:59] We'll see about those, but this time after Final Freeze we try to be more disciplined [10:00] I uploaded a mosquitto but its still not in proposed pocket [10:00] Like, we don't want to accept non-blocker fixes as per final freeze [10:02] -queuebot:#ubuntu-release- Unapproved: wine-development (hirsute-proposed/universe) [5.5-5ubuntu1 => 5.6-2] (i386-whitelist) (sync) [10:03] yay, It worked "WARNING: Saw clang: error: unable to execute command: Segmentation fault (core dumped) in log, which is a sign of a real (not tmp) failure - seen 3 so far" [10:03] -queuebot:#ubuntu-release- Unapproved: accepted wine-development [sync] (hirsute-proposed) [5.6-2] [10:05] did somebody start thousands of tests again? :D [10:07] eek, new dpkg is not in [10:07] hirsute+1's apt requires dpkg >> 1.20.8, so I like need to install it from proposed [10:10] -queuebot:#ubuntu-release- Unapproved: python-apt (hirsute-proposed/main) [2.1.7ubuntu1 => 2.1.7ubuntu2] (core, i386-whitelist) [10:11] sil2100: ^ possibly too late, but here's a python-apt with updated mirror list [10:11] Seems I gotta do 2.2.0 as an SRU [10:12] 2.2.0 is basically the same, just stable release instead of pre-release versioning. Though it might have some build-dep annotations, but it's waiting for Debian release team [10:14] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Hirsute Final] (20210419) has been added [10:14] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Hirsute Final] (20210419) has been added [10:14] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Hirsute Final] (20210419) has been added [10:14] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Hirsute Final] (20210419) has been added [10:15] We need the ability to flag packages in -updates for unattended-upgrades, really [10:19] juliank, ? [10:19] juliank, flag to install or not to install? [10:20] rbalint: e.g. the apt upgrade we have in updates it would have made sense to apply automatically; such that people don't get ubuntu-driver crashes when they plug in an nvidia card on a focal system due to the libc thingy [10:20] rbalint: Or the python-apt update above updates the mirror list [10:21] rbalint: So a flag like "Unattended-Upgrade: yes" to roll out critical updates without having to copy them over to security might make sense [10:23] juliank, i think that would surprise plenty of admins [10:23] possibly [10:23] non-security updates landing in security might too, though [10:23] juliank, the glibc triggering apt error part was a pressing issue only because ubuquity does not upgrade itself afaik [10:23] juliank: so a good question actually - how are those mirror lists in python-apt used and how important it is to have them super up-to-date? [10:24] sil2100: they are used for mirror selection in software-properties [10:24] juliank, you can argue the the crash is a local DOS :-) [10:25] juliank, i don't think that mirror selection is that critical to warrant an install through u-u [10:25] rbalint: It's still an issue because the nvidia drivers still fail to install for systems installed with 20.04.1 media _now_ [10:26] juliank, with all -updates installed? [10:26] rbalint: No, because people don't install updates themselves [10:26] juliank, their problem [10:26] rbalint: So they add an Nvidia card, click install driver, and it fails [10:27] rbalint: Re mirror list, it should really be a file updated automatically as part of apt update [10:27] and not in a package [10:28] which is in https://bugs.launchpad.net/launchpad/+bug/1875910 [10:28] Launchpad bug 1875910 in python-apt (Ubuntu) "Command to update mirror list" [High, Triaged] [10:30] juliank, i agree that mirror list should be split from python-apt, but imo it is ok to ship this split in -updates only without asking u-u to install it [10:30] I wonder if software-properties will break when we SRU a distro-info-data with hirsute+1 in it, I've heard rumors that debian bullseye users got trixie-updates when enabling updates. [10:30] I guess we'll see! [10:37] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (groovy-proposed) [2:17.1.0-0ubuntu1] [10:52] xnox: https://code.launchpad.net/~juliank/ubiquity/+git/ubiquity/+merge/401370 [10:52] xnox, sil2100: LP: #1925010 [10:52] Launchpad bug 1925010 in shim (Ubuntu) "shim-signed does not boot on MBA 5,2" [High, New] https://launchpad.net/bugs/1925010 [10:52] xnox: Validated that it skips the install medium ESP, but need to check it doesn't skip ESPs on the real disk [10:53] xnox: Ah no, it seems I already checked :D [10:53] /dev/sda2 which is 537 MB is marked EFI, and /dev/sdb2 which is 5MB is not [10:55] juliank: awesomes [10:57] juliank: https://code.launchpad.net/~juliank/ubiquity/+git/ubiquity/+merge/401370 looks good, but you need release team approval. [10:57] sil2100: the shim-signed bug sounds scary. [10:57] sil2100, Laney One of you want to approve that ubiquity change^ [10:58] s/change/merge proposal/ [10:59] -queuebot:#ubuntu-release- Unapproved: ovn (focal-proposed/main) [20.03.1-0ubuntu1.2 => 20.03.2-0ubuntu0.20.04.1] (no packageset) [10:59] -queuebot:#ubuntu-release- Unapproved: ovn (groovy-proposed/main) [20.06.2-0ubuntu1.2 => 20.06.3-0ubuntu0.20.10.1] (no packageset) [11:00] Commit message should probably say 50 MiB [11:03] xnox: upload it, will accept from the queue [11:06] Laney: I guess you mean me? [11:07] juliank: you can if you have merging powers [11:07] -queuebot:#ubuntu-release- Unapproved: ubiquity (hirsute-proposed/main) [21.04.17 => 21.04.18] (desktop-core) [11:08] Laney: ^ there it is, and merged [11:08] ty [11:08] juliank: can you add it to the release discourse too please? link in topic [11:10] Laney: Under Bugs which are fixed or Bugs to watch? [11:11] Notably it's just a workaround, not a complete bug fix, so haven't closed the issue in the changelog [11:11] well we need to check it is fixed, I dunno either the first or the third section [11:11] no idea what that third one is to be honest, we haven't used it before [11:14] -queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (hirsute-proposed) [2.1.7ubuntu2] [11:14] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (hirsute-proposed) [21.04.18] [11:14] cjwatson: there is some sort of publisher outage at the minute, right? [11:15] I also want to point out that ubiquity crashed for me when I go back after the partition screen [11:15] But I need to recheck [11:15] Laney, sil2100, others, any chance to get xserver-xorg-input-libinput in? it's a trivial change for an xserver sigabrt, I would prefer to have in the image that post release if possible, session closing can mean loosing work and no everyone is online to install updates [11:17] Oh dear bugs [11:26] looks likeit, no sources published fot at least 2h [11:27] seb128: I guess but looks like it could have been done sooner, not super happy about release week fixes [11:27] seb128: how frequent is this crash? Since we *really* try to minimize things we land no matter how trivial the changeset is to release-critical or installer facing ones [11:27] and I don't believe 'trivial' at this point :p [11:27] oh [11:27] heh [11:27] if not too late, could we get this fix uploaded please? https://code.launchpad.net/~saivinob/usb-creator/usb-creator/+merge/401344 [11:28] gwenview in the queue also fixexs a data loss issue [11:28] -queuebot:#ubuntu-release- Unapproved: alsa-ucm-conf (hirsute-proposed/main) [1.2.4-2ubuntu1 => 1.2.4-2ubuntu1.1] (core) [11:29] sil2100, 7 launchpad duplicates, which is probably the highest I've seen on desktop this cycle, the error tracker has 288 reports, it's low enough but unstable cycles don't get low number of users [11:30] -queuebot:#ubuntu-release- Unapproved: rejected gwenview [sync] (hirsute-proposed) [4:20.12.3-2] [11:30] Laney, feel free to reject, it's not my upload, I've just been doing some launchpad triaging to spot release issues and it seemed like a ratio complexity of the change/benefit worth trying to push for, and yes I would have liked to see that fixed before [11:30] -queuebot:#ubuntu-release- Unapproved: rejected libubootenv [sync] (hirsute-proposed) [0.3-3] [11:31] -queuebot:#ubuntu-release- Unapproved: accepted octavia [source] (groovy-proposed) [7.1.1-0ubuntu1] [11:31] sil2100, Laney, anyway, I was just trying to help, I'm too tired at this point to argue more so I stop there and let it up to you, I will move back to other things :) [11:32] sorry for bothering [11:35] -queuebot:#ubuntu-release- Unapproved: alsa-ucm-conf (focal-proposed/main) [1.2.2-1ubuntu0.6 => 1.2.2-1ubuntu0.7] (no packageset) [11:35] seb128: it's ok, thanks for raising, it's mostly that we would like to get a more stable release week than we've had in recent cycles where we've had very bumpy ones with late nights / emergency respins / post release point releases required [11:35] sometimes with release week introduced regressions [11:36] yes, I understand and share the concerns [11:36] so moving a bit more conservative on that stuff, hopefully a side effect is that we manage to push people to test in earlier weeks (maybe we need to get more organised on that for future cycles) [11:37] does whoever rejected gwenview want that queued up with SRU etc versioning instead? [11:37] but lining up SRUs at this point is fine and expected [11:37] RikMills: see the reject message which you can see in the queue (but yes) [11:38] Laney, I should have done that triaging earlier, just got sick and busy and didn't find the energy, I guess if I miss my opportunity I should just deal with the fact that we didn't manage to get the quality where I wish we had and accept it's SRU material at this point, something I need to learn to be better at [11:38] Laney: ah, I didn't know you could see that there. plus I got no email due to the sync. thank you [11:39] Laney, but yeah, we need to be more organized in testing [11:39] also not having to deal with toolchain changes way post beta would help to free time for quality [11:40] but I'm not going to redo that discuss here today [11:40] :) [11:40] -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (groovy-proposed) [4:18.6.2-0ubuntu1] [11:43] RikMills: semi forgot about the no email thing, grr [11:44] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (groovy-proposed) [2:17.1.1-0ubuntu1] [11:44] -queuebot:#ubuntu-release- Unapproved: rejected nova [source] (groovy-proposed) [2:22.2.0-0ubuntu1] [11:46] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (groovy-proposed) [2:22.2.0-0ubuntu1] [12:09] sil2100, ddstreet: adding sshuttle to the big queue didn't help (if the last tests were run using the big queue) [12:20] -queuebot:#ubuntu-release- Unapproved: gwenview (hirsute-proposed/universe) [4:20.12.3-1 => 4:20.12.3-1ubuntu0.1] (kubuntu) [12:20] Laney: hope that ^ is ok now [12:33] Laney: indeed, sorry :-/ [12:33] Will be working on this today [12:35] I don't know what's up yet, it's very weird [12:36] Hey release-team! I've fixed a ABI breaking regression in netplan on friday, which I just uploaded and hope to still land in HH -release (or 0-day SRU). I filed a SRU bug, according to the final freeze protocol: bug #1922898 [12:36] Bug 1922898 in netplan.io (Ubuntu Hirsute) "[SRU] SEGFAULT on upgrade to 0.102-0ubuntu1~20.04.1" [Undecided, Triaged] https://launchpad.net/bugs/1922898 [12:40] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (focal-proposed) [2:16.3.0-0ubuntu1] [12:40] doko the MR still isn't merged https://code.launchpad.net/~ddstreet/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/401036 [12:41] doko the 'big' queue is totally different from 'big' tests [12:42] the 'big' autopkgtests make the testbed use 4 vcpus and a bit more mem, and increase the test timeout to 20000 seconds (about 5 hours) [12:42] the 'big' queue doesn't change what testbed or timeout is used for the test, IIUC [12:42] sorry 'huge' queue [12:47] personally i think the default timeout should be increased as IMHO keeping it at ~3hr doesn't save much and just increases the amount of wasted man-hours looking at timed out tests [12:47] but that's not up to me ;-) [12:49] sil2100, I've a fix for bug 1925002 coming. Currently testing it. [12:49] Bug 1925002 in ubiquity (Ubuntu) "Installer crashes during manual fulldisk encryption install (single partition with ext4, no LVM/ZFS)" [High, Triaged] https://launchpad.net/bugs/1925002 [12:53] jibel: ACK, thanks! [12:55] slyon: hey! Thanks! How broken is netplan.io in hirsute right now? How easy is it to reproduce this crash on a normally running system? [12:57] -queuebot:#ubuntu-release- Unapproved: openblas (hirsute-proposed/universe) [0.3.13+ds-2 => 0.3.13+ds-3] (kubuntu) (sync) [12:58] sil2100: hey! It's not too broken in hirsute itself, as the crash only happens in a upgrade scenario where netplan-generate (v0.101) is using libnetplan v0.102. So it does not crash in hirsute itself, but might crash if somebody upgrades from an older version. [12:58] Ok, then this feels like a good 0-day SRU candidate! [12:59] Also, the problem is that the current version is shippting the new "tunnel.ttl" feature/setting, which I needed to drop, as it caused the ABI breakage. And if we ship that with HH we would roll-back/regress that feature in hirsute-release [13:00] whereas it would never have been officially shipped if it lands in -release. But 0-day SRU should be fine as well. [13:05] The crash is easily reproducible, if v0.102 library and v0.101 binary ("generate") is installed, just by executing /usr/lib/netplan generate, having the basic YAML config from the bug report in place. [13:06] Laney: hi, could I get access to update the release notes? [13:14] -queuebot:#ubuntu-release- Unapproved: netplan.io (focal-proposed/main) [0.102-0ubuntu1~20.04.1 => 0.102-0ubuntu1~20.04.2] (core) [13:18] -queuebot:#ubuntu-release- Unapproved: winetricks (hirsute-proposed/universe) [0.0+20210206-1 => 0.0+20210206-2] (no packageset) (sync) [13:19] -queuebot:#ubuntu-release- Unapproved: accepted winetricks [sync] (hirsute-proposed) [0.0+20210206-2] [13:21] slyon: yeah, it's a bit unfortunate that we'll be rolling back functionality, but sometimes there's not much one can do - netplan.io is risky enough that I'd prefer to just 0-day SRU it [13:22] sil2100: sure. that's fine, thank you! [13:25] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (focal-proposed) [2:16.3.1-0ubuntu1] [13:27] coreycb: not from me, you need to be added to the canonical group, ask popey (who is going to be able to do that $later?) [13:27] Laney tons of people. there's more admins than users on that site! [13:27] good [13:27] is that viewable? [13:27] Laney: popey: ok thanks [13:27] -queuebot:#ubuntu-release- Unapproved: rejected nova [source] (focal-proposed) [2:21.2.0-0ubuntu1] [13:29] Laney by admins, yes [13:29] heh [13:29] I see a bootstrapping problem [13:29] corey is already in canonical and release groups [13:30] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (focal-proposed) [2:21.2.0-0ubuntu1] [13:30] rhys, igor, peterm, pdjc, hloeung. tons [13:31] ty [13:32] Laney: once you put the freeze block on, I'll accept netplan.io as a 0-day SRU o/ [13:32] -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (focal-proposed) [3:18.3.3-0ubuntu1] [13:33] sil2100: Laney: do we want new usb-creator? https://code.launchpad.net/~saivinob/usb-creator/usb-creator/+merge/401344 [13:33] it's borked on kde. [13:34] coreycb: hey! Looking at the OpenStack updates for focal - the bug says there should be an octavia upload as well, but I don't see it in the queue? [13:35] xnox: I don't think we need this to work from the live-session? It's not installation critical, people can upgrade to get it working [13:35] So I'd say a 0-day SRU possibly? [13:35] ubuntu-archive please move libzstd and binaries to main in xenial, too, it is in main in later releases [13:38] rbalint: is there a component mismatch? [13:42] -queuebot:#ubuntu-release- Unapproved: ubiquity (hirsute-proposed/main) [21.04.17 => 21.04.19] (desktop-core) [13:43] sil2100: here you go, we tested it carefully with both encryption methods (manual and auto) ^ [13:43] I just released containerd to Groovy, Focal and Bionic, but just remembered there's a NEW binary that needs an AA ack. [13:44] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.49.2] [13:44] Could ubuntu-archive take a look please? [13:44] And will that need fixing up in -updates after? [13:46] xnox: I'd think we could SRU usb-creator. [13:49] Reviewing ubiquity ^ [13:54] didrocks999: thanks! Looks sane, I don't know the new recovery key code too well but I trust your testing! [13:55] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (hirsute-proposed) [21.04.19] [13:57] xnox: you can upload it, not sure if should be sru, but get it in the queue with a bug linked if you want [14:00] hi guys, I'm having trouble with a groovy laptop (desktop install) that I upgraded to hirsute, it's not booting anymore after the upgrade (UEFI, not secure boot). I can't even get to grub. Just wondering if there is a known issue around this, while I troubleshoot further [14:00] it's lvm+luks [14:01] Nothing that I'm aware of [14:01] ok, thx [14:02] hum, what's the logic behind not taking fixes like the usb-creater kde one? That's a side utility that isn't going to impact the live session nor installer and it's not starting today, what's the regression potential? [14:03] not that I particular care about that fix but that seems over conservative... [14:03] seb128: taking usb-creator in means respining all flavours that have usb-creator on them, i.e. ubuntu => it's not just an upload that affects kubuntu. [14:04] seb128: and we have had an icon change producing unbootable isos on release week before.... the squashfs bug. [14:04] xnox, we have an ubiquity upload that is going to be accepted, doesn't it mean respinning anyway? [14:04] literary a change of an icon, triggered bug in squashfs module of kernel, making all isos not boot =) [14:04] seb128: sure => just saying that any upload carries additional "unknown" risk. [14:06] xnox, I stand to the fact that if respin it's not then including a fix for a broken utility isn't going extra risks [14:07] vorlon: Laney tells me that the KPI re CD image size had a bug which was fixed around the jump in size date [14:07] doko, not yet, but bdmurray made the observation that libzstd1 is not in main when he looked at dpkg in Xenial's Unapproved queue that will depend on it [14:08] doko, bdmurray imo it is enough to sort this out after dpkg landed in -proposed, but maybe it can be done earlier [14:12] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.49.2+18.04] [14:14] rbalint: did you upload libzstd sru too? bumpt to match bionic point release? [14:14] that one should be published into main. [14:17] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (focal-proposed) [2.49.2+20.04] [14:19] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (groovy-proposed) [2.49.2+20.10] [14:24] icey: o/ is sil2100's question above related to a point release? [14:25] xnox, 1.3.x is present in Xenial already [14:26] coreycb: ah - yeah; it turns out that I don't have permissions to upload Octavia to Focal :) [14:26] coreycb: it's ready for upload in the git repo [14:27] icey: ok let me upload that and report back [14:27] thanks! [14:28] xnox, if you mean Xenial's libzstd needs the CVE fixes to be promoted then dpkg only decompresses packages thus the CVEs listed in bionic's update are not affecting this use case [14:28] ubuntu-archive: is there any AA available to process the new containerd binary package uploaded to focal and bionic? [14:29] sil2100: icey: octavia is on it's way to the focal unapproved queue. thanks for reviewing sil2100. [14:29] Found the publisher problem, should be fixed shortly [14:29] Sorry about that, rare corner case [14:29] (https://bugs.launchpad.net/launchpad/+bug/1900464) [14:29] \o/ [14:29] Launchpad bug 1900464 in Launchpad itself "ddtp-translations publication of Translation-en breaks the publisher" [Critical, Triaged] [14:29] -queuebot:#ubuntu-release- Unapproved: octavia (focal-proposed/universe) [6.1.0-0ubuntu1 => 6.2.0-0ubuntu1] (no packageset) [14:29] xnox, also security fixes can be released in the ESM period, too, thus those are not reasons to block dpkg in my eye [14:30] kanashiro: on it o/ [14:30] cjwatson: wow [14:31] cjwatson: so it happened once again! I didn't even know this happened for groovy already [14:31] sil2100, thanks! FWIW vorlon agreed on accepting it in a previous discussion with sergiodj [14:33] -queuebot:#ubuntu-release- New: accepted containerd [amd64] (focal-proposed) [1.4.4-0ubuntu1~20.04.2] [14:33] -queuebot:#ubuntu-release- New: accepted containerd [amd64] (bionic-proposed) [1.4.4-0ubuntu1~18.04.2] [14:49] -queuebot:#ubuntu-release- Unapproved: heat-dashboard (hirsute-proposed/main) [4.1.0-0ubuntu1 => 5.0.0-0ubuntu1] (openstack) [14:51] -queuebot:#ubuntu-release- Unapproved: magnum-ui (hirsute-proposed/universe) [8.0.0~rc1-0ubuntu1 => 8.0.0-0ubuntu1] (no packageset) [14:52] -queuebot:#ubuntu-release- Unapproved: accepted magnum-ui [source] (hirsute-proposed) [8.0.0-0ubuntu1] === stgraber_ is now known as stgraber [15:02] Laney, sil2100: there is an MP for shim now https://code.launchpad.net/~rbalint/shim/+git/shim/+merge/401388 [15:05] ahasenack: what hardware? bug 1925010 [15:05] Bug 1925010 in shim (Ubuntu) "shim-signed does not boot on MBA 5,2" [High, New] https://launchpad.net/bugs/1925010 [15:05] ahasenack: are you using an old macbook? [15:07] bdmurray: we're newbs in the shim world, but does that require re-signing shim? [15:07] sil2100: yes [15:09] Ok, so nothing we can do for 21.04? [15:10] Yes, and we might want to block upgrades for this hardware until its sorted. [15:15] any idea how to do that? [15:16] Laney: we might be able to query the UEFI version from runtime. [15:16] We need to do some investigation into quirking it. [15:21] xnox: query for Apple as vendor or just disable it on all UEFI !secure-boot [15:23] or revert shim & shim-signed to previous version. [15:24] juliank: it's specific to old efi implementations thus is not vendor specific. [15:24] juliank: trying to find if the EFI spec version is exposed anywhere at runtime. [15:24] xnox: only apple really shipped EFI [15:24] * 1 [15:25] I mean it's gonna make all the SRUs wait until this is fixed isn't it? [15:25] -queuebot:#ubuntu-release- Unapproved: accepted octavia [source] (focal-proposed) [6.2.0-0ubuntu1] [15:25] yes, no shim SRUs before this is fixed [15:25] juliank: wait, this is about EFI 1.1 without the U? =) [15:25] omg..... maybe we can just quirk it to apple. [15:26] i had EFI 1.1 motherboard, but it defaulted to legacy boot, one had to opt into EFI boot. [15:26] and it was all kinds of broken. [15:26] xnox: Yes, UEFI is 2.0+ [15:26] but then we still have to say don't download hirsute ISOs if you have this hardware, and somehow fix them later [15:26] Laney: The images won't boot anyway [15:26] because? [15:26] Laney, bdmurray, sil2100: dunno if anyone read my mutterings from over the weekend; do we want to seed xz-utils so that it stays in ubuntu-standard? It fell out as a side-effect of demoting mime-support [15:26] Laney: They use a shim too? [15:26] I'm less concerned about bzip2, but xz-utils I think should be installed everywhere by default [15:27] Laney: So if you can boot shim on the iso, you can boot shim on the disk [15:27] juliank: I know [15:27] Laney: there are existing old EFI 1.x Macbooks that groovy doesn't boot on [15:27] vorlon: Sounds like a good idea to seed that to me [15:28] why seed xz-utils? [15:28] how is it important to anyone? [15:28] juliank: because uncompressing xz archives is a common action, just like gzip (but not bz2) [15:28] and tar aiui doesn't link to a library for this but calls out to unxz [15:29] juliank: are there any variable we can check that is UEFI 2.0+ specific and not present on EFI? [15:29] I guess I'm mainly saying if this is going to delay the SRU anyway for all the other releases, then why not the same for hirsute and we can keep it booting on more hardware [15:30] xnox: I looked at the shim patch from Peter and it is looking at the *table* header, not a variable, and I can't see that this is exported to userspace by the kernel. We could pick some variable that is standardized in 2.0 but not in 1.0 but that would still be heuristic [15:30] It's just one more release to SRU [15:30] xnox: I don't know [15:30] Laney: we certainly would SRU it to hirsute so that upgrades from groovy work; but that wouldn't fix the boot media? [15:30] I'm suggesting reverting [15:30] Laney: Do you want to respin hirsute when the old shim is revoked? [15:30] oh [15:31] well, repeating xnox's suggestion :-) [15:31] /sys/firmware/efi/config_table hm [15:31] Laney: because THAT has the consequence that hirsute boot media stop working sometime after July for Windows dual-boot users, after Microsoft revokes the old shim [15:31] before hirsute EOLs [15:32] Yah, same for LTSen [15:32] LTS will have a point release in July for this [15:32] July/August [15:32] Laney: We respin LTS releases, but not hirsute [15:32] Wait, vorlon just mentioned there are existing old EFI macbooks that groovy doesn't boot on currently? For the same reason? [15:32] hirsute wouldn't unless we have to [15:32] sil2100: Another reason [15:32] sil2100: for a different but related reason (shim falls over if it can't write to MokListRT) [15:32] hm, ohkay [15:32] Our options are [15:33] it's a smaller set of old MacBooks [15:33] 1) delay hirsute 2) revert and respin hirsute when new shim is there 3) delay hirsute upgrades [15:33] I believe that 3 is the most sensible option [15:33] anyway, on balance I think "boot media revoked and not bootable on recent Windows machines in ~5 months" > "boot media doesn't work on 10-year-old MacBooks" [15:34] rbalint: what is output of /sys/firmware/efi/fw_vendor for you? [15:34] Could we just shorten the support period of Hirsute? ;-) [15:34] rbalint: wait, that's not useful as that's just the _address_ of it. not value. [15:34] We wouldn't be in the LHS position because we'd have respun [15:34] well people would have to go re-download :( [15:36] Laney: "we'd have respun" - so you want to commit us to do a point release of hirsute? [15:36] I don't [15:37] We could just not accept SRUs and then respin 21.04.0 in a week or two [15:37] Yes, I don't think it's a big deal to add it to the set with the LTS releases, it's better than being avoidably known broken on some hardware [15:37] it's not a huge deal to me, but I think it is a better option [15:38] somewhere in this house is one of those machines :p [15:38] Am I thinking correctly that both 2) and 3) options would ultimately require us to re-spin? In the case of 2) to get the new shim, 3) to also get the new shim to 'unblock' broken devices? [15:39] Well, of course with 3) we can just stay and say "we don't care about these old devices" too [15:39] Laney: I disagree because messaging around point releases of non-LTS releases is confusing, and a point release is a non-trivial amount of work for each series; we would do it for each of the supported LTSes because there's no other option, but I was trying to avoid it for hirsute [15:39] And only worry about users upgrading [15:40] sil2100: We'd not respin just to provide hirsute images to 10y old macbook users [15:40] sil2100: I would definitely not message it as "we don't care about these devices" - we just were unable to support the non-standard EFI implementation on hirsute install media, but upgrades from focal or groovy will work [15:40] They'd have to go start with a groovy image [15:40] Yeah, so I don't know yet which option I like best, but thinking about another non-lts point-release does make me feel anxious [15:41] We could try submitting the shim today I suppose, given the small number of patches [15:41] Since we seem to be doing those over and over again (for security issues) while we shouldn't really [15:41] But I don't think we'd have a shim back before planned release data [15:41] vorlon: right, yeah [15:41] i would want to respin resign shim; push hirsute release day by 1 week. [15:42] xnox: what was signing rtt for last shim? [15:42] juliank: less than 48h [15:42] submitted on thursday, and it was back on Monday morning EU time. No idea if it was like signed on Friday. [15:42] so if we submit today, we should be able to get a shim back this week and release next week [15:42] juliank: there's no way that submitting it today with the intent of including it in hirsute media doesn't impact our media mastering timeline [15:42] vorlon: right [15:42] vorlon: we'd have to push the release to apr 29 [15:43] vorlon: or respin 21.04.0 on apr 29 [15:43] on desktop [15:43] :P [15:43] we could publish amd64+mac image with old shim [15:43] So personally I really don't feel this is something we should be delaying the release for [15:43] and publish old shim as shim-signed-apple [15:43] This I know for sure [15:43] we did have amd64+mac images before.... [15:43] sil2100: 21.04.0 would be OK I'd guess, with only the shim updated? [15:44] xnox: if we push the release date would you stay on the team for the extra week? [15:44] or a mac specific image with just the shim [15:44] that would still be a point release [15:44] just one on a very short timeline [15:44] i do not want to piss off mac users. [15:44] and it wouldn't be fair to anyone to suggest we do this only for Ubuntu Desktop media [15:44] we have all the flavours too. [15:45] It's all possible, since we could keep hirsute frozen and just wait for this one SRU to be ready, but that will require the usual release testing resources [15:45] bdmurray: i'll discuss that with my manager bjf on our 1:1 this week ;-) [15:45] So it's just another thing that we didn't really plan for [15:46] hm hm [15:46] hmm flavours are a problem [15:46] last point release was a disaster PR wise. [15:46] when we did respin it, effectively. [15:46] xnox: the subset of mac users using 10yo+ hardware, running Ubuntu, and are super-keen to reinstall hirsute instead of upgrading [15:47] vorlon: it's not just 10yo+ hardware => are new macs actually UEFI yet? [15:47] we're not saying we won't support these users; we're saying they won't be able to use hirsute install media [15:47] xnox: new macs don't work anyway AFAIUI :D [15:47] >_< [15:48] lolz [15:48] "Since 2006, Mac computers with an Intel-based CPU use an Intel firmware based on the Extensible Firmware Interface (EFI) Development Kit (EDK) version 1 or version 2." https://support.apple.com/guide/security/uefi-firmware-security-in-an-intel-based-mac-seced055bcf6/web [15:48] "adequate macs of an appropriate age" [15:48] so yes, they did transition to UEFI 2 at some point [15:48] Ubuntu 21.04 install media and upgraded systems may not boot on older macs. Users are advised to hold off upgrading until a fixed version of shim is released. [15:48] ^ sth like that in release notes [15:49] again, I'm not ok with handling the upgrade issue only in the release notes [15:49] Yes [15:49] i think the comments about 2017 are valid => as bootcamp has ability to turn on Windows10 signing key to boot in secureboot on. So let's assume that 2017+ intel macs are UEFI v2. [15:49] we need to block the upgrade (for at least these users, and reliably) until we have the new shim [15:49] vorlon: I did not say "just" [15:49] possibly the cut off is somewhere between 2012 & 2017. [15:49] juliank: but then we don't have to advise them anything [15:49] vorlon: release notes + quirk or generic upgrade disablement [15:49] do we still submit new shim for signing today then? [15:50] xnox: has it been tested [15:50] ? [15:50] there are a couple of bug fixes we can pick up that are merged upstream. [15:50] we have a test plan that should be followed before we submit it [15:50] rbalint: you did test the patch on macbook right? [15:50] vorlon: balint verified the fix for the macbook sisue [15:50] We have not verified other fixes xnox wants or regression tested them on other systems [15:50] sure, but we should be running any new shim binary through the full testing before submitting for signing [15:50] We should submit & test in parallel imo [15:51] * could [15:51] this code change is unlikely to introduce regressions elsewhere (that our testing would catch) but cosmic rays etc [15:51] We want to cherry-pick 3 patches, not like a whole new release :) [15:51] if we're not trying to get it on release media there's no reason to submit it today [15:51] instead of after testing [15:51] that's true, I guess [15:52] and the downside of doing it in parallel is that we'll have generated an additional UEFI signed artifact that's useless :) [15:52] xnox, yes i've tested it, but i have not generated the shim-signed package, just copied the .efi binaries from the build to EFI/ [15:53] rbalint: that's all we need for that patch, cause there is no secureboot on macs. [15:53] vorlon: we don't have to submit it to signing, just to review :) [15:53] rbalint: that's all we need for that patch, cause there is no secureboot on _affected_ macs. [15:53] juliank: oh, doing that part in parallel seems fine to me, yes [15:55] anyway I'm seeding xz-utils and uploading ubuntu-meta, if someone can review [15:57] vorlon: +1 [15:59] uploaded [15:59] Looking [16:00] -queuebot:#ubuntu-release- Unapproved: ubuntu-meta (hirsute-proposed/main) [1.468 => 1.469] (core) [16:01] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (hirsute-proposed) [1.469] [16:01] vorlon: steve can you join the hangout? [16:03] Any objection to me updating hirsute base images (chroots and LXD images) from the cpc-buildd images, for https://answers.launchpad.net/launchpad/+question/696569)? I'll be able to revert if needed [16:04] Ideally I'd have done it last week, I know, but I was pretty slammed [16:05] i'm still +1 on that request. [16:05] we are not expecting any new toolchain things. [16:06] -queuebot:#ubuntu-release- Unapproved: accepted openblas [sync] (hirsute-proposed) [0.3.13+ds-3] [16:08] OK, other people have the amount of time it takes me to make coffee to object :-) [16:08] No objection here [16:16] "time it takes me to make coffee" can be very different depending on your technique! [16:17] I wasn't going to Colombia to get the beans [16:17] Updated now [16:17] xnox: Do you have some builds you can retry to confirm that this fixes the problem you had? [16:18] cjwatson: yes. [16:18] -queuebot:#ubuntu-release- Unapproved: usb-creator (hirsute-proposed/main) [0.3.9 => 0.3.10] (ubuntu-desktop) [16:22] xnox: https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/21429287 looks promising I think? [16:26] doko: apport has passed with pygobject, gdb, and dpkg now [16:26] cjwatson: yeap, all good. [16:27] \o/ [16:35] bdmurray: thank you for the usb-creator upload :) [16:36] RikMills: no problem! btw did those wifi testing steps help? [16:38] release freeze block is in place, seeded things need manually unblocking now [16:39] bdmurray: I think it did yes. Helped at least one tester confirm the fix as far as I know [16:47] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-450 (hirsute-proposed/restricted) [450.102.04-0ubuntu2 => 450.119.03-0ubuntu1] (core, i386-whitelist) [16:47] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-460 (hirsute-proposed/restricted) [460.67-0ubuntu1 => 460.73.01-0ubuntu1] (core, i386-whitelist) [16:48] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (hirsute-proposed/restricted) [390.141-0ubuntu2 => 390.143-0ubuntu1] (core, i386-whitelist, kernel-dkms) [16:48] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-460-server (hirsute-proposed/restricted) [460.32.03-0ubuntu2 => 460.73.01-0ubuntu1] (core, i386-whitelist) [16:49] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-418-server (hirsute-proposed/restricted) [418.181.07-0ubuntu2 => 418.197.02-0ubuntu1] (core, kernel-dkms) [16:49] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-450-server (hirsute-proposed/restricted) [450.102.04-0ubuntu2 => 450.119.03-0ubuntu1] (core, i386-whitelist) [17:03] hey ahasenack, what hardware did you have your Groovy upgrade issue? [17:08] bdmurray: juliank: it's a T420 in UEFI-only mode [17:08] paride: ^ [17:08]