== Meeting information == * #ubuntu-meeting: Weekly Main Inclusion Requests status meeting, started by cpaelzer, 19 Mar at 15:34 — 16:15 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-03-19-15.34.log.html == Meeting summary == === current component mismatches === Discussion started by cpaelzer at 15:34. * ''LINK:'' https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg (cpaelzer, 15:34) * ''LINK:'' https://people.canonical.com/~ubuntu-archive/component-mismatches.svg (cpaelzer, 15:34) === New MIRs === Discussion started by cpaelzer at 15:50. * ''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 (cpaelzer, 15:50) * ''LINK:'' https://bugs.launchpad.net/ubuntu/+source/platformdirs/+bug/2057683 (cpaelzer, 15:50) * ''LINK:'' http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html#canonical-mainstream (cpaelzer, 15:57) === Incomplete bugs / questions === Discussion started by cpaelzer at 15:59. * ''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 (cpaelzer, 15:59) === Process/Documentation improvements === Discussion started by cpaelzer at 16:00. * ''LINK:'' https://github.com/canonical/ubuntu-mir/pulls (cpaelzer, 16:00) * ''LINK:'' https://github.com/canonical/ubuntu-mir/issues (cpaelzer, 16:00) === MIR related Security Review Queue === Discussion started by cpaelzer at 16:01. * ''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 (cpaelzer, 16:01) * ''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 (cpaelzer, 16:01) * ''LINK:'' https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 (cpaelzer, 16:01) === Any other business? === Discussion started by sarnold at 16:09. == People present (lines said) == * cpaelzer (90) * slyon (30) * sarnold (29) * didrocks (15) * jbicha (13) * eslerm_ (12) * jamespage (4) * meetingology (2) * joalif (1) * seb128 (1) == Full log == 15:34 #startmeeting Weekly Main Inclusion Requests status 15:34 Meeting started at 15:34:31 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology 15:34 Available commands: action, commands, idea, info, link, nick 15:34 Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) 15:34 #topic current component mismatches 15:34 Mission: Identify required actions and spread the load among the teams 15:34 #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg 15:34 #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 15:34 o/ 15:34 we see the known set ot trace* 15:35 then the unsurprising long case of jaraco 15:35 freerdp3 seems new and needs investigation by the desktop team (cc didrocks) 15:35 will that ever chance jamespage? 15:35 ack on freerdp3 15:35 I need to refresh my brain on why that's still there 15:35 jbicha: you said hi, do you happen to know any more on freerdp3? 15:35 oh right this was todo with pydantic 15:36 and also for jamespage there is python-openstacksdk -> platformdirs 15:36 but is filed 15:36 libtraceevent is being worked on by security, libtracefs was deemed to not need security review. should be good to go 15:36 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 waiting for an assigneed 15:36 it is just needs someone other than me (who filed it) to review 15:36 jbicha: ok, is freerdp3 based ont he source of freerdp2 or something completely else? 15:37 yes jamespage we will get to that when looking at tasks to assign - thanks 15:37 eslerm_: *trace* still needs some work from foundations, primarly to enable tests 15:37 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 slyon: yes some QA is also what I've seen the most there - also on bpf* 15:37 o/ 15:37 slyon: but all of it moves and I have hopes it works out 15:37 the new source package idea was also done years ago when freerdp2 was introduced 15:37 ack 15:37 jbicha: so will we need both in the archive or both in main for a transition time? 15:38 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 freerdp2 will not be needed in main for 24.04 LTS 15:39 ok, I think you can craft a bug until next week 15:39 basicaly demote freedrp2 & promote freerdp3 IIUC 15:39 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 10 reverse dependencies 15:40 cpaelzer: so you want an explicit MIR bug for freerdp3? 15:40 is there an old one we could tag this on to? 15:40 from freerdp2 15:41 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 bug 673925 15:41 ffe was bug 2057842 , granted pending MIR approval 15:41 great 15:42 heh kees sure has a way with words :) "it implies a grievous lack of attention to security" 15:42 all testing off makes me wonder 15:42 jbicha: freerdp3 has no autopkgtests :( 15:42 -DBUILD_TESTING=OFF in build 15:42 nothing in debian/tests/ 15:42 ... 15:42 sure we could say it is as bad as before, but I'm feeling not too happy 15:43 is the need for freerdp2 related to fdk-aac-free? 15:43 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 eslerm_: not directly, but gnome-remote-desktop (and a a few others) want fdk-aac* 15:45 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 (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 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 thanks seb128, that is all I wanted - you gave jbicha the time to have a look 15:46 +1 on implementing at least a basic set of tests, if that is an option 15:48 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 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 I write a bug update ... 15:48 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 sarnold: oh, I have a minimal manual test plan for both Remmina & gnome-remote-desktop https://wiki.ubuntu.com/DesktopTeam/TestPlans/RemoteDesktop 15:50 updated https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/2057842 jbicha 15:50 I hope that is ok as the compromise we found here 15:50 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 jbicha: nice, thanks 15:50 wow, time flies 15:50 #topic New MIRs 15:50 yes 15:50 Mission: ensure to assign all incoming reviews for fast processing 15:50 #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 https://bugs.launchpad.net/ubuntu/+source/platformdirs/+bug/2057683 15:50 I'm ok to give this a shot 15:50 as relax task between roadmaps 15:51 and I haven#t done one in two weeks 15:51 eslerm_: fdk-aac-free isn't needed for the freerdp3 switch. Thank you 15:51 ack, +1 15:51 next is https://bugs.launchpad.net/ubuntu/+bug/2058192 15:51 which looks ... unfinished? 15:51 it sure feels like we've already got something for the xdg directory names thingy 15:52 - Binary configservice_lenovo and DPR_Fcc_unlock_service in /opt/fcc_lenovo/ is no problem because AppArmor constraints applied 15:52 well that's sure iffy 15:52 lenovo-wwan-unlock being not yet even in universe makes us lack and history on quuality 15:52 the link has no code, no build 15:53 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 just a PPA build in https://launchpad.net/~dirksu/+archive/ubuntu/fccunlock-test 15:54 But I agree this should go through normal review & sponsorship into multiverse first 15:55 hmm 15:55 incomplete for now 15:56 until it at least is in the archive 15:56 can we give our coworker some concrete advice on a next step? 15:56 yeah, but I wonder what that is other than get it in the archive 15:56 I strongly dislike the idea of us packaging *anything* in /opt 15:56 - debian/watch is not present because it is a native package and need to add 15:56 ?? 15:56 that is not mutually excludive 15:56 exclusive 15:57 has canonical-mainstream ever owned a package 15:57 I might have missed them since it is OEM work 15:57 Maybe a next step could be reaching out to ~ubuntu-sponsors to get it reviewed and sponsored into the archive? 15:57 http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html#canonical-mainstream 15:57 yep ok 15:57 I remember other canonical-mainstream bugs from the sponsorhip queue 15:58 slyon: that is a good suggestion 15:58 I can write a comment 15:58 already on it 15:58 done 15:58 thx 15:59 #topic Incomplete bugs / questions 15:59 Mission: Identify required actions and spread the load among the teams 15:59 #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 also time is up 15:59 arr 15:59 I need to run today 15:59 incompletes are discussions going on 16:00 I'd go on, but can no more drive things ... :-/ 16:00 I can check the details on gnome-snapshot (bug #2052652) after the meeting 16:00 #topic Process/Documentation improvements 16:00 Mission: Review pending process/documentation pull-requests or issues 16:00 #link https://github.com/canonical/ubuntu-mir/pulls 16:00 #link https://github.com/canonical/ubuntu-mir/issues 16:00 thank slyon 16:01 nothing new here, I think. 16:01 ack 16:01 I merged https://github.com/canonical/ubuntu-mir/pull/53 earlier today 16:01 thanks 16:01 #topic MIR related Security Review Queue 16:01 we have consensus on https://github.com/canonical/ubuntu-mir/issues/51 16:01 Mission: Check on progress, do deadlines seem doable? 16:01 Some clients can only work with one, some with the other escaping - the URLs point to the same place. 16:01 #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 #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 Internal link 16:01 - ensure your teams items are prioritized among each other as you'd expect 16:01 - ensure community requests do not get stomped by teams calling for favors too much 16:01 #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 16:02 Security is aiming to clear our currently assigned board this week so that we are available for last minute requests 16:02 please assign platformdirs and lenovo-wwan-unlock asap to avoid crunch 16:02 I believe our current status is happier than this board indicates 16:02 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 most of the board is in review :) 16:04 eslerm_: so maybe we should assign libtracefs already. As the pending tests should be independent of security review 16:04 bug #2051925 wdyt? 16:04 that was deemed >This does not need a security review 16:04 libtracefs* 16:04 oh wait 16:04 right. No need here 16:05 So things are looking good from Foundations POV 16:05 slyon: would foundatoins want to do a new upload of ndctl to re-pick-up libtracefs? 16:06 I guess that's not really super-important now, but it's a possibility anyway 16:06 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 ndctl is actually owned by server. So they could jump on libtracefs once it got MIR approval 16:07 ah d'oh 16:07 (essentially dropping the delta) 16:09 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 #topic Any other business? 16:09 thanks for the dbus-broker #2015538 comment slyon 16:09 #topic Any other business? 16:09 o/ (I’m back) 16:09 not from me 16:09 seb128: bug #2015538 might contain some update for you 16:09 I did spend half a day already on trying to remove the rust windows dep on authd 16:09 yes libtrace could be used in other places 16:09 cargo doesn’t cooperate, albeit I am not a Rust expert 16:09 i.e.: we might not need the rust parts for dbus-run-session 16:10 without guidance, this is really difficult, so I would appreciate any help 16:10 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 didrocks: maybe reach out to liushuyu-011 16:10 sarnold: exactly, and even if you mess up with the .lock files, the checksum doesn’t match 16:10 didrocks: blech. 16:11 I had really assumed it was just going to ignore everything that it didn't need for that build :( 16:11 yeah, clearly not :/ 16:12 slyon: I will try, but if he doesn’t have any bandwith 16:12 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 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 the meaning of *best-effort* is flexible :pray: thank you for your efforts didrocks 16:13 well, it is what it is, if this is a requirement, fine, just that we will miss the target for this 16:13 I’ll try again giving another day, and we’ll see 16:13 I think we'd rather be pragmatic 16:13 eslerm_: I agree. If "best-effort" doesn't work out, it needs to be ignored 16:13 I still think this is more an infrastructure helper tool matter, but I lost that argument already :) 16:14 no, you're 100% right on that one, too :) it's just that they're in the same boat, heh 16:14 (same, we have our own tooling for vendoring because it’s not well supported and we start having copy) 16:14 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 didrocks: please do shoot liushuyu-011 a quick summary of the goal, where you got stuck, and hope there's a brainstorm :) 16:14 will try 16:14 thanks 16:14 thanks! 16:15 anything else? 16:15 nothing. 16:15 nothing else either 16:15 alrighty then :) 16:15 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)