[13:07] cpaelzer: I will be away during the MIR meeting but available 30 minutes afterward. So, I will read the scrollback [13:14] ok, thanks didrocks [13:15] didrocks: did you have time to have a look at the new rust rules? [13:15] as I'll need to call for a vote on them [13:15] and if not yet, maybe you can look now and leave a vote on the PR? [13:33] cpaelzer: yeah, doing now [13:41] awesome [14:28] getting ready slowly but surely ... [14:30] good morning [14:30] o/ [14:30] #startmeeting Weekly Main Inclusion Requests status [14:30] Meeting started at 14:30:33 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology [14:30] Available commands: action, commands, idea, info, link, nick [14:30] Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage [14:30] hello everyone [14:30] o/ [14:30] FYI didrocks has a conflict but will read backlog later [14:31] so we will assign almost everything to him *evilgrin* [14:31] #topic current component mismatches [14:31] Mission: Identify required actions and spread the load among the teams [14:31] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:31] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:31] the lintian explosion is starting to be covered by stubs and approved MIRs [14:31] nothing new as far as I can tell [14:31] isoburn and co are ongoing and covered [14:32] I created lintian stubs. those approved (old) MIRs are probably useless and should be unassigned [14:32] yep, nothing new from my POV either [14:32] I had one questrion wrt false positives. [14:32] but maybe we can discuss this during AOB [14:32] shoot [14:32] ah ok [14:32] then AOB [14:32] #topic New MIRs [14:32] Mission: ensure to assign all incoming reviews for fast processing [14:32] #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 [14:33] plzip & lzlib are my false positives to be discussed later [14:33] ok [14:33] then https://bugs.launchpad.net/ubuntu/+source/libisofs/+bug/1977959 [14:33] Launchpad bug 1977959 in usb-creator (Ubuntu) "[MIR] libisoburn, libburn, libisofs" [Undecided, New] [14:33] this was reviewed by diddledani [14:33] sorry [14:33] didrocks: [14:33] libisoburn, libburn, libisofs is for didrocks to have a look at. I think everything is resolved and this should be a MIR team ACK [14:33] damn, I thought I was useful then! [14:33] yes slyon I also think this is a re-evaluation if all required todos are covered [14:34] ACK [14:34] do I hear that you will do that re-check slyon? [14:34] diddledani :) [14:34] and keeping plzip for AOB discussion ... [14:34] #topic Incomplete bugs / questions [14:34] Mission: Identify required actions and spread the load among the teams [14:34] #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 [14:34] it's all good IMO, but I wanted to leave it for didrocks as he did the initial review and I don't want to override his decision [14:34] should be quick, though [14:35] ok, then we consider it pre-checked and didrocks gets the task to check if he agrees [14:35] if yes, then assign seucrity or mark it as approved for the archive admins [14:35] going to incomplete cases then [14:35] two recent updates [14:36] ipmitool entered seucrity queue [14:36] I have an update there that we have automated tests which we think we can add [14:36] was only recommended, but still more tests = better [14:36] lintian is just a MIR stub & update-excuse bug for now [14:36] there is an ipmi simulator which can be used for some [14:36] and ack on lintian* [14:36] TL;DR nothing to act or assign here [14:36] #topic MIR related Security Review Queue [14:36] Mission: Check on progress, do deadlines seem doable? [14:37] #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 [14:37] sarnold: has anything left the queue in the last week? [14:37] cpaelzer: I believe only telegraf -- it's hard to call that a win, but it's one fewer in the queue.. [14:37] yeah [14:38] sarnold: in terms of non-progress - at what date do you want me to make the same noisy call to security management that got jammy reviews fixed last minute? [14:39] given that many have 7 weeks left (scheduled for feature freeze) [14:39] I think it is time that I ask this ... sorry [14:40] or do you expect you can get your new helping hands that you mentioned in the past to help you to get some of these cases done soon? [14:40] cpaelzer: probably about two weeks -- we're doing onboarding for two new team members last week and this week, the holiday weekend is in the past :(, so it should be a bit of a slow return to work.. [14:40] cpaelzer: it is reassuring to see the 'in progress' cards on jira :) [14:40] ok, let us then consider - if in two weeks we still see none cleared I'll take the sad job of ringing bells wherever I can [14:40] thanks :D [14:41] with the current load I can skip the internal queue [14:41] we get to ... [14:41] #topic Any other business? [14:41] wrt the lintian component-mismatch, plzip & lzlib seem to be false positives, as described here: https://bugs.launchpad.net/ubuntu/+source/lzlib/+bug/1980663 [14:41] Launchpad bug 1980663 in plzip (Ubuntu) "[MIR] plzip & lzlib" [Undecided, New] [14:41] slyon: let us talk about https://bugs.launchpad.net/ubuntu/+source/lzlib/+bug/1980663 [14:42] ack slyon, that is the most common type of false-positive that I know of [14:42] I was wondering if we should somehow track those false positives, e.g. by keeping that bug open (in NEW state) and adopt the title to something like "[MIR]... FALSE-POSITIVE" ? [14:42] so you can set that bug to "invalid" [14:42] oh I see [14:42] you mean to get them "non-white" [14:42] We could even consider using just ONE bug and add bug tasks [14:42] that way we would not need to remember the false-positives ourselves, but would have a reference from the generated SVG [14:42] yes that way my idea [14:43] the only problem would be "what if it ever is a real dependency" but we have that problem already as we ignore some [14:43] oh I really like this "use one bug over and over" idea [14:43] unless it gets way too many tasks launchpad is ok with that [14:43] slyon: how about this, you can set plzip to the state/content you'd like for this [14:43] next week we check component mismatches and how it looks [14:43] if it "feels right" then we add all the other known cases [14:44] would that work for all of us? [14:44] how many would we have? it feels like we have a dozen of these, and launchpad is unhappy at the kernel's four dozen-ish tasks.. [14:44] sarnold: I've found that until ~25 things are ok [14:44] dang that's lower than I thought [14:44] the problem with a single bug is that we cannot have the analyis per case in the description/content [14:44] if we make a new bug every tenpackages, though, that's still a big step up [14:44] hmm, that is true slyon [14:44] oh well [14:44] if we keep it as-is, it would describe why it's a false positive. and if it would pop up as a real dependency that could be checked [14:45] we could have the description just have an explanation of why we have false positives [14:45] and every PKG added can be a new comment outlining the reason [14:45] that might be a nice solution. [14:45] how about trying this for the zip cases then [14:45] let me set it up like this, and we can think about it for a bit [14:45] then make a call next week [14:46] exactly [14:46] slyon: if you are in the mood you can also immediately add the other known cases, up to you(r available time) [14:46] sure [14:46] which would be like xterm, esmtp IIRC [14:47] ok next topic [14:47] we have successfully moved to GH with our rules [14:47] I thought it is worth to document that here as well [14:47] it has a TOC still (top left button) and sub-anchor links work [14:47] https://github.com/canonical/ubuntu-mir#mir-team-weekly-status-meeting [14:48] nice work, thank you! [14:48] nice :D [14:48] and using that - as you have sen in your mail I have created a renewed PR for rust [14:48] https://github.com/canonical/ubuntu-mir/pull/1 [14:48] Pull 1 in canonical/ubuntu-mir "Add rust v3" [Open] [14:48] I'm obviously in +1 to my own proposal [14:48] slyon: reviewed and is ok as well [14:48] didrocks: reviewed just before and +1 (I'll add his small feedback in a bit) [14:49] I guess we definetly want sarnold/security to +1 and otherwise just need a majority [14:49] if I might ask joalif / sarnold / jamespage to review that? [14:49] looking [14:49] I liked the comment of slyon as that really was as I see it quoting: "I feel like this should be landed soon to have a base to build upon. It can still be improved/adopted later on, once we processed some initial Rust packages." [14:50] and server team has a case ready for review (including cargo.lock) once we approved the rules [14:51] so TL;DR for now - please review this, once we have more +1 I'd merge it and we will then throw the mdevctl MIR into the ring to try it out [14:51] did the package need to go to some effort to copy the cargo.lock into the built package? [14:52] sarnold: without the tooling in place we had to essentially create the .lock file ourselves [14:52] sarnold: we have documented that in README.source as our preliminary rules ask for [14:53] dh-cargo strips upstreams .lock files and avoids creating new ones, so until implemented there some kind of maintainer-created .lock is the only way to reasonably go [14:53] it is not that we write it line by line, there is a command which generates it just fine [14:54] +1 [14:55] thanks joalif - just throw that +1 as approval on the PR along any feedback if you have some [14:55] so the task to read in detail is left for sarnold [14:56] and for jamespage is you want (but so far openstack != rust) so you might rightfully not care much [14:56] and by that I'd call this meeting closed [14:56] any last important things to share? [14:56] thanks cpaelzer, all :) [14:56] nothing, thanks cpaelzer, all! [14:56] ok then - see you next week and happy reviewing [14:56] #endmeeting [14:56] Meeting ended at 14:56:45 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-07-05-14.30.moin.txt [14:56] thanks cpaelzer, all [15:07] slyon: cpaelzer: will recheck iso/burn* [15:09] thanks didrocks [15:09] thanks didrocks