[00:07] -queuebot:#ubuntu-release- Unapproved: apport (jammy-proposed/main) [2.20.11-0ubuntu82.4 => 2.20.11-0ubuntu82.5] (core, i386-whitelist)
=== chris14_ is now known as chris14
[02:28] -queuebot:#ubuntu-release- Unapproved: ddtp-translations (lunar-proposed/universe) [20221010.1 => 20230413.1] (no packageset)
[02:29] -queuebot:#ubuntu-release- Unapproved: accepted ddtp-translations [source] (lunar-proposed) [20230413.1]
[03:08] -queuebot:#ubuntu-release- Unapproved: gnome-characters (lunar-proposed/main) [44.0-1 => 44.0-2] (ubuntu-desktop)
[04:20] -queuebot:#ubuntu-release- Unapproved: accepted yaru-theme [source] (lunar-proposed) [23.04.4-0ubuntu1]
[04:24] -queuebot:#ubuntu-release- Unapproved: accepted gnome-characters [source] (lunar-proposed) [44.0-2]
[06:59] -queuebot:#ubuntu-release- Unapproved: tmuxp (lunar-proposed/universe) [1.27.0-1 => 1.27.0-1ubuntu1] (no packageset)
[06:59] -queuebot:#ubuntu-release- Unapproved: accepted tmuxp [source] (lunar-proposed) [1.27.0-1ubuntu1]
[07:49] -queuebot:#ubuntu-release- Unapproved: stress-ng (lunar-proposed/universe) [0.15.06-2 => 0.15.07-1] (no packageset) (sync)
[07:50] -queuebot:#ubuntu-release- Unapproved: accepted stress-ng [sync] (lunar-proposed) [0.15.07-1]
[08:26] <LocutusOfBorg> Hello sil2100 and Ubuntu Release, can I work on fixing bileto? I don't know if the work will be lost or not... Right now I'm getting a local instance running on 22.04
[08:27] <LocutusOfBorg> I find development without bileto to be PITA for me, can't bootstrap things, can't run autopkgtests for test matrix, and can't run easily britney
[09:07] <LocutusOfBorg> well, local instance works (I don't want to create new ppas, so I won't use it)
[09:08] <LocutusOfBorg> I suspect it needs some manual cleanup on server... :/
[09:54] <sil2100> Yep :)
[09:54] <sil2100> I'm still waiting to get access to the machine
[09:54] <sil2100> That's the only thing blocking me from fixing it up (and lack of time)
[09:54] <sil2100> Maybe next cycle
[10:25] <waveform> sil2100, I've filed MRs to deal with getting the rpi desktop builds going. Both livecd-rootfs and ubuntu-settings need fixes but I've linked both merge requests from LP: #2016285 -- any chance you can take a look at 'em?
[10:25] -ubottu:#ubuntu-release- Launchpad bug 2016285 in ubuntu-settings (Ubuntu) "Redundant creation of oem user in rpi desktop images" [Critical, New] https://launchpad.net/bugs/2016285
[10:26] <waveform> the ubuntu-settings MR is also linked to LP: #2016286 which doesn't *have* to be fixed at the same time (it's an upgrade rather than a release issue, so we *could* do it later). Anyway, if you want me to strip that one out of the MR, I've put the commits at the end so I can do that easily if wanted
[10:26] -ubottu:#ubuntu-release- Launchpad bug 2016286 in ubuntu-settings (Ubuntu) "growroot-almost service failure after upgrade" [Undecided, New] https://launchpad.net/bugs/2016286
[11:23] <LocutusOfBorg> sil2100, I did open a merge request btw
[11:23] <LocutusOfBorg> its a easy cleanup, you might want to quick merge it :)
[12:04] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (kinetic-proposed) [2.23.1-0ubuntu3.3]
[12:07] -queuebot:#ubuntu-release- Unapproved: rejected apport [source] (jammy-proposed) [2.20.11-0ubuntu82.4]
[12:37] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (kinetic-proposed) [2023c-0ubuntu0.22.10.1]
[12:38] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (jammy-proposed) [2023c-0ubuntu0.22.04.1]
[12:39] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (focal-proposed) [2023c-0ubuntu0.20.04.1]
[13:43] -queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27.26 => 2.20.11-0ubuntu27.27] (core, i386-whitelist)
[14:03] -queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu7.29 => 2.20.9-0ubuntu7.30] (core)
[15:08] <bdmurray> juliank: python-apt is a bit old (4 weeks) - do the mirror lists still need updating?
[15:10] <juliank> bdmurray: It says "Thu, 23 Feb 2023 21:38:02 +0100" so probably could use an update yeah. not a huge delta it seems though
[15:10] <bdmurray> juliank: Ah, I didn't look at the changelog date. Will you do the update or should i?
[15:11] <juliank> bdmurray: I can upload in a copule secs
[15:11] <bdmurray> juliank: ack, thanks
[15:17] <juliank> Running CI
[15:20] -queuebot:#ubuntu-release- Unapproved: python-apt (lunar-proposed/main) [2.5.3 => 2.5.3ubuntu1] (core, i386-whitelist)
[15:22] <juliank> bdmurray: ^ uploaded. I also updated the CI and debian/gbp.conf to point to lunar for future SRU work
[15:23] <juliank> the CI = .gitlab-ci.yml
[15:23] <juliank> I did not give it a new upstream version, maybe I should have so it syncs again in lunar+1, but meh, it's done now :)
[15:26] <juliank> bdrung: that reminds me, I want to move the mirror lists in python-apt to distro-info-data
[15:27] <bdmurray> I've heard this one before
[15:27] <juliank> Yeah we hadn't hired one of its maintainers back then
[15:28] <bdmurray> heh
[15:28] <juliank> this is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922232
[15:28] -ubottu:#ubuntu-release- Debian bug 922232 in distro-info-data "src:distro-info: Please take over distro info from python-apt" [Wishlist, Open]
[15:29] -queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (lunar-proposed) [2.5.3ubuntu1]
[15:39] <sil2100> waveform: ok, approved your livecd-rootfs changes - will merge and sponsor o/
[15:39] <sil2100> waveform: btw. do you have the power to upload ubuntu-settings?
[15:39] <waveform> sil2100, nope
[15:39] <sil2100> Ok, I'll try to sponsor that one after I review the changes too then
[15:40] <waveform> thanks!
[15:43] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (lunar-proposed/main) [2.827 => 2.828] (desktop-core, i386-whitelist)
[15:52] -queuebot:#ubuntu-release- Unapproved: ubuntu-settings (lunar-proposed/main) [23.04.4 => 23.04.5] (ubuntu-desktop)
[15:53] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (lunar-proposed) [2.828]
[15:53] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-settings [source] (lunar-proposed) [23.04.5]
[15:58] <bdmurray> vorlon: the boost1.74 / cmake issue was due to networking :-|
[15:59] <sil2100> bdmurray, vorlon: base-files for release incoming! Can someone review?
[16:00] -queuebot:#ubuntu-release- Unapproved: base-files (lunar-proposed/main) [12.3ubuntu1 => 12.3ubuntu2] (core, i386-whitelist)
[16:02] <bdmurray> I can do this
[16:06] <vorlon> bdmurray: do we move forward with skiptests?  I plan to release icu and cmake today one way or another
[16:06] -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (lunar-proposed) [12.3ubuntu2]
[16:07] <bdmurray> vorlon: I said was
[16:08] <bdmurray> so its sorted now afaik
[16:09] <vorlon> ah ok
[16:27] -queuebot:#ubuntu-release- Unapproved: accepted gnu-efi [sync] (kinetic-proposed) [3.0.15-1~22.10.1]
[16:33] <xnox> hey release-team there are a number of kernels that are in lunar-proposed and haven't been unblocked to be promoted yet, but they should be:
[16:35]  * vorlon attends
[16:35] <xnox> linux-meta-kvm => is meta respin only to drop uninstallable linux-modules-iwlwifi-kvm (because a real abi-versioned linux-modules-iwlwifi-kvm cannot be provided as that kernel doesn't have wifi) ditto many/most dkms packages do not work with kvm flavour hence show up as "regression" to britney, but "always failed in adt-matrix"
[16:35] <xnox> request: please RM NBS linux-modules-iwlwifi-kvm (from 6.2.0.1003.3) in lunar-proposed
[16:35] <xnox> please force-skiptest & unblock linux-meta-kvm 6.2.0.1003.4
[16:35] <xnox> ...
[16:36] <vorlon> afaics it's already unblocked, but addressed the other two bits
[16:36] <xnox> also please unblock linux-kvm 6.2.0-1003.3 with the above
[16:36] <xnox> .......
[16:36] <vorlon> fwiw linux-meta-kvm wasn't blocked in the first place so no unblock needed
[16:36] <xnox> ack!
[16:36] <vorlon> and linux-kvm has already been unblocked
[16:37] <xnox> next up linux-lowlatency
[16:37] <xnox> linux-meta-lowlatency is blocked by autopkgtest policy so needs force-skiptest linux-meta-lowlatency 6.2.0.1003.3
[16:38] <vorlon> done
[16:38] <xnox> the sl-modem is neutral result; the linux-lowlatency itself RT regressions are being resolved / acked / not a regression; and the systemd thing is related to nested qemu segfaulting which i will come back to later.
[16:39] <xnox> the above should take all the lrm lowlatency and signed with it. etc.
[16:39] <xnox> ...
[16:39] <vorlon> my analysis concurs
[16:39] <xnox> next up is even more fun
[16:40] <xnox> linux-allwinner / linux-meta-allwinner is binary copy up from kinetic. we don't have swm automation that can do such kernels to automatically unblock them. They have passed all the RT and physical device testing. Please unblock to migrate it.
[16:40] <xnox> linux-meta-allwinner
[16:40] <vorlon> done
[16:40] <xnox> it is v5.19 based; upstream it hasn't yet been integrated to just be v6.2; our own forward port to v6.2 is incomplete; and we are keeping it on v5.19 for now
[16:41] <vorlon> ack
[16:41] -queuebot:#ubuntu-release- Unapproved: accepted anacron [source] (kinetic-proposed) [2.3-33ubuntu2]
[16:41] <vorlon> (ick/ack)
[16:41] <xnox> next up.
[16:41] <xnox> ick/ack x2 => same store with linux-meta-starfive 5.19.0.1005.5
[16:41] <xnox> *story
[16:42] <xnox> in does imply that we will be coming back later with "erghm, v5.19 is EOL and we can't / don't want to update starfive/allwinner anymore, and nobody can buy those boards anymore, so there's that" or like "we created frankenstein forward ports to v6.2, we need SRU expection to roll these v5.19s to v6.2 as an SRU"
[16:42] <vorlon> xnox: I noticed the starfive kernel is actually quite old in lunar-proposed and is out of date vs kinetic
[16:43] <vorlon> 5.19.0-1005.7 vs 5.19.0-1015.17
[16:43] <xnox> vorlon:  also that. I am not sure, if we should copy them up again. both of them from kinetic to lunar, and automate unblocking them.
[16:43] <xnox> (i.e. such that SWM when unblocking those in kinetic, unblocks them in lunar too)
[16:43] <vorlon> is there going to be any testing of them in lunar-proposed?
[16:43] <vorlon> if not then I would just sync them straight to lunar release pocket.
[16:44] <vorlon> (not as a policy per se, but I'm saying that's what I would do right now)
[16:44] <xnox> automated testing in kernel-cert is done in QEMU only; the SRUs are tested on hw by riscv people. and syncing them striaght to lunar release pocket sounds safe => but wouldn't do britney installability checks, right?
[16:45] <vorlon> correct it would not
[16:45] <vorlon> but in this case I'm willing to own that
[16:45] <vorlon> ditto allwinner
[16:45] <xnox> (they are installable, have been before, but also would want to always force check that, because increasing uninstallability count by accident can lead to fun)
[16:46] <xnox> (let me make your libc uninstallable, because we can now make all of perl installable => will never forget that)
[16:46] <xnox> (the other release we used the force hint to migrate perl)
[16:46] <vorlon> yes, I don't want random devs syncing to the release pocket (if launchpad even allows that?)  but I'm at the start of my work day and if I break a couple of per-board riscv kernels, I will deal with the fallout before EOD
[16:46] <vorlon> and before rolling candidate images, which I'm also on the hook for :P
[16:46] <xnox> ah i see. cool cool. sounds good.
[16:47] <arighi> cpaelzer, vorlon, FYI, about the bigger linux-headers size in lunar (LP: #2015867), we're currently respinning all kernels (generic and clouds), we have a patch in generic to mitigate the size (by ~50M) and for the cloud kernels we have decided to disable Rust for now, so the size of linux-headers is pretty much the same as the 5.19 kernels. These kernels can be released either as 0-day
[16:47] -ubottu:#ubuntu-release- Launchpad bug 2015867 in linux (Ubuntu) "Kernel 6.1 bumped the disk consumption on default images by 15%" [Undecided, Confirmed] https://launchpad.net/bugs/2015867
[16:47] <arighi> update or in the images if the bigger size is a show stopper.
[16:47] <xnox> launchpad in fact allows to do that with yes to the archive admins. but not mere mortal devs like me.
[16:47] <xnox> ....
[16:48] <xnox> now extra things for non-candidate images, indeed arighi is respining kernel that we will probably want to pick up in the cloud images (so potentially we may want to release those respins) and generic (which we will not want to release on the isos, but like as zero-day SRU and probably for the cloud images)
[16:48] <vorlon> arighi: interesting, ok
[16:48] <xnox> see above.
[16:48] <xnox> ....
[16:48] <vorlon> why do you not want it on the ISOs?
[16:48] <juliank> What do we need to do to get a copy-package --from-suite kinetic-devel or similar (that is either kinetic-updates or kinetic). That would be so incredibly useful
[16:49]  * juliank goes into #ubuntu-devel with his topic, sorry
[16:49] <vorlon> juliank: patches welcome
[16:49] <vorlon> :)
[16:49] <juliank> I wonder if launchpad has a "whatever pocket is latest API"
[16:49] <juliank> but sure client-side retry works too, I suppose
[16:50] <xnox> vorlon -> if we can that would be nice, but i don't know if we can complete all the RT & cert testing on the generic kernel in time to build candidate image and release it this weekend to release pocket.
[16:50] <xnox> i don't know if arighi even started the build of it.
[16:50] <xnox> and we do not consider it to be boot time critical for the installer images.
[16:50] <vorlon> juliank: but if you specify '-devel' I would expect it to try -proposed first
[16:50] -queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (kinetic-proposed) [5.28ubuntu0.22.10.0]
[16:50] <arighi> xnox, they're building now in the c-k-t/bootstrap ppa
[16:50] <juliank> vorlon: makes sense
[16:50] <vorlon> xnox: ack
[16:50] <xnox> .....
[16:50] <xnox> and finally qemu
[16:51] <juliank> vorlon: whatever git-ubuntu does :D
[16:52] <xnox> qemu is segfauling in nested VM launch inside autopkgtests, and it seems concerning, as it fails in init on allocating caches, and checks that an even number of them has been allocated, and looks scary. However, lots of people hit that assert on the internet since 2018 too. and i can't tell if it's a real issue (i.e. broken qemu unable to use nested VMs) or if there is a different crash of
[16:52] <xnox> hte guest and it's just a red herring (the VM is being killed / crashing anyway, and an assert is hit on the way in or out / and it is "fine")
[16:52] -queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (jammy-proposed) [5.28ubuntu0.22.04.0]
[16:53] <xnox> qemu maintainers opinion would be nice to hear.
[16:53] <vorlon> my understanding of nested qemu was "you're lucky if it works and we don't support it in production"
[16:53] <xnox> true.
[16:53] <xnox> but hitting assert() code path in C sounds odd though.
[16:54] <xnox> qemu-system-x86_64: ../../util/cacheflush.c:208: init_cache_info: Assertion `(isize & (isize - 1)) == 0' failed. on somthing which literary just did the init of the variable and checks that it is even.
[16:54] -queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (focal-proposed) [5.28ubuntu0.20.04.0]
[16:54] <xnox> will ping sergio about it.
[16:55] <xnox> lastly, we have already one known hardware/kernel release-regression without a patch or a workaround that the 3rd party vendor is working on a fix. certain nvidia sr-iov driver support has regressed at runtime, that otherwise has been working on v5.15 and v5.19 kernels but not v6.2 kernels. It will go as release note, as we don't have a patch/solution for that yet.
[16:56] <xnox> the bug number is...
[16:56] -queuebot:#ubuntu-release- Unapproved: dkimpy (lunar-proposed/universe) [1.1.0-1 => 1.1.2-1] (no packageset) (sync)
[16:56] <rbasak> juliank: I don't remember exactly what git-ubuntu does, but it's wrong in edge cases because there's no obvious answer. I wouldn't rely on any heuristic for copy-package.
[16:57] <vorlon> sounds like you should stick that in the release notes https://discourse.ubuntu.com/t/lunar-lobster-release-notes/31910
[16:57] <vorlon> xnox: ^
[16:57] -queuebot:#ubuntu-release- Unapproved: accepted dkimpy [sync] (lunar-proposed) [1.1.2-1]
[16:57] <xnox> https://bugs.launchpad.net/ubuntu-release-notes/+bug/1988806
[16:57] -ubottu:#ubuntu-release- Launchpad bug 1988806 in linux (Ubuntu Lunar) "Add support for mdev_set_iommu_device() kABI in Ubuntu 22.10 kernel" [Undecided, Triaged]
[16:57] <xnox> vorlon:  yes, will do.
[16:58] <juliank> rbasak: I mean basically it needs to test kinetic-proposed, kinetic-updates, kinetic and pick the first one that has a version
[16:58] <vorlon> xnox: thanks
[16:58] <xnox> vorlon:  and other than that, no concerns for the lunar release to go ahead =)
[16:58] <juliank> Maybe I should just add comma support to copy-package
[16:58] <juliank> --from-suite kinetic-proposed,kinetic-updates,kinetic
[16:59] <juliank> Seems reasonable to me
[16:59] <xnox> juliank:  i thought from-suite is optional no, if one specifies version? (not sure if this is helpful, as i have no idea about the context)
[16:59] <juliank> xnox: I'm mass copied whatever is in whatever kinetic pocket to test rebuild PPA for gnu-efi SRU basically,
[17:00] <juliank> xnox: So I don't know the versions, I just want to test if the reverse-deps in the latest version still build :)
[17:00] <xnox> and something else did client-side did such fallbacks already.... the logic there was sound, pull-lp-source maybe?
[17:00] <juliank> pull-lp-source pulls from kinetic-updates even if you say kinetic
[17:00] <xnox> juliank:  ah i see. the way we used to do it, is to copy everything three times. all packages copy from kinetic, then updates, then proposed. to catch them all =)
[17:01] <vorlon> afk for ~1.5h; those kernels should publish soon, then I'll binary-copy the riscv ones from kinetic-updates
[17:01] <xnox> juliank:  pull-lp-source pulls from the range of all pockets for naked name "kinetic", if you want specific from release the syntax is "kinetic-release"
[17:01] <juliank> ack
[17:01] <xnox> (kinetic-updates kinetic-proposed kinetic-security)
[17:01] <juliank> Not a change I'd make for copy-package as that has worked differently for ages
[17:01] <juliank> :)
[17:02] <xnox> the idea being that pull-lp-source kinetic, i guess behaves the way you want kinetic-devel to behave (meaning the highest one)
[17:02] <xnox> juliank:  yeah, copy-package is very strict.
[17:03] <xnox> one could make it accept kinetic-release as alias for kinetic, but yeah, we must not change the copy-package's meaning of "kinetic" it will confuse all users of it.
[17:04] <rbasak> juliank: well I don't know your scenario exactly, but sometimes stuff gets deleted, sometimes the security pocket has something higher, etc. After a new release stuff gets left behind in proposed that we don't want. Etc.
[17:05] <juliank> I guess explicit comma-ing for search order makes most sense
[17:05] <arighi> xnox, do we want to mention about rust for the generic kernel in the lunar release notes?
[17:05] <juliank> For copy-package we don't have leftovers and deleted stuff because we look at live archive view, but still
[17:06] <rbasak> This is about what you want vs. what's actually there, even with a live archive view.
[17:06] <xnox> arighi:  we do!
[17:07] <rbasak> From my POV copy-package is rarely used. If there's a common scenario that could use some more convenient heuristics, maybe it should have a more dedicated tool?
[17:07] <xnox> juliank:  rbasak: yeah, we can have archive if fun states, and so far copy-package was strict and declarative, meaning only exact locations accepted. And like if you try to do things with != "Release" pocket on a PPA it all just fails.
[17:08] <xnox> *s/if/in/
=== arraybolt3_ is now known as arraybolt3
[18:14] -queuebot:#ubuntu-release- Unapproved: accepted magnum [source] (kinetic-proposed) [15.0.1-0ubuntu1]
[18:25] -queuebot:#ubuntu-release- Unapproved: accepted magnum [source] (jammy-proposed) [14.1.0-0ubuntu1]
[18:28] -queuebot:#ubuntu-release- Unapproved: accepted magnum [source] (focal-proposed) [10.1.0-0ubuntu1]
[18:40] -queuebot:#ubuntu-release- Unapproved: ubiquity (lunar-proposed/main) [23.04.7 => 23.04.8] (ubuntu-desktop)
[18:41] <vorlon> bdmurray: ^^ please
[18:42] -queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (focal-proposed) [2.0.31-0ubuntu0.1]
[18:54] <bdmurray> vorlon: looking
[18:56] <bdmurray> lol at the bug being fixed
[18:56] <bdmurray> or maybe lol sob
[18:57] <bdmurray> vorlon: will you also upload it or commit it for Jammy so we don't forget?
[18:57] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (lunar-proposed) [23.04.8]
[19:27] <vorlon> bdmurray: commit for jammy yes
[19:32] -queuebot:#ubuntu-release- Unapproved: linux-allwinner (lunar-release/main) [5.19.0-1007.7 => 5.19.0-1009.9] (no packageset) (sync)
[19:32] -queuebot:#ubuntu-release- Unapproved: linux-meta-starfive (lunar-release/main) [5.19.0.1005.5 => 5.19.0.1014.12] (no packageset) (sync)
[19:33] -queuebot:#ubuntu-release- Unapproved: linux-meta-allwinner (lunar-release/main) [5.19.0.1007.7 => 5.19.0.1009.9] (no packageset) (sync)
[19:33] -queuebot:#ubuntu-release- Unapproved: linux-starfive (lunar-release/main) [5.19.0-1005.7 => 5.19.0-1014.16] (no packageset) (sync)
[19:42] -queuebot:#ubuntu-release- Unapproved: binutils (lunar-proposed/main) [2.40-2ubuntu3 => 2.40-2ubuntu4] (core, i386-whitelist)
[19:43] <vorlon> bdmurray: ^^
[19:43] <vorlon> (the binutils, not the kernels - I pushed those through)
[19:44] -queuebot:#ubuntu-release- Unapproved: accepted linux-allwinner [sync] (lunar-release) [5.19.0-1009.9]
[19:44] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta-starfive [sync] (lunar-release) [5.19.0.1014.12]
[19:44] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta-allwinner [sync] (lunar-release) [5.19.0.1009.9]
[19:44] -queuebot:#ubuntu-release- Unapproved: accepted linux-starfive [sync] (lunar-release) [5.19.0-1014.16]
[19:48] -queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (lunar-proposed) [2.40-2ubuntu4]
[19:55] <vorlon> so we have a new ubiquity to get through, and some kernels to publish (above), and language-pack-en, and then I'll start building candidate images
[19:56] <vorlon> I won't wait for binutils because it's not relevant to image testing, it only fixes an upgrade issue
[19:56] <vorlon> (binutils takes 7 hours to build on riscv64 so we'll pick it up in the next build)
[19:57] <vorlon> and ubiquity takes 3 hours on riscv64, so we've got another 2h+ to go before candidate images start
[19:59] <vorlon> ah python-apt also, but that just blocks on a few autopkgtests
[19:59] <vorlon> aptdaemon/amd64 failed so retrying that
[20:00] -queuebot:#ubuntu-release- Unapproved: irssi (lunar-proposed/main) [1.4.3-1ubuntu1 => 1.4.3-2ubuntu1] (core)
[20:00] <LocutusOfBorg> vorlon, ^^ this one has CVE fix
[20:00] <vorlon> ack
[20:00] <vorlon> not on images so fine to take
[20:01] <bdmurray> vorlon: I also see python-apt and update-manager as a regression and I'm looking at it
[20:01] <vorlon> bdmurray: ok
[20:01] <bdmurray> only to see you already retried it
[20:01] <vorlon> :)
[20:02] -queuebot:#ubuntu-release- Unapproved: accepted irssi [source] (lunar-proposed) [1.4.3-2ubuntu1]
[20:03] <LocutusOfBorg> ta
[20:04] -queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (kinetic-proposed) [2.4.22-0ubuntu0.22.10.1]
[20:04] <vorlon> what, https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html hasn't regenerated in 20 minutes?! unacceptable
[20:05] -queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (jammy-proposed) [2.4.22-0ubuntu0.22.04.1]
[20:15] -queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (kinetic-proposed) [1:7.0+dfsg-7ubuntu2.3]
[20:17] -queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (jammy-proposed) [1:6.2+dfsg-2ubuntu6.8]
[20:25] -queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (focal-proposed) [1:4.2-3ubuntu6.26]
[20:32] -queuebot:#ubuntu-release- Unapproved: accepted openvpn [source] (jammy-proposed) [2.5.8-0ubuntu0.22.04.1]
[20:55] <LocutusOfBorg> LOL
[21:02] -queuebot:#ubuntu-release- Unapproved: accepted certmonger [source] (jammy-proposed) [0.79.14+git20211010-2ubuntu1.1]
[21:03] <vorlon> just waiting on ubiquity now; riscv64 build almost done
[21:30] <vorlon> ubiquity/riscv64 accepted
[21:36] -queuebot:#ubuntu-release- Unapproved: ubuntucinnamon-environment (lunar-proposed/universe) [23.04.4 => 23.04.5] (no packageset)
[21:37] <Eickmeyer> ^ grrrr.....
[21:39] <vorlon> Eickmeyer: accepted
[21:40] <Eickmeyer> vorlon: Thanks. I didn't know how well that was going to go down considering the freeze.
[21:40] <Eickmeyer> He's trying to get his UX down.
[21:40] -queuebot:#ubuntu-release- Unapproved: accepted ubuntucinnamon-environment [source] (lunar-proposed) [23.04.5]
[21:49] <vorlon> Eickmeyer: flavor leads always have broad discretion in telling us that they consider flavor-specific package updates critical for release
[21:49] <Eickmeyer> vorlon: Valid.
[21:53] -queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (jammy-proposed) [1.21.1ubuntu2.2]
[22:20] -queuebot:#ubuntu-release- Unapproved: accepted pacemaker [source] (jammy-proposed) [2.1.2-1ubuntu3.1]
[22:20] <vorlon> when proposed-migration is running faster than the publisher...
[22:25] -queuebot:#ubuntu-release- Unapproved: accepted krb5 [source] (jammy-proposed) [1.19.2-2ubuntu0.2]
[22:29] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (jammy-proposed) [2.765.21]
[22:33] -queuebot:#ubuntu-release- Unapproved: rejected apport [source] (focal-proposed) [2.20.11-0ubuntu27.26]
[22:35] -queuebot:#ubuntu-release- Unapproved: accepted openssh [source] (focal-proposed) [1:8.2p1-4ubuntu0.7]
[22:36] -queuebot:#ubuntu-release- Unapproved: mutter (lunar-proposed/main) [44.0-2ubuntu3 => 44.0-2ubuntu4] (desktop-core, desktop-extra)
[22:51] <Eickmeyer> If only it could've ran that fast all cycle.
[22:55] <vorlon> it runs a lot faster when there's not much to do
[22:56] <vorlon> but also the publisher is running unusually slowly by the look of things :)
[23:23] <vorlon> kicking off a round of builds
[23:35] <LocutusOfBorg> hello who to report MoM issues?
[23:36] <LocutusOfBorg> that generated page is missing information about where code is and similar
[23:37] <LocutusOfBorg> maybe Colin is the best person to ask
[23:38] <vorlon> who broke livecd-rootfs https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/lunar/ubuntu-server/+build/435057
[23:40] <vorlon> but wait, what build even is this? this doesn't look like the live image
[23:42] <vorlon> bdmurray: ^^ is 'Product (Ubuntu Server)' supposed to be preinstalled images?  Somehow clicking rebuild for everything in the manifest got me an amd64 image
[23:42] <vorlon> or rather, an amd64 failure
[23:43] <vorlon> it wasn't released with beta so I don't care that it ftbfs but I wonder why it's on the tracker
[23:48] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Lunar Final] (20230414) has been added
[23:49] <vorlon> uhhhhh xubuntu-minimal tried to dispatch to a non-launchpad builder, that's special
[23:49] <vorlon> retrying
[23:49] <bluesabre> I probably am not to blame
[23:49] <vorlon> yes, you're not
[23:50] <bluesabre> :)
[23:50] <vorlon> some flakiness in the cdimage-master env
[23:50] <vorlon> which I don't remember ever seeing previous
[23:50] <vorlon> transient dns failure maybe