[00:13] <vorlon> bdmurray: python-apt/jammy accepted
[00:13] <vorlon> bdmurray: which reminds me, I don't recall seeing an updated notice to the SRU team about not accepting things without coordination due to the point release?
[00:17] <bdmurray> I don't recall that either
[04:17] <vorlon> jbicha: why debhelper (>= ) + debian/compat instead of debhelper-compat (= 12) for a new package? (rust-gstreamer-player-sys)
[04:19] <vorlon> jbicha: what is debian/copyright.debcargo.hint? interesting in principle but the hint is larger than the actual file so
[04:19] <vorlon> jbicha: and an empty file debian/RFS
[04:23] <vorlon> xnox: interesting that rust-bindgen is pinned to a version that apparently was never uploaded to Debian at all
[04:28] <vorlon> xnox: and you have explicit packaging to allow inclusion of windows .dll files... no?
[04:30] <vorlon> xnox: if there's a reason this would be ok, please explain; in the meantime I'm rejecting
[04:31] <vorlon> (to avoid accidental acceptance that results in the need for bumping the upstream version)
[06:55] <fnordahl> RAOF: I respectfully disagree with the decision to reject the ovn 22.03.2-0ubuntu0.22.04.1 upload, and hope you would consider having another look ref: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2003056/comments/3
[06:55] -ubottu:#ubuntu-release- Launchpad bug 2003056 in ovn (Ubuntu Jammy) "[SRU] OVN 22.03.2 point release" [High, Triaged]
[06:59] <RAOF> fnordahl: So, I'm not disagreeing with extending the set of tests which are skipped; I'm suggesting that "replace a list of tests to run with a script that parses the testsuite and a list of names of tests to skip and then generates a list of tests to run" might not be a minimal fix.
[07:03] <RAOF> I'm not even against the existence of the script + list of tests to skip. I'm just mildly pushing back on running it at package build time (so I have to review the script), rather than running it when generating the source package (so I can review the output of the script).
[07:09] <fnordahl> RAOF: pre-generating the test list and keeping that statically in d/rules would indeed be nice, I'm not sure it would improve reviewability though, given the autotest script is generated at package build time too, so one would have to actually build the package to review
[07:11] <RAOF> Wait, how did that work? You had a static list of tests to skip in the package before?
[07:12] <RAOF> Is it an upstream change which means there's no longer a static number associated with each test?
[07:13] <RAOF> Oh, or that the numbers are not append-only?
[07:15] <fnordahl> RAOF: As long as the testsuite is not changed the test numbers don't change. What triggered the creation of the script was that upstream keeps extending the test matrix, so from one version to the next test A can go from being executed 2 times with two test numbers to being executed 6 times with 6 test numbers
[07:15] <fnordahl> And also, if a test is added in the middle, the numbers will shuffle
[07:17] <fnordahl> The testsuite is built of many individual *.at files, so shuffling is inevitable if a test is added in any of them
[07:18] <RAOF> Ok, that's relevant context to why this is a reasonable change. Thanks!
[07:19] <RAOF> I'll fish it out of -rejected after dinner.
[07:20] <fnordahl> RAOF: thank you for thorough review and good discussion
[09:50] <jbicha> vorlon: Debian Rust packaging uses a mono repo & partially generated packaging. It's wild. Currently it uses the old debian/compat style. https://salsa.debian.org/rust-team/debcargo-conf/-/tree/master/src/gstreamer-player-sys/debian
[09:50] <jbicha> https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/README.rst
[09:52] <jbicha> the Debian maintainer is not a DD so he'll need a sponsor to get it through Debian's NEW queue so I think I'll leave the RFS file https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/CONTRIBUTING.rst
[10:13] <xnox> vorlon:  the whole rustc toolchain validates all checksums of all files everywhere and the build fails if i drop those .dll
[10:13] <xnox> vorlon: and if anybody will try to touch that package again, and vendor the deps they will come back
[10:13] <xnox> vorlon:  so i'm not sure what i can do there
[10:14] <xnox> tjaalton:  please reject kpatch from kinetic unapproved as it is not needed https://launchpad.net/ubuntu/kinetic/+queue?queue_state=1&queue_text=kpatch
[10:24] <tjaalton> xnox: thanks
[10:24] <tjaalton> xnox: what about jammy?
[10:32] <ricotz> tjaalton, hello :), have you noticed https://launchpad.net/ubuntu/+source/mesa/22.3.4-1ubuntu1/+build/25559244 ?
[10:33] <tjaalton> ricotz: nope, so that's why it's stuck
[10:33] <ricotz> tjaalton, yeah, missing i386 dep
[10:33] <tjaalton> i386 keeps on giving
[10:38] <xnox> tjaalton:  never proposed any update into jammy =)
[10:39] <tjaalton> xnox: oh, I just assumed it was there, you're right
[10:39] <xnox> we probably need to seed llvm into the i386 builds, and update the seed/filter in launchpad?
[10:39] <xnox> or do we exclude llvm from i386 can't remember
[10:40] <xnox> nope we totally build it on i386 https://launchpad.net/ubuntu/+source/llvm-toolchain-14/1:14.0.6-10ubuntu1/+build/25461674
[10:40] <tjaalton> right, it just needs 15 there
[10:40] <xnox> hm https://launchpad.net/ubuntu/+source/llvm-toolchain-15/1:15.0.7-1/+build/25486594 but there is 15 on i386
[10:41] <xnox> ooooh
[10:41] <tjaalton> ah, it's spirv-llvm-translator
[10:41] <tjaalton> not llvm itself
[10:41] <tjaalton> this is new
[10:41] <xnox> let's try adding it to i386 then
[10:42] <tjaalton> because of rusticl
[10:44] <xnox> added it to i386 seed
[10:44] <xnox> but now archive admin needs to update the seeds; to see if we can build that one easily
[10:45] <xnox> hm but i also see people added sources inside the update-i386-whitelist too
[10:45] <xnox> maybe my i386 seed update is wrong.
[11:06] <slyon> sil2100: bug #2007032 is the tiny systemd-hwe fix I mentioned earlier. Could be a nice to have for .2
[11:06] -ubottu:#ubuntu-release- Bug 2007032 in systemd-hwe (Ubuntu Kinetic) "Add keymap for Dell G16 micmute" [Undecided, In Progress] https://launchpad.net/bugs/2007032
[11:28] <sil2100> slyon: will check it out, thanks o/
[12:06] <juliank> xnox: how da kernels looking? anything needs help? everything else of the new boot stack is releasable (grub and fwupd have been for weeks but I don't know why nobody releases them)
[12:06] <juliank> possibly it's confusion :D
[12:06] <juliank> new grub, fwupd don't need new kernels out first, or timing with new shim, they can go any time :D
[12:08] <juliank> Everything broken!
[12:08] <juliank> Are we moving the point release a 2nd time?
[12:09] <xnox> juliank:  https://kernel.ubuntu.com/sru/dashboards/web/kernel-stable-board.html?cycle=2023.01.02 so kinetic is done! everything else still has laggers.
[12:10] <juliank> cool dashboard
[12:11] <juliank> So let's release grub2-signed, grub2-unsigned, fwupd-efi, fwupd-signed, shim-signed on kinetic
[12:11] <juliank> Let it be a canary!
[12:43] <xnox> juliank:  it's depressing, when one has to fix every row of that dashboard every single time =)
[12:44] <ogra> hire an intern 😛
[13:01] <juliank> if we had an internship process
[13:01] <juliank> hire interns to verify SRUs
[13:02] <juliank> that's a very representative internship experience!
[13:04] <jbicha> vorlon: I think we need to sync python3-defaults to handle Debian bug 1031336
[13:04] -ubottu:#ubuntu-release- Debian bug 1031336 in python3-distutils "python3-distutils is not installable" [Serious, Open] https://bugs.debian.org/1031336
[14:13] <pmatulis2> rbasak, hi, i was wondering about when this -proposed focal package would enter -updates :
[14:13] <pmatulis2> https://launchpad.net/ubuntu/+source/ovn/20.03.2-0ubuntu0.20.04.4
[14:14] <pmatulis2> verification has been done afaiu:
[14:14] <pmatulis2> https://bugs.launchpad.net/charm-ovn-chassis/+bug/1940043/comments/11
[14:14] -ubottu:#ubuntu-release- Launchpad bug 1940043 in Ubuntu Cloud Archive wallaby "Upgrade from OVN 20.03 to newer OVN version will cause data plane outage" [High, Triaged]
[16:44] <vorlon> xnox: sorry it's hard; nevertheless that's not a justification for shipping sourceless .dll files in main/universe.  As far as re-vendoring deps, that's a good reason to have something in debian/rules to automate this?
[16:44] <vorlon> jbicha: python3-defaults sync> please check with ginggs / doko then
[16:46] <bdmurray> pmatulis: There are 2 bugs requiring verification and only 1 has been done
[16:46] <bdmurray> https://people.canonical.com/~ubuntu-archive/pending-sru.html
[16:59] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Lunar Daily] has been updated (20230215)
[17:10] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Jammy Daily] has been updated (20230215)
[17:35] <pmatulis> bdmurray, gratitude
[18:26] -queuebot:#ubuntu-release- New binary: ghostscript [i386] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:30] -queuebot:#ubuntu-release- New binary: ghostscript [arm64] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:31] -queuebot:#ubuntu-release- New binary: ghostscript [s390x] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:33] -queuebot:#ubuntu-release- New binary: ghostscript [ppc64el] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:41] -queuebot:#ubuntu-release- New binary: ghostscript [armhf] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[18:51] <arraybolt3> Is it already a known problem that python3 is gunked up again? A bunch of packages (including python3-lib2to3) have unsatisfiable deps, which is causing build failures that can be reproduced both locally and on LP.
[18:52] <arraybolt3> It seems like it might be that only some of the packages migrated from Debian to Ubuntu via autosync or the like - is that possible?
[18:53]  * arraybolt3 is now realizing it may have been better to just wait and see if it auto-ungunked rather than bringing it up only ~six hours after the Debian upload was made
[18:55] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Lunar Daily] has been updated (20230215)
[19:30] <jbicha> ginggs: doko: I'm syncing python3-defaults to unbreak building packages on lunar
[19:40] <ginggs> jbicha: i think that was already fixed by python3-stdlib-extensions 3.11.2-2
[19:41] <jbicha> vorlon: could you remove my synced python3-defaults?
[19:42] <ginggs> jbicha: i don't that's needed, it would have autosync
[19:42] <ginggs> 'd anway
[19:43] <jbicha> autosync is disabled for python3-defaults
[19:43] <jbicha> it's going to flood the autopkgtest queues more
[19:51]  * bdmurray would cry some more but is out of tears
[19:54] -queuebot:#ubuntu-release- New binary: ghostscript [amd64] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[19:56]  * Eickmeyer[m] looks at linux-lowlatency in jammy and shares bdmurray's sentiment
[20:08] <vorlon> jbicha: the autopkgtests will go to the end of the queue so I don't really care.  I've removed the sync-blacklist entry tho
[20:16] -queuebot:#ubuntu-release- Unapproved: docker.io (kinetic-proposed/universe) [20.10.21-0ubuntu1~22.10.1 => 20.10.21-0ubuntu1~22.10.2] (no packageset)
[20:18] -queuebot:#ubuntu-release- Unapproved: docker.io (jammy-proposed/universe) [20.10.21-0ubuntu1~22.04.1 => 20.10.21-0ubuntu1~22.04.2] (no packageset)
[20:31] <ricotz> hello :), is anyone looking into the autopkgtests situation? occurrences of "No space left on device" in https://autopkgtest.ubuntu.com/running looks like something which doesn't resolve itself
[20:32] <sarnold> yeah, i think that's known and being worked
[20:33] <ricotz> sarnold, I see, thanks
[20:36] -queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (lunar-proposed/universe) [23.04.1] (personal-fossfreedom, ubuntu-budgie)
[21:25] -queuebot:#ubuntu-release- New binary: ghostscript [riscv64] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
[22:13] -queuebot:#ubuntu-release- New binary: retroarch [amd64] (lunar-proposed/universe) [1.14.0+dfsg-1] (no packageset)
[22:18] <bdmurray> ricotz[m]: Yes, I'm actively trying to resolve the situation(s)
[22:26] <bdmurray> Why do we run libreoffice autopkgtests on i386 for >= Jammy?
[22:37] <bdmurray> Adding it to never-run
[22:38] <vorlon> bdmurray: because britney doesn't have any logic to exclude triggering packages on i386 which only provide arch: all binaries there
[22:41] <vorlon> bdmurray: it would require some thinking about; if there is an Arch: all package which both depends on and is depended on by Arch: i386 binaries that we do build, should that package get tested?
[22:42] <vorlon> the existing policy is "meh whatever yes the arch: all binaries are published on i386 and therefore trigger tests but it's still fewer tests than were triggered when we were building the full arch and may not be worth optimizing"
[22:46] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Lunar Daily] has been updated (20230215)
[22:47] <bdmurray> vorlon: Could I also add linux-starfive to never_run i386?
[22:57] <vorlon> bdmurray: sure
[22:58] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Jammy Daily] has been updated (20230215)