| didrocks | cpaelzer: I will be away during the MIR meeting but available 30 minutes afterward. So, I will read the scrollback | 13:07 |
|---|---|---|
| cpaelzer | ok, thanks didrocks | 13:14 |
| 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:15 |
| didrocks | cpaelzer: yeah, doing now | 13:33 |
| cpaelzer | awesome | 13:41 |
| cpaelzer | getting ready slowly but surely ... | 14:28 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| cpaelzer | and server team has a case ready for review (including cargo.lock) once we approved the rules | 14:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| joalif | +1 | 14:54 |
| 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:55 |
| 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 | 14:56 |
| didrocks | slyon: cpaelzer: will recheck iso/burn* | 15:07 |
| slyon | thanks didrocks | 15:09 |
| cpaelzer | thanks didrocks | 15:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
