[00:00] <tomreyn> it ia also listed at https://wiki.ubuntu.com/SecurityTeam/FAQ#GPG_Keys_used_by_Ubuntu
[00:01] <jbicha> should we update the channel topics again for the new archive freeze?
[00:06] <vorlon> jbicha: thanks, doing
[00:25] -queuebot:#ubuntu-release- Unapproved: octave-control (noble-proposed/universe) [4.0.1-1 => 4.0.1-1ubuntu1] (no packageset)
[00:28] -queuebot:#ubuntu-release- Unapproved: libpng1.6 (noble-proposed/main) [1.6.43-3 => 1.6.43-5] (core, i386-whitelist) (sync)
[00:28] -queuebot:#ubuntu-release- Unapproved: kbuild (noble-proposed/universe) [1:0.1.9998svn3589+dfsg-1 => 1:0.1.9998svn3604+dfsg-1] (no packageset) (sync)
[04:11] <vorlon> would still be a good idea for someone to see if they can reproduce that debootstrap failure.  Here, I'm hitting an unrelated failure
[05:37] <vorlon> juliank: apt/armhf test failure with the reverted xz-utils https://autopkgtest.ubuntu.com/packages/a/apt/noble/armhf
[06:57] -queuebot:#ubuntu-release- Unapproved: ukui-panel (noble-proposed/universe) [4.0.0.2-1build1 => 4.0.0.4-1] (ubuntukylin) (sync)
[07:13] <LocutusOfBorg> 	2024-03-30 04:05:13 CET	Published	Noble	updates	main	misc	1.6.42-1
[07:13] <LocutusOfBorg>  	2024-03-28 08:53:09 CET	Published	Noble	release	main	misc	1.6.43-3
[07:13] <LocutusOfBorg> OMG what does this mean?
[07:13] <LocutusOfBorg> libpng1.6 has higher version in noble-updates
[07:14] <LocutusOfBorg> and a non-renamed library in updates?
[07:31] <vorlon> LocutusOfBorg: this is rollback for xz-utils
[07:31] <LocutusOfBorg> ok
[07:31] <LocutusOfBorg> I'm trying to fix haskell, I got a fix, but the archive looks meh
[07:31] <vorlon> we're using the noble-updates pocket to be able to have last-known-good amd64 binaries available, in parallel with the latest versions on all other architectures
[07:31] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+sourcepub/15894110/+listing-archive-extra
[07:31] <vorlon> so that we don't have to re-bootstrap armhf for time_t
[07:31] <LocutusOfBorg> FYI ^^
[07:32] <LocutusOfBorg> haskell-haskell-gi suffered a failure due to newer glib2.0
[07:32] <LocutusOfBorg> vorlon, it's ok for me :)
[07:32] <LocutusOfBorg> just maybe mention some uninstallabilities, or archive inconsistencies on topic?
[07:33] <LocutusOfBorg> but as long as this is something you are aware of, I go back to haskell
[07:33] <vorlon> what uninstallabilities specifically?
[07:36] <LocutusOfBorg> I mean version lower in updates w.r.t. release pocket
[07:37] <LocutusOfBorg> I don't know if I can upload an haskell fix and start give backs, or should I wait
[07:37] <LocutusOfBorg> haskell can take few days to build on risc and armhf, the sooner we start, the better
[07:37] <LocutusOfBorg> (I mean haskell-gi-* foobar is really long)
[07:38] <LocutusOfBorg> btw I fixed in my libpng1.6 the udeb uninstallability issue due to renaming, I don't think this is an Ubuntu issue, but also I'm scared if this can be the culprit of the issues you are having
[07:50] <vorlon> you can upload; stuff in the queue will be released once we're ready to go with rebuilding everything
[07:57] -queuebot:#ubuntu-release- Unapproved: haskell-charsetdetect-ae (noble-proposed/universe) [1.1.0.4-5 => 1.1.0.4-6] (no packageset) (sync)
[07:57] -queuebot:#ubuntu-release- Unapproved: haskell-fgl (noble-proposed/universe) [5.8.0.0-1 => 5.8.1.1-1] (no packageset) (sync)
[07:57] -queuebot:#ubuntu-release- Unapproved: haskell-hoogle (noble-proposed/universe) [5.0.18.3+dfsg1-4build1 => 5.0.18.3+dfsg1-5] (no packageset) (sync)
[07:58] -queuebot:#ubuntu-release- Unapproved: pkg-haskell-tools (noble-proposed/universe) [0.12.4build1 => 0.12.5] (no packageset) (sync)
[08:00] -queuebot:#ubuntu-release- Unapproved: haskell-haskell-gi (noble-proposed/universe) [0.26.7-2build1 => 0.26.7-2ubuntu1] (no packageset)
[08:02] <mitya57> vorlon: I also have one issue on amd64: https://launchpadlibrarian.net/721969472/buildlog_ubuntu-noble-amd64.qttools-opensource-src_5.15.13-1_BUILDING.txt.gz
[08:02] <mitya57> It looks like libwacom-common is available in both -release and -updates (with -release having newer version), while libwacom9 is available only in -updates (and the version mismatches libwacom-common in -release).
[08:02] <mitya57> Maybe related to the fact that one of them is arch:all and another arch:any (and arch:any amd64 binaries were deleted from -release?)
[08:03] <vorlon> yes
[08:04] <vorlon> those should all shake out when the rebuilds happen in -proposed
[08:04] <mitya57> Ah, okay
[08:04] <vorlon> there may be a few cases where we have to drop the Arch: all package from the release pocket as well to let new amd64 build, but that should be rare
[08:05] <mitya57> vorlon: By the way, how much chances I have to get new Qt 5 patch release in noble? I thought I would try to manage to get it prepared before beta freeze, but with this xz rollback and yet another world rebuild maybe I should give up?
[08:06]  * mitya57 started preparing it in a ppa as usual: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4979/+packages
[08:15] -queuebot:#ubuntu-release- Unapproved: connectagram (noble-proposed/universe) [1.3.5-1ubuntu1 => 1.3.5-2] (no packageset) (sync)
[08:16] -queuebot:#ubuntu-release- Unapproved: indi-gige (noble-proposed/universe) [0.1+20221223115700-1ubuntu1 => 0.1+20221223115700-2] (no packageset) (sync)
[08:16] -queuebot:#ubuntu-release- Unapproved: entropybroker (noble-proposed/universe) [2.9-7ubuntu1 => 2.9-8] (no packageset) (sync)
[08:33] -queuebot:#ubuntu-release- Unapproved: glibc (noble-proposed/main) [2.39-0ubuntu7 => 2.39-0ubuntu8] (core, i386-whitelist)
[08:46] -queuebot:#ubuntu-release- Unapproved: accepted glibc [source] (noble-proposed) [2.39-0ubuntu8]
[08:53] <LocutusOfBorg> [1;91mERROR: [97mcouldn't find API description for GLib.time_t[22;94m
[08:53] <LocutusOfBorg> LOL
[09:41] <lotuspsychje> im getting a weird error and depend on trying to install nmap on noble, can anyone test that?
[09:49] <lotuspsychje> its a conflict between nmap-common versions
[09:53] <RikMills> lotuspsychje: that is not surprising, as there is currently a mass removal of amd64 binaries that were built after the compromised xz-utils was published
[09:54] <lotuspsychje> ok tnx RikMills just wanted to report
[09:56] <RikMills> lotuspsychje: np. when the (7000 ish) packages get rebuilt in due course, should all get fixed
[09:56] <lotuspsychje> phew good luck to all
[10:57] -queuebot:#ubuntu-release- Unapproved: xubuntu-default-settings (noble-proposed/universe) [24.04.2 => 24.04.3] (xubuntu)
[11:15] -queuebot:#ubuntu-release- Unapproved: google-android-installers (noble-proposed/multiverse) [1707406511ubuntu3 => 1710437545-3] (no packageset) (sync)
[12:01] -queuebot:#ubuntu-release- Unapproved: newlib (noble-proposed/universe) [3.3.0-1.3 => 4.4.0.20231231-2] (no packageset) (sync)
[13:05] -queuebot:#ubuntu-release- Unapproved: gcc-14 (noble-proposed/main) [14-20240315-1ubuntu1 => 14-20240330-1ubuntu1] (i386-whitelist)
[13:16] -queuebot:#ubuntu-release- Unapproved: gcc-14 (noble-proposed/main) [14-20240315-1ubuntu1 => 14-20240330-1ubuntu1] (i386-whitelist)
[13:17] -queuebot:#ubuntu-release- Unapproved: rejected gcc-14 [source] (noble-proposed) [14-20240330-1ubuntu1]
[13:35] -queuebot:#ubuntu-release- Unapproved: gcc-13 (noble-proposed/main) [13.2.0-23ubuntu2 => 13.2.0-23ubuntu3] (i386-whitelist)
[13:59] -queuebot:#ubuntu-release- Unapproved: isc-kea (noble-proposed/main) [2.4.1-2build1 => 2.4.1-3] (no packageset) (sync)
[14:22] <doko> is somebody running a script to retry builds?  please stop that for now
[14:23] <doko> vorlon: binutils unfortunately built on amd64
[14:26] <adrien> doko: well, there's the fallout management from the xz-utils backdoor
[14:26] <doko> sure, but cancelled builds are not retried on it's own
[14:30] <adrien> ah, ok; I know apw was looking at something but I can't tell if it's related for sure
[14:44] <doko> looks like the package was has been built with the restored amd64 binaries
[14:59] <ahasenack> hi ubuntu-release, I synced https://launchpad.net/debian/+source/isc-kea/2.4.1-3 to fix https://launchpad.net/bugs/2055151
[14:59] -ubottu:#ubuntu-release- Launchpad bug 2055151 in isc-kea (Ubuntu) "kea-ctrl-agent segfault in ppc64el dep8 test" [High, Fix Committed]
[15:01] <bdmurray> I've targetted bug 2055151 for the beta so we don't lose track of it.
[15:01] -ubottu:#ubuntu-release- Bug 2055151 in isc-kea (Ubuntu) "kea-ctrl-agent segfault in ppc64el dep8 test" [High, Fix Committed] https://launchpad.net/bugs/2055151
[15:02] <ahasenack> thanks
[15:55] <vorlon> doko: I built binutils
[15:56] <doko> vorlon: I was assuming that. next gcc-13 is dep-wait with ghostscript uninstallabilities.
[15:56] <vorlon> yes. looking to see what arch: all package needs removed
[15:57] <vorlon> also lol ubuntu-build is broken because the archive is in pre-releaze freeze sigh
[15:57] <doko> I can prepare an upload doing without graphviz and ghostscript
[15:57] <vorlon> no, we shouldn't need any more bootstrap builds here, just need the archive tuned
[15:57] <vorlon> which is faster overall
[16:08] <vorlon> I'll also look ahead at glibc build-dep installability
[16:09] <vorlon> looks ok actually
[16:09] <doko> when you start gcc-13, please also accept gcc-14 for the shared libs
[16:18] <vorlon> doko: I've set the starting of gcc-13 on a trigger so I may be afk when it accepts (and ubuntu-build doesn't give me useful return codes for scripting this); but I'll accept gcc-14 asap after
[16:18] <vorlon> moving ghostscript to the top of my list for rebuilds as well.  its build-deps look clean
[16:19] <vorlon> and texinfo, whose Arch: all I had to remove last night for binutils
[16:21] <vorlon> (this doesn't matter for the amd64 builds, but will matter for getting other archs built faster, including riscv64)
[16:33] <vorlon> looking for someone to un-freeze noble now. there may be some packages that fail to build due to archive inconsistency, but there is no ongoing concern about tainted builds
[16:33] <vorlon> (we want gcc to finish building but that will be done soon)
[16:35] -queuebot:#ubuntu-release- Unapproved: accepted edubuntu-meta [source] (noble-proposed) [24.04.12.1]
[16:35] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (noble-proposed) [1.294.1]
[16:35] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-unity-meta [source] (noble-proposed) [0.17]
[16:35] -queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-meta [source] (noble-proposed) [0.57]
[16:35] -queuebot:#ubuntu-release- Unapproved: accepted xubuntu-meta [source] (noble-proposed) [2.261]
[16:35] -queuebot:#ubuntu-release- Unapproved: accepted ubuntucinnamon-meta [source] (noble-proposed) [24.04.3.1]
[16:35] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (noble-proposed) [1.538]
[16:35] -queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (noble-proposed) [24.04.18]
[16:38] <vorlon> heh, xz-utils amd64 binaries in -proposed got caught up by the removal script; restoring them
[16:49] <vorlon> having a look at autopkgtest queues (we should dump any tests triggered by glibc 2.39-0ubuntu7 which is now obsolete)
[17:00] <ahasenack> is noble release still a bit inconsistent?
[17:00] <ahasenack>  elinks | 0.16.1.1-4.1ubuntu1 | noble-updates/universe | source
[17:00] <ahasenack>  elinks | 0.16.1.1-4.1ubuntu2 | noble/universe         | source
[17:00] <ahasenack> why would updates have a lower version than release
[17:00] <ahasenack> (and why would updates be populated at this stage)
 we're using the noble-updates pocket to be able to have last-known-good amd64 binaries available, in parallel with the latest versions on all other architectures
[17:02] <RikMills> ahasenack: ^^
[17:02] <ahasenack> ah
[17:03] <ahasenack> I got this weird depwait in a ppa build: Missing build dependencies: elinks-data (= 0.16.1.1-4.1ubuntu1)
[17:04] <RikMills> yeah, it makes some issues with versioned depends on arch:all packages
[17:05] <vorlon> yeah. wrt ppas, these will shake out in the next couple of days as we're able to get rebuilds done in -proposed and then migrated back to the release pocket.  The critical chain here at the moment is publication of libgs10-common removal -> gcc-13 build -> glibc build -> upload the world
[17:06] <vorlon> (don't worry, it's "only" 7172 packages to upload)
[17:07] <vorlon> will aim to get some clearer messaging published about this, but well, holiday weekend
[17:07] <ahasenack> np
[17:12] -queuebot:#ubuntu-release- Unapproved: isc-kea (noble-proposed/main) [2.4.1-2build1 => 2.4.1-3] (no packageset) (sync)
[17:17] <wxl> the Lubuntu ISO failed for an interesting reason today: livecd-rootfs has no installation candidate
[17:33]  * Eickmeyer just is expecting image build failures for the next couple days while everything gets sorted
[17:45] -queuebot:#ubuntu-release- Unapproved: isc-kea (noble-proposed/main) [2.4.1-2build1 => 2.4.1-3] (no packageset) (sync)
[18:19] <vorlon> gcc-13 is building, should be done in a couple of hours
[18:19] <vorlon> accepting gcc-14 now
[18:20] <vorlon> archive is unfrozen again but it's advisable to wait until gcc-13 and glibc are published before uploading stuff so that it gets built with the latest toolchain
[18:20] -queuebot:#ubuntu-release- Unapproved: accepted gcc-14 [source] (noble-proposed) [14-20240330-1ubuntu1]
[18:24] <vorlon> going ahead and uploading livecd-rootfs, it's arch: any but doesn't build any binary artifacts
[18:25] <vorlon> doesn't mean image builds will start working but it can be unblocked all the same
[18:29] -queuebot:#ubuntu-release- Unapproved: accepted isc-kea [sync] (noble-proposed) [2.4.1-3]
[18:29] -queuebot:#ubuntu-release- Unapproved: rejected isc-kea [sync] (noble-proposed) [2.4.1-3]
[18:29] -queuebot:#ubuntu-release- Unapproved: accepted isc-kea [sync] (noble-proposed) [2.4.1-3]
[18:29] <vorlon> accidentally clicked accept on isc-kea when I meant to click reject on the duplicate uploads in the queue; oops oh well
[18:49] <mitya57> vorlon: Hi! Not sure if you saw my question about Qt above, but let me try again:
[18:49] <mitya57> - Currently noble has Qt 5.15.12 but 5.15.13 was published earlier this month. Do I have chances to squeeze it in for noble, or we should better stick to 5.15.12?
[18:49] <mitya57> - If I have chances: I started preparing packages in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4979 but some packages there were built yesterday, which is with liblzma 5.4.5. Should I start from scratch in a new PPA?
[18:51] <doko> well, if you built the *source* with new xz-utils, it should be fine? independent of the new subminor version
[18:53] <mitya57> By source you mean *+dfsg.orig.tar.xz? Then I built it for Debian and it was a few weeks ago.
[18:56] <doko> isn't debian.tar.xz also compressed with lzma?
[18:58] <mitya57> doko: Yes it is. Do we have any evidence that these files may be infected/screwed up, and/or a way to check that?
[19:20] <vorlon> mitya57: we don't have a way to check that no.  The *known* attack is sophisticated enough that we assume there are others and we have not yet characterized them
[19:20] <vorlon> mitya57: but building yesterday with liblzma 5.4.5 is fine? it's 5.6.x that is the known problem
[19:21] <vorlon> mitya57: and as for having time to squeeze things in, well I have no idea at this point.  I don't expect beta to be possible in 6 days but we haven't had a chance to assess full impact since the mitigation work is still ongoing
[19:25] <mitya57> vorlon: "but building yesterday with liblzma 5.4.5 is fine" — ah, right. I didn't see the +really suffix so was confused. But still, there are .debian.tar.xz copied from Debian which were built with 5.6.x.
[19:25] <vorlon> mitya57: that's not a vector that we're currently intending to do anything about.  But if you ask the question "should we trust it?" the answer is "no"
[19:27] <mitya57> Okay. I will probably continue copying stuff from Debian to my PPA and in case we know that .xz files are affected, I'll be able to do *build1 uploads at any time.
[19:27] <vorlon> mitya57: *however*, I will say that in terms of strategy, "injecting code into liblzma to compromise sshd" and "causing liblzma to generate broken compressed files that can then be used to compromise other systems via an undisclosed vulnerability in the decompressor" are quite disjoint
[19:27] <mitya57> Ack. Thanks for your answers (and work on this).
[19:42] <vorlon> gcc-13 almost done (currently at pkgstriptranslations)
[19:43] <vorlon> gonna go ahead and skiptest livecd-rootfs. the autopkgtests don't provide us any additional surety here
[19:45] <vorlon> (the one in release pocket has been removed on amd64 so obviously we can't regress buildability right now!)
[20:15] <vorlon> juliank: I think I've lost track of what's happening with the migration-reference/0 tests.  We will want to preempt these now due to the xz-utils rebuilds.  Did you want these requeued afterwards? At that point I'm not sure it really matters
[20:16] <juliank> vorlon: yeah still *some* time to analyse any regressions we introduced between beta and release
[20:16] <vorlon> juliank: well effectively, tests are going to be retriggered for the world against the packages in -proposed, and if those show up as regressions britney will do its own migration-reference/0 triggers where necessary?
[20:19] <juliank> To some extent yes
[20:20] <juliank> My concern was all-proposed testing with partial migration causing hidden regressions
[20:21] <juliank> Oh? Are they still running, I thought they'd be killed already
[20:21] <vorlon> xz-utils revdep autopkgtest regressions caused by libevent, that's fine; releasing xz-utils now
[20:22] <vorlon> juliank: killing them requires someone to actively do so, and no one has gotten to it yet :) I'll do it now
[20:22] <juliank> Regardless of what I want, you can kill any reference tests, the script will pick that up and add them to the to-be-scheduled output again
[20:22] <juliank> I made magic
[20:23] <vorlon> ack
[20:23] <vorlon> I thought I remembered that was the case but wanted to double-check
[20:24] <vorlon> arm64 queue still won't be quite zeroed, but
[20:24] <vorlon> man, component-mismatches is seriously confused
[20:24] <juliank> The builds happen in chroots, right?
[20:25] <vorlon> yes
[20:25] <juliank> Debian seems to consider to rebuild the machines the chroots are on as well
[20:25] <cjwatson> the builds are also in ephemeral VMs
[20:25] <vorlon> ^
[20:25] <juliank> Ah
[20:25] <juliank> So you boot a VM, and then a chroot in it, fun
[20:25] <vorlon> yeah build isolation has been a concern for a long time, on account of the fact that we have ppas :)
[20:25] <juliank> Right
[20:25] <cjwatson> and the build chain for those VMs didn't involve noble last time I checked, which I doubt very much has changed since November
[20:25] <vorlon> indeed it has not
[20:26] <juliank> Very good
[20:26] <vorlon> and the buildd chroots in launchpad haven't been updated ;P
[20:26] <juliank> Heh
[20:28] <cjwatson> I wrote down how to do that in my handover notes I think
[20:29] <cjwatson> So if the current LP team is lost, that's where to point them ...
[20:29] <vorlon> ack :)
[21:22] <vorlon> building glibc
[22:10] <bdmurray> I sorted out some issues with arm64 queue processing a bit ago.
[22:11] <bdmurray> a bit being like 3 hours ago
[22:19] <vorlon> juliank: https://lists.ubuntu.com/archives/ubuntu-devel/2024-March/042955.html seems like it should be a bug report against gst-plugins-good1.0?
[22:21] <vorlon> glibc built
[23:01] <ricotz> hello ubuntu-archive, would it be possible to delete this source - https://launchpad.net/ubuntu/+source/libreoffice/4:24.2.2-0ubunut1
[23:01] <vorlon> haha
[23:01] <vorlon> ok
[23:02] <ricotz> thanks! and yeah, the typo is one thing :\
[23:02] <ricotz> vorlon, regarding the amd64/arm64 failures, is the archive in a bad state currently?
[23:02] <vorlon> ricotz: mostly on amd64
[23:03] <vorlon> lots of comments on it in scrollback, but basically this is mitigation of the amd64-specific xz-utils backdoor
[23:04] <vorlon> we've rolled back 7k source packages to their pre-xz-utils versions in noble-updates, deleted amd64 binaries from noble and noble-proposed, and that means some packages are uninstallable because of arch: all packages being newer than their arch: amd64 packages
[23:04] <vorlon> and that's not something we'll resolve with blanket removals of arch: all packages because that makes the situation worse for all the other archs, including the much-slower riscv64
[23:05] <ricotz> ok, I see, so uploading e.g. libreoffice won't result in proper build any time soon then
[23:05] <vorlon> anyway, just as soon as glibc publishes (which should be very very soon), I'll be kicking off mass rebuilds
[23:05] <vorlon> oh in fact it looks like glibc is published
[23:06] <vorlon> (to ftpmaster.internal; not to the public mirrors)
[23:06] <ricotz> ah ok, so it won't hurt me uploading it
[23:06] <vorlon> so here we goooooo
[23:08] <LocutusOfBorg> vorlon, can we ask Santa to have binNMU per arch the way Debian has? it would have helped on this issue a lot I guess
[23:08] <LocutusOfBorg> (also time64_t)
[23:08] <ricotz> (debian versions are fun, I would not have expected that 0.19.2-3+b1 is higher than 0.19.2-3build2)
[23:10] <vorlon> LocutusOfBorg: it wouldn't have helped with *this* issue.  And we would've wanted rebuilds on all archs for time_t as well, to ensure switching to the new library packages on upgrade (to not island users on the old package which gets no security updates).  And binNMUs also bring challenges with multiarch co-installability (sometimes Debian winds up doing binNMUs on all architectures for this).  So
[23:10] <vorlon> it's not something I regard as a priority
[23:10] <jbicha> LocutusOfBorg: I've heard people in Debian wish that they only used Ubuntu-style binNMUs
[23:11] <vorlon> ah shoot I thought glibc was in this latest publisher run but it's not
[23:11] <vorlon> holding off for the next one (hopefully quick)
[23:12] <vorlon> jbicha: hiya. is https://lists.ubuntu.com/archives/ubuntu-devel/2024-March/042955.html anything you want to look at? :)
[23:14] <jbicha> that requires more concentration than I have this weekend :)
[23:16] <vorlon> fair!
[23:18] <vorlon> LocutusOfBorg: ok actually I suppose it would have helped with this issue; but the arch:any/arch:all skew thing would've still needed dealing with
[23:49] <vorlon> glibc is published.  Mass rebuilds incoming.
[23:55] <vorlon> accepting all from the unapproved queue
[23:56] -queuebot:#ubuntu-release- Unapproved: accepted haskell-charsetdetect-ae [sync] (noble-proposed) [1.1.0.4-6]
[23:56] -queuebot:#ubuntu-release- Unapproved: accepted haskell-hoogle [sync] (noble-proposed) [5.0.18.3+dfsg1-5]
[23:56] -queuebot:#ubuntu-release- Unapproved: accepted libpng1.6 [sync] (noble-proposed) [1.6.43-5]
[23:56] -queuebot:#ubuntu-release- Unapproved: accepted ukui-panel [sync] (noble-proposed) [4.0.0.4-1]
[23:56] -queuebot:#ubuntu-release- Unapproved: accepted haskell-fgl [sync] (noble-proposed) [5.8.1.1-1]
[23:56] -queuebot:#ubuntu-release- Unapproved: accepted octave-control [source] (noble-proposed) [4.0.1-1ubuntu1]
[23:56] -queuebot:#ubuntu-release- Unapproved: accepted kbuild [sync] (noble-proposed) [1:0.1.9998svn3604+dfsg-1]
[23:56] -queuebot:#ubuntu-release- Unapproved: accepted pkg-haskell-tools [sync] (noble-proposed) [0.12.5]
[23:57] -queuebot:#ubuntu-release- Unapproved: accepted connectagram [sync] (noble-proposed) [1.3.5-2]
[23:57] -queuebot:#ubuntu-release- Unapproved: accepted gcc-13 [source] (noble-proposed) [13.2.0-23ubuntu3]
[23:57] -queuebot:#ubuntu-release- Unapproved: rejected haskell-haskell-gi [source] (noble-proposed) [0.26.7-2ubuntu1]
[23:57] -queuebot:#ubuntu-release- Unapproved: accepted newlib [sync] (noble-proposed) [4.4.0.20231231-2]
[23:57] -queuebot:#ubuntu-release- Unapproved: accepted entropybroker [sync] (noble-proposed) [2.9-8]
[23:57] -queuebot:#ubuntu-release- Unapproved: accepted indi-gige [sync] (noble-proposed) [0.1+20221223115700-2]
[23:57] -queuebot:#ubuntu-release- Unapproved: accepted google-android-installers [sync] (noble-proposed) [1710437545-3]
[23:57] -queuebot:#ubuntu-release- Unapproved: accepted xubuntu-default-settings [source] (noble-proposed) [24.04.3]