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