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 <jbicha> ffe was bug 2057842 , granted pending MIR approval
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 <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 <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 <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 <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 <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 <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 <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 <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