14:29 <slyon> #startmeeting Weekly Main Inclusion Requests status
14:29 <meetingology> Meeting started at 14:29:08 UTC.  The chair is slyon.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
14:29 <meetingology> Available commands: action, commands, idea, info, link, nick
14:29 <slyon> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )
14:29 <dviererbe> o/
14:29 <slyon> Still a bit early. Let's give it a minute or two
14:30 <slyon> #topic current component mismatches
14:30 <joalif> o/
14:30 <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 <slyon> This is looking very good. *bpf* got promoted. *trace* is making nice progress, just pending some work on libtracefs
14:31 <slyon> #topic New MIRs
14:31 <slyon> Mission: ensure to assign all incoming reviews for fast processing
14:32 <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:32 <cpaelzer> I managed to be free - hello (keep going slyon and thank you!)
14:32 <slyon> just bug #2060056 from dviererbe
14:32 <slyon> just-in-time cpaelzer :)
14:32 <slyon> I'd like to ask cpaelzer to check this ^ as I think you have the most context.
14:32 <cpaelzer> ack on bpf, I resolved that
14:32 <cpaelzer> trace-cmd ack on looking good but needing a bit
14:32 <slyon> It should be a quick "versioned package" upgrade, I assume. Correct, dviererbe?
14:33 <dviererbe> Yes
14:33 <cpaelzer> on dotnet8 I didn't feel there was much open other than asking "do we need a full process again"
14:33 <cpaelzer> reading ...
14:33 <cpaelzer> spoiler: the answer is no - not full again
14:33 <cpaelzer> Oh I see, that is the new bug
14:33 <sarnold> good morning
14:33 <cpaelzer> I can give this a review tomorrow morning, expect this to be 99% a yes
14:34 <dviererbe> Thanks! :)
14:34 <slyon> cool, thanks!
14:34 <slyon> assigned
14:34 <slyon> #topic Incomplete bugs / questions
14:34 <slyon> Mission: Identify required actions and spread the load among the teams
14:34 <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:36 <cpaelzer> so many recent updates
14:36 <cpaelzer> should we go top to bottom?
14:36 <slyon> ok. bug #2004516
14:36 <cpaelzer> ok, that says escalate to have a chance
14:36 <cpaelzer> which I think is reasonable
14:37 <slyon> 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 <slyon> bug #2051925
14:37 <cpaelzer> yes
14:37 <cpaelzer> and update the case either way
14:37 <slyon> will do
14:37 <cpaelzer> part of the bigger "perf tools for ubuntu by default" movement
14:38 <cpaelzer> "I'm working on this and mostly finishing the changes." sounds good
14:38 <slyon> right. that should be the last missing piece for trace-cmd
14:38 <cpaelzer> ok, wait for the final update
14:38 <slyon> bug #2004449
14:38 <slyon> cpaelzer: you were the original reviewer. This is part of the libgd2 -> libheif -> ... chain, which is moving closer to completion
14:38 <cpaelzer> same as libyuv - although I'd love to have that in next LTS
14:39 <slyon> 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 <cpaelzer> oh no, security has passed that already
14:39 <cpaelzer> yeah I can check against my requests from the review
14:39 <slyon> thanks
14:39 <sarnold> can this move forward if libyuv doesn't?
14:39 <slyon> no it can't
14:40 <slyon> well... it could probably, but doesn't make a lot of sense I think
14:40 <cpaelzer> well,  libde265 could - but there is no point for the final use case without the other
14:40 <adrien> 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 <slyon> exactly
14:41 <slyon> thanks adrien! please re-ping the MIR bug once it's ready
14:41 <slyon> bug #1977614
14:41 <adrien> sure
14:41 <slyon> tracking update from security team. Nothing to do for us
14:41 <cpaelzer> ack
14:41 <slyon> bug #2058192
14:41 <cpaelzer> not yet ready
14:42 <slyon> ack
14:42 <slyon> bug #2054480
14:43 <slyon> this is a case of "to re-review security" or "not to re-review security"
14:43 <cpaelzer> +1 vote on should-be-reviewed
14:43 <slyon> 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 <cpaelzer> or is this "needs to be in noble in main asap" panic (still review but later then)?
14:44 <slyon> I'll try to find out
14:44 <cpaelzer> and if you need it
14:44 <cpaelzer> go the "escalate with security" path
14:44 <waveform> 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 <cpaelzer> See the update by Seth on the other bug
14:44 <cpaelzer> if you (and mclemenceau_) think we should have it
14:44 <cpaelzer> escalate it now
14:44 <cpaelzer> and we might
14:45 <cpaelzer> waveform: can this be "added to main later" ?
14:45 <cpaelzer> we have done component moves after the release, that isn't impossible
14:45 <cpaelzer> so could it be ready for 24.04.1 ?
14:45 <waveform> 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 <cpaelzer> or is - after that is approved - a "major revamp how everything works" needed?
14:46 <cpaelzer> I'm mostly, is this a "safe addition" later or is this "to be used break the world" change
14:46 <cpaelzer> if it is the former, we can make it happen toward 24.04.1 and that should be our goal then IMHO
14:46 <waveform> oh, safe addition -- it's basically just enabling the initramfs to support nbd boot (assuming the necessary kernel param is present)
14:46 <cpaelzer> ok, how about that - not giving up on the item but timing it towards that?
14:46 <eslerm_> o/
14:46 <sarnold> 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 <cpaelzer> update the bug in that case and security can review without panic-priority
14:47 <waveform> I'm fine with that (enabling for .1)
14:47 <adrien> 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 <cpaelzer> sarnold: sure, if you consider this a quick security review - let us make the change for 24.04
14:47 <cpaelzer> I'm sure waveform will be happy
14:47 <waveform> I would love it to go into 24.04 but if it has to be shunted, I'm okay with that too
14:47 <cpaelzer> 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 <cpaelzer> if that outcome is good, get it into 24.04
14:48 <sarnold> wfm
14:48 <cpaelzer> if not, see former plan for 24.04.1
14:48 <cpaelzer> great
14:48 <waveform> sure
14:48 <slyon> very nice! thanks
14:48 <cpaelzer> waveform: sarnold: work together and make my Pi NBD boot!
14:48 <sarnold> :D
14:48 <waveform> o7
14:48 <slyon> I guess that's all for MIR updates. dbus-broker is stuck for now and needs some additional (upstream) work
14:49 <slyon> #topic Process/Documentation improvements
14:49 <slyon> Mission: Review pending process/documentation pull-requests or issues
14:49 <slyon> #link https://github.com/canonical/ubuntu-mir/pulls
14:49 <slyon> #link https://github.com/canonical/ubuntu-mir/issues
14:49 <slyon> no updates as of last week AFAICT
14:49 <slyon> #topic MIR related Security Review Queue
14:49 <slyon> Mission: Check on progress, do deadlines seem doable?
14:49 <slyon> Some clients can only work with one, some with the other escaping - the URLs point to the same place.
14:49 <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:49 <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:49 <slyon> Internal link
14:49 <slyon> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
14:50 <cpaelzer> no more looks front-loaded which is good given the time we are in the cycle
14:50 <slyon> bug #2004516 was discussed above and should not get a sec-* tag for now
14:50 <cpaelzer> slyon: it should
14:51 <slyon> bug #2060035 is targeted for 24.04.1
14:51 <cpaelzer> just not an urgent one
14:51 <slyon> wfm
14:51 <cpaelzer> 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 <sarnold> <3
14:51 <eslerm_> <3
14:51 <cpaelzer> thanks sarnold and eslerm_ - pass the thanks to all that helped please
14:51 <slyon> Yes.. we have enough fires in other places this cycle :)
14:51 * slyon looking at t64 & xz
14:51 <cpaelzer> oh so true slyon
14:51 <sarnold> yes
14:52 <slyon> sarnold: eslerm_: OK so can we get msgraph and libyuv imported in Jira?
14:52 <eslerm_> can do
14:52 <slyon> for non-urgent processing
14:53 <slyon> #topic Any other business?
14:53 <dviererbe> 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 <slyon> adrien: can you please repeat your question from above?
14:53 <slyon> dviererbe: AAs usually pick it up from the report, once the MIR status is "Fix Committed"
14:54 <slyon> and it is seeded/pulled as a dependency
14:54 <sarnold> dviererbe: the last comment from cpaelzer is "ready for you to change seeds" -- do know if this step has been done yet?
14:54 <cpaelzer> I do not see it in component mismatches
14:54 <slyon> neither do I
14:54 <dviererbe> No, I don't think so
14:55 <mirespace> o/ for the DMARC perl, do you need anything from me to decide about libmime-tools vs libemail-mime ?
14:55 <cpaelzer> Hi mirespace -  who are you asking in particular?
14:55 <cpaelzer> security, MIR in general, ... ?
14:55 <slyon> mirespace: did you see this update? https://github.com/rjbs/Email-MIME/issues/66#issuecomment-2024085120 (cc eslerm_)
14:55 <cpaelzer> there is so much context that sadly left my memory
14:55 <adrien> 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 <cpaelzer> dviererbe: for your case, do you know what is expected from you to change seeds for this?
14:56 <mirespace> _checking that link_
14:56 <dviererbe> cpaelzer: not really, I have never done this so far
14:56 <adrien> 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 <cpaelzer> 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 <slyon> 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 <cpaelzer> slyon: can you teach dviererbe or organize that someone else does?
14:57 <cpaelzer> foundations internal I mean
14:57 <slyon> sure dviererbe. I can help with that. please reach out to me on MM
14:57 <adrien> slyon: hmmm, right, the question is mostly moot indeed
14:57 <dviererbe> slyon: ack
14:57 <cpaelzer> 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 <mirespace> :O ... so the MIME DoS issue is not toatally resolved...
14:57 <adrien> cpaelzer: thanks
14:58 <mirespace> cpaelzer: I was worried that the debate between mime-tools and email-mime could make the MIR being stuck
14:59 <eslerm_> I would like to see rjbs/Email-MIME in 24.04, the upstream devs do great work at fastmail
14:59 <cpaelzer> I'm worried as well, but too far from it to have a good understanding atm
14:59 <slyon> mirespace: can you remind us of the LP bug number?
14:59 <slyon> it didn't show up in today's lists
14:59 <cpaelzer> also collision and I need to leave for the next meeting
14:59 <cpaelzer> slyon: it is an older incomplete somewhere
14:59 <mirespace> https://bugs.launchpad.net/ubuntu/+source/libmail-dmarc-perl/+bug/2023971
14:59 <slyon> cpaelzer: I have one question for you, regarding libgoa-* depdency
15:00 <slyon> cpaelzer: see https://bugs.launchpad.net/ubuntu/+source/msgraph/+bug/2060035 (you can reply on that bug later)
15:00 <slyon> 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 <cpaelzer> eslerm_: to what extend it rjibs/Email-MIME and similar good wishes for the future but no blockers for now
15:01 <cpaelzer> after all time for 24.04 runs out and I understand mirespace getting concerned
15:01 <cpaelzer> mirespace:  what are the options we have there
15:01 <cpaelzer> is it:
15:01 <eslerm_> libmail-dmarc-perl does have an ack, the open issue needs to be solved, but *might* not be a blocker (Seth?)
15:02 <cpaelzer> I fail to summarize it :-/
15:02 <mclemenceau_> thanks cpaelzer sarnold, I'm ok with the plan w.r.t netboot with a preference for addition in 24.04 :)
15:02 <eslerm_> I don't mind contacting upstream and asking if they can make a plan
15:02 <mirespace> use the change we did to use libmime-tools-perl, diverging from upstream
15:02 <cpaelzer> ok, consider ^^ option (a)
15:03 <cpaelzer> what is option (b)
15:03 <cpaelzer> 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 <mirespace> if (a) is libemail-mime contacting upstream, option (b)is  use libmime-tools, diverging upstream
15:04 <slyon> cpaelzer: ACK. thanks I'll update the case
15:04 <cpaelzer> 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 <sarnold> (or 'it's not a library it's just a .h file tricks :)
15:04 <cpaelzer> slyon: >Trusty, before it had to be
15:04 <cpaelzer> sarnold: yes, that I count as "static code active in the final binary" which would need to be in main
15:05 <cpaelzer> sarnold: just as much as any other similar trick
15:05 <cpaelzer> back to mime
15:05 <cpaelzer> eslerm_: mirespace: what is the way forward
15:05 <cpaelzer> eslerm_: you said the open issue might (tm) not be a blocker
15:05 <slyon> libgoa being gnome-online-accounts, right? I.e. https://packages.ubuntu.com/noble/libgoa-1.0-0b
15:05 <cpaelzer> just an important "we want to work thazt out in the long run"
15:06 <cpaelzer> if it is really that, can we go on with the promotion of that stack then?
15:06 <cpaelzer> as-is I mean
15:06 <mirespace> the promotion form my PPA uses libmime-tools by the moment
15:06 <eslerm_> 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 <mirespace> because emailñ-mime introduced duplicity
15:07 <cpaelzer> sounds like a good plan compromise, unblock now, do not give up on making it better
15:07 <cpaelzer> and thanks for the offer to contact upstream
15:07 <sarnold> 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 <eslerm_> (I'll message upstream today)
15:07 <sarnold> 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 <cpaelzer> sarnold: well, we can slowly sort that out one by one >24.04
15:08 <cpaelzer> the question is can we take the current approved set for 24.04 and resolve it here?
15:09 <cpaelzer> 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 <cpaelzer> mirespace: will work on several follow up items anyway, like the elliptic curve lib wrapper and such
15:10 <mirespace> for me it's ok
15:11 <slyon> +1
15:12 <cpaelzer> 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 <cpaelzer> short: get what we have to noble, mid term make it better
15:12 <eslerm_> I can do that :)
15:13 <mirespace> sounds like a plan :)
15:13 <cpaelzer> 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 <cpaelzer> it is work, but better than the unclear state before
15:13 <cpaelzer> ok, we are way over time
15:13 <mirespace> yes, I do.. thank you all for unblocking this
15:13 <cpaelzer> slyon: time to get to the end :-) ?
15:13 <sarnold> 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 <sarnold> DOS, that'd probably be tolerable enough to fix post-release if upstream doesn't get to it sooner
15:14 <sarnold> (doesn't every mail server have 100 gigs ram? :)
15:14 <cpaelzer> almost
15:14 <slyon> thanks for the summary!
15:14 <cpaelzer> or 640k
15:14 <sarnold> :D
15:14 <slyon> do we have anything else?
15:14 <slyon> #endmeeting