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 <ubottu> Launchpad bug 1977959 in usb-creator (Ubuntu) "[MIR] libisoburn, libburn, libisofs" [Undecided, New]
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 <ubottu> Launchpad bug 1980663 in plzip (Ubuntu) "[MIR] plzip & lzlib" [Undecided, New]
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 <ubottu> Pull 1 in canonical/ubuntu-mir "Add rust v3" [Open]
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