[07:16] <LocutusOfBorg> wow xnox!
[07:16] <LocutusOfBorg> so R^3: no was actually correct in vbox?
[07:36] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-adkins-meta [sync] (focal-proposed) [20.04~ubuntu1]
[07:37] <apw> vorlon, the abi changes on 99% of all uploads
[07:43] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-adkins-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[07:44] <apw> vorlon, we may have also transitioned you between streams at the same time though, 460->470 or some such.
[07:45] -queuebot:#ubuntu-release- New: accepted oem-sutton.simon-barbara-meta [sync] (focal-proposed) [20.04~ubuntu1]
[07:49] -queuebot:#ubuntu-release- New binary: oem-sutton.simon-barbara-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[07:51] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-canyon-meta [sync] (focal-proposed) [20.04~ubuntu1]
[08:02] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-canyon-meta [amd64] (focal-proposed/universe) [20.04~ubuntu1] (canonical-oem-metapackages)
[08:02] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-aenedleah-meta [sync] (focal-proposed) [20.04~ubuntu1]
[08:05] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-aenedleah-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[08:09] <laney> sil2100: you reviewing those oem metas?
[08:09] <laney> just as a reminder, they need to be accepted into main
[08:11] <sil2100> laney: yessir! I remember that, will promote them afterwards
[08:11] <sil2100> I just can't insta-accept them into main as sru-review doesn't support such an operation
[08:12] <sil2100> But it's on my radar, will do that once I accept all the binaries
[08:12] <laney> okey
[08:12] <laney> sru-review needs sorting out a bit for these things
[08:12] <laney> like fixing the tasks properly
[08:13] <laney> anyway thanks for doing that!
[08:13] <sil2100> Yeah, I'm for instance sadly adding the bug tasks manually after each accept, since only then it's possible to do that - earlier the package is still unknown
[08:14] <sil2100> But it's okay
[08:14] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-adrian-meta [sync] (focal-proposed) [20.04~ubuntu1]
[08:15] <laney> I'm not sure which order LP will let things happen in, but the tool could do the accept(); fix_tasks(); dance
[08:15] <laney> also take the component to accept into main directly
[08:15] <laney> anywayyayay
[08:16] <RikMills> sil2100: if I upload a focal plasma SRU later today, is there a chance to get it in the point release?
[08:17] <RikMills> it is just the bugfixes, so 12 packages instead of 40+
[08:18] <sil2100> RikMills: oh my, if you feel this isn't too risky, sure
[08:18] <sil2100> We'd have to get the SRUs prepared and accepted today
[08:18] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-adrian-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[08:23] <RikMills> sil2100: if you think its better, I can do this right after the point release. not a big deal
[08:24] <mwhudson> sil2100: can we get a focal live server image build with livecd-rootfs from proposed?
[08:24] <sil2100> mwhudson: hey! Sure, I can do that o/
[08:24] <mwhudson> ty
[08:24] <sil2100> Though I don't think I have any way of stopping it from going to current/
[08:24] <sil2100> ...guess that's fine?
[08:25] <laney> do another non proposed one straight after ;-)
[08:28] <RikMills> sil2100: in fact lets wait on the plasma SRU. would hate to make a mistake in haste. I will let it be tested in a PPA for a week or two
[08:28] <RikMills> sorry for the noise
[08:29] <sil2100> RikMills: no worries! I mean, maybe I'm oversensitive, but with the recent point-release hiccups we had, I feel as if playing it safe is a much better option
[08:29] <RikMills> yep, very fair point
[09:09] <mwhudson> sil2100: yeah i think what laney says is probably ok
[09:09] <mwhudson> sil2100: i can probably sabotage the ci runs somehow :)
[09:45] <doko> fyi, gcc-defaults pointing to GCC 11 is now in impish-proposed, but not yet built on all archs. will follow-up once it it built everywhere
[09:49] <schopin> what's the policy regarding autopkgtests failures caused by testbed limitations rather than the tested software itself? i.e. Debian bug https://bugs.debian.org/961138 causing the following failures https://autopkgtest.ubuntu.com/packages/r/r-bioc-rtracklayer/bionic/amd64
[09:49] <ubottu> Debian bug 961138 in autodep8 "autodep8 uses host APT packages to generate dependencies for pkg-r-autopkgtest tests" [Normal, Open]
[09:49] <schopin> is it reasonable to add a britney override on a case-by-case basis?
[10:19] <mwhudson> sil2100: can you ping me / comment on one of the SRU bugs when that proposed=1 build finishes?
[10:19]  * mwhudson falls azleep
[10:33] <sil2100> o/
[10:33] <sil2100> uh, what the heck, the build died
[10:35] <sil2100> I'll restart those without --live once the arm64 live build finishes
[10:57] <sil2100> Ok, this time it didn't barf, I see it's moving on as expected
[10:59] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-adrion-meta [sync] (focal-proposed) [20.04~ubuntu1]
[11:02] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-adrion-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[11:03] <sil2100> mwhudson: hey! Ok, so the build seems to have finished, 20210805.1 is the publish ID
[11:03] <sil2100> Let me comment on the bug as well
[11:08] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carin-meta [sync] (focal-proposed) [20.04~ubuntu1]
[11:12] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-carin-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[13:32] <slyon> Hey! I have a question regarding systemd vs snapd for the ubuntu-release team: For this cycle we wanted to switch to cgroups v2 in systemd by default and feature freeze is approaching, but snapd isn't quite ready yet (pending review & testing: https://github.com/snapcore/snapd/pulls?q=is%3Apr+is%3Aopen+label%3Acgroupv2), thus enabling cgroups v2 would break snapd and systemd autopkgtest and block migration.
[13:32] <slyon> How to handle this situation? I see 3 options (non of which is ideal):
[13:32] <slyon> 1/ postpone cgroups v2 to next cycle
[13:32] <slyon> 2/ upload systemd, blocking the migration and wait for snapd to deploy the pending fixes
[13:32] <slyon> 3/ wait for snapd to deploy the fixes and request a FFe for systemd
[13:32] <slyon> what's the release team's opinion on this?
[13:37] <stgraber> I'd go with 2). It'd also be interesting to understand what the adt failures would be for snapd. With my LXD hat on, we have our snap running on a variety of distros that made the switch to cgroup2 and it's working just fine. The main visible issue is the snapd warning message every time a command is run and in the backend there's the issue that some operations that use the freezer cgroup
[13:37] <stgraber> will run without it.
[13:37] <stgraber> but if that's the extent of it, I'd probably argue we shouldn't even hold the entire migration in -proposed but let it hit the release pocket so we have more time to find additional issues with cgroup2 and just get a commitment from the snapd team that cgroup2 support will be there by beta or final freeze
[13:38] <stgraber> postponing by one release means switching to cgroup2 on an LTS which seems like a terrible plan to me
[13:39] <stgraber> and similarly, switching systemd at the last minute in the 21.10 cycle makes it very likely we'll be dealing with a bunch of potentially complex issues as SRUs
[13:43] <LocutusOfBorg> vorlon, hello, please hint node-websocket-driver? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991820 regressed in release, rc buggy in Debian, fails testsuite too there
[13:43] <ubottu> Debian bug 991820 in src:node-websocket-driver "node-websocket-driver: autopkgtest needs update for new version of nodejs: DeprecationWarning: The legacy HTTP parser is deprecated." [Serious, Open]
[13:43] <bdmurray> v_orlon is out this week
[13:44] <bdmurray> laney: could you look at bug 1843049 and add boxer-data to the sync-blacklist?
[13:44] <ubottu> Bug 1843049 in boxer-data (Ubuntu) "boxer-data: please keep it out from eoan" [Undecided, New] https://launchpad.net/bugs/1843049
[13:45] <slyon> thanks for your stance on this, stgraber! I'm currently doing some testing around this here: https://bileto.ubuntu.com/excuses/4602/impish.html For snapd it seems to be the "tests/smoke/sandbox" test that is failing, for systemd its only the "tests-in-lxd" tests that are failing, only for that LXD/snapd "WARNING" message that you mentioned. That warning message is logged to stderr and picked up by autopkgtest, failing those tests. systemd
[13:45] <slyon> tests would most probably pass it the warning wouldn't be there
[13:48] <slyon> option (2) was also what was suggested to do by the snapd team. So it's good being on the same page here. I'll let this age a bit to give others a chance to jump in and do some more testing on my side. If I do not hear any objections, I'll enable cgroups v2 in systemd within the next two weeks
[14:15] <laney> bdmurray: will do
[14:38] -queuebot:#ubuntu-release- New: accepted oem-sutton.simon-aenescumb-meta [sync] (focal-proposed) [20.04~ubuntu1]
[14:40] -queuebot:#ubuntu-release- New binary: oem-sutton.simon-aenescumb-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[15:22] -queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (focal-proposed) [1:3.36.5-0ubuntu3]
[15:38] <stgraber> slyon: we could probably have the snapd team make the warning disappear when a particular env variable is set
[15:38] <stgraber> slyon: that would then make it easier to still run normal adt tests without the warning on stderr causing everything to fail
[15:38] <stgraber> (while retaining it for actual users)
[15:44] <slyon> stgraber: that's a good idea! I might come up with a snapd PR tomorrow and propose that change to the snapd team
[15:44] -queuebot:#ubuntu-release- New: accepted oem-sutton.simon-cabernet-meta [sync] (focal-proposed) [20.04~ubuntu1]
[15:45] <juliank> Debian's release is next Saturday, I wonder if it would make sense to stop the importer a few days earlier to not get all the fancy new stuff hitting unstable directly before feature freeze
[15:46] <laney> could be a good idea
[15:46] -queuebot:#ubuntu-release- New binary: oem-sutton.simon-cabernet-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[15:48] <juliank> I'll write an emaail
[15:48] <bdmurray> cabernet
[15:49] <laney> 🍷
[15:56] <juliank> An email has been sent to ubuntu-devel
[15:57] <schopin> bdmurray: could you have a look and merge https://code.launchpad.net/~schopin/britney/+git/hints-ubuntu/+merge/406727 ? Once this is done, the openssl SRUs should all be good to go.
[16:01] <bdmurray> schopin: It looks like there's a conflict or something in the diff
[16:03] -queuebot:#ubuntu-release- New: accepted oem-somerville-sanbernardino-meta [sync] (focal-proposed) [20.04~ubuntu1]
[16:05] -queuebot:#ubuntu-release- New binary: oem-somerville-sanbernardino-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[16:07] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-adkins-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:07] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-aenedleah-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:07] -queuebot:#ubuntu-release- New: accepted oem-sutton.simon-barbara-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:07] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-adrian-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:07] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-canyon-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:08] -queuebot:#ubuntu-release- New: accepted oem-somerville-sanbernardino-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:08] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carin-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:08] -queuebot:#ubuntu-release- New: accepted oem-sutton.simon-cabernet-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:08] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-adrion-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:08] -queuebot:#ubuntu-release- New: accepted oem-sutton.simon-aenescumb-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:13] <bdmurray> schopin: anyway, I'll sort it out
[16:15] <schopin> I guess my remote wasn't up-to-date.
[16:18] <bdmurray> schopin: also won't this be a problem for other releases sometime?
[16:21] <schopin> Hence my asking earlier about the policy when the bug is in the testbed :)
[16:23] <schopin> bdmurray: I don't know enough about how our autopkgtest infra is set up nor the R packages to be able to predict how the problem might evolve over time.
[16:24] <bdmurray> schopin: okay, maybe sending a note to ubuntu-devel is appropriate then so its not just you and I who know that there could be more autopkgtest failures in the future
[16:25] <bdmurray> well you, me and avid readers of #ubuntu-release
[16:25] <schopin> eh, not just the two of us, there's at least ginggs and tumbleweed :P
[16:26] <schopin> OK, I'll write an advisory to the ML :)
[16:26] <bdmurray> thanks!
[16:38] <ginggs> i'm a bit surprised that issue showed up in bionic, I thought it only appeared later
[16:39] <ginggs> but we do try to prevent it from happening since hirsute
[16:39] <ginggs> https://launchpad.net/ubuntu/+source/dh-r/20210218ubuntu1
[17:02] <vorlon> apw: the nvidia ABI? (not the kernel abi)
[19:58] -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (focal-proposed) [11ubuntu5.4]
[23:16] -queuebot:#ubuntu-release- Unapproved: accepted zhmcclient [source] (hirsute-proposed) [0.31.0-0ubuntu3~21.04.1]
[23:19] -queuebot:#ubuntu-release- Unapproved: accepted zhmcclient [source] (focal-proposed) [0.31.0-0ubuntu3~20.04.1]
=== Kamilion is now known as Kamilion|KV