=== JanC_ is now known as JanC === cpaelzer_ is now known as cpaelzer === JanC is now known as Guest5729 === JanC_ is now known as JanC [14:31] hello [14:31] hello o/ [14:31] let us see if we reach critical mass for MIR team today [14:31] o/ [14:31] hello o/ [14:32] that looks good [14:32] #startmeeting Weekly Main Inclusion Requests status [14:32] Meeting started at 14:32:06 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] #topic current component mismatches [14:32] hola o/ [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:33] rustc on c-m-p looks new (pulling in new dependencies) [14:33] there is a master bug at the top of the perl tree [14:33] indeed rustc shows up as well [14:34] slyon: do you happen to know if this is being worked on already? [14:34] o/ [14:34] cpaelzer: I don't know, but I will clarify [14:34] thanks slyon [14:34] furthermore this upload was a bit hijacking the process by bundling all the code of the open cargo MIR IIRC [14:34] interesting ... [14:35] by that it (all the cargo) would go into main without being fully processed and approved [14:35] there have been pings flowing around [14:35] so shall we mark it "block-proposed" for now, until fully approved? [14:35] but IMHO we should not let the current one pass until this is sorted out [14:35] yeah [14:35] that is exactly what I wanted to lead the discussion to [14:36] I understand that this is the way you (=Foundation) want to go and I'm not even opposed. But all the bits and how they are tested, built, and updated needs to be clear [14:37] This has come up and seems to have gotten a comment here https://bugs.launchpad.net/ubuntu/+source/cargo/+bug/1993819 [14:37] -ubottu:#ubuntu-meeting- Launchpad bug 1993819 in dh-cargo (Ubuntu) "MIR: cargo, dh-cargo" [High, In Progress] [14:38] let me answer there [14:38] Yes, that'd be best. And I guess we'd also need an additional bug report against rustc (or maybe we add a rustc bugtask to the cargo MIR), to mark it block-proposed. [14:40] yeah, for now I said I'd want them to hold it back and assume they'll deal with it [14:40] ok, it seems clear this was a) unintended and b) shouldn't pass [14:41] from here we can see how this unfolds [14:41] #topic New MIRs [14:41] Mission: ensure to assign all incoming reviews for fast processing [14:41] #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:41] hehe, I see why jamespage has said hi today :-) [14:41] thanks cpaelzer ^ [14:41] yw [14:42] two to grab [14:42] 1. https://bugs.launchpad.net/ubuntu/+source/pydantic/+bug/2001699 [14:42] -ubottu:#ubuntu-meeting- Launchpad bug 2001699 in jaraco.text (Ubuntu) "[MIR] python-autocommand, python-inflect, pydantic" [Undecided, In Progress] [14:42] that is about jaraco which we have seen a while in component mismatches [14:42] thats me catching up on things at last [14:42] thanks [14:42] so it is two reviews actually [14:43] pydantic and python-inflect [14:43] AFAICS [14:43] and then the third is https://bugs.launchpad.net/ubuntu/+source/libmail-dmarc-perl/+bug/2023971 [14:43] -ubottu:#ubuntu-meeting- Launchpad bug 2023971 in libmail-dmarc-perl (Ubuntu) "[MIR] libmail-dmarc-perl" [Undecided, New] [14:43] which is - as mentioned above - actually many perl special cases [14:43] I'd try to do pydantic - that sounds fun [14:44] volunteers for inflect and one to (get started on) the perl chunk? [14:44] inflect was reviewed previous - [14:44] i can take inflect [14:44] shouldn't 2001699 have seperate MIRs for each package? [14:44] eslerm: no it was always ok to group if none of the cases was too complex [14:44] IIRC: only later we said we prefer (but not insist) on individual bugs [14:44] joalif: would you mind me taking inflect, as I did the previous review? [14:45] you could take pydantic instead [14:45] I think pydantic may need security review [14:45] slyon: ok [14:45] sorry joalif I didn't get it was reviewed before - just went by the state [14:46] thanks joalif, assigning [14:46] but jamespage we need to work out inflect [14:46] jamespage: it had two todos [14:46] 1. update (done) [14:46] cpaelzer: I don't think complexity is a factor ? https://github.com/canonical/ubuntu-mir/pull/15 [14:46] -ubottu:#ubuntu-meeting- Pull 15 in canonical/ubuntu-mir "require a single Launchpad bug for each MIR request" [Merged] [14:46] and 2. automated tests [14:47] eslerm: as I said "we have changed since" - it was ok in the past [14:47] ack, thanks [14:48] cpaelzer: jamespage: from a brief check it looks like the TODOs are addressed. But I'll do a full check [14:48] thanks slyon [14:49] I've assigned the two [14:49] and I've given bryce a few todos on libmail-dmarc-perl to split it out properly [14:50] then we can assign it next time [14:50] thx! [14:50] thanks eslerm for reminding me, i've updated a new bug to follow the new rule [14:51] but do we still need to split 2001699? [14:51] let me check if one of them has to go through the security queue (and thereby tooling) [14:51] bug #2001699 [14:51] -ubottu:#ubuntu-meeting- Bug 2001699 in jaraco.text (Ubuntu) "[MIR] python-autocommand, python-inflect, pydantic" [Undecided, In Progress] https://launchpad.net/bugs/2001699 [14:51] for me, it's _fine_ not to split as a one-off [14:51] ok, inflect does not go to security [14:52] we'll have to see what the outcome on pydantic is [14:52] thanks, time flies by - I'll go on to reach the later agenda stages ... [14:52] #topic Process/Documentation improvements [14:52] Mission: Review pending process/documentation pull-requests or issues [14:52] #link https://github.com/canonical/ubuntu-mir/pulls [14:52] #link https://github.com/canonical/ubuntu-mir/issues [14:53] slyon: is https://github.com/canonical/ubuntu-mir/pull/27 good for your questions [14:53] -ubottu:#ubuntu-meeting- Pull 27 in canonical/ubuntu-mir "Document a possible symbols exception for c++ libraries" [Open] [14:53] it still fails the spellchecker ... [14:53] * slyon looking.. [14:54] the spellchecker failure is the job having limitations [14:54] dviererbe: is https://github.com/canonical/ubuntu-mir/pull/23 stuck as WIP (and should we mark it that way) ? [14:54] -ubottu:#ubuntu-meeting- Pull 23 in canonical/ubuntu-mir "Modernize Process States Overview" [Open] [14:54] dviererbe: or is that ready for re-consideration [14:54] It is ready [14:54] abi and SOVER are technical acronyms and not wrong english [14:54] cpaelzer: #27 LGMT, will add a comment [14:55] thanks slyon [14:55] seb128: that is correct, but we land changes to the spellchecker along the PRs that break them [14:55] dviererbe: ok, I'll need to re-review it then ... [14:55] nice, thank you [14:56] dviererbe: would you want to be a helping hand and provide a spellcheck PR that makes #27 work [14:56] I can do that :) [14:56] then we could merge #27 and yours [14:56] awesome [14:56] let us have a look at security queues [14:56] thanks! [14:56] #topic MIR related Security Review Queue [14:56] Mission: Check on progress, do deadlines seem doable? [14:56] Some clients can only work with one, some with the other escaping - the URLs point to the same place. [14:56] #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:56] #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:56] Internal link [14:56] - ensure your teams items are prioritized among each other as you'd expect [14:56] - ensure community requests do not get stomped by teams calling for favors too much [14:57] #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 [14:57] On the last note: What is SOVER? [14:57] version of a shared object [14:57] ah.. ok, thanks! [14:57] dviererbe: .so ABI version of a shared library [14:58] in too simplified terms the number at libfoo [14:58] Always funny how many abreviations ubuntu has ^^ [14:59] it is part of SONAME (which we might want to allow-list, too) [14:59] ack [14:59] sarnold: eslerm: in the past the perl packages that were trivial (just wrappers around the module including tests and all) got a fast pathed by Doko. Did those went through security review, at least when they processed potentially external data? [14:59] oh this is actually already the next agenda entry [14:59] the security queue LGTM, so I think we can go on to that [15:00] #topic Any other business? [15:00] I don't believe there is much to update on security's side. Seth is out. Plans to assign cargo may be delayed, dontnet6 conversation is starting, and codecs are being weighed [15:00] cpaelzer: I'd wait to ask Seth [15:00] ack on that [15:00] oh yeah, you mention dotent6 - I've doen the review and it is massive [15:00] but for that was actually fine [15:00] as a FYI the gtkmm stack should be ready now, we added symbols enforcing for a group of selected architectures [15:01] quite a list of questions and required tasks, but better than I expected \o/ [15:01] thanks seb128, are there cases for us to recheck and ack? [15:01] if so we haven't seen them today [15:01] iiuc, Seth and Ian will sync on dotnet6 [15:01] great eslerm [15:01] seb128: Maybe they are still in "incomplete" state? [15:01] cpaelzer, I think they are in the normal process so should be picked up again by the reviewers [15:02] checking one (as example) - https://bugs.launchpad.net/ubuntu/+source/gtkmm4.0/+bug/2020472 [15:02] -ubottu:#ubuntu-meeting- Launchpad bug 2020472 in gtkmm4.0 (Ubuntu) "[MIR] gtkmm4.0" [Undecided, Incomplete] [15:02] there is no "reviewer" anymore [15:02] I will check with Jeremy [15:02] jbicha, ^ [15:02] the process hand them back to the reporter - and the expectation is "set incomplete -> new once ready for a look again" [15:03] that would have been seen in our queue each week [15:03] and then probably got a quick pass as they indeed LGTM on a glance [15:03] right, I though Jeremy was going to do that before the meeting but he didn't, they will be back to review by next meeting [15:03] if you can wait until next week, just fix the state and it will be done [15:03] if not, fix the state and ping me and I'll check them in between [15:03] ack, will do, thanks [15:03] also as a FYI I plan to start a discussion about the current policy of nacking hardware enablement related packages when we don't have access to the hardware [15:03] cpaelzer: glibmm2.68 is ready. I will update the others tomorrow [15:04] puh, only 3 minute over today :-/ [15:04] thank you all [15:04] haha, those meetings are getting longer these days :) [15:04] I think that just hurt Ubuntu for no valid reason [15:04] seb128: which hurts? [15:04] well not valid ... let's say that the tradeoff is in our disfavor [15:04] we can wait on gtkmm4 and friends until next week though [15:04] cpaelzer, bugs like https://bugs.launchpad.net/ubuntu/+source/libqrtr-glib/+bug/1963707 [15:04] -ubottu:#ubuntu-meeting- Launchpad bug 1963707 in libqrtr-glib (Ubuntu) "[MIR] libqrtr-glib" [Low, Incomplete] [15:05] I've some new cases in pipewire [15:05] an extra library needed to support firewire audio devices [15:06] but it's going to end up in the same case, our team doesn't own the hardware and doesn't have budget to buy some [15:06] Maybe we'd need some kind of community testing process? To involve external people that actually have the hardware to run some test plans? [15:06] meanwhile we fall behind other distros in term of hardware which is working on our platform [15:06] We had too many cases where people just even bothered to try to test, but this really wasn't meant to block things entirely. We might need to revisit that. [15:07] It seems Desktop in particular is victim of "special HW" cases [15:07] slyon, we can try, in practice finding people to verify updates is hard [15:07] and unreliable [15:07] they might show and then disappear [15:07] yes. But might be better than doing no testing at all. [15:07] anyway, I will open a ticket on github about that [15:08] thanks, sounds good! [15:08] I think this is a problem were all of us see both bad outcomes - we neither want to deny or fall behind. But neither do we want to accept untestable things in main, since a fair question is how you'd think you ever support those. [15:08] It is clearly worth a call up on an Issue and potentially there to a higher place to decide [15:09] ack [15:10] * cpaelzer forecasts that this will need to be converted to a mail to the TB, but please start the discussion as GH issue and we'll work on it together from there [15:10] will do [15:10] seb128: if I might suggest, this might be worth a mid-cycle sprint breakout - potentially even including release team / sru team and sabdfl (depending on how ready the state of the discussion is by then) [15:11] I'll end this meeting here today [15:11] for the record I don't see why that would need the TB, we used to have more flexibility in our promotion process [15:11] the recent strictness of the review is coming from this team afaik [15:11] and maybe include certlab people, too. [15:11] short summary before I call an end [15:11] 1. we used to be flexible [15:11] 2. people have been living in pain to support/test things [15:12] 3. quality assurance part of the Mir process was upped to avoid that [15:12] 4. now you rightfully challenge the other side of this decisions consequence [15:12] Maybe not TB, but as you mentioned it seems to be "do we put it to main (which implies guarantees) without being able to test it"? or "do we allocate budget to be able to test it" [15:13] the strictness has come from this team for the reason of ensuring quality in Ubuntu [15:13] but I agree it shouldn't render you unable to do anything [15:14] hence we might need to bring it up [15:14] alright, well let's follow the logic steps, I will start with the github ticket [15:14] thank you [15:14] thanks! [15:14] #endmeeting [15:14] Meeting ended at 15:14:52 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-07-04-14.32.moin.txt [15:15] thanks! [15:15] cpaelzer: The PR adding spellchecker terms is here: https://github.com/canonical/ubuntu-mir/pull/29 [15:15] -ubottu:#ubuntu-meeting- Pull 29 in canonical/ubuntu-mir "Add spellchecker terms" [Open] [15:15] thanks all o/ [15:15] thanks! o/