[14:55] méôw [14:59] wuff [14:59] o/ [14:59] o/ [14:59] o/ [15:00] o/ [15:00] o/ [15:00] #startmeeting Weekly Ubuntu Foundations team [15:00] Meeting started at 15:00:33 UTC. The chair is jawn-smith. Information about MeetBot at https://wiki.ubuntu.com/meetingology [15:00] Available commands: action, commands, idea, info, link, nick [15:00] #topic Lightning Round [15:00] The status is here: https://discourse.ubuntu.com/t/foundations-team-updates-thursday-07-july-2022/29330/2 [15:02] o/ [15:04] bdrung: With apport's autopkgtests they aren't running / skipped for armhf on previous releases. Are the any chances of it being SRU'ed. [15:05] ? [15:05] bdmurray, the current uploaded apport SRU fixes several autopkgtest (but not all for armhf). I can include all needed autopkgtest fixes in the next SRUs to let autopkgtest succeed on all archs. [15:06] IIRC except for one or two cases, all needed changes were only for the tests itself. [15:06] If it is just test fixes then using block-proposed-$release sounds appropriate. I was asking because if they are fixed then they shouldn't be denylisted any more. [15:08] bdmurray, i will take care of removing it from the denylist [15:08] https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs/tree/never_run here is the never_run list [15:09] #topic Release incoming bugs [15:09] rls-kk is empty today [15:09] #link https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-incoming-bug-tasks.html#foundations-bugs [15:09] bug 1979874 [15:09] Bug 1979874 in netplan.io (Ubuntu) "Unable to set bridge to lower MTU that interface its attached to" [Medium, Triaged] https://launchpad.net/bugs/1979874 [15:09] I tried to quickly reproduce this one. Results were inconsistent... [15:10] Not sure if it needs to be carded [15:10] It's worth investigating. Does that investigation require a card mclemenceau ? [15:11] maybe we can leave it in LP for a little bit and revisit a little later in the cycle or if there's more impacted user? [15:12] Sounds good, let's remove the rls-jj tag [15:12] bug 1980589 [15:12] Bug 1980589 in update-notifier (Ubuntu) "Reports that there are updates but there are none" [Undecided, New] https://launchpad.net/bugs/1980589 [15:13] Is this really update-notifier? [15:13] I think it does some motd stuff [15:13] Okay, who tends to work on update-notifier [15:13] ? [15:13] sometimes [15:14] Does anyone have an opinion on the importance of this bug? [15:15] let's card it that's very confusing [15:16] Medium or Low I'd say [15:16] especially it says there are security updates so it's scary and confusing if that happens [15:16] Okay we've agreed to card it [15:16] mclemenceau: would you do the honors? [15:16] sure thing [15:16] Thanks! [15:17] rls-ii and rls-ff are actually empty [15:17] \o/ [15:17] #topic Team proposed-migration report [15:17] #link https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs [15:17] vorlon: [15:18] let's see! [15:18] ubuntu-meta: still in Desktop's court [15:18] python3-stdlib-extensions: doko, is this still yours? [15:19] yes [15:19] ok [15:20] usb-creator: as noted in the weekly status, the MIR is moving forward [15:20] mutt: gsasl MIR [15:20] waiting on security team [15:21] systemd: was skipped last time, should that just be retried? (but it's blocking a kernel package and they have their own test matrix that's invisible to us) [15:21] should be re-tried. systemd 251 already migrated in the meantime [15:21] last week we said llvm-toolchain-14 was ftbfs for the same reason as gcc; gcc has been fixed but llvm-toolchain-14 not? [15:21] so does someone want to follow through on llvm? [15:22] ah it's built now on every arch but riscv64 and that one is building [15:22] so probably nothing to do here [15:22] hmm, that was for arm64. I didn't check risc64 yet. it's currently building [15:22] it's only waiting on a riscv64 build, that keeps failing without logs [15:24] lintian: I saw there was a mention of this in the weekly status; MIR is open, is anyone filling those out? [15:24] vorlon: no we need somebody to fill those [15:24] I did some initial investigation and marked some false-positves [15:25] ginggs: thanks for volunteering on lintian [15:26] with ogayot helping (slyon can help point out which part of the MIR could be split off) [15:26] ack [15:26] curl ftbfs on several archs. dbungert can you take this? [15:26] vorlon: ack [15:26] it also ftbfs in Debian fwiw [15:26] good datapoint [15:27] oh I had curl last week [15:27] oh [15:27] Didn't get to it with the long weekend and +1 maintenance [15:27] sorry I thought we were into the stuff that was too new to have been assigned [15:27] ok curl: jawn-smith [15:28] pygments: there's an update-excuse bug that points at pytest which needs a merge; dbungert can you take this instead? [15:28] vorlon: ack for pygments [15:28] gcc-11: also just waiting for a build on riscv64 [15:29] libxcrypt vs perl: doko does your latest merge fix this? [15:29] I hope so [15:30] bdrung: can you follow through to make sure it actually does? [15:30] okay [15:30] (and also db5.3) [15:30] and, apparently, also dpkg :P [15:30] a whole lot of perl autopkgtest failures! [15:31] casper vs localechooser: I uploaded this, I'll take it [15:31] and that's the bottom of the list [15:31] jawn-smith: [15:31] #topic AOB [15:32] the pygments update-excuse, LP: #1980296, raises the concern that a merge of pytest-7 would potentially affect 2000 packages, I assume we proceed? treat it as a transition? [15:32] Launchpad bug 1980296 in pytest (Ubuntu) "pygments FTBFS requires pytest >> 7.0" [Medium, New] https://launchpad.net/bugs/1980296 [15:33] pytest migration is progressing nicely in debian [15:33] https://tracker.debian.org/pkg/pytest [15:33] only 9 failures left, and they are being worked on [15:35] you could start now by checking whether we need a merge or a sync [15:35] OK [15:36] #endmeeting [15:36] Meeting ended at 15:36:54 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-07-07-15.00.moin.txt [15:37] Thanks! [15:38] o/ === NotEickmeyer is now known as Eickmeyer