== Meeting information == * #ubuntu-meeting: Weekly Main Inclusion Requests status meeting, started by cpaelzer, 05 Jul at 14:30 — 14:56 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-07-05-14.30.log.html == Meeting summary == === current component mismatches === Discussion started by cpaelzer at 14:31. * ''LINK:'' https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg (cpaelzer, 14:31) * ''LINK:'' https://people.canonical.com/~ubuntu-archive/component-mismatches.svg (cpaelzer, 14:31) === New MIRs === Discussion started by cpaelzer at 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 (cpaelzer, 14:32) === Incomplete bugs / questions === Discussion started by cpaelzer at 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 (cpaelzer, 14:34) === MIR related Security Review Queue === Discussion started by cpaelzer at 14:36. * ''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 (cpaelzer, 14:37) === Any other business? === Discussion started by cpaelzer at 14:41. * ''LINK:'' https://github.com/canonical/ubuntu-mir#mir-team-weekly-status-meeting (cpaelzer, 14:47) * ''LINK:'' https://github.com/canonical/ubuntu-mir/pull/1 (cpaelzer, 14:48) == People present (lines said) == * cpaelzer (99) * slyon (22) * sarnold (12) * joalif (3) * ubottu (3) * meetingology (2) * diddledani (1) == Full log == 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 Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)