=== not_phunyguy is now known as phunyguy
[14:05] <joalif> cpaelzer: I'm at sprint in Montreal, I won't be attending today's meeting
[14:30] <sarnold> good morning
[14:30] <slyon> hello o/
[14:31] <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:32] <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:33] <slyon> nothing new on -release
[14:34] <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:35] <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:36] <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:37] <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:38] <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:39] <sarnold> slyon: yeah, eslerm acked it, but only unassigned us when done, not change the status to In Progress
[14:40] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <cpaelzer> fully back - reading backlog
[14:54] <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:55] <cpaelzer> esmtp was also an alternative
[14:56] <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:57] <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:58] <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:59] <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
[15:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <slyon> (sorry for running over time)
[15:06] <sarnold> no worries here :)