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