/srv/irclogs.ubuntu.com/2023/02/15/#ubuntu-release.txt

vorlonbdmurray: python-apt/jammy accepted00:13
vorlonbdmurray: 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:13
bdmurrayI don't recall that either00:17
=== chris14_ is now known as chris14
=== kgiii_ is now known as KGIII
=== chris14_ is now known as chris14
vorlonjbicha: why debhelper (>= ) + debian/compat instead of debhelper-compat (= 12) for a new package? (rust-gstreamer-player-sys)04:17
vorlonjbicha: what is debian/copyright.debcargo.hint? interesting in principle but the hint is larger than the actual file so04:19
vorlonjbicha: and an empty file debian/RFS04:19
vorlonxnox: interesting that rust-bindgen is pinned to a version that apparently was never uploaded to Debian at all04:23
vorlonxnox: and you have explicit packaging to allow inclusion of windows .dll files... no?04:28
vorlonxnox: if there's a reason this would be ok, please explain; in the meantime I'm rejecting04:30
vorlon(to avoid accidental acceptance that results in the need for bumping the upstream version)04:31
fnordahlRAOF: 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/306:55
-ubottu:#ubuntu-release- Launchpad bug 2003056 in ovn (Ubuntu Jammy) "[SRU] OVN 22.03.2 point release" [High, Triaged]06:55
RAOFfnordahl: 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.06:59
RAOFI'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:03
fnordahlRAOF: 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 review07:09
RAOFWait, how did that work? You had a static list of tests to skip in the package before?07:11
RAOFIs it an upstream change which means there's no longer a static number associated with each test?07:12
RAOFOh, or that the numbers are not append-only?07:13
fnordahlRAOF: 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 numbers07:15
fnordahlAnd also, if a test is added in the middle, the numbers will shuffle07:15
fnordahlThe testsuite is built of many individual *.at files, so shuffling is inevitable if a test is added in any of them07:17
RAOFOk, that's relevant context to why this is a reasonable change. Thanks!07:18
RAOFI'll fish it out of -rejected after dinner.07:19
fnordahlRAOF: thank you for thorough review and good discussion07:20
jbichavorlon: 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/debian09:50
jbichahttps://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/README.rst09:50
jbichathe 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.rst09:52
xnoxvorlon:  the whole rustc toolchain validates all checksums of all files everywhere and the build fails if i drop those .dll10:13
xnoxvorlon: and if anybody will try to touch that package again, and vendor the deps they will come back10:13
xnoxvorlon:  so i'm not sure what i can do there10:13
xnoxtjaalton:  please reject kpatch from kinetic unapproved as it is not needed https://launchpad.net/ubuntu/kinetic/+queue?queue_state=1&queue_text=kpatch10:14
tjaaltonxnox: thanks10:24
tjaaltonxnox: what about jammy?10:24
ricotztjaalton, hello :), have you noticed https://launchpad.net/ubuntu/+source/mesa/22.3.4-1ubuntu1/+build/25559244 ?10:32
tjaaltonricotz: nope, so that's why it's stuck10:33
ricotztjaalton, yeah, missing i386 dep10:33
tjaaltoni386 keeps on giving10:33
xnoxtjaalton:  never proposed any update into jammy =)10:38
tjaaltonxnox: oh, I just assumed it was there, you're right10:39
xnoxwe probably need to seed llvm into the i386 builds, and update the seed/filter in launchpad?10:39
xnoxor do we exclude llvm from i386 can't remember10:39
xnoxnope we totally build it on i386 https://launchpad.net/ubuntu/+source/llvm-toolchain-14/1:14.0.6-10ubuntu1/+build/2546167410:40
tjaaltonright, it just needs 15 there10:40
xnoxhm https://launchpad.net/ubuntu/+source/llvm-toolchain-15/1:15.0.7-1/+build/25486594 but there is 15 on i38610:40
xnoxooooh10:41
tjaaltonah, it's spirv-llvm-translator10:41
tjaaltonnot llvm itself10:41
tjaaltonthis is new10:41
xnoxlet's try adding it to i386 then10:41
tjaaltonbecause of rusticl10:42
xnoxadded it to i386 seed10:44
xnoxbut now archive admin needs to update the seeds; to see if we can build that one easily10:44
xnoxhm but i also see people added sources inside the update-i386-whitelist too10:45
xnoxmaybe my i386 seed update is wrong.10:45
slyonsil2100: bug #2007032 is the tiny systemd-hwe fix I mentioned earlier. Could be a nice to have for .211:06
-ubottu:#ubuntu-release- Bug 2007032 in systemd-hwe (Ubuntu Kinetic) "Add keymap for Dell G16 micmute" [Undecided, In Progress] https://launchpad.net/bugs/200703211:06
sil2100slyon: will check it out, thanks o/11:28
juliankxnox: 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
juliankpossibly it's confusion :D12:06
julianknew grub, fwupd don't need new kernels out first, or timing with new shim, they can go any time :D12:06
juliankEverything broken!12:08
juliankAre we moving the point release a 2nd time?12:08
xnoxjuliank:  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:09
juliankcool dashboard12:10
juliankSo let's release grub2-signed, grub2-unsigned, fwupd-efi, fwupd-signed, shim-signed on kinetic12:11
juliankLet it be a canary!12:11
xnoxjuliank:  it's depressing, when one has to fix every row of that dashboard every single time =)12:43
ograhire an intern 😛12:44
juliankif we had an internship process13:01
juliankhire interns to verify SRUs13:01
juliankthat's a very representative internship experience!13:02
jbichavorlon: I think we need to sync python3-defaults to handle Debian bug 103133613:04
-ubottu:#ubuntu-release- Debian bug 1031336 in python3-distutils "python3-distutils is not installable" [Serious, Open] https://bugs.debian.org/103133613:04
pmatulis2rbasak, hi, i was wondering about when this -proposed focal package would enter -updates :14:13
pmatulis2https://launchpad.net/ubuntu/+source/ovn/20.03.2-0ubuntu0.20.04.414:13
pmatulis2verification has been done afaiu:14:14
pmatulis2https://bugs.launchpad.net/charm-ovn-chassis/+bug/1940043/comments/1114: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]14:14
=== pmatulis2 is now known as pmatulis
vorlonxnox: 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
vorlonjbicha: python3-defaults sync> please check with ginggs / doko then16:44
bdmurraypmatulis: There are 2 bugs requiring verification and only 1 has been done16:46
bdmurrayhttps://people.canonical.com/~ubuntu-archive/pending-sru.html16:46
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Lunar Daily] has been updated (20230215)16:59
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Jammy Daily] has been updated (20230215)17:10
pmatulisbdmurray, gratitude17:35
-queuebot:#ubuntu-release- New binary: ghostscript [i386] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)18:26
-queuebot:#ubuntu-release- New binary: ghostscript [arm64] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)18:30
-queuebot:#ubuntu-release- New binary: ghostscript [s390x] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)18:31
-queuebot:#ubuntu-release- New binary: ghostscript [ppc64el] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)18:33
-queuebot:#ubuntu-release- New binary: ghostscript [armhf] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)18:41
arraybolt3Is 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:51
arraybolt3It 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:52
* 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 made18:53
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Lunar Daily] has been updated (20230215)18:55
jbichaginggs: doko: I'm syncing python3-defaults to unbreak building packages on lunar19:30
ginggsjbicha: i think that was already fixed by python3-stdlib-extensions 3.11.2-219:40
jbichavorlon: could you remove my synced python3-defaults?19:41
ginggsjbicha: i don't that's needed, it would have autosync19:42
ginggs'd anway19:42
jbichaautosync is disabled for python3-defaults19:43
jbichait's going to flood the autopkgtest queues more19:43
* bdmurray would cry some more but is out of tears19:51
-queuebot:#ubuntu-release- New binary: ghostscript [amd64] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)19:54
* Eickmeyer[m] looks at linux-lowlatency in jammy and shares bdmurray's sentiment19:56
vorlonjbicha: the autopkgtests will go to the end of the queue so I don't really care.  I've removed the sync-blacklist entry tho20:08
-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:16
-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:18
ricotzhello :), 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 itself20:31
sarnoldyeah, i think that's known and being worked20:32
ricotzsarnold, I see, thanks20:33
-queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (lunar-proposed/universe) [23.04.1] (personal-fossfreedom, ubuntu-budgie)20:36
-queuebot:#ubuntu-release- New binary: ghostscript [riscv64] (lunar-proposed/main) [10.0.0~dfsg1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)21:25
-queuebot:#ubuntu-release- New binary: retroarch [amd64] (lunar-proposed/universe) [1.14.0+dfsg-1] (no packageset)22:13
bdmurrayricotz[m]: Yes, I'm actively trying to resolve the situation(s)22:18
bdmurrayWhy do we run libreoffice autopkgtests on i386 for >= Jammy?22:26
bdmurrayAdding it to never-run22:37
vorlonbdmurray: because britney doesn't have any logic to exclude triggering packages on i386 which only provide arch: all binaries there22:38
vorlonbdmurray: 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:41
vorlonthe 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:42
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Lunar Daily] has been updated (20230215)22:46
bdmurrayvorlon: Could I also add linux-starfive to never_run i386?22:47
vorlonbdmurray: sure22:57
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Jammy Daily] has been updated (20230215)22:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!