[00:02] -queuebot:#ubuntu-release- New: accepted macromoleculebuilder [arm64] (jammy-proposed) [3.5+dfsg-4ubuntu1] [00:15] schopin: fwiw you didn't subscribe ubuntu-archive to LP: #1964367 but I found it anyway [00:15] Launchpad bug 1964367 in virtuoso-opensource (Ubuntu) "virtuoso-opensource: remove armhf and s390x binaries from Jammy" [Undecided, Fix Released] https://launchpad.net/bugs/1964367 [01:48] -queuebot:#ubuntu-release- Unapproved: glibc (focal-proposed/main) [2.31-0ubuntu9.7 => 2.31-0ubuntu9.8] (core, i386-whitelist) [07:27] -queuebot:#ubuntu-release- Unapproved: linux-firmware (focal-proposed/main) [1.187.28 => 1.187.29] (core, kernel) [08:36] cjwatson: kubuntu livefs failed again this morning https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/jammy/kubuntu [08:36] the 'fixed harder' didn't work [08:40] xubuntu also failed. possibly others [08:50] ubuntu worked but maybe we just got lucky [08:59] vorlon: oh? thanks! [09:15] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (impish-proposed/main) [2.742.4 => 2.742.5] (desktop-core, i386-whitelist) [09:23] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.40 => 2.664.41] (desktop-core, i386-whitelist) [09:28] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.57 => 2.525.58] (desktop-core) [09:55] sil2100: FYI - I have updated the virt-manager FFe bug and I think it is now ready for (re)evaluation for an FFe approval by the release team. (https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1961027) [09:55] Launchpad bug 1961027 in virt-manager (Ubuntu) "[FFE] merge virt-manger >3.2 for Jammy once released" [Critical, New] [10:14] cpaelzer: thanks, let me look in a moment! [10:20] RikMills: Yeah, I updated our ticket with IS last night with some more details of failures we've observed [10:26] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (focal-proposed) [1.187.29] [13:47] -queuebot:#ubuntu-release- Unapproved: keyutils (bionic-proposed/main) [1.5.9-9.2ubuntu2 => 1.5.9-9.2ubuntu2.1] (core) [13:48] sil2100: o/ I've got an urgent customer SRU request that's been through a couple of review iterations already. It's keyutils in Bionic. I've SRU-reviewed it already and it's ready to accept, but I'd like to make an exception that I don't feel comfortable making without checking with another SRU team member first. It would mean accepting into Bionic (and releasing when tested by the customer, [13:48] shortening the usual 7-day aging) without Focal and Impish fixed. So for a while there would be a user regression if they upgrade from Bionic to Focal. In mitigation that's theoretical because this customer knows about it and don't intend to do that upgrade, and we know of nobody else even affected by this bug. Jammy is fixed. For Focal and Impish the backport is more complicated and that's why it [13:48] hasn't been resolved yet. But utkarsh2102 commits to making sure that he will also fix Focal and Impish soon. Does that sound OK to you? [13:49] rbasak: hey! Let me take a look at the upload there, gather some context and get back to you in a minute. I'll just finish up the SRU review that I'm doing right now! [13:51] Thanks! Apart from the above question, I'm happy to accept it to Bionic now. The Focal and Impish need adjusting and I'm rejecting them now. [13:52] -queuebot:#ubuntu-release- Unapproved: rejected keyutils [source] (focal-proposed) [1.6-6ubuntu1.1] [13:52] -queuebot:#ubuntu-release- Unapproved: rejected keyutils [source] (impish-proposed) [1.6.1-2ubuntu2.1] [13:56] -queuebot:#ubuntu-release- Unapproved: accepted command-not-found [source] (impish-proposed) [21.10.1] [13:58] -queuebot:#ubuntu-release- Unapproved: accepted command-not-found [source] (focal-proposed) [20.04.6] [14:02] -queuebot:#ubuntu-release- Unapproved: accepted command-not-found [source] (bionic-proposed) [18.04.6] [14:05] rbasak: ok, this sounds fine, if utkarsh2102 makes sure it's handled for the later releases in the next 1-2 weeks [14:05] rbasak: feel free to accept o/ [14:12] ginggs, doko: FWIW I'm still looking at a couple of python3.10 + setuptools / distutils issues, but other things on the go too. hopefully will have some patches in a couple of days [14:13] tumbleweed: thank you! [14:17] sil2100: thanks! [14:18] I'll accept it now. [14:19] -queuebot:#ubuntu-release- Unapproved: accepted keyutils [source] (bionic-proposed) [1.5.9-9.2ubuntu2.1] [14:26] -queuebot:#ubuntu-release- Unapproved: libreoffice (impish-proposed/main) [1:7.2.5-0ubuntu0.21.10.1 => 1:7.2.6-0ubuntu0.21.10.1] (ubuntu-desktop) [15:03] sil2100, hello :), I am hoping you have time to look at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1963279 [15:03] Launchpad bug 1963279 in libreoffice (Ubuntu Impish) "[SRU] libreoffice 7.2.6 for impish" [High, In Progress] [15:16] o/ [15:23] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (impish-proposed) [1:7.2.6-0ubuntu0.21.10.1] [15:25] thank you very much :) [15:30] sil2100, rbasak: thank you very much! I've informed the partner and they're testing it right now. And I'll take care of Focal and Impish by the next week (or two) === dbungert1 is now known as dbungert [16:11] oh great, I can't reproduce the osslsigncode build failure locally. >_< [16:12] vorlon: maybe a TZ issue? It's all related to timestamps [16:16] schopin: Debian maintainer disabled the test suite in a subsequent upload, so I'm doing the same [16:18] osslsigncode seems perfectly compatible with openssl, just got stuck because the Debian maintainer had enabled a buggy test suite [16:18] at just the wrong time for us [16:38] -queuebot:#ubuntu-release- New source: xilinx-runtime (jammy-proposed/primary) [2.8.743-0ubuntu5] [16:42] -queuebot:#ubuntu-release- New: accepted xilinx-runtime [source] (jammy-proposed) [2.8.743-0ubuntu5] [17:02] -queuebot:#ubuntu-release- New binary: xilinx-runtime [arm64] (jammy-proposed/universe) [2.8.743-0ubuntu5] (no packageset) [17:03] -queuebot:#ubuntu-release- New: accepted xilinx-runtime [arm64] (jammy-proposed) [2.8.743-0ubuntu5] [17:04] -queuebot:#ubuntu-release- New source: cd-boot-images-riscv64 (jammy-proposed/primary) [1] [17:06] -queuebot:#ubuntu-release- New: accepted cd-boot-images-riscv64 [source] (jammy-proposed) [1] [17:08] -queuebot:#ubuntu-release- New: accepted opm-simulators [amd64] (jammy-proposed) [2021.10-4ubuntu1] [17:08] -queuebot:#ubuntu-release- New: accepted opm-simulators [ppc64el] (jammy-proposed) [2021.10-4ubuntu1] [17:08] -queuebot:#ubuntu-release- New: accepted opm-simulators [arm64] (jammy-proposed) [2021.10-4ubuntu1] [17:22] would someone please 'force-badtest pyfai/0.21.1+dfsg1-1build1/ppc64el' ? it has already regressed in release in the same way on all other architectures, but migration-reference/0 gives me neutral because of skip-not-installable [17:25] ginggs: ack [17:25] vorlon: ta! [17:25] ginggs: doen [17:55] -queuebot:#ubuntu-release- New: accepted cd-boot-images-riscv64 [riscv64] (jammy-proposed) [1] [18:30] hi release team, debian just removed src:libnfsidmap-regex from debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006709) [18:30] Debian bug 1006709 in ftp.debian.org "RM: libnfsidmap-regex -- ROM; not needed anymore as provided with src:nfs-utils" [Normal, Open] [18:30] more fun for me, to start providing bin:libnfsidmap-regex built from src:nfs-utils, or work on a MIR for being able to include the libnfsidmap-regex code in bin:libnfsidmap1 (built from src:nfs-utils), just like debian [18:31] just letting you know I'm aware of it, and considering my options [18:37] cjwatson: Studio failed today, same issue. [18:42] -queuebot:#ubuntu-release- Unapproved: rejected glibc [source] (focal-proposed) [2.31-0ubuntu9.8] [18:51] Eickmeyer: Yep, as I mentioned to Rik I escalated it again last night [18:51] No word yet though [19:02] bdmurray: what is stopping https://launchpad.net/ubuntu/+source/sbsigntool/0.9.2-2ubuntu1~18.04.1 from being merged? cjwatson asked me to SRU a patch for signing riscv64 images. But I guess the previous SRU should be finished first. [19:04] ... for bionic (as this is the release on our signing box) [19:05] xypron: I see that package version as being in bionic [19:07] bdmurray: in updates ok [19:07] ahasenack: does a decision need to be made on libnfsidmap-regex for jammy? We don't have to remove the package before release just because Debian has; OTOH the package is in universe and has no reverse-depends so even if we did I'm not sure how significant the impact is [19:07] (the package name itself personally makes me shudder, if I found myself managing nfs idmaps with a regex engine I would be rethinking my life choices) [19:08] bdmurray: so this will not be added to release? [19:08] vorlon: realistically, only if the security team could ack a yet-to-be-written MIR for it [19:08] vorlon: for now, let's keep it [19:08] it works with nfs-utils as we have it in jammy now [19:09] it's delta with debian we can manage [19:09] although an alternative it to just create a bin:libnfsidmap-regex package from src:nfs-utils [19:09] no mir needed, and we keep the status quo, and we could then remove src:libnfsidmap-regex [19:09] xypron: you have the wrong end of the stick [19:09] a bit more of delta with debian [19:10] because they package that regex.so together with bin:libnfsidmap1 [19:10] what we're asking for is whether the riscv64 support added in https://launchpad.net/ubuntu/+source/sbsigntool/0.9.4-2ubuntu1 could please be either backported or cherry-picked to bionic-updates and focal-updates, as SRUs [19:10] let's keep it as is, there are options [19:10] in order to support riscv64 signing by Launchpad [19:11] bionic (the release pocket) is frozen as of release time, which we know very well and so we certainly would not have asked for it to be updated :-) [19:12] cjwatson: sorry for my missing understanding. The patch for RISC-V has been accepted in upstream and will prepare an SRU. Is Bionic alone enough? [19:12] xypron: see https://wiki.ubuntu.com/StableReleaseUpdates for how this works. An SRU that has reached -updates is complete [19:12] cjwatson: wait, who's signing what on riscv64? [19:13] xypron: It should really ideally be in both bionic-updates and focal-updates, so that if we upgrade the signing service to focal rather than directly to jammy then the feature doesn't regress [19:13] vorlon: xnox and xypron were asking for this in ~launchpad a while back; I don't know what the signing regime is but this was just with ad-hoc generated PPA keys [19:13] hmm [19:13] ok [19:14] if it's just ppa keys then that's fine for now; I've specifically asked that we not be signing any riscv64 artifacts with the Ubuntu keys [19:14] until there is a use case for them that's not snakeoil [19:14] right, that's fair enough, I'm just thinking of getting enablement going [19:14] * vorlon nods [19:24] jbicha: LP: #1964407> omg [19:25] Launchpad bug 1964407 in rutilt (Ubuntu) "Please remove rutilt from Ubuntu" [Undecided, New] https://launchpad.net/bugs/1964407 [19:35] cjwatson: LP #1964510 [19:35] Launchpad bug 1964510 in sbsigntool (Ubuntu) "[SRU] enable signing riscv64 binaries in bionic" [Undecided, New] https://launchpad.net/bugs/1964510 [20:58] xypron: brilliant, thanks! [21:14] So I suggest we do a quasi-sync of mariadb-10.6 (LP: #1964045) to make progress on openssl 1.1, but rbasak rightly points out that we can expect a ppc FTBFS with that (debbug 1006527). Shall we proceed? [21:14] Launchpad bug 1964045 in mariadb-10.6 (Ubuntu) "FTBFS with current test suite" [Undecided, Confirmed] https://launchpad.net/bugs/1964045 [21:24] dbungert: I'm happy with proceeding, if there are build failures I always prefer they be visible in -proposed than somewhere else :) [21:28] currently buliding [21:29] vorlon: thanks! [21:34] I just looked to see if someone was expecting me to sponsor the sync. Why the ubuntu1 upload instead of a sync directly from experimental? [21:34] Anyway it's not important. I'm just curious to know the logic there. [21:34] rbasak: to avoid a ~exp1 version number in an LTS release [21:34] (so, cosmetics) [21:34] OK :) [22:56] rbasak, dbungert: mariadb-10.6 built on ppc64el? [22:57] vorlon: looking at tasksel one of its reverse dependencies is provided by the debian-science source package which also produces some science-* metapackages. [22:57] vorlon: Given that I'm not sure if it is still worth trying to remove tasksel. [23:04] vorlon: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/3478b9d9b2f0520be4f36b84aa444e4cdb90e9da [23:04] Commit 3478b9d in mariadb-team/mariadb-server "Fix htm use on PowerPC to fix build failure (might close #1006527)" [23:31] bdmurray: feel free to close the bug in this case [23:35] https://buildd.debian.org/status/package.php?p=mariadb-10.6&suite=experimental [23:36] Is the Ubuntu upload not exactly the same? Or some build dependency difference? [23:41] the ubuntu source difference should just be changelog + what `update-maintainer` does