[15:30] <cpaelzer> hiho
[15:30] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[15:30] <meetingology> Meeting started at 15:30:22 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:30] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:30] <cpaelzer> ping slyon, didrocks, sarnold, joalif, jamespage for MIR meeting
[15:30] <didrocks> hey
[15:30] <joalif> o/
[15:30] <jamespage> o/
[15:30] <cpaelzer> #topic Review of previous action items
[15:30] <cpaelzer> last week we landed a few wiki updates (done)
[15:30] <cpaelzer> adn we assigned a few MIR reviews
[15:31] <cpaelzer> I've just seen didrocks complete his a few hours ago
[15:31] <cpaelzer> and I did mine last wednesday
[15:31] <didrocks> *many* hours ago, hem hem :)
[15:31] <slyon> o/
[15:31] <cpaelzer> IIRC there was one more for joalif with guidance by jamespage if needed - did that complete as well?
[15:31] <joalif> I'm working on mine, i'm about to finish it
[15:31] <slyon> I completed mine as well (set to incomplete)
[15:31] <cpaelzer> and we had something I forgot assigned to slyon, maybe not a review - /me checks logs
[15:31] <cpaelzer> ah ok
[15:31] <cpaelzer> great then
[15:31] <cpaelzer> so notihng toally stuck and forgotten
[15:32] <cpaelzer> great
[15:32] <cpaelzer> let us look at this weeks news then
[15:32] <cpaelzer> #topic current component mismatches
[15:32] <sarnold> good morning
[15:32] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[15:32] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[15:32] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[15:32] <cpaelzer> non-proposed looks like all-known
[15:33] <cpaelzer> libreoffice-epiphany sounds familiar, but not of recently
[15:33] <cpaelzer> didrocks: thinse LO is desktop, do you remember?
[15:33] <cpaelzer> s/thinse/since/
[15:34] <didrocks> I don’t remember we had it on the list, I’ll look at it
[15:34] <cpaelzer> wanted to write "that" and changed my mind to 2since" => thinse :-)
[15:34] <cpaelzer> thanks for having a look
[15:34] <cpaelzer> the rest is mostly known
[15:34] <cpaelzer> mesa/postgresql-14 -> llvm-toolchain-13 really "just" waits for promotion of llvm-toolchain-13
[15:34] <slyon> ack
[15:34] <cpaelzer> mclemenceau:  has asked doko to have a look
[15:35] <cpaelzer> but nothing happened for quite a while, probably busy by many other things
[15:35] <cpaelzer> slyon: do you know if doko is available enough these days to rely on him, or should we make his life easier asking another AA to promote it?
[15:36] <slyon> he is only available a few days a week, so if it just needs promotion, we might need another AA to move it forward quicker
[15:36] <slyon> s/might need/might ask/
[15:36] <cpaelzer> foundations agrees to own it and IIRC they subscribed
[15:36] <cpaelzer> let me check
[15:37] <slyon> yes we agreed to own LLVM. but apparently the llvm-toolchain-13 package is not yet subscribed :-/
[15:37] <cpaelzer> foundations-bugs is not yet subscribed AFAICS
[15:37] <cpaelzer> so not "just promoting it"
[15:38] <slyon> let me check back with doko then during our next team meeting
[15:38] <cpaelzer> you already do the work and maintenance, we just need to correct the subscription and then promote it
[15:38] <cpaelzer> no need for a complex case, but it would unblock a lot of rather complex things in -proposed
[15:38] <cpaelzer> so I'd like to give this a  +1 in prio
[15:38] <cpaelzer> thanks slyon for carrying it to the team
[15:39] <cpaelzer> doesn't have to be doko to handle it AFAICT
[15:39] <cpaelzer> ok, enough of mismatches for today
[15:39] <cpaelzer> #topic New MIRs
[15:39] <sarnold> python-vitrage?
[15:39] <cpaelzer> sarnold: while new it has a bug assigned per the color
[15:39] <jamespage> I'll take that its openstack related
[15:39] <cpaelzer> thanks jamespage
[15:40] <cpaelzer> https://bugs.launchpad.net/cloud-archive/+bug/1893935
[15:40] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/twitter-bootstrap3/+bug/1667150
[15:40] <slyon> that was marked wontfix in 2019..
[15:40] <sarnold> comment #9 suggests the JS is just for docs
[15:40] <cpaelzer> the latter can be painful doing much more than needed in one package and having plenty of dependencies (from my look at it for mailman3 back in the day)
[15:40] <sarnold> I don't know how we mark those
[15:40] <jamespage> it will be
[15:40] <cpaelzer> so be careful when reviewing those jamespage
[15:41] <cpaelzer> maybe you can cut twitter-bootstrap3 and only need the python-vitrageclient
[15:41] <cpaelzer> should be much easier overall
[15:41] <jamespage> ack
[15:41] <cpaelzer> ok, trying again to go on with the agenda :-) Thanks for bringing it up though - was worth the discussion
[15:41] <cpaelzer> #topic New MIRs
[15:42] <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
[15:42] <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
[15:42] <cpaelzer> "only one bug" but a complex one and two tasks
[15:42] <cpaelzer> step #1 - I'd suggest we do assign two people (one per task) to split the load
[15:42] <cpaelzer> anyone feeling less than 1255 busy these days that could have a look?
[15:42] <cpaelzer> 125%
[15:43] <didrocks> I am 214% this week (approximately), but if this can wait another week, I’m happy reviewing something like cargo
[15:43] <didrocks> well, by some definition of "happy" :)
[15:44] <cpaelzer> there are quite some "TODO" left open in the bug description
[15:44] <cpaelzer> are we sure this is even meant to be ready for review?
[15:44] <joalif> same for me, however I am happy to review whatever (right now I cannot judge the complexity of a review )
[15:45] <slyon> I've been told its ready. I think the mwhudson opinion has been clarified in the comments and an autopkgtest has been proposed in Debian
[15:45] <cpaelzer> ok
[15:45] <cpaelzer> I do not really see the time either, but since I'm involved in drafting the rust rules I'll take rustc
[15:45] <didrocks> agreed that description should be updated first to address/remove TODOs
[15:45] <cpaelzer> but for cargo at least I'd want someone else to do it
[15:46] <sarnold> hmm, he mentions devendoring llvm.. I thought the rust folks had pretty significant changes in their llvm
[15:46] <cpaelzer> schopin: could you carry https://bugs.launchpad.net/ubuntu/+source/cargo/+bug/1957932/comments/1 into an update of the bug description please?
[15:48] <cpaelzer> I think for rustc I'm gonna do a first level reivew asking for detailed plans on llvm but also things like dh-cargo and others that came up while drafting the MIR rules for it
[15:48] <cpaelzer> looking for a cargo volunteer
[15:49] <cpaelzer> If no one says yes it will be didrocks with the acknowledgement to do it next week and a big credit for next "looking for volunteers" round :-)
[15:49] <sarnold> hehe
[15:49] <cpaelzer> ok that will be it
[15:49] <didrocks> (beers in Franfurt :p)
[15:49] <cpaelzer> we have to get through our content to not miss other bits ...
[15:49] <cpaelzer> #topic Incomplete bugs / questions
[15:49] <cpaelzer> Mission: discuss the recent activity to identify any follow up action
[15:49] <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
[15:50] <cpaelzer> I have pinged ahasenack on FRR, thanks didrocks for the review
[15:50] <didrocks> yw!
[15:50] <cpaelzer> Since it was a security-team request to please change quagga->frr I hope we can still get a fast-pass on an security ack
[15:51] <cpaelzer> the other things you asked on the bug seem fine and ahasenack is great at resolving those
[15:51] <cpaelzer> everything else is older
[15:51] <cpaelzer> v4l2-relayd
[15:51] <slyon> that one is back to the reporter
[15:52] <cpaelzer> oh I see, long list of todos
[15:52] <cpaelzer> thanks
[15:52] <slyon> I assembled a list of TODOs that needs improvement
[15:52] <cpaelzer> #topic MIR related Security Review Queue
[15:52] <cpaelzer> Mission: Check on progress, do deadlines seem doable?
[15:52] <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
[15:52] <cpaelzer> sarnold: any news that will raise our mood on this?
[15:53] <sarnold> only slightly, python-cheroot is still in progress, no progress on adsys
[15:53] <cpaelzer> I see foundations and Desktop have updated their deadlines/milestones
[15:53] <slyon> \o/
[15:53] <cpaelzer> 10 Packages (+FRR/libyang2 that we know of + potentially a bit more over the next few weeks)
[15:53] <sarnold> having these milestones, and the launchpad config to see them :), is pretty fantastic
[15:54] <slyon> yeah... the Rust/Cargo MIR is one of them..
[15:54] <slyon> (once assigned to security)
[15:54] <cpaelzer> if we look at feature freeze or even beta that means from now on we will need like 3-4 per week done to go on
[15:54] <cpaelzer> just to size the focus and priority correctly
[15:54] <cpaelzer> @sarnold
[15:55] <sarnold> well, I *was* feeling optimstic..
[15:55] <cpaelzer> or you shut down security for a week at the last possible time and all do just reviews - but then no time is left, so no findings allowed :-)
[15:56] <cpaelzer> Please be optimistic, but I just wanted to make clear what velocity you need to get it done - so you can scream for more people in the team meetings that you have
[15:56] <cpaelzer> and by that we get to
[15:56] <cpaelzer> #topic Any other business?
[15:56] <sarnold> nothing from me
[15:56] <cpaelzer> nothing from me
[15:56] <joalif> nothing
[15:56] <didrocks> nothing either
[15:56] <slyon> nothing here
[15:57] <cpaelzer> ok then, closing for today ... just in time
[15:57] <cpaelzer> thank you all
[15:57] <cpaelzer> #endmeeting
[15:57] <meetingology> Meeting ended at 15:57:07 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-02-01-15.30.moin.txt
[15:57] <sarnold> thanks cpaelzer, all :)
[15:57] <slyon> thank you all!
[15:57] <joalif> thanks all, bye
[15:57] <didrocks> thank you all :)
[15:57] <seb128> arg, I had a question but missed the meeting
[15:57] <seb128> already, next week
[15:57] <seb128> alright
[15:57] <cpaelzer> if it can wait seb128, then yes next week
[15:58] <cpaelzer> otherwise use the full ping list (see the meeting start) and ask it now
[15:58] <cpaelzer> won#t be in the log though
[15:58] <seb128> I will ask anyway in case it's easy reply
[15:58] <seb128> but I will ask officially next week otherwise
[15:58] <cpaelzer> ok
[15:58] <seb128> is it possible to MIR a trivial binary package from a complex source?
[15:58] <seb128> or would that be better split in a new source somehow?
[15:59] <seb128> asking because we would like to preinstall steam-devices which is a bunch of udev rules but built from the steam source
[15:59] <seb128> (ideally those rules wouldn't be needed and be included in systemd or something standard, I will investigate that possibility first)
[16:05] <cpaelzer> seb128: "better" split it, but sometimes the effort of the split - the related Debian Delta and all that is just too painful
[16:05] <cpaelzer> seb128: therefore if CAN be done to just promote one binary
[16:06] <cpaelzer> seb128: it depends a bit if the source between "to be promoted" and "to stay behind" is rather clear split in the archive or not
[16:06] <cpaelzer> imagine two small .c files to build binaries and a gigantinc shared C file -> bad case
[16:06] <cpaelzer> seb128: but two separate subdirectories and the to-be-promoted binary just coming from one -> good csae
[16:06] <seb128> in this case it's steam and on the side a small binary with udev rules
[16:07] <seb128> so that's the easy case probably
[16:07] <didrocks> I’m afraid that after some years, we go with what we hear often ("the source is in main, so promoting the binary doesn’t need a full MIR review")
[16:07] <seb128> the alternative would be to create a new source with the rules, but then we need a delta to remove the binary from steam and create a new package and keep it updated
[16:07] <didrocks> (even if the initial MIR ack was "only for this binary package)
[16:08] <cpaelzer> the problem is what didrocks outlined that later on someone can come by and say "from the same source, please promote"
[16:08] <seb128> right
[16:08] <cpaelzer> but for that we have these two lines in the template for reviewers
[16:08] <cpaelzer> to at least document it in the MIR clearly
[16:08] <cpaelzer> TODO: List of specific binary packages to be promoted to main: <TBD>
[16:08] <seb128> anyway it's post your meeting, I didn't meant to drag you into a late discussion
[16:08] <cpaelzer> TODO: Specific binary packages built, but NOT to be promoted to main: <TBD>
[16:08] <seb128> I will raise it again at the next meeting
[16:08] <seb128> thanks for the replies!
[16:08] <didrocks> yeah, we need to ensure AA look for the MIR bug before doing any AA work
[16:09] <didrocks> food for thoughts for next week :)
[16:09] <seb128> or we should explicitly blacklist the other binaries
[16:09] <cpaelzer> ^^ this
[16:09] <seb128> we have some list of things that should not be promoted irrc
[16:09] <seb128> with things like ffmpeg codecs on it
[16:09] <seb128> just to make sure they don't get pulled in by mistake
[16:10] <seb128> but then the list might get outdated with new binaries from the source created after the promotion...
[16:10] <cpaelzer> I think that only matters to avoid auto-inclusion, if there is an explicit seed or dependency added it would still get in IIRC
[16:10] <seb128> we maybe should create a promotion blacklist
[16:10] <seb128> or system to avoid promoting other binaries from a source
[16:12] <seb128> cpaelzer, oh, while I'm talking to you, did you see https://github.com/cpaelzer/ubuntu-mir/pull/5 and is that the right way to suggest such changes? or should I rather bring that up to the next meeting as well?
[16:13] <cpaelzer> seb128: that PR plus pinging in the meeting is the recommended way
[16:13] <cpaelzer> there are no notifications set up at all
[16:13] <cpaelzer> so we will miss it until there is a ping
[16:13] <seb128> k, I will ping next week :)
[16:20] <ahasenack> on the topic of promoting specific binaries, nginx comes to mind
[16:20] <ahasenack> when it was MIRed, there was one binary package that was explicitly stated to NOT be promoted to main
[16:20] <ahasenack> because its source was in debian/*, not part of upstream, and that was not reviewed in the MIR
[16:44] <schopin> cpaelzer: ACK on the rust MIR comment/description thing