[10:36] seb128: I'm currently re-considering the libcamera MIR (looking mostly good, bug #1997560). Is it still true that you only need the libcamera0.0.5 package promoted and none of the (new/splitted) libcamera-{ipa,tools,v4l2} or gstreamer1.0-libcamera packages? [10:36] -ubottu:#ubuntu-meeting- Bug 1997560 in libcamera (Ubuntu) "[MIR] libcamera" [Undecided, New] https://launchpad.net/bugs/1997560 [11:06] Well... I guess those split packages are fine anyways (except -tools). So nevermind. [14:30] o/ === cpaelzer_ is now known as cpaelzer [14:30] \o [14:30] o/ [14:30] o/ [14:30] #startmeeting Weekly Main Inclusion Requests status [14:30] Meeting started at 14:30:40 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology [14:30] Available commands: action, commands, idea, info, link, nick [14:30] Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) [14:30] Hello everyone [14:30] glad to see so many waiting [14:31] so without further ado, jumping on agenda point 1 [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] bryce is still working on that spamassassin case [14:31] it seems we will need it [14:31] and he preps the paperwork [14:31] but as in the past, those perl libs are just structural wrappers around the source [14:32] o/ [14:32] so we have been - and here for efficiency - do some less deep checks [14:32] mostly "is this really such a simple case" [14:32] but, not open for review yet [14:32] just a heads up [14:32] o/ [14:32] jamespage: the other never ending story is yourd - jaraco.text [14:33] when you read this later, let us know what the state and expectation on this should be [14:33] we have a new cycle, so everything might be different now :-) [14:33] ruby has gotten stub bugs [14:33] existing, but not yet ready [14:33] good morning [14:33] I see nothing else new in those files [14:34] hello also to didrocks joalif and sarnold [14:34] and to slyon eslerm and dviererbe who were here before logging started :-) [14:34] ok, going on [14:34] #topic New MIRs [14:34] Mission: ensure to assign all incoming reviews for fast processing [14:34] #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:35] oof, good luck to bryce [14:35] hehe [14:35] as i said, ruby isn't really ready yet [14:35] so we can ignore that for this week [14:35] I'll mark them incomplete for now [14:36] that leaves https://bugs.launchpad.net/ubuntu/+source/dotnet6/+bug/2023531 [14:36] -ubottu:#ubuntu-meeting- Launchpad bug 2023531 in dotnet6 (Ubuntu) "[MIR] dotnet6" [Undecided, New] [14:36] I filed an MIR for dotnet6. Its a large and complex package but there is no time pressure to get it into main this cycle [14:36] dviererbe: dare you, how could you brind this [14:36] it is huge for sure [14:36] dviererbe: I guess foundations would be the owning team. I can see it subscribed.. do you want me to do that? [14:36] can't* [14:37] dviererbe: any reason to start with dotnet6 and not 7 ? [14:37] or is 7 already up and in some interim state? [14:37] We only want to MIR LTS versions [14:37] (maybe I should read the bug) [14:37] - This MIR exists in parralel to the MIR for dotnet7 [14:37] cpaelzer: Waht does "brind mean" [14:38] bring + a typo [14:38] As I understood, dotnet7 is not an LTS, so no MIR for it [14:38] ohh... I'm sorry [14:38] correct [14:38] dviererbe: what are the target releases for this - only mantic or later? [14:38] dviererbe: or will this be going back in time, as you backport all of it all the time anyway [14:39] Including all, back until jammy would be preferred [14:39] will we have both dotnet6 and dotnet8 in 24.04 LTS ? https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core [14:39] or will you make a choice [14:39] dotnet8 will be there in 24.04 [14:39] which dotnet matches which Ubuntu LTSes [14:39] "Even numbered releases are LTS releases that get free support and patches for three years." oof that's long, eh? :( [14:40] so will it be dotnet6 18-04->23.10 and then dotnet8 24.04->future ? [14:40] only since jammy [14:41] ? [14:41] The actual support strategy is a little bit complicated. I will add a comment to the bug [14:41] thanks [14:41] dotnet8 on >=jammy - is that it [14:41] appreciate that [14:41] what's our plan for after the end of upstream support? [14:42] If I recall correctly dotnet8 will only be needed in >= 24.04 and dotnet6 in >= 22.04 [14:42] The plan is to provide a transitional package that deinstalls dotnet when it reaches EOL [14:42] aha, interesting [14:42] We already talked with security about that [14:42] wow [14:43] umm, yeah please outline that on the bug :-) [14:43] it does sound familiar. sigh :( my memory isn't what it was :( [14:43] no worries you have a lot to do [14:43] ok, I made a post on the bug [14:43] and I'm waiting for dviererbe to add more details later [14:43] in any case, we need to start a review on it [14:44] and that isn't as special in this case [14:44] as things with daemons and ports are often more complex to review [14:44] do we have such strong feelings about 'no generated objects / sources' the same way debian does? [14:44] this is more pain for security later on I guess [14:44] sarnold: we do have the opinion to avoid whenever possible, but not strictly forbid them AFAIK [14:44] this feels likely to be supported via the 'big blog from MS' model [14:44] s/blog/blob/' [14:44] s/blog/blob/ ? [14:45] yeah :-) [14:45] ok, counting slyon out as he is in the requesting team [14:45] which I have to say isn't very pleasing when applied to eg mysql [14:45] sarnold: Maybe you can talk with Ian about the dotnet package. we work with him for security releases [14:45] * slyon nods [14:45] that leaves joalif didrocks or me to review [14:45] volunteers or should I roll a dice [14:46] roll a dice :p [14:46] if there is no time constraints, I can take it, but we can make it fun too with a dice roll :) [14:46] 1-2 me, 3-4 joalif, 5-6 didrocks [14:46] 1 [14:46] = me [14:46] snake eyes! [14:46] I'm sorry :/ [14:46] there goes my automation of statistics ... o/ [14:47] sorry too for you :/ wonder how you did your dice roll though! [14:47] all fine dviererbe [14:47] didrocks: I have literally dices on my desk for planning and situations like this [14:47] :D [14:47] benefit of old role players I can cover any team size [14:47] ok, going on [14:47] waow, that’s orgnanization! :) [14:47] #topic Incomplete bugs / questions [14:47] Mission: Identify required actions and spread the load among the teams [14:47] #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:47] I wanna see that three-sided die [14:47] sarnold: you do realize thet is a D6/2 [14:48] primes are hard [14:48] oh. that's less fun. [14:48] but as manager we can be creative [14:48] two of the recent cases are in here [14:48] https://bugs.launchpad.net/ubuntu/+source/cairomm1.16/+bug/2020273 [14:48] -ubottu:#ubuntu-meeting- Launchpad bug 2020273 in cairomm1.16 (Ubuntu) "[MIR] cairomm1.16" [Undecided, Incomplete] [14:48] tasks of slyon for4 jbicha [14:48] I had a question about the symbols handling on this one ^ [14:48] "This does not need a security review" <3 :) [14:48] state ok for now [14:48] as discussed on the mailinglist [14:49] so we are coming back to symbosl [14:49] symbols [14:49] I haven't seen that, do you have a link slyon? [14:50] is that the continuation of the discussion seb opened a while ago? [14:50] yeah [14:50] https://bugs.launchpad.net/ubuntu/+source/cairomm1.16/+bug/2020273/comments/2 - my normal MIR review [14:50] -ubottu:#ubuntu-meeting- Launchpad bug 2020273 in cairomm1.16 (Ubuntu) "[MIR] cairomm1.16" [Undecided, Incomplete] [14:50] IIRC last week we said he is writing a PR to clarify the "one should try" [14:50] talking about symbols in my review this week https://bugs.launchpad.net/ubuntu/+source/gtkmm4.0/+bug/2020472 , symbols were missing as well for gtkmm4.0 but I wrote it is ok since gtkmm3.0 are also missing and is already in universe [14:50] -ubottu:#ubuntu-meeting- Launchpad bug 2020472 in gtkmm4.0 (Ubuntu) "[MIR] gtkmm4.0" [Undecided, In Progress] [14:50] essentially, I couldn't find a previous MIR (seems this has been in main forever). So I did a full review [14:50] slyon: yeah, that happened to me as well [14:51] cairomm[1.16] does not ship any .symbols files and I could not find any other attempt at ABI compatibilty testing. Therefore, I asked the questions why it should be skipped for this package (cc jbicha) [14:51] yeah [14:51] and as discussed we want to see it tried and given up for a reason [14:51] instead of giving up generally [14:51] agreed [14:51] right. [14:51] ok for now [14:52] let us wait what the answer is [14:52] to close out this agenda item - https://bugs.launchpad.net/ubuntu/+source/libhttp-cookiejar-perl/+bug/2024245 - has an open question and therefore is ok to be incomplete for now [14:52] -ubottu:#ubuntu-meeting- Launchpad bug 2024245 in libhttp-cookiejar-perl (Ubuntu) "[MIR] libhttp-cookiejar-perl" [Undecided, Incomplete] [14:52] And accepting it just because it has been bad before (without any reasoning given) isn't good [14:52] IMHO [14:52] yep [14:52] there is some balance to strike, but yes [14:52] we can keep it at that for now [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:52] . [14:53] oh, hi jbicha [14:53] do you want to immediately discuss/report about that? [14:53] or only seen the highlights so far [14:53] for glibmm2.68, I have a draft to force symbols tracking for amd64 on Ubuntu only https://salsa.debian.org/gnome-team/glibmm2.68/-/merge_requests/2 [14:53] -ubottu:#ubuntu-meeting- Merge 2 in gnome-team/glibmm2.68 "Draft: Add symbols tracking" [Opened] [14:53] awesome [14:53] thanks jbicha [14:53] I can investigate cairomm1.16 then too [14:54] let us know via an update in the bug if you think this lands in time or if you expect this to take ages (more thna you can wait with promotion) [14:54] that'd be great, thanks jbicha [14:54] while we are at it - here we have the aforementioned PR about symbols [14:54] https://github.com/canonical/ubuntu-mir/pull/27 [14:54] -ubottu:#ubuntu-meeting- Pull 27 in canonical/ubuntu-mir "Document a possible symbols exception for c++ libraries" [Open] [14:56] I think slyon and I commented [14:56] I'm curious to see how difficult it is to update the symbols for glibmm for the next major release. The Desktop Team may come back to the MIR team if it's just too much of a headache [14:56] we can wait for an answer [14:56] jbicha: that sounds fair to me [14:56] I expect to have an update for cairomm by next week's meeting [14:56] jbicha: symbols are missing for gtkmm4.0 too could you also take a look at it ? [14:57] https://bugs.launchpad.net/ubuntu/+source/gtkmm4.0/+bug/2020472 [14:57] -ubottu:#ubuntu-meeting- Launchpad bug 2020472 in gtkmm4.0 (Ubuntu) "[MIR] gtkmm4.0" [Undecided, Incomplete] [14:57] jbicha: I really like the sound of that salsa merge request [14:57] while making progress - the other PR up is https://github.com/canonical/ubuntu-mir/pull/28 [14:57] -ubottu:#ubuntu-meeting- Pull 28 in canonical/ubuntu-mir "Explicitly state that reviews are about source packages" [Open] [14:57] gtkmm will be like glibmm so I'll aim to complete by next meeting too [14:57] slyon: that is simple enough and I'm +1 [14:58] if no one objects I'd merge it as-is [14:58] any -1 here? [14:58] +1 [14:58] +1 [14:58] enough for me as it is trivial [14:58] thanks [14:58] answered +1 on the PR, unsure how useful this is, but ok :) [14:58] the other cases are open [14:58] but not ready [14:59] the only issue worth is https://github.com/canonical/ubuntu-mir/issues/26 [14:59] -ubottu:#ubuntu-meeting- Issue 26 in canonical/ubuntu-mir "Decide if we get enough value from c++ symbols tracking to keep doing it" [Open] [14:59] sarnold: given the changes, can we close this now? [14:59] if you are ok, please do so sarnold [14:59] and keeping time in mind, I'm going on ... [14:59] cpaelzer: I figured we'd close it when we merge in https://github.com/canonical/ubuntu-mir/pull/27 [14:59] -ubottu:#ubuntu-meeting- Pull 27 in canonical/ubuntu-mir "Document a possible symbols exception for c++ libraries" [Open] [14:59] ack @sarnold [14:59] #topic MIR related Security Review Queue [14:59] Mission: Check on progress, do deadlines seem doable? [14:59] Some clients can only work with one, some with the other escaping - the URLs point to the same place. [14:59] #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 [15:00] #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 [15:00] Internal link [15:00] - ensure your teams items are prioritized among each other as you'd expect [15:00] - ensure community requests do not get stomped by teams calling for favors too much [15:00] #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 [15:00] That LGTM - any concerns from your side sarnold ? [15:00] that big pile of perl is worrying .. [15:00] but right now, things feel pretty good [15:00] it is coming [15:00] but usually those go by mostly without security [15:00] we will see [15:00] thanks sarnold [15:00] #topic Any other business? [15:00] please mind that your other meetings might start now [15:00] nothing here [15:01] this is done any minute ... [15:01] cargo and rust dependencies [15:01] https://launchpad.net/ubuntu/+source/dh-builtusing ... [15:01] yeah you wanted to bring those up last time [15:01] we might lose qorum, but you should bring up the question for awareness [15:01] I think we'd need didrocks opinion on https://bugs.launchpad.net/ubuntu/+source/cargo/+bug/1993819/comments/5 to move forward the cargo MIR [15:01] -ubottu:#ubuntu-meeting- Launchpad bug 1993819 in dh-cargo (Ubuntu) "MIR: cargo, dh-cargo" [High, In Progress] [15:01] is ^^ this thing Good Enough? please skim it :) [15:01] and if we can not close it out bring it up as first item next time [15:02] yeah, as I didn’t "win" any MIR this week, I can have another look at this [15:02] thank you didrocks [15:02] at the Rust Support in Main meeting in Prague, other teams agreed to define a policy for tracking rebuild-dependencies [15:02] this is important to the Security Team, as we need to rebuild Rust packages when vulnerabilities in their dependencies are patched [15:02] i.e., patching a package should trigger rebuilding all statically linked reverse-dependencies, and rebuilds of their reverse-dependencies, and so on [15:02] yeah, that is driven by foundations IIRC [15:02] at the meeting we agreed that this new policy should apply to all packages, not just Rust [15:03] I think as foundation has toolchains maintainer, this is rather something between security and them, no? [15:03] yes didrocks [15:03] (I'm happy to give a hand on Go, and explaining how this works out for it as I think I might be the one with the most awareness of govulncheck and so on…) [15:03] slyon: would you chase down internally if this was lost or net even meant to be on foundations plate? [15:04] Yes, will do [15:04] thanks [15:04] we are good for today [15:04] sorry to have kept you so long [15:04] but it is important, all the time [15:04] o/ [15:04] thanks cpaelzer, all [15:04] #endmeeting [15:04] thanks everyone [15:04] Meeting ended at 15:04:45 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-06-27-14.30.moin.txt [15:04] o/ [15:04] thanks! [15:04] Thanks! [15:05] thanks. I'll try to get back to eslerm about the rebuild-tracking policy [15:07] thank you slyon [19:00] o/ [19:00] o/ [19:00] o/ [19:00] I don't have any progress to report this meeting unfortunately. But I'm around now. [19:00] hey [19:00] Hello! [19:01] #startmeeting Technical Board Meeting [19:01] Meeting started at 19:01:26 UTC. The chair is sil2100. Information about MeetBot at https://wiki.ubuntu.com/meetingology [19:01] Available commands: action, commands, idea, info, link, nick [19:01] #topic Apologies [19:01] I don't think there were any explicit apologies sent beforehand [19:02] #topic Action review [19:03] Since rbasak said there's no progress on his tasks, I'll carry them over. It's sadly the same for me, so I'll do that as well [19:03] #action rbasak to get agreed backporter charter https://lists.ubuntu.com/archives/technical-board/2023-June/002740.html documented under https://wiki.ubuntu.com/TechnicalBoard/ [19:03] ACTION: rbasak to get agreed backporter charter https://lists.ubuntu.com/archives/technical-board/2023-June/002740.html documented under https://wiki.ubuntu.com/TechnicalBoard/ [19:03] * sil2100 seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage [19:03] amurray, seb128: any news on this from your side? [19:04] I had proposed something a while ago but I think the doc still shows it as a suggestion - so I guess that is awaiting feedback? [19:05] oh I see - seb128 and ken provided some comments - i guess I need to go read those - righto - let me take that as a carry-over then [19:05] amurray: thanks! [19:06] #action seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage [19:06] ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage [19:06] Ok, mine is carry-over [19:06] #action sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step [19:06] ACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step [19:06] #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification [19:06] ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification [19:06] #action rbasak to follow up on finding consensus on question of test plans for third party apps [19:06] ACTION: rbasak to follow up on finding consensus on question of test plans for third party apps [19:06] #action rbasak to restructure the third-party repo doc to make the status clearer [19:06] ACTION: rbasak to restructure the third-party repo doc to make the status clearer [19:07] #action rbasak to open wider discussion on third-party repo policy [19:07] ACTION: rbasak to open wider discussion on third-party repo policy [19:07] Now it's this one: [19:07] * sil2100 rbasak, vorlon, amurray to replay their responses to Key Ubuntu teams discussion [19:07] sil2100, we are missing your input on that discussion! :-) [19:08] seb128: I know! I think I need an action item for that too :( [19:08] but the 'reply' part is done [19:08] replay [19:08] Ok, so I'll add this as done and add an action item for me [19:08] though I think my main concern wasn't address and there was no reply to my most recent email [19:08] #done rbasak, vorlon, amurray to replay their responses to Key Ubuntu teams discussion [19:08] but maybe others aren't interested in addressing that part, hard to say [19:09] #action sil2100 to follow up on the Key Ubuntu teams discussion [19:09] ACTION: sil2100 to follow up on the Key Ubuntu teams discussion [19:10] seb128: I'll really try hard to find a slot to address this, maybe my reply will help things moving forward [19:10] Anyway, let's move on [19:10] #topic Scan the mailing list archive for anything we missed (standing item) [19:10] #link https://lists.ubuntu.com/archives/technical-board/2023-June/thread.html [19:11] Nothing here, just the Key Ubuntu teams discussion which I'm really bad at following up on... [19:11] #topic Check up on community bugs and techboard bugs [19:11] #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard [19:11] #link https://bugs.launchpad.net/techboard [19:11] No new bugs open besides the ones we already know about [19:12] #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) [19:12] #agreed next meeting chair: amurray, backup: rbasak [19:12] AGREED: next meeting chair: amurray, backup: rbasak [19:12] #topic AOB [19:12] Any other business? [19:12] The floor is open [19:12] not from me [19:13] nothing from me [19:13] There was a potential new item via the ML re: the adsys MRE, but I think that was resolved without requiring input from the TB [19:14] Yeah I think that's now an SRU team item to figure out. [19:14] Okay then, it's a quick meeting then. Maybe I can find time to start gathering time for the Key Ubuntu teams discussion for the reminder of the meeting [19:14] that would be nice indeed :) [19:14] #endmeeting [19:14] Meeting ended at 19:14:32 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-06-27-19.01.moin.txt [19:14] Thank you everyone o/ [19:14] thanks sil2100 [19:14] thanks sil2100 for chairing! [19:14] efficient meetings are the best :p