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