15:31 #startmeeting Weekly Main Inclusion Requests status 15:31 Meeting started at 15:31:53 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology 15:31 Available commands: action, commands, idea, info, link, nick 15:31 Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) 15:32 #topic current component mismatches 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 trace-cmd is an ongoing effort 15:32 we have reviewed some of them, no new action 15:32 #topic New MIRs 15:32 Mission: ensure to assign all incoming reviews for fast processing 15:32 #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:32 hmm, two new ones here 15:33 first: https://bugs.launchpad.net/ubuntu/+source/tree/+bug/2056099 15:33 reading the rational before we try to assign ... 15:34 hmm - reading "this has been discussed with the Foundations team" 15:34 slyon isn't around 15:34 What I see makes me think could it not do that while staying in universe? 15:35 it won't be seeded, nor will it be advertised much outside of the mentioned SDK 15:35 Hello, I posted the MIR about tree . It is my first MIR so feel free to ask me questions here. 15:35 hi ahresse, welcome 15:35 try to answer the above I guess 15:35 it is mostly me trying to get if the motivation to do that is valid 15:35 o/ 15:36 hi joalif (and sarnold and eslerm_) 15:36 JFTR 15:36 ahresse: what I mean is that you've written "their user experience on their Ubuntu based SDK images" 15:36 which is fine, but why does it have to be in main for that 15:37 what is the value it provides to the rest of Ubuntu, since you said "enerally useful for a large part of our user base using the command-line" over it being what it is right now 15:37 I guess we (Canonical) concluded to support these packages officially in our partneship contract 15:37 And getting these into main is the way to validate this 15:38 If (IIFF) foundations is truly happy to own this, I'm ok then. This will go to some -supported seed and not be pulled in anywhere. 15:38 since slyon isn't around and do_ko extra busy with time_t64 I'd wait until next week for them to say something instead of assigning it right away 15:39 doesn't the contract validate support? 15:39 oh eslerm_ do not get me started "support" is an undefined term to begin with 15:39 it means 105 things to 52 different people 15:39 it could just be that getting updates for this from esm to sdk users might be A Real Challenge 15:39 ahresse: you could speed that up or avoid the same delay to happen again if you could ask Fundations management to comment on the bug agreeing that they will own it and that they consider this a good idea too 15:40 ahresse: this isn't negelcting your request, but we need to validate you are not secretly putting that onto their agenda :-) 15:40 and I'd not feel well for someon in the MIR team to review before I feel sure this will happen 15:40 does that work for you ahresse? 15:40 What I noted from my meeting from Fundation was: Lukasz: low risk, not so critical. Should go with a MIR. No strong objection from Foundation. 15:41 I totally believe you, but "No strong objection from Foundation" does not yet say "I'm ok that our team will take care for this for a decade" - although to admit this one seems low effort indeed 15:42 still I need to hold everything against sort of the same bar to pass 15:42 and we had others suggesting other owning teams ... guess how those ended up 15:42 @MIR folks - how do you think about adding a rule to the template that enforced an ack from the to be owning team? 15:42 I feel we almost have discussed that ... 15:43 ++1 15:43 that's probably a good idea, we've had other community folks try to get teams to support (sorry) packages that they weren't interested in 15:43 +1 15:44 ok, 1 sec 15:45 created https://github.com/canonical/ubuntu-mir/issues/52 15:45 TBH, this is my first MIR attempt so I will just follow what you propose... Let's just summerize it on the associated LP bug at the end. 15:46 ok, on tree we will recheck next week with foundations people around 15:46 again ahresse you can help with asking them to please comment and confirm on the bug 15:46 no problem ahresse, we are friendly and try to get your case resolved 15:46 excuse us for immediately starting with an extra whoop to jump through 15:46 ahresse: to be clear, this is a lovely mir :) 15:46 indeed sarnold 15:46 the rest LGTM in a glance 15:47 just in the 360 and FF week resources are scarce 15:47 hence I'm hoolding back and want to ensure ownership before spending any 15:47 next to look at is https://bugs.launchpad.net/ubuntu/+source/pemmican/+bug/2055434 15:47 and ahresse - thanks for being here for discussion 15:47 that helps to speed up things - so it is highly appreciated 15:48 in regard to the former discussion foundations team asking to own it themselve 15:48 also a pattern that we had before - special Pi bits for the Pi images that need to be in main for that reason 15:48 joalif: do you have any capacity to consider reviewing this (I'm drowned in 360 efforts)? 15:48 sorry :) 15:49 yup 15:49 hu, why excusing waveform 15:49 all good 15:49 thank you so much joalif 15:49 assigning 15:49 #topic Process/Documentation improvements 15:49 Mission: Review pending process/documentation pull-requests or issues 15:49 #link https://github.com/canonical/ubuntu-mir/pulls 15:49 #link https://github.com/canonical/ubuntu-mir/issues 15:49 my issue of 4 minutes ago 15:50 and eslerm with cargo vendor 15:50 reading ... 15:50 https://github.com/canonical/ubuntu-mir/issues/51 15:51 yeah, we need to have the toolchain folks comment 15:51 and until then probably leave a note in the MIR policies 15:51 WDYT? 15:51 toolchains commented in the linked jira task 15:51 opening 15:51 I understand there's around 80megs of windows crates in the authd packages 15:52 so what can we do for now, other than expecting anyone touching it to manually do the culling to those that matters? 15:52 should we ask for those to be deleted by hand before release? shipping that to all mirrors for ten more years makes me sad :( 15:52 we can not say "no rust until it solved" not can we "all that is listed needs to be fully reviewed" :-/ 15:53 sarnold: with "by hand" you mean d/rules removing them along the source build and build? 15:53 cpaelzer: exactly 15:54 posting on the case 15:54 but I'm unsure who to wait/block/gate/assign 15:54 so what will happen now, and by whom ... ? 15:56 updated to ask didrocks what he thinks 15:56 waiting for more discussion might be a good place to wait for next week 15:56 that was triggered by a desktop package right? 15:56 correct 15:56 authd - yeah 15:56 let us see what becomes of this 15:56 interesting for sure 15:56 rushing the last steps, 4 minutes to go 15:56 #topic MIR related Security Review Queue 15:56 Mission: Check on progress, do deadlines seem doable? 15:56 Some clients can only work with one, some with the other escaping - the URLs point to the same place. 15:56 #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:57 #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=[MIR]&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir 15:57 Internal link 15:57 - ensure your teams items are prioritized among each other as you'd expect 15:57 - ensure community requests do not get stomped by teams calling for favors too much 15:57 #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 15:57 security mirs are progressing :) 15:57 we need a volunteer for a perl package, we'll ifnd one 15:57 make them found eslerm_! :-) 15:57 bpf mirs are going smoothly 15:58 I guess there is not much more to say here 15:58 any other around bpf (like trace and such) showing any signs of trouble? 15:58 yes 15:58 oh 15:58 I mention it in the spec 15:59 the binaries from these packages are numerous (which is fine) and duplicate each others function 15:59 but, those working on the spec can figure this out 15:59 yeah I've seen that if you mean libbpf-tools and bpt-tools IIRC 15:59 but they are from the same source - so just one effort to maintain 15:59 we don't want ALL of these binaries to be installed by default most likely 15:59 and we'd not install all 15:59 yeah 15:59 ack on not installing all 16:00 TBH only the smaller ones built with less dependencies would be my suggestions (libbpf-tools) 16:00 and bpftrace, it dupes bpt-tools too 16:00 oh 16:00 unexpected 16:00 thanks for raising 16:00 rushing on then ... 16:00 in bpftrace's cases, I'd make the binaries examples since that is really what they are 16:00 examples of writing bpfc-tools with bpftrace 16:00 agreed, that is what I considered them 16:00 useful examples though 16:00 very 16:00 #topic Any other business? 16:00 not from me 16:01 none 16:01 none 16:01 none here 16:01 thanks 16:01 sorry for the rush 16:01 two more meetings now ... 16:01 o/ 16:01 o/ 16:01 thanks cpaelzer, all :) 16:01 thanks cpaelzer, all :) 16:01 #endmeeting