/srv/irclogs.ubuntu.com/2021/01/29/#ubuntu-release.txt

-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-136.140] (core, kernel)00:14
-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:15
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (groovy-proposed/main) [5.8.0-42.47] (core, kernel)00:18
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (groovy-proposed/main) [5.8.0-42.47] (core, kernel)00:24
sil2100Oh well, looks like we'll have to build the .2 RCs tomorrow00:45
sil2100o/00:45
-queuebot:#ubuntu-release- New binary: adios [riscv64] (hirsute-proposed/universe) [1.13.1-27] (no packageset)01:20
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.3 => 1:20.04.13] (core)02:05
=== Kamilion|ZNC is now known as Kamilion
=== guiverc2 is now known as guiverc
-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]06:23
=== tjaalton_ is now known as tjaalton
sil2100o/09:53
sil2100xnox: give me a poke once you were able to do the manual test of u-boot-menu09:53
sil2100tseliot: hey! Guess you have been pinged about the ubuntu-drivers-common issue in focal? https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/191365109:56
ubot5Ubuntu bug 1913651 in ubuntu-drivers-common (Ubuntu Groovy) "/usr/bin/ubuntu-drivers:PermissionError:/usr/bin/ubuntu-drivers@480:__call__:main:invoke:invoke:invoke:new_func:invoke:autoinstall:command_install" [High,Triaged]09:56
sil2100Seeing that it appears rather frequent, I'd like to get that fixed before .209:57
=== OldManWi1ter is now known as OldManWinter
xnoxsil2100:  https://bugs.launchpad.net/ubuntu/+source/u-boot-menu/+bug/1913468 verified.10:09
ubot5Ubuntu bug 1913468 in u-boot-menu (Ubuntu Groovy) "Improve u-boot-menu in focal" [Undecided,In progress]10:09
sil2100xnox: thank you!10:12
tseliotsil2100, ubuntu-drivers should be used with root privileges, at least when installing drivers10:43
tseliotI'll make sure to check that, and make the program exit when those privileges are not available10:45
julianktseliot: ubuntu-drivers {devices,debug,list{,-oem}} probably not10:46
juliankas in please don't break those10:47
tseliotjuliank, no, it's just the install case that requires root privileges10:48
paridesil2100, hi! I see there are no amd64 dailies here: https://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/pending/11:17
parideand also no arm6411:19
paridedid something go wrong with the image build process?11:19
* paride checks11:19
parideyup, 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.log11:23
ogra32bit are enough for everyone !11:23
seb128cp: cannot stat '/srv/cdimage.ubuntu.com/ftp/dists/focal-updates/main/installer-arm64/current/legacy-images/hwe-cdrom/vmlinuz': No such file or directory11:24
Laneythat sounds like xnox's change from yesterday11:24
jibelcp: cannot stat '/srv/cdimage.ubuntu.com/ftp/dists/focal-updates/main/installer-amd64/current/legacy-images/hwe-cdrom/initrd.gz': No such file or directory11:25
* Laney joins the club11:25
Laneycp: cannot stat '/srv/cdimage.ubuntu.com/ftp/dists/focal-updates/main/installer-amd64/current/legacy-images/hwe-cdrom/initrd.gz': No such file or directory11:25
sil2100Legacy?11:25
paride:) saw that11:25
sil2100Why does everything have to explode on Fridays11:26
parideon release candidates friday11:27
sil2100Anyway, looking at this, but anyway xnox ^11:27
paridethanks sil210011:28
sil2100uh, crap11:35
sil2100Ok, so we weren't ready for this yet, I see the debian-cd focal boot-amd64 is still written to work with debian-installer11:37
sil2100And 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 interesting11:37
sil2100Need to see how boot-amd64 looked in groovy and backport that there11:37
* sil2100 looks11:37
sil2100ARGH, then again, we have no cd-boot-images-* for focal11:39
sil2100Ok, 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 bits11:41
sil2100I'll prepare the second option since the first feels very frisky to me11:41
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.3 => 1:20.04.10.4] (core)11:58
tjaaltonsil2100, xnox: 20.04.2 should use oem-5.612:00
sil2100This is about server12:02
tjaaltonright, but the desktop image, instead of oem-5.1012:02
-queuebot:#ubuntu-release- Unapproved: update-manager (groovy-proposed/main) [1:20.10.3 => 1:20.10.4] (core)12:02
sil2100Argh, ok, one thing at a time12:03
sil2100;)12:03
tjaaltonso, no changes needed, unless there's a sane way to get rid of the 5.10 bits12:03
tjaaltonhehe, right12:03
tjaaltonno action needed :)12:03
LaneyI forgot how that gets on there12:03
tjaaltonjust a fyi12:03
tjaaltonLaney: because of nvidia?12:04
Laneyis that a question question or a statement question :p12:04
Laneyyou can probably tell a bit by diving in https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.focal/ or cd build logs12:05
tjaaltonstatement I think :)12:05
tjaaltonI'll look12:05
Laneyhttps://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.focal/ship-live.seedtext12:06
xnoxtjaalton:  well, we probably want to get rid of the nvidia oem 5.10 bits i'll see if that can be fixed.12:06
Laneyif it's that and there's a way to tweak this regex, we could do it12:06
xnoxsil2100:  sigh.12:06
xnoxLaney:  it is.12:06
xnoxsil2100:  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
xnoxsil2100:  let me see what i can make up.12:07
tjaaltonah yes, that linux-modules-nvidia regex will pick 20.04b as well12:08
xnoxhar har12:08
xnoxso we try to download d-i stuff..... and then we do not use it.12:08
Laneyyou could probably add a $ at the end, that would exclude the b variants12:09
tjaaltonyeah12:09
sil2100xnox: oh, so it's not actually used, just downloaded?12:12
sil2100You 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 reasons12:13
xnoxsil2100:  yeah, downloaded checked, then later we end up with if live use the casper one; else use the downloaded d-i one.12:13
xnoxsil2100:  and all of that stopped using d-i bits in groovy+12:14
xnoxsil2100: 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
sil2100hm, so maybe it would be trivial enough to just modify the boot-* scripts to do what we did in groovy?12:14
sil2100Ok12:14
xnoxsil2100:  not quite, cause in groovy+ we use cd-boot-images-* stuff that doesn't exist in focal.12:15
sil2100Yeah, saw that indeed12:15
xnoxfocal still uses syslinux boot12:15
sil2100(which is why I didn't want to do it myself)12:15
sil2100Ok, so in that case you do your magic, I'll revert the CONF.sh piece12:16
-queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (focal-proposed) [11ubuntu5.3]12:29
tjaalton^ this was the old version from September, which now needs to be rebased..12:30
xnoxsil2100:  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
xnoxbut whatever.12:32
sil2100Ah, 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 kp12:33
sil2100...and even more than that12:34
sil2100hm, 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:36
xnoxsil2100:  we still use debian_cd tarball on both d-i & subiquity images.12:38
xnoxi have this so far:12:38
xnoxhttps://paste.ubuntu.com/p/vdwGHX3m7W/12:38
xnoxhttps://paste.ubuntu.com/p/cZ7sChDYSP/ => with CONF.sh change back in.12:39
xnoxbut need to test all of this.12:39
sil2100oh!12:39
xnoxlet me try to sync a mirror, and try to do local builds of all of these without the --livefs12:39
xnoxto test that everything is sane.12:39
sil2100Yeah, this feels like a better idea12:40
xnoxand it will be the first time we are doing hwe on s390x subiquity iso12:40
xnoxcause there was no s390x subiquity in bionic12:40
sil2100xnox: 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 conditional12:43
xnoxsil2100:  it looks scoped correctly to me.12:44
xnoxabove the else12:44
xnoxand else is for the cdimage_install_base12:44
* xnox is not sure if i should be reindenting this stuff or not.12:44
sil2100Oh, indeed, nvm, I think my eyes got confused by the indent and lack of coffee, thanks!12:45
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (groovy-proposed) [1:20.10.4]12:51
-queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (focal-proposed) [1:20.04.13]12:56
-queuebot:#ubuntu-release- Unapproved: update-notifier (focal-proposed/main) [3.192.30.5 => 3.192.30.6] (ubuntu-desktop, ubuntu-server)13:00
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.3 => 1:20.04.10.4] (core)13:13
-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:17
sil2100xnox: you fine testing that locally? Since we could also do a cdimage build with the changes without --livefs13:18
LaneyI'm going to push that ship-live change discussed above13:21
Laneytjaalton: is there somewhere we should note this to remember to fix it when rolling the oem kernel13:21
Laney?13:21
sil2100Laney: ACK13:21
tjaaltonLaney: maybe we should have a public tracker bug for that13:22
tjaaltondon't think there is one now13:23
LaneyI was thinking like a SOP or a bug template - to roll an OEM kernel onto a new series do x, y, z13:23
tjaaltonah13:23
Laneyotherwise I predict us forgetting this part13:24
Laney:p13:24
tjaaltonheh, quite possibly13:24
Laneyok committed13:26
Laneywe must must remember to verify this worked and test an nvidia install13:26
xnoxin my local builds the seed change looks good13:49
xnoxit shows me the diff that the 5.10 stuff is gone13:49
sil2100tseliot: 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
tseliotsil2100, correct13:56
sil2100Just making sure that the other commands don't crash when ran as non-root13:57
sil2100Ok, so not a blocker then!13:57
tseliotno, they won't13:57
sil2100Thanks o/13:57
tseliotnp13:57
sil2100Guess 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 list13:57
sil2100Wonder how users encountered this cash though, by manually running the command?14:01
xnoxnot sure that arm64 subiquity was ever built with hwe before either14:09
xnoxalso not sure if my arm64 subiquity hwe changes would break arm64 desktop which i'm not sure if we are building for focal still14:10
xnoxleh sigh.14:10
xnoxand also on arm64 we probably ought to add 64k kernel installer option.14:10
xnox(for hirsute)14:10
sil2100xnox: yeah, so we are still building dailies of the arm64 desktop14:34
sil2100(for focal)14:35
xnoxsil2100:  cool.14:36
xnoxsil2100:  so i'm finding more and more issues. s390x & arm64 are now building; and my mirror was incomplete for amd64.14:37
xnoxhowever none of them have the right grub menu.14:37
xnoxie. 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:37
sil2100ugh, where is all of this coming from? Is this all from the boot-amd64 etc. scripts as well?14:40
xnoxand boot-arm6414:40
xnoxwe 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 .014:41
xnoxanyway, getting there.14:41
xnoxit also means we didn't test any of the subiquity installers with hwe kernels =)14:41
xnoxfun fun fun14:41
xnoxon any arch.14:42
sil2100Glorious14:43
ograkernels ... so overrated14:43
sil2100I 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 well14:43
sil2100Nothing like discovering such issues on a Friday before release ;)14:44
-queuebot:#ubuntu-release- New source: directx-headers (hirsute-proposed/primary) [1.0.1-0ubuntu1]14:50
sil2100xnox: ...should we just backport cd-boot-images-* to focal? ;D14:50
xnoxhar har har14:52
xnoxso. ppc64le is now perfect.14:52
xnoxarm64 one has two extra entries, will try to make it as perfect as ppc64le14:52
xnoxbut meeting time.14:52
xnoxif i don't finish i will hand-over to somebody else before eod.14:53
sil2100Thanks!14:56
sil2100I 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 this14:57
sil2100But probably vorlon would be more useful14:57
sil2100tseliot: 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:57
tseliotsil2100, yes, I think they use polkit or something like that, since apt won't let users install packages unless they have root privileges15:59
sil2100Ok, 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 ;p16:00
tseliotsil2100, it's always been this way, it's just that now it tries writing to a file before using apt, hence the different error16:04
Laneyit could do like systemd does and use polkit to get elevated permissions16:05
Laneymight be too much work :p16:05
xnoxvorlon:  does grubx64.efi on the amd64 iso come from d-i build, in focal?16:36
Eickmeyerubuntu-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:42
vorlonxnox: that is my recollection yes16:43
vorlonEickmeyer: 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 Ubuntu16:44
vorlon(in principle we want process-removals to honor sync-blacklist but in practice this is not implemented)16:45
Eickmeyervorlon: 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
vorlonEickmeyer: if you want this dropped from the blacklist now that it's back in Debian, I'm happy to remove it from the blacklist yes16:46
Eickmeyervorlon: Awesome, that would be great. :)16:46
vorlondone16:46
EickmeyerThanks. :)16:46
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.4 => 1:20.04.10.5] (core)16:48
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (focal-proposed) [20.04.15.6]16:58
* sil2100 goes AFK a bit to rest17:02
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.10.5]17:02
xnoxvorlon:  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:05
xnoxvorlon:  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
xnoxor 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:06
xnoxi am thinking to somehow download & unpack grub-efi-amd64-signed17:10
xnoxand steal the right grub from there.17:10
Eickmeyervorlon: 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:14
xnoxfakesync?17:17
xnox(from ubuntu-dev-tools)17:17
Eickmeyerxnox: Yeah, tried that, same issue.17:17
xnoxsigh17:17
xnoxEickmeyer:  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:17
xnoxEickmeyer:  do you want "to sync it from debian to ubuntu, for realz, kthxbye"?17:18
Eickmeyerxnox: Hahaha! Exactly.17:18
xnoxcool. will do.17:18
Eickmeyerxnox: You're amazing. Thanks a lot. :)17:18
xnoxvorlon:  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
xnoxbut if one strips signatures with sbattach --remove, then the two grubs are identical and comparable.17:42
xnoxso 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.17:43
xnoxsil2100:  vorlon: https://code.launchpad.net/~xnox/debian-cd/hwe-focal/+merge/39718118:07
xnoxotherwise we don't have hwe stack on the subiquity isos.18:07
xnoxas in no boot-loader menus18:07
sil2100o/18:17
sil2100Looking18:17
xnoxEickmeyer:  uploaded.18:21
sil2100Ok, for this I think I need a coffee, back to the review in a bit18:27
Eickmeyerxnox: Thanks so much! :)18:30
xnoxsil2100:  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
xnoxplus a few trials and errors to get it more or less ok.18:50
ckingsil2100, i verified 189432919:09
-queuebot:#ubuntu-release- Unapproved: ubiquity (groovy-proposed/main) [20.10.13.1 => 20.10.13.2] (desktop-core)19:13
tumbleweedI'm fixing up a bunch of old data in distro-info-data19:26
tumbleweedIs there a canonical EOL date for ESM releases?19:27
tumbleweedaccording to https://wiki.ubuntu.com/Releases 12.04 ESM should be EOL, but there's no date there19:27
tumbleweedI see ubuntu-security-status consults distro-info-data19:28
tumbleweedif I tweak eol by a couple of days, should I be tweaking eol-esm too?19:28
tumbleweedI've also seen that ESM can be available for 5 years rather than the 2 we're quoting19:29
xnoxtumbleweed:  precise ESM is no longer for sale; but as can be obviously seen precise archives are not yet removed from primary mirrors .................. sigh .....19:32
tumbleweedyeah, I gathered as much19:33
xnoxtumbleweed:  Security updates for 14.04 LTS until 2022 to trusty is defined at least on https://ubuntu.com/security/esm as 3 years of ESM19:33
xnoxand ditto for xenial Extended Security Maintenance for Ubuntu 16.04 LTS will be available April 2021 until 2024.19:34
xnoxbionic is yet to be defined.19:34
xnoxfocal has been announced in the past as offering 5 years of esm.19:34
tumbleweeddoes anyone care if I tweak the exact dates in there to match the final eol date19:34
xnoxtumbleweed:  i think it is a fair default of 3 years of esm for everything for now.19:35
tumbleweed+ 3 years19:35
xnoxtumbleweed:  bdmurray i think is off, but i think he in the past was involved in those dates.19:35
xnoxtumbleweed:  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
tumbleweedtrue19:36
xnoxtumbleweed:  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:36
tumbleweedthanks!19:37
xnoxsomething 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
tumbleweedit's kind of amazing how many off by one or two mistakes there were19:37
tumbleweedI should stop caring :P19:37
sil2100cking: thanks!19:38
sil2100Back on it now19:42
tumbleweedxnox: turns out the only tweak was to precise (2017-04-26 -> 28). It's in the past, I'm sure nobody cares.19:44
* tumbleweed tweaks eol-esm and is done with it19:45
tumbleweedhttps://salsa.debian.org/debian/distro-info-data/-/commit/c84eef6eda6c87e0bd5229e6202385202c8c440a19:47
bdmurraythanks tumbleweed19:48
tumbleweedmerging your esm patches, this should be more maintainable in the future19:48
vorlonxnox: which signed build of it> you're looking at gcdx64.efi not grubx64.efi in the source, right?19:54
vorlonxnox: and yes, we want a d-i rebuild; have you done this yet?19:54
vorlonxnox: "generate different signatures for each suite" uh?19:55
vorlonxnox, 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" please19:57
vorlonxnox: as I don't see a d-i upload in the queue, should I do one?19:57
tumbleweedvorlon: I think that'd only be Focal19:58
tumbleweedbut no ESM release has a day of the month specified, only the month19:59
vorlontumbleweed: xnox said bionic "is yet to be defined" whereas focal has been announced as 5 years19:59
tumbleweedvorlon: it has an EOL date on https://wiki.ubuntu.com/Releases19:59
tumbleweedfocal does not19:59
tumbleweedif 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 for20:00
vorlonI'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 page20:02
tumbleweedthe decleration of the date for bionic came from https://bugs.launchpad.net/ubuntu/+source/distro-info-data/+bug/184868820:02
ubot5Ubuntu bug 1848688 in distro-info-data (Ubuntu Trusty) "Add Ubuntu 20.04 Focal Fossa" [Undecided,Fix committed]20:02
tumbleweedwhich wasn't me20:02
tumbleweedbut I would have done the same thing20:02
tumbleweederr no, that's focal20:03
tumbleweedhttps://launchpad.net/ubuntu/+source/distro-info-data/0.37ubuntu0.3 - bdmurray20:03
sil2100xnox: 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 image20:05
sil2100Ah, no, I think I get it20:07
tumbleweedvorlon: https://ubuntu.com/security/esm declares 5 years for >= Bionic20:07
tumbleweedwhich I guess means 2 years (5 total - 3 LTS)20:08
vorlontumbleweed: yeah I was just about to send you that link20:08
vorlon:)20:08
tumbleweedoh, no that is LTS + 5 years20:10
Odd_BlokeIt actually declares "up to" 5 years, which is less categorical.20:11
tumbleweedyeah, but I need a date20:12
tumbleweedand eol + 5 years is what ubuntu is currently carrying20:12
Odd_BlokeYeah, I agree that's your best option for a date.20:15
tumbleweedat some point, we probably need a more complex data structure to be able to carry nuance like announced vs expected20:16
-queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.15.5 => 20.04.15.6] (core)20:16
-queuebot:#ubuntu-release- Unapproved: debian-installer (focal-proposed/main) [20101020ubuntu614.1 => 20101020ubuntu614.2] (core)20:18
sil2100xnox: ok, I think this is almost +1 - just had one quick question there, inline20:21
vorlonsil2100: ^^ do you want to review this trivial d-i upload or should I self-accept?20:23
sil2100vorlon: I'll just glance it real quick20:24
sil2100ahaha20:25
sil2100Ok20:25
sil2100Forgot it's just the rebuild, ugh20:25
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (focal-proposed) [20101020ubuntu614.2]20:26
sil2100vorlon: 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 question20:29
vorlondarn, I was hoping you wouldn't ask ;)20:30
vorlonyes, I'll look20:30
sil2100Thanks ;) I'd merged it if not for my worry about those HWE entries for desktop suddenly appearing20:32
sil2100s/merged/merge20:35
vorlonsil2100: bleurgh, ftbfs20:46
vorlon(d-i)20:46
vorlonI'll chase it up after the debian-cd review unless you want to look at it20:46
vorlonlolwut, xfsprogs upstream regressed its architecture support and now ftbfs on riscv6420:53
vorlonsil2100: addressed your open question on the hwe mp; doing a more thorough review now20:56
vorlonalso I really want to change this code to say "KERNEL_PREFICES"20:56
-queuebot:#ubuntu-release- Packageset: Added p7zip to i386-whitelist in hirsute20:58
-queuebot:#ubuntu-release- Packageset: Added rpm to i386-whitelist in hirsute20:58
xnoxsil2100:  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:02
juliankvorlon: eww, KERNEL_PREFICES is just wrong21:06
vorlon;)21:06
juliankit's an interesting word because you'd think it's like matrix, but it isn't21:07
juliankthe plural of praefixum being praefixa21:08
julianklatin weird21:08
vorlonjuliank: cool, didn't know that, just was enjoying making the false analogy21:09
juliankvorlon: 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%2Cc021:11
juliankwell just late 70s really21:11
sil2100xnox: got it!21:12
vorlonxnox: 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
vorlonxnox: without that, this debian-cd change seems less useful?21:16
vorlonsil2100: ^^21:17
vorlond-i build failure: "Disk full' on mcopy -i./tmp/netboot/boot.img ./tmp/netboot/initrd.gz ::initrd.gz :P21:18
sil2100Another FLOPPY_SIZE bump?21:20
vorlonyeah21:20
sil2100Test building with a 5MB bump in a PPA21:23
vorlonsil2100: so you'll take care of this change?21:23
sil2100vorlon: I can!21:24
vorlonsil2100: might want to also wait for xnox to respond wrt the missing hwe-* trees under installer-$arch in the archive before uploading21:25
sil2100I 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
sil2100Since in the morning I wanted to prep the d-i hwe additions already, have even an almost-done package21:26
vorlonsil2100: 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:27
sil2100vorlon: 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 - silly21:34
vorlonsil2100: whereas I feel better not having additional dead and broken code branches as future pitfalls :)21:34
sil2100hah, I think we can remove it in that case ;) But it does make me feel uneasy!21:41
ckingsil2100, what was the status of the zfsutils-linux and grub being blocked in proposed?22:20
sil2100Let me try that now22:25
ckingthanks22:27
sil2100vorlon: 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:29
vorlonsil2100: yes22:48
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [sync] (focal-proposed) [20101020ubuntu614.3]22:58
sil2100xnox, 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 code23:00
vorlonsil2100: yeah I can follow through23:03
sil2100Thank you o/ If anything needs doing just drop me a msg on mm23:12
-queuebot:#ubuntu-release- New binary: gevent-websocket [amd64] (hirsute-proposed/universe) [0.10.1-4] (no packageset)23:23
-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:26
-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]23:27

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!