[15:30] <sarnold> good morning
[15:31] <eslerm_> o/
[15:31] <cpaelzer> hiho
[15:31] <cpaelzer> just 1 more minute to get started
[15:32] <slyon> o/
[15:34] <cpaelzer> ok
[15:34] <jbicha> o/
[15:34] <cpaelzer> rush ...
[15:34] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[15:34] <meetingology> Meeting started at 15:34:31 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:34] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:34] <cpaelzer> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )
[15:34] <cpaelzer> #topic current component mismatches
[15:34] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[15:34] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[15:34] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[15:34] <jamespage> o/
[15:34] <cpaelzer> we see the known set ot trace*
[15:35] <cpaelzer> then the unsurprising long case of jaraco
[15:35] <slyon> freerdp3 seems new and needs investigation by the desktop team (cc didrocks)
[15:35] <cpaelzer> will that ever chance jamespage?
[15:35] <cpaelzer> ack on freerdp3
[15:35] <jamespage> I need to refresh my brain on why that's still there
[15:35] <cpaelzer> jbicha: you said hi, do you happen to know any more on freerdp3?
[15:35] <jamespage> oh right this was todo with pydantic
[15:36] <cpaelzer> and also for jamespage there is python-openstacksdk -> platformdirs
[15:36] <cpaelzer> but is filed
[15:36] <eslerm_> libtraceevent is being worked on by security, libtracefs was deemed to not need security review. should be good to go
[15:36] <jbicha> yes, Ubuntu Desktop would like to do a straight swap: freerdp3 for freerdp2. It has 2 main reverse dependencies, gnome-remote-desktop & remmina and both have been switched in noble-proposed
[15:36] <cpaelzer> waiting for an assigneed
[15:36] <jamespage> it is just needs someone other than me (who filed it) to review
[15:36] <cpaelzer> jbicha: ok, is freerdp3 based ont he source of freerdp2 or something completely else?
[15:37] <cpaelzer> yes jamespage we will get to that when looking at tasks to assign - thanks
[15:37] <slyon> eslerm_: *trace* still needs some work from foundations, primarly to enable tests
[15:37] <jbicha> cpaelzer: it is a new upstream version of the same project. It just will take a while for everything in universe to be ported
[15:37] <cpaelzer> slyon: yes some QA is also what I've seen the most there - also on bpf*
[15:37] <joalif> o/
[15:37] <cpaelzer> slyon: but all of it moves and I have hopes it works out
[15:37] <jbicha> the new source package idea was also done years ago when freerdp2 was introduced
[15:37] <slyon> ack
[15:37] <cpaelzer> jbicha: so will we need both in the archive or both in main for a transition time?
[15:38] <jbicha> cpaelzer: both are only needed in main for the short (lol) time it will take for things to get out of noble-proposed
[15:39] <jbicha> freerdp2 will not be needed in main for 24.04 LTS
[15:39] <cpaelzer> ok, I think you can craft a bug until next week
[15:39] <slyon> basicaly demote freedrp2 & promote freerdp3 IIUC
[15:39] <cpaelzer> and if it is indeed the same and not hilariously bad (and slipped into main in the dark past) then it should be a quick case
[15:40] <cpaelzer> 10 reverse dependencies
[15:40] <jbicha> cpaelzer: so you want an explicit MIR bug for freerdp3?
[15:40] <cpaelzer> is there an old one we could tag this on to?
[15:40] <cpaelzer> from freerdp2
[15:41] <cpaelzer> and OTOH this is kind of a lib transition, there release team might want to talk about an FFE - up to you to judge
[15:41] <jbicha> bug 673925
[15:41] -ubottu:#ubuntu-meeting- Bug 673925 in freerdp "[MIR] freerdp" [Undecided, New] https://launchpad.net/bugs/673925
[15:41] <jbicha> ffe was bug 2057842 , granted pending MIR approval
[15:41] -ubottu:#ubuntu-meeting- Bug 2057842 in remmina (Ubuntu) "FFe: freedp2 -> freerdp3 in main" [Undecided, Fix Committed] https://launchpad.net/bugs/2057842
[15:41] <cpaelzer> great
[15:42] <sarnold> heh kees sure has a way with words :) "it implies a grievous lack of attention to security"
[15:42] <cpaelzer> all testing off makes me wonder
[15:42] <slyon> jbicha: freerdp3 has no autopkgtests :(
[15:42] <cpaelzer>     -DBUILD_TESTING=OFF in build
[15:42] <cpaelzer> nothing in debian/tests/
[15:42] <cpaelzer> ...
[15:42] <cpaelzer> sure we could say it is as bad as before, but I'm feeling not too happy
[15:43] <eslerm_> is the need for freerdp2 related to fdk-aac-free?
[15:43] <cpaelzer> I think it is ok to say yes, as nothing will regress. But I feel bad to let this opportuinty to add some QA be added :-/
[15:44] <jbicha> eslerm_: not directly, but gnome-remote-desktop (and a a few others) want fdk-aac*
[15:45] <cpaelzer> this isn't a dictatorship - how do others feel. Passing as "same content new name and version" or passing with "yes, but add some tests before promotion" ?
[15:45] <seb128> (sorry in a call at the same time but I'm happy to commit desktop team time to improve tests/packaging before the end of the cycle if that can help to unblock things)
[15:45] <jbicha> cpaelzer: I can add some bugs and Jira cards for exploring enabling freerdp tests. Unfortunately things are so busy I don't think we have capacity before noble's release
[15:45] <cpaelzer> thanks seb128, that is all I wanted - you gave jbicha the time to have a look
[15:46] <slyon> +1 on implementing at least a basic set of tests, if that is an option
[15:48] <sarnold> another possibility if it's just too hard to test during build or too fickle to test during autopkgtest is the 'manual testing plan' and assurances that it'd be run on every update; we haven't done this in a while, is it still an option or did we push strongly enough for fully automated testing that we removed the manual testing plan?
[15:48] <jbicha> eslerm_: I believe the takeaway on fdk-aac-free was "No for 24.04 LTS, can re-evaluate later to check for improvement in security handling"
[15:48] <cpaelzer> I write a bug update ...
[15:48] <sarnold> if upstream has already abandoned the older versions, it'd be unfun to stick on it for the next ten years vs this one, which might be replaced by freerdp4 in another five or so :)
[15:49] <jbicha> sarnold: oh, I have a minimal manual test plan for both Remmina & gnome-remote-desktop https://wiki.ubuntu.com/DesktopTeam/TestPlans/RemoteDesktop
[15:50] <cpaelzer> updated https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/2057842 jbicha
[15:50] -ubottu:#ubuntu-meeting- Launchpad bug 2057842 in remmina (Ubuntu) "FFe: [MIR] freedp2 -> freerdp3 in main" [Undecided, Fix Committed]
[15:50] <cpaelzer> I hope that is ok as the compromise we found here
[15:50] <eslerm_> jbicha: if fdk-aac-free is causing the change from freerdp3 to freerdp2, please message me. The security tradeoff is likely better with 3. The chain to upstream needs to be improved for fdk-aac
[15:50] <sarnold> jbicha: nice, thanks
[15:50] <cpaelzer> wow, time flies
[15:50] <cpaelzer> #topic New MIRs
[15:50] <sarnold> yes
[15:50] <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
[15:50] <cpaelzer> #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
[15:50] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/platformdirs/+bug/2057683
[15:50] -ubottu:#ubuntu-meeting- Launchpad bug 2057683 in platformdirs (Ubuntu) "[MIR] platformdirs" [High, New]
[15:50] <cpaelzer> I'm ok to give this a shot
[15:50] <cpaelzer> as relax task between roadmaps
[15:51] <cpaelzer> and I haven#t done one in two weeks
[15:51] <jbicha> eslerm_: fdk-aac-free isn't needed for the freerdp3 switch. Thank you
[15:51] <eslerm_> ack, +1
[15:51] <cpaelzer> next is https://bugs.launchpad.net/ubuntu/+bug/2058192
[15:51] -ubottu:#ubuntu-meeting- Launchpad bug 2058192 in ubuntu "[MIR][needs-packaging] lenovo-wwan-unlock" [Wishlist, New]
[15:51] <cpaelzer> which looks ... unfinished?
[15:51] <sarnold> it sure feels like we've already got something for the xdg directory names thingy
[15:52] <sarnold>   - Binary configservice_lenovo and DPR_Fcc_unlock_service in /opt/fcc_lenovo/ is no problem because AppArmor constraints applied
[15:52] <sarnold> well that's sure iffy
[15:52] <cpaelzer> lenovo-wwan-unlock being not yet even in universe makes us lack and history on quuality
[15:52] <cpaelzer> the link has no code, no build
[15:53] <sarnold> I realize our OEM stuff can be weird but this feels too weird, or it's in the wrong place, or something like that
[15:53] <slyon> just a PPA build in https://launchpad.net/~dirksu/+archive/ubuntu/fccunlock-test
[15:54] <slyon> But I agree this should go through normal review & sponsorship into multiverse first
[15:55] <cpaelzer> hmm
[15:55] <cpaelzer> incomplete for now
[15:56] <cpaelzer> until it at least is in the archive
[15:56] <sarnold> can we give our coworker some concrete advice on a next step?
[15:56] <cpaelzer> yeah, but I wonder what that is other than get it in the archive
[15:56] <sarnold> I strongly dislike the idea of us packaging *anything* in /opt
[15:56] <cpaelzer>  - debian/watch is not present because it is a native package and need to add
[15:56] <cpaelzer> ??
[15:56] <cpaelzer> that is not mutually excludive
[15:56] <cpaelzer> exclusive
[15:57] <cpaelzer> has canonical-mainstream ever owned a package
[15:57] <cpaelzer> I might have missed them since it is OEM work
[15:57] <slyon> Maybe a next step could be reaching out to ~ubuntu-sponsors to get it reviewed and sponsored into the archive?
[15:57] <cpaelzer> http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html#canonical-mainstream
[15:57] <cpaelzer> yep ok
[15:57] <slyon> I remember other canonical-mainstream bugs from the sponsorhip queue
[15:58] <cpaelzer> slyon: that is a good suggestion
[15:58] <slyon> I can write a comment
[15:58] <cpaelzer> already on it
[15:58] <cpaelzer> done
[15:58] <slyon> thx
[15:59] <cpaelzer> #topic Incomplete bugs / questions
[15:59] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[15:59] <cpaelzer> #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
[15:59] <cpaelzer> also time is up
[15:59] <cpaelzer> arr
[15:59] <cpaelzer> I need to run today
[15:59] <cpaelzer> incompletes are discussions going on
[16:00] <cpaelzer> I'd go on, but can no more drive things ... :-/
[16:00] <slyon> I can check the details on gnome-snapshot (bug #2052652) after the meeting
[16:00] -ubottu:#ubuntu-meeting- Bug 2052652 in gnome-snapshot (Ubuntu) "[MIR] gnome-snapshot" [Undecided, Incomplete] https://launchpad.net/bugs/2052652
[16:00] <cpaelzer> #topic Process/Documentation improvements
[16:00] <cpaelzer> Mission: Review pending process/documentation pull-requests or issues
[16:00] <cpaelzer> #link https://github.com/canonical/ubuntu-mir/pulls
[16:00] <cpaelzer> #link https://github.com/canonical/ubuntu-mir/issues
[16:00] <cpaelzer> thank slyon
[16:01] <slyon> nothing new here, I think.
[16:01] <cpaelzer> ack
[16:01] <slyon> I merged https://github.com/canonical/ubuntu-mir/pull/53 earlier today
[16:01] -ubottu:#ubuntu-meeting- Pull 53 in canonical/ubuntu-mir "Rationale and ownership" [Merged]
[16:01] <cpaelzer> thanks
[16:01] <cpaelzer> #topic MIR related Security Review Queue
[16:01] <slyon> we have consensus on https://github.com/canonical/ubuntu-mir/issues/51
[16:01] -ubottu:#ubuntu-meeting- Issue 51 in canonical/ubuntu-mir "cargo vendor adds unnecessary crates" [Open]
[16:01] <cpaelzer> Mission: Check on progress, do deadlines seem doable?
[16:01] <cpaelzer> Some clients can only work with one, some with the other escaping - the URLs point to the same place.
[16:01] <cpaelzer> #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
[16:01] <cpaelzer> #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
[16:01] <cpaelzer> Internal link
[16:01] <cpaelzer> - ensure your teams items are prioritized among each other as you'd expect
[16:01] <cpaelzer> - ensure community requests do not get stomped by teams calling for favors too much
[16:01] <cpaelzer> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
[16:02] <eslerm_> Security is aiming to clear our currently assigned board this week so that we are available for last minute requests
[16:02] <eslerm_> please assign platformdirs and lenovo-wwan-unlock asap to avoid crunch
[16:02] <sarnold> I believe our current status is happier than this board indicates
[16:02] <eslerm_> please recall that "For a MIR to be considered for a release, it must be assigned to the Security team (by the MIR team) before Beta Freeze"
[16:02] <eslerm_> most of the board is in review :)
[16:04] <slyon> eslerm_: so maybe we should assign libtracefs already. As the pending tests should be independent of security review
[16:04] <slyon> bug #2051925 wdyt?
[16:04] -ubottu:#ubuntu-meeting- Bug 2051925 in libtracefs (Ubuntu) "[MIR] promote libtracefs as a trace-cmd dependency" [Undecided, Incomplete] https://launchpad.net/bugs/2051925
[16:04] <eslerm_> that was deemed >This does not need a security review
[16:04] <eslerm_> libtracefs*
[16:04] <slyon> oh wait
[16:04] <slyon> right. No need here
[16:05] <slyon> So things are looking good from Foundations POV
[16:05] <sarnold> slyon: would foundatoins want to do a new upload of ndctl to re-pick-up libtracefs?
[16:06] <sarnold> I guess that's not really super-important now, but it's a possibility anyway
[16:06] <slyon> I'd need to check back with the team... But for now I'd say we should first try to get libtracefs in shape
[16:07] <slyon> ndctl is actually owned by server. So they could jump on libtracefs once it got MIR approval
[16:07] <sarnold> ah d'oh
[16:07] <slyon> (essentially dropping the delta)
[16:09] <sarnold> seems like there's not a whole lot more to discuss re: security, and if there is, head to the office hours meeting :)
[16:09] <sarnold> #topic Any other business?
[16:09] <eslerm_> thanks for the dbus-broker #2015538 comment slyon
[16:09] <sarnold> #topic Any other business?
[16:09] <didrocks> o/ (I’m back)
[16:09] <cpaelzer> not from me
[16:09] <slyon> seb128: bug #2015538 might contain some update for you
[16:09] -ubottu:#ubuntu-meeting- Bug 2015538 in dbus-broker (Ubuntu) "[MIR] dbus-broker" [Undecided, Incomplete] https://launchpad.net/bugs/2015538
[16:09] <didrocks> I did spend half a day already on trying to remove the rust windows dep on authd
[16:09] <cpaelzer> yes libtrace could be used in other places
[16:09] <didrocks> cargo doesn’t cooperate, albeit I am not a Rust expert
[16:09] <slyon> i.e.: we might not need the rust parts for dbus-run-session
[16:10] <didrocks> without guidance, this is really difficult, so I would appreciate any help
[16:10] <sarnold> didrocks: did it just brute-force try to download all those crates during build-time even if they weren't needed for the config in question?
[16:10] <slyon> didrocks: maybe reach out to liushuyu-011
[16:10] <didrocks> sarnold: exactly, and even if you mess up with the .lock files, the checksum doesn’t match
[16:10] <sarnold> didrocks: blech.
[16:11] <sarnold> I had really assumed it was just going to ignore everything that it didn't need for that build :(
[16:11] <didrocks> yeah, clearly not :/
[16:12] <didrocks> slyon: I will try, but if he doesn’t have any bandwith
[16:12] <sarnold> I really don't like the idea of polluting all our mirrors with hundreds of megabytes of windows-only crates but there's not a whole lot of time left to come up with something to avoid it.
[16:12] <didrocks> not like we do either, we are late to the projects, add more tasks added by day, so I have few hope to get authd in main this cycle
[16:13] <eslerm_> the meaning of *best-effort* is flexible :pray: thank you for your efforts didrocks
[16:13] <didrocks> well, it is what it is, if this is a requirement, fine, just that we will miss the target for this
[16:13] <didrocks> I’ll try again giving another day, and we’ll see
[16:13] <sarnold> I think we'd rather be pragmatic
[16:13] <slyon> eslerm_: I agree. If "best-effort" doesn't work out, it needs to be ignored
[16:13] <didrocks> I still think this is more an infrastructure helper tool matter, but I lost that argument already :)
[16:14] <sarnold> no, you're 100% right on that one, too :) it's just that they're in the same boat, heh
[16:14] <didrocks> (same, we have our own tooling for vendoring because it’s not well supported and we start having copy)
[16:14] <didrocks> let’s see how it goes, let me give this another try, but I wanted to update you on the progress (or rather lack of)
[16:14] <sarnold> didrocks: please do shoot liushuyu-011 a quick summary of the goal, where you got stuck, and hope there's a brainstorm :)
[16:14] <didrocks> will try
[16:14] <sarnold> thanks
[16:14] <slyon> thanks!
[16:15] <sarnold> anything else?
[16:15] <slyon> nothing.
[16:15] <didrocks> nothing else either
[16:15] <sarnold> alrighty then :)
[16:15] <sarnold> #endmeeting
[16:15] <meetingology> Meeting ended at 16:15:53 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-03-19-15.34.moin.txt
[16:15] <eslerm_> thanks everyone o/
[16:15] <seb128> slyon, I saw that and need to reply, basically I need to check if the claim that dbus-run-session depends on dbus-daemon make past cycle is true (because if it is then the split isn't going to enough to remove dbus-daemon to universe)
[16:16] <sarnold> thanks cpaelzer, all :)
[16:16] <didrocks> thanks!
[16:16] <didrocks> (for once the meeting is long enough for me to attend the end, I’ll scrollback now)
[16:16] <slyon> thanks all! o/
[16:17] <slyon> seb128: thanks for double-checking this!
[16:18] <cpaelzer> thank you all
[16:18] <seb128> I missing the AOB opportunity, but any idea from security when https://bugs.launchpad.net/ubuntu/+source/gnome-snapshot/+bug/2052652 might get reviewed?
[16:18] -ubottu:#ubuntu-meeting- Launchpad bug 2052652 in gnome-snapshot (Ubuntu) "[MIR] gnome-snapshot" [Undecided, Incomplete]
[16:19] <eslerm_> review is in progress
[16:19] <seb128> ideally that's a change we would still like to land for Noble since that's something we told oem we would do
[16:19] <eslerm_> aiming to complete review by eow
[16:19] <seb128> change between cheese->snapshot
[16:19] <seb128> eslerm_, great, thanks!
[16:20] <eslerm_> I reported upstream about unnecessary crate vendoring https://gitlab.gnome.org/GNOME/snapshot/-/issues/137
[16:20] -ubottu:#ubuntu-meeting- Issue 137 in GNOME/snapshot "unnecessary crate vendoring in source download" [Opened]
[16:21] <slyon> seb128: I'm looking into gnome-snapshot right now
[16:21] <seb128> slyon, thanks!
=== JanC_ is now known as JanC