[00:00] -queuebot:#ubuntu-release- Unapproved: ncbi-blast+ (groovy-proposed/universe) [2.10.1-2 => 2.10.1-3] (no packageset) (sync)
[00:01] -queuebot:#ubuntu-release- Unapproved: accepted ncbi-blast+ [sync] (groovy-proposed) [2.10.1-3]
[00:01] -queuebot:#ubuntu-release- Unapproved: python-biopython (groovy-proposed/universe) [1.77+dfsg-3 => 1.78+dfsg-3] (no packageset) (sync)
[00:01] -queuebot:#ubuntu-release- Unapproved: accepted python-biopython [sync] (groovy-proposed) [1.78+dfsg-3]
[00:14] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64+raspi [Groovy Final] has been updated (20201020.2)
[00:27] <vorlon> ^^ arm64+raspi successfully rebuilt and ready for testing
[00:29] <amurray> hmm so I accidentally published this freetype update to groovy-security - should that go to release or is it fine to sit in -security since we are so close to release?
[03:30] <bdmurray> given that it is seeded on most live media and we are so close to release I think letting it sit there is best
[03:47] <plars> swapfile seems to work fine now on pi-desktop
[04:10] <amurray> bdmurray: ok no worries
[05:52] -queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (groovy-proposed/multiverse) [6.1.14-2 => 6.1.16-1] (no packageset) (sync)
[05:52] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [sync] (groovy-proposed) [6.1.16-1]
[06:23] -queuebot:#ubuntu-release- Unapproved: virtualbox (groovy-proposed/multiverse) [6.1.14-dfsg-4 => 6.1.16-dfsg-1~build1] (ubuntu-cloud)
[06:35] <LocutusOfBorg> sigh ^^
[06:39] <LocutusOfBorg> if possible to grab the 6.1.16-dfsg-1 from sid even better :(
[06:39] <LocutusOfBorg> there are few fixes in 3d host/guest and kernel side...
[06:39] <LocutusOfBorg> we really should have them
[07:04] <sil2100> o/
[08:27] <seb128> I've uploaded a language-pack-he fix, the change is a gnome-desktop translation update to fix the clock being inverted in hebrew (https://launchpadlibrarian.net/502434781/%D7%A6%D7%99%D7%9C%D7%95%D7%9D%20%D7%9E%D7%A1%D7%9A%20%D7%9E%D6%BE2020-10-17%2018-59-26.png)
[08:27] <seb128> (I basically copie the fix from -base with the fix from https://gitlab.gnome.org/GNOME/gnome-desktop/-/commit/4db3e5d9 applied on top)
[08:28] <seb128> it might be something nice to fix in the release, unsure if that langpack is on any ISO, otherwise 0 day SRU
[08:28] <seb128> hum also unsure why the bot didn't pick up the upload
[08:28] <seb128> but I also didn't get an email for it (but it's in the queue so it worked)
[08:28] <seb128> probably some issue on the launchpad side of things?
[08:29] <handsome_feng> Hi, Is it possible for someone in ubiquity-slideshow team to review this before groovy release:  https://code.launchpad.net/~feng-kylin/ubiquity-slideshow-ubuntu/ubuntukylin-groovy/+merge/391419 ? It only affect two strings.
[08:30] <seb128> handsome_feng, I could merge and upload, but I'm unsure the release team are wanting to accept an update to that package since it would mean respinning ISOs
[08:31] <seb128> also it would invalid translations
[08:31] <seb128> I'm not in the release team though so I'm going to let them +1 or -1, just feel free to ping me in you needed an uploader
[08:35] <handsome_feng> seb128: Thanks! So, hi, release team, what your opinion? And If we can't make it to this release, can I update this after release by SRU?
[08:37] <seb128> handsome_feng, there is no much point updating the installer slides in a SRU since they are only shown on the ISO...
[08:38] <handsome_feng> Okay, Got it. :(
[08:41] <handsome_feng> seb128: BTW,  Do you know how can I join the ubiquity-slideshow team? I sent an email, but no response yet.
[08:41] <seb128> handsome_feng, no idea sorry
[08:42] <handsome_feng> seb128:  Thank you anyway!
[08:43] <Laney> we probably need a new administrator for that ... https://launchpad.net/~ubiquity-slideshow/+members
[08:43] <Laney> does anybody know that person?
[08:48] <Laney> handsome_feng: it would mean rebuilding all of the ISOs that have the slideshow on, which is not planned this late, but we can pick it up if we need to do a respin for another reason
[08:49] <handsome_feng> Laney: That's fine, thank you very much!
[08:49] -queuebot:#ubuntu-release- Unapproved: pulseaudio (groovy-proposed/main) [1:13.99.2-1ubuntu1 => 1:13.99.2-1ubuntu2] (core, i386-whitelist)
[08:49] <Laney> sorry for missing it, I know I don't get emails for reviews on this project (:
[08:49] <Laney> :(*
[08:51] <juliank> Hey folks, we have a regression in shim-signed in groovy that breaks multi-esp installs (supported by subiquity) and DKMS modules - 1.41 never included the changes from 1.40.* which fixed those
[08:51] <juliank> Because 1.41 was earlier than 1.40.x due to the shim revert
[08:52] <juliank> so we reverted focal from 1.41 to 1.40 and kept going, but groovy continued on with 1.41, and lost all changes from focal
[08:52] <juliank>  Pass --timeout -1 to mokutil in a separate mokutil run (LP: #1869187)
[08:52] <juliank> Install grub to multiple ESPs (LP: #1871821)
[08:52] <juliank> Depend on the correct version of grub-signed (LP: #1871895)
[08:55] <juliank> So, I'd just merge the focal branch into groovy and copy the changelog entries with the relevant bug numbers for groovy to the top entry
[08:55] <juliank> But does this need a respin after?
[08:56] <juliank> I don't know
[08:56] <juliank> should it be 0day sru?
[08:56] <juliank> If it's a 0day SRU, chances are subiquity multiple ESP installs are broken, though not sure
[08:56] <juliank> probably it's fine
[08:58] <Laney> juliank: We need it on the media I think, ubiquity can integrate with this
[08:58] <juliank> on it
[08:58] <handsome_feng> Laney: It's my fault, I just sent the email yesterday, I should have been on the irc earlier.
[08:59] <Laney> handsome_feng: looks like you might be lucky ;-)
[08:59] <handsome_feng> \o/
[09:04] <juliank> Laney: uploaded
[09:05] -queuebot:#ubuntu-release- Unapproved: shim-signed (groovy-proposed/main) [1.44 => 1.45] (core)
[09:05] <juliank> I only have myself to blame :/
[09:06] <juliank> I'd mark bug 1899678 as a duplicate of bug 1869187
[09:07] <juliank> But oh well, we don't know for sure it's the same bug, but it's very unlikely to be not
[09:07] <juliank> :D
[09:09] <handsome_feng> seb128: Hi, Could you merge and upload the changes? Since we get a chance that all the iso might be respin.
[09:13] <seb128> handsome_feng, k
[09:14] <handsome_feng> <&
[09:14] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (groovy-proposed) [1.45]
[09:19] -queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (groovy-proposed/main) [162 => 163] (ubuntu-desktop)
[09:20] <seb128> Laney, handsome_feng ^
[09:20] <Laney> thank you!
[09:20] <seb128> np!
[09:23] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (groovy-proposed) [163]
[09:27] <handsome_feng> Thank you, guys. \o/
[09:30] <sil2100> yw!
[09:32] <seb128> handsome_feng, you are going to have those strings in english and not chinese though, I guess that's ok?
[09:32] <seb128> handsome_feng, if you want to avoid that issue next time you can update the zh translation in the same merge request at least
[09:32] <handsome_feng> It's ok! It's better than wrong strings
[09:33] <seb128> right
[09:35] <handsome_feng> seb128: Got it! I didn't update the zh translation this time because those would been overwritten by the translation on launchpad.
[09:36] <seb128> handsome_feng, on the next export manually imported right? if would have been enough for that upload as a temporary thing
[09:36] <seb128> you should still do translate on launchpad as well in those cases
[09:38] <handsome_feng> OK
[09:45] <seb128> whoever is maintaining https://xubuntu.org/release/20-04/ , the torrent url needs to be updated for .1 , it's currently a notfound
[09:46] <seb128> I should probably mention that on #xubuntu
[09:53] <juliank> Laney: I just realized I never uploaded the apt that changed focal to groovy in the docs
[09:54] <juliank> which people will get angry about
[09:54] <Laney> hm?
[09:54] <juliank> Laney: The docs and example sources.list say focal but should say groovy
[09:55] <juliank> Laney: And customers copy those examples into their sources.list and break their systems :D
[09:56] <sil2100> Is that an apt upload then?
[09:56] <juliank> So I'm releasing 2.1.11 now which has that change, a "fix" for LP#1871268 (turns error into warning), a typo fix and a translation update
[09:56] <juliank> But I think we can SRU that
[09:56] <juliank> It doesn't have to be in the release pocket
[09:57] <sil2100> Yeah, apt feels like not the best thing right now
[09:57] <sil2100> So +1 on SRUing
[09:57] <juliank> Do we want SRU bugs for them all, or given that the other is just small stuff, are we fine just using bug 1871268?
[09:59] <juliank> I don't think we need an SRU bug for the translation update, the typo fix and the s/focal/groovy/
[09:59] <juliank> Seems like a waste of paperwork :)
[10:10] <juliank> oh ffs
[10:11] <juliank> I typed in launchpad for 10 or 20 mins and hit a wrong key combo and it's all gone
[10:11] <juliank> Oh I hit Esc
[10:11] <juliank> Because I mapped CapsLock to Esc
[10:18] <sil2100> juliank: I guess maybe all in one SRU bug? Since it's nice to have something for tracking at least
[10:18] <juliank> sil2100: I've added SRU info about squashed changes to bug 1871268 in a [Groovy SRU] section
[10:20] <juliank> Someone ought to add this to beta testing
[10:20] <juliank> "Check that /usr/share/doc/apt/examples/sources.list points to the correct Ubuntu release"
[10:23] <sil2100> \o/
[10:26] <juliank> fakesynced it for reviewability :)
[10:26] -queuebot:#ubuntu-release- Unapproved: apt (groovy-proposed/main) [2.1.10 => 2.1.11] (core, i386-whitelist)
[10:29] <juliank> groovy will be tracking unstable for a bit, but it's not clear for how long
[10:29] <juliank> at some point we'll have changes not worth SRUing
[11:24] <Laney> sil2100: good to respin now I think
[11:31] <sil2100> o/
[11:32] <sil2100> SPINNING
[11:50] <LocutusOfBorg> Laney, is it possible to accept virtualbox, seeded in ubuntu-cloud?
[11:50] <LocutusOfBorg> I know its meh :/
[11:50] <LocutusOfBorg> but the new release fixes some 3d acceleration issues and resize screen that we should have in the iso, if there
[11:55] <juliank> new upstream releases? that sounds like a lot
[11:55] <juliank> sounds more like an SRU to me
[11:57] <LocutusOfBorg> the diff is trivial, kernel fixes, 3d fixes, patches merged, end
[11:58] <Laney> in the iso, why?
[11:58] <LocutusOfBorg> oh, virtualbox is not part of the iso anymore, right?
[11:59] <LocutusOfBorg> because that "(ubuntu-cloud)" means nothing, wrt respins?
[11:59] <LocutusOfBorg> (this is a mistake I do exactly twice a year :p )
[11:59] <Laney> it's a packageset
[12:01] <Laney> but I'm thinking SRU still, no time to fix any regressions if you introduce them with this
[12:01] <Laney> and after final freeze basically everything should be SRU-level anyway
[12:02] <LocutusOfBorg> mmm but the guest-additions is already migrated, as well as the -hwe
[12:02] <LocutusOfBorg> so, we are left with vbox and the ext-pack, but we will have inconsistencies between host and guest...
[12:12] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Groovy Final] has been updated (20201021)
[12:13] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Groovy Final] has been updated (20201021)
[12:15] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Groovy Final] has been updated (20201021)
[12:18] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Groovy Final] has been updated (20201021)
[12:18] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Groovy Final] has been updated (20201021)
[12:18] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Groovy Final] has been updated (20201021)
[12:18] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Groovy Final] has been updated (20201021)
[12:20] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Groovy Final] has been updated (20201021)
[12:20] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Groovy Final] has been updated (20201021)
[12:23] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Groovy Final] has been updated (20201021)
[12:25] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Groovy Final] has been updated (20201021)
[12:35] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Groovy Final] has been updated (20201021)
[12:40] -queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.32 => 1:2.11+dfsg-1ubuntu7.33] (ubuntu-server, virt)
[12:40] -queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.46 => 1:2.5+dfsg-5ubuntu10.47] (ubuntu-server, virt)
[12:41] -queuebot:#ubuntu-release- Unapproved: qemu (focal-proposed/main) [1:4.2-3ubuntu6.7 => 1:4.2-3ubuntu6.8] (ubuntu-server, virt)
[12:42] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64+raspi [Groovy Final] has been updated (20201021)
[12:52] <handsome_feng> popey: Hi, I'm one of the leader of Ubuntu Kylin, could you give me write access to the release note post? Then I can modify the release note's link of Ubuntu Kylin.
[12:55] <handsome_feng> Discourse account name: handsome_feng       mail: jianfengli@ubuntukylin.com
[13:07] <patviafore> sil2100: regarding cloud images, our plan is to make a build late US time today, check in with you tomorrow for any respins (building again if necessary), wait for your +1 and release
[13:09] <sil2100> patviafore: sounds like a plan, thanks!
[13:12] <plars> sil2100: was the pi-desktop rebuild for today intentional? any idea what changed from the 20201020.2 image I saw last night?
[13:14] <sil2100> plars: hey! Yes, we rebuilt it since there was a new slideshow that got accepted
[13:15] <sil2100> No relevant changes really
[13:15] <plars> sil2100: ok, I'll try it still, just wondering if there was anything else I should pay close attention to
[13:21] -queuebot:#ubuntu-release- Unapproved: accepted python3.9 [source] (focal-proposed) [3.9.0-5~20.04]
[13:27] <jibel> plars, here is what changed https://discourse.ubuntu.com/t/20-10-release-candidate-isos-ready-for-testing/18894/4
[13:29] <plars> jibel: ah, I think I'm subscribed to the release one but not this, thanks for pointing it out
[13:30] <Laney> 👍 useful post
[14:05] <bdmurray> juliank: can you add something to https://wiki.ubuntu.com/BetaProcess about apt doc updates?
[14:10] <juliank> bdmurray: Someone has to figure out which of those days :D
[14:10] <juliank> minus 7?
[14:10] <juliank> minus 10?
[14:10] <juliank> I don't know
[14:10] <juliank> We can also do it earlier
[14:10] <juliank> It really should happen during archive opening, I suppose
[14:10] <juliank> s/during/after/
[14:11] <bdmurray> Then put it here! https://wiki.ubuntu.com/NewReleaseCycleProcess
[14:11] <bdmurray> Or is it similar to "Update /usr/share/python-apt/templates/Ubuntu.info in python-apt to include the new release name."
[14:12] <Laney> could it be de-hardcoded so it's figured out at build time?
[14:12] <Laney> then it'd only be a problem if we manage to go a whole cycle without uploading apt ...
[14:20] <juliank> Laney: I don't know, I guess
[14:22] <coreycb> @bdmurray I've added SRU sections for the ceph bug. sorry I didn't realize that got backported to focal.
[14:22] <coreycb> bdmurray: ^
[14:25] <coreycb> hello, please can an archive admin promote python3-octavia-lib to main? that will unblock ovn-octavia-provider from groovy-proposed. the corresponding MIR has received a security team ack. https://bugs.launchpad.net/bugs/1864666
[14:25] <plars> sil2100: waveform: one thing I did just notice - sound defaults seem to be different on pi-desktop. With the server image, it seems to default to whichever hdmi is plugged in, and I can reconfigure using .asoundrc for headphones. On desktop it seems to default to headphones even if they are not plugged in
[14:25] <waveform> plars, yup - I've got that in the release notes pointing to the relevant bug
[14:26] <waveform> (nearly done writing - should have them done in a few minutes)
[14:26] <bdmurray> coreycb: Do you have anything we could add to https://discourse.ubuntu.com/t/groovy-gorilla-release-notes/15533 for openstack?
[14:26] <Laney> waveform: I wrote a short sentence about the new pi desktop image, don't know if you want to expand that and also I don't know what the right link to the rasperry pi imager is.
[14:26] <plars> waveform: ok, good, I couldn't find a bug for it yet but I thought I'd check to make sure
[14:26] <coreycb> bdmurray: yes, I've been meaning to do that. I'll do that now.
[14:27] <Laney> waveform: Or maybe there's going to be a proper page on ubuntu.com which we should link to there instead?
[14:27] <waveform> Laney, I've written a quick post about installation here: https://waldorf.waveform.org.uk/2020/boot-configuration-with-pibootctl.html - I think Rhys is organizing something for ubuntu.com ?
[14:30] <Laney> waveform: ok, I asked Rhys
[14:32] <Laney> coreycb: there's no ack on octavia itself yet, is that ok?
[14:32] <coreycb> Laney: yes we can hold off on that MIR until next release
[14:32] <Laney> alright
[14:32] <coreycb> thanks Laney
[14:56] -queuebot:#ubuntu-release- Unapproved: netplan.io (focal-proposed/main) [0.100-0ubuntu4~20.04.2 => 0.100-0ubuntu4~20.04.3] (core)
[15:01] -queuebot:#ubuntu-release- Unapproved: openjdk-13 (groovy-proposed/universe) [13.0.4+8-1 => 13.0.5+3-2ubuntu1] (i386-whitelist)
[15:03] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-13 [source] (groovy-proposed) [13.0.5+3-2ubuntu1]
[15:14] <xnox> apw:  https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-455 how come this migrated; and yet we don't have lrm modules built for 455?
[15:14] <waveform> sil2100, updated release notes; plars, the issue for the incorrect audio device selection is LP: #1899962 which is now in the release notes
[15:15] <xnox> apw:  didn't the monday kernel respin, build lrm for 455 nvidia?
[15:20] -queuebot:#ubuntu-release- Unapproved: openjdk-15 (groovy-proposed/universe) [15+36-1 => 15.0.1+9-0ubuntu1] (i386-whitelist)
[15:20] <xnox> sforshee:  are you online?
[15:22] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-15 [source] (groovy-proposed) [15.0.1+9-0ubuntu1]
[15:22] <xnox> fginther:  are you online?
[15:23] <sil2100> waveform: thank you!
[15:23] <xnox> one way for us to fix this is to remove nvidia-graphics-drivers-455 from the archive
[15:23] <fginther> xnox, yes I am
[15:25] <sforshee> xnox: yes
[15:33] <xnox> sforshee:  tah, fginther is quicker. Shipping nvidia-graphics-drivers-455 without matching lrm; breaks ubiquity installer =( cause it picks the highest one, instead of picking the highest one WITH lrm =) hence we are removing 455 from release; and publish it into -proposed; you can publish 455 into groovy-updates;
[15:33] <xnox> once there is matching lrm for 455 with the next kernel sru.
[15:35] <sforshee> ack, I wasn't even aware that a -455 driver had landed
[15:36] <sforshee> tseliot: ^
[15:37] <tseliot> sforshee, yes, I am aware of the problem. The 455 series doesn't replace any other series, so that the l-r-m are not broken. Of course, then, things break with secureboot
[15:38] <xnox> tseliot:  issue is that we automatically included 455 on the iso; and during ubiquity isntallation ubuntu-drivers picked to install 455 driver as the best one; despite it having only dkms module provider, and not lrm one.
[15:39] <xnox> tseliot:  see https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1900870 i think ideally we should prefer to install the driver that is highest with lrm; and if none found, then prefer highest dkms one.
[15:40] -queuebot:#ubuntu-release- Unapproved: virtualbox (groovy-proposed/multiverse) [6.1.14-dfsg-4 => 6.1.16-dfsg-1] (ubuntu-cloud) (sync)
[15:40] <tseliot> xnox, yes, I can implement that, so that drivers with the lrm sort before the dkms ones
[15:40] <xnox> tseliot:  hence out of the box ubiquity 3rd party drivers is broken on nvidia =( anyway, removing 455 from the archive which can come in ubuntu-updates later.
[15:40] <xnox> tseliot:  tah, but for next cycle.
[15:40] <tseliot> ok
[15:41] <xnox> sforshee:  so 455 landed on the 10-14; and kernel rebuild was done on 10-15 => not sure about timezones though, i doubt that the people who kicked kernel rebuild knew about 455 at the same time.
[15:42] <tseliot> xnox, no, that was intentional on my side. I can't share the reasoning behind it here.
[15:42] <xnox> horum.
[15:49] <tseliot> xnox, making ubuntu-drivers prefer the LTS driver (450) over the NFB (455) would also do it. That's a very easy change to make.
[15:50] <xnox> tseliot:  no, as it will need respinning squashfs of all the live .isos which takes a long time. and affects more flavours.
[15:51] <xnox> tseliot:  by removing 455, we can respin /pool/ directory of 5 flavours only to fix things; without rebuilding the full squashfs even. as the nvidia debs are only in the iso /pool/ and not in the live session at all.
[15:51] <tseliot> ok
[15:53] <xnox> tseliot:  i mean we should probably do both; as ubuntu-drivers change will be useful when you upload 460 =)
[15:54] <xnox> as this removal juggling is one off fix to ship groovy.
[15:54] <xnox> tseliot:  but no need to stay up over this; can land ubuntu-drivers next week or whatever.
[15:55] <Laney> yes, it should be SRUed
[15:55] <tseliot> xnox, ok. We will be losing support for the new NVIDIA Ampere architecture without 455
[15:55] <Laney> it can go back in via -updates as soon as either LRM exists or the ubuntu-drivers fixes are uploaded
[15:57] <Laney> (and accepted :p)
[15:57] <xnox> tseliot:  until the next kernel sru.... yes. Do a nochange kernel rebuild, with lrm with 455 and release to updates this week.
[15:57] <tseliot> xnox, I don't think we can do this. sforshee ^^
[15:57] <xnox> tseliot:  it's not like you are gonna gain support for that architecture with secureboot anyway without lrm =) since nobody knows how to do mok.
[15:58] <tseliot> xnox, doesn't dkms enroll its own key these days?
[15:58] <xnox> tseliot:  it needs user interaction on reboot...... lrm ones just modprobe
[15:59] <tseliot> oh, ok
[16:02] <xnox> tseliot:  yeah, if we can't have lrm soon => then ubuntu-drivers might be a quicker
[16:02] <xnox> way to publish 455 back into updates.
[16:08] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Groovy Final] has been updated (20201021.1)
[16:08] <tseliot> xnox, yes, that's what I was thinking
[16:12] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Groovy Final] has been updated (20201021.1)
[16:13] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Groovy Final] has been updated (20201021.1)
[16:15] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Groovy Final] has been updated (20201021.1)
[16:17] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Groovy Final] has been updated (20201021.1)
[16:48] <coreycb> popey: may I have access to the groovy release notes to update them for openstack?
[16:57] <jibel> xnox, verified with 20201021.1 and 450 + corresponding lrm are installed
[17:07] <vorlon> Laney: I see you processed LP: #1867813; fwiw you missed promoting the source package.  You generally want the '-S' option to change-override
[17:08] <xnox> jibel:  whoop whoop
[17:31] <sil2100> \o/
[17:41] <Laney> vorlon: cheers
[18:29] <mwhudson> good morning how on fire are things today?
[18:31] <Laney> small flames
[18:31] <Laney> nice to keep your hands warm
[18:31] <sil2100> A thousand little respins
[18:32] <Laney> continuous delivery right
[18:33] <Laney> Trevinho: will you be around in ~1h to retest?
[18:33] <Trevinho> Laney: yeah
[18:33] <mwhudson> every week should be release week!
[18:34] <Laney> Trevinho: cool, look out for a notification from queuebot
[18:35] <Laney> I guess it would be helpful to do offline and online unless jibel comes back :>
[18:38] <Laney> bdmurray: sil2100: just double checking that someone notified the flavours of this respin
[18:38] <Laney> (not waiting for the response though, consider this a poke :P)
[18:38] <Laney> see ya
[18:38] <bdmurray> I did
[18:51] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Groovy Final] has been updated (20201021.2)
[18:54] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Groovy Final] has been updated (20201021.2)
[19:02] <bdmurray> Trevinho: ^
[19:02] <Trevinho> thanks
[19:02] <bdmurray> thank you for testing!
[19:06] <vorlon> xnox: should initramfs-tools-devices be removed from the archive in groovy?
[19:06] <vorlon> xnox: it currently wants demoting because initramfs-tools-ubuntu-core is removed; but if initramfs-tools-ubuntu-core is removed I'm not sure why we still want it at all in groovy
[19:07] <vorlon> abeato: ^^ perhaps you would be a better person to answer
[19:08] <abeato> vorlon, well, we have used it some times for resizing of the rootfs on first boot - not sure if there is an alternative
[19:10] <abeato> vorlon, we use it on classic, not UC
[19:16] <popey> coreycb done
[19:22] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Groovy Final] has been updated (20201021.2)
[19:25] <xnox> vorlon:  it should die.
[19:28] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Groovy Final] has been updated (20201021.2)
[19:34] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Groovy Final] has been updated (20201021.2)
[19:35] <plars> bdmurray: did you want to put some sort of testcase on isotracker for Ubuntu Desktop arm64+raspi? I don't think we can log that anything was tested on it unless there's something there
[19:40] <bdmurray> plars: Is there some template we could copy over?
[19:40] <bdmurray> plars: I haven't tried the image myself
[19:44] <Odd_Bloke> vorlon: Is it expected that http://cdimage.ubuntu.com/ubuntu-base/releases/18.04.3/release/ will only contain the .5 files (rather than redirecting or 404ing)?
[19:46] <plars> bdmurray: Well, I wouldn't copy over the desktop tests, because most of them wouldn't apply since they focus on ubiquity (pi desktop more like a preinstall image with oem-config to set up lang, tz, user, etc). In the interest of time, it may make more sense to just have an entry for rpi4b 4G and 8G. I know there are people trying it out, would just be good to have a place to log it rather than leave
[19:46] <plars> you wondering whether anyone tried it or not when making the release
[19:46] <bdmurray> Odd_Bloke: what are you doing snooping around in our cupboards
[19:51] <Odd_Bloke> bdmurray: Answering questions for users in #ubuntu-server. :p
[19:57] <Trevinho> bdmurray: confirm working now!
[19:57] <bdmurray> Trevinho: right on
[19:57] <bdmurray> plars: here you go http://iso.qa.ubuntu.com/qatracker/milestones/418/builds/222055/testcases
[19:58] <vorlon> Odd_Bloke: well, it's not ideal to have an 18.04.3 that doesn't point to 18.04.3 objects.  https://lists.ubuntu.com/archives/ubuntu-release/2020-October/005113.html for context
[19:59] <vorlon> I also wonder why we didn't do an 18.04.6 for ubuntu-base, since AFAIK the 18.04.5 misses the apt security fix
[19:59] <vorlon> abeato: so you're using it in classic images based on releases later than 20.04?
[20:00] <vorlon> (or expect that you will do)
[20:33] -queuebot:#ubuntu-release- Unapproved: google-osconfig-agent (groovy-proposed/universe) [20200625.00-0ubuntu2 => 20200625.00-0ubuntu3] (no packageset)
[20:33] <rbalint> ^later SRU or punting to h*
[20:34] <rbalint> not super urgent but would be nice to have
[20:34] -queuebot:#ubuntu-release- Unapproved: accepted google-osconfig-agent [source] (groovy-proposed) [20200625.00-0ubuntu3]
[21:14] -queuebot:#ubuntu-release- Unapproved: resource-agents (focal-proposed/main) [1:4.5.0-2ubuntu2 => 1:4.5.0-2ubuntu2.1] (ubuntu-server)
[21:18] <plars> sil2100: waveform: heads up, new regression found for rpi - lp#1900904
[21:20] <waveform> plars, hmm, that's a consequence of us getting rid of net.ifnames=0; I'll release note it for now
[21:22] <plars> waveform: ack
[21:22] <plars> waveform: it should have still caught it without the driver restriction in the netplan yaml though, shouldn't it?
[21:23] <waveform> I don't think so - I think the way it's configured at the moment I'd need an *additional* section to deal with "other" ethernet interfaces
[21:23] <waveform> (optional obviously)
[21:24] <vorlon> do we really have to be using set-name >_<
[21:25] <waveform> without that, on the most common model Bs we wind up with wlan0 and enxMACMACMAC which is ... incongruous to say the least
[21:25] <vorlon> right
[21:25] <waveform> I agree it's hacky though
[21:25] <vorlon> so yes, you'd want another section, for the case of drivers where you don't intend to rename the interface
[21:26] <plars> waveform: interesting side-note - since we override the cloud-init data for creating the default user in automated provisioning (but we don't touch anything network related), we don't see this happen there. I only saw this when booting fresh with a local device and nothing added. When we add the extra cloud-init bits to create a user, it seems to generate something that IDs it by mac
[21:26] <waveform> plars, yup - that's the "default" configuration - unfortunately that configuration also breaks the "move your SD card between pis" use-case
[21:27] <plars> indeed
[21:31] <sil2100> waveform, plars: thanks for the heads-up guys o/
[23:08] <sil2100> bdmurray: hey! Did you try chasing down the pulseaudio guys regarding LP: #1897934 ?
[23:12] <sil2100> I'm a bit angry at myself, how did I miss this on my radar
[23:13] <bdmurray> sil2100: I have not, steve suggested desktop.
[23:14] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Groovy Final] has been marked as ready
[23:14] <Eickmeyer[m]> Might be premature but... ^
[23:15] <vorlon> sil2100: well, I think we need to work on making sure we have explicit tracking of the run-once tests at beta
[23:22] <sil2100> vorlon: agreed
[23:23] <sil2100> Anyway, maybe we should try reaching out to Kai-Heng Feng, or Hui Wang? Since I see they worked on pulseaudio uploads before
[23:23] <sil2100> They could start investigating before the desktop team wakes up
[23:24] <sil2100> Since otherwise we'll waste precious time in the morning, leaving us not so much time to respin and retest
[23:25] <vorlon> sil2100: I think this is going to just have to be release-noted, unless we want to slip the release.  It could be either a kernel regression or a pulseaudio regression, and either is going to take time to sort out
[23:28] <sil2100> I consider that a possibility, yes, but it is a accessibility regression, making it potentially harder for people with disabilities to install/test groovy
[23:28] <sil2100> Since I assume it might not always be trivial for them, in such case, to change the volume to make the sound appear
[23:29] <sil2100> So if there's a chance that someone can possibly figure this out before release still, I'd like to try
[23:29] <vorlon> yes. I'm not happy about it, I'm just trying to be realistic about our chances of fixing it in the next 24 hours
[23:29] <vorlon> sil2100: so certainly, reaching out to anyone who might be available to look into it is a good idea IMHO
[23:30] <sil2100> I'll send an e-mail and try to get things moving
[23:32] <vorlon> sil2100, xnox, bdmurray: opinions on https://code.launchpad.net/~vorlon/debian-cd/lp.1899615/+merge/392638 ?  it's a small change to restore the boot option; I don't think it warrants a respin, and I don't feel strongly that we should block the merge until after release
[23:51] <sil2100> vorlon: hm, no strong preference here - but maybe we could add that in case we respin the world (in the unlikely case of getting a fix for the audio issue)
[23:53] <sil2100> Ok, updated the status tracking post
[23:53] <sil2100> E-mail sent, not much we can do now but wait...
[23:53] <sil2100> I go to sleep in the meantime, see you tomorrow o/