| -queuebot:#ubuntu-release- Unapproved: accepted xubuntu-default-settings [source] (hirsute-proposed) [21.04.2] | 07:21 | |
| -queuebot:#ubuntu-release- Unapproved: base-files (hirsute-proposed/main) [11ubuntu18 => 11ubuntu19] (core, i386-whitelist) | 07:28 | |
| -queuebot:#ubuntu-release- Unapproved: ddtp-translations (hirsute-proposed/universe) [20201019.1 => 20210416.1] (no packageset) | 07:38 | |
| -queuebot:#ubuntu-release- Unapproved: accepted ddtp-translations [source] (hirsute-proposed) [20210416.1] | 07:39 | |
| -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] | 07:44 | |
| doko | I know we ignored the apport test failures for some packages. are we going to do that for the remaining ones as well? | 08:02 |
|---|---|---|
| sil2100 | Laney: base-files for the release in the queue, if you have a moment! | 08:03 |
| doko | 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:04 | |
| -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (hirsute-proposed) [11ubuntu19] | 08:07 | |
| Laney | sil2100: done | 08:08 |
| Laney | doko: yeah | 08:08 |
| sil2100 | \o/ | 08:09 |
| -queuebot:#ubuntu-release- Unapproved: dogtag-pki (hirsute-proposed/universe) [10.10.2-1 => 10.10.2-3] (no packageset) (sync) | 08:20 | |
| -queuebot:#ubuntu-release- Unapproved: accepted dogtag-pki [sync] (hirsute-proposed) [10.10.2-3] | 08:21 | |
| === 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 | ||
| doko | juliank, https://autopkgtest.ubuntu.com/running#pkg-llvm-toolchain-12 looks like bogus running state | 08:34 |
| juliank | doko: looking | 08:35 |
| juliank | clang: error: unable to execute command: Segmentation fault (core dumped) | 08:37 |
| juliank | clang: error: linker command failed due to signal (use -v to see invocation) | 08:37 |
| juliank | autopkgtest [08:32:55]: ERROR: testbed failure: testbed auxverb failed with exit code 254 | 08:37 |
| juliank | doko: ^ seeing crashes a lot | 08:37 |
| juliank | doko: it just retries all the time | 08:38 |
| juliank | 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 |
| doko | but it's an outdated trigger | 08:39 |
| juliank | doko: we're talking about the dpkg/1.20.9ubuntu1 trigger, no? | 08:40 |
| juliank | that was the one at the top when you asked | 08:40 |
| juliank | and that's the dpkg version in proposed | 08:40 |
| doko | ahh, ok | 08:41 |
| juliank | Also I'm not sure we cleanup triggers if they become obsolete | 08:41 |
| juliank | Anyway, I think all llvm-toolchain-12 runs are failures | 08:41 |
| doko | anyway, it's not important now | 08:41 |
| juliank | They just retry all the time, wasting resources | 08:41 |
| juliank | because autopkgtest thinks they're temporary testbed failures because compiler crashes usually ar | 08:42 |
| Laney | juliank: you can add a string to one of thoes lists in worker/worker | 08:44 |
| juliank | I think this run is obsolete: ['llvm-toolchain-12/1:12.0.0-1ubuntu1'] | 08:44 |
| Laney | do that, and then HUP them and eventually those things will fail out properly | 08:44 |
| juliank | Laney: doing that | 08:46 |
| doko | hmm, ok. never saw these because they always failed on !amd64 | 08:48 |
| juliank | They should now fail once the worker restarted | 08:49 |
| === pieq_ is now known as pieq | ||
| -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-libinput (hirsute-proposed/main) [0.30.0-1build1 => 0.30.0-1ubuntu1] (desktop-core) | 08:56 | |
| seb128 | ^ 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 | 08:59 |
| RikMills | 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:32 |
| RikMills | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987063 | 09:38 |
| ubot3 | Debian bug 987063 in gwenview "gwenview: looses image metadata on jpg rotation" [Important, Open] | 09:38 |
| -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:46 | |
| LocutusOfBorg | hello is publisher dead? | 09:59 |
| sil2100 | We'll see about those, but this time after Final Freeze we try to be more disciplined | 09:59 |
| LocutusOfBorg | I uploaded a mosquitto but its still not in proposed pocket | 10:00 |
| sil2100 | Like, we don't want to accept non-blocker fixes as per final freeze | 10:00 |
| -queuebot:#ubuntu-release- Unapproved: wine-development (hirsute-proposed/universe) [5.5-5ubuntu1 => 5.6-2] (i386-whitelist) (sync) | 10:02 | |
| juliank | 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:03 | |
| juliank | did somebody start thousands of tests again? :D | 10:05 |
| juliank | eek, new dpkg is not in | 10:07 |
| juliank | hirsute+1's apt requires dpkg >> 1.20.8, so I like need to install it from proposed | 10:07 |
| -queuebot:#ubuntu-release- Unapproved: python-apt (hirsute-proposed/main) [2.1.7ubuntu1 => 2.1.7ubuntu2] (core, i386-whitelist) | 10:10 | |
| juliank | sil2100: ^ possibly too late, but here's a python-apt with updated mirror list | 10:11 |
| juliank | Seems I gotta do 2.2.0 as an SRU | 10:11 |
| juliank | 2.2.0 is basically the same, just stable release instead of pre-release versioning. Though it might have some <!nocheck> build-dep annotations, but it's waiting for Debian release team | 10:12 |
| -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:14 | |
| juliank | We need the ability to flag packages in -updates for unattended-upgrades, really | 10:15 |
| rbalint | juliank, ? | 10:19 |
| rbalint | juliank, flag to install or not to install? | 10:19 |
| juliank | 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 |
| juliank | rbalint: Or the python-apt update above updates the mirror list | 10:20 |
| juliank | 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:21 |
| rbalint | juliank, i think that would surprise plenty of admins | 10:23 |
| juliank | possibly | 10:23 |
| juliank | non-security updates landing in security might too, though | 10:23 |
| rbalint | juliank, the glibc triggering apt error part was a pressing issue only because ubuquity does not upgrade itself afaik | 10:23 |
| sil2100 | 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:23 |
| juliank | sil2100: they are used for mirror selection in software-properties | 10:24 |
| rbalint | juliank, you can argue the the crash is a local DOS :-) | 10:24 |
| rbalint | juliank, i don't think that mirror selection is that critical to warrant an install through u-u | 10:25 |
| juliank | rbalint: It's still an issue because the nvidia drivers still fail to install for systems installed with 20.04.1 media _now_ | 10:25 |
| rbalint | juliank, with all -updates installed? | 10:26 |
| juliank | rbalint: No, because people don't install updates themselves | 10:26 |
| rbalint | juliank, their problem | 10:26 |
| juliank | rbalint: So they add an Nvidia card, click install driver, and it fails | 10:26 |
| juliank | rbalint: Re mirror list, it should really be a file updated automatically as part of apt update | 10:27 |
| juliank | and not in a package | 10:27 |
| juliank | which is in https://bugs.launchpad.net/launchpad/+bug/1875910 | 10:28 |
| ubot3 | Launchpad bug 1875910 in python-apt (Ubuntu) "Command to update mirror list" [High, Triaged] | 10:28 |
| rbalint | 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 |
| juliank | 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 |
| juliank | I guess we'll see! | 10:30 |
| -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (groovy-proposed) [2:17.1.0-0ubuntu1] | 10:37 | |
| juliank | xnox: https://code.launchpad.net/~juliank/ubiquity/+git/ubiquity/+merge/401370 | 10:52 |
| rbalint | xnox, sil2100: LP: #1925010 | 10:52 |
| ubot3 | Launchpad bug 1925010 in shim (Ubuntu) "shim-signed does not boot on MBA 5,2" [High, New] https://launchpad.net/bugs/1925010 | 10:52 |
| juliank | xnox: Validated that it skips the install medium ESP, but need to check it doesn't skip ESPs on the real disk | 10:52 |
| juliank | xnox: Ah no, it seems I already checked :D | 10:53 |
| juliank | /dev/sda2 which is 537 MB is marked EFI, and /dev/sdb2 which is 5MB is not | 10:53 |
| xnox | juliank: awesomes | 10:55 |
| xnox | juliank: https://code.launchpad.net/~juliank/ubiquity/+git/ubiquity/+merge/401370 looks good, but you need release team approval. | 10:57 |
| xnox | sil2100: the shim-signed bug sounds scary. | 10:57 |
| juliank | sil2100, Laney One of you want to approve that ubiquity change^ | 10:57 |
| juliank | s/change/merge proposal/ | 10:58 |
| -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) | 10:59 | |
| juliank | Commit message should probably say 50 MiB | 11:00 |
| Laney | xnox: upload it, will accept from the queue | 11:03 |
| juliank | Laney: I guess you mean me? | 11:06 |
| Laney | 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:07 | |
| juliank | Laney: ^ there it is, and merged | 11:08 |
| Laney | ty | 11:08 |
| Laney | juliank: can you add it to the release discourse too please? link in topic | 11:08 |
| juliank | Laney: Under Bugs which are fixed or Bugs to watch? | 11:10 |
| juliank | Notably it's just a workaround, not a complete bug fix, so haven't closed the issue in the changelog | 11:11 |
| Laney | well we need to check it is fixed, I dunno either the first or the third section | 11:11 |
| Laney | no idea what that third one is to be honest, we haven't used it before | 11:11 |
| -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 | |
| Laney | cjwatson: there is some sort of publisher outage at the minute, right? | 11:14 |
| juliank | I also want to point out that ubiquity crashed for me when I go back after the partition screen | 11:15 |
| juliank | But I need to recheck | 11:15 |
| seb128 | 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:15 |
| juliank | Oh dear bugs | 11:17 |
| doko | looks likeit, no sources published fot at least 2h | 11:26 |
| Laney | seb128: I guess but looks like it could have been done sooner, not super happy about release week fixes | 11:27 |
| sil2100 | 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 |
| Laney | and I don't believe 'trivial' at this point :p | 11:27 |
| Laney | oh | 11:27 |
| Laney | heh | 11:27 |
| RikMills | if not too late, could we get this fix uploaded please? https://code.launchpad.net/~saivinob/usb-creator/usb-creator/+merge/401344 | 11:27 |
| RikMills | 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:28 | |
| seb128 | 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:29 |
| -queuebot:#ubuntu-release- Unapproved: rejected gwenview [sync] (hirsute-proposed) [4:20.12.3-2] | 11:30 | |
| seb128 | 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:30 | |
| -queuebot:#ubuntu-release- Unapproved: accepted octavia [source] (groovy-proposed) [7.1.1-0ubuntu1] | 11:31 | |
| seb128 | 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:31 |
| seb128 | sorry for bothering | 11:32 |
| -queuebot:#ubuntu-release- Unapproved: alsa-ucm-conf (focal-proposed/main) [1.2.2-1ubuntu0.6 => 1.2.2-1ubuntu0.7] (no packageset) | 11:35 | |
| Laney | 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 |
| Laney | sometimes with release week introduced regressions | 11:35 |
| seb128 | yes, I understand and share the concerns | 11:36 |
| Laney | 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:36 |
| RikMills | does whoever rejected gwenview want that queued up with SRU etc versioning instead? | 11:37 |
| Laney | but lining up SRUs at this point is fine and expected | 11:37 |
| Laney | RikMills: see the reject message which you can see in the queue (but yes) | 11:37 |
| seb128 | 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 |
| RikMills | Laney: ah, I didn't know you could see that there. plus I got no email due to the sync. thank you | 11:38 |
| seb128 | Laney, but yeah, we need to be more organized in testing | 11:39 |
| seb128 | also not having to deal with toolchain changes way post beta would help to free time for quality | 11:39 |
| seb128 | but I'm not going to redo that discuss here today | 11:40 |
| Laney | :) | 11:40 |
| -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (groovy-proposed) [4:18.6.2-0ubuntu1] | 11:40 | |
| Laney | RikMills: semi forgot about the no email thing, grr | 11:43 |
| -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:44 | |
| -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (groovy-proposed) [2:22.2.0-0ubuntu1] | 11:46 | |
| doko | sil2100, ddstreet: adding sshuttle to the big queue didn't help (if the last tests were run using the big queue) | 12:09 |
| -queuebot:#ubuntu-release- Unapproved: gwenview (hirsute-proposed/universe) [4:20.12.3-1 => 4:20.12.3-1ubuntu0.1] (kubuntu) | 12:20 | |
| RikMills | Laney: hope that ^ is ok now | 12:20 |
| cjwatson | Laney: indeed, sorry :-/ | 12:33 |
| cjwatson | Will be working on this today | 12:33 |
| cjwatson | I don't know what's up yet, it's very weird | 12:35 |
| slyon | 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 |
| ubot3 | 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:36 |
| -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (focal-proposed) [2:16.3.0-0ubuntu1] | 12:40 | |
| ddstreet | doko the MR still isn't merged https://code.launchpad.net/~ddstreet/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/401036 | 12:40 |
| ddstreet | doko the 'big' queue is totally different from 'big' tests | 12:41 |
| ddstreet | 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 |
| ddstreet | the 'big' queue doesn't change what testbed or timeout is used for the test, IIUC | 12:42 |
| ddstreet | sorry 'huge' queue | 12:42 |
| ddstreet | 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 |
| ddstreet | but that's not up to me ;-) | 12:47 |
| jibel | sil2100, I've a fix for bug 1925002 coming. Currently testing it. | 12:49 |
| ubot3 | 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:49 |
| sil2100 | jibel: ACK, thanks! | 12:53 |
| sil2100 | 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:55 |
| -queuebot:#ubuntu-release- Unapproved: openblas (hirsute-proposed/universe) [0.3.13+ds-2 => 0.3.13+ds-3] (kubuntu) (sync) | 12:57 | |
| slyon | 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 |
| sil2100 | Ok, then this feels like a good 0-day SRU candidate! | 12:58 |
| slyon | 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 | 12:59 |
| slyon | whereas it would never have been officially shipped if it lands in -release. But 0-day SRU should be fine as well. | 13:00 |
| slyon | 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:05 |
| coreycb | Laney: hi, could I get access to update the release notes? | 13:06 |
| -queuebot:#ubuntu-release- Unapproved: netplan.io (focal-proposed/main) [0.102-0ubuntu1~20.04.1 => 0.102-0ubuntu1~20.04.2] (core) | 13:14 | |
| -queuebot:#ubuntu-release- Unapproved: winetricks (hirsute-proposed/universe) [0.0+20210206-1 => 0.0+20210206-2] (no packageset) (sync) | 13:18 | |
| -queuebot:#ubuntu-release- Unapproved: accepted winetricks [sync] (hirsute-proposed) [0.0+20210206-2] | 13:19 | |
| sil2100 | 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:21 |
| slyon | sil2100: sure. that's fine, thank you! | 13:22 |
| -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (focal-proposed) [2:16.3.1-0ubuntu1] | 13:25 | |
| Laney | 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 |
| popey | Laney tons of people. there's more admins than users on that site! | 13:27 |
| Laney | good | 13:27 |
| Laney | is that viewable? | 13:27 |
| coreycb | Laney: popey: ok thanks | 13:27 |
| -queuebot:#ubuntu-release- Unapproved: rejected nova [source] (focal-proposed) [2:21.2.0-0ubuntu1] | 13:27 | |
| popey | Laney by admins, yes | 13:29 |
| Laney | heh | 13:29 |
| Laney | I see a bootstrapping problem | 13:29 |
| popey | corey is already in canonical and release groups | 13:29 |
| -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (focal-proposed) [2:21.2.0-0ubuntu1] | 13:30 | |
| popey | rhys, igor, peterm, pdjc, hloeung. tons | 13:30 |
| Laney | ty | 13:31 |
| sil2100 | 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:32 | |
| xnox | sil2100: Laney: do we want new usb-creator? https://code.launchpad.net/~saivinob/usb-creator/usb-creator/+merge/401344 | 13:33 |
| xnox | it's borked on kde. | 13:33 |
| sil2100 | 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:34 |
| sil2100 | 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 |
| sil2100 | So I'd say a 0-day SRU possibly? | 13:35 |
| rbalint | ubuntu-archive please move libzstd and binaries to main in xenial, too, it is in main in later releases | 13:35 |
| doko | rbalint: is there a component mismatch? | 13:38 |
| -queuebot:#ubuntu-release- Unapproved: ubiquity (hirsute-proposed/main) [21.04.17 => 21.04.19] (desktop-core) | 13:42 | |
| didrocks999 | sil2100: here you go, we tested it carefully with both encryption methods (manual and auto) ^ | 13:43 |
| rbasak | I just released containerd to Groovy, Focal and Bionic, but just remembered there's a NEW binary that needs an AA ack. | 13:43 |
| -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.49.2] | 13:44 | |
| rbasak | Could ubuntu-archive take a look please? | 13:44 |
| rbasak | And will that need fixing up in -updates after? | 13:44 |
| bdmurray | xnox: I'd think we could SRU usb-creator. | 13:46 |
| sil2100 | Reviewing ubiquity ^ | 13:49 |
| sil2100 | didrocks999: thanks! Looks sane, I don't know the new recovery key code too well but I trust your testing! | 13:54 |
| -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (hirsute-proposed) [21.04.19] | 13:55 | |
| Laney | xnox: you can upload it, not sure if should be sru, but get it in the queue with a bug linked if you want | 13:57 |
| ahasenack | 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 |
| ahasenack | it's lvm+luks | 14:00 |
| bdmurray | Nothing that I'm aware of | 14:01 |
| ahasenack | ok, thx | 14:01 |
| seb128 | 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:02 |
| seb128 | not that I particular care about that fix but that seems over conservative... | 14:03 |
| xnox | 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:03 |
| xnox | seb128: and we have had an icon change producing unbootable isos on release week before.... the squashfs bug. | 14:04 |
| seb128 | xnox, we have an ubiquity upload that is going to be accepted, doesn't it mean respinning anyway? | 14:04 |
| xnox | literary a change of an icon, triggered bug in squashfs module of kernel, making all isos not boot =) | 14:04 |
| xnox | seb128: sure => just saying that any upload carries additional "unknown" risk. | 14:04 |
| seb128 | 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:06 |
| bdmurray | 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 |
| rbalint | 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:07 |
| rbalint | doko, bdmurray imo it is enough to sort this out after dpkg landed in -proposed, but maybe it can be done earlier | 14:08 |
| -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.49.2+18.04] | 14:12 | |
| xnox | rbalint: did you upload libzstd sru too? bumpt to match bionic point release? | 14:14 |
| xnox | that one should be published into main. | 14:14 |
| -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (focal-proposed) [2.49.2+20.04] | 14:17 | |
| -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (groovy-proposed) [2.49.2+20.10] | 14:19 | |
| coreycb | icey: o/ is sil2100's question above related to a point release? | 14:24 |
| rbalint | xnox, 1.3.x is present in Xenial already | 14:25 |
| icey | coreycb: ah - yeah; it turns out that I don't have permissions to upload Octavia to Focal :) | 14:26 |
| icey | coreycb: it's ready for upload in the git repo | 14:26 |
| coreycb | icey: ok let me upload that and report back | 14:27 |
| icey | thanks! | 14:27 |
| rbalint | 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 |
| kanashiro | ubuntu-archive: is there any AA available to process the new containerd binary package uploaded to focal and bionic? | 14:28 |
| coreycb | sil2100: icey: octavia is on it's way to the focal unapproved queue. thanks for reviewing sil2100. | 14:29 |
| cjwatson | Found the publisher problem, should be fixed shortly | 14:29 |
| cjwatson | Sorry about that, rare corner case | 14:29 |
| cjwatson | (https://bugs.launchpad.net/launchpad/+bug/1900464) | 14:29 |
| Laney | \o/ | 14:29 |
| ubot3 | 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 | |
| rbalint | xnox, also security fixes can be released in the ESM period, too, thus those are not reasons to block dpkg in my eye | 14:29 |
| sil2100 | kanashiro: on it o/ | 14:30 |
| sil2100 | cjwatson: wow | 14:30 |
| sil2100 | cjwatson: so it happened once again! I didn't even know this happened for groovy already | 14:31 |
| kanashiro | sil2100, thanks! FWIW vorlon agreed on accepting it in a previous discussion with sergiodj | 14:31 |
| -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:33 | |
| -queuebot:#ubuntu-release- Unapproved: heat-dashboard (hirsute-proposed/main) [4.1.0-0ubuntu1 => 5.0.0-0ubuntu1] (openstack) | 14:49 | |
| -queuebot:#ubuntu-release- Unapproved: magnum-ui (hirsute-proposed/universe) [8.0.0~rc1-0ubuntu1 => 8.0.0-0ubuntu1] (no packageset) | 14:51 | |
| -queuebot:#ubuntu-release- Unapproved: accepted magnum-ui [source] (hirsute-proposed) [8.0.0-0ubuntu1] | 14:52 | |
| === stgraber_ is now known as stgraber | ||
| bdmurray | Laney, sil2100: there is an MP for shim now https://code.launchpad.net/~rbalint/shim/+git/shim/+merge/401388 | 15:02 |
| bdmurray | ahasenack: what hardware? bug 1925010 | 15:05 |
| ubot3 | Bug 1925010 in shim (Ubuntu) "shim-signed does not boot on MBA 5,2" [High, New] https://launchpad.net/bugs/1925010 | 15:05 |
| juliank | ahasenack: are you using an old macbook? | 15:05 |
| sil2100 | bdmurray: we're newbs in the shim world, but does that require re-signing shim? | 15:07 |
| bdmurray | sil2100: yes | 15:07 |
| sil2100 | Ok, so nothing we can do for 21.04? | 15:09 |
| bdmurray | Yes, and we might want to block upgrades for this hardware until its sorted. | 15:10 |
| Laney | any idea how to do that? | 15:15 |
| xnox | Laney: we might be able to query the UEFI version from runtime. | 15:16 |
| bdmurray | We need to do some investigation into quirking it. | 15:16 |
| juliank | xnox: query for Apple as vendor or just disable it on all UEFI !secure-boot | 15:21 |
| xnox | or revert shim & shim-signed to previous version. | 15:23 |
| xnox | juliank: it's specific to old efi implementations thus is not vendor specific. | 15:24 |
| xnox | juliank: trying to find if the EFI spec version is exposed anywhere at runtime. | 15:24 |
| juliank | xnox: only apple really shipped EFI | 15:24 |
| juliank | * 1 | 15:24 |
| Laney | 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 | |
| juliank | yes, no shim SRUs before this is fixed | 15:25 |
| xnox | juliank: wait, this is about EFI 1.1 without the U? =) | 15:25 |
| xnox | omg..... maybe we can just quirk it to apple. | 15:25 |
| xnox | i had EFI 1.1 motherboard, but it defaulted to legacy boot, one had to opt into EFI boot. | 15:26 |
| xnox | and it was all kinds of broken. | 15:26 |
| juliank | xnox: Yes, UEFI is 2.0+ | 15:26 |
| Laney | but then we still have to say don't download hirsute ISOs if you have this hardware, and somehow fix them later | 15:26 |
| juliank | Laney: The images won't boot anyway | 15:26 |
| Laney | because? | 15:26 |
| vorlon | 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 |
| juliank | Laney: They use a shim too? | 15:26 |
| vorlon | I'm less concerned about bzip2, but xz-utils I think should be installed everywhere by default | 15:26 |
| juliank | Laney: So if you can boot shim on the iso, you can boot shim on the disk | 15:27 |
| Laney | juliank: I know | 15:27 |
| vorlon | Laney: there are existing old EFI 1.x Macbooks that groovy doesn't boot on | 15:27 |
| Laney | vorlon: Sounds like a good idea to seed that to me | 15:27 |
| juliank | why seed xz-utils? | 15:28 |
| juliank | how is it important to anyone? | 15:28 |
| vorlon | juliank: because uncompressing xz archives is a common action, just like gzip (but not bz2) | 15:28 |
| vorlon | and tar aiui doesn't link to a library for this but calls out to unxz | 15:28 |
| xnox | juliank: are there any variable we can check that is UEFI 2.0+ specific and not present on EFI? | 15:29 |
| Laney | 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:29 |
| vorlon | 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 |
| Laney | It's just one more release to SRU | 15:30 |
| juliank | xnox: I don't know | 15:30 |
| vorlon | Laney: we certainly would SRU it to hirsute so that upgrades from groovy work; but that wouldn't fix the boot media? | 15:30 |
| Laney | I'm suggesting reverting | 15:30 |
| juliank | Laney: Do you want to respin hirsute when the old shim is revoked? | 15:30 |
| vorlon | oh | 15:30 |
| Laney | well, repeating xnox's suggestion :-) | 15:31 |
| xnox | /sys/firmware/efi/config_table hm | 15:31 |
| vorlon | 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 |
| vorlon | before hirsute EOLs | 15:31 |
| Laney | Yah, same for LTSen | 15:32 |
| vorlon | LTS will have a point release in July for this | 15:32 |
| vorlon | July/August | 15:32 |
| juliank | Laney: We respin LTS releases, but not hirsute | 15:32 |
| sil2100 | Wait, vorlon just mentioned there are existing old EFI macbooks that groovy doesn't boot on currently? For the same reason? | 15:32 |
| vorlon | hirsute wouldn't unless we have to | 15:32 |
| juliank | sil2100: Another reason | 15:32 |
| vorlon | sil2100: for a different but related reason (shim falls over if it can't write to MokListRT) | 15:32 |
| sil2100 | hm, ohkay | 15:32 |
| juliank | Our options are | 15:32 |
| vorlon | it's a smaller set of old MacBooks | 15:33 |
| juliank | 1) delay hirsute 2) revert and respin hirsute when new shim is there 3) delay hirsute upgrades | 15:33 |
| juliank | I believe that 3 is the most sensible option | 15:33 |
| vorlon | 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:33 |
| xnox | rbalint: what is output of /sys/firmware/efi/fw_vendor for you? | 15:34 |
| bdmurray | Could we just shorten the support period of Hirsute? ;-) | 15:34 |
| xnox | rbalint: wait, that's not useful as that's just the _address_ of it. not value. | 15:34 |
| Laney | We wouldn't be in the LHS position because we'd have respun | 15:34 |
| Laney | well people would have to go re-download :( | 15:34 |
| vorlon | Laney: "we'd have respun" - so you want to commit us to do a point release of hirsute? | 15:36 |
| vorlon | I don't | 15:36 |
| juliank | We could just not accept SRUs and then respin 21.04.0 in a week or two | 15:37 |
| Laney | 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 |
| Laney | it's not a huge deal to me, but I think it is a better option | 15:37 |
| Laney | somewhere in this house is one of those machines :p | 15:38 |
| sil2100 | 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:38 |
| sil2100 | Well, of course with 3) we can just stay and say "we don't care about these old devices" too | 15:39 |
| vorlon | 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 |
| sil2100 | And only worry about users upgrading | 15:39 |
| juliank | sil2100: We'd not respin just to provide hirsute images to 10y old macbook users | 15:40 |
| vorlon | 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 |
| juliank | They'd have to go start with a groovy image | 15:40 |
| sil2100 | 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:40 |
| juliank | We could try submitting the shim today I suppose, given the small number of patches | 15:41 |
| sil2100 | Since we seem to be doing those over and over again (for security issues) while we shouldn't really | 15:41 |
| juliank | But I don't think we'd have a shim back before planned release data | 15:41 |
| sil2100 | vorlon: right, yeah | 15:41 |
| xnox | i would want to respin resign shim; push hirsute release day by 1 week. | 15:41 |
| juliank | xnox: what was signing rtt for last shim? | 15:42 |
| xnox | juliank: less than 48h | 15:42 |
| xnox | submitted on thursday, and it was back on Monday morning EU time. No idea if it was like signed on Friday. | 15:42 |
| juliank | so if we submit today, we should be able to get a shim back this week and release next week | 15:42 |
| vorlon | 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 |
| juliank | vorlon: right | 15:42 |
| juliank | vorlon: we'd have to push the release to apr 29 | 15:42 |
| juliank | vorlon: or respin 21.04.0 on apr 29 | 15:43 |
| juliank | on desktop | 15:43 |
| vorlon | :P | 15:43 |
| xnox | we could publish amd64+mac image with old shim | 15:43 |
| sil2100 | So personally I really don't feel this is something we should be delaying the release for | 15:43 |
| xnox | and publish old shim as shim-signed-apple | 15:43 |
| sil2100 | This I know for sure | 15:43 |
| xnox | we did have amd64+mac images before.... | 15:43 |
| juliank | sil2100: 21.04.0 would be OK I'd guess, with only the shim updated? | 15:43 |
| bdmurray | xnox: if we push the release date would you stay on the team for the extra week? | 15:44 |
| juliank | or a mac specific image with just the shim | 15:44 |
| vorlon | that would still be a point release | 15:44 |
| vorlon | just one on a very short timeline | 15:44 |
| xnox | i do not want to piss off mac users. | 15:44 |
| vorlon | and it wouldn't be fair to anyone to suggest we do this only for Ubuntu Desktop media | 15:44 |
| xnox | we have all the flavours too. | 15:44 |
| sil2100 | 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 |
| xnox | bdmurray: i'll discuss that with my manager bjf on our 1:1 this week ;-) | 15:45 |
| sil2100 | So it's just another thing that we didn't really plan for | 15:45 |
| sil2100 | hm hm | 15:46 |
| juliank | hmm flavours are a problem | 15:46 |
| xnox | last point release was a disaster PR wise. | 15:46 |
| xnox | when we did respin it, effectively. | 15:46 |
| vorlon | xnox: the subset of mac users using 10yo+ hardware, running Ubuntu, and are super-keen to reinstall hirsute instead of upgrading | 15:46 |
| xnox | vorlon: it's not just 10yo+ hardware => are new macs actually UEFI yet? | 15:47 |
| vorlon | 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 |
| juliank | xnox: new macs don't work anyway AFAIUI :D | 15:47 |
| xnox | >_< | 15:47 |
| xnox | lolz | 15:48 |
| vorlon | "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 |
| xnox | "adequate macs of an appropriate age" | 15:48 |
| vorlon | so yes, they did transition to UEFI 2 at some point | 15:48 |
| juliank | 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 |
| juliank | ^ sth like that in release notes | 15:48 |
| vorlon | again, I'm not ok with handling the upgrade issue only in the release notes | 15:49 |
| juliank | Yes | 15:49 |
| xnox | 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 |
| vorlon | we need to block the upgrade (for at least these users, and reliably) until we have the new shim | 15:49 |
| juliank | vorlon: I did not say "just" | 15:49 |
| xnox | possibly the cut off is somewhere between 2012 & 2017. | 15:49 |
| vorlon | juliank: but then we don't have to advise them anything | 15:49 |
| juliank | vorlon: release notes + quirk or generic upgrade disablement | 15:49 |
| xnox | do we still submit new shim for signing today then? | 15:49 |
| vorlon | xnox: has it been tested | 15:50 |
| vorlon | ? | 15:50 |
| xnox | there are a couple of bug fixes we can pick up that are merged upstream. | 15:50 |
| vorlon | we have a test plan that should be followed before we submit it | 15:50 |
| xnox | rbalint: you did test the patch on macbook right? | 15:50 |
| juliank | vorlon: balint verified the fix for the macbook sisue | 15:50 |
| juliank | We have not verified other fixes xnox wants or regression tested them on other systems | 15:50 |
| vorlon | sure, but we should be running any new shim binary through the full testing before submitting for signing | 15:50 |
| juliank | We should submit & test in parallel imo | 15:50 |
| juliank | * could | 15:51 |
| vorlon | this code change is unlikely to introduce regressions elsewhere (that our testing would catch) but cosmic rays etc | 15:51 |
| juliank | We want to cherry-pick 3 patches, not like a whole new release :) | 15:51 |
| vorlon | if we're not trying to get it on release media there's no reason to submit it today | 15:51 |
| vorlon | instead of after testing | 15:51 |
| juliank | that's true, I guess | 15:51 |
| vorlon | and the downside of doing it in parallel is that we'll have generated an additional UEFI signed artifact that's useless :) | 15:52 |
| rbalint | 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:52 |
| xnox | rbalint: that's all we need for that patch, cause there is no secureboot on macs. | 15:53 |
| juliank | vorlon: we don't have to submit it to signing, just to review :) | 15:53 |
| xnox | rbalint: that's all we need for that patch, cause there is no secureboot on _affected_ macs. | 15:53 |
| vorlon | juliank: oh, doing that part in parallel seems fine to me, yes | 15:53 |
| vorlon | anyway I'm seeding xz-utils and uploading ubuntu-meta, if someone can review | 15:55 |
| sil2100 | vorlon: +1 | 15:57 |
| vorlon | uploaded | 15:59 |
| sil2100 | Looking | 15:59 |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-meta (hirsute-proposed/main) [1.468 => 1.469] (core) | 16:00 | |
| -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (hirsute-proposed) [1.469] | 16:01 | |
| xnox | vorlon: steve can you join the hangout? | 16:01 |
| cjwatson | 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:03 |
| cjwatson | Ideally I'd have done it last week, I know, but I was pretty slammed | 16:04 |
| xnox | i'm still +1 on that request. | 16:05 |
| xnox | we are not expecting any new toolchain things. | 16:05 |
| -queuebot:#ubuntu-release- Unapproved: accepted openblas [sync] (hirsute-proposed) [0.3.13+ds-3] | 16:06 | |
| cjwatson | OK, other people have the amount of time it takes me to make coffee to object :-) | 16:08 |
| Laney | No objection here | 16:08 |
| bdmurray | "time it takes me to make coffee" can be very different depending on your technique! | 16:16 |
| cjwatson | I wasn't going to Colombia to get the beans | 16:17 |
| cjwatson | Updated now | 16:17 |
| cjwatson | xnox: Do you have some builds you can retry to confirm that this fixes the problem you had? | 16:17 |
| xnox | cjwatson: yes. | 16:18 |
| -queuebot:#ubuntu-release- Unapproved: usb-creator (hirsute-proposed/main) [0.3.9 => 0.3.10] (ubuntu-desktop) | 16:18 | |
| cjwatson | xnox: https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/21429287 looks promising I think? | 16:22 |
| bdmurray | doko: apport has passed with pygobject, gdb, and dpkg now | 16:26 |
| xnox | cjwatson: yeap, all good. | 16:26 |
| cjwatson | \o/ | 16:27 |
| RikMills | bdmurray: thank you for the usb-creator upload :) | 16:35 |
| bdmurray | RikMills: no problem! btw did those wifi testing steps help? | 16:36 |
| Laney | release freeze block is in place, seeded things need manually unblocking now | 16:38 |
| RikMills | bdmurray: I think it did yes. Helped at least one tester confirm the fix as far as I know | 16:39 |
| -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:47 | |
| -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:48 | |
| -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) | 16:49 | |
| paride | hey ahasenack, what hardware did you have your Groovy upgrade issue? | 17:03 |
| ahasenack | bdmurray: juliank: it's a T420 in UEFI-only mode | 17:08 |
| ahasenack | paride: ^ | 17:08 |
| bdmurray | ahasenack: got it | 17:08 |
| ahasenack | but no secure-boot | 17:08 |
| juliank | ahasenack: T420 should have UEFI 2 though, so not the EFI 1 bug | 17:09 |
| juliank | ahasenack: I think you need to boot with like old shim or something and enable shim debug mode | 17:10 |
| juliank | possibly from live medium | 17:10 |
| ahasenack | it's very weird, it doesn't seem to be loading grub, and I get just a black screen, not even ctrl-alt-del works | 17:10 |
| juliank | ahasenack: Run mokutil --set-verbosity true from live | 17:10 |
| juliank | ahasenack: Then it should print if shim is starting up | 17:10 |
| ahasenack | but there is no secure boot, is that relevant? | 17:10 |
| juliank | ahasenack: god I hope not | 17:11 |
| juliank | shim breaking only on non-secureboot system would be hilarious | 17:11 |
| juliank | that said, I don't think we test non-securely booting shims at all, do we xnox? | 17:11 |
| juliank | I certainly did not with my shim updates | 17:12 |
| ahasenack | juliank: bdmurray: this comment fixed it for my T420: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1925010/comments/2 | 17:23 |
| ubot3 | Launchpad bug 1925010 in shim (Ubuntu) "shim-signed does not boot on MBA 5,2" [High, New] | 17:23 |
| juliank | ahasenack: ok, so shim is broken for you | 17:23 |
| juliank | xnox: ^ | 17:23 |
| juliank | I'd like to find more T420 users | 17:23 |
| juliank | ahasenack: Still would like you to run with verbose mode and see if it prints anything, if possible | 17:24 |
| ahasenack | so, break it again, and run that mokutil command? | 17:25 |
| juliank | ahasenack: yeah | 17:25 |
| ahasenack | I assume running grub-install would break it again | 17:25 |
| juliank | possible | 17:25 |
| juliank | probable | 17:25 |
| juliank | If T420 are affected, we should not enable dist upgrades at all, and don't need to worry about building quirks :D | 17:25 |
| ahasenack | it's a respectable T420: i7, 16Gb :) | 17:27 |
| ahasenack | but I'm on my 3rd keyboard tbh | 17:27 |
| bdmurray | I've a T450s is that worth testing? | 17:28 |
| juliank | vorlon's x230 might be worth testing | 17:29 |
| juliank | the *30 series was like close to *20 | 17:29 |
| juliank | just with the CPU heat turned up | 17:29 |
| ahasenack | ok, rebooting | 17:30 |
| juliank | My X230 is at my parents unfortunately | 17:30 |
| ahasenack | and kaput | 17:30 |
| juliank | ahasenack: Did it say anything | 17:33 |
| juliank | shim should print its version | 17:34 |
| ahasenack | juliank: that mokutil command returns with "This system doesn't support SEcure Boot" | 17:34 |
| ahasenack | bar the typo | 17:34 |
| juliank | ugh | 17:34 |
| juliank | ahasenack: Would you be willing to test enabling secure boot? | 17:35 |
| juliank | ahasenack: ah ok, i just heard it does not support sb at all | 17:35 |
| ahasenack | yep | 17:36 |
| ahasenack | that's why I asked if that command was relevant :) | 17:36 |
| ahasenack | I guess I didn't mention that it had no support for it, not that I just had it disabled | 17:36 |
| juliank | ahasenack: HGmm you can download https://pjones.fedorapeople.org/SHIM_VERBOSE-605dab50-e046-4300-abb6-3dd810dd8b23 and copy it to /sys/firmware/efi/efivars | 17:37 |
| juliank | ahasenack: that makes it verbose too | 17:38 |
| ahasenack | and reboot? | 17:39 |
| ahasenack | just did it on live, ready to reboot | 17:39 |
| -queuebot:#ubuntu-release- Unapproved: logwatch (bionic-proposed/main) [7.4.3+git20161207-2ubuntu1.2 => 7.4.3+git20161207-2ubuntu1.3] (ubuntu-server) | 17:41 | |
| -queuebot:#ubuntu-release- Unapproved: logwatch (xenial-proposed/main) [7.4.2-1ubuntu1.1 => 7.4.2-1ubuntu1.2] (ubuntu-server) | 17:41 | |
| ahasenack | that was very verbose indeed | 17:42 |
| -queuebot:#ubuntu-release- Unapproved: logwatch (focal-proposed/main) [7.5.2-1ubuntu1.1 => 7.5.2-1ubuntu1.2] (ubuntu-server) | 17:42 | |
| -queuebot:#ubuntu-release- Unapproved: logwatch (hirsute-proposed/main) [7.5.5-1ubuntu1 => 7.5.5-1ubuntu2] (no packageset) | 17:42 | |
| -queuebot:#ubuntu-release- Unapproved: logwatch (groovy-proposed/main) [7.5.4-0ubuntu3 => 7.5.4-0ubuntu3.1] (no packageset) | 17:42 | |
| -queuebot:#ubuntu-release- Unapproved: accepted logwatch [source] (hirsute-proposed) [7.5.5-1ubuntu2] | 17:42 | |
| ahasenack | would need to dump that to a serial console or something | 17:43 |
| ahasenack | it seems to be dumping a db to the screen in hex mode | 17:44 |
| xnox | ahasenack: yeap, all 300+ of hashes | 17:53 |
| juliank | xnox, ahasenack so I got report from an x220 that the shim binary works fine | 17:54 |
| juliank | ahasenack: wondering if your efi variable storage is full and that wreaks havoc somewhere | 17:55 |
| juliank | ahasenack: but at least it's dumping something so it starts running :D | 17:56 |
| ahasenack | don't know what to say, this is the only OS on that machine, and has been the only OS for many many many years (its whole lifetime basically) | 18:01 |
| ahasenack | if that's relevant to "efi being full" | 18:01 |
| juliank | It ran over for me once and then stopped booting | 18:01 |
| juliank | on the x230 | 18:01 |
| vorlon | ahasenack: it's extremely unlikely that the T420 issue is the same as the Macbook one since as juliank says it should be UEFI 2.0; so I think you should open a separate bug report for this issue | 18:02 |
| juliank | that too | 18:02 |
| juliank | * that's true | 18:02 |
| ahasenack | where do I check the uefi version? Somewhere in /sys? | 18:02 |
| juliank | ahasenack: you can look at /sys/firmware/efi/efivars and see if there are any large variables in there that could be deleted, fwiw, but i'm just guessing | 18:03 |
| juliank | ahasenack: in dmesg | grep EFI it tells you | 18:03 |
| juliank | Apr 14 12:08:39 jak-t480s kernel: efi: EFI v2.50 by Lenovo | 18:03 |
| ahasenack | has someone tried the patch from that bug in the mac to see if it fixes it? | 18:03 |
| juliank | ahasenack: yes, it fixes mac boot | 18:04 |
| ahasenack | ok, I see v2.00 by Lenovo too | 18:04 |
| juliank | ahasenack: it should not fix your boot though, because it will still trigger the v2 code path | 18:04 |
| juliank | ahasenack: but maybe you can hack it and make it always take the v1 path for testing purposes | 18:04 |
| ahasenack | if I remove the shim packages, will that fix it? | 18:04 |
| vorlon | "fix" | 18:05 |
| ahasenack | (the removal, not the patch) | 18:05 |
| ahasenack | well, until they are installed again | 18:05 |
| ahasenack | which I hope nothing would pull in | 18:05 |
| juliank | removing shim{,-signed} will make things work yes | 18:05 |
| vorlon | it would allow it to boot | 18:05 |
| vorlon | but that's not our supported UEFI boot configuration in Ubuntu | 18:05 |
| juliank | it would be an unsupported system | 18:05 |
| ahasenack | tough call: supported but unbootable, unsupported but bootable? | 18:05 |
| juliank | we'd rather get your boot fixed :) | 18:06 |
| ahasenack | agreed | 18:06 |
| juliank | Bugs everywhere, sigh | 18:07 |
| ahasenack | incidentally, if I may | 18:07 |
| ahasenack | the live env used to be persistent | 18:07 |
| ahasenack | or at least have a persistent partition | 18:07 |
| ahasenack | is that gone, or just moved elsewhere, renamed? | 18:07 |
| juliank | ahasenack: Also check BIOS and see what it says for UEFI BIOS version, others tested with 1.46 on x220 | 18:08 |
| ahasenack | let me get a new bug with that | 18:08 |
| ahasenack | found this in the duplicate check: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1849863 | 18:09 |
| ubot3 | Launchpad bug 1849863 in shim (Ubuntu) "shim-signed does not boot on Lenovo Yoga C630 WOS" [Undecided, New] | 18:09 |
| juliank | ahasenack: That's onARM | 18:13 |
| ahasenack | right | 18:13 |
| juliank | * on ARM | 18:13 |
| ahasenack | my bios version is 1.49, btw | 18:14 |
| ahasenack | from 2016 | 18:14 |
| ahasenack | ok, filed https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1925064 | 18:16 |
| ubot3 | Launchpad bug 1925064 in shim (Ubuntu) "shim(-signed)? does not boot on T420" [Undecided, New] | 18:16 |
| juliank | ahasenack: Maybe you can capture 120hz video of screen :D | 18:17 |
| juliank | ahasenack: With like phone | 18:17 |
| juliank | then we can slow-motion it | 18:17 |
| ahasenack | I actually tried | 18:17 |
| juliank | ah | 18:17 |
| ahasenack | but it was still too fast | 18:17 |
| ahasenack | it was using a big font | 18:17 |
| juliank | shame | 18:17 |
| ahasenack | 4min43s | 18:18 |
| === mhcerri_ is now known as mhcerri | ||
| vorlon | ahasenack: persistent> the desktop images have never included a persistent partition by default. subiquity can auto-create one, but ubiquity never has. You can create one yourself on a USB stick | 19:08 |
| ahasenack | I vaguely remember this working in older ubuntu live images | 19:09 |
| vorlon | not automatically if you just dd the image | 19:09 |
| vorlon | I think usb-creator may have created the persistence partition by default if writing to USB | 19:09 |
| ahasenack | it was using the usb creator | 19:09 |
| ahasenack | you could even select how much space you wanted for the persistent area | 19:09 |
| vorlon | right | 19:10 |
| vorlon | so, that's a feature of usb-creator, not of the images | 19:10 |
| ahasenack | that feature seems to have vanished | 19:10 |
| vorlon | out of usb-creator? | 19:10 |
| ahasenack | yeah | 19:10 |
| ahasenack | or I'm mixing utilities | 19:10 |
| vorlon | hmm, I don't know anything about that, sorry | 19:10 |
| ahasenack | `usb-creator-gtk` | 19:11 |
| bdmurray | * Rework the whole imaging process for writing to devices: | 19:11 |
| bdmurray | - Use an equivalent of dd to make an exact copy of the image to the device | 19:11 |
| bdmurray | - This also breaks persistence | 19:11 |
| ahasenack | xenial | 19:11 |
| vorlon | heh | 19:11 |
| bdmurray | That's from 2015 | 19:11 |
| vorlon | was that possibly driven by the syslinux inter-series incompatibilities? | 19:12 |
| ahasenack | no bug number | 19:12 |
| vorlon | (basically, because of ABI breaks, if you tried to use usb-creator to remaster an image for a newer release than the one you were running on, it would be unbootable) | 19:12 |
| vorlon | or vice-versa, running usb-creator on a newer release with a newer syslinux but trying to remaster an image for an older release | 19:13 |
| -queuebot:#ubuntu-release- Unapproved: dxvk (hirsute-proposed/universe) [1.7.3+ds1-1 => 1.8.1+ds1-1] (i386-whitelist) (sync) | 19:27 | |
| LocutusOfBorg | hello please accept ubootenv, due to * Define NDEBUG to avoid debug prints (Closes: #985948) | 19:27 |
| -queuebot:#ubuntu-release- Unapproved: accepted dxvk [sync] (hirsute-proposed) [1.8.1+ds1-1] | 19:27 | |
| LocutusOfBorg | basically the DEBUG was breaking parsing from reverse-deps | 19:27 |
| LocutusOfBorg | Eickmeyer, hello, syncing recordmydesktop will grab the fixes from debian, specifically libjack-jackd2-dev, | 19:39 |
| LocutusOfBorg | move from old libjack-dev | 19:39 |
| LocutusOfBorg | the diff is null I think | 19:40 |
| vorlon | LocutusOfBorg: what is ubootenv? There's no source package by that name in any release and nothing by that name in the unapproved queue | 19:42 |
| LocutusOfBorg | libubootenv | 19:42 |
| vorlon | LocutusOfBorg: the one that was rejected 8 hours ago? | 19:43 |
| LocutusOfBorg | oh I missed that | 19:43 |
| LocutusOfBorg | mmm I didn't really get the message | 19:43 |
| LocutusOfBorg | I should introduce a delta then? | 19:43 |
| vorlon | LocutusOfBorg: seems like it, based on the reject message | 19:45 |
| LocutusOfBorg | so I prefer a bug rather than a delta :) | 19:46 |
| vorlon | doko: why did you promote lzma to main, which has been in universe since bionic? (see my comments in the channel above over the weekend about the c-m) | 19:48 |
| vorlon | doko: anyway, it now shows up in c-m in the other direction, so I'm happily demoting it again | 19:48 |
| -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-460 [source] (hirsute-proposed) [460.73.01-0ubuntu1] | 19:51 | |
| -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-450 [source] (hirsute-proposed) [450.119.03-0ubuntu1] | 19:56 | |
| -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-390 [source] (hirsute-proposed) [390.143-0ubuntu1] | 20:00 | |
| Eickmeyer | LocutusOfBorg: Ok, super! | 20:02 |
| Eickmeyer | LocutusOfBorg: You doing that or should I? | 20:02 |
| * vorlon grumps at libmd0 having to be pulled in at Priority: important just on account of some things using libbsd for strlcpy/strlcat | 20:03 | |
| vorlon | glibc should just implement those | 20:03 |
| -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-460-server [source] (hirsute-proposed) [460.73.01-0ubuntu1] | 20:03 | |
| vorlon | ahasenack: if you reinstall the *old* shim binary, what effect does that have on your boot? | 20:05 |
| -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-450-server [source] (hirsute-proposed) [450.119.03-0ubuntu1] | 20:07 | |
| -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-418-server [source] (hirsute-proposed) [418.197.02-0ubuntu1] | 20:09 | |
| ahasenack | vorlon: I did an apt --reinstall of all grub packages, which ran grub-install again, and that broke the boot again | 20:09 |
| vorlon | ahasenack: ok, but I'm talking about a downgrade of shim-signed? | 20:10 |
| ahasenack | ah, sorry, missed you meant a downgrade | 20:10 |
| ahasenack | let me see if it's still available in the archive | 20:10 |
| ahasenack | if not, grab the focal one I guess | 20:10 |
| vorlon | ahasenack: it'll be available in groovy or focal yes | 20:10 |
| vorlon | (shim-signed doesn't change much ;) | 20:10 |
| ahasenack | so there are 3 shim packages | 20:10 |
| ahasenack | all of them? | 20:10 |
| ahasenack | shim, shim-canonical-unsigned, shim-signed | 20:11 |
| vorlon | shim-signed is the only one that matters, but it'll pull old shim as a dependency | 20:11 |
| vorlon | anyway, if you get the same behavior with the previous shim then that points to this being some issue with nvram as previously speculated and not a regression with new shim | 20:12 |
| vorlon | if the old shim DOES boot then I'd want to take a look at the tail end of your debug output (photo of the screen or whatever) | 20:12 |
| ahasenack | vorlon: so I did this: https://pastebin.ubuntu.com/p/jbX5JRHnVB/ | 20:21 |
| ahasenack | and now my boot is stuck at some sort of --version information, it just says | 20:22 |
| ahasenack | UEFI SHIM | 20:22 |
| ahasenack | $Version: 15 $ | 20:22 |
| ahasenack | $BuildMachine: .... $ | 20:22 |
| ahasenack | $Commit: ..... $ | 20:22 |
| ahasenack | the "..." are not literal, of course | 20:22 |
| ahasenack | if this is what was happening before, I can't tell, bceause the screen was black before | 20:24 |
| -queuebot:#ubuntu-release- Unapproved: cloud-init (hirsute-proposed/main) [21.1-19-gbad84ad4-0ubuntu2 => 21.1-19-gbad84ad4-0ubuntu3] (core, ubuntu-cloud) | 20:27 | |
| bdmurray | ahasenack: Is some of that output because the shim verbose change is still in place? | 20:27 |
| ahasenack | not sure, it was very verbose before, 4 minutes of scrolling text | 20:28 |
| ahasenack | this time, just that banner, and stuck | 20:28 |
| ahasenack | bdmurray: I still see the SHIM_VERBOSE-* in /sys/firmware/efi, so I guess yes | 20:31 |
| Odd_Bloke | If someone could reject the Unapproved cloud-init in hirsute, I'd appreciate it: I uploaded from the wrong branch so it's subtly wrong. | 20:34 |
| Odd_Bloke | (That won't burn the version number AIUI?) | 20:34 |
| bdmurray | That's true no burning will happen | 20:34 |
| -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (hirsute-proposed) [21.1-19-gbad84ad4-0ubuntu3] | 20:38 | |
| LocutusOfBorg | Eickmeyer, done! | 20:49 |
| -queuebot:#ubuntu-release- Unapproved: recordmydesktop (hirsute-proposed/universe) [0.4.0-0ubuntu1 => 0.4.0-1] (kubuntu) (sync) | 20:50 | |
| -queuebot:#ubuntu-release- Unapproved: update-notifier (hirsute-proposed/main) [3.192.40 => 3.192.41] (ubuntu-desktop, ubuntu-server) | 20:58 | |
| -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (hirsute-proposed/main) [2.718 => 2.719] (desktop-core, i386-whitelist) | 20:59 | |
| sil2100 | vorlon, bdmurray: hey! So apparently, we have a 'blocker' regarding the raspi images as flagged by CE - we thought we fixed it but we forgot about something very important | 21:00 |
| bdmurray | sil2100: okay | 21:00 |
| sil2100 | So the story is: we use the raspi seeds for raspi desktop images, and we have raspi server seeds for the server image as well that we should have used | 21:00 |
| bdmurray | Why is blocker in ''? Is that like air quotes? | 21:00 |
| sil2100 | And we thought we did | 21:00 |
| Eickmeyer | LocutusOfBorg: Awesome, thanks! | 21:01 |
| sil2100 | But the truth is, we actually never enabled the raspi server seeds in our server pi images, so none of the seed changes waveform did recently had any effect | 21:01 |
| sil2100 | And to fix USB ethernet devices and GPIO permissions, we need to pull in ubuntu-raspi-settings for server | 21:02 |
| sil2100 | We have two options: | 21:02 |
| sil2100 | a) Start using the raspi seeds as we were supposed to and have those pull in all the required pi deps | 21:02 |
| sil2100 | b) Hack livecd-rootfs to just install the required dependency to make things work | 21:02 |
| waveform | (the required dependency being the fairly trivial ubuntu-raspi-settings package) | 21:03 |
| sil2100 | So a) is the correct solution, but it's risky on release week. We never used the raspi-server seed so far, it requires changing the livecd-rootfs build logic a bit and I'm a bit worried it might backfire, as every release-week rushed in fix | 21:03 |
| sil2100 | So I pushed b) to the queue, which is just an one line change to pull in ubuntu-raspi-settings | 21:03 |
| sil2100 | If anyone strongly thinks we should just do a), I'm also fine with that, it's just that things like these so late in the cycle can backfire | 21:04 |
| sil2100 | vorlon, bdmurray: ^ what do you guys think? | 21:05 |
| bdmurray | I'm +1 with b | 21:05 |
| sil2100 | The sad thing about b) is that we should have had a) since start of hirsute - but I feel it's safer to just stick what we have and know that doesn't explode | 21:06 |
| sil2100 | It's not like a) is risky, it's also quite a trivial change, but it changes a bit how we'd be building the images | 21:07 |
| sil2100 | *is super risky | 21:07 |
| -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (hirsute-proposed) [2.719] | 21:22 | |
| sil2100 | o/ | 21:54 |
| vorlon | ahasenack: thanks. Can you post that information to the bug report as well, if you haven't already? I think that's sufficient to establish that this is not a regression caused by the new shim and therefore not a release blocker | 21:55 |
| sil2100 | bdmurray, vorlon: pushed an unblock for livecd-rootfs ^ | 22:15 |
| sil2100 | ...and going EOD now o/ | 22:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!