[15:00] o/ [15:00] o/ [15:00] o/ [15:00] o/ [15:00] \o [15:01] o/ [15:01] o/ [15:02] o/ [15:03] * vorlon waves [15:03] o/ [15:03] #startmeeting Weekly Ubuntu Foundations team [15:03] Meeting started at 15:03:39 UTC. The chair is jawn-smith. Information about MeetBot at https://wiki.ubuntu.com/meetingology [15:03] Available commands: action, commands, idea, info, link, nick [15:03] #topic Lightning Round [15:03] The status is here: https://discourse.ubuntu.com/t/foundation-team-updates-thursday-02-june-2022/28714/8 [15:04] Let's all take some time to read through it and ask questions [15:04] And to congratulate schopin on becoming core dev! [15:04] wrt. alexghiti's libgpg-error multi-arch fix, we'd need somebody to deploy this: https://code.launchpad.net/~ubuntu-release/autopkgtest/+git/development/+merge/423176 [15:04] maybe vorlon or juliank could help with that? [15:05] I thought it autodeploys [15:05] hasn't been deployed as of a few hours ago [15:05] It doesn't autodeploy [15:05] The manual says to run some juju thingy [15:06] but that might be broken and one has to run git pull [15:06] I'd like to do that after the meeting [15:06] directly [15:06] ok [15:06] thanks bdmurray [15:07] Okay, any other questions? [15:08] #topic Release incoming bugs [15:08] #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-kk-incoming-bug-tasks.html#foundations-bugs [15:08] bug 1880029 [15:08] Bug 1880029 in netplan.io (Ubuntu) "Netplan optional-addresses produces Unknown key name 'OptionalAddresses'" [Medium, Triaged] https://launchpad.net/bugs/1880029 [15:09] slyon: you tagged this [15:09] we had some discussions wrt netplan's "optional-addresses" and it turned out that it is not working proper ever since [15:09] (or at least since ~2018) [15:09] so we should look into that [15:10] is this something that would be worthy of an SRU? [15:10] eventually yes, but could be through a full version backport of netplan [15:10] Okay. mclemenceau would you mind carding this? [15:10] of course! on it [15:11] thanks! [15:11] bug 1976607 [15:11] Bug 1976607 in systemd (Ubuntu Kinetic) "tests-in-lxd autopkgtest is skipped, due to missing 'lxd' deb" [Medium, Triaged] https://launchpad.net/bugs/1976607 [15:11] that's mine as well [15:11] this one eve has a patch, so a card seems justified [15:11] s/eve/even [15:11] yeah, patch doesn't fully work unfortunately [15:11] ah okay. Either way if work is being done on it we should go ahead and create a card [15:12] but we need to fix it. systemd's autopkgtests were reduced post Jammy feature freeze due to the 'lxd' deb being removed [15:12] so many tests are skipped, which is bad [15:12] That does indeed sound bad [15:12] ok carding this then [15:12] Thanks! [15:12] bug 1976299 [15:12] Bug 1976299 in python3.10 (Ubuntu Kinetic) "hashlib.algorithms_available lists algorithms that cannot be used" [Undecided, Confirmed] https://launchpad.net/bugs/1976299 [15:13] I see both schopin and bdmurray commenting on this [15:14] Is this something you're working on schopin? [15:14] not actively, no, I just tagged it so that it'd show up on my list. [15:15] Okay, well sounds important so let's card it [15:15] ok [15:15] ack [15:15] #link https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-incoming-bug-tasks.html#foundations-bugs [15:16] The first two were already covered under kk [15:16] bug 1976258 [15:16] Bug 1976258 in icu (Ubuntu) "icu ftbfs in the jammy release pocket" [Undecided, New] https://launchpad.net/bugs/1976258 [15:16] tagged by doko [15:16] The dbus one was not discussed under kk [15:17] eh? Okay I'll go back to it [15:17] I've seen this failing test before from icu [15:17] At least I'm pretty sure [15:17] It had something to do with our tzdata being different than Debian's [15:18] so mclemenceau can you card this and assign to me? [15:18] icu does occassionally get security updates so that seems worth sorting but might be a low priority [15:18] ok [15:18] thanks! [15:18] jawn-smith: if you think it's a flaky, and needs a retry, i can do that [15:18] ginggs: if it's the problem I've seen before it's not flakey [15:19] but rather different names for certain locales that makes the test fail [15:19] moving on to bug 1968845 [15:19] Bug 1968845 in dbus (Ubuntu) "Upgrade to 22.04 from 20.04 ends with dbus installation asking for a reboot" [High, Incomplete] https://launchpad.net/bugs/1968845 [15:19] we actually discussed this during the last meeting, hence my purple link [15:19] This was discussed elsewhere and there is a plan [15:20] Does that plan involve a card? [15:20] It probably should [15:20] Cool, let's card it and move on [15:20] rls-ii is empty [15:20] \o/ [15:21] Ack [15:21] #link https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html#foundations-bugs [15:21] bug 1888347 [15:21] Bug 1888347 in lvm2 (Ubuntu) "blk-availability unmounts filesystems before applications have finished using them" [High, Confirmed] https://launchpad.net/bugs/1888347 [15:21] we discussed this one last week [15:22] I tagged it because there was reference to data loss but the linked bugs are quite different from what the description says [15:22] It appears there was an action for bdmurray to investigate if this was fixed in focal+ [15:23] bdmurray: have you looked into that? [15:23] there's also a private bug 1921145 which apparently has an upstream fix and backport provided, so should probably be verified and included in the next systemd Focal SRU [15:25] Let's ask for a test case from the reporter about the lvm2 bug [15:25] Sounds good to me [15:25] That's it for bugs then [15:25] #topic Team proposed-migration report [15:26] #link http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs [15:26] vorlon: take it away [15:26] only 13 packages to discuss [15:26] I'll try to be quick [15:26] libevent, I know is in progress [15:27] correct, we have identified a solution [15:27] waveform doesn't seem to be around today, but I guess this is still ok to carry over? [15:27] doko: are you keeping dash? [15:27] Yeah, I may end up fixing it while ubuntu-image tests are running or something like that [15:28] schopin: are you still driving the MIRs for licensecheck? [15:28] licensecheck and sphinx are in progress: LP: #1972853 [15:28] Launchpad bug 1972853 in libxs-parse-sublike-perl (Ubuntu) "[MIR] lib*-perl" [Undecided, Incomplete] https://launchpad.net/bugs/1972853 [15:28] excellent [15:28] dnspython is still mine, I have a plan for the first problem but there is a whole secondary problem that needs investigation. [15:28] agreed, still working on it. [15:28] so is libgpg-error, LP: #1975673 [15:28] Launchpad bug 1975673 in libgpg-error (Ubuntu) "libgpg-error/1.45-2 fails autopkgtest on i386" [Undecided, New] https://launchpad.net/bugs/1975673 [15:28] schopin: are you also still working on the MIR for sphinx? [15:29] Yes, we bundled all the perl MIRs in one bug. [15:29] incidentally that specific one is the one causing the delay. [15:29] MIRs for mutt are in progress as mentioned in jawn-smith's weekly report [15:30] brltty is waiting on new espeak-ng, which rings a bell for me; I'll have a look at it [15:30] paramiko vs libcloud, enr0n seems to be on top of this [15:31] Yeah, I tracked down the root cause this morning, and I am working on a patch. [15:31] dbungert already mentioned dnspython [15:31] that takes us to the new stuff (7 days old) [15:31] python-future has some autopkgtest regressions [15:31] who can take this? [15:31] i'll take that [15:31] python-future to ginggs [15:31] thanks [15:32] python-httplib2: bdrung: ? [15:32] yes, i can take that [15:32] dpkg: juliank: do you want this? [15:33] ack [15:33] pillow: ogayot: can you take this? [15:33] pillow is blocked by skimage which has a new indirect dependency [15:33] debian bug #1010595 [15:33] Debian bug 1010595 in src:xsimd "Please make xsimd available on all platforms" [Normal, Open] https://bugs.debian.org/1010595 [15:33] are you saying not to give it to ogayot? :) [15:34] Seems like we need to wait on Debian. I can take it then. [15:37] I believe that's everything for this week [15:37] #topic AOB [15:38] i did have a quick question about bdrung's onetbb thing [15:38] just wondering if it may be better to add things to big_packages instead of long_tests [15:38] (provided they can run their tests in parallel) [15:38] i had some success doing that with mercurial [15:39] what is the practical difference between big_packages and long_tests? [15:39] big_packages is larger VMs; long_tests extends the timeout [15:39] https://wiki.ubuntu.com/ProposedMigration#autopkgtests [15:40] so it needs to be checked if the cmake test suite can be executed in parallel [15:41] in terms of the trade-offs, big_packages is better than long_tests if it solves the failure *and* the autopkgtest infra is under low load [15:42] however, I don't think our handling of quota for big VMs is very good [15:42] so large numbers of packages requiring big_packages ==> increased VM allocation failure rate [15:42] seeing "Threads = 1" and "parallel_for" in the autoptkgtest output, so we can test running autopkgtest with different VMs to see how much it gets faster [15:43] and in principle, when we get around to implementing baseline retesting, "low load" will become an infrequent state [15:43] is it documented somewhere how big those autopkgtest VMs are? [15:44] you can probably infer from debian's results [15:44] https://ci.debian.net/packages/o/onetbb/unstable/arm64/ [15:44] If you want to test in an environment similar to the autopkgtest environment [15:44] 38-52 minutes [15:44] openstack and juju have the different sizes: m1.small and m1.large [15:44] most packages run on an m1.small, but big_packages run on an m1.large [15:45] also in the wiki bdmurray posted ^ [15:45] There's also an m1.tiny, but I recommend avoiding that [15:45] Debian CI on amd64 uses 4 threads and takes 36m. [15:45] locally I use qemu --ram-size=4096 --cpus=4 [15:46] i.e. for testing amd64 [15:46] so the result is: ginggs is right, big_packages is better than long_tests. [15:46] i'll put it on my agenda to change that (with some numbers on the runtime in the MR) [15:46] jawn-smith: pretty sure we are using a custom VM type that's not an m1.small though I would have to look to see what the difference is [15:46] ah okay, thanks for the correction [15:47] also I'm not sure that 'small' and 'large' have a global definition that's guaranteed to be constant over time [15:47] `tests run on something similar to an m1.small unit` [15:47] right, "similar to", uhh [15:48] One more topic. I heard back from cpaelzer about how to tag the MIR bug so it shows up in excuses but doesn't throw off the MIR team. He suggests adding the "update-excuse" tag, tagging the parent package (mutt) and leaving it assigned to someone so it doesn't show up in the MIR team searches [15:48] err, not "tagging" the parent package but rather marking it as "affects" [15:49] that's kind of lame [15:50] Okay, anything else? [15:51] #endmeeting [15:51] Meeting ended at 15:51:19 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-06-02-15.03.moin.txt