15:31 <slyon> #startmeeting Weekly Main Inclusion Requests status 15:31 <meetingology> Meeting started at 15:31:20 UTC. The chair is slyon. Information about MeetBot at https://wiki.ubuntu.com/meetingology 15:31 <meetingology> Available commands: action, commands, idea, info, link, nick 15:31 <slyon> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) 15:31 <slyon> #topic current component mismatches 15:31 <slyon> Mission: Identify required actions and spread the load among the teams 15:31 <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg 15:31 <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 15:31 <slyon> non-proposed looking clean 15:32 <slyon> -proposed is known AFAICT, except for openjdk-21 15:32 <slyon> For openjdk-21 we need to demote the -doc binary. cpaelzer could you do that (later)? 15:32 <slyon> That's how it had been handled in the past 15:33 <slyon> #topic New MIRs 15:33 <slyon> Mission: ensure to assign all incoming reviews for fast processing 15:33 <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 15:33 <slyon> bug #2054480 15:33 <didrocks> (I’m around today, but in meetings) 15:34 <slyon> Any volunteers to review ^ ? 15:34 <didrocks> I’m happy to take any MIRs, I can’t sign off they will be done next week though, I’ll aim for the next next one 15:34 <didrocks> of* 15:34 <joalif> i can take the simple-perl 15:35 <slyon> simple-perl is done already AFAIC. 15:35 <didrocks> it doesn’t seem there is due date for ndb, so I can it 15:35 <didrocks> take* 15:35 <slyon> thanks, assigning to didrocks 15:35 <jamespage> that ndb one is odd - its a binary only promotion for a package already in main 15:35 <jamespage> so that might be super-easy! 15:36 <jamespage> nbd rather... 15:36 <jamespage> I also typo that 15:36 <slyon> indeed. it's well written too, so let's see what remarks are given 15:36 <slyon> moving on... bug #2054480 15:36 <slyon> opps. 15:36 <slyon> bug #2029379 15:37 <joalif> that also has a review 15:38 <slyon> it seems ready, except for the team subscription. Can you confirm this joalif ? 15:38 <slyon> So I'd move it to "In Progress" 15:38 <joalif> yup that's correct 15:39 <slyon> bug #2031491 15:39 <cpaelzer> I can fix the subscription right now 15:40 <slyon> same here, we have the condicinal ACK and the duplication concern was addressed 15:40 <slyon> already subscribed, too 15:40 <slyon> let's move it forward 15:41 <slyon> bug #2055165 15:41 <jbicha> hi 15:42 <jbicha> we're wondering if we can avoid the whole MIR process for gcr4 15:42 <slyon> jbicha: hey! Are there major code changes between gcr and gcr4? Or should it be considered a "versioned package upgrade", that does not need MIR, but just AA approval? 15:43 <cpaelzer> FYI: subscription on libdbd-sqlite3-perl added 15:43 <sarnold> I don't understand quite what that first paragraph is saying; if gcr doesn't include gui widgets, why do we need a separate version for gtk4? 15:45 <jbicha> gtk4 apps couldn't use libgcr-ui-3-1 anyway because of its gtk3 dependency. gcr devs also chose to make some other api changes at the same time 15:45 <slyon> jbicha: is gcr4 a continuation of the gcr codebase? 15:45 <jbicha> slyon: yes! 15:46 <jbicha> it's still https://gitlab.gnome.org/GNOME/gcr 15:46 <cpaelzer> usually versioned transitions can have some overlap, but eventually resolve. Is this expected to only have gcr4 at some point, if so when? 15:46 <slyon> I'd assume that depends on GTK3 usage in main..? 15:47 <jbicha> I can't give you an exact time since seahorse & shotwell are undermaintained & porting to gtk4 is a lot for big apps 15:47 <cpaelzer> I see, so it really is once all GTK3 in main are gone some day 15:47 <jbicha> the old gcr will be in universe for a long time 15:47 <jbicha> yes 15:47 <seb128> hey there, sorry I wanted to join but I've another call at the same time and forgot to /j on IRC 15:48 <cpaelzer> I'm personally fine with that TBH 15:48 <seb128> jbicha, thanks for covering for desktop :) 15:48 <slyon> Considering it's a versioned transition and we have precedence for parallel GTK3 & GTK4 I'm +1 on promoting this. But I'd like to defer to cpaelzer and/or didrocks for a final decision, with their AA hats on 15:48 <cpaelzer> I'm +1 as well, with a twist (not too bad one, let me write ...) 15:49 <didrocks> I don’t think that’s much different from gtk3 -> gtk4. It would have been a good time for reviewing the package and how we can improve it, but I don’t think this is doable in a realistic timeframe 15:49 <cpaelzer> I haven't had a look, but is it reasonable to ask for improved testing and quality 15:49 <cpaelzer> otherwise we have to wait for GTK5 :-) 15:49 <cpaelzer> OTOH I totally see hwo time runs out for that 15:50 <cpaelzer> given that it is the same as before but newer I'm +1 even without, but couldn't resist asking for some QA and testing eyes 15:50 <slyon> Let's make improved/non-superficial autopkgtest a recommendation, then? 15:50 <cpaelzer> slyon: yeah, that 15:50 <seb128> +1, we can card that on our backlog, not going to happen for feature freeze though :) 15:51 <cpaelzer> that is ok as a compromise - if it is before final freeze (vs the backlog being 234235346345 items long) 15:51 <slyon> I updated the case on LP. status: Fix Committed 15:51 <cpaelzer> thanks 15:52 <slyon> #topic Incomplete bugs / questions 15:52 <slyon> Mission: Identify required actions and spread the load among the teams 15:52 <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 15:52 <slyon> bug #2023971 15:53 <slyon> seems to be a tracking update (cc joalif) 15:53 <slyon> bug #2051850 15:54 <slyon> here we're waiting on implementation of required TODOs by foundations 15:54 <slyon> bug #2051916 15:54 <eslerm> (I'm planning to do the trace-cmd audit early) 15:54 <slyon> I've been working with upils actively to move this forward. There are still some issues with testing on s390x. To be resolved soon 15:54 <slyon> thanks eslerm 15:55 <slyon> bug #2051925 15:55 <slyon> similar to the previous bug. We have a patch that needs review and sponsoring. not actionable for MIR team 15:56 <slyon> bug #2048781 15:56 <cpaelzer> on this very topic of the production-tools related MIRs 15:56 <cpaelzer> I have ruled out two cases with a pre-review, they will never hit the MIR queue 15:56 <slyon> yes, there's overall quite some frustration about the perf tools MIRs, as the packages are not in very good shape 15:57 <cpaelzer> they are in much better shape than those I eliminated upfront 15:57 <slyon> ok 15:57 <cpaelzer> TL;DR: I've drawn a line for some to be ok to match what common documentation mentioned, but need to stay in universe 15:57 <cpaelzer> so meta package cahnges to get them easy : yes - full main approval - no 15:57 <cpaelzer> sorry to distract, keep goin 15:57 <cpaelzer> g 15:58 <slyon> joalif: should bug #2048781 be status: New to make it into the security-review list? 15:58 <joalif> slyon: sorry in 2 meetings checking 15:58 <slyon> I see no required TODOs there 15:59 <slyon> moving on in parallel, feel free to give your comment later on 15:59 <slyon> #topic Process/Documentation improvements 15:59 <slyon> Mission: Review pending process/documentation pull-requests or issues 15:59 <joalif> slyon I think it's already in securitiy-review list 15:59 <slyon> #link https://github.com/canonical/ubuntu-mir/pulls 15:59 <slyon> #link https://github.com/canonical/ubuntu-mir/issues 15:59 <slyon> joalif: OK, setting to "Confirmed" then 15:59 <slyon> Simple typo fix https://github.com/canonical/ubuntu-mir/pull/50 16:00 <cpaelzer> feel free to merge 16:00 <eslerm> one issue to raise within the base-sets issue also 16:00 <slyon> Will double-check and merege after the meeting. 16:00 <eslerm> within the authd MIR, there are comments about windows crates being vendored 16:00 <slyon> eslerm: your comment from December? 16:00 <eslerm> this is related to https://github.com/canonical/ubuntu-mir/issues/35#issuecomment-1859325671 16:01 <eslerm> yes 16:01 <eslerm> please see comment #11 from authd as well 16:01 <eslerm> I'm not sure where to take this issue beyond here 16:02 <slyon> I guess there are some hints in https://wiki.ubuntu.com/RustCodeInMain how to mangle the unneeded crates manually.. 16:03 <sarnold> that's for mangling, does it also work for deleting? 16:04 <eslerm> in the best case, that is manual work for each package 16:04 <eslerm> I'm not sure how well rerunning `crate vendor` works 16:04 <slyon> Yes, I think it's manual work. The package should have some script to drop unneeded stuff and mangle the manifest accordingly 16:05 <eslerm> and it would be ongoing manual work 16:05 <slyon> I think longer term we'd need upstream toolchain support to vendor only the necessary deps 16:06 <slyon> but that's not something that we have right now. 16:06 <eslerm> I have links to upstream comments 16:06 <didrocks> yeah, I think that should be done centrally, at worst, in the packaging tooling then 16:06 <eslerm> in the MIR and issue thread 16:06 <didrocks> otherwise, everyone will have different ways of doing it, hard to update and so on 16:06 <eslerm> this is out of scope for cargo upstream, a thirdparty lint is likely needed 16:07 <slyon> I can put it into the Foundations/Toolchain squad's backlog for review during next roadmap planning 16:07 <sarnold> thanks 16:07 <eslerm> thank you ! 16:07 <slyon> #topic MIR related Security Review Queue 16:08 <slyon> Mission: Check on progress, do deadlines seem doable? 16:08 <slyon> Some clients can only work with one, some with the other escaping - the URLs point to the same place. 16:08 <didrocks> sounds perfect! 16:08 <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 16:08 <slyon> #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 16:08 <slyon> Internal link 16:08 <slyon> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 16:08 <slyon> sarnold: eslerm: what are the security-review updates? 16:08 <sarnold> progress is progressing :) 16:09 <eslerm> we're fairly caught up. we're expecting MIRs for tracing and perl to land in our queue soon 16:09 <slyon> sounds good. Let's move on as we're already overtime. All pending/ready MIRs seem to be in the queue 16:10 <slyon> #topic Any other business? 16:10 <eslerm> dbus-broker is very close 16:10 <slyon> Is there still a change to do the dbus-broker switch in noble (cc seb128)? 16:10 <slyon> chance* 16:11 <slyon> I mean, it would be great the have the MIR and security review ready anyway 16:11 <slyon> so we can to the change whenever needed 16:11 <slyon> Do we have anything else? 16:12 <eslerm> not from me 16:12 <slyon> sorry for running late! o/ 16:12 <slyon> #endmeeting