[00:02] <xnox> vorlon:  https://paste.ubuntu.com/p/6jHRmjjwZ8/
[00:03] <xnox> vorlon:  i like 541, but i don't know how far back it exists.
[00:04] <xnox> and i guess xen doesn't matter as it should just work
[00:04] <xnox> if we do that, we will need not to do the cloud-init stuff either.
[00:05] <vorlon> xnox: I want to do https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/commit/?id=5bb3139fbef5b43b07146d3bfc951e4a0c2ff24e
[00:05] <vorlon> the cloud-init stuff will still matter for dist-upgrades
[00:05] <vorlon> which are unlikely in the cloud, but supported
[00:08] <xnox> vorlon:  i am confused.
[00:10] <xnox> vorlon:  i thought you meant https://paste.ubuntu.com/p/jd5c8p64Pd/
[00:10] <xnox> vorlon:  why would you want to ever run grub-install of grub-pc on upgrades?
[00:11] <vorlon> xnox: I want to fix the problem that a security update is borking you.  But as I said, in the general case, we do still /want/ to have the newer grub written to disk on upgrades, but because of the abi break it's prudent to limit it to release upgrades
[00:12] <xnox> we /want/ but cannot do so.
[00:12] <xnox> you will brick everyone on dist-upgrade then.
[00:12] <vorlon> this solves the present problem and kicks the can on the question of handling the failures on release upgrade due to abi changes
[00:12] <vorlon> xnox: we've already done that in the past
[00:12] <xnox> because this SRU has changed abi for everyone.
[00:12] <chrisccoulson> if grub-install is never executed when upgrading grub-pc, is there a risk of other parts that are upgraded going out of sync (eg, grub.cfg depending on new commands)
[00:13] <vorlon> yes there is
[00:13] <vorlon> or incompatible filesystem support
[00:13] <xnox> chrisccoulson:  update-grub is still called, using the new tooling.
[00:14] <vorlon> if you have old grub, and you do something to upgrade your filesystem, and you don't get new grub, you could also be sunk
[00:14] <xnox> vorlon:  i'd still want you to make your new case to be elif where i show mine.
[00:14] <vorlon> xnox: fair
[00:14] <chrisccoulson> xnox, yeah, that's an issue isn't it - calling update-grub with the new tooling without calling grub-install (not this time around, but maybe in a future update)
[00:16] <xnox> vorlon:  https://paste.ubuntu.com/p/k2Jqt5yWyg/ or some such. Makes it a lot easier to review / update / backport.
[00:17] <xnox> vorlon:  a vendor kept on asking if we will continue to support bios.
[00:17]  * xnox ponders
[00:17] <xnox> it's unsupportable already
[00:18] <vorlon> xnox: :P
[00:19] <vorlon> xnox: https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/388437
[00:19] <mwhudson> vorlon: test "$wubi_device" oh boy
[00:20] <vorlon> mwhudson: ignore ignore ignore
[00:20] <vorlon> lalalal
[00:20] <vorlon> a
[00:20] <sbeattie> haha, saw that too, and cried.
[00:21] <vorlon> mwhudson: I mean, aside from the fact that I need to fix the syntax ;)
[00:21] <vorlon> (done)
[00:21] <mwhudson> vorlon: oh i hadn't got as far as syntax yet :)
[00:21] <vorlon> mwhudson: yeah that was a mis-edit of the previous attemp
[00:21] <vorlon> t
[00:24] <mwhudson> vorlon: approvedz
[00:24] <mwhudson> vorlon: i presume you have similar changes for bionic, xenial?
[00:25] <mwhudson> and uh trusty?
[00:25] <vorlon> mwhudson: will do, with adjusted version numbers; but those are not in git I guess :/
[00:26] <mwhudson> yes i was assuming you'd remember the version numbers :)
[00:26] <mwhudson> and hm the branches start with disco it seems?
[00:26] <xnox> i am confused about "ge" still.
[00:26] <mwhudson> also bios is bad
[00:27] <vorlon> xnox: greater than or equal to the version in the release pocket
[00:27] <mwhudson> also also is there a bug for "pls to be not installing modules until after writing the mbr"
[00:28] <xnox> which means "any focal version" or "downgrade from groovy"
[00:28] <xnox> and screw downgrade people
[00:29] <vorlon> xnox: if you're downgrading, you're presumably on the other side of the ABI change
[00:29] <vorlon> at least for focal
[00:29] <xnox> this is safe in-series, ship it.
[00:29] <vorlon> ok
[00:35] <vorlon> bdmurray: around?
[00:36] <Bashing-om> vorlon: xnox: Confirmation: old AMD bios system - apt policy grub-pc >> Installed: 2.02-2ubuntu8.16
[00:36] <Bashing-om> No issues seen here.
[00:40] -queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.1 => 2.04-1ubuntu26.2] (core)
[00:49] -queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.142.3 => 1.142.4] (core)
[00:50] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.1] has been updated (20200730.1)
[00:50] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.1] has been updated (20200730.1)
[00:50] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.1] has been updated (20200730.1)
[00:50] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.1] has been updated (20200730.1)
[00:51] <bdmurray> vorlon: yeah
[00:53] <vorlon> bdmurray: grub2, grub2-signed in focal, I could use an SRU reviewer
[00:53] <vorlon> to keep me honest
[00:53] <bdmurray> okay
[00:53] <bdmurray> honesty is good
[00:55] <bdmurray> why does the debdiff look so weird?
[00:55] <vorlon> does it?
[00:55] <bdmurray> or the changelog specifically
[00:55] <vorlon> is it diffing against the wrong target?
[00:56] <vorlon> hmm
[00:56] <vorlon> I based this on the git branch which I assumed was up-to-date
[00:56] <vorlon> chrisccoulson: ^^
[00:56] <vorlon> bdmurray: please reject and I'll reupload
[00:56] <bdmurray> will do
[00:58] -queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (focal-proposed) [1.142.4]
[00:58] -queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (focal-proposed) [2.04-1ubuntu26.2]
[00:59] <vorlon> xnox: ^^ you synced the focal branch over?  somehow it doesn't contain the debian/2.04-1ubuntu26.1 tag and doesn't match the archive contents
[00:59] <chrisccoulson> oh, huh, I updated the changelog right before uploading the last version to add all of the CVE references, but didn't commit those to git
[00:59] <vorlon> ah
[00:59] <chrisccoulson> vorlon, the tag is missing because the 2.04-1ubuntu26.1 version was already used and tagged for a SRU that wasn't uploaded
[00:59] <vorlon> well
[01:00] <vorlon> nuke those tags from orbit
[01:00] <vorlon> :P
[01:00] <chrisccoulson> I thought I'd pushed the proper changelog (but just without the tag though)
[01:00] <mwhudson> NoMoreSourcePackages pls
[01:04] -queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.1 => 2.04-1ubuntu26.2] (core)
[01:04] <vorlon> bdmurray: ^^
[01:05] <chrisccoulson> yeah, that looks better :)
[01:11] <bdmurray> vorlon: looking
[01:18] <bdmurray> vorlon: so there will be a better upload coming and this is a stop gap?
[01:20] <vorlon> bdmurray: there will be further improvements to make grub-pc behave better on upgrades between releases
[01:24] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (focal-proposed) [2.04-1ubuntu26.2]
[01:24] <bdmurray> vorlon: where is the signed version? or should I rescue the old one
[01:25] <bdmurray> yeah that would make sense
[01:39] -queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.2 => 2.04-1ubuntu26.2] (core)
[01:48] <vorlon> bdmurray: the old grub2-signed is fine, yeah
[01:51] -queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.2 => 2.04-1ubuntu26.2] (core)
[01:51] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.16 => 2.02-2ubuntu8.17] (core)
[04:15] -queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.18 => 1.93.19] (core)
[04:21] -queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (bionic-proposed) [2.02-2ubuntu8.17]
[04:23] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.16 => 2.02-2ubuntu8.17] (core)
[04:28] -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.26 => 2.02~beta2-36ubuntu3.27] (core)
[04:42] -queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.26 => 1.66.27] (core)
[04:43] -queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (bionic-proposed) [2.02-2ubuntu8.17]
[04:48] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.16 => 2.02-2ubuntu8.17] (core)
[04:49] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.17]
[04:49] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu26.2]
[04:49] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu26.2]
[04:50] -queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (bionic-proposed) [1.93.19]
[04:51] -queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.18 => 1.93.19] (core)
[04:52] -queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.27]
[04:53] -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.26 => 2.02~beta2-36ubuntu3.27] (core)
[05:00] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.93.19]
[05:02] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.17 => 2.02-2ubuntu8.17] (core)
[05:04] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.27]
[05:04] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.27]
[05:05] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.17]
[05:08] <vorlon> mwhudson: still around at all?
[05:21] -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.27 => 2.02~beta2-36ubuntu3.27] (core)
[05:29] -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.27 => 2.02~beta2-36ubuntu3.27] (core)
[05:45] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.17 => 2.02-2ubuntu8.17] (core)
[05:45] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1021.21]
[06:18] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.17]
[06:21] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.27]
[06:21] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.27]
[07:31] -queuebot:#ubuntu-release- Unapproved: rejected mutter [source] (focal-proposed) [3.36.4-0ubuntu0.20.04.2]
[08:56] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.16]
[09:24] <LocutusOfBorg> can anybody please accept s390-tools from unapproved? needed for json-c transition
[09:27] <LocutusOfBorg> also, please kick ntopng out from release pocket? its bd uninstallable due to ndpi
[09:27] <LocutusOfBorg> out from debian testing
[09:43] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-440-server [i386] (bionic-proposed) [440.95.01-0ubuntu0.18.04.1]
[11:01] -queuebot:#ubuntu-release- New: accepted haskell-hgettext [amd64] (groovy-proposed) [0.1.31.0-7]
[11:02] -queuebot:#ubuntu-release- New: accepted haskell-hgettext [armhf] (groovy-proposed) [0.1.31.0-7]
[11:02] -queuebot:#ubuntu-release- New: accepted haskell-hgettext [riscv64] (groovy-proposed) [0.1.31.0-7]
[11:02] -queuebot:#ubuntu-release- New: accepted haskell-hgettext [arm64] (groovy-proposed) [0.1.31.0-7]
[11:02] -queuebot:#ubuntu-release- New: accepted haskell-hgettext [s390x] (groovy-proposed) [0.1.31.0-7]
[11:02] -queuebot:#ubuntu-release- New: accepted haskell-hgettext [ppc64el] (groovy-proposed) [0.1.31.0-7]
[11:20] <LocutusOfBorg> vorlon, with ntopng kicked out from release (we should keep it in proposed, so it builds once ndpi is fixed in debian and syncs), and the s390-tools accept from unapproved, json-c should be fine to go
[11:37] <xnox> mwhudson:  sil2100: new subiquity image regressed on s390x https://bugs.launchpad.net/subiquity/+bug/1889749
[11:37] <ubot5> Ubuntu bug 1889749 in Ubuntu on IBM z Systems "No longer able to do zFCP/SCSI multipath installations on focal image '20200730.1'" [Critical,New]
[11:43] <xnox> Laney:  https://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html is out of date, last generate yesterday?
[11:43] <xnox> sil2100:  grub2-signed & grub2 are ready for release to updates in xenial, bionic, focal
[11:48] -queuebot:#ubuntu-release- New source: agda-stdlib (groovy-proposed/primary) [1.3-1~build1]
[11:56] -queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.16 => 20101020ubuntu543.17] (core)
[11:58] <xnox> sil2100: bdmurray: vorlon: fix for FTBFS of s390x d-i in bionic uploaded ^
[12:46] <Odd_Bloke> xnox: vorlon: I saw mention of potentially not needing the cloud-init fix; should I continue working on it, or do we categorically no longer need it?
[12:51] <xnox> Odd_Bloke: we absolutely need it now.
[12:51] <xnox> Odd_Bloke: grub is only a cludge, and will delay breaking machines until after release upgrade.
[12:52] <xnox> Odd_Bloke: cloud init fix can unbreak some clouds to correctly upgrade to new grub.
[12:52] <xnox> and not fail release upgrade.
[12:52] -queuebot:#ubuntu-release- Unapproved: accepted bcache-tools [source] (focal-proposed) [1.0.8-3ubuntu0.1]
[12:53] <xnox> Odd_Bloke: however the grub cludge makes cloud-init fix not time sensitive, as much.
[12:54] <xnox> We are choosing to skip grub-install for security update, but will call it on release upgrade.
[12:56] <Odd_Bloke> xnox: Thanks!
[12:57] -queuebot:#ubuntu-release- Unapproved: accepted smokeping [source] (focal-proposed) [2.7.3-2ubuntu20.04.1]
[12:57] <Odd_Bloke> xnox: My next Q: does that affect whether or not we need to release a cloud-init fix to -security?
[12:58] <xnox> Odd_Bloke: we are choosing to not call grub-install in -security, thus cloud-init can simply go to -updates.
[12:59] <xnox> (note this is all about grub-pc, the efi signed stuff is upgraded, as that's the point of this security update)
[12:59] -queuebot:#ubuntu-release- Unapproved: accepted network-manager-applet [source] (focal-proposed) [1.8.24-1ubuntu3]
[12:59] <sbeattie> xnox: FYI, there will at least need to be a respin of grub2 before it can go into security, as the ones in proposed were built with -updates enabled, and so at least a no-change rebuild will be needed for -security.
[13:00] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu27.5]
[13:02] <Odd_Bloke> xnox: "we are choosing to not call grub-install in -security" <-- as a rule going forward, or just for this grub upload?  If the latter, then folks running -security will run into this next time around (or on release upgrade?), no?
[13:02] <xnox> vor
[13:02] <xnox> vorlon: why did you direct upload instead of copy?! :-)
[13:03] <xnox> sbeattie: let me prepare that then.
[13:03] <xnox> Odd_Bloke: until we fix grub-install to at least rollback and not fail to install core; yet update to incompatible modules in /boot.
[13:03] <xnox> Od
[13:03] <xnox> Odd_Bloke: as we break machines, intentionally, and know it, and carry on.
[13:08] <Odd_Bloke> xnox: -security-only users who would be fixed by the cloud-init upload still wouldn't get new grubs because their install_devices will still be incorrect.  Or will upgrades of grub fail in a way that's very obvious (and should therefore prompt users to fix install_devices themselves)?
[13:12] <xnox> Odd_Bloke:  once cloud-init fix is out, we can order to have new cloud-init configured first on release-upgrades.
[13:12] <xnox> Odd_Bloke: or, when we fix up grub-install => things will fail, but ensure that system remains bootable & rebootable.
[13:13] <xnox> Odd_Bloke:  when we have better/proper grub-install we will push it to security too, i think.
[13:25] <Odd_Bloke> xnox: Right, it sounds like we will ensure the system remains bootable & rebootable, but with the cloud-init fix we could do better for some systems (in that they would both remain (re)bootable, but also get new grub updates).
[13:26] <Odd_Bloke> (I'm not asserting that the cloud-init fix must go to -security, just making sure I understand what, if any, gap we'll be leaving if it doesn't.)
[13:29] <xnox> yeap yeap yeap
[13:29] <ahasenack> hello ubuntu-archive, are you fine with also promoting adcli and realmd to main in focal? Their MIRs were approved (and done) for groovy. The versions in focal are identical. https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu-seeds/+merge/388428
[13:30] <ahasenack> maybe now just before the 20.04.1 is not the best time (or is it?)
[14:07] <paride> xnox, so new trip to candidate for subiquity?
[14:09] <xnox> paride: yeah, pushing buttons to make a new edge build.
[14:09] <xnox> once jfh tests it from edge, will promote it to release.
[14:09] <xnox> paride:  i guess we can trigger edge jenkins jobs too, once i publish it to edge?
[14:10] <paride> xnox, yes you can trigger the -smoke-edge jobs
[14:14] <paride> but  it just tests the default install case
[14:15] <xnox> it's ok.
[14:15] <xnox> they are currently building.
[14:17] <ahasenack> ubuntu-archive, hi, can you please remove sssd from groovy-proposed that I just synced? I wanted to sync ldb and samba first, and sssd later
[14:17] <ahasenack> or is it too late
[14:20] <ahasenack> it's still building for all but s390x: https://launchpad.net/ubuntu/+source/sssd/2.3.1-1
[14:21]  * ahasenack tries cancelling the other builds
[14:33] <paride> sil2100, do you think we can add a 18.04.5 milestone to the ISO tracker?
[14:33] <paride> or is it still too early?
[14:34] <paride> the 20200731.1 bionic images look good
[14:43] <paride> well we probably want the new subiquity there too, even if there's no s390x
[14:43] <paride> but the d-i images should be fine
[14:44] <sil2100> paride: I think it's too early, wanted to add it once we start building candidates
[14:45] <paride> ack
[14:48] <bdmurray> sil2100: I have a "dumb" fix for bug 1889449 but I'm also working on a better one. Do you have a timeline in mind that I should be done by?
[14:48] <ubot5> bug 1889449 in ubuntu-release-upgrader (Ubuntu) "18.04 to 20.04.1 upgrade on raspberry pi removes too many kernel meta packages" [Undecided,New] https://launchpad.net/bugs/1889449
[15:10] <xnox> paride: new subiquity in edge, please kick edge jobs off.
[15:16] <paride> xnox, done already, all passed on bionic amd64 and focal amd64 ppc64el s390x
[15:18] <paride> I checked the snap build id to make sure the jobs ran using the edge snap
[15:22] <sil2100> paride: thanks for the testing!
[15:22] <sil2100> bdmurray: I guess the deadline would be next week when we release .1 and enable upgrades, but I guess the earlier the better
[15:22] <sil2100> Let me take a look at what you proposed
[15:25] <sil2100> bdmurray: I don't know the mechanics of the blacklist_removal.cfg - that only affects release upgrades?
[15:27] <bdmurray> sil2100: here's my dumb fix https://pastebin.ubuntu.com/p/sskcZsQ2Kp/
[15:28] <bdmurray> sil2100: yes, removal_blacklist.cfg is a part of the dist-upgrader tarball and is only used during the dist upgrade process
[15:28] <bdmurray> and here's the better fix https://pastebin.ubuntu.com/p/GxF2QHhrJT/
[15:28] <bdmurray> It didn't do what I wanted yesterday but I was missing the third change there
[15:29] <bdmurray> I'm gonna test the better fix shortly
[15:33] <xnox> paride: thinking to release to stable. But did not hear from Frank yet
[15:34] <xnox> ok jfh says it's good
[15:36] <xnox> sil2100:  new subiquity published with regression fix, so live-server could be respun.
[15:36] <xnox> (or well, ready to respin, whenever you want)
[15:38] <paride> sil2100, if you do, I
[15:38] <paride> sil2100, if you do, let me know and I'll submit results before EOD
[15:42] <paride> xnox, can we tell which subiquity went into an image from the image build logs?
[15:45] <sil2100> Yay, I'll have to respin everything now!
[15:45] <sil2100> People will be really happy
[15:49] <sil2100> bdmurray: hm, the 'better' fix looks okay from the look of it, though I still wonder why is the new metapackage marked for autoremoval anyway
[15:55] <xnox> paride:  yes, if you click on the livefs build, and then click on build log of that, one can see subiquity revision in the log.
[15:56] <xnox> paride:  we really should fix the manifests to include subiquity revision id in the manifest.
[16:06] <Odd_Bloke> rcj: xnox: vorlon: One thing I don't think I've fully understood: is the intent to never grub-install on upgrade of grub-pc systems again, or is that a stopgap while we implement reliable grub-install on such systems?
[16:09] <xnox> Odd_Bloke:  it's a stop gap.
[16:10] <xnox> Odd_Bloke:  intent is to call grub-install, and rollback when it is unsuccessful.
[16:13] <Odd_Bloke> xnox: OK, cool, thanks!
[16:18] <vorlon> xnox, Odd_Bloke: I disagree, actually.  The fact that we can never reliably know on BIOS systems that the disk we've installed the bootloader to is the actual boot disk means the ABI break is always a foot-gun, and I think we should avoid applying this to users' systems from grub-pc for the lifetime of these releases and only deal with it during release upgrades
[16:19] <vorlon> the other changes to make grub-install more resilient are still relevant, but I don't think it's an either-or
[16:24] <Odd_Bloke> vorlon: "always a foot-gun" because we could "successfully" install to /boot and /dev/sda and then the system boots from /dev/sdb and hits the incompatibility anyway, you mean?
[16:24] <vorlon> Odd_Bloke: exactly
[16:36] <xnox> Odd_Bloke:  there is no protocol to tell us off what we booted, and where things should be.
[16:36] <xnox> Odd_Bloke:  another example is degraded raid, yes installing on sda sdb sdc is correct, and yes sdc is missing, and sdb has incompatible core, and yes all of them should be updated. etc.
[16:38] <sbeattie> vorlon: that means never being able to SRU a bugfix for bios users again in these releases.
[16:39] <sbeattie> (which may be an okay tradeoff)
[16:39] <xnox> sbeattie:  most of our bugfixes are around generating grub.cfg though.
[16:42] <sbeattie> okay. just want to make sure the implications are understood.
[16:46] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200731)
[16:52] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200731)
[16:53] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200731)
[16:53] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal 20.04.1] has been updated (20200731)
[16:53] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200731)
[16:53] -queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Focal 20.04.1] has been updated (20200731)
[16:53] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Focal 20.04.1] has been updated (20200731)
[16:57] <Odd_Bloke> If we did hit a circumstance where we did need to SRU a bugfix for bios users that did require a `grub-install` then we could presumably handle "undisabling" it at that time too?
[16:58] <Odd_Bloke> (Feasibly such a bugfix might only apply to a subset of bios systems, so we could conditionally `grub-install` or whatever; we will know better once confronted with such an issue.)
[16:58] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal 20.04.1] has been updated (20200731)
[16:59] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal 20.04.1] has been updated (20200731)
[16:59] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal 20.04.1] has been updated (20200731)
[17:07] <Odd_Bloke> vorlon: So should I drop https://github.com/canonical/cloud-init/pull/514/files#diff-0a6a3bac6b74050d52c36391345e3838R316 from the cloud-init postinst I'm working on?
[17:07] <gitbot> canonical issue (Pull request) 514 in cloud-init "debian/cloud-init.postinst: fix NVMe grub install device on upgrade" [Open]
[17:09] <Odd_Bloke> Or should I still call `grub-install` because it will be a noop when appropriate?
[17:11] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal 20.04.1] has been updated (20200731)
[17:11] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal 20.04.1] has been updated (20200731)
[17:11] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal 20.04.1] has been updated (20200731)
[17:11] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal 20.04.1] has been updated (20200731)
[17:11] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal 20.04.1] has been updated (20200731)
[17:19] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal 20.04.1] has been updated (20200731)
[17:19] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal 20.04.1] has been updated (20200731)
[17:21] -queuebot:#ubuntu-release- New binary: pygame-sdl2 [amd64] (groovy-proposed/universe) [7.3.5-1] (no packageset)
[17:23] <sil2100> vorlon: hey! So there's that very old shim-signed in bionic-proposed, which is being pulled in by ubiquity when I try to update the sources
[17:24] -queuebot:#ubuntu-release- New binary: pygame-sdl2 [s390x] (groovy-proposed/universe) [7.3.5-1] (no packageset)
=== ijohnson is now known as ijohnson|lunch
[17:25] -queuebot:#ubuntu-release- New binary: pygame-sdl2 [ppc64el] (groovy-proposed/universe) [7.3.5-1] (no packageset)
[17:30] <vorlon> sil2100: that one is effectively verification-failed; there is a fix in the unapproved queue. are you ok with me accepting the new one, or should I just delete the old one?
[17:33] <vorlon> Odd_Bloke: how sure can you be that grub-install is called for the right target?
[17:39] <vorlon> sbeattie: yeah, I understood that implication; we could revisit the question if it came up that we did need an SRU to fix the grub-pc binary bits, but aside from a couple of long-past xenial SRUs, we don't have a history of doing this
[17:39] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.1] has been updated (20200731)
[17:39] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.1] has been updated (20200731)
[17:39] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.1] has been updated (20200731)
[17:39] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.1] has been updated (20200731)
[17:48] <xnox> vorlon:  even if sure of target, it may not be successful as we see in the other cloud.
[17:50] <Odd_Bloke> vorlon: This is basically running the "determine the correct install_device" logic that cloud-init runs at first boot, only on systems with an NVMe disk (to target AWS Nitro instances), and only if the current value is /dev/sda (cloud-init's previous default).
[17:50] -queuebot:#ubuntu-release- New binary: pygame-sdl2 [armhf] (groovy-proposed/universe) [7.3.5-1] (no packageset)
[17:50] -queuebot:#ubuntu-release- New binary: pygame-sdl2 [arm64] (groovy-proposed/universe) [7.3.5-1] (no packageset)
[17:58] -queuebot:#ubuntu-release- New binary: pygame-sdl2 [riscv64] (groovy-proposed/universe) [7.3.5-1] (no packageset)
[18:01] <sforshee> vorlon: could you approve the linux signing tarballs for groovy? Not sure if there's anyone else still around today who is willing to touch those
[18:04] <Odd_Bloke> vorlon: Honestly, I am wondering if we need to do anything in cloud-init for existing instances, if we never plan to rely on what they have set in grub-pc/install_devices.
[18:09] <xnox> Odd_Bloke:  wait "never plan to rely on what they have set in grub-pc/install_devices" is not true. we absolutely rely on that to be correct during do-release-upgrade and will attempt installing grub-pc into the devices listed there.
[18:09] <xnox> Odd_Bloke:  so we do want those corrected for nitro instances.
[18:10] <xnox> Odd_Bloke:  but you may choose to skip calling grub-install on them, when correcting that.
[18:12] <Odd_Bloke> xnox: And we shouldn't/won't just be prompting people to select the correct install device at do-release-upgrade time?
[18:15] <Odd_Bloke> I guess where I'm at is: either we trust this determination (and therefore can grub-install immediately) or we don't (and therefore shouldn't use it for do-release-upgrade either).
[18:15] <Odd_Bloke> And the correct value could have changed by the time a `do-release-upgrade` occurs.
[18:17] <Odd_Bloke> So if we won't need it until then, it seems to me that it would make most sense to wait until then to determine it.
[18:24] <xnox> Odd_Bloke:  we know that sda on nitro nvme instances is wrong, that must be corrected.
[18:24] <xnox> Odd_Bloke:  such that user is not asked about it.
=== ijohnson|lunch is now known as ijohnson
[18:33] <paride> sil2100, submitted all the results for focal server 20200731
[18:46] <Odd_Bloke> xnox: vorlon: I'm a couple of hours away from EOW, and I'm out on Monday: can the cloud-init change wait until mid-next-week, or should I be looking to hand it off to someone to keep pushing it on Monday?  (My feeling currently is that it can wait, given the grub change making its way out.)
[18:55] <vorlon> Odd_Bloke: I believe the grub change that's been uploaded is a complete mitigation for the problems we've seen
[18:56] <vorlon> sforshee: I don't see any linux signing tarballs pending for groovy?
[18:58] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (groovy-proposed) [1.4.5-1]
[18:58] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (groovy-proposed) [1.4.5-1]
[18:58] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (groovy-proposed) [1.4.5-1]
[18:58] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (groovy-proposed) [2.12.0-0ubuntu6]
[19:07] <sforshee> vorlon: someone else must have approved them
[19:10] -queuebot:#ubuntu-release- New binary: linux-signed [s390x] (groovy-proposed/main) [5.8.0-12.13] (core, kernel)
[19:56] <vorlon> sforshee: well I don't see any mentioned by the bot in the past day either
[20:02] <sforshee> huh, that's odd
[20:38]  * cjwatson wonders if Foundations are ever planning to send any of this grub maintainer script hackery to Debian so that it can at least be discussed more widely
[20:39] <cjwatson> or just carry on diverging ever further in Ubuntu
[20:40] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (groovy-proposed/main) [5.8.0-12.13] (core, kernel)
[20:50] <bryyce> there are 4 php-horde packages needing blacklisted, could an ubuntu-archive admin merge https://bazaar.launchpad.net/~bryce/+junk/sync-blacklist-php-horde/revision/772 for me?
[20:51] <bryyce> (LP: #1880776)
[20:51] <ubot5> Launchpad bug 1880776 in php-horde (Ubuntu) "Please blacklist and remove php-horde and php-horde-* from groovy (and future releases)" [Undecided,New] https://launchpad.net/bugs/1880776
[21:17] -queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.29 => 1:2.11+dfsg-1ubuntu7.30] (ubuntu-server, virt)
[21:48] <vorlon> cjwatson: that would be... ideal, yes
[21:51] <vorlon> bryyce: I was unclear on the rationale for why we blacklisted php-horde again given that the packages that were coming from Debian are maintained again.  Is this really intended to be a permanent blacklist? cpaelzer's comment suggests it might not be
[21:52] <vorlon> bryyce: anyway, merged in keeping with the existing ones
[22:08] <vorlon> why is retry-autopkgtest-regressions trying (and failing) to parse yaml related to a snap-triggered test?
[22:08] <vorlon> (when run with -s bionic)
[22:08] <bryyce> vorlon, thanks for merging it, sorry about the lack of clarity, yes it was intended to be a permanent block
[22:08] <vorlon> bryyce: what's the rationale of making it permanent, if it's maintained again in Debian?
[22:12] <bryyce> vorlon, rationale is that it has a small userbase (per Josh's review), and it is comprised of a very large number of packages with widely varying upstream maintenance support, which has resulted in lots of effort required on our end to resolve migration conflicts
[22:13] <vorlon> bryyce: ok
[22:13] <vorlon> thanks :)
[22:14] <bryyce> the rationale's also documented on the bug report for posterity
[22:23] <vorlon> rbalint_: the recent changes from lp:~rbalint/ubuntu-archive-tools/retry-intermittent appear to cause retry-autopkgtest-regressions to fail when there are snap-triggered autopkgtests running
[23:19] -queuebot:#ubuntu-release- New binary: gvm-libs [s390x] (groovy-proposed/universe) [11.0.1-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: gvm-libs [arm64] (groovy-proposed/universe) [11.0.1-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: gvm-libs [ppc64el] (groovy-proposed/universe) [11.0.1-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: gvm-libs [armhf] (groovy-proposed/universe) [11.0.1-1] (no packageset)
[23:31] -queuebot:#ubuntu-release- New binary: gvm-libs [riscv64] (groovy-proposed/universe) [11.0.1-1] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: gvm-libs [amd64] (groovy-proposed/universe) [11.0.1-1] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: ospd [amd64] (groovy-proposed/universe) [2.0.1-1] (no packageset)