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