=== JanC_ is now known as JanC === JanC_ is now known as JanC === JanC_ is now known as JanC === cpaelzer_ is now known as cpaelzer [14:30] huhu [14:30] Hello o/ [14:30] hello [14:30] good morning [14:31] #startmeeting Weekly Main Inclusion Requests status [14:31] Meeting started at 14:31:03 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology [14:31] Available commands: action, commands, idea, info, link, nick [14:31] Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) [14:31] we already got a few "hello" before the meeting (and thereby the log) started [14:31] hi everyone [14:31] hey [14:31] o/ [14:31] Mantic is rather active now, let us get this started [14:31] #topic current component mismatches [14:31] Mission: Identify required actions and spread the load among the teams [14:31] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:31] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:31] o/ [14:32] wow [14:32] lol love all the arrows on nvidia* [14:32] nvidia-graphics-drivers-530 looks funny [14:32] but no work for us there [14:32] transmission still has stubs [14:32] nothing to act yet on that [14:32] jaraco is going on still [14:33] the rest are known false-positives IIRC [14:33] sounds about right [14:33] #topic New MIRs [14:33] Mission: ensure to assign all incoming reviews for fast processing [14:33] #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:33] one new https://bugs.launchpad.net/ubuntu/+source/libmysofa/+bug/2019951 [14:33] -ubottu:#ubuntu-meeting- Launchpad bug 2019951 in libmysofa (Ubuntu) "[MIR] libmysofa" [Undecided, New] [14:34] weird name, but reasonable use [14:34] spatial audio [14:34] looking for a reviewer [14:34] I’m happy to get it in our next pulse [14:34] I'm still on dhcpcd from last week, that is a bit bigger than I assumed [14:34] next pulse means starting monday didrocks? [14:34] the 05 June [14:34] that should still be ok [14:34] thanks for volunteering [14:34] I think so [14:35] I'm sure you'll have your fun criticizing missing tests [14:35] (with the amount of specs I’m writing, the current pulse is already too booked to be completed) [14:35] understandable [14:35] I’m sure seb128 is already waiting for it :) [14:35] he now sees a name who to ping if needed [14:35] #topic Incomplete bugs / questions [14:35] Mission: Identify required actions and spread the load among the teams [14:35] #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:35] wow [14:36] so many recent updates [14:36] hello new gtk? [14:36] indeed [14:36] but yet incomplete [14:36] let us wait until they get all the ducks in a row [14:36] agreed [14:36] probably up for reivew in a while [14:36] ... good thing they have duktape :) [14:37] too many "mm" in the names, not really looking forward to doing c++ :p [14:37] the one without mm has c++ in the name :-P [14:37] lol [14:37] anyway, ok for today [14:37] but kind of a heads up what is coming [14:37] #topic Process/Documentation improvements [14:37] Mission: Review pending process/documentation pull-requests or issues [14:38] #link https://github.com/canonical/ubuntu-mir/pulls [14:38] #link https://github.com/canonical/ubuntu-mir/issues [14:38] (I like that this is an official topic now) [14:38] me too :) [14:39] indeed [14:39] ci: add automated spell checking [14:39] https://github.com/canonical/ubuntu-mir/pull/19 [14:39] -ubottu:#ubuntu-meeting- Pull 19 in canonical/ubuntu-mir "ci: add automated spell checking" [Open] [14:39] the PR on the MIR process still waits on me to create a tool to query [14:39] that will take a while [14:39] but the contribs of dviererbe are ready IMHO [14:39] I looked at them before [14:39] have a look at his link [14:39] and also at https://github.com/canonical/ubuntu-mir/pull/18 which is the direct result [14:39] -ubottu:#ubuntu-meeting- Pull 18 in canonical/ubuntu-mir "fix small typos" [Open] [14:40] I really like that and would merge, it it fails we can undo it - but it LGTM [14:40] maybe squash, but I'm agnostic [14:40] I'd keep them as is [14:40] yeah, it look all good :) (I like separate commits though) [14:40] commits are not costly here [14:40] +2 [14:41] we haven't reached the projetc size to need squashing or submaintainers :-) [14:41] +1 for merging #18 [14:41] I added small comments to #19 [14:41] slyon: demonstrates that one can find things if you actually read every word - thanks [14:41] dviererbe: will you fix up #19 and then ping me? [14:42] I think we are ok to land once those are good [14:42] #18 seems ready now, those are just good fixes [14:42] Yes, will do [14:42] thanks [14:42] Please wait for #18 [14:42] I think sylon has found another typo [14:42] I'm on hold until you let me know [14:42] nifty @check-spelling-bot Report [14:42] does not neet to be live in this meeting [14:42] I think in the long term we should factor this in a separate repo, as a github reusable workflow [14:43] Okay :) [14:43] didrocks: you are right, but for now let us keep it simple [14:43] didrocks: that allows this and a few others to evolve until we could see what would be a good general checker for canonical [14:44] agreed [14:44] happy to help once it matures enough [14:44] do the "forbidden patterns" need to be cleaned up from the check spelling report? [14:45] I think we should put all questions/suggestions into the PR itself, so dviererbe can work on it after the meeting [14:45] ack [14:45] sounds good [14:45] ack [14:45] good on that topic it seems [14:45] let us go on [14:45] thanks already for the contrib dviererbe [14:46] https://github.com/canonical/ubuntu-mir/pull/19 [14:46] -ubottu:#ubuntu-meeting- Pull 19 in canonical/ubuntu-mir "ci: add automated spell checking" [Open] [14:46] #topic MIR related Security Review Queue [14:46] Mission: Check on progress, do deadlines seem doable? [14:46] #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:46] Internal link [14:46] - ensure your teams items are prioritized among each other as you'd expect [14:46] - ensure community requests do not get stomped by teams calling for favors too much [14:46] #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 [14:47] we are ramping mir assignment backup on the security team after the sprint/lunar [14:47] we have none and won't add much these cycle, maybe one or two [14:47] rust is a large priority [14:47] the first url is buggy (at least in my IRC client) [14:47] the %5B/%5D confuse the query [14:47] we've had little progress since last week; we have assigned some of the holdovers from last cycle, but yesterday, so unlikely anyone's made progress on anything. last I knew our coverity license hadn't been sorted yet. [14:48] eslerm: I'm glad to hear that! :) (wrt rust) [14:48] seb128: I click and it works - it is is [ 5D is ] [14:48] seb128, does it cope with lowercase better? 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] the problem is that unescaped even mire clients and tools would fail [14:48] no, but don't worry about it, perhaps an issue with hexchat on my end... [14:49] for me upper and lower works - IIRC the escaping is supposed to use upper case right? [14:49] seb128: your browser should understand [14:49] I'm shocked to say that I have no idea :D [14:49] I end up with a launchpad page with '%5bMIR%5d' as text which has no match [14:49] sounds like a busted security fix *cough* [14:49] anyway don't let me derail the meeting [14:49] sarnold: does 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 work for you? [14:50] that one wfm [14:50] hmm [14:50] cpaelzer: wfm in firefox [14:50] so proper escaping fails on some clients [14:50] but no escaping works [14:50] I'll update the templat to just throw both links [14:50] clients being smart about doing the escaping themselves.. [14:50] so each combination of the chatclient/browser populations will have one that works [14:51] lol [14:51] nice solution :) [14:51] escape the escaping - meta issues FTW [14:51] xD [14:52] hey iosifache :) [14:52] fixed [14:52] o/ [14:52] Hey! [14:53] ok, the actual topic is good [14:53] the meta issue on it is fixed [14:53] going on [14:53] #topic Any other business? [14:53] none from me [14:53] I'll be out for the next two weeks, would you mind as usual to self organize and someone lead the meeting then? [14:53] nothing either [14:54] I'll be out for the next 2-3 weeks for personal reasons :) [14:54] I know :-) [14:54] I need input from the MIR team on https://bugs.launchpad.net/ubuntu/+source/dbus-broker/+bug/2015538 [14:54] -ubottu:#ubuntu-meeting- Launchpad bug 2015538 in dbus-broker (Ubuntu) "[MIR] dbus-broker" [Undecided, New] [14:54] seb128: looking. [14:54] seb128: should we just read the comments? [14:54] or is there a more specific question [14:54] it was acked by slyon but I found that demoting dbus-daemon might not be as easy as expected [14:54] see current comment [14:55] I wonder if keeping an utility binary from dbus-daemon in main would be acceptable [14:55] if we demote the actual service [14:56] IMO the suggested solution is OK (as long as we're not doing it in an LTS, so Mantic is fine), but I'd leave the final call about that to the security team. As long as the plan is still in place to get it fully resolved by the next LTS [14:57] this issue was opened in 2018 :( [14:57] ack to slyon, but I have one extra constraint to add [14:58] In the past we had such agreements, but by the fact that the team owning - in this case dbus - is foundations and security, but not Desktop we had the problem that the motivation to resolve this wasn't present in the same team [14:58] due to that things dragged on a while [14:58] would you be ok to take dbus >=mantic [14:58] then you'd be the one benefitting from the situation being resolved [14:59] BTW - former cases were not your team [14:59] hum, I'm not sure I can commit at this point to us rewritting dbus-run-session for the LTS [14:59] so I'm purely referring to lessons learned [14:59] I guess plan B is to give up on that switch [15:00] desktop was not the driver for that switch, though we picked it up and have interested [15:00] I see [15:00] It got dropped by foundations in the past due to lack of capacity [15:00] it would be a shame to fully give it up, but we are somewhat between a rock and a hard place [15:00] I can try to make a case to squeeze that work next cycle but I've no visiblity at this point on how realistic that is for us [15:00] how did fedora deal with the switch? [15:01] they keep installing dbus-tools from dbus-daemon [15:01] they don't bother about 'demoting' things as much as we do [15:01] aha [15:02] hmm [15:02] how about changing the order of things [15:02] work on rewriting first [15:02] if it works in time for the LTS, let us switch [15:02] that basically means giving up on the switch for the LTS [15:03] is it? [15:03] the one person in our team with the skills to do that work is already overworked over capacity this cycle [15:03] and we will no switch a base foundation component in the LTS cycle [15:03] not [15:03] indeed, that is something we'd generall want before the LTS [15:04] so IMHO it becomes a call for foundations and secuity if it is a problem that they will hold on to dbus while dbus-broker is then there as well [15:04] I could check back with mclemenceau_ if there's any capacity in foundation's system squad.. but I think they're fully booked, too. [15:04] if that is ok for those two groups, then the duplication problem isn't that much of a problem [15:04] we would only maintain the utility [15:04] maybe slyon and sarnold can bring that to the team and update the bug once they know [15:04] seb128: yep [15:05] a plan C could be to try to copy that part of the dbus-daemon code in the dbus-broker source... [15:05] but that's just a more complicated way to end up maintaining the same code [15:05] yeah, I'd not like that [15:05] I did wonder about that, or split the source file out into its own micropackage, but it'd probably drag in some percentage of the dbus-daemon code anyway, then we've got a few versions of it to track :( [15:05] I'm fine with letting it to foundations and security to figure out what they want to do [15:05] the process is meant to help not maintaining the same thing twice - not to make us do awkward twists to trick it [15:06] ok, slyon and sarnold - would you take the task to find out and comment back on the bug [15:06] I guess we all would want dbus-broker, but can not decide if that is ok for you [15:06] yeah, thanks for raising it nice and early seb128 :) [15:06] thanks seb128for bringing it up [15:06] thanks! [15:06] ack, thanks! [15:07] ok [15:07] it seems we can conclude [15:07] sorry for running over [15:07] anything else to say before we close? [15:07] enjoy your two weeks off, those who are doing so :) [15:07] thanks [15:08] but that is easy, enjoy the weeks working - because that is when things are great [15:08] closing the meting then [15:08] thank you all [15:08] bye all o/ [15:08] #endmeeting [15:08] Meeting ended at 15:08:16 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-05-23-14.31.moin.txt [15:08] :D [15:08] bye, thanks all [15:08] o/ [15:08] thanks [15:08] thanks cpaelzer, all [15:08] Bye! [15:08] thanks! === juliank_ is now known as juliank