== Meeting information == * #ubuntu-meeting: Weekly Main Inclusion Requests status meeting, started by cpaelzer, 28 Jun at 14:33 — 14:56 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-06-28-14.33.log.html == Meeting summary == === current component mismatches === Discussion started by cpaelzer at 14:33. * ''LINK:'' https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg (cpaelzer, 14:33) * ''LINK:'' https://people.canonical.com/~ubuntu-archive/component-mismatches.svg (cpaelzer, 14:33) === New MIRs === Discussion started by cpaelzer at 14:38. * ''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 (cpaelzer, 14:38) === Incomplete bugs / questions === Discussion started by cpaelzer at 14:38. * ''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 (cpaelzer, 14:38) * ''LINK:'' https://bugs.launchpad.net/ubuntu/+source/ipmitool/+bug/1978144 (cpaelzer, 14:39) * ''LINK:'' https://bugs.launchpad.net/ubuntu/+source/libisofs/+bug/1977959 (cpaelzer, 14:40) === MIR related Security Review Queue === Discussion started by cpaelzer at 14:43. * ''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 (cpaelzer, 14:43) * ''LINK:'' https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 (cpaelzer, 14:44) === Any other business? === Discussion started by cpaelzer at 14:46. * ''LINK:'' https://github.com/cpaelzer/ubuntu-mir/pull/3/files (cpaelzer, 14:47) == People present (lines said) == * cpaelzer (89) * slyon (30) * didrocks (15) * sarnold (10) * ubottu (6) * joalif (3) * meetingology (2) == Full log == 14:33 #startmeeting Weekly Main Inclusion Requests status 14:33 Meeting started at 14:33:09 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology 14:33 Available commands: action, commands, idea, info, link, nick 14:33 Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage 14:33 most of you are here already, just me being slightly late due to head to head meetings - sorry :-/ 14:33 #topic current component mismatches 14:33 Mission: Identify required actions and spread the load among the teams 14:33 #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg 14:33 #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 14:33 let us see what this week has new for us 14:34 nothing in non-proposed 14:34 but a lintian explosion in -proposed 14:34 ugh lintian... they're adding new dependencies quicker than we can process them :) 14:34 lintian got a new maintainer upstream and I think there was a big re-organization of the code 14:34 or.... hooray for more automated checking :) (I hope) 14:34 which is all great, but paingul 14:34 slyon: a question, is there a strong resaon it needs to be in main 14:34 I'll check those new dependencies. and assign them out within foundations, as needed 14:34 slyon: it does not have to be as a build-dependency 14:35 perlpainful even :p 14:35 cpaelzer: yeah.. we had that discussion during the Frankfurt sprint. But there were some strong opinions about keeping it in main 14:35 I can lookup the details if you want to 14:35 ok, then you said it right -sort out the MIRs on your end and file them 14:35 just wanted to ask to be sure 14:36 the rest are known false positives 14:36 or cases waiting for review 14:36 openwsman? 14:36 sarnold: that whole maas seed thing is there forver and not changing 14:37 it is aphilospohopy questions, someone decided to declare a seed as maas uses those, but no one stepped up owning and promoting the packages 14:37 aha. it felt vaguely familiar but I didn't see openwsman in /lastlog. this should do for another few months then.. heh 14:37 it is a very special case of false positives 14:37 TBH all cases that are up are in the security queue 14:37 so you can clear this view a lot sarnold :-P 14:38 #topic New MIRs 14:38 Mission: ensure to assign all incoming reviews for fast processing 14:38 #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:38 none 14:38 \o/ 14:38 really, I thought I have seen one in my inbox this week 14:38 let me see if it shows up in incomplete 14:38 #topic Incomplete bugs / questions 14:38 Mission: Identify required actions and spread the load among the teams 14:38 #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:39 a few updates on those 14:39 https://bugs.launchpad.net/ubuntu/+source/ipmitool/+bug/1978144 14:39 Launchpad bug 1978144 in ipmitool (Ubuntu) "[MIR] ipmitool" [Undecided, Incomplete] 14:39 was reviewsed by joalif 14:39 looks good a few todos for the team, soon to be handled 14:39 we can assign this to security already IMHO 14:39 as we usually do 14:39 so this needs sec review 14:40 Lena will add the test details while that is hanging in the sec queue 14:40 but I didn't know if i shoudl assign it to them before the todos are done 14:40 yes joalif, I assigned security now 14:40 ah ok 14:40 https://bugs.launchpad.net/ubuntu/+source/libisofs/+bug/1977959 14:40 Launchpad bug 1977959 in libisofs (Ubuntu) "[MIR] libisoburn, libburn, libisofs" [Undecided, Incomplete] 14:40 this goes on between slyon and alexghiti 14:40 I think slyon kept in sync with his time 14:40 team* 14:40 actually: 14:41 ? 14:41 this is a question for didrocks: 14:41 about the .symbols file 14:41 (I agree about the no additional delta if we can’t get it sponsored to debian) 14:41 if that was your question :p 14:41 I think we do not want to block on this here. as they're using the "-V" parameter 14:42 yeah, I agree, but can we try to get them in debian still? 14:42 i.e. dh_makeshlibs -V 14:42 Yes, I feel like it should be sent to Debian, but no need to inroduce a Ubuntu delta, right? 14:42 ack 14:42 right, this is what I just wrote ^ 14:42 ok, thanks for clarification 14:43 Then we have https://bugs.launchpad.net/ubuntu/+source/gsasl/+bug/1972866 14:43 I will talk to Alex, he's out currently, though 14:43 Launchpad bug 1972866 in gsasl (Ubuntu) "[MIR] gsasl" [Undecided, Incomplete] 14:43 slyon: just to ensure this is done, forwarded, but ack then. I’ll let you finish syncing with your team 14:43 good :) 14:43 this goes on in discussion - so far mostly about nothing yet testing it AFAICS 14:43 nothing to act for us right now 14:43 #topic MIR related Security Review Queue 14:43 should this be set to "New"+security? 14:43 Mission: Check on progress, do deadlines seem doable? 14:43 #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:43 Internal link 14:44 - ensure your teams items are prioritized among each other as you'd expect 14:44 - ensure community requests do not get stomped by teams calling for favors too much 14:44 #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 14:44 I think foundations' part is done on gsasl 14:44 yes slyon 14:44 will do cpaelzer 14:44 set 14:44 thx 14:44 I could ask, but I ask the same thing every week sarnold - so I'm not asking this week 14:44 but the list is huge again :-/ 14:45 * cpaelzer hugs sarnold for review-pain 14:45 Does anyone have other teams inout on the security queue or its handling atm? 14:45 s/inout/input/ 14:46 I guess that is a "no by timeout" 14:46 there was little progress last week due to a security sprint, which was excellent -- and I expect little this week, as most of my colleagues are on vacation this week and much of next week; however, we had good discussions on performing MIRs, the new folks who have taken some are keen, and I'm still feeling happy thoughts :) 14:46 oh great 14:46 so it seems we can hope that this isn't just on your shoulds soon then 14:46 yes 14:46 great 14:46 #topic Any other business? 14:47 none here 14:47 I have a heads up on https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 14:47 Launchpad bug 1942394 in mdevctl (Ubuntu) "[MIR] mdevctl 1.0.0 (rust switch)" [Undecided, Incomplete] 14:47 this ties into the rust rules that we have discussed a while ago 14:47 https://github.com/cpaelzer/ubuntu-mir/pull/3/files 14:47 Pull 3 in cpaelzer/ubuntu-mir "Add rust rules" [Open] 14:47 I will soon have to rebase and re-propose that to land it 14:47 because we have it almost ready in the form that was suggested 14:47 there are things which we need to reconsider 14:48 for example cargo.lock isn't yet done by the dh_cargo tooling, until it exists one can not provide it 14:48 there are fallbacks in our proposed ruling which we will use 14:48 so far just an FYI so you know it comes 14:48 and sadly the wiki has become immutable again 14:48 nice, thanks 14:48 nothing else from my side 14:49 I have once question wrt my last comment on https://bugs.launchpad.net/ubuntu/+source/lerc/+bug/1977551 14:49 Launchpad bug 1977551 in lerc (Ubuntu) "[MIR] lerc" [Undecided, New] 14:49 do we require the build to fail on .symbols file changes? 14:49 on breaking symbols change IIRC yes 14:49 the MIR rules state that symbols tracking needs to be in place 14:49 not on just adding new symbols 14:49 lerc is tracking symbols, but ignoring the changes during build 14:49 (only to be checked manually) 14:49 cargo.lock missing from dh_cargo :( -- do we need to ask our rust experts to help push that over the finish line? 14:50 * didrocks likes to use level 4 as discussed the other days, but it’s more a personal preference on package I used to maintain directly 14:50 sarnold: (rust) yes, but I'd decouple the MIR rules and any ongoing package from that. Once it exists it shall be used, but until it does we can't require it 14:50 I think though that yeah, only on removing symbols (even if adding symbols can break in C++) 14:50 didrocks: ACK, thanks for your input on this one! maybe we don't need to be as strict in the generic rules. 14:51 But I'll ask seb to introduce a delta to make the build fail on symbols changes 14:51 slyon: it should fail on removing a symbol - if it does that it is ok IMHO 14:51 cpaelzer: I'm afraid if we go down that path we'll eventually have a dozen packages in, and no support, and no incentive to get it done.. 14:51 sarnold: and if we don't we can't update more and more waiting on the dh_cargo feature to exist 14:51 cpaelzer: I agree on this. So we need to patch lerc, as the maintainers do not want this, due to it being too much work for C++ libraries with lots of generated symbols names 14:52 that might change on toolchain changes 14:52 slyon: I'm really only having a soft opinion here - I do not maintain much C++ 14:52 it feels odd to add delta just for that 14:52 hmm 14:52 if you want to be scared on how you can break the ABI in C++: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B 14:53 and you see that removing symbols is not the only way to break it :p 14:53 (but I think good enough for most of the cases) 14:53 sarnold: (rust) so yes, let us hard-request that from dh-cargo asap - but allow some way to make progress in between 14:54 cpaelzer: (rust) yes, that can make sense -- but I'm really only comfortable allowing the first if we also have a resourced plan to get to a better dh_cargo situation 14:54 (c++ symbols) IMO it makes sense to rather be on the safe side and check/adopt .symbols after toolchain changes, rather than missing a ABI break 14:55 ack 14:55 that is the way to go then slyon 14:55 thanks. nothing else from my side 14:56 ok, that sounds like a wrap then 14:56 thanks cpaelzer, all :) 14:56 thank you all 14:56 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)