[15:30] o/ [15:30] slowly here ... [15:31] o/ [15:32] finally, now ... [15:33] #startmeeting Weekly Main Inclusion Requests status [15:33] Meeting started at 15:33:04 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology [15:33] o/ [15:33] Available commands: action, commands, idea, info, link, nick [15:33] Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) [15:33] sorry for the 3 min delay [15:33] o/ [15:33] #topic current component mismatches [15:33] Mission: Identify required actions and spread the load among the teams [15:33] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [15:33] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [15:33] looks much less expliding than last time [15:34] jpeg-xl, jemalloc, mysql all wait to be acted on [15:34] good morning [15:34] kernels are usually dealt with by kernel [15:34] the set of openstack related is still a set of stubs [15:34] nothing new here to act, unless some of those cases show up in new/incomplete lists later [15:34] #topic New MIRs [15:34] Mission: ensure to assign all incoming reviews for fast processing [15:35] #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir [15:35] here we go [15:35] mysql-8.4 is likely just same content new versioned source [15:35] I'd handled that as i can also immediately act on promoting it if it is as clear as I expect [15:36] https://bugs.launchpad.net/ubuntu/+source/jemalloc/+bug/2088056 needs a reviewer [15:36] -ubottu:#ubuntu-meeting- Launchpad bug 2088056 in jemalloc (Ubuntu) "[MIR] jemalloc" [Undecided, New] [15:36] is this an ideal moment to ask if we should move to mariadb or stop preferring one over the other? [15:36] sarnold: that discussion has happened on ubuntu-devel [15:36] mysql isn't exactly what one would call an ideal upstream [15:36] ah good good [15:36] I might not get to that discussion until next year, at this rate :/ [15:37] now we know your inbox read speed :-) [15:37] i can take jemalloc [15:37] anyone available for jemalloc [15:37] a [15:37] thanks joalif [15:37] and then the third here https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/2089690 [15:37] -ubottu:#ubuntu-meeting- Launchpad bug 2089690 in rust-sequoia-sq (Ubuntu) "[MIR] rust-sequoia-sq" [Undecided, Incomplete] [15:37] the explosion of component mismatches reduced, so was that now vendored? [15:38] this isn't really ready for MIR review yet AFAICS [15:38] back to incomplete - WDYT? [15:38] I'm not sure, probably got dropped from gnupg2 [15:38] yep [15:39] yeah.. gnupg2 should be assigned to foundations and the others marked as Incomplete [15:39] that is why component mismatches looked sane [15:39] slyon: would that go to foundations-bugs? [15:40] yes, I assigned it, just to make it vanish from the MIR queue [15:40] ok, aborting my update and reloading [15:40] ack [15:40] LGTM [15:40] thanks [15:40] ok, that is this stage for now [15:40] #topic Incomplete bugs / questions [15:40] Mission: Identify required actions and spread the load among the teams [15:40] #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir [15:41] I'm happy to see Zixing work on this, bue it would be back to new if it needs a review or anything else [15:41] that is for https://bugs.launchpad.net/ubuntu/+source/dbus-broker/+bug/2015538 [15:41] -ubottu:#ubuntu-meeting- Launchpad bug 2015538 in dbus-broker (Ubuntu) "[MIR] dbus-broker" [Undecided, Incomplete] [15:42] I'll ask around who drives this over the finishing line and wehn [15:42] but getting the C implementation was one of the former needs IIRC [15:42] thx [15:42] then we have https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/2054480 [15:43] -ubottu:#ubuntu-meeting- Launchpad bug 2054480 in nbd (Ubuntu) "[MIR] nbd-client" [Undecided, Incomplete] [15:43] got some tests [15:43] once there also is isolation or a reasonable evidence it was tried and is impossible we can evaluate if all we need was provided [15:44] there's some code in the tests that unloads an apparmor profile on two architectures [15:44] feels funny [15:44] I dropped a comment [15:44] seeing it in line 183 [15:44] thanks [15:44] ok then [15:44] going on [15:44] #topic Process/Documentation improvements [15:44] Mission: Review pending process/documentation pull-requests or issues [15:44] #link https://github.com/canonical/ubuntu-mir/pulls [15:44] #link https://github.com/canonical/ubuntu-mir/issues [15:45] busy [15:45] no new issues [15:45] but two PRs to look at [15:45] https://github.com/canonical/ubuntu-mir/pull/71 [15:45] -ubottu:#ubuntu-meeting- Pull 71 in canonical/ubuntu-mir "Rust: Make the tarball more reproducible" [Open] [15:45] that improves the example [15:46] if we could get a +1 by one of the rust'y people in foundations maybe? [15:46] then this looks like a great help (even though the command got awfully long) [15:46] looks solid [15:46] it's not about Rust, but about tar [15:46] I ping Zixing [15:46] thanks dviererbe [15:46] to be clear this is likely 99.999 fine, but having a rusty ack before merge to be sure [15:47] ok [15:47] slyon: isn't it only about the tar as used to repack the vendored dependencies? [15:47] slyon: so it is "rusty tar" :-) [15:47] well, yes [15:47] I mean the options all read well, avoid owner, avoid order, avoid ... [15:48] probably merged next week then [15:48] and thanks juliank for that one! [15:48] next https://github.com/canonical/ubuntu-mir/pull/72 [15:48] -ubottu:#ubuntu-meeting- Pull 72 in canonical/ubuntu-mir "vendor/Rust: more comprehensive dependency removal" [Open] [15:48] yw [15:49] it's marked as a draft, so I think it is not ready yet [15:49] yeah dviererbe [15:49] this is the more rusty part. The "currently unreleased" looks suspicious [15:49] and I also have slight concerns [15:49] I like changing long commandlines to a tool, but being unreleased or only in the very latest limits the use [15:50] I'd suggest to him to write it as "use A, or if available to you B" [15:51] #topic MIR related Security Review Queue [15:51] Mission: Check on progress, do deadlines seem doable? [15:51] Some clients can only work with one, some with the other escaping - the URLs point to the same place. [15:51] #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir [15:51] #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=[MIR]&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir [15:51] Internal link [15:51] - ensure your teams items are prioritized among each other as you'd expect [15:51] - ensure community requests do not get stomped by teams calling for favors too much [15:51] #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 [15:51] wb sarnold [15:51] thanks :) [15:51] jpeg-xl is the one I know holding up things [15:51] the downside of course is that I have no recollection of the state and wasn't able to find time yesterday, and I'm unlikely to find time today, either :( [15:51] could that be assigned or did that had reasons it wasn't yet [15:52] likely just my bandwidth, thanks for identifying a good potential one to assign [15:52] yeah, go for that one if you have limited time [15:52] thank you thank you :) [15:52] the rest can follow as you are fully recovering the backlog [15:52] i've only got a few more working days the rest of the year [15:52] the queue is not as bad as it has been, no huge rush atm [15:52] #topic Any other business? [15:53] topic: sarnold has too few working days, let me change that ... :-P [15:53] lol [15:53] every few years I have my usual conversation "hey what if instead of a year-end carry-over cap we have a monthly PTO cap?" [15:54] and every few years I'm told it's a good idea for the entire company to shutdown for most of december [15:54] so :) [15:54] hehe [15:54] collect PTO for early retirement that never happens sarnold :-) [15:54] nothing from my side [15:54] anyway, I assume no true topics we need to discuss then ... ? [15:55] cpaelzer: oh yeah, those stories of old timers collecting a few years of PTO in their jobs without caps... and then not showing up for their final two years of work :) [15:55] nothing really here beyond a general note that you should take your holidays and not let your own PTO days expire [15:55] signing that [15:55] * sarnold <-- trying to set a good example [15:55] ok, getting ready for the next call then and closing out [15:55] 9 [15:55] 3 [15:55] 1 [15:55] 6 [15:56] done [15:56] thanks cpaelzer, all :) [15:56] #endmeeting [15:56] Meeting ended at 15:56:03 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-12-03-15.33.moin.txt [15:56] lol yay another fun sequence :) [15:56] thanks cpaelzer, all! [15:56] thanks, everyone :) [15:56] one day this will be the best source for entropy [15:56] \o/ [19:59] o/ [20:00] o/ [20:04] vorlon: coming? I don't see seb128 or sil2100 here. [20:04] steve sent a message on MM saying he can't make it a bit earlier so it may be just the two of us [20:05] We don't have any action items. [20:05] I'm just quickly checking the other standing items [20:06] Nothing on the ML, no new bug activity. [20:06] The next meetings would be on the 17th and the 31st. What's your schedule like for those? [20:06] I wonder if/what we should skip. [20:07] How about I write to the ML and ask so others can get to it offline? [20:07] 17th is fine for me but 31st may be tricky [20:07] Apart from that, I see nothing else for discussion. Shall we skip the meeting today? [20:07] yeah sounds fair - thanks rbasak === tsimonq2_ is now known as tsimonq2