[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] <xnox> aaaaaaaaaaaaaaa
[11:47] <xnox> where is sil
[11:48] <xnox> 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] <xnox> could you please take a look?
[11:50] <sil2100> o/
[11:51] <sil2100> Oh, ok, forgot about this step, might need to write it down somewhere
[11:51] <sil2100> On it now
[11:52] <tjaalton> sil2100: fyi, linux-firmware is verified now
[11:52] <tjaalton> on focla
[11:52] <tjaalton> focal
[11:52] <sil2100> tjaalton: thanks! :)
[11:54] <sil2100> xnox: merged and deployed
[11:54] <Laney> woohoo work saved
[11:54] <xnox> sil2100:  thank you!
[11:55] <xnox> Laney:  =)))))) i think sil2100 felt disturbance in the force that somebody is trying to bypass him to touch debian-cd.
[11:55] <sil2100> xnox: ...and modding the checklist to make sure I don't miss it during 22.04.2 :D
[11:55] <xnox> 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] <Laney> that's good because I don't understand how that variable is used so I would have had to learn
[11:55] <sil2100> Good thing there's xnox always with a watchful eye!
[11:55] <xnox> sil2100:  since we now always have hwe metapackages. we could be always generating hwe menu entries in subquity.
[11:56] <Laney> https://paste.ubuntu.com/p/7NvZwBrzfz/
[11:56] <Laney> gibberish
[11:56] <xnox> 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] <sil2100> Laney: just the way we like it
[11:57] <xnox> Laney:  i think that hunk is not used, because that's d-i image stuff ?!
[11:57] <Laney> who knows
[11:57]  * xnox was looking into tools/boot/focal/boot-amd64 script
[11:57] <Laney> that bit is slightly more understandable
[11:59] <sil2100> 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] <sil2100> 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] <xnox> sil2100:  as we now found out on the desktop, right?! =)
[12:00] <sil2100> Yeah ;)
[12:06] <tjaalton> 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] <tjaalton> on the image
[12:07] <tjaalton> then the metapackage to pull would be -oem-20.04b
[12:07] <tjaalton> 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] <xnox> 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] <xnox> unless things have changed =)
[12:16] <xnox> tjaalton:  do we have oem-metas that reference oem-20.04b on the iso itself?
[12:17] <tjaalton> that's correct, but the image probably has no need for 5.6 anyway. most of the migrations have happened already aiui
[12:17] <tjaalton> the image didn't seem to have 20.04b meta, so I'd say no?
[12:18] <tjaalton> anyway, they're testing 5.10 now and should have results before the end of the week
[12:24] <xnox> tjaalton:  i'm just worried about image size of 3 x (kernel + lrm) stacks.
[12:25] <tjaalton> sure, I'm pretty confident 5.6 will get dropped
[12:26] <Laney> O_O
[12:28] <tjaalton> also, I'm forced to respin 5.10 but it should get in updates by tuesday
[12:29] <tjaalton> 5.6 has a security update respin
[12:29] <xnox> somehow i don't see meta, but linux-image-5.10.0-1011-oem is on the iso
[12:29] <tjaalton> yeah I'm not sure how it got there..
[12:29] <xnox> i wonder if our globs for nvidia or some such pull that in.
[12:30] <xnox> tjaalton:  yeap we pull in linux-modules-nvidia-460-oem-20.04
[12:30] <xnox> wait
[12:30] <xnox> and this one too linux-modules-nvidia-460-oem-20.04b
[12:31] <tjaalton> ah
[12:31] <xnox> so 3x nvidia, with 2.5x of kernels =)
[12:35] <Laney> I thought 5.6 was meant to be dropped
[12:36] <tjaalton> aiui they want to test that 5.10 at least boots up
[12:36] <tjaalton> on the machines that now use 5.6
[12:36] <tjaalton> hmm
[12:36] <tjaalton> though most should use hwe
[12:37] <tjaalton> anyway, rex knows more :)
[12:37] <Laney> 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] <tjaalton> yes
[12:37] <tjaalton> but timing for the .2 image was challenging
[12:46] <sil2100> xnox: hm, can we consider https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/1905274 verified?
[12:58] <xnox> sil2100:  yes, commented.
[12:58] <xnox> sil2100: focal verified for realz. groovy is hand wave.
[13:48] <tseliot> hey sil2100 , can you approve LP: #1904583 for bionic too, please? (so that we can verify it)
[14:00] <sil2100> tseliot: adding it to my TODO o/
[14:00] <sil2100> xnox: thanks!
[14:00] <tseliot> sil2100, thanks a lot :)
[14:01] <sil2100> 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] <cking> 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] <slyon> 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] <slyon> It's not normal that they fail so often in a row
[14:07] <sil2100> Ok
[14:08] <slyon> Let me quickly try if I can reporduce them in a local autopkgtest
[14:11] <xnox> cking: any uploader can retry tests with extra packages from proposed, or everything from proposed. you know that right?
[14:12] <xnox> and grub-zfstestsuite seems to need the same fixes as zsys. looking into that.
[14:15] <xnox> trying to upload grub-zfstestsuite that doesn't ftbfs
[14:34] <cking> xnox, ack, thanks
[14:35] <slyon> 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] <slyon> But I think you should be fine releasing glib2.0
[15:27] <xnox> cking:  calling a pass.
[15:27] <xnox> # github.com/ubuntu/grubmenugen-zfs-tests_test [github.com/ubuntu/grubmenugen-zfs-tests.test]
[15:27] <xnox> ./disk_handler_test.go:248:38: not enough arguments in call to zfs.DatasetSnapshot
[15:27] <xnox> 	have (string, bool, map[zfs.Prop]zfs.Property)
[15:28] <xnox> 	want (string, bool, map[zfs.Prop]zfs.Property, map[string]string)
[15:28] <xnox> didrocks999:  can you please fix grub-zfstestsuite too?
[15:58] <didrocks999> 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] <didrocks999> 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] <xnox> i see
[16:01] <xnox> didrocks999:  i wonder if i should help rebasing that.
[16:01] <xnox> cking:  sigh
[16:01] <xnox> didrocks999:  cking: sounds like we will need to ping ubuntu-release to allow things to migrate.
[16:03] <didrocks999> yeah, that’s what I suggested cking, it’s only a testsuite anyway so it can stay in proposed
[16:03] <didrocks999> xnox: if you want, there is a bunch of patches, but the most important part and time consuming is testing grub
[16:12] <cking> ugh, what a pain
[16:17] <didrocks999> 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] <vorlon> if anyone else is having trouble finding that package, it's apparently grubzfs-testsuite in the archive
[16:19] <cking> didrocks999, so I did ask a coupla hours ago in this channel, not sure what else I need to do
[16:22] <didrocks999> 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] <cking> +1 ^
[16:24] <sil2100> 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] <didrocks999> thanks sil2100!
[16:57] <sil2100> 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] <xnox> vorlon:  oooh, components missmatches in maas seed in focal and needs promotion => pxelinux (deb) from the syslinux source
[16:58] <xnox> (and they try to do testing/building with main only)
[16:58] <sil2100> bdmurray: if you could verify at least groovy and focal tzdata, that would be awesome
[16:58] <vorlon> 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] <vorlon> (the git branch is a bit behind so I'll need to ask rbalint for a reimport)
[16:59] <sil2100> hm, not sure how many tools from there are used by the publisher and such
[17:00] <vorlon> xnox: in *focal*?
[17:00] <sil2100> 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] <vorlon> 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] <bdmurray> sil2100: okay
[17:01] <bdmurray> vorlon: I've one MP outstanding for ubuntu-archive-tools
[17:01] <xnox> vorlon:  and in hirsute too pxelinux syslinux-common
[17:01] <vorlon> bryce: ack
[17:01] <xnox> vorlon:  they got dropped when we moved off them, but maas still uses them.
[17:01] <vorlon> xnox: how did it end up as a c-m in focal?
[17:02] <xnox> vorlon:  by getting seeded into maas-supported seed by me.
[17:02] <xnox> (sponsoring merge proposal from maas team)
[17:02] <xnox> vorlon:  it's stuff inside the maas snap / boot-resources maas stream.
[17:03] <vorlon> mm
[17:03] <xnox> pxelinux syslinux-common => both should be in main in focal & hirsute.
[17:03] <xnox> vorlon:  unless you disagree with how to pxeboot?
[17:03] <vorlon> xnox: I generally disagree with changing seeds in stable releases :)
[17:04] <xnox> vorlon:  i can ask for clarifications.
[17:04] <vorlon> I suppose it's a special case where there was an untracked dependency that was only detected post-release
[17:05] <xnox> yeah, that.
[17:06] <Laney> I would actively enjoy it if ubuntu-archive-tools were to be migrated
[17:07] <vorlon> Laney: any concerns about timing?
[17:07] <vorlon> 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] <Laney> not for my own checkout
[17:08] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-202.234]
[17:09] <Laney> 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] <Laney> probably low likelihood
[17:10] <vorlon> xnox: syslinux source is in main in focal, promoting the binaries requires republishing focal-updates, I'm inclined to punt
[17:11] <xnox> vorlon:  after pooint release? we publish focal-updates all the time.....
[17:11] <rbalint> vorlon, please ping me when everything is ready and i'll do the reimport
[17:11] <vorlon> rbalint: thanks
[17:12] <vorlon> 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] <xnox> vorlon:  ack!
[17:12] <xnox> gotcha.
[17:17] <vorlon> 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] <bdmurray> sil2100: tzdata verified for F and G
[17:40] <xnox> 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] <xnox> 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] <cjwatson> 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] <vorlon> 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
[17:55] <vorlon> 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] <xnox> vorlon:  the target so far is to move maas-images to next lts around/after .1 release.
[17:56] <xnox> vorlon:  should we do something of the same effect earlier?
[17:57] <vorlon> 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] <xnox> or like have ~ubuntu-cdimage owned pipeline that builds maas-images ?
[17:57] <xnox> or even building out of devel?
[17:57] <cjwatson> vorlon: yeah
[17:57] <vorlon> xnox: they ought to have a CI pipeline for devel, independent of what release they use for production
[17:57] <xnox> vorlon:  i wonder if we should have per-series boot-resources builds anyway.
[17:57] <xnox> vorlon:  ack.
[17:58] <vorlon> xnox: I'm fine not having per-series boot resources, I just want them checking this stuff against trunk :)
[17:58] <vorlon> xnox: and where are you having this conversation w/ Lee given that he's not in this channeL?
[17:59] <xnox> vorlon:  ~secureboot-maas
[17:59] <xnox> vorlon:  my special place where i have maas team on demand =)
[18:00] <vorlon> >_<
[18:00] <xnox> 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] <bdmurray> sil2100: I'm looking at the tzdata autopkgtest failures now
[18:12] <tseliot> 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] <kanashiro> 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] <sil2100> bdmurray: thanks!
[18:45] <kanashiro> we would be following what debian already did
[19:03] <kanashiro> it will also unblock many ruby libraries that are stuck in proposed at the moment
[19:51] <bdmurray> sil2100: tzdata is all SRU'ed and autopkgtests have passed.
[19:51] <bdmurray> SRU verified
[19:51] <vorlon> 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
[20:11] <vorlon> 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] <vorlon> 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] <vorlon> also why is there a grub-common service on s390x :P
[20:35] <sil2100> bdmurray: thanks!
[20:37] <sil2100> 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] <sil2100> So wtf
[20:37] <sil2100> Oh, wait, one time it was unittests.sh that also failed, uh
[20:38] <sil2100> So it's not reliably failing the same thing!
[21:01] <vorlon> sil2100: yeah :/
[21:07] <bdmurray> vorlon: speaking of things not to phase - language-pack-* ?
[21:32] <xnox> vorlon:  i don't know why we build grub-common deb on s390x.
[21:36] <vorlon> xnox: well if we didn't then ubuntu-image would currently be uninstallable
[21:36] <vorlon> bdmurray: sounds right to me
[21:37] <bdmurray> so sil2100 you might want to fully phase those
[21:55] <sil2100> 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)
[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)