[00:14] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-136.140] (core, kernel)
[00:15] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (groovy-proposed/main) [5.8.0-42.47] (core, kernel)
[00:15] -queuebot:#ubuntu-release- New binary: linux-signed [s390x] (groovy-proposed/main) [5.8.0-42.47] (core, kernel)
[00:15] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-136.140] (core, kernel)
[00:18] -queuebot:#ubuntu-release- New binary: linux-signed [arm64] (groovy-proposed/main) [5.8.0-42.47] (core, kernel)
[00:24] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (groovy-proposed/main) [5.8.0-42.47] (core, kernel)
[00:45] <sil2100> Oh well, looks like we'll have to build the .2 RCs tomorrow
[00:45] <sil2100> o/
[01:20] -queuebot:#ubuntu-release- New binary: adios [riscv64] (hirsute-proposed/universe) [1.13.1-27] (no packageset)
[02:05] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.3 => 1:20.04.13] (core)
[06:23] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (groovy-proposed) [5.8.0-42.47]
[06:23] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (groovy-proposed) [5.8.0-42.47]
[06:23] -queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (groovy-proposed) [5.8.0-42.47]
[06:23] -queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (groovy-proposed) [5.8.0-42.47]
[06:23] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-136.140]
[06:23] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-136.140]
[09:53] <sil2100> o/
[09:53] <sil2100> xnox: give me a poke once you were able to do the manual test of u-boot-menu
[09:56] <sil2100> tseliot: hey! Guess you have been pinged about the ubuntu-drivers-common issue in focal? https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1913651
[09:57] <sil2100> Seeing that it appears rather frequent, I'd like to get that fixed before .2
[10:09] <xnox> sil2100:  https://bugs.launchpad.net/ubuntu/+source/u-boot-menu/+bug/1913468 verified.
[10:12] <sil2100> xnox: thank you!
[10:43] <tseliot> sil2100, ubuntu-drivers should be used with root privileges, at least when installing drivers
[10:45] <tseliot> I'll make sure to check that, and make the program exit when those privileges are not available
[10:46] <juliank> tseliot: ubuntu-drivers {devices,debug,list{,-oem}} probably not
[10:47] <juliank> as in please don't break those
[10:48] <tseliot> juliank, no, it's just the install case that requires root privileges
[11:17] <paride> sil2100, hi! I see there are no amd64 dailies here: https://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/pending/
[11:19] <paride> and also no arm64
[11:19] <paride> did something go wrong with the image build process?
[11:19]  * paride checks
[11:23] <paride> yup, there are two "ERROR WHILE BUILDING OFFICIAL IMAGES" in the latest build log https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/focal/daily-live-20210129.log
[11:23] <ogra> 32bit are enough for everyone !
[11:24] <seb128> cp: cannot stat '/srv/cdimage.ubuntu.com/ftp/dists/focal-updates/main/installer-arm64/current/legacy-images/hwe-cdrom/vmlinuz': No such file or directory
[11:24] <Laney> that sounds like xnox's change from yesterday
[11:25] <jibel> cp: cannot stat '/srv/cdimage.ubuntu.com/ftp/dists/focal-updates/main/installer-amd64/current/legacy-images/hwe-cdrom/initrd.gz': No such file or directory
[11:25]  * Laney joins the club
[11:25] <Laney> cp: cannot stat '/srv/cdimage.ubuntu.com/ftp/dists/focal-updates/main/installer-amd64/current/legacy-images/hwe-cdrom/initrd.gz': No such file or directory
[11:25] <sil2100> Legacy?
[11:25] <paride> :) saw that
[11:26] <sil2100> Why does everything have to explode on Fridays
[11:27] <paride> on release candidates friday
[11:27] <sil2100> Anyway, looking at this, but anyway xnox ^
[11:28] <paride> thanks sil2100
[11:35] <sil2100> uh, crap
[11:37] <sil2100> Ok, so we weren't ready for this yet, I see the debian-cd focal boot-amd64 is still written to work with debian-installer
[11:37] <sil2100> And since we do not use d-i anymore, and therefore we did not bump d-i with the HWE variant, it looks in legacy-images/ and doesn't find anything interesting
[11:37] <sil2100> Need to see how boot-amd64 looked in groovy and backport that there
[11:37]  * sil2100 looks
[11:39] <sil2100> ARGH, then again, we have no cd-boot-images-* for focal
[11:41] <sil2100> Ok, so we have two options, either hacking boot-* scripts in debian-cd to do the right thing, but I'd need xnox to look at that - or actually bump debian-installer and continue using the legacy-server bits
[11:41] <sil2100> I'll prepare the second option since the first feels very frisky to me
[11:58] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.3 => 1:20.04.10.4] (core)
[12:00] <tjaalton> sil2100, xnox: 20.04.2 should use oem-5.6
[12:02] <sil2100> This is about server
[12:02] <tjaalton> right, but the desktop image, instead of oem-5.10
[12:02] -queuebot:#ubuntu-release- Unapproved: update-manager (groovy-proposed/main) [1:20.10.3 => 1:20.10.4] (core)
[12:03] <sil2100> Argh, ok, one thing at a time
[12:03] <sil2100> ;)
[12:03] <tjaalton> so, no changes needed, unless there's a sane way to get rid of the 5.10 bits
[12:03] <tjaalton> hehe, right
[12:03] <tjaalton> no action needed :)
[12:03] <Laney> I forgot how that gets on there
[12:03] <tjaalton> just a fyi
[12:04] <tjaalton> Laney: because of nvidia?
[12:04] <Laney> is that a question question or a statement question :p
[12:05] <Laney> you can probably tell a bit by diving in https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.focal/ or cd build logs
[12:05] <tjaalton> statement I think :)
[12:05] <tjaalton> I'll look
[12:06] <Laney> https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.focal/ship-live.seedtext
[12:06] <xnox> tjaalton:  well, we probably want to get rid of the nvidia oem 5.10 bits i'll see if that can be fixed.
[12:06] <Laney> if it's that and there's a way to tweak this regex, we could do it
[12:06] <xnox> sil2100:  sigh.
[12:06] <xnox> Laney:  it is.
[12:07] <xnox> sil2100:  i wonder if we can somehow not tweak CONF at all (i.e. revert my change from yesterday) and just set that to true inside all the boot scripts and/or like for ubuntu-server only.
[12:07] <xnox> sil2100:  let me see what i can make up.
[12:08] <tjaalton> ah yes, that linux-modules-nvidia regex will pick 20.04b as well
[12:08] <xnox> har har
[12:08] <xnox> so we try to download d-i stuff..... and then we do not use it.
[12:09] <Laney> you could probably add a $ at the end, that would exclude the b variants
[12:09] <tjaalton> yeah
[12:12] <sil2100> xnox: oh, so it's not actually used, just downloaded?
[12:13] <sil2100> You know these code paths much better, but if anything I have a d-i upload almost done that would add those files - even if for dummy reasons
[12:13] <xnox> sil2100:  yeah, downloaded checked, then later we end up with if live use the casper one; else use the downloaded d-i one.
[12:14] <xnox> sil2100:  and all of that stopped using d-i bits in groovy+
[12:14] <xnox> sil2100: if you want you can revert the CONF commit for now, i'm reworking matching boot-* changes to have it all work in concert.
[12:14] <sil2100> hm, so maybe it would be trivial enough to just modify the boot-* scripts to do what we did in groovy?
[12:14] <sil2100> Ok
[12:15] <xnox> sil2100:  not quite, cause in groovy+ we use cd-boot-images-* stuff that doesn't exist in focal.
[12:15] <sil2100> Yeah, saw that indeed
[12:15] <xnox> focal still uses syslinux boot
[12:15] <sil2100> (which is why I didn't want to do it myself)
[12:16] <sil2100> Ok, so in that case you do your magic, I'll revert the CONF.sh piece
[12:29] -queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (focal-proposed) [11ubuntu5.3]
[12:30] <tjaalton> ^ this was the old version from September, which now needs to be rebased..
[12:32] <xnox> sil2100:  your comment in the debian-cd revert is incorrect. teh BACKPORT_KERNEL setting is used to trigger hwe code-paths for both d-i & subiquity; but we always download d-i kernels, even when building just the subiquity image.
[12:32] <xnox> but whatever.
[12:33] <sil2100> Ah, you are right! I see it now, as it causes adding a new KERNEL_PREFIX, and I see a lot of possibly non-legacy stuff done per kp
[12:34] <sil2100> ...and even more than that
[12:36] <sil2100> hm, if I was to hack on this, I wonder what would happen if we simply re-added BACKPORT_KERNEL but removed the bits for "# Download boot images" + the loop for copying over the kernel stuff from ${!kp}cdrom/
[12:38] <xnox> sil2100:  we still use debian_cd tarball on both d-i & subiquity images.
[12:38] <xnox> i have this so far:
[12:38] <xnox> https://paste.ubuntu.com/p/vdwGHX3m7W/
[12:39] <xnox> https://paste.ubuntu.com/p/cZ7sChDYSP/ => with CONF.sh change back in.
[12:39] <xnox> but need to test all of this.
[12:39] <sil2100> oh!
[12:39] <xnox> let me try to sync a mirror, and try to do local builds of all of these without the --livefs
[12:39] <xnox> to test that everything is sane.
[12:40] <sil2100> Yeah, this feels like a better idea
[12:40] <xnox> and it will be the first time we are doing hwe on s390x subiquity iso
[12:40] <xnox> cause there was no s390x subiquity in bionic
[12:43] <sil2100> xnox: hm, you still might be working on that, but I think you might be missing moving the list_kernel_abis call for ppc64el to under the "$CDIMAGE_INSTALL_BASE" = 1 conditional
[12:44] <xnox> sil2100:  it looks scoped correctly to me.
[12:44] <xnox> above the else
[12:44] <xnox> and else is for the cdimage_install_base
[12:44]  * xnox is not sure if i should be reindenting this stuff or not.
[12:45] <sil2100> Oh, indeed, nvm, I think my eyes got confused by the indent and lack of coffee, thanks!
[12:51] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (groovy-proposed) [1:20.10.4]
[12:56] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (focal-proposed) [1:20.04.13]
[13:00] -queuebot:#ubuntu-release- Unapproved: update-notifier (focal-proposed/main) [3.192.30.5 => 3.192.30.6] (ubuntu-desktop, ubuntu-server)
[13:13] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.3 => 1:20.04.10.4] (core)
[13:17] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (focal-proposed) [1:20.04.10.4]
[13:17] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.10.4]
[13:18] <sil2100> xnox: you fine testing that locally? Since we could also do a cdimage build with the changes without --livefs
[13:21] <Laney> I'm going to push that ship-live change discussed above
[13:21] <Laney> tjaalton: is there somewhere we should note this to remember to fix it when rolling the oem kernel
[13:21] <Laney> ?
[13:21] <sil2100> Laney: ACK
[13:22] <tjaalton> Laney: maybe we should have a public tracker bug for that
[13:23] <tjaalton> don't think there is one now
[13:23] <Laney> I was thinking like a SOP or a bug template - to roll an OEM kernel onto a new series do x, y, z
[13:23] <tjaalton> ah
[13:24] <Laney> otherwise I predict us forgetting this part
[13:24] <Laney> :p
[13:24] <tjaalton> heh, quite possibly
[13:26] <Laney> ok committed
[13:26] <Laney> we must must remember to verify this worked and test an nvidia install
[13:49] <xnox> in my local builds the seed change looks good
[13:49] <xnox> it shows me the diff that the 5.10 stuff is gone
[13:56] <sil2100> tseliot: ok, so the crash from the mentioned ubuntu-drivers-common is only from when `ubuntu-drivers install` is called as non-root, right (seeing that the trash is via command_install())?
[13:56] <tseliot> sil2100, correct
[13:57] <sil2100> Just making sure that the other commands don't crash when ran as non-root
[13:57] <sil2100> Ok, so not a blocker then!
[13:57] <tseliot> no, they won't
[13:57] <sil2100> Thanks o/
[13:57] <tseliot> np
[13:57] <sil2100> Guess it would be good to print out a message about missing privilages, but that's more of an UX improvement for the future. Anyway, let me get it off from the blocker list
[14:01] <sil2100> Wonder how users encountered this cash though, by manually running the command?
[14:09] <xnox> not sure that arm64 subiquity was ever built with hwe before either
[14:10] <xnox> also not sure if my arm64 subiquity hwe changes would break arm64 desktop which i'm not sure if we are building for focal still
[14:10] <xnox> leh sigh.
[14:10] <xnox> and also on arm64 we probably ought to add 64k kernel installer option.
[14:10] <xnox> (for hirsute)
[14:34] <sil2100> xnox: yeah, so we are still building dailies of the arm64 desktop
[14:35] <sil2100> (for focal)
[14:36] <xnox> sil2100:  cool.
[14:37] <xnox> sil2100:  so i'm finding more and more issues. s390x & arm64 are now building; and my mirror was incomplete for amd64.
[14:37] <xnox> however none of them have the right grub menu.
[14:37] <xnox> ie. arm64 ends up without hwe entries in grub.cfg; and has menu entries that are complete BS. I.e. desktop-like entries for oem-config and what not which make no sense with subiquity.
[14:40] <sil2100> ugh, where is all of this coming from? Is this all from the boot-amd64 etc. scripts as well?
[14:40] <xnox> and boot-arm64
[14:41] <xnox> we really did add all the subiquity stuff for hwe in boot-amd64 only, in bionic only, for .2 release. meaning that focal boot-* have none of that, because they derived from cosmic / bionic .0
[14:41] <xnox> anyway, getting there.
[14:41] <xnox> it also means we didn't test any of the subiquity installers with hwe kernels =)
[14:41] <xnox> fun fun fun
[14:42] <xnox> on any arch.
[14:43] <sil2100> Glorious
[14:43] <ogra> kernels ... so overrated
[14:43] <sil2100> I don't know all the code-paths there, but I guess this would basically mean we'd have similar problems with the boot entries even if I did my debian-installer workaround with adding the HWE entries there, oh well
[14:44] <sil2100> Nothing like discovering such issues on a Friday before release ;)
[14:50] -queuebot:#ubuntu-release- New source: directx-headers (hirsute-proposed/primary) [1.0.1-0ubuntu1]
[14:50] <sil2100> xnox: ...should we just backport cd-boot-images-* to focal? ;D
[14:52] <xnox> har har har
[14:52] <xnox> so. ppc64le is now perfect.
[14:52] <xnox> arm64 one has two extra entries, will try to make it as perfect as ppc64le
[14:52] <xnox> but meeting time.
[14:53] <xnox> if i don't finish i will hand-over to somebody else before eod.
[14:56] <sil2100> Thanks!
[14:57] <sil2100> I don't know these parts but if you won't be able to find anyone, I could potentially take over - already learned like a LOT about this
[14:57] <sil2100> But probably vorlon would be more useful
[15:57] <sil2100> tseliot: hey! Sorry to get back to this again, but I want to make sure about that: what about if users start the 'Additional Drivers' section and select a driver to install - is that using `ubuntu-drivers install`? If yes, are the permissions escalated by that point so this is running as root?
[15:59] <tseliot> sil2100, yes, I think they use polkit or something like that, since apt won't let users install packages unless they have root privileges
[16:00] <sil2100> Ok, if this was tested then good, thanks - since I have no way of testing that as I have nothing that I could install drivers for there ;p
[16:04] <tseliot> sil2100, it's always been this way, it's just that now it tries writing to a file before using apt, hence the different error
[16:05] <Laney> it could do like systemd does and use polkit to get elevated permissions
[16:05] <Laney> might be too much work :p
[16:36] <xnox> vorlon:  does grubx64.efi on the amd64 iso come from d-i build, in focal?
[16:42] <Eickmeyer> ubuntu-archive: Is there a reason why hydrogen is on the Debian blacklist? IIRC it had to do with the qt4-qt5 transition, but I could be wrong.
[16:43] <vorlon> xnox: that is my recollection yes
[16:44] <vorlon> Eickmeyer: the sync blacklist has a bzr log :) "blacklist hydrogen, documenting that it shouldn't be removed" - hydrogen had been removed from Debian and this was a way to document that the removal shouldn't be followed in Ubuntu
[16:45] <vorlon> (in principle we want process-removals to honor sync-blacklist but in practice this is not implemented)
[16:46] <Eickmeyer> vorlon: Hi! Good to read you. :) Since it's in Debian now, and is being actively maintained there, wouldn't it be logical to remove the blacklist on it?
[16:46] <vorlon> Eickmeyer: if you want this dropped from the blacklist now that it's back in Debian, I'm happy to remove it from the blacklist yes
[16:46] <Eickmeyer> vorlon: Awesome, that would be great. :)
[16:46] <vorlon> done
[16:46] <Eickmeyer> Thanks. :)
[16:48] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.4 => 1:20.04.10.5] (core)
[16:58] -queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (focal-proposed) [20.04.15.6]
[17:02]  * sil2100 goes AFK a bit to rest
[17:02] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.10.5]
[17:05] <xnox> vorlon:  i'm kind of confused how i'm failing to identify which signed build of it, is used. will try again but like using the .iso from cdimage, rather than locally built. cause maybe my environment is dirty.
[17:06] <xnox> vorlon:  a separate question then, should i be preparing d-i rebuild, for us to gain `exit 1` in grub & to potentially get secureboot on arm64?
[17:06] <xnox> or should we do what was mentioned a few times now, and backport cd-boot-images-* to focal, such that we can pull grub from there for the efi boot.
[17:10] <xnox> i am thinking to somehow download & unpack grub-efi-amd64-signed
[17:10] <xnox> and steal the right grub from there.
[17:14] <Eickmeyer> vorlon: Now I'm having difficulty as the hydrogen orig tarballs have differing contents. Even tried a manual upload with the same result. Got any suggestions? (sorry to take any of your time).
[17:17] <xnox> fakesync?
[17:17] <xnox> (from ubuntu-dev-tools)
[17:17] <Eickmeyer> xnox: Yeah, tried that, same issue.
[17:17] <xnox> sigh
[17:17] <xnox> Eickmeyer:  i am a bit tied up now, but if you tell me what needs to be achieved, i can poke it when i'm free next.
[17:18] <xnox> Eickmeyer:  do you want "to sync it from debian to ubuntu, for realz, kthxbye"?
[17:18] <Eickmeyer> xnox: Hahaha! Exactly.
[17:18] <xnox> cool. will do.
[17:18] <Eickmeyer> xnox: You're amazing. Thanks a lot. :)
[17:42] <xnox> vorlon:  d-i pulls signed grub directly from /uefi/ from the archive; like grub2-signed does at build time. but because we actually generate different signatures for each suite, it means that d-i's & grub2-signed deb binaries have different checksums => horay.
[17:42] <xnox> but if one strips signatures with sbattach --remove, then the two grubs are identical and comparable.
[17:43] <xnox> so yeah, our isos ship with `grub2-signed 1.142.3` still and thus don't have support for `exit 1` on both amd64 & arm64; nor secureboot on arm64.
[18:07] <xnox> sil2100:  vorlon: https://code.launchpad.net/~xnox/debian-cd/hwe-focal/+merge/397181
[18:07] <xnox> otherwise we don't have hwe stack on the subiquity isos.
[18:07] <xnox> as in no boot-loader menus
[18:17] <sil2100> o/
[18:17] <sil2100> Looking
[18:21] <xnox> Eickmeyer:  uploaded.
[18:27] <sil2100> Ok, for this I think I need a coffee, back to the review in a bit
[18:30] <Eickmeyer> xnox: Thanks so much! :)
[18:50] <xnox> sil2100:  it's a mish mash of bionic's boot-* with focal's boot-*, sometimes cheating and looking at what hirsute's boot-* files do.
[18:50] <xnox> plus a few trials and errors to get it more or less ok.
[19:09] <cking> sil2100, i verified 1894329
[19:13] -queuebot:#ubuntu-release- Unapproved: ubiquity (groovy-proposed/main) [20.10.13.1 => 20.10.13.2] (desktop-core)
[19:26] <tumbleweed> I'm fixing up a bunch of old data in distro-info-data
[19:27] <tumbleweed> Is there a canonical EOL date for ESM releases?
[19:27] <tumbleweed> according to https://wiki.ubuntu.com/Releases 12.04 ESM should be EOL, but there's no date there
[19:28] <tumbleweed> I see ubuntu-security-status consults distro-info-data
[19:28] <tumbleweed> if I tweak eol by a couple of days, should I be tweaking eol-esm too?
[19:29] <tumbleweed> I've also seen that ESM can be available for 5 years rather than the 2 we're quoting
[19:32] <xnox> tumbleweed:  precise ESM is no longer for sale; but as can be obviously seen precise archives are not yet removed from primary mirrors .................. sigh .....
[19:33] <tumbleweed> yeah, I gathered as much
[19:33] <xnox> tumbleweed:  Security updates for 14.04 LTS until 2022 to trusty is defined at least on https://ubuntu.com/security/esm as 3 years of ESM
[19:34] <xnox> and ditto for xenial Extended Security Maintenance for Ubuntu 16.04 LTS will be available April 2021 until 2024.
[19:34] <xnox> bionic is yet to be defined.
[19:34] <xnox> focal has been announced in the past as offering 5 years of esm.
[19:34] <tumbleweed> does anyone care if I tweak the exact dates in there to match the final eol date
[19:35] <xnox> tumbleweed:  i think it is a fair default of 3 years of esm for everything for now.
[19:35] <tumbleweed> + 3 years
[19:35] <xnox> tumbleweed:  bdmurray i think is off, but i think he in the past was involved in those dates.
[19:36] <xnox> tumbleweed:  plus it's not like we will publish your tweaks to said data into ESM repos themselves. and people see their entitements via the `ua` (ubuntu advantage) client anyway.
[19:36] <tumbleweed> true
[19:36] <xnox> tumbleweed:  i don't see any harm in +3years as a rule of thumb. but maybe wait for someone else to speak up. like bdmurray and/or vorlon.
[19:37] <tumbleweed> thanks!
[19:37] <xnox> something something us holiday last or the week before, swap for today, happening a lot though. so maybe they will only respond next week.
[19:37] <tumbleweed> it's kind of amazing how many off by one or two mistakes there were
[19:37] <tumbleweed> I should stop caring :P
[19:38] <sil2100> cking: thanks!
[19:42] <sil2100> Back on it now
[19:44] <tumbleweed> xnox: turns out the only tweak was to precise (2017-04-26 -> 28). It's in the past, I'm sure nobody cares.
[19:45]  * tumbleweed tweaks eol-esm and is done with it
[19:47] <tumbleweed> https://salsa.debian.org/debian/distro-info-data/-/commit/c84eef6eda6c87e0bd5229e6202385202c8c440a
[19:48] <bdmurray> thanks tumbleweed
[19:48] <tumbleweed> merging your esm patches, this should be more maintainable in the future
[19:54] <vorlon> xnox: which signed build of it> you're looking at gcdx64.efi not grubx64.efi in the source, right?
[19:54] <vorlon> xnox: and yes, we want a d-i rebuild; have you done this yet?
[19:55] <vorlon> xnox: "generate different signatures for each suite" uh?
[19:57] <vorlon> xnox, tumbleweed: for releases where Canonical has not declared a support period, I would prefer you not list any end date as that may prematurely influence customers' decisions if it turns out to be inaccurate. "TBD" please
[19:57] <vorlon> xnox: as I don't see a d-i upload in the queue, should I do one?
[19:58] <tumbleweed> vorlon: I think that'd only be Focal
[19:59] <tumbleweed> but no ESM release has a day of the month specified, only the month
[19:59] <vorlon> tumbleweed: xnox said bionic "is yet to be defined" whereas focal has been announced as 5 years
[19:59] <tumbleweed> vorlon: it has an EOL date on https://wiki.ubuntu.com/Releases
[19:59] <tumbleweed> focal does not
[20:00] <tumbleweed> if there was somewhere I could refer to for what time frames canonical has declared support for, that'd be great, it's what I was asking for
[20:02] <vorlon> I'll see if I can track that down; but again, if there hasn't been an announcement, we shouldn't list any end date on this page
[20:02] <tumbleweed> the decleration of the date for bionic came from https://bugs.launchpad.net/ubuntu/+source/distro-info-data/+bug/1848688
[20:02] <tumbleweed> which wasn't me
[20:02] <tumbleweed> but I would have done the same thing
[20:03] <tumbleweed> err no, that's focal
[20:03] <tumbleweed> https://launchpad.net/ubuntu/+source/distro-info-data/0.37ubuntu0.3 - bdmurray
[20:05] <sil2100> xnox: hm hm, ok, so I'm might need some clarification. I mean, generally this hwe debian-cd branch seems fine with my limited knowledge, I'm just wondering about the HWE menu labels on the arm64 image
[20:07] <sil2100> Ah, no, I think I get it
[20:07] <tumbleweed> vorlon: https://ubuntu.com/security/esm declares 5 years for >= Bionic
[20:08] <tumbleweed> which I guess means 2 years (5 total - 3 LTS)
[20:08] <vorlon> tumbleweed: yeah I was just about to send you that link
[20:08] <vorlon> :)
[20:10] <tumbleweed> oh, no that is LTS + 5 years
[20:11] <Odd_Bloke> It actually declares "up to" 5 years, which is less categorical.
[20:12] <tumbleweed> yeah, but I need a date
[20:12] <tumbleweed> and eol + 5 years is what ubuntu is currently carrying
[20:15] <Odd_Bloke> Yeah, I agree that's your best option for a date.
[20:16] <tumbleweed> at some point, we probably need a more complex data structure to be able to carry nuance like announced vs expected
[20:16] -queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.15.5 => 20.04.15.6] (core)
[20:18] -queuebot:#ubuntu-release- Unapproved: debian-installer (focal-proposed/main) [20101020ubuntu614.1 => 20101020ubuntu614.2] (core)
[20:21] <sil2100> xnox: ok, I think this is almost +1 - just had one quick question there, inline
[20:23] <vorlon> sil2100: ^^ do you want to review this trivial d-i upload or should I self-accept?
[20:24] <sil2100> vorlon: I'll just glance it real quick
[20:25] <sil2100> ahaha
[20:25] <sil2100> Ok
[20:25] <sil2100> Forgot it's just the rebuild, ugh
[20:26] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (focal-proposed) [20101020ubuntu614.2]
[20:29] <sil2100> vorlon: could you also have a second look at https://code.launchpad.net/~xnox/debian-cd/hwe-focal/+merge/397181 ? You feel more comfortable in debian-cd - to me it seemed fine with just one stupid inline question
[20:30] <vorlon> darn, I was hoping you wouldn't ask ;)
[20:30] <vorlon> yes, I'll look
[20:32] <sil2100> Thanks ;) I'd merged it if not for my worry about those HWE entries for desktop suddenly appearing
[20:35] <sil2100> s/merged/merge
[20:46] <vorlon> sil2100: bleurgh, ftbfs
[20:46] <vorlon> (d-i)
[20:46] <vorlon> I'll chase it up after the debian-cd review unless you want to look at it
[20:53] <vorlon> lolwut, xfsprogs upstream regressed its architecture support and now ftbfs on riscv64
[20:56] <vorlon> sil2100: addressed your open question on the hwe mp; doing a more thorough review now
[20:56] <vorlon> also I really want to change this code to say "KERNEL_PREFICES"
[20:58] -queuebot:#ubuntu-release- Packageset: Added p7zip to i386-whitelist in hirsute
[20:58] -queuebot:#ubuntu-release- Packageset: Added rpm to i386-whitelist in hirsute
[21:02] <xnox> sil2100:  so i don't think anything will appear on desktop; as we only ever set KERNEL_PREFIX to more than one value, if PROJECT is ubuntu-server, on top of the file.
[21:06] <juliank> vorlon: eww, KERNEL_PREFICES is just wrong
[21:06] <vorlon> ;)
[21:07] <juliank> it's an interesting word because you'd think it's like matrix, but it isn't
[21:08] <juliank> the plural of praefixum being praefixa
[21:08] <juliank> latin weird
[21:09] <vorlon> juliank: cool, didn't know that, just was enjoying making the false analogy
[21:11] <juliank> vorlon: for some reason prefices, was popular-ish in the 70s/80s: https://books.google.com/ngrams/graph?content=prefices&year_start=1800&year_end=2000&corpus=15&smoothing=3&share=&direct_url=t1%3B%2Cprefices%3B%2Cc0#t1%3B%2Cprefices%3B%2Cc0
[21:11] <juliank> well just late 70s really
[21:12] <sil2100> xnox: got it!
[21:16] <vorlon> xnox: TAR_IMAGES="$TAR_IMAGES ${!kp}netboot/netboot.tar.gz" but I don't see that hwe-netboot/netboot.tar.gz ever exists, or even hwe-cdrom/initrd.gz, what gives?
[21:16] <vorlon> xnox: without that, this debian-cd change seems less useful?
[21:17] <vorlon> sil2100: ^^
[21:18] <vorlon> d-i build failure: "Disk full' on mcopy -i./tmp/netboot/boot.img ./tmp/netboot/initrd.gz ::initrd.gz :P
[21:20] <sil2100> Another FLOPPY_SIZE bump?
[21:20] <vorlon> yeah
[21:23] <sil2100> Test building with a 5MB bump in a PPA
[21:23] <vorlon> sil2100: so you'll take care of this change?
[21:24] <sil2100> vorlon: I can!
[21:25] <vorlon> sil2100: might want to also wait for xnox to respond wrt the missing hwe-* trees under installer-$arch in the archive before uploading
[21:26] <sil2100> I thought those are not really used right now, that was my understanding when I talked with xnox - that they're just checked, downloaded and then the casper bits are used?
[21:26] <sil2100> Since in the morning I wanted to prep the d-i hwe additions already, have even an almost-done package
[21:27] <vorlon> sil2100: so this code would only be used for legacy ISOs which we no longer build; in which case, why not kill this code instead of adding an additional if block?
[21:34] <sil2100> vorlon: it's probably absurd but I think we want to be as safe as possible ;p Guess we could kill it, but I personally feel better not removing code just-in-case - silly
[21:34] <vorlon> sil2100: whereas I feel better not having additional dead and broken code branches as future pitfalls :)
[21:41] <sil2100> hah, I think we can remove it in that case ;) But it does make me feel uneasy!
[22:20] <cking> sil2100, what was the status of the zfsutils-linux and grub being blocked in proposed?
[22:25] <sil2100> Let me try that now
[22:27] <cking> thanks
[22:29] <sil2100> vorlon: since I built that d-i successfully in a bileto PPA, I guess I can just bin-copy it over to focal-proposed to save build time, right?
[22:29] -queuebot:#ubuntu-release- Unapproved: debian-installer (focal-proposed/main) [20101020ubuntu614.2 => 20101020ubuntu614.3] (core) (sync)
[22:48] <vorlon> sil2100: yes
[22:58] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [sync] (focal-proposed) [20101020ubuntu614.3]
[23:00] <sil2100> xnox, vorlon: ok, I need to EOD now, but I'll be back tomorrow - can you sort out the debian-cd merge? I guess we could take xnox's change and just remove that unused block of code
[23:03] <vorlon> sil2100: yeah I can follow through
[23:12] <sil2100> Thank you o/ If anything needs doing just drop me a msg on mm
[23:23] -queuebot:#ubuntu-release- New binary: gevent-websocket [amd64] (hirsute-proposed/universe) [0.10.1-4] (no packageset)
[23:26] -queuebot:#ubuntu-release- New: accepted adios [amd64] (hirsute-proposed) [1.13.1-27]
[23:26] -queuebot:#ubuntu-release- New: accepted adios [armhf] (hirsute-proposed) [1.13.1-27]
[23:26] -queuebot:#ubuntu-release- New: accepted adios [riscv64] (hirsute-proposed) [1.13.1-27]
[23:26] -queuebot:#ubuntu-release- New: accepted adios [arm64] (hirsute-proposed) [1.13.1-27]
[23:26] -queuebot:#ubuntu-release- New: accepted gevent-websocket [amd64] (hirsute-proposed) [0.10.1-4]
[23:27] -queuebot:#ubuntu-release- New: accepted adios [ppc64el] (hirsute-proposed) [1.13.1-27]
[23:27] -queuebot:#ubuntu-release- New: accepted adios [s390x] (hirsute-proposed) [1.13.1-27]
[23:27] -queuebot:#ubuntu-release- New: accepted linkchecker [arm64] (hirsute-proposed) [10.0.0-1]
[23:27] -queuebot:#ubuntu-release- New: accepted linkchecker [ppc64el] (hirsute-proposed) [10.0.0-1]
[23:27] -queuebot:#ubuntu-release- New: accepted linkchecker [s390x] (hirsute-proposed) [10.0.0-1]
[23:27] -queuebot:#ubuntu-release- New: accepted linkchecker [amd64] (hirsute-proposed) [10.0.0-1]
[23:27] -queuebot:#ubuntu-release- New: accepted linkchecker [riscv64] (hirsute-proposed) [10.0.0-1]
[23:27] -queuebot:#ubuntu-release- New: accepted linkchecker [armhf] (hirsute-proposed) [10.0.0-1]