14:31 <slyon> #startmeeting Weekly Main Inclusion Requests status
14:31 <meetingology> Meeting started at 14:31:16 UTC.  The chair is slyon.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
14:31 <meetingology> Available commands: action, commands, idea, info, link, nick
14:31 <slyon> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )
14:31 <slyon> #topic current component mismatches
14:31 <slyon> Mission: Identify required actions and spread the load among the teams
14:31 <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
14:31 <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
14:31 <dviererbe> o/
14:32 <sarnold> good morning
14:32 <slyon> hplip -> python-reportlab is new (due to the non snappy CUPS stack).
14:32 <slyon> I left some comments in bug #2028054 (cc seb128)
14:33 <seb128> slyon, I will review
14:33 <slyon> wrt. libmail-dmarc-perl: I'd like to recommend the server team to consider cutting the tree a bit (if possible), by dropping Recommends to Suggests, e.g. for libmoose-perl or libdbix-simple-perl Recommends. That should avoid ~20 MIRs
14:34 <slyon> nvme-stas -> dasbus, both are now ready for promotion
14:34 <sarnold> I think they've been doing that along the way, heh
14:34 <slyon> ok, that's good!
14:34 <slyon> I don't see anything new besides this
14:35 <sarnold> me neither, but it's hard to be sure with trees that large, heh
14:35 <slyon> #topic New MIRs
14:35 <slyon> Mission: ensure to assign all incoming reviews for fast processing
14:35 <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
14:35 <slyon> Only one. Do we have any volunteers?
14:35 <slyon> bug #2028054
14:35 <slyon> sorry, wrong paste
14:35 <slyon> bug #2031814
14:36 <slyon> Otherwise, I can take that one for next week.
14:36 <seb128> I'm unclear if that's still needed this cycle since we revert the cups snap transition
14:36 <seb128> still we will need it at some point so would be nice to get it reviewed
14:37 <seb128> but probably as a low priority one
14:37 <slyon> OK, thanks. I'll reach out to Till, to clarify the details
14:37 <seb128> thanks
14:37 * slyon assigned himself
14:37 <slyon> #topic Incomplete bugs / questions
14:37 <slyon> Mission: Identify required actions and spread the load among the teams
14:37 <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
14:38 <slyon> A bunch of updates since 2023-08-22
14:38 <slyon> bug #2023531 is actively being worked on by dviererbe IIRC
14:39 <slyon> regarding the SRU exception TODO
14:39 <slyon> bug #2030482
14:39 <sarnold> slyon: re 2030880  "This does need a security review, so I'll assign ubuntu-security" -- but it was assigned back to  Miriam
14:40 <slyon> sarnold: right. there are 3 required TODOs, so I decided to first pass it on to Miriam. Once resolved it can go to security. Or feel free to already put it into the security pipeline right now.
14:40 <sarnold> aha, okay, thanks
14:41 <eslerm> is this package required in mantic?
14:41 <eslerm> if so, we could add it to the queue now
14:41 <slyon> Similar situation for s390-tools: It's not yet fully ready for MIR (re-)review but I was told that all the bits relevant for security are already there. And I'd like to ask s390-tools (especially the new vendored rust dependencies) to be put into the security pipeline already.
14:42 <slyon> eslerm: Yes, I think so. For both, Miriam's -perl and s390-tools
14:42 <eslerm> can do
14:42 <slyon> thx!
14:42 <slyon> (cc schopin ^)
14:43 <slyon> bug #2031491 this is also for security, while we work out a single TODO
14:44 <slyon> bug #2030962 is back to Miriam
14:44 <slyon> we talked about bug #2030880 already
14:45 <slyon> we talked about bug #2028054 already (Desktop team to look into it)
14:45 <slyon> And that's the list.
14:45 <slyon> #topic Process/Documentation improvements
14:45 <didrocks> not that terrible :)
14:45 <slyon> Mission: Review pending process/documentation pull-requests or issues
14:45 <slyon> #link https://github.com/canonical/ubuntu-mir/pulls
14:45 <slyon> #link https://github.com/canonical/ubuntu-mir/issues
14:46 <slyon> https://github.com/canonical/ubuntu-mir/pull/37
14:46 <slyon> dviererbe: I think this should be mostly ready, right?
14:46 <dviererbe> correct
14:47 <slyon> thanks for working on the date/time formatting
14:47 <slyon> do we have any objections?
14:47 <dviererbe> Yes the documentation team suggested using 16:30+01:00, but i strongly disagree
14:47 <slyon> OK
14:48 <dviererbe> there was also a suggestion of using 15:30 UTC
14:48 <slyon> I guess I'll leave merging to cpaelzer, maybe he has some time after the meeting.
14:48 <sarnold> except our meeting isn't scheduled with UTC
14:48 <slyon> So other MIR people have some time to put their ACK/NACK onto the PR
14:48 <sarnold> if we change that for some reason, we can adapt this easily enough
14:48 <dviererbe> I linked the MM thread in the pull request
14:48 <slyon> sarnold: I think we're now using a CET format
14:48 <slyon> which is the timezone that our meeting is scheduled in
14:48 <dviererbe> https://chat.canonical.com/canonical/pl/g9sse8b7jpdfifr7hesfs6kzxc
14:49 <dviererbe> I am also not a fan of their suggestion
14:49 <slyon> We're also still waiting for more ACK/NACK on this PR: https://github.com/canonical/ubuntu-mir/pull/36
14:50 <slyon> Please everybody put your opinions on GitHub so we can get them merged (or rejected)
14:50 <didrocks> I will catch up on that one
14:50 <slyon> thanks!
14:50 <slyon> #topic MIR related Security Review Queue
14:50 <slyon> Mission: Check on progress, do deadlines seem doable?
14:50 <slyon> Some clients can only work with one, some with the other escaping - the URLs point to the same place.
14:50 <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
14:50 <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
14:50 <slyon> Internal link
14:50 <slyon> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
14:51 <slyon> eslerm:
14:51 <eslerm> we assigned new MIRs from last week
14:51 <seb128> we have a problem from the desktop side
14:52 <eslerm> dasbus was completed today
14:52 <seb128> https://launchpad.net/bugs/2031406 is blocking the new GNOME in mantic-proposed
14:52 <eslerm> for libei, I requested review by desktop freeze, but that is close
14:52 <seb128> GNOME isn't great in telling distributors in advance about new dependency so it came late
14:53 <seb128> any way we would get a preempt ack to promote it before review?
14:53 <slyon> seb128: libei also still lacking some autopkgtests from the MIR review.
14:54 <seb128> slyon, well, that's easy to resolve, I plan to work on that tomorrow
14:54 <seb128> easy->easier
14:54 <seb128> I'm more concerned about the security review delays
14:54 <slyon> ACK. sounds good! After that I'd be good from the MIR side, and I'd leave a decision about preempt security ACK to sarnold
14:54 <sarnold> one week?
14:54 <seb128> wfm
14:55 <seb128> that makes us catch beta still
14:55 <sarnold> I'm uneasy with the preemptive acks before review, in practice that tends to lead to packages that are never reviewed at all
14:55 <seb128> I don't feel like we have much of a choice, unless we throw away the new GNOME version
14:55 <seb128> but sure
14:57 <slyon> Ok.. so how do we find consensus on that. Did we have any similar precedence in the past?
14:58 <seb128> well sarnold said one week
14:58 <seb128> so it seems we just see if we get the security review by the next meeting?
14:58 <seb128> and re-discuss it not?
14:58 <sarnold> well, no, I was surprised you were frustrated with security delays when we were assigned this around one week ago
14:58 <seb128> ah
14:58 <seb128> sorry
14:59 <seb128> I'm not frustrated by the delay, sorry if it came along like that
14:59 <sarnold> ah, thanks. sorry for my part, too :)
14:59 <seb128> I started by apologizing, we got screwed by GNOME
14:59 <sarnold> yes :(
14:59 <seb128> we have no visibility on things like that
14:59 <slyon> we had a turnaround of about one week for most recent MIRs, to get into the security queues, which is very good.
14:59 <seb128> we are just in between a rock and an hard place now
14:59 <sarnold> I've left a note for alex in the ticket
15:00 <seb128> the depends is not easy to avoid/revert
15:00 <seb128> thanks
15:00 <slyon> Ok. I guess security is aware of the high priority and they'll try to do their very best. We can check the status next week and still decide about preemtiv promotion, if needed.
15:00 <slyon> is that fine for everybody?
15:01 <sarnold> wfm
15:01 <eslerm> +1
15:01 <didrocks> and meanwhile, desktop add the autopkgtest
15:01 <slyon> yes
15:01 <slyon> #topic Any other business?
15:02 <didrocks> nothing for me
15:02 <slyon> we're at the top of the hour. So keeping it short if possible.
15:02 <sarnold> none here
15:02 <eslerm> none
15:02 <slyon> alright, thank you all!
15:03 <seb128> not from me, and sorry again for the late request
15:03 <seb128> thanks!
15:03 <slyon> #endmeeting