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