=== JanC_ is now known as JanC [14:31] late just a bit [14:31] good morning [14:31] o/ [14:31] hey [14:32] heyho o/ [14:33] ok getting ready ... [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 [14:56] Meeting ended at 14:56:57 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-06-28-14.33.moin.txt [14:57] thanks cpaelzer, all! [14:57] thanks all! [14:57] thanks all