| === not_phunyguy is now known as phunyguy | ||
| joalif | cpaelzer: I'm at sprint in Montreal, I won't be attending today's meeting | 14:05 |
|---|---|---|
| sarnold | good morning | 14:30 |
| slyon | hello o/ | 14:30 |
| cpaelzer | hi joalif - yes that is ok | 14:31 |
| cpaelzer | I'm also stuck in a roadmap prep :-/ | 14:31 |
| cpaelzer | slyon: sarnold: I wonder if you could kick and lead the meeting until I'm ready | 14:31 |
| cpaelzer | my only main thing today is to discuss the rust PR state and next steps | 14:31 |
| slyon | #startmeeting Weekly Main Inclusion Requests status | 14:32 |
| meetingology | Meeting started at 14:32:06 UTC. The chair is slyon. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 14:32 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 14:32 |
| sarnold | hah, slyon's faster today :) thanks | 14:32 |
| slyon | joalif (afk), sarnold, didrocks, cpaelzer, jamespage MIR meeting ping o/ | 14:32 |
| slyon | #topic current component mismatches | 14:32 |
| slyon | Mission: Identify required actions and spread the load among the teams | 14:32 |
| slyon | #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 14:32 |
| slyon | #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 14:32 |
| slyon | nothing new on -release | 14:33 |
| slyon | on -proposed we have libisofs->jigit, which had some discussion today in #ubuntu-release, but I'll bring that up during AOB | 14:34 |
| sarnold | -proposed has a mess of lintian, python->redis brings in python-deprecated,. python-async-timeout, python-typing-extensions | 14:34 |
| sarnold | liburi-perl -> libregexp-ipv6-perl | 14:34 |
| slyon | python-redis seems new. It's ubuntu-openstack, so probably for jamespage to have a look at | 14:34 |
| slyon | the lintian mess is all assigned with the Foundations team | 14:35 |
| slyon | liburi-perl seems Foundation'ish, so I'll investigate that | 14:35 |
| slyon | the others seem to be known | 14:35 |
| sarnold | and hooray for the tracking bug for the known false positives :) | 14:36 |
| slyon | I'd also like to talk about false-positives (https://bugs.launchpad.net/ubuntu/+source/plzip/+bug/1980663) e.g. plzip, lzlib, xterm ... but we can do this during AOB, too, when cpaelzer is available as well. | 14:36 |
| ubottu | Launchpad bug 1980663 in xterm (Ubuntu) "[MIR] false-positives, do not promote" [Undecided, Fix Released] | 14:36 |
| jamespage | o/ | 14:36 |
| jamespage | apologies for being a little late | 14:36 |
| slyon | hey jamespage! could you have a look at the new python-redis depends/mismatches on https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg? | 14:37 |
| jamespage | looking now | 14:37 |
| slyon | thanks. Moving on | 14:37 |
| slyon | #topic New MIRs | 14:37 |
| slyon | Mission: ensure to assign all incoming reviews for fast processing | 14:37 |
| slyon | #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:37 |
| slyon | we only have https://bugs.launchpad.net/ubuntu/+source/protobuf-c/+bug/1956617 | 14:37 |
| ubottu | Launchpad bug 1956617 in protobuf-c (Ubuntu) "[MIR] protobuf-c" [Undecided, New] | 14:37 |
| sarnold | I think that's just a simple matter of the statuses being set incorrectly | 14:38 |
| slyon | We got the security team ACK. but we need to sync from debian | 14:38 |
| slyon | sarnold: is it? there was some recent activity | 14:38 |
| sarnold | slyon: yeah, eslerm acked it, but only unassigned us when done, not change the status to In Progress | 14:39 |
| sarnold | I changed it to In Progress just now so we'll probably see it again in a few minutes :) | 14:40 |
| slyon | sarnold: right. I think this is actually done (MIR ACK & security ACK), but we'd want to sync/merge from debian before promoting it, right? | 14:40 |
| slyon | thanks | 14:40 |
| slyon | #topic Incomplete bugs / questions | 14:40 |
| slyon | Mission: Identify required actions and spread the load among the teams | 14:40 |
| slyon | #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:40 |
| sarnold | there was a good debate about the security fix and whether or not it actually made sense, etc, so pulling in from debian *soon* would give us a lot more confidence for the release | 14:40 |
| slyon | I guess I can do the protobuf-c merge and set to "Fix Committed" afterwards.. | 14:42 |
| slyon | as I've been involved in resolving the original MIR requirements | 14:42 |
| sarnold | excellent, thanks | 14:42 |
| slyon | so for incomplete MIRs, we have: https://bugs.launchpad.net/ubuntu/+source/libregexp-wildcards-perl/+bug/1980968 | 14:42 |
| ubottu | Launchpad bug 1980968 in libregexp-wildcards-perl (Ubuntu) "[MIR] libregexp-wildcards-perl" [Undecided, Incomplete] | 14:42 |
| slyon | oh that's a dummy. Foundations tracking it wrt lintian mismatch | 14:43 |
| slyon | same with https://bugs.launchpad.net/ubuntu/+source/libhtml-tokeparser-simple-perl/+bug/1980662 (assigend to Graham) | 14:43 |
| ubottu | Launchpad bug 1980662 in libwww-mechanize-perl (Ubuntu) "[MIR] lib*-perl for lintian 2.115" [Undecided, Incomplete] | 14:43 |
| sarnold | "Moved libregexp-wildcards-perl into a separate MIR since it's maintained by a different group" aha! | 14:43 |
| sarnold | and that question answered :) | 14:43 |
| slyon | that leaves us with https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 | 14:44 |
| ubottu | Launchpad bug 1942394 in mdevctl (Ubuntu) "[MIR] mdevctl 1.0.0 (rust switch)" [Undecided, Incomplete] | 14:44 |
| sarnold | I can't quickly spot what changed in the description recently.. | 14:44 |
| sarnold | aha, TODOs are changed, eg " The package runs a test suite on build time, if it fails it makes the build fail" | 14:44 |
| slyon | I think this is related to the rust ruleset changes and for cpaelzer to comment on | 14:45 |
| slyon | IIRC mdevctl was the first rust package | 14:45 |
| sarnold | yeah | 14:45 |
| slyon | it seems to be actively worked on (last change 5 min ago), so I'd just let it sit there for now and move to AOB, to discuss the rust changes | 14:46 |
| slyon | ah wait. security update first :) | 14:46 |
| sarnold | it's probably the same discussion anyway :) | 14:46 |
| slyon | #topic MIR related Security Review Queue | 14:46 |
| slyon | Mission: Check on progress, do deadlines seem doable? | 14:46 |
| slyon | #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:46 |
| slyon | #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 | 14:46 |
| sarnold | ah right! protobuf-c is finished yesterday \o/ | 14:47 |
| slyon | sarnold: do you have any news for us? We saw some progress on protobuf-c :) | 14:47 |
| slyon | sarnold: have you been able to onboard a few more security reviewers? | 14:48 |
| sarnold | other MIRs are in progress, which is good; even with the help of the newer folks, we are getting worried about burning down the entire list of MIRs to finish, so we'd like to encourage / recommend teams to please set priorities in jira, it really does help us when we're assigning tasks | 14:48 |
| slyon | do the priorities in jira somehow relate to the milestones we set in launchpad? | 14:49 |
| sarnold | slyon: let's say sporadic progress, promising, but a reminder that we can't expect the same throughput from newer folks than our friends who'd found greener pastures, etc.. | 14:49 |
| sarnold | through a manual process :( | 14:49 |
| slyon | understandably. | 14:49 |
| sarnold | and when there's risk of not getting all the tasks done in a milestone, it's nice to know which ones the requesting teams would like us to pick first | 14:49 |
| slyon | so is this something the security team is doing (setting priorities) or are teams expected to set priorities in LP and jira? | 14:50 |
| sarnold | those are inputs from other teams | 14:50 |
| sarnold | (fwiw I don't think LP priorities are considered at all) | 14:50 |
| slyon | okay. Maybe let's repeat that next week. as this week's MIR meeting seems a bit short staffed :) | 14:50 |
| sarnold | will do | 14:51 |
| slyon | thanks! | 14:51 |
| slyon | #topic Any other business? | 14:51 |
| * sarnold pokes cpaelzer | 14:51 | |
| slyon | maybe let's start with https://bugs.launchpad.net/ubuntu/+source/plzip/+bug/1980663 | 14:51 |
| ubottu | Launchpad bug 1980663 in xterm (Ubuntu) "[MIR] false-positives, do not promote" [Undecided, Fix Released] | 14:51 |
| sarnold | that's lovely | 14:51 |
| sarnold | good job with the explanations | 14:52 |
| slyon | I created this bug to track some false-positive component-mismatches. what do you thinkg about having such a ticket? (And do you feel the "Fix Released" status is appropriate? | 14:52 |
| slyon | the idea is to add a bug task + description in the comments for every false-positive package | 14:52 |
| sarnold | it is a bit weird that it shows up bright yellow in the svgs, but the legend seems to suggest that's a very low-stress place for them to be, so it kind of feels like it fits | 14:52 |
| slyon | this way they would show up as yellow on the component-mismatch list and are clickable to read the explanation | 14:52 |
| cpaelzer | fully back - reading backlog | 14:53 |
| slyon | sarnold: ACK. I felt the "yellow" fix-released status to be the least actionable, that's why i chose it | 14:54 |
| cpaelzer | ok | 14:54 |
| cpaelzer | thanks slyon for the false-positive handling | 14:54 |
| cpaelzer | the good thing on approved/yellow state is that it is more obvious that those are different | 14:54 |
| cpaelzer | so I like it | 14:54 |
| slyon | I couldn't come up with a proper analysis for esmtp (and others) so if somebody knows their story, feel free to add a bug task abou tit | 14:54 |
| cpaelzer | esmtp was also an alternative | 14:55 |
| cpaelzer | wow this is older that the move to libera | 14:56 |
| slyon | cpaelzer: could you add that in a comment? | 14:56 |
| cpaelzer | need the other log for esmtp | 14:56 |
| slyon | ok | 14:56 |
| slyon | On a different note, there was some discussion today on #ubuntu-release about https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1978066 | 14:56 |
| ubottu | Launchpad bug 1978066 in usb-creator (Ubuntu) "[MIR] jigit" [Undecided, Confirmed] | 14:56 |
| cpaelzer | slyon: that is the reason for esmtp https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/1895011 | 14:57 |
| ubottu | Launchpad bug 1895011 in germinate (Ubuntu) "virtual-packages do not pick a seeded package (ordering dependent)" [Undecided, New] | 14:57 |
| slyon | looks like libisofs https://bugs.launchpad.net/ubuntu/+source/libisoburn/+bug/1977959 was set to "Fix Committed" (and promoted) too early, which caused Desktop ISOs build failures | 14:57 |
| ubottu | Launchpad bug 1977959 in usb-creator (Ubuntu) "[MIR] libisoburn, libburn, libisofs" [Undecided, Fix Released] | 14:57 |
| cpaelzer | hmm that is an issue slyon | 14:58 |
| cpaelzer | how did that happen? | 14:58 |
| slyon | src:libisofs has a required TODO: "- In addition of this MIR for the 3 packages, ensure that jigit MIR is also acked (https://bugs.launchpad.net/ubuntu/+source/jigit/+bug/1978066)." which is not yet resolved. So I guess its status should be set to "In Progress" right? | 14:58 |
| ubottu | Launchpad bug 1978066 in usb-creator (Ubuntu) "[MIR] jigit" [Undecided, Confirmed] | 14:58 |
| cpaelzer | yesa indeed | 14:58 |
| slyon | we rolled back the change for now (moved usb-creator to -proposed) and set a "block-proposed" tag on LP to avoid this issue for now | 14:59 |
| cpaelzer | it is a miss by didrocks (who isn't here to defend) when re-checking the case | 14:59 |
| cpaelzer | rolling it back was right IMHO | 14:59 |
| slyon | OK I'll update the status | 14:59 |
| cpaelzer | we might want/need to update th ebug | 14:59 |
| cpaelzer | ok thanks | 14:59 |
| cpaelzer | using the last few seconds .. (time flies) | 14:59 |
| cpaelzer | about the rust rules | 14:59 |
| cpaelzer | https://github.com/canonical/ubuntu-mir/pull/1 | 15:00 |
| ubottu | Pull 1 in canonical/ubuntu-mir "Add rust v3" [Open] | 15:00 |
| cpaelzer | the question comes down to | 15:00 |
| cpaelzer | a) land rules now - modify later OR hold changes back until all is ready | 15:00 |
| cpaelzer | and | 15:00 |
| cpaelzer | b) do we allow packages in main before things like cargo.lock or else are ready OR not | 15:00 |
| cpaelzer | a and b can be decided independently | 15:01 |
| cpaelzer | and the time here runs out | 15:01 |
| cpaelzer | there is also a discussion about if the new static-built-using is helpful and would replace go.mod/sum and cargo.lock or not | 15:01 |
| cpaelzer | since time runs out all I can ask is to participate on the PR discussion | 15:01 |
| cpaelzer | sorry | 15:01 |
| sarnold | iirc static-built-using reports only source retrieved from other binary packages; and the cargo.lock reports also vendored-in sources | 15:02 |
| cpaelzer | and next week is planning sprint - so most likely hard to attend for even more of us | 15:02 |
| sarnold | should we skip it? or is it that much more important? | 15:02 |
| cpaelzer | thanks sarnold - I also expected it to cover only packages | 15:03 |
| slyon | I'm all for merging the rust rules, soon. As landing smaller changes/adoptions in the future (wrt cargo.lock/static-built-using) should be much easier | 15:03 |
| cpaelzer | so it really comes down to ask foundations if they would be willing to pick up generating a cargo.lock in dh-cargo | 15:03 |
| sarnold | hmm; related to the jigit/iso-creator .. should we have a step "add block-proposed to a bug if there are outstanding TODO"? | 15:03 |
| cpaelzer | I'll ask mclemenceau about that | 15:03 |
| cpaelzer | but for landing the current text I'm also preferring to land it soon | 15:03 |
| slyon | thanks cpaelzer. It would probably be for Simon, who's on vacation currently | 15:04 |
| cpaelzer | sarnold: what if I change the rules for rust to require the cargo.lock (that we can't have yet) | 15:04 |
| cpaelzer | sarnold: can we then merge them | 15:04 |
| cpaelzer | sarnold: and later revise? | 15:04 |
| sarnold | cpaelzer: that would make me feel vastly better, yes | 15:04 |
| cpaelzer | ok, I#ll ping you once updated | 15:04 |
| sarnold | cpaelzer: so long as point (b) remains .. | 15:04 |
| sarnold | thank you thank you :) | 15:04 |
| cpaelzer | thank you all | 15:05 |
| cpaelzer | I'm on a run again :-/ | 15:05 |
| cpaelzer | thanks for leading slyon | 15:05 |
| sarnold | thanks slyon, cpaelzer, jamespage :) | 15:05 |
| slyon | sounds good! let's merge the rules with requiring cargo.lock and discuss the cargo.lock + static-built-using situation further as the next step | 15:05 |
| slyon | thanks all! | 15:05 |
| slyon | #endmeeting | 15:05 |
| meetingology | Meeting ended at 15:05:53 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-07-12-14.32.moin.txt | 15:05 |
| slyon | (sorry for running over time) | 15:06 |
| sarnold | no worries here :) | 15:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
