== Meeting information == * #ubuntu-meeting: Weekly Main Inclusion Requests status meeting, started by slyon, 09 Apr at 14:29 — 15:14 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-04-09-14.29.log.html == Meeting summary == === current component mismatches === Discussion started by slyon at 14:30. * ''LINK:'' https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg (slyon, 14:31) * ''LINK:'' https://people.canonical.com/~ubuntu-archive/component-mismatches.svg (slyon, 14:31) === New MIRs === Discussion started by slyon at 14:31. * ''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 (slyon, 14:32) === Incomplete bugs / questions === Discussion started by slyon at 14:34. * ''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 (slyon, 14:34) === Process/Documentation improvements === Discussion started by slyon at 14:49. * ''LINK:'' https://github.com/canonical/ubuntu-mir/pulls (slyon, 14:49) * ''LINK:'' https://github.com/canonical/ubuntu-mir/issues (slyon, 14:49) === MIR related Security Review Queue === Discussion started by slyon at 14:49. * ''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 (slyon, 14:49) * ''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 (slyon, 14:49) * ''LINK:'' https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 (slyon, 14:49) === Any other business? === Discussion started by slyon at 14:53. * ''LINK:'' https://bugs.launchpad.net/ubuntu/+source/libmail-dmarc-perl/+bug/2023971 (mirespace, 14:59) == People present (lines said) == * cpaelzer (96) * slyon (81) * sarnold (15) * mirespace (12) * eslerm_ (9) * dviererbe (7) * adrien (7) * waveform (7) * meetingology (2) * joalif (1) * mclemenceau_ (1) == Full log == 14:29 #startmeeting Weekly Main Inclusion Requests status 14:29 Meeting started at 14:29:08 UTC. The chair is slyon. Information about MeetBot at https://wiki.ubuntu.com/meetingology 14:29 Available commands: action, commands, idea, info, link, nick 14:29 Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) 14:29 o/ 14:29 Still a bit early. Let's give it a minute or two 14:30 #topic current component mismatches 14:30 o/ 14:30 Mission: Identify required actions and spread the load among the teams 14:31 #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg 14:31 #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 14:31 This is looking very good. *bpf* got promoted. *trace* is making nice progress, just pending some work on libtracefs 14:31 #topic New MIRs 14:31 Mission: ensure to assign all incoming reviews for fast processing 14:32 #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:32 I managed to be free - hello (keep going slyon and thank you!) 14:32 just bug #2060056 from dviererbe 14:32 just-in-time cpaelzer :) 14:32 I'd like to ask cpaelzer to check this ^ as I think you have the most context. 14:32 ack on bpf, I resolved that 14:32 trace-cmd ack on looking good but needing a bit 14:32 It should be a quick "versioned package" upgrade, I assume. Correct, dviererbe? 14:33 Yes 14:33 on dotnet8 I didn't feel there was much open other than asking "do we need a full process again" 14:33 reading ... 14:33 spoiler: the answer is no - not full again 14:33 Oh I see, that is the new bug 14:33 good morning 14:33 I can give this a review tomorrow morning, expect this to be 99% a yes 14:34 Thanks! :) 14:34 cool, thanks! 14:34 assigned 14:34 #topic Incomplete bugs / questions 14:34 Mission: Identify required actions and spread the load among the teams 14:34 #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:36 so many recent updates 14:36 should we go top to bottom? 14:36 ok. bug #2004516 14:36 ok, that says escalate to have a chance 14:36 which I think is reasonable 14:37 This is blocked on security-review. but it's too late. I think it's not high priority and not necessarily needed for 24.04. So probably no need for escalation. I'll double check with ravikant_ 14:37 bug #2051925 14:37 yes 14:37 and update the case either way 14:37 will do 14:37 part of the bigger "perf tools for ubuntu by default" movement 14:38 "I'm working on this and mostly finishing the changes." sounds good 14:38 right. that should be the last missing piece for trace-cmd 14:38 ok, wait for the final update 14:38 bug #2004449 14:38 cpaelzer: you were the original reviewer. This is part of the libgd2 -> libheif -> ... chain, which is moving closer to completion 14:38 same as libyuv - although I'd love to have that in next LTS 14:39 Vladimir told me he did the work on this in Debian an it's sync'ed, can you double-check the requirements, cpaelzer ? 14:39 oh no, security has passed that already 14:39 yeah I can check against my requests from the review 14:39 thanks 14:39 can this move forward if libyuv doesn't? 14:39 no it can't 14:40 well... it could probably, but doesn't make a lot of sense I think 14:40 well, libde265 could - but there is no point for the final use case without the other 14:40 for libtracefs, I think I'm only left waiting on test results (I think I triggered the tests too early and it didn't pick the version in the PPA sadly) 14:40 exactly 14:41 thanks adrien! please re-ping the MIR bug once it's ready 14:41 bug #1977614 14:41 sure 14:41 tracking update from security team. Nothing to do for us 14:41 ack 14:41 bug #2058192 14:41 not yet ready 14:42 ack 14:42 bug #2054480 14:43 this is a case of "to re-review security" or "not to re-review security" 14:43 +1 vote on should-be-reviewed 14:43 It would be useful, but we're past the point where we can make it happen for 24.04 I assume? I'll double-check with waveform to see how critical this is 14:43 or is this "needs to be in noble in main asap" panic (still review but later then)? 14:44 I'll try to find out 14:44 and if you need it 14:44 go the "escalate with security" path 14:44 slyon, it's one of the items on my roadmap but it's not going to "break the image" if it has to go red 14:44 See the update by Seth on the other bug 14:44 if you (and mclemenceau_) think we should have it 14:44 escalate it now 14:44 and we might 14:45 waveform: can this be "added to main later" ? 14:45 we have done component moves after the release, that isn't impossible 14:45 so could it be ready for 24.04.1 ? 14:45 well, the idea of including it in the image was to enable netboot of the release image, so if we add it to main later it'll only really benefit .1 onwards 14:45 or is - after that is approved - a "major revamp how everything works" needed? 14:46 I'm mostly, is this a "safe addition" later or is this "to be used break the world" change 14:46 if it is the former, we can make it happen toward 24.04.1 and that should be our goal then IMHO 14:46 oh, safe addition -- it's basically just enabling the initramfs to support nbd boot (assuming the necessary kernel param is present) 14:46 ok, how about that - not giving up on the item but timing it towards that? 14:46 o/ 14:46 given that this package had been in main itself, it's 'just'a binary package move, and I don't recall seeing it as a source of work, and that the attack surface is largely in the kernel, I think I'd encourage this to go to main in time for 24.04 release 14:47 update the bug in that case and security can review without panic-priority 14:47 I'm fine with that (enabling for .1) 14:47 I do have a question for libtracefs btw: I've addressed comments; does the MIR team still needs to be involved or could a regular review before upload do it? (sorry to come back late to this) 14:47 sarnold: sure, if you consider this a quick security review - let us make the change for 24.04 14:47 I'm sure waveform will be happy 14:47 I would love it to go into 24.04 but if it has to be shunted, I'm okay with that too 14:47 how about this - sarnold spends 20 minutes, and gives a shallow security review based on this being in main in the past kind of alreay 14:48 if that outcome is good, get it into 24.04 14:48 wfm 14:48 if not, see former plan for 24.04.1 14:48 great 14:48 sure 14:48 very nice! thanks 14:48 waveform: sarnold: work together and make my Pi NBD boot! 14:48 :D 14:48 o7 14:48 I guess that's all for MIR updates. dbus-broker is stuck for now and needs some additional (upstream) work 14:49 #topic Process/Documentation improvements 14:49 Mission: Review pending process/documentation pull-requests or issues 14:49 #link https://github.com/canonical/ubuntu-mir/pulls 14:49 #link https://github.com/canonical/ubuntu-mir/issues 14:49 no updates as of last week AFAICT 14:49 #topic MIR related Security Review Queue 14:49 Mission: Check on progress, do deadlines seem doable? 14:49 Some clients can only work with one, some with the other escaping - the URLs point to the same place. 14:49 #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:49 #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:49 Internal link 14:49 #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 14:50 no more looks front-loaded which is good given the time we are in the cycle 14:50 bug #2004516 was discussed above and should not get a sec-* tag for now 14:50 slyon: it should 14:51 bug #2060035 is targeted for 24.04.1 14:51 just not an urgent one 14:51 wfm 14:51 BTW - I know we all feel pressure atm, please all remember how bad this often was in the past, and be happy. Then take a breath and thank security for making it happen! 14:51 <3 14:51 <3 14:51 thanks sarnold and eslerm_ - pass the thanks to all that helped please 14:51 Yes.. we have enough fires in other places this cycle :) 14:51 * slyon looking at t64 & xz 14:51 oh so true slyon 14:51 yes 14:52 sarnold: eslerm_: OK so can we get msgraph and libyuv imported in Jira? 14:52 can do 14:52 for non-urgent processing 14:53 #topic Any other business? 14:53 A follow up question to the dotnet6 MIR: Do I need to find an Archive Admin to do the promotion or will someone take care of this eventually before 24.04 GA? 14:53 adrien: can you please repeat your question from above? 14:53 dviererbe: AAs usually pick it up from the report, once the MIR status is "Fix Committed" 14:54 and it is seeded/pulled as a dependency 14:54 dviererbe: the last comment from cpaelzer is "ready for you to change seeds" -- do know if this step has been done yet? 14:54 I do not see it in component mismatches 14:54 neither do I 14:54 No, I don't think so 14:55 o/ for the DMARC perl, do you need anything from me to decide about libmime-tools vs libemail-mime ? 14:55 Hi mirespace - who are you asking in particular? 14:55 security, MIR in general, ... ? 14:55 mirespace: did you see this update? https://github.com/rjbs/Email-MIME/issues/66#issuecomment-2024085120 (cc eslerm_) 14:55 there is so much context that sadly left my memory 14:55 slyon: my question is whether the MIR team expects to have further MIR-specific comments for libtracefs or if any uploader/reviewer could check the open items effectively 14:56 dviererbe: for your case, do you know what is expected from you to change seeds for this? 14:56 _checking that link_ 14:56 cpaelzer: not really, I have never done this so far 14:56 I've been addressing all the open comments and I'm almost done (it looks like something still isn't ready but it shouldn't take much longer) 14:56 dviererbe: and you can be bold, and do it for dotnet6 and dotnet8 (for noble) to make them supported (but do not pre-install them anywhere) 14:56 adrien: you get the upload done and then a MIR team member needs to approve the bug report by changing to the relevant status 14:56 slyon: can you teach dviererbe or organize that someone else does? 14:57 foundations internal I mean 14:57 sure dviererbe. I can help with that. please reach out to me on MM 14:57 slyon: hmmm, right, the question is mostly moot indeed 14:57 slyon: ack 14:57 adrien: once you think it is ready, update the case. And for urgency get in touch with me or slyon (to not wait for next Tue) 14:57 :O ... so the MIME DoS issue is not toatally resolved... 14:57 cpaelzer: thanks 14:58 cpaelzer: I was worried that the debate between mime-tools and email-mime could make the MIR being stuck 14:59 I would like to see rjbs/Email-MIME in 24.04, the upstream devs do great work at fastmail 14:59 I'm worried as well, but too far from it to have a good understanding atm 14:59 mirespace: can you remind us of the LP bug number? 14:59 it didn't show up in today's lists 14:59 also collision and I need to leave for the next meeting 14:59 slyon: it is an older incomplete somewhere 14:59 https://bugs.launchpad.net/ubuntu/+source/libmail-dmarc-perl/+bug/2023971 14:59 cpaelzer: I have one question for you, regarding libgoa-* depdency 15:00 cpaelzer: see https://bugs.launchpad.net/ubuntu/+source/msgraph/+bug/2060035 (you can reply on that bug later) 15:00 Not sure what to do about the libgoa-* dependency or why we check for it during the MIR review. It's been there for historical reasons. But we need it in this case 15:01 eslerm_: to what extend it rjibs/Email-MIME and similar good wishes for the future but no blockers for now 15:01 after all time for 24.04 runs out and I understand mirespace getting concerned 15:01 mirespace: what are the options we have there 15:01 is it: 15:01 libmail-dmarc-perl does have an ack, the open issue needs to be solved, but *might* not be a blocker (Seth?) 15:02 I fail to summarize it :-/ 15:02 thanks cpaelzer sarnold, I'm ok with the plan w.r.t netboot with a preference for addition in 24.04 :) 15:02 I don't mind contacting upstream and asking if they can make a plan 15:02 use the change we did to use libmime-tools-perl, diverging from upstream 15:02 ok, consider ^^ option (a) 15:03 what is option (b) 15:03 slyon: for libgoa - it can be a build dependency, just not a runtime dependency (and not part of the final code, no static linking tricks) 15:03 if (a) is libemail-mime contacting upstream, option (b)is use libmime-tools, diverging upstream 15:04 cpaelzer: ACK. thanks I'll update the case 15:04 slyon: but if it is used at build to get stuff done (like test tools, binary mangling helpers, ...) then it does not need to be in main 15:04 (or 'it's not a library it's just a .h file tricks :) 15:04 slyon: >Trusty, before it had to be 15:04 sarnold: yes, that I count as "static code active in the final binary" which would need to be in main 15:05 sarnold: just as much as any other similar trick 15:05 back to mime 15:05 eslerm_: mirespace: what is the way forward 15:05 eslerm_: you said the open issue might (tm) not be a blocker 15:05 libgoa being gnome-online-accounts, right? I.e. https://packages.ubuntu.com/noble/libgoa-1.0-0b 15:05 just an important "we want to work thazt out in the long run" 15:06 if it is really that, can we go on with the promotion of that stack then? 15:06 as-is I mean 15:06 the promotion form my PPA uses libmime-tools by the moment 15:06 since these are ack'd I am okay with pushing through if Seth agrees. If so, I can contact upstream and try to settle issues. 15:06 because emailñ-mime introduced duplicity 15:07 sounds like a good plan compromise, unblock now, do not give up on making it better 15:07 and thanks for the offer to contact upstream 15:07 I'm a bit worried that comment #27 on https://bugs.launchpad.net/ubuntu/+source/libmail-dmarc-perl/+bug/2023971 suggests that there's even MORE packages to MIR in order to "just ship what debian ships" 15:07 (I'll message upstream today) 15:07 but I have to admit that this is a twisty maze of package names that all collide into one single mental hashbucket and I've long ago lost the plot 15:07 sarnold: well, we can slowly sort that out one by one >24.04 15:08 the question is can we take the current approved set for 24.04 and resolve it here? 15:09 if yes, then I'd ask mirespace to work with bryce to prepare the seed/dependency changes and prepare a session telling me what would need to be promoted and why. I could check one by one - if all good mass promotion 15:09 mirespace: will work on several follow up items anyway, like the elliptic curve lib wrapper and such 15:10 for me it's ok 15:11 +1 15:12 so to summarize, eslerm_ contacts upstreams for a better path forward. mirespace will prep and lay out what we have ready and can land for 24.04 15:12 short: get what we have to noble, mid term make it better 15:12 I can do that :) 15:13 sounds like a plan :) 15:13 mirespace: can you work with bryce to get all in line (probably some blocks by the beta freeze) and then get in touch 15:13 it is work, but better than the unclear state before 15:13 ok, we are way over time 15:13 yes, I do.. thank you all for unblocking this 15:13 slyon: time to get to the end :-) ? 15:13 i'm probably not going to come to a good udnerstanding of the whole problem space and the options quickly .. so here's a few of my general thoughts: (a) I'd prefer to not diverge from debian and the upstreams if we can (b) i'm fine with shipping mirespace's "lets change packages to meet our existing main requirements" but I'm not wedded to it (c) I'm not too worried about a 1 meg --> 2 gigs of ram 15:13 DOS, that'd probably be tolerable enough to fix post-release if upstream doesn't get to it sooner 15:14 (doesn't every mail server have 100 gigs ram? :) 15:14 almost 15:14 thanks for the summary! 15:14 or 640k 15:14 :D 15:14 do we have anything else? 15:14 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)