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