[02:18] I'm having trouble understanding why ubuntustudio-meta isn't migrating. Literally metapackages, and there's nothing in update-excuses that tells anything. [02:22] Eickmeyer[m]: when update_excuses doesn't explain, you have to look to https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ; which shows that the new version becomes uninstallable on riscv64 [06:41] ok, second round of cleanups for DPDK now that OVS/netplan is resolved [06:41] asking for ubuntu-archive again for some more binary main->universe movements [06:41] now that the other dust has settled it seems what is left is this list [06:41] https://paste.ubuntu.com/p/KmbrMBzVHw/ [06:42] which is librte-meta-* out of the report at https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html [07:00] cpaelzer: Done. [07:00] thank you [09:45] vorlon or sil2100: what do you know about the cowboy on ancientminister:/srv/cdimage.ubuntu.com/production/trigger-mirrors ? [09:56] Laney: uh, I know nothing about it, not sure if I ever touched that part [09:57] So we probably need to wait for vorlon to be up [09:57] np [09:57] and hey and happy new year! [10:02] Happy new year to you too! :) [10:02] Fingers crossed for 2021 [10:02] :) [10:04] hm, queuebot seems awfully quiet [10:25] sil2100: could you release the focal SRU for LP: #1901609 [10:25] Launchpad bug 1901609 in signon (Ubuntu Focal) "signond causes qprocess crash" [Undecided,Incomplete] https://launchpad.net/bugs/1901609 [10:25] the ppc64el build was fixed on a simple retry [10:46] RikMills: sure! Switched it back to Fix Committed and now re-looking [10:47] Done o/ [10:50] sil2100: ty :) [11:11] yw! [12:04] doko: any idea what regressed that dh_strip now fails on mingw binaries in both libassuan/amd64 and npth/amd64 ? [12:05] also libmaus2 on ppc64el? [12:10] these are archives with .o files not having any code in the object files. I'll need to look at these, if the check is too strict, or if it's better to fix the builds [12:20] but I don't want to change that now, as long as the lto archive rebuild is running on arm64. that should be the complete list: https://paste.ubuntu.com/p/Qr6Njf5K2m/ [14:29] sil2100: hello, if you happen to have any sru cycles we have a new openvswitch in bionic unapproved that we'd really like to get into proposed and start testing. [14:53] coreycb: o/ [14:55] sil2100: o/ [15:08] tjaalton, hey, can you reject nvidia-prime from groovy, focal, and bionic, please? [15:09] tseliot: sure [15:11] tjaalton, thanks [15:12] and done [15:32] sil2100: would you be able to do a trivial sru accept on https://launchpad.net/ubuntu/groovy/+queue?queue_state=1&queue_text=opensbi and https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=opensbi ? [15:32] sil2100: that would make it easier to prepare the u-boot srus. [15:35] Looking [15:37] Ok, let me handle those quickly and then get back to OVS [15:59] can any ubuntu-archive please NBS-proposed cleanup digikam? [15:59] NBS on ppc64el riscv64 s390x anymore [16:40] Laney, sil2100: sorry, I don't know teh source of that trigger-mirrors cowboy either, I don't believe it was me [16:41] should we just make the repo look like that? [16:46] I suppose so [16:58] vorlon, hey, can you accept nvidia-graphics-drivers-460 in hirsute NEW, please? [17:06] vorlon, I didn't mention in the changelog that it replaces the 455 series. If it's a problem, I'll reupload === ijohnson is now known as ijohnson|lunch [19:38] sil2100: The tzdata verification for bug 1909698 is all verified. [19:38] bug 1909698 in tzdata (Ubuntu) "new upstream release 2020f" [Medium,In progress] https://launchpad.net/bugs/1909698 === ijohnson|lunch is now known as ijohnson [20:52] vorlon, python-fabio i386 hint please? [20:56] LocutusOfBorg: done [21:35] vorlon: Do you want to release the tzdata SRUs? The python3.9 tzdata triggered autopkgtest has passed now too. [22:00] thanks [23:13] tseliot: accepted [23:13] bdmurray: ok, looking [23:15] Thanks [23:17] vorlon: I'm sure you don't need reminding but don't forget -security. [23:33] vorlon, thanks [23:40] hm, is it possible for some AA to retrigger some armhf rebuilds? I missed the fact that net-snmp's armhf build hadn't been published yet, and uploaded a bunch of no-change uploads related to its transition [23:41] almost everything is fine, but the armhf builds used the previous libsnmp35 library :-/ [23:42] I don't want to do another round of no-change uploads just because of this, so I thought I'd ask here if it's possible to retrigger the armhf builds of the affected packages