15:31 <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
15:31 <meetingology> Meeting started at 15:31:02 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
15:31 <meetingology> Available commands: action, commands, idea, info, link, nick
15:31 <cpaelzer> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )
15:31 <jamespage> o/
15:31 <cpaelzer> I consier 4 critical mass in the week of thanksgiving - IIRC sarnold mentioned he might not be around?
15:32 <cpaelzer> let us go through the lists what actions we have
15:32 <cpaelzer> #topic current component mismatches
15:32 <cpaelzer> Mission: Identify required actions and spread the load among the teams
15:32 <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
15:32 <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
15:32 <cpaelzer> jemalloc is now a proper stub
15:32 <cpaelzer> jpeg-xl still waiting, butthen good
15:32 <slyon> ouch, sequoia
15:32 <cpaelzer> the openstack python bits also have proper stubs now
15:32 <slyon> there's an ongoing discussion about it in Foundations channels
15:32 <cpaelzer> mysql-8.4 needs a promotion, same source new version
15:33 <cpaelzer> there was a debian devel post about sequoia
15:33 <cpaelzer> also too many vowels think about if we added "sequoia in eoan"
15:34 <cpaelzer> is rust-nettle also related to that slyon?
15:34 <slyon> most probably yes.
15:34 <cpaelzer> in there I see libpfm4 hiding for llvm19, but that is a proper bug already
15:34 <liushuyu> sequoia uses libnettle for crypto operations on non-Windows systems
15:35 <slyon> Looks like gnupg2 pulls in some sequoia (camelaeon) bits, which depends on all sort of non-vendored rust dependenceis
15:35 <cpaelzer> ok, we leave that until you have concluded how you want to handle that
15:36 <cpaelzer> background https://www.mail-archive.com/debian-devel@lists.debian.org/msg382884.html
15:36 <cpaelzer> for the MIR context we can move on today
15:36 <cpaelzer> #topic New MIRs
15:36 <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
15:36 <cpaelzer> #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:36 <cpaelzer> two cases there
15:36 <liushuyu> The idea was to use the gpgv-compatible command-line tool but with sequoia implementation (since GnuPG now uses an implementation that diverges from the OpenPGP standards)
15:37 <cpaelzer> slyon: https://bugs.launchpad.net/ubuntu/+source/mmdebstrap/+bug/2087937
15:38 <slyon> adding a comment..
15:38 <cpaelzer> this is juliank wanting to revisit - which is fine but not yet putting this to the MIR team discussion
15:38 <cpaelzer> how about unsubscribing mir-team until this is somewhere we need to look?
15:38 <liushuyu> Yes, I was about to bring the http-parser vs llhttp discussion, since http-parser was MIR'ed together with Rust toolchain
15:38 <cpaelzer> we get to that next liushuyu
15:39 <liushuyu> sorry
15:39 <cpaelzer> np at all
15:40 <slyon> for mmdebstrap: Status: Incomplete should be fine until the MIR is filed?
15:40 <cpaelzer> yep
15:40 <cpaelzer> I saw your comment
15:40 <cpaelzer> also removed us until it is ready
15:40 <cpaelzer> as it might or might not become a MIR again
15:40 <cpaelzer> let us get to https://bugs.launchpad.net/ubuntu/+source/node-undici/+bug/2080872 now
15:41 <slyon> I think node-undici can be dropped from the MIR list, too.
15:41 <cpaelzer> liushuyu: so you got the ack by security to use the vendored one
15:42 <cpaelzer> I do not even see node-undici ?!
15:42 <slyon> We have the security team agreement. And it's now in the Foundations team's hand to make the switch from (deprecated) http-parser to vendored llhttp
15:42 <liushuyu> so we had some discussions about the situation and the idea was to use the vendored llhttp
15:42 <cpaelzer> and it is assigned so schopin
15:42 <cpaelzer> yes liushuyu
15:42 <cpaelzer> and security said two things
15:42 <cpaelzer> 1. yes as it is the best bad option available right now
15:42 <liushuyu> ... because we can't afford maintaining llhttp by pulling in Node.js
15:42 <cpaelzer> 2. do something really good so we do not forget revisiting and updating that in the future
15:43 * schopin didn't want any part of this but wasn't at that meeting...
15:43 <cpaelzer> once  llhttp is split apart.
15:43 <cpaelzer> oO sorry schopin
15:43 <cpaelzer> mayb liushuyu wants to do that for you?
15:43 <schopin> you're not the one who assigned it to me ;)
15:43 <cpaelzer> so you can not be part of it
15:44 <liushuyu> I don't know if we track vendored dependencies using `Static-Built-Using` binary package tags?
15:44 <slyon> I think the approach is clear (and has been tested, but rejected for now, in Debian). Vendoring llhttp probably needs a new .orig tarball, though.
15:45 <cpaelzer> yep, I updated the bug state
15:45 <cpaelzer> this does not need the MIR team
15:45 <slyon> ACK, MIR can be dropped
15:45 <cpaelzer> and you can internally sort out who is allowed to not deal with it
15:45 <cpaelzer> #topic Incomplete bugs / questions
15:45 <cpaelzer> Mission: Identify required actions and spread the load among the teams
15:45 <cpaelzer> #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:45 <schopin> Well, we did need MIR's ACK on the vendoring but afterwards it's indeed not your problem.
15:46 <cpaelzer> indeed, but that was given now by the rule slyon quoted and security saying ok as well
15:46 <cpaelzer> in this list only some openstack dependencies got recent updtes, we've seen them above as stubs
15:47 <cpaelzer> nothing to act on this one either
15:47 <cpaelzer> #topic MIR related Security Review Queue
15:47 <cpaelzer> Mission: Check on progress, do deadlines seem doable?
15:47 <cpaelzer> Some clients can only work with one, some with the other escaping - the URLs point to the same place.
15:47 <cpaelzer> #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:47 <cpaelzer> #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:47 <cpaelzer> Internal link
15:47 <cpaelzer> - ensure your teams items are prioritized among each other as you'd expect
15:47 <cpaelzer> - ensure community requests do not get stomped by teams calling for favors too much
15:47 <cpaelzer> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
15:47 <cpaelzer> without sarnold around there is not much but staring at the lists
15:47 <cpaelzer> even a usual suspect like eslerm seems not to be around
15:47 <cpaelzer> so let me go on for today
15:47 <cpaelzer> #topic Any other business?
15:48 <liushuyu> oh wait, I would like to ask about https://bugs.launchpad.net/ubuntu/+source/dbus-broker/+bug/2015538
15:48 <cpaelzer> I have a special case raised by utkarsh, but let us discuss the case of liushuyu first
15:48 <liushuyu> so the situation with dbus-broker is a bit strange, because it's co-owned by both Foundations and Desktop
15:49 <cpaelzer> yeah, let me answer to that post on the bug
15:49 <slyon> strictly speaking, it's still in universe, so not owned by anyone. But both teams had some attempts at enabling it in the past..
15:49 <liushuyu> ... and the trouble is, from the LP bug, I can't see what's blocking the task
15:50 <slyon> src:dbus is owned by Foundations, so in theory dbus-broker would be a good fit to be owned by Foundations, too.
15:51 <slyon> liushuyu: the blocker is having dbus and dbus-broker installed in parallel
15:51 <slyon> gdm needs dbus-run-session (https://gitlab.gnome.org/GNOME/gdm/-/blob/main/daemon/gdm-session.c#L2973) which is tightly coupled with src:dbus
15:51 <liushuyu> slyon: In thoery yes, but you see this kinda breaks GNOME desktop because some components use the legacy `dbus-run-session` thing
15:51 <slyon> so we either need to adopt gdm, or need a drop-in replacement for dbus-run-session
15:51 <liushuyu> but we now have several implementations for that
15:52 <slyon> those implementation need to be packaged, tested & shipped. Then a new case can be made to move the dbus-broker MIR forward. IMO that should be the next step
15:53 <cpaelzer> yes to the above
15:53 <cpaelzer> I answered the open questions on the bug
15:53 <cpaelzer> TL;DR
15:53 <cpaelzer> 1. I really recommend one team
15:53 <liushuyu> slyon: I see, then the issue would be there needs to be some communications between Desktop and Foundations to figure out how to perform the transitions
15:53 <cpaelzer> 2. ubuntu-security is the team to subscribe if it is them
15:53 <cpaelzer> yes liushuyu
15:53 <cpaelzer> it seems like neither can do it alone
15:54 <slyon> yes. liushuyu does that help to clarify the next steps?
15:54 <cpaelzer> I'm so glad it is late 2024 and not late 2025 being in this state
15:54 <liushuyu> slyon: Yes
15:54 <cpaelzer> great
15:54 <liushuyu> ah, sorry, wrong ping
15:54 <cpaelzer> then the case i had in mind
15:55 <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1889248
15:55 <cpaelzer> this is about the request to also promote jq in focal (it is in main in >=Jammy)
15:55 <cpaelzer> I've evaluated the differences and considered it an ack
15:55 <cpaelzer> security had a look as well, also an ack
15:56 <slyon> delta should be relatively small, considering we have 1.6 in foca-updates and jammy-release
15:56 <cpaelzer> as a bonus utkarsh will work on adding autopkgtests of it to devel
15:56 <cpaelzer> this is a "speak now or forever hold your peace" moment in case you disagree
15:56 <liushuyu> cpaelzer: I'm so glad it is late 2024 and not late 2025 being in this state > I think you would wish for that, because systemd people might pull out their new Varlink (tm) technology to replace D-Bus
15:56 <slyon> lgtm
15:56 <cpaelzer> liushuyu: yeah I've read about that
15:56 <cpaelzer> jamespage: joalif: any objections?
15:57 <cpaelzer> and also - any other topic?
15:57 <cpaelzer> nothing more from me
15:57 <slyon> nothing here
15:57 <jamespage> none
15:58 <liushuyu> No at the moment from me, but I might bring up "Rust code in main" situation
15:58 <joalif> nothing from me
15:58 <liushuyu> ... maybe next time?
15:58 <cpaelzer> from experience that blows the session time, but yeah let us go for it
15:58 <liushuyu> (considering we are running out of time)
15:58 <cpaelzer> next time
15:58 <cpaelzer> 2 minutes will not allow for any progress
15:58 <slyon> liushuyu: sure! Feel free to join next time, or create an Issue/PR on https://github.com/canonical/ubuntu-mir in the meantime
15:58 <cpaelzer> please be encouraged to jump in next time
15:58 <cpaelzer> or right PRs
15:58 <cpaelzer> uh
15:59 <cpaelzer> #topic Process/Documentation improvements
15:59 <cpaelzer> Mission: Review pending process/documentation pull-requests or issues
15:59 <cpaelzer> #link https://github.com/canonical/ubuntu-mir/pulls
15:59 <cpaelzer> #link https://github.com/canonical/ubuntu-mir/issues
15:59 <cpaelzer> notihng new
15:59 <cpaelzer> :-)
15:59 <liushuyu> cpaelzer, slyon: will do
15:59 <cpaelzer> but we will have one next time by liushuyu
15:59 <cpaelzer> thanks in advance
15:59 <cpaelzer> ok, that is it for today then
15:59 <cpaelzer> count ing out somehow ...
15:59 <cpaelzer> 1
15:59 <cpaelzer> 3
15:59 <cpaelzer> #endmeeting