=== philroche_ is now known as philroche === guiverc2 is now known as guiverc [05:18] -queuebot:#ubuntu-release- New binary: linkchecker [amd64] (hirsute-proposed/none) [10.0.0-1] (no packageset) [05:21] -queuebot:#ubuntu-release- New binary: linkchecker [arm64] (hirsute-proposed/none) [10.0.0-1] (no packageset) [05:21] -queuebot:#ubuntu-release- New binary: linkchecker [armhf] (hirsute-proposed/none) [10.0.0-1] (no packageset) [05:23] -queuebot:#ubuntu-release- New binary: linkchecker [ppc64el] (hirsute-proposed/none) [10.0.0-1] (no packageset) [05:23] -queuebot:#ubuntu-release- New binary: linkchecker [s390x] (hirsute-proposed/none) [10.0.0-1] (no packageset) [05:38] -queuebot:#ubuntu-release- New binary: linkchecker [riscv64] (hirsute-proposed/universe) [10.0.0-1] (no packageset) [08:18] -queuebot:#ubuntu-release- Unapproved: barbican (focal-proposed/main) [1:10.0.0-0ubuntu0.20.04.1 => 1:10.0.0-0ubuntu0.20.04.2] (openstack, ubuntu-server) [09:34] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (groovy-proposed) [2021a-0ubuntu0.20.10] [09:43] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (focal-proposed) [2021a-0ubuntu0.20.04] [09:56] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (bionic-proposed) [2021a-0ubuntu0.18.04] [10:06] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (xenial-proposed) [2021a-0ubuntu0.16.04] [10:09] -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (focal-proposed) [11ubuntu5.3] [10:39] -queuebot:#ubuntu-release- Unapproved: friendly-recovery (groovy-proposed/main) [0.2.41 => 0.2.41ubuntu0.20.10.1] (core) [10:41] -queuebot:#ubuntu-release- Unapproved: friendly-recovery (focal-proposed/main) [0.2.41 => 0.2.41ubuntu0.20.04.1] (core) [10:42] -queuebot:#ubuntu-release- Unapproved: friendly-recovery (bionic-proposed/main) [0.2.38ubuntu1.1 => 0.2.38ubuntu1.2] (core) [11:31] -queuebot:#ubuntu-release- Unapproved: rejected binutils [source] (focal-proposed) [2.34-6ubuntu1.1] [11:47] aaaaaaaaaaaaaaa [11:47] where is sil [11:48] Laney: https://code.launchpad.net/~xnox/debian-cd/activate-focal-hwe-kernel/+merge/397085 we have started to build hwe things in livefs (via livecd-rootfs change) and new server subiquity images do have both generic & hwe kernels initrds etc. Now need to trigger generation of the boot menu entries. [11:48] could you please take a look? [11:50] o/ [11:51] Oh, ok, forgot about this step, might need to write it down somewhere [11:51] On it now [11:52] sil2100: fyi, linux-firmware is verified now [11:52] on focla [11:52] focal [11:52] tjaalton: thanks! :) [11:54] xnox: merged and deployed [11:54] woohoo work saved [11:54] sil2100: thank you! [11:55] Laney: =)))))) i think sil2100 felt disturbance in the force that somebody is trying to bypass him to touch debian-cd. [11:55] xnox: ...and modding the checklist to make sure I don't miss it during 22.04.2 :D [11:55] sil2100: well, for 22.04.2 and/or even now, i do wonder if I can somehow make it do the right right always. [11:55] that's good because I don't understand how that variable is used so I would have had to learn [11:55] Good thing there's xnox always with a watchful eye! [11:55] sil2100: since we now always have hwe metapackages. we could be always generating hwe menu entries in subquity. [11:56] https://paste.ubuntu.com/p/7NvZwBrzfz/ [11:56] gibberish [11:56] Laney: let's pretend i understand how it works. looking at boot-amd64 it sort of looks like it would work right. but we shall see. [11:56] Laney: just the way we like it [11:57] Laney: i think that hunk is not used, because that's d-i image stuff ?! [11:57] who knows [11:57] * xnox was looking into tools/boot/focal/boot-amd64 script [11:57] that bit is slightly more understandable [11:59] What I wouldn't want is for us to provide the boot entry all the time, even when the hwe meta package still points to the GA kernel - since that would be confusing to users [12:00] So we'd have to add some smarts to make sure it's pointing at the hwe kernel but ignoring it if hwe = ga [12:00] sil2100: as we now found out on the desktop, right?! =) [12:00] Yeah ;) [12:06] btw, the image has packages for both 5.6 & 5.10 oem kernels, and folks are now testing if 5.10 should replace 5.6 [12:07] on the image [12:07] then the metapackage to pull would be -oem-20.04b [12:07] 5.6 will be obsolete in a month [12:13] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-202.234] (core, kernel) [12:15] tjaalton: well, i thought it wasn't that straight forward. some 5.6-oem will move onto 5.8-hwe; and some will start off with 5.10-oem; and some will upgrade from 5.6-oem to 5.10-oem. [12:15] unless things have changed =) [12:16] tjaalton: do we have oem-metas that reference oem-20.04b on the iso itself? [12:17] that's correct, but the image probably has no need for 5.6 anyway. most of the migrations have happened already aiui [12:17] the image didn't seem to have 20.04b meta, so I'd say no? [12:18] anyway, they're testing 5.10 now and should have results before the end of the week [12:24] tjaalton: i'm just worried about image size of 3 x (kernel + lrm) stacks. [12:25] sure, I'm pretty confident 5.6 will get dropped [12:26] O_O [12:28] also, I'm forced to respin 5.10 but it should get in updates by tuesday [12:29] 5.6 has a security update respin [12:29] somehow i don't see meta, but linux-image-5.10.0-1011-oem is on the iso [12:29] yeah I'm not sure how it got there.. [12:29] i wonder if our globs for nvidia or some such pull that in. [12:30] tjaalton: yeap we pull in linux-modules-nvidia-460-oem-20.04 [12:30] wait [12:30] and this one too linux-modules-nvidia-460-oem-20.04b [12:31] ah [12:31] so 3x nvidia, with 2.5x of kernels =) [12:35] I thought 5.6 was meant to be dropped [12:36] aiui they want to test that 5.10 at least boots up [12:36] on the machines that now use 5.6 [12:36] hmm [12:36] though most should use hwe [12:37] anyway, rex knows more :) [12:37] right, machines go to hwe or new oem as required, then old oem goes away, that's what I thought the idea was [12:37] yes [12:37] but timing for the .2 image was challenging [12:46] xnox: hm, can we consider https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/1905274 verified? [12:47] Ubuntu bug 1905274 in u-boot (Ubuntu Groovy) "enable u-boot spl for riscv64" [Undecided,Fix committed] [12:58] sil2100: yes, commented. [12:58] sil2100: focal verified for realz. groovy is hand wave. [13:48] hey sil2100 , can you approve LP: #1904583 for bionic too, please? (so that we can verify it) [13:48] Launchpad bug 1904583 in ubuntu-drivers-common (Ubuntu Bionic) "SRU: Backport the latest developments on drivers detection and hybrid graphics" [Medium,In progress] https://launchpad.net/bugs/1904583 [14:00] tseliot: adding it to my TODO o/ [14:00] xnox: thanks! [14:00] sil2100, thanks a lot :) [14:01] slyon: hey! http://autopkgtest.ubuntu.com/packages/n/netplan.io/focal/amd64 <- did you take a look at those? Since I was thinking about releasing glib2.0, but I see this one is happening all the time - it feels flaky as everytime a different test fails, so I guess it's nothing scary, right? [14:04] hi there, zsys and zfsutils-linux for hirsute are stuck in proprosed migration, is it possible to add a hint skipping the implicit dependency (grubzfs-testsuite) and get it moving? [14:06] hey sil2100 ! Yes, I looked into them. looked like flaky timeouts which happen from time to time. But I'm not sure why it fails everytime... [14:06] It's not normal that they fail so often in a row [14:07] Ok [14:08] Let me quickly try if I can reporduce them in a local autopkgtest [14:11] cking: any uploader can retry tests with extra packages from proposed, or everything from proposed. you know that right? [14:12] and grub-zfstestsuite seems to need the same fixes as zsys. looking into that. [14:15] trying to upload grub-zfstestsuite that doesn't ftbfs [14:34] xnox, ack, thanks [14:35] sil2100: the "bonds" test passed locally. So it seems to be flaky indeed. Flakyness seems to have become more intense as of glib2.0/2.64.6-1~ubuntu20.04.1, though. [14:36] But I think you should be fine releasing glib2.0 [15:27] cking: calling a pass. [15:27] # github.com/ubuntu/grubmenugen-zfs-tests_test [github.com/ubuntu/grubmenugen-zfs-tests.test] [15:27] ./disk_handler_test.go:248:38: not enough arguments in call to zfs.DatasetSnapshot [15:27] have (string, bool, map[zfs.Prop]zfs.Property) [15:28] want (string, bool, map[zfs.Prop]zfs.Property, map[string]string) [15:28] didrocks999: can you please fix grub-zfstestsuite too? === alan_g_ is now known as alan_g [15:58] xnox: not immediatly, this one depends on a grub with patched behavior. However, when we prepared both grub-zfstestsuite, an out of VCS upload was done by foundation, and so, we need to rebase our commits which is a nightmare (+redo all the work and testing). No time for this right now [15:59] this is why I told cking that it’s ok to hint to skip grub-zfstestsuite behavior [16:00] -queuebot:#ubuntu-release- Unapproved: dpdk (focal-proposed/main) [19.11.3-0ubuntu0.2 => 19.11.6-0ubuntu0.20.04.1] (kernel-dkms, ubuntu-server) [16:00] -queuebot:#ubuntu-release- Unapproved: dpdk (groovy-proposed/main) [19.11.5-1 => 19.11.6-0ubuntu0.20.10.1] (kernel-dkms, ubuntu-server) [16:01] i see [16:01] didrocks999: i wonder if i should help rebasing that. [16:01] cking: sigh [16:01] didrocks999: cking: sounds like we will need to ping ubuntu-release to allow things to migrate. [16:03] yeah, that’s what I suggested cking, it’s only a testsuite anyway so it can stay in proposed [16:03] xnox: if you want, there is a bunch of patches, but the most important part and time consuming is testing grub [16:12] ugh, what a pain [16:17] cking: really, as told by email, just ask for an hint on autopkgtests to skip the grub-zfstestsuite, there is no impact on this one anyway and this is on my list to spend again a full day on it redoing the work that was overridden by previous grub upload [16:19] if anyone else is having trouble finding that package, it's apparently grubzfs-testsuite in the archive [16:19] didrocks999, so I did ask a coupla hours ago in this channel, not sure what else I need to do [16:22] sil2100: mind hinting zfs-linux and zsys to transition to the release pocket, skipping grubzfs-testsuite autopkgtests failure (as we will let it in -proposed) ^ [16:22] +1 ^ [16:24] didrocks999: I can look at it after the meeting and after some SRU releases for .2! ;) [16:25] * cking suddenly realizes he didn't ask clearly enough, doh [16:25] thanks sil2100! [16:57] cking: in the meantime, could you take a look at https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1894329 verification for focal? Since I guess it would be good to get that for .2? [16:57] Ubuntu bug 1894329 in coreutils (Ubuntu) "ZFS revert from grub menu not working." [High,Incomplete] [16:57] vorlon: oooh, components missmatches in maas seed in focal and needs promotion => pxelinux (deb) from the syslinux source [16:58] (and they try to do testing/building with main only) [16:58] bdmurray: if you could verify at least groovy and focal tzdata, that would be awesome [16:58] ubuntu-archive: we have a migration prepared for moving ubuntu-archive-tools from bzr to git (https://code.launchpad.net/~rbalint/ubuntu-archive-tools/bzr-to-git/+merge/384436). Is there a good/bad time to do this migration? [16:59] (the git branch is a bit behind so I'll need to ask rbalint for a reimport) [16:59] hm, not sure how many tools from there are used by the publisher and such [17:00] xnox: in *focal*? [17:00] So you're probably more familiar with what risk that could introduce - I just know that for image build and publishing we have a local copy on ancientminister and that won't break anything [17:01] sil2100: I would handle migrating the snakefruit and anonster checkouts, it's more about coordinating with the archive team to update their local checkouts and retarget any in-progress MPs [17:01] sil2100: okay [17:01] vorlon: I've one MP outstanding for ubuntu-archive-tools [17:01] vorlon: and in hirsute too pxelinux syslinux-common [17:01] bryce: ack [17:01] vorlon: they got dropped when we moved off them, but maas still uses them. [17:01] xnox: how did it end up as a c-m in focal? [17:02] vorlon: by getting seeded into maas-supported seed by me. [17:02] (sponsoring merge proposal from maas team) [17:02] vorlon: it's stuff inside the maas snap / boot-resources maas stream. [17:03] mm [17:03] pxelinux syslinux-common => both should be in main in focal & hirsute. [17:03] vorlon: unless you disagree with how to pxeboot? [17:03] xnox: I generally disagree with changing seeds in stable releases :) [17:04] vorlon: i can ask for clarifications. [17:04] I suppose it's a special case where there was an untracked dependency that was only detected post-release [17:05] yeah, that. [17:06] I would actively enjoy it if ubuntu-archive-tools were to be migrated [17:07] Laney: any concerns about timing? [17:07] we do have rather a few outstanding MPs which I think is why this didn't get done sooner; I'll try to garden those before pulling the trigger [17:07] not for my own checkout [17:08] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-202.234] [17:09] Only if there's a problem for the point release which needs a fix there and it doesn't get deployed because some server's copy didn't get switched over yet [17:09] probably low likelihood [17:10] xnox: syslinux source is in main in focal, promoting the binaries requires republishing focal-updates, I'm inclined to punt [17:11] vorlon: after pooint release? we publish focal-updates all the time..... [17:11] vorlon, please ping me when everything is ready and i'll do the reimport [17:11] rbalint: thanks [17:12] xnox: not even then. I don't want to do a re-publish of a package to -updates for no other reason than a binary c-m fix when the source is already in main and it is therefore already tracked for security support [17:12] vorlon: ack! [17:12] gotcha. [17:17] tseliot: nvidia-graphics-drivers-435 source is in hirsute with no binaries; should it be removed? (noticed because it's currently in the i386 whitelist, but is no longer after a refresh) [17:22] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (bionic-proposed) [1:0.8.6.3~0.18.04.1] [17:26] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-prime [source] (bionic-proposed) [0.8.15.3~0.18.04.1] [17:37] sil2100: tzdata verified for F and G [17:40] vorlon: lp:maas-images are moving from using bionic bootloaders to using focal ones; since we are not choosing to republish syslinux into main unchanged, it means ltrager will have to change lp:maas-images to enable universe to pull pxelinux. [17:41] but otherwise ~foundations-bugs are still on the hook to maintain it. [17:41] * cjwatson has no concerns about u-a-t if somebody else is dealing with the migration and chasing down things like clones on snakefruit :) [17:42] we've been pointing people at tools like copy-package there for some time, so it's probably worth doing a wiki search (including {help,dev}.launchpad.net) and actively notifying people like IS who might be heavy users [17:43] -queuebot:#ubuntu-release- Packageset: Removed libcroco from i386-whitelist in hirsute [17:43] -queuebot:#ubuntu-release- Packageset: Removed nvidia-graphics-drivers-435 from i386-whitelist in hirsute [17:43] -queuebot:#ubuntu-release- Packageset: Removed uthash from i386-whitelist in hirsute [17:43] -queuebot:#ubuntu-release- Packageset: Added libbpf to i386-whitelist in hirsute [17:43] -queuebot:#ubuntu-release- Packageset: Added libfile-dirlist-perl to i386-whitelist in hirsute [17:43] -queuebot:#ubuntu-release- Packageset: Added libfile-touch-perl to i386-whitelist in hirsute [17:43] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-460-server to i386-whitelist in hirsute [17:51] xnox: ok; I don't really want maas-images pulling arbitrarily from universe, but OTOH if we're not going to have a feedback loop that enforces main-ness before release I'm not sure whether there's much value === ijohnson is now known as ijohnson|lunch [17:55] cjwatson: good points - though in the worst case users will update their checkouts and get a README pointing them elsewhere so I'm not too fussed if we miss a spot [17:56] vorlon: the target so far is to move maas-images to next lts around/after .1 release. [17:56] vorlon: should we do something of the same effect earlier? [17:57] xnox: which is not the point at which we should be getting feedback from the MAAS team that packages need to be promoted to main for the release [17:57] or like have ~ubuntu-cdimage owned pipeline that builds maas-images ? [17:57] or even building out of devel? [17:57] vorlon: yeah [17:57] xnox: they ought to have a CI pipeline for devel, independent of what release they use for production [17:57] vorlon: i wonder if we should have per-series boot-resources builds anyway. [17:57] vorlon: ack. [17:58] xnox: I'm fine not having per-series boot resources, I just want them checking this stuff against trunk :) [17:58] xnox: and where are you having this conversation w/ Lee given that he's not in this channeL? [17:59] vorlon: ~secureboot-maas [17:59] vorlon: my special place where i have maas team on demand =) [18:00] >_< [18:00] vorlon: i'll open maas-images project bug report about that. [18:08] -queuebot:#ubuntu-release- Unapproved: cinder (groovy-proposed/main) [2:17.0.1-0ubuntu1 => 2:17.0.1-0ubuntu2] (openstack) [18:10] -queuebot:#ubuntu-release- Unapproved: cinder (bionic-proposed/main) [2:12.0.10-0ubuntu1 => 2:12.0.10-0ubuntu2] (openstack, ubuntu-server) [18:10] -queuebot:#ubuntu-release- Unapproved: cinder (focal-proposed/main) [2:16.2.1-0ubuntu1 => 2:16.2.1-0ubuntu2] (openstack, ubuntu-server) [18:12] sil2100: I'm looking at the tzdata autopkgtest failures now [18:12] vorlon, it can be removed, since I think we have transitional packages for it [18:38] -queuebot:#ubuntu-release- Unapproved: python-pip (focal-proposed/universe) [20.0.2-5ubuntu1.1 => 20.0.2-5ubuntu1.2] (no packageset) [18:39] -queuebot:#ubuntu-release- Unapproved: python-virtualenv (focal-proposed/universe) [20.0.17-1 => 20.0.17-1ubuntu0.1] (no packageset) [18:44] ubuntu-archive: I need some removals from hirsute to unblock ruby-faraday{,-middleware} migration. You can find all the details in LP #1913596 and LP #1913598 [18:44] Launchpad bug 1913596 in ruby-puppet-forge (Ubuntu) "autopkgtest failure is blocking ruby-faraday{,-middleware} in hirsute-proposed" [Undecided,New] https://launchpad.net/bugs/1913596 [18:44] Launchpad bug 1913598 in ruby-faraday-middleware (Ubuntu) "[RM] autopkgtest failure is blocking ruby-faraday{,-middleware} in hirsute-proposed" [Undecided,New] https://launchpad.net/bugs/1913598 [18:44] bdmurray: thanks! [18:45] we would be following what debian already did [19:03] it will also unblock many ruby libraries that are stuck in proposed at the moment [19:51] sil2100: tzdata is all SRU'ed and autopkgtests have passed. [19:51] SRU verified [19:51] xnox: why does boost1.74 not build libboost-iostreams1.74-dev on i386? (thin-provisioning-tools wants it) [19:58] -queuebot:#ubuntu-release- Packageset: Removed libesmtp from i386-whitelist in hirsute [19:58] -queuebot:#ubuntu-release- Packageset: Removed libnet from i386-whitelist in hirsute [19:58] -queuebot:#ubuntu-release- Packageset: Added libudfread to i386-whitelist in hirsute === ijohnson|lunch is now known as ijohnson [20:11] xnox: I guess the answer is you pruned everything not known to be needed; straightforward enough. I'm readding now [20:14] * enyc meows [20:16] sil2100: https://autopkgtest.ubuntu.com/packages/u/ubuntu-image/hirsute/s390x this is crazypants... why are tests consistently failing on s390x due to failure to start the grub-common.service, only with the new python3-defaults, and passing otherwise? [20:16] also why is there a grub-common service on s390x :P [20:35] bdmurray: thanks! [20:37] vorlon: uh, I'd have to take a look, but that sounds weird! And it seems to be happening only for the qa tests, and that depends on @buildeps@ and uh, git [20:37] So wtf [20:37] Oh, wait, one time it was unittests.sh that also failed, uh [20:38] So it's not reliably failing the same thing! [21:01] sil2100: yeah :/ [21:07] vorlon: speaking of things not to phase - language-pack-* ? [21:32] vorlon: i don't know why we build grub-common deb on s390x. [21:36] xnox: well if we didn't then ubuntu-image would currently be uninstallable [21:36] bdmurray: sounds right to me [21:37] so sil2100 you might want to fully phase those [21:55] bdmurray: yeah, will do [22:17] -queuebot:#ubuntu-release- Unapproved: update-manager (groovy-proposed/main) [1:20.10.2 => 1:20.10.3] (core) [22:41] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.3 => 1:20.04.10.4] (core) [22:56] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (groovy-proposed) [1:20.10.3] [22:57] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (focal-proposed) [1:20.04.10.4] [22:59] -queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.15.5 => 20.04.15.6] (core) [23:28] -queuebot:#ubuntu-release- New binary: adios [s390x] (hirsute-proposed/none) [1.13.1-27] (no packageset) [23:32] -queuebot:#ubuntu-release- New binary: adios [amd64] (hirsute-proposed/universe) [1.13.1-27] (no packageset) [23:32] -queuebot:#ubuntu-release- New binary: adios [ppc64el] (hirsute-proposed/universe) [1.13.1-27] (no packageset) === fabiomirmar_ is now known as fabiomirmar [23:55] -queuebot:#ubuntu-release- New binary: adios [arm64] (hirsute-proposed/universe) [1.13.1-27] (no packageset) [23:55] -queuebot:#ubuntu-release- New binary: adios [armhf] (hirsute-proposed/universe) [1.13.1-27] (no packageset)