=== athos_ is now known as athos [13:59] o/ [14:17] slyon: no meeting today? [14:17] schopin: ~10 min to go (I was a bit early apparently :)) [14:31] hiho [14:31] getting started [14:31] hey [14:31] hello o/ [14:32] hey! [14:32] arr [14:32] good morning [14:32] other meeting closed [14:32] opening the guide ... [14:33] #startmeeting Weekly Main Inclusion Requests status [14:33] Meeting started at 14:33:07 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 ( eslerm dviererbe ) [14:33] glad to be back after the sprint [14:33] I hope there was no panic here [14:33] It was pretty calm [14:33] let us get the normal agenda points covered [14:33] and then get to any open things left in AOB [14:33] thanks slyon [14:33] #topic current component mismatches [14:33] Mission: Identify required actions and spread the load among the teams [14:34] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:34] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:34] mirespace still supposed to work on the MIR of the perl deps [14:34] let me ping here again [14:34] Those look pretty usual, except for dnspython, which was resolved today and will go away. [14:34] sorry for this overview not being readable again [14:35] is it the same [14:35] Also, python-jsonschema is growing some more Recommends (cc jamespage) [14:35] I do not remember python-jsonschema [14:35] to python-rfc3987 and webcolors [14:35] oh yeah [14:35] good [14:35] so it was not just my memory [14:35] Tue 01 14:32:59 < slyon> python-jsonschema seems new, and needs to be looked at by the openstack team (cc jamespage) [14:36] oh, so there was no reply since [14:36] let me do the same ping on #openstack internally to ensure they see it [14:36] might have been lost in the sprint [14:37] done [14:37] TIL: interestingly the Recommends (as in python-jsonschema case) are not enforced by britney, so that package migrated, even though it has component mismatches [14:37] that is ... unexpected [14:38] did you talk last week about python-reportlab? [14:38] according to v_orlon this has been the case ever since [14:38] cpaelzer: yes. reportlab is going to be demoted this cycle (once the desktop team demoted the printing stack) [14:38] heh, maybe https://bugs.launchpad.net/britney/+bug/1593148 ought to get a priority boost? [14:38] ok, waiting for that then [14:38] -ubottu:#ubuntu-meeting- Launchpad bug 1593148 in britney "trigger tests for reverse-recommends dependencies" [Low, Triaged] [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] wow [14:38] nice [14:38] for once! [14:39] #topic Incomplete bugs / questions [14:39] Mission: Identify required actions and spread the load among the teams [14:39] #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] so slyon commented on s390x tools [14:39] (from components, is rustc still an approved MIR?) [14:39] eslerm: it can only find and color one [14:39] so it finds the old rustc [14:39] thanks [14:39] not the new cargo+rustc one [14:40] ok I see that Mirespace worked on https://bugs.launchpad.net/ubuntu/+source/libmail-dmarc-perl/+bug/2023971 recently [14:40] -ubottu:#ubuntu-meeting- Launchpad bug 2023971 in libmail-dmarc-perl (Ubuntu) "[MIR] libmail-dmarc-perl" [Undecided, Incomplete] [14:40] not ready yet but that update is expected [14:40] what is https://bugs.launchpad.net/ubuntu/+source/dhcpcd/+bug/2019191 about ... ? [14:40] -ubottu:#ubuntu-meeting- Launchpad bug 2019191 in dhcpcd (Ubuntu) "[MIR] dhcpcd" [Undecided, Incomplete] [14:40] s390-tools is a heads-up for everybody. It will start to pull in vendored rust dependencies. And it was not super clear how to handle them from a MIR/security perspective. Do we need a new MIR? [14:40] cc schopin ^ [14:40] cc fheimes ^ [14:40] hmm, we didn't add re-MIR in the past [14:41] * schopin pops his head in. [14:41] but this is a rather big change [14:41] I think they can ask for acceptance and re-review on the old MIR bug [14:41] I created that bug, to have some starting point for a discussion [14:41] but I'm not sure about it [14:42] sarnold: what's your perspective on packages in main pulling in new (vendored) dependencies? [14:42] IMHO (and that really is opinion for now) - they should re-review, but we haven't put re-review of any kind in-process yet [14:42] would it be a normal package dependency, we would probably handle it through the component-mismatches process and have all of the dependencies MIRed [14:43] mostly to avoid people getting things approved while trivial and then exploding complexity without ensuring quality and maintainability [14:43] we normally assume that some reasonable amount of changes over time are just going to happen, and that's fine, but this sounds like it might be a pretty big set of changes. maybe we ought to try to use 'package churn' as a guide for our "re-review old packages" stretch goal? [14:43] slyon: do they have to be vendored? [14:43] this seems to be a meta package https://github.com/ibm-s390-linux/s390-tools [14:43] The MIR rules state that they do :) [14:43] cpaelzer: Probably yes. Those are rust crates [14:44] .. and maybe at the birth of a new ecosystem is a good time to try to encourage 'good taste' in selecting which crates to vendor? not that we've got *that* much influence over upstream authors.. [14:44] This specific upstream should be easier to work with than most. [14:44] yeah [14:45] But then there's the issue of the *version* of the crates we want them to use. [14:45] yep the rules were written with the ecosystem of the time in mind [14:45] So we basically ask for a new s390-tools MIR and will see what that brings (I expect lots of work, as those are big crates) [14:45] and since the goal is to get it to compile with the new tools, today, on an oddball architecture, they'll have a very strong incentive to make sure it actually works in the places where rust feels weakest [14:46] slyon: yes, that would be helpful I think [14:46] let us continue for now [14:46] and to close this section out, dhcpcd - is that the one you meant will resolve in a bit slyon? [14:47] no. I was talking about dnspython [14:47] oh [14:47] so laste ocmment on https://bugs.launchpad.net/ubuntu/+source/dhcpcd/+bug/2019191 [14:47] -ubottu:#ubuntu-meeting- Launchpad bug 2019191 in dhcpcd (Ubuntu) "[MIR] dhcpcd" [Undecided, Incomplete] [14:47] dhcpcd is probably waiting on tobias to replace non-fips-approved code with fips-approved-code [14:47] yeah, thanks for cleaning up the assignment [14:47] to make it clear who we wait on [14:48] (schopin I will tag bug #2030482 as rls-mm-incoming, so we can assign the MIR to somebody in the next ubuntu-meeting) [14:48] -ubottu:#ubuntu-meeting- Bug 2030482 in s390-tools (Ubuntu) "[MIR] s390-tools Rust dependencies (vendored)" [Undecided, Incomplete] https://launchpad.net/bugs/2030482 [14:48] fair enough :) [14:48] #topic MIR related Security Review Queue [14:48] Mission: Check on progress, do deadlines seem doable? [14:48] Some clients can only work with one, some with the other escaping - the URLs point to the same place. [14:48] #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:48] #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:48] Right. I should probably ping tobhe and/or bdrung about dhcpcd [14:49] Internal link [14:49] - ensure your teams items are prioritized among each other as you'd expect [14:49] - ensure community requests do not get stomped by teams calling for favors too much [14:49] #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 [14:49] initial libmysofa MIR is in review. We need upstream followup to decide on promotion--reviewer on PTO. dropping libmysofa-utils from promotion would help. @seb128 [14:49] libwebm and nvme-stas MIRs are drafted and in review. likely to be published this week [14:49] dasbus will be taken when nmve-stas is complete [14:49] dotnet6 MIR s in progress [14:49] Security's fdk-aac review is blocked downstream, Desktop may have an alternative package to promote [14:50] that all sounds fine IMHO - thanks for the update. Anything else to add sarnold or anyone? [14:50] eslerm: do we get our ETA for rust/cargo today? [14:50] slyon, i talked with tobhe yesterday. He will prepare the patches for using openssl that I can hopefully upload today or tomorrow. [14:50] bdrung: sounds great, thanks [14:50] great, thanks for the info bdrung [14:50] yes, cargo MIR draft is complete and in review as of today [14:50] slyon: one better :) pfsmorigo has posted a review for review :) it's on us to take a look and iterate on it [14:50] I was shuffling agenda items unintentionally [14:51] #topic Process/Documentation improvements [14:51] Mission: Review pending process/documentation pull-requests or issues [14:51] #link https://github.com/canonical/ubuntu-mir/pulls [14:51] #link https://github.com/canonical/ubuntu-mir/issues [14:51] as I posted https://github.com/canonical/ubuntu-mir/pull/31 can land now [14:51] -ubottu:#ubuntu-meeting- Pull 31 in canonical/ubuntu-mir "Clarify options in case special-HW is needed" [Open] [14:51] everyone that might later complain has approved [14:51] \o/ [14:51] anyone wants to use the last change of stopping me? [14:52] 3 [14:52] 2 [14:52] uhoh, is this the "supervillian transformation moment"? :) [14:52] 1 [14:52] hehe [14:52] is this AOB? [14:52] no [14:52] not yet jbicha [14:52] this is the issue/Pr section [14:52] merged [14:52] how about https://github.com/canonical/ubuntu-mir/pull/33 ? [14:52] -ubottu:#ubuntu-meeting- Pull 33 in canonical/ubuntu-mir "Guide how to check nobody/suid rules" [Open] [14:53] did we settle enough on this [14:53] spelling is fixed [14:53] and I thought most of the discussion should be in [14:53] I'm context switching in this case ... [14:54] didrocks: I think your comment is the only one I have not yet addressed [14:54] the package build log note was a nice one [14:54] oh actually I think I have added binary and source [14:54] yes [14:54] https://github.com/canonical/ubuntu-mir/pull/33/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R881 [14:54] -ubottu:#ubuntu-meeting- Pull 33 in canonical/ubuntu-mir "Guide how to check nobody/suid rules" [Open] [14:54] didrocks: are you fine as well then? [14:55] cpaelzer: that’s correct, I would have preferred we dig a little bit deeper in it: but TBH, no time for this… So good enough as is [14:55] I didn't want to explode complexity [14:55] PRs welcome :-P [14:55] let us merge it then and anyone is free to extend at another day [14:55] ok? [14:55] understandable :) [14:55] ack [14:56] done [14:56] then last new before AOB [14:56] https://github.com/canonical/ubuntu-mir/issues/35 [14:56] -ubottu:#ubuntu-meeting- Issue 35 in canonical/ubuntu-mir "RFC: Introduce 'base-sets' for vendored dependencies" [Open] [14:56] I think this is a good topic to have [14:56] but breaking the time we have [14:56] ^ This is something I was thinking about today. [14:56] can we declare review and discussion homework until next week? [14:56] Not necessarily needed right now. But maybe everybody could have a look eventually and leave their comments [14:57] I've added it to my "to review" list [14:57] thanks for starting the thought [14:57] cc schopin, too ^ [14:57] #topic Any other business? [14:57] jbicha: now :-) [14:57] nothing from server this week btw [14:58] https://gitlab.freedesktop.org/libinput/libei will be a new dependency for Mutter 45 for Desktop so I'm letting y'all know that will be a rush and coming soon [14:58] mmm eis [14:58] jbicha: what is your gut-feeling on quality of it? [14:59] libEgg :-) [14:59] thanks for the heads up [14:59] jbicha: we can usually do promotions post feature freeze. So as long as you can get your changes in (e.g. using FFe), we should still have some time. But that's for the heads-up! [14:59] jbicha: you can file this asap even before the dependency is there [14:59] so that we can start to review next week [15:00] ok, anything else - or can we close? [15:00] thanks* [15:00] 5 [15:00] 7 [15:00] 8 [15:00] nothing here [15:00] #endmeeting [15:00] Meeting ended at 15:00:21 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-08-08-14.33.moin.txt [15:00] thank you all [15:00] thanks everyone! [15:00] but I kinda want some eis now :) [15:00] bye all o/ [15:00] this consumes all time regularly [15:00] thanks cpaelzer, all :) [15:00] hmmm :-/ [15:00] thanks! o/ === bdmurray_ is now known as bdmurray [19:00] o/ [19:00] o/ === amurray_ is now known as amurray [19:04] I guess we're missing a few members, but I don't see anything new on the agenda [19:04] Just the usual items [19:05] yeah [19:09] I guess let's try again in a couple weeks time [19:32] Oh sorry I was expecting this to be half past the hour for some reason [19:32] I think I had it confused with a different meeting that does that :-/