[14:30] <cpaelzer> o/
[14:30] <jbicha> o/
[14:30] <slyon> o/
[14:30] <joalif> o/
[14:31] <seb128> o/
[14:31] <sarnold> good morning
[14:31] <eslerm_> o/
[14:32] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[14:32] <meetingology> Meeting started at 14:32:03 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:32] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:32] <cpaelzer> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )
[14:32] <cpaelzer> actually almost everyone said hi already
[14:32] <cpaelzer> let us start
[14:32] <cpaelzer> #topic current component mismatches
[14:32] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:32] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:32] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:32] <aciba> O/
[14:32] <cpaelzer> first trace-cmd and libtraceevent
[14:33] <cpaelzer> trace-cmd ready
[14:33] <cpaelzer> libtraceevent ready as well
[14:33] <slyon> I think those are ready, but pending libtracefs, which still sees some tests issues on s390x & ppc64el
[14:33] <cpaelzer> can be promoted
[14:33] <cpaelzer> any opposing opinions?
[14:33] <slyon> would it be OK to skip those architectures?
[14:34] <cpaelzer> I was going by the "all required TODOs" - thanks for reminding me
[14:34] <slyon> +1 for promoting trace-cmd + libtraceevent already. That would reduce the component mismatches already
[14:34] <sarnold> are we suggesting to leave them buggy or change the arch: lines to remove those buggy arches?
[14:34] <slyon> it's already a mismatch, so .. meh
[14:34] <cpaelzer> we do not really promote just some arches
[14:34] <slyon> I do not mean in promotion, but in the MIR test requirements
[14:34] <slyon> cc adrien
[14:37] <cpaelzer> I'm failing to find the test issues in the logs that are linked on libtracefs
[14:38] <dviererbe> o/
[14:38] <cpaelzer> I think if we not build this for ppc64 and s390x IBM and IBM users would be rather unhappy
[14:38] <sarnold> hi dviererbe
[14:38] <cpaelzer> the question is can it be fixed later
[14:38] <cpaelzer> or not
[14:38] <cpaelzer> is there new insight in that?
[14:38] <slyon> IMO we should still build it, but just accept ppc64el and s390x autopkgtest failing (for now) – to be fixed later
[14:39] <slyon> at least now we know that it's broken on ppc64el and s390x, whereas before (without tests) it was just broken
[14:39] <sarnold> https://autopkgtest.ubuntu.com/packages/libtracefs -- some fails here?
[14:40] <slyon> sarnold: we just have the superficial test in the archive, still. adrien added _actual_ tests in his PPA, but those fail on ppc and s390x
[14:40] <sarnold> ahh
[14:40] <cpaelzer> now things make sense again
[14:40] <slyon> see two latest comments on https://bugs.launchpad.net/ubuntu/+source/libtracefs/+bug/2051925
[14:40] -ubottu:#ubuntu-meeting- Launchpad bug 2051925 in libtracefs (Ubuntu) "[MIR] promote libtracefs as a trace-cmd dependency" [Undecided, Incomplete]
[14:40] <cpaelzer> I think under those conditions, and given the time let us promote it but please commit to continue working with upstream and IBM to fix it
[14:41] <slyon> we're on it already and it will show up in our usual proposed-migration report
[14:41] <slyon> adrien: Can you get the current tests uploaded into noble-proposed?
[14:41] <cpaelzer> yeah - and with then then promoting it
[14:42] <adrien> slyon: I'm preparing the MR right now
[14:42] <adrien> I'm also backlogging here (I arrived a minute ago)
[14:42] <slyon> cool, thanks. So let's move it to "In Progress" for now?
[14:42] <cpaelzer> it is already in mismatches
[14:42] <cpaelzer> so someone else would not understand why not fix comitted
[14:42] <slyon> oh right
[14:42] <adrien> I also updated the LP bug not long ago so some of you might have to refresh the page
[14:42] <cpaelzer> slyon: you might do a summary what we decided here as a comment
[14:43] <slyon> Will do.
[14:43] <cpaelzer> thanks
[14:43] <cpaelzer> Going on to get more cases discussed
[14:43] <cpaelzer> from the proposed mismatches
[14:43] <cpaelzer> python-boto3 and botocore and s3transfer
[14:43] <adrien> thanks
[14:43] <cpaelzer> I've done a review on all of them, but the cases were not yet fully ready for a post and since then I'm debugging the beta
[14:44] <cpaelzer> I can post my reviews in a bit, but here the TL;DR
[14:45] <cpaelzer> boto3 abd botocore are fine - they mostly lack tests which aciba is working on right now
[14:45] <cpaelzer> the important thing is that they replace something much worse
[14:45] <cpaelzer> the old version has been discontinued by upstream ages ago and isn't compatible with the python in noble
[14:45] <cpaelzer> So we have two options:
[14:46] <cpaelzer> remember: they are ok once the tests land, but need security review then
[14:46] <cpaelzer> a) schedule a security review, but let them in now
[14:46] <cpaelzer> b) do not promote them in time for noble
[14:46] <cpaelzer> I do not consider an asap review it the next hours a fair ask for @security
[14:47] <slyon> Is this a release blocker?
[14:47] <cpaelzer> my argument for (a) would be that all that is proposed while not yet having a review is replacing code that is much older and worse
[14:47] <slyon> I assume the issue is that we do not want to support the old unmaintained thing for 10+ years?
[14:47] <cpaelzer> it is a maintenance concern
[14:47] <cpaelzer> aciba: who joined works on it the last few days
[14:47] <slyon> I have a tendency towards (a) as well, but this is cutting corners with security review..
[14:48] <cpaelzer> it is not breaking the release, hence no strict blocker - but it would be much much better
[14:48] <cpaelzer> sarnold:  or eslerm_ what do you think about (a) vs (b)
[14:48] <sarnold> there's apparently some new code in here, too "Whilst looking at the package with Alberto, we found that python3-s3transfer, one of the boto3's runtime dependencies, is in Universe, too."
[14:48] <cpaelzer> yep, the old python-boto did it all by itself
[14:48] <cpaelzer> upstream broke that up in individual libs to do these things
[14:49] <sarnold> moving from boto to boto3 on its own isn't *too* worrying. I'm unhappy that this is only discovered this week but I can kinda understand how we got here. but dragging in a whole new s3 support layer is big ask in the final week.
[14:49] <sarnold> is this the old boto s3 support split out?
[14:49] <sarnold> does anything else use this s3 support?
[14:49] <cpaelzer> AFAICS boto3 and botocore are split out evolutions
[14:50] <cpaelzer> s3transfer is only used by boto
[14:50] <sarnold> do we actually care about s3 for simplestreams?
[14:50] <cpaelzer> in fact it is only considered to be useful in boto3 as they evolve together
[14:50] <sarnold> can we stub it out?
[14:50] <cpaelzer> aciba: ^^ ?
[14:51] <aciba> I think we can, I superficially grep cpc and mass code and they do not use it
[14:51] <cpaelzer> I assume the problem is that we might beak other users of that library if we'd remove s3 from boto3
[14:51] <aciba> but I am not 100% sure
[14:51] <sarnold> hmm. good point. sigh.
[14:51] <cpaelzer> all those three are the newer set of libs
[14:51] <cpaelzer> and it would allow to demote the old unmaintained one
[14:52] <cpaelzer> that is kind of what makes me suggest to let them in and demote the old
[14:52] <cpaelzer> and schedule but not wait for the security review
[14:52] <sarnold> iff you can do both operations in the same minute...
[14:52] <cpaelzer> the code isn't new - it is just universe -> main
[14:52] <cpaelzer> yeah - I can do both at once once ready
[14:52] <cpaelzer> waiting for the tests by aciba
[14:53] <cpaelzer> we'd like to get this out of proposed by ~tomorrow I'd assume to not be in the way of RC images
[14:53] <cpaelzer> aciba: can you get tests done by mid day tomorrow?
[14:53] <sarnold> I think I'm coming around to your way of thinking, but I'm not real keen on "just wait until the last week" being used as a way to get beyond the MIR process.
[14:53] <eslerm_> ^
[14:53] <cpaelzer> sarnold: I agree, but have no better option
[14:53] <aciba> I have 3 MRs up, adding build tests and autopkg test, I am verifying autopkgtest work
[14:53] <sarnold> cpaelzer: I mean, the kernel team had their kernels yanked from the upcoming release due to missing deadlines
[14:54] <aciba> I think I could, assuming I have someone reviewing, pushing to -proposed
[14:54] <cpaelzer> and they add it back as we speak
[14:55] <cpaelzer> I'm unsure - should we vote
[14:55] <cpaelzer> this isn't perfect and clean . otherwise we would have settled by now
[14:55] <cpaelzer> but even time for the meeting runs out :-/
[14:55] <sarnold> heh :(
[14:55] <cpaelzer> so to get conclusion on this non-easy case ...
[14:55] <sarnold> yeah, I'm fine with a vote
[14:56] <sarnold> but I'd like us to consider how to avoid this situation in future cycles
[14:56] <cpaelzer> I guess we can be sure that noboday wanted or planned for this
[14:56] <eslerm_> I would really like to see an unmaintained package leave main, otoh there is not time to review and s3 is something that certainly needs security review
[14:56] <cpaelzer> the problem is that simplestreams being in an ownership nimbus between teams
[14:57] <cpaelzer> Calling for a vote +1 to let it in under the mentioned constraints (add tests, schedule security review, follow up on findings) -1 to keep the deprecated old python-boto
[14:57] <cpaelzer> +1 (for a lack of a better option)
[14:57] <slyon> +1 (same)
[14:57] <sarnold> +1 (but grumpy about it)
[14:57] <eslerm_> +/- 0 (non-vote)
[14:57] <cpaelzer> joalif: didrocks: around?
[14:58] <joalif> sorry in other meeting as well, +1
[14:58] <cpaelzer> thanks
[14:58]  * cpaelzer is sad that there is nothing better
[14:58] <cpaelzer> but thanks for everyones understanding
[14:58] <cpaelzer> and thanks aciba to pick this up in the first place
[14:58] <cpaelzer> or we would not even have that option to discuss
[14:58] <aciba> thanks!
[14:58] <cpaelzer> aciba: I'll later complete and post my review
[14:59] <cpaelzer> and let you know if there is something big other than waiting for tests
[14:59] <sarnold> aciba: aye, yes, please don't take this personally. it's better to find and point it out. i'm just dissapointed that we didn't find this in the previous N cycles.
[14:59] <cpaelzer> I'd then bring it up in tomorrow daily release meeting
[14:59] <cpaelzer> to get an ack by release folks before moving it in (or killing it if they object)
[14:59] <aciba> sweet thanks. yeah, totally not taken as personally!
[14:59] <cpaelzer> so the target to be ready is 4pm CET
[15:00] <cpaelzer> I think we are out of time
[15:00] <cpaelzer> just quickly the lists ...
[15:00] <cpaelzer> #topic New MIRs
[15:00] <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
[15:00] <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:00] <cpaelzer> as I said all boto cases to me
[15:00] <cpaelzer> msgraph ?
[15:01] <slyon> I think that should be ready for promotion. See https://bugs.launchpad.net/ubuntu/+source/msgraph/+bug/2060035/comments/5 for the libgoa-* confusion
[15:01] -ubottu:#ubuntu-meeting- Launchpad bug 2060035 in msgraph (Ubuntu) "[MIR] msgraph" [Undecided, Confirmed]
[15:01] <slyon> We should actually drop the libgoa-* requirement instead, due to not being relevant anymore
[15:01] <cpaelzer> and security review in
[15:01] <eslerm_> also https://github.com/canonical/ubuntu-mir/issues/54
[15:01] -ubottu:#ubuntu-meeting- Issue 54 in canonical/ubuntu-mir "Remove libgoa from the upstream redflags" [Open]
[15:01] <cpaelzer> so state "in-progress" then?
[15:02] <cpaelzer> I didn't see it in mismatches
[15:02] <slyon> yes. Also needs a team bug-subscriber
[15:02]  * slyon adding a comment
[15:02] <cpaelzer> already done
[15:02] <slyon> ok
[15:02] <cpaelzer> #topic Incomplete bugs / questions
[15:02] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[15:02] <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:03] <cpaelzer> onyl the dmarc case
[15:03] <cpaelzer> which was the huge tree
[15:03] <cpaelzer> I'm afraid we can't change all in one day
[15:03] <cpaelzer> reading ...
[15:06] <eslerm_> I reached out to the developers concerning https://github.com/rjbs/Email-MIME/issues/66 but have not heard back
[15:06] -ubottu:#ubuntu-meeting- Issue 66 in rjbs/Email-MIME "DoS on excessive or deeply nested parts" [Open]
[15:07] <eslerm_> likely deserves a CVE regardless
[15:08] <cpaelzer> ran out of time and into concurrent meetings
[15:08] <cpaelzer> sorry
[15:09] <cpaelzer> let us skip docs and GH issues - not much there
[15:09] <cpaelzer> important to not miss if anyone was waiting might be
[15:09] <cpaelzer> #topic Any other business?
[15:09] <slyon> This is the libgoa-* issue: https://github.com/canonical/ubuntu-mir/issues/54
[15:09] <cpaelzer> no more special cases from me
[15:09] -ubottu:#ubuntu-meeting- Issue 54 in canonical/ubuntu-mir "Remove libgoa from the upstream redflags" [Open]
[15:09] <sarnold> of the list of packages at the end of comment 29 on Bug #2023971 only libemail-simple-perl wasn't in main already, and that's got a MIR ack
[15:09] -ubottu:#ubuntu-meeting- Bug 2023971 in libmail-dmarc-perl (Ubuntu) "[MIR] libmail-dmarc-perl" [High, Incomplete] https://launchpad.net/bugs/2023971
[15:09] <slyon> please everybody take a look after the meeting and give your feedback on GitHub.
[15:09] <eslerm_> libyuv needs a security reviewer still
[15:10] <sarnold> I completely forgot to do the nbd-client review from last week :( sorry.
[15:10] <slyon> eslerm_: on libyuv, Final Freeze should be fine as the latest possible deadline. vpa1977 is preparing the packaging changes in parallel
[15:10] <dviererbe> Is there any action needed from me for the seedchange of dotnet6/8 on mantic jammy?
[15:10] <sarnold> dviererbe: did you submit a merge request for the seed?
[15:10] <eslerm_> I'll see if we can get a reviewer assigned asap
[15:10] <slyon> eslerm_: thanks!
[15:11] <sarnold> https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=000b7f04d17867dd38b8f94f54d594aff4d274f1
[15:11] -ubottu:#ubuntu-meeting- Commit 000b7f0 in ~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu "Add dotnet8 to additional supported languages."
[15:11] <slyon> sarnold: yes we did that
[15:12] <slyon> It just needs an AA to promote it. (But it might be hidden from reports, due to being a retroactive promotion)
[15:12] <slyon> dviererbe: I assume poking AAs about it is your best bet
[15:12] <sarnold> aha, cool; that entire end of the world is pretty hazy :) i'm not sure what else was necessary, I just knew this step remained, hehe
[15:13] <sarnold> yeah, I think pop into #ubuntu-release and mention it and see if anyone's around
[15:14] <dviererbe> Oh.. sorry I see it is merged now. My last update was that it still needs review... waiting on AA then
[15:15] <slyon> dviererbe: waiting might not be enough, though. As the reports only show things about devel/noble. So it might need active pokes to make people look at it
[15:15] <didrocks> (back, waow a lot of backlog!)
[15:16] <sarnold> hey didrocks :)
[15:16] <didrocks> o/
[15:17] <sarnold> dviererbe: you may have missed: < slyon> dviererbe: waiting might not be enough, though. As the reports only show things about devel/noble. So it might need active pokes to make people look at it
[15:18] <sarnold> err, dviererbe1 rather ^^
[15:19] <slyon> sarnold: I'll forward that bit to him on internal channels .)
[15:19] <slyon> :)
[15:20] <dviererbe> sarnold: Okay poking an AA then. (My internet connection is currently not the best :/)
[15:20] <slyon> nvm
[15:20] <sarnold> heh yeah, ping timeouts from irc means something is in pretty bad shape, it's a very forgiving protocol :)
[15:21] <sarnold> my guess is this meeting has run its course, I propose we end it here :)
[15:22] <sarnold> 3
[15:22] <sarnold> 2
[15:22] <sarnold> 1
[15:22] <sarnold> #endmeeting
[15:22] <meetingology> Meeting ended at 15:22:07 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-04-16-14.32.moin.txt
[15:22] <eslerm_> o/
[15:22] <sarnold> thanks cpaelzer, all :)
[15:22] <slyon> thanks all! o/
[15:22] <didrocks> thanks! I’ll finish backlogging :)
[15:22] <dviererbe> Thanks everyone!
[15:22] <sarnold> good luck, hehe :)
[15:22] <aciba> thanks all!
[15:34] <cpaelzer> ok then
[15:34] <cpaelzer> engind
[15:34] <cpaelzer> #endmeeting
[15:34] <cpaelzer> nice, thanks sarnold for already doing it :-)
[15:34] <cpaelzer> these weeks should not be seen by a stress doctor :-)
[15:51] <adrien> I did some last minute cleanups for libtracefs so I'm going to give this another round of test to make sure I didn't introduce syntax errors
[15:55] <adrien> https://code.launchpad.net/~adrien-n/ubuntu/+source/libtracefs/+git/libtracefs/+merge/464434
[15:55] <adrien> and I'll call it EOD, at least until the PPA builds and the tests run