15:35 #startmeeting Weekly Main Inclusion Requests status 15:35 Meeting started at 15:35:12 UTC. The chair is sarnold. Information about MeetBot at https://wiki.ubuntu.com/meetingology 15:35 Available commands: action, commands, idea, info, link, nick 15:35 Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) 15:35 #topic current component mismatches 15:35 Mission: Identify required actions and spread the load among the teams 15:35 #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg 15:35 #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 15:35 wow so much qt6 15:36 I pushed some seed changes to hopefully get rid of the qt5 & qt6 trees earlier today. 15:36 woot 15:36 Also I cleaned up the sbuild->mmdebstrap and investigated libgit2 (more about this in AOB) 15:36 there was a request for an archive admin to demote new gpgme binaries for qt6 15:36 tmux to jemalloc, server team .. 15:36 jbicha: do you have a reference? 15:37 I added extra includes for the new libqgpgme* packages 15:37 i'm always skeptical of packages that "need" a fancy malloc, I hope this can be cleaned up. (nothing against jemalloc..) 15:37 *extra-excludes 15:37 slyon: https://irclogs.ubuntu.com/2024/11/03/%23ubuntu-release.html#t18:38 15:37 thx 15:37 cpaelzer: should investigate/delegate tmux 15:38 libgit2 -> node-undici looks to be foundations, too? perhaps the http parser gizmo has a new requirement? I had the impression that there might be a good replacement for the http gizmo they were using, so there might be a very nice outcome there.. 15:39 python-osprofiler -> python-jaeger-client looks like openstack, is that one for jamespage to either file MIRs (my guess) or remove the dep? 15:39 sarnold: Yes, I updated the attached MIR bug report. lining out 3 options, and would like to get some security team insights about the different approaches 15:39 slyon: oh sweet :) 15:39 plucky kernel seed feels like an aa thing to handle, another one for cpaelzer in a free moment? 15:40 python-pint -> flexcache and flexparser, feels like another jamespage thing to drive 15:40 ack, or maybe the kernel team themselves? Not sure who handles those usually, but they tend to go away after a while :) 15:40 slyon: lol yes :) 15:40 logcheck->esmtp feels like it'd be nice to take off the graph this cycle, through whatever means :) 15:41 sarnold: probably - I'll take a look this week 15:41 jamespage: thanks :) 15:42 so .. that leaves the various unapproved MIRs .. we should probably try to figure out where each one of those is at, and see if they need assignment, or a poke, etc 15:42 https://bugs.launchpad.net/ubuntu/+source/jpeg-xl/+bug/2070882 and https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2070807 -- looks like these are back to jbicha for the moment 15:42 ACK, we probably want the original MIR reviewer to validate/update the case 15:43 https://bugs.launchpad.net/ubuntu/+source/libgit2/+bug/2080872 is looking for advice, so please everyone give this a look and advise :) https://bugs.launchpad.net/ubuntu/+source/libgit2/+bug/2080872 15:43 I believe jpeg-xl & highway are ready. architecture-properties also 15:43 https://bugs.launchpad.net/ubuntu/+source/architecture-properties/+bug/2080965 15:44 joalif: can you double-check jpeg-xl 15:44 ? 15:44 jbicha: could you add comments to the bugs with the current states? I thought jpeg-xl might still be waiting on security review? (but I haven't really looked in N weeks) 15:44 I will double-check highway 15:44 and I will double-check architecture properties 15:45 architecture-properties confuses me, there's a bunch of i386 discussion there, but I thought this package was mostly about indicating 64 bit in general, or which flavor of amd64 instruction sets it supports? 15:46 well, I might as well put that in the bug, I may not be the only one curious :) 15:47 sarnold: I think it also provides some "is-32bit" / "is-64bit" (or alike) conditions 15:47 so would be good to have on i386 15:47 slyon: oops, jpeg-xl is blocked for security review, which means highway doesn't need to be promoted yet 15:48 ok. Let's assign it to ubuntu-security then 15:48 cool cool 15:48 https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 15:48 all covered 15:48 ack 15:48 maybe we ought to swap the order of these links? heh 15:49 #topic New MIRs 15:49 Mission: ensure to assign all incoming reviews for fast processing 15:49 #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:49 looks like all four covered already 15:49 #topic Incomplete bugs / questions 15:49 Mission: Identify required actions and spread the load among the teams 15:49 #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:49 I created tracking bug #2087937 15:50 nothing actionable for us. I downgraded the Recommends in sbuild 15:51 is ther any appetite for considering a switch to mmdebstrap? I understand it's way faster than debootstrap, and if this unshare mode is nice it might also be an improvement over chroots? 15:51 I remember some recent discussion in Foundations about using it in ubuntu-image, which was rejected 15:51 (I can dig up the details, if needed) 15:52 it might be nice, I'm probably not the only one curious :) 15:52 I'll add a link to the LP bug 15:52 @slyon @jbicha wrt to jpeg-xl it needs a sec review plus highway to promoted 15:53 https://bugs.launchpad.net/ubuntu/+source/lenovo-wwan-unlock/+bug/2058192 is coming along nicely, it looks like they made some changes https://github.com/lenovo/lenovo-wwan-unlock/commit/255ec187a428a99710d0e44b165ee95436952830 so that's probably on me to review 15:54 https://bugs.launchpad.net/ubuntu/+source/linuxptp/+bug/2071717 looks like it's "back to ther reporter to handle this"? probably we can skip looking at the rest of this list 15:54 nothing new in here ^ needs more work by the OEM team 15:54 #topic Process/Documentation improvements 15:54 Mission: Review pending process/documentation pull-requests or issues 15:54 #link https://github.com/canonical/ubuntu-mir/pulls 15:54 #link https://github.com/canonical/ubuntu-mir/issues 15:55 I seriously wish for a date from github on most recent change to a thing; anyway it feels like these are fine 15:55 #topic MIR related Security Review Queue 15:55 Mission: Check on progress, do deadlines seem doable? 15:55 Some clients can only work with one, some with the other escaping - the URLs point to the same place. 15:55 #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:55 #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:55 Internal link 15:55 - ensure your teams items are prioritized among each other as you'd expect 15:55 - ensure community requests do not get stomped by teams calling for favors too much 15:55 #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 15:55 hmm importance sort is probably not the best (it never is) 15:57 well, here's hoping that this cycle is more effective than last cycle.. it's sad seeing last cycle's stuff on here :( 15:58 I'm concerned about fdk-aac-free -- that code felt pretty abandoned :( 15:58 otherwise i'll try to get some traction on these 15:59 please do make sure the items in the jira are prioritised appropriately -- we can't always handle them in priority order, since we also try to match who is available with what is available with the time available, etc.. 15:59 but it certainly helps 15:59 so.. 15:59 #topic Any other business? 15:59 sarnold: I'd like you input on option A/B/C in https://bugs.launchpad.net/ubuntu/+source/node-undici/+bug/2080872/comments/2 – doesn't need to be ad-hoc, but maybe as a comment on LP 16:00 slyon: ack, thanks for the reminder :) 16:00 basically, we have no proper libllhttp package, so should consider how to vendor it 16:00 oh dang, I was hoping it was "replace it with something less weird" :) 16:01 well... its typescript being transpiled to C and then vendored as a shared object... tell me about weird :) 16:01 *shudder* 16:02 if that's it... 16:02 #endmeeting