14:32 #startmeeting Weekly Main Inclusion Requests status 14:32 Meeting started at 14:32:06 UTC. The chair is slyon. Information about MeetBot at https://wiki.ubuntu.com/meetingology 14:32 Available commands: action, commands, idea, info, link, nick 14:32 hah, slyon's faster today :) thanks 14:32 joalif (afk), sarnold, didrocks, cpaelzer, jamespage MIR meeting ping o/ 14:32 #topic current component mismatches 14:32 Mission: Identify required actions and spread the load among the teams 14:32 #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg 14:32 #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 14:33 nothing new on -release 14:34 on -proposed we have libisofs->jigit, which had some discussion today in #ubuntu-release, but I'll bring that up during AOB 14:34 -proposed has a mess of lintian, python->redis brings in python-deprecated,. python-async-timeout, python-typing-extensions 14:34 liburi-perl -> libregexp-ipv6-perl 14:34 python-redis seems new. It's ubuntu-openstack, so probably for jamespage to have a look at 14:35 the lintian mess is all assigned with the Foundations team 14:35 liburi-perl seems Foundation'ish, so I'll investigate that 14:35 the others seem to be known 14:36 and hooray for the tracking bug for the known false positives :) 14:36 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 Launchpad bug 1980663 in xterm (Ubuntu) "[MIR] false-positives, do not promote" [Undecided, Fix Released] 14:36 o/ 14:36 apologies for being a little late 14:37 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 looking now 14:37 thanks. Moving on 14:37 #topic New MIRs 14:37 Mission: ensure to assign all incoming reviews for fast processing 14:37 #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 we only have https://bugs.launchpad.net/ubuntu/+source/protobuf-c/+bug/1956617 14:37 Launchpad bug 1956617 in protobuf-c (Ubuntu) "[MIR] protobuf-c" [Undecided, New] 14:38 I think that's just a simple matter of the statuses being set incorrectly 14:38 We got the security team ACK. but we need to sync from debian 14:38 sarnold: is it? there was some recent activity 14:39 slyon: yeah, eslerm acked it, but only unassigned us when done, not change the status to In Progress 14:40 I changed it to In Progress just now so we'll probably see it again in a few minutes :) 14:40 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 thanks 14:40 #topic Incomplete bugs / questions 14:40 Mission: Identify required actions and spread the load among the teams 14:40 #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 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:42 I guess I can do the protobuf-c merge and set to "Fix Committed" afterwards.. 14:42 as I've been involved in resolving the original MIR requirements 14:42 excellent, thanks 14:42 so for incomplete MIRs, we have: https://bugs.launchpad.net/ubuntu/+source/libregexp-wildcards-perl/+bug/1980968 14:42 Launchpad bug 1980968 in libregexp-wildcards-perl (Ubuntu) "[MIR] libregexp-wildcards-perl" [Undecided, Incomplete] 14:43 oh that's a dummy. Foundations tracking it wrt lintian mismatch 14:43 same with https://bugs.launchpad.net/ubuntu/+source/libhtml-tokeparser-simple-perl/+bug/1980662 (assigend to Graham) 14:43 Launchpad bug 1980662 in libwww-mechanize-perl (Ubuntu) "[MIR] lib*-perl for lintian 2.115" [Undecided, Incomplete] 14:43 "Moved libregexp-wildcards-perl into a separate MIR since it's maintained by a different group" aha! 14:43 and that question answered :) 14:44 that leaves us with https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 14:44 Launchpad bug 1942394 in mdevctl (Ubuntu) "[MIR] mdevctl 1.0.0 (rust switch)" [Undecided, Incomplete] 14:44 I can't quickly spot what changed in the description recently.. 14:44 aha, TODOs are changed, eg " The package runs a test suite on build time, if it fails it makes the build fail" 14:45 I think this is related to the rust ruleset changes and for cpaelzer to comment on 14:45 IIRC mdevctl was the first rust package 14:45 yeah 14:46 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 ah wait. security update first :) 14:46 it's probably the same discussion anyway :) 14:46 #topic MIR related Security Review Queue 14:46 Mission: Check on progress, do deadlines seem doable? 14:46 #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 #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 14:47 ah right! protobuf-c is finished yesterday \o/ 14:47 sarnold: do you have any news for us? We saw some progress on protobuf-c :) 14:48 sarnold: have you been able to onboard a few more security reviewers? 14:48 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:49 do the priorities in jira somehow relate to the milestones we set in launchpad? 14:49 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 through a manual process :( 14:49 understandably. 14:49 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:50 so is this something the security team is doing (setting priorities) or are teams expected to set priorities in LP and jira? 14:50 those are inputs from other teams 14:50 (fwiw I don't think LP priorities are considered at all) 14:50 okay. Maybe let's repeat that next week. as this week's MIR meeting seems a bit short staffed :) 14:51 will do 14:51 thanks! 14:51 #topic Any other business? 14:51 * sarnold pokes cpaelzer 14:51 maybe let's start with https://bugs.launchpad.net/ubuntu/+source/plzip/+bug/1980663 14:51 Launchpad bug 1980663 in xterm (Ubuntu) "[MIR] false-positives, do not promote" [Undecided, Fix Released] 14:51 that's lovely 14:52 good job with the explanations 14:52 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 the idea is to add a bug task + description in the comments for every false-positive package 14:52 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 this way they would show up as yellow on the component-mismatch list and are clickable to read the explanation 14:53 fully back - reading backlog 14:54 sarnold: ACK. I felt the "yellow" fix-released status to be the least actionable, that's why i chose it 14:54 ok 14:54 thanks slyon for the false-positive handling 14:54 the good thing on approved/yellow state is that it is more obvious that those are different 14:54 so I like it 14:54 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:55 esmtp was also an alternative 14:56 wow this is older that the move to libera 14:56 cpaelzer: could you add that in a comment? 14:56 need the other log for esmtp 14:56 ok 14:56 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 Launchpad bug 1978066 in usb-creator (Ubuntu) "[MIR] jigit" [Undecided, Confirmed] 14:57 slyon: that is the reason for esmtp https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/1895011 14:57 Launchpad bug 1895011 in germinate (Ubuntu) "virtual-packages do not pick a seeded package (ordering dependent)" [Undecided, New] 14:57 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 Launchpad bug 1977959 in usb-creator (Ubuntu) "[MIR] libisoburn, libburn, libisofs" [Undecided, Fix Released] 14:58 hmm that is an issue slyon 14:58 how did that happen? 14:58 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 Launchpad bug 1978066 in usb-creator (Ubuntu) "[MIR] jigit" [Undecided, Confirmed] 14:58 yesa indeed 14:59 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 it is a miss by didrocks (who isn't here to defend) when re-checking the case 14:59 rolling it back was right IMHO 14:59 OK I'll update the status 14:59 we might want/need to update th ebug 14:59 ok thanks 14:59 using the last few seconds .. (time flies) 14:59 about the rust rules 15:00 https://github.com/canonical/ubuntu-mir/pull/1 15:00 Pull 1 in canonical/ubuntu-mir "Add rust v3" [Open] 15:00 the question comes down to 15:00 a) land rules now - modify later OR hold changes back until all is ready 15:00 and 15:00 b) do we allow packages in main before things like cargo.lock or else are ready OR not 15:01 a and b can be decided independently 15:01 and the time here runs out 15:01 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 since time runs out all I can ask is to participate on the PR discussion 15:01 sorry 15:02 iirc static-built-using reports only source retrieved from other binary packages; and the cargo.lock reports also vendored-in sources 15:02 and next week is planning sprint - so most likely hard to attend for even more of us 15:02 should we skip it? or is it that much more important? 15:03 thanks sarnold - I also expected it to cover only packages 15:03 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 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 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 I'll ask mclemenceau about that 15:03 but for landing the current text I'm also preferring to land it soon 15:04 thanks cpaelzer. It would probably be for Simon, who's on vacation currently 15:04 sarnold: what if I change the rules for rust to require the cargo.lock (that we can't have yet) 15:04 sarnold: can we then merge them 15:04 sarnold: and later revise? 15:04 cpaelzer: that would make me feel vastly better, yes 15:04 ok, I#ll ping you once updated 15:04 cpaelzer: so long as point (b) remains .. 15:04 thank you thank you :) 15:05 thank you all 15:05 I'm on a run again :-/ 15:05 thanks for leading slyon 15:05 thanks slyon, cpaelzer, jamespage :) 15:05 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 thanks all! 15:05 #endmeeting