[01:56] -queuebot:#ubuntu-release- New binary: gcc-11-cross-mipsen [arm64] (noble-proposed/universe) [6+c1+nmu1] (no packageset)
[02:06] -queuebot:#ubuntu-release- New binary: gcc-11-cross-mipsen [ppc64el] (noble-proposed/universe) [6+c1+nmu1] (no packageset)
=== chris14_ is now known as chris14
[02:20] -queuebot:#ubuntu-release- New binary: gcc-11-cross-mipsen [amd64] (noble-proposed/universe) [6+c1+nmu1] (no packageset)
[02:21] -queuebot:#ubuntu-release- New: accepted gcc-11-cross-mipsen [amd64] (noble-proposed) [6+c1+nmu1]
[02:21] -queuebot:#ubuntu-release- New: accepted gcc-11-cross-mipsen [ppc64el] (noble-proposed) [6+c1+nmu1]
[02:21] -queuebot:#ubuntu-release- New: accepted gcc-11-cross-mipsen [arm64] (noble-proposed) [6+c1+nmu1]
[02:26] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.10.20]
[02:31] <doko> cpaelzer: promoted ruby3.2, and building on i386. please subscribe server-team
[02:38] <kanashiro> doko I am subscribing the server team, thanks for the promotion
[02:55] -queuebot:#ubuntu-release- Packageset: Added ruby3.2 to i386-whitelist in noble
[03:12] <Eickmeyer> Please reject orchis-kde. Was intended for PPA.
[03:13] -queuebot:#ubuntu-release- New source: orchis-kde (noble-proposed/primary) [2024-01-08-0ubuntu1~ppa3]
[03:16] -queuebot:#ubuntu-release- New: rejected orchis-kde [source] (noble-proposed) [2024-01-08-0ubuntu1~ppa3]
[03:21] <Eickmeyer> thx
[03:43] <mwhudson> LocutusOfBorg: hello i think you can do something with https://salsa.debian.org/pkg-security-team/binwalk/-/merge_requests/1 ?
[03:43] -ubottu:#ubuntu-release- Merge 1 in pkg-security-team/binwalk "Take patch from https://github.com/ReFirmLabs/binwalk/pull/668 for Python 3.12..." [Opened]
[03:51] <mwhudson> this one on the other hand is for ubuntu-archive https://bugs.launchpad.net/ubuntu/+source/bookletimposer/+bug/2052009
[03:51] -ubottu:#ubuntu-release- Launchpad bug 2052009 in bookletimposer (Ubuntu) "please remove bookletimposer from noble" [Undecided, New]
[04:01] <vorlon> yes, we shall have no one else posing as a bookletim in the archive
[04:21] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:18.04.11.23]
[04:24] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (xenial-proposed) [1:16.04.20]
[04:44] -queuebot:#ubuntu-release- New source: orchis-kde (noble-proposed/primary) [2024-01-08-0ubuntu1]
[04:44] <Eickmeyer> XD
[04:45] <Eickmeyer> Seems a little sus
[04:45] <Eickmeyer> Imposters aside, orchis-kde has an ITP bug 2051998
[04:45] -ubottu:#ubuntu-release- Bug 2051998 in Orchis KDE "[ITP] orchis-kde" [Wishlist, In Progress] https://launchpad.net/bugs/2051998
[04:46] <Eickmeyer> Not super urgent, but would like to get it in the archive. Not to be seeded this cycle. materia(-gtk-theme|-kde) is dead upstream, and this is the logical successor.
[05:19] -queuebot:#ubuntu-release- New binary: mystic [amd64] (noble-proposed/none) [0.4.2-1] (no packageset)
=== pushkarnk1 is now known as pushkarnk
[07:09] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (focal-proposed) [2.60.2+20.04]
[07:35] <vorlon> can't do SRU verification of LP: #2050209 because I have to wait for the daily riscv64 server image builds to finish sighhhh
[07:35] -ubottu:#ubuntu-release- Launchpad bug 2050209 in livecd-rootfs (Ubuntu Jammy) "Add support for ubuntu-server live largemem SUBARCH images (64k kernel variant)" [High, Fix Committed] https://launchpad.net/bugs/2050209
[07:36] -queuebot:#ubuntu-release- Unapproved: accepted kdump-tools [source] (mantic-proposed) [1:1.8.1ubuntu1.1]
[07:37] -queuebot:#ubuntu-release- Unapproved: accepted kdump-tools [source] (jammy-proposed) [1:1.6.10ubuntu2.2]
[07:47] <vorlon> well that build is going to fail anyway, so I'll just cancel it
[07:48] -queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (mantic-proposed) [1:5.0.1-0ubuntu8~23.10.1]
[07:48] -queuebot:#ubuntu-release- New: accepted mystic [amd64] (noble-proposed) [0.4.2-1]
[07:58] <zhsj> ubuntu-archive: please remove canu on armhf which is disabled in d/control in the new version.
[08:02] <tjaalton> sudip: the lcov upload refers to two bugreports, but they both seem to be the same bug?
[08:06] <tjaalton> well, no, but it's confusing to mention on the other bug that "it's being handled in NNN"
[08:19] <vorlon> zhsj: done, cheers
[08:19] <zhsj> thx
[08:24] <vorlon> https://autopkgtest.ubuntu.com/packages/libm/libmonitoring-livestatus-perl/noble/arm64 well, now that we have an index again we can see the big picture; this autopkgtest is failing in proposed w/ new perl and it seems to have nothing to do with uninstallability
[08:25] <vorlon> ginggs, doko: ^ this error looks vaguely familiar but I don't know how it was resolved before
[08:26] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (mantic-proposed) [2:23.0.0-0ubuntu1.1]
[08:35] <ginggs> vorlon: in 2024-01-29 11:23:09 UTC ?
[08:36] <vorlon> ginggs: I mean that you, me, and doko have all retried this autopkgtest with the same results
[08:38] <ginggs> well in the result timestamped above, I see
[08:38] <ginggs> 1169s autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from noble-proposed
[08:38] <ginggs> so it might be a case of adding the correct triggers, so that the fallback on all package from -proposed doesn't kick in
[08:39] <ginggs> iirc, we often need to do this during glibc transitions as well
[08:40] -queuebot:#ubuntu-release- Unapproved: accepted dns-root-data [source] (mantic-proposed) [2023112702~ubuntu0.23.10.1]
[08:42] -queuebot:#ubuntu-release- Unapproved: accepted dns-root-data [source] (jammy-proposed) [2023112702~ubuntu0.22.04.1]
[08:43] -queuebot:#ubuntu-release- Unapproved: accepted dns-root-data [source] (focal-proposed) [2023112702~ubuntu0.20.04.1]
[08:44] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (jammy-proposed) [2:20.3.1-0ubuntu1.1]
[08:48] <pushkarnk> vorlon: The libmonitoring-livestatus-perl autopkgtest appears to a flaky one. Running it locally multiple times, with the default number of args = 5, caused a zero memory delta sometimes, sometimes not.
[08:50] <pushkarnk> While attempting to migrate faiss (which blocks python) away from distutils, I realized faiss ftbfs now, mostly because of a new release of swig. Wrote up bug 2052017 and bug 2052041
[08:50] -ubottu:#ubuntu-release- Bug 2052017 in faiss (Ubuntu) "faiss FTBFS on noble" [Undecided, New] https://launchpad.net/bugs/2052017
[08:50] -ubottu:#ubuntu-release- Bug 2052041 in faiss (Ubuntu) "faiss autopkgtests fail with python 3.12" [Undecided, New] https://launchpad.net/bugs/2052041
[09:00] -queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (mantic-proposed) [2.2.0-0ubuntu1~23.10.2]
[09:00] <tchavadar> tjaalton: About bug 2037407, can you please check the bug and if it is ok approve it to jammy? (we have addressed the missing test report from ZCU board recently)
[09:00] -ubottu:#ubuntu-release- Bug 2037407 in flash-kernel (Ubuntu Mantic) "[SRU] Add support for AMD-Xilinx Kria KD240" [Undecided, Fix Committed] https://launchpad.net/bugs/2037407
[09:06] <tjaalton> tchavadar: no release on a Friday, sorry
[09:07] <tchavadar> tjaalton: oh I see, I will ping again on Monday then :)
[09:53] -queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (jammy-proposed) [2.1.5-1ubuntu6~22.04.3]
[09:57] -queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (focal-proposed) [0.8.3-1ubuntu12.17]
[09:57] <tjaalton> tchavadar: yup, that's fine
[10:11] -queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (jammy-proposed) [42.0-1ubuntu7.22.04.4]
[10:20] -queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (jammy-proposed) [1:5.0.0~git2209-g5a7b9ce67-0ubuntu1.1]
[10:25] -queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (jammy-proposed) [1:6.2+dfsg-2ubuntu6.17]
[10:55] -queuebot:#ubuntu-release- Packageset: Added shaderc to i386-whitelist in noble
[10:59] <LocutusOfBorg> rbasak, I read the virtualbox meeting notes, sorry for the tone, and sorry if I didn't address your concerns, there is nothing more than probably misunderstanding of something I missed to do, or failed to update the wiki
[10:59] <LocutusOfBorg> (also vorlon!)
[10:59] <LocutusOfBorg> I'm trying now to login into wiki, but the login page times out
[11:00] <LocutusOfBorg> I'll remove virtualbox from here: https://wiki.ubuntu.com/StableReleaseUpdates
[11:00] <LocutusOfBorg> update this page with what arraybolt3 did as testing https://wiki.ubuntu.com/VirtualboxUpdates
[11:00] <LocutusOfBorg> please ping me if there is something else I can do to move the process on!
[11:00] <LocutusOfBorg> w.r.t. kernel regressing vbox, if you want to have some help, I'm pretty sure I don't know what really happened, but I'm happy to help if possible
=== pushkarnk1 is now known as pushkarnk
[11:24] <LocutusOfBorg> where are the autopkgtest results for virtualbox/jammy? https://autopkgtest.ubuntu.com/packages/virtualbox
[11:32] <rbasak> LocutusOfBorg: thanks. Have you seen https://lists.ubuntu.com/archives/technical-board/2024-February/002879.html ? RAOF will work with you to get the documentation resolved and approved so hopefully it can go smoother in the future.
[11:33] <ginggs> LocutusOfBorg: the results database is having some R & R, see https://discourse.ubuntu.com/t/autopkgtest-service/34490
[11:34] <ginggs> recreation and recovery
=== deathcollege is now known as lemondr0p_
[13:05] <LocutusOfBorg> RAOF, please ping me in case something is missing
[13:06] <LocutusOfBorg> ginggs, thanks!
[13:07] <LocutusOfBorg> vorlon, I wonder (don't know if it makes SRU team easier or not to find what broke in the process). virtualbox autopkgtests fails against some specific kernels, such as linux-meta-azure linux-meta-aws and similar. I don't know why, and why such kernels exists. Maybe the test matrix sees virtualbox as "know to fail" because for some kernel it can't build properly
[13:08] <LocutusOfBorg> and for this reason it is not seen as a regression even when it's supposed to build properly
[13:08] <LocutusOfBorg> xnox, does this make sense? should we blacklist vbox when triggered by some specific kernel flavours?
[13:08] <LocutusOfBorg> https://autopkgtest.ubuntu.com/packages/virtualbox/trusty/amd64
[13:10] <LocutusOfBorg> (not having newer autopkgtests is sad, for example the logs on trusty shows a well known "failed to exec gcc", so we shouldn't be on this issue anymore
[14:06] <tjaalton> I actually thought the vbox exception was settled, which is why the updates got accepted last week.. oops
[14:12] -queuebot:#ubuntu-release- Unapproved: accepted linux-show-player [source] (jammy-proposed) [0.5.2-1ubuntu0.1]
[14:19] -queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (jammy-proposed) [2.7.18-13ubuntu1.2]
[14:24] -queuebot:#ubuntu-release- Unapproved: accepted libslirp [source] (jammy-proposed) [4.6.1-1ubuntu0.1]
[14:26] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (focal-proposed) [2.664.52]
[14:33] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.52]
[14:41] -queuebot:#ubuntu-release- Unapproved: accepted ltrace [source] (focal-proposed) [0.7.3-6.1ubuntu1.1]
[15:09] <LocutusOfBorg> tjaalton, question: is the SRU something like "whitelist a package without checking deeply each time an SRU is requested", so this means that no SRU can be done for new micro releases if the package is not in that page?
[15:09] <LocutusOfBorg> I was thinking (understanding) more as "slow process if you are not on the SRU page, faster if you are", but not "hey don't release if the paperwork is not done"
[15:09] <LocutusOfBorg> (sorry I find difficult to explain the point)
[16:02] <tjaalton> LocutusOfBorg: mmh, well there is the micro-release exception in place, not sure where the line is drawn
[16:03] <tjaalton> but vbox is a stack of packages, so in that sense it makes sense to have a special case for it
[16:13] <LocutusOfBorg> ok, so no general answer :)
[16:14] <LocutusOfBorg> please don't take me wrong, but I would *really* appreciate a fixed set of rules from SRU team, this way people can follow a well defined algorithm for their SRU instead of being blocked by some bits without even noticing...
[16:14] <LocutusOfBorg> like 1) only bugfix patches accepted without SRU whitelist, else 2) ask for SRU whitelist for MRE else 3) security uploads can use newer releases if upstream doesn't release point CVE fixes as patches
[16:15] <LocutusOfBorg> vbox went into case 3 for a couple of times in the past, and to 2 in other cases (even if I discovered the whitelist done by pitti in 2015 or so was not "good" in the current workflow
[16:16] <LocutusOfBorg> I can understand that having a general rule is hard, but please try to be for some minutes inside the head of the developer not knowing understanding if something is done correctly or not
[16:16] <LocutusOfBorg> or if I have to ping/buy beers to have something accepted
[16:17] <LocutusOfBorg> I don't want to be "vbox special" case, or to have to ping here and there, if we have clear rules, I think we all benefits
[16:25] <vorlon> LocutusOfBorg: the point is precisely that we're trying to work out what the rules should be for these packages from the SRU side, so that we as a team are able to refer to something agreed and be consistent.  Because right now it basically just looks like a high-risk black-box upstream dump which falls outside the standard SRU rules
[16:27] <vorlon> (and AIUI, with ambiguous test plan)
[16:49] <mirespace> I filed a bug for cpio, blocking sbuild/unshare-qemuwrapper test: https://bugs.launchpad.net/ubuntu/+source/sbuild/+bug/2052295
[16:49] -ubottu:#ubuntu-release- Launchpad bug 2052295 in cpio (Ubuntu Noble) "autopkgtest unshare-qemuwrapper failing on amd64" [Undecided, In Progress]
[16:49] <mirespace> MP attached to the bug
=== deathcollege is now known as lemondr0p
[18:14] <bdmurray> Also I think it is incorrect to classify virtualbox updates as a microrelease
[18:17] <vorlon> definitely
[22:13] <bluesabre> bdmurray: Let's move Xubuntu to 4 GB. The ISO isn't going to get smaller (everything within only gets bigger), and 4 GB is reasonable for installation media (probably not many flash drives in the 3GB range). https://git.launchpad.net/ubuntu-cdimage/tree/lib/cdimage/tree.py?id=e0361427a783d6d025fc0390b3ff187766edd204#n1986
[22:16] <bdmurray> will do
[22:33] <bdmurray> bluesabre: https://git.launchpad.net/ubuntu-cdimage/commit/?id=c67e5934c74dbb94944d908cdb46d2bb4bddb6f8
[22:33] -ubottu:#ubuntu-release- Commit c67e593 in ubuntu-cdimage "tree.py: bump the size of xubuntu per bluesabre HEAD main"
[23:55] <bluesabre> bdmurray: thanks, as always!