14:31 #startmeeting Weekly Main Inclusion Requests status 14:31 Meeting started at 14:31:17 UTC. The chair is slyon. 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 14:31 c_paelzer is on vacation AFAIK 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:32 c-m looking as usual (except for network-manager -> iwd, which is also in c-m-proposed) 14:32 c-m-proposed: 14:32 hey o/ 14:33 I was able to get a few things moving, namely systemd -> systemd-hwe and mutt -> gsasl 14:33 \o/ 14:33 looks like network-manager -> iwd -> ell also resolved the leaf level 14:33 and the lintian dependencies are making some progress \o/ 14:34 I see nothing else noteworthy in there.. 14:35 should we point out to the kernel team that their linux-raspi-unstable appears to be in universe? 14:35 I don't know how their packages are arranged, it probably doesn't really matter one way or another 14:36 oh right that seed change! 14:36 who could we ping about that? 14:38 good question; on the one hand, I think apw is an archive admin and would know how to sort it out quick, but pinging one person in a big team isn't great; maybe just drop it in ~Kernel and see if it falls off the list next week? :) 14:38 sarnold: sounds like a plan! Would you mind doing that? 14:38 sure thing! 14:38 thanks 14:38 #topic New MIRs 14:38 Mission: ensure to assign all incoming reviews for fast processing 14:38 #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:39 tuna and tuned 14:39 We have two new cases ^ bug #1988066 14:39 Bug 1988066 in tuned (Ubuntu Jammy) "[MIR] tuned" [High, New] https://launchpad.net/bugs/1988066 14:40 it doesn’t seem that it’s following the template, like elements about tests have been removed for instance 14:40 well. actually, it’s modified from the template and written with: 14:40 * No Test Suite shipped with the package 14:41 so could still be reviewed 14:41 (I have been p-uzzled by the Overview section) 14:41 seems like this will be maintained by the kernel team. 14:41 and i dont understand if it's 2 source packages or 1 14:41 hmm; we have tlp and gamemode in main already 14:42 do we have any volunteers to have a look at that? 14:42 joalif: it's two source packages, src:tuna and src: tuned 14:42 seems to be two according to launchpad 14:42 TBH, not sure I can commit this week. I finished yesterday the 2 on -perl and spent some times on it 14:42 so if it can be only handled next week (after next meeting), I can take one 14:42 I cannot commit to anything this week either, as I'll be out on vacation in 2 days 14:43 joalif: are you interested (and have capacity) to take one of them? I think you still have the other 2 -perl reviews on the list, though 14:43 yes 14:44 I've done the other 2 14:44 a couple of hours earlier 14:44 joalif: thanks! So feel free to pick one (or both, if you're feeling lucky ;-) ) and assign your name to in on launchpad 14:44 they are on security now 14:44 i'll take one 14:44 joalif: ah perfect, thanks a lot. I didn't see that yet 14:45 @slyon I took tuna 14:45 I’ll probably wait on next week before grabbing it, in case someone beats me to it :) 14:45 #Info joalif to review tuna 14:45 okay. so we'll leave tuned untouched for now, to be assigned next week 14:46 #info tuned to be assigned next week 14:46 #topic Incomplete bugs / questions 14:46 Mission: Identify required actions and spread the load among the teams 14:46 #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 bug #1963707 14:47 Bug 1963707 in libqrtr-glib (Ubuntu) "[MIR] libqrtr-glib" [Low, Incomplete] https://launchpad.net/bugs/1963707 14:47 seb asked a question about hardware availability... 14:48 didrocks: do you know if we had similar cases in the past? where MIR team is requiring that the hardware is available for testing? 14:48 I think it makes sense to have that requirement, otherwise the manual test plan is useless (unless testing is done by the community..) 14:49 slyon: the hardware/fallback to manual test is quite recent actually (like a year ago?) when we started to make tests a requirement 14:49 but the team committed to do the manual testing, which doesn't work without hardware 14:49 which is a good thing I think, but we don’t have precedence 14:49 most of stuff comes with tests. desktop components don’t often unfortunately :/ 14:49 so yeah, we are quite in a blocking situation here 14:50 I don’t feel it’s good to continue delivering things without testing (automatically or at least manually) 14:50 I agree, we should stick to the testing requirement 14:50 didrocks: +1 not that i have much to say as i don't work at Canonical, but is that modem avalible in cheaper usb devices? 14:50 I guess the fact that he is upset is about the ACK, then NACK 14:50 just a random tough 14:51 yes, that ACK->NACK was a bit unfortunate. 14:52 luna__: didrocks: I'll add a comment, that we want to stick to that requirement 14:52 TBH, if they haven’t told us they didn’t have the hw, we wouldn’t know 14:52 so I think that no proof of automated tests, for all new components, is maybe the wrong path 14:52 (even if it’s a simple test) 14:52 and I don’t feel that every upload will follow the testplan 14:53 so… on that topic 14:53 we should make our QA team entering the discussion 14:53 as in the end, they will be the one owning the testing story 14:53 and they should be the ones deciding if the component is enough testing or not, and how 14:53 +1 14:53 rather then the MIR team 14:53 oh, do we have a qa team that's staffed enough to do those things? 14:53 unsure about the staffed enough part :p 14:53 but bdmurray is leading it AFAIK? 14:54 something to discuss at next IRL sprint? 14:54 cc bdmurray: ^ (we'd be interested in the QA teams opinion on the "manual testing" story for packages in the main component) 14:54 yes, that might be a good topic for the next IRL sprint 14:57 OK, i added a comment. moving on 14:57 bug #1986591 14:57 Bug 1986591 in fstrm (Ubuntu) "[MIR] fstrm" [Undecided, Incomplete] https://launchpad.net/bugs/1986591 14:57 tracking update 14:58 vpnc-scripts: tracking update & seems to be still actively worked on, bug #1987571 14:58 Bug 1987571 in vpnc-scripts (Ubuntu) "[MIR] vpnc-scripts" [Undecided, Incomplete] https://launchpad.net/bugs/1987571 14:59 bug #1987447 is still searching for an owning team 14:59 Bug 1987447 in python-mechanize (Ubuntu) "[MIR] python-mechanize" [Undecided, Incomplete] https://launchpad.net/bugs/1987447 15:00 same story with #1987448 15:00 bug #1987448 15:00 Bug 1987448 in stoken (Ubuntu) "[MIR] stoken" [Undecided, Incomplete] https://launchpad.net/bugs/1987448 15:00 yeah, we should probably something in the MIR template 15:00 same, bug #1987446 15:00 Bug 1987446 in openconnect (Ubuntu) "[MIR] openconnect" [Undecided, Incomplete] https://launchpad.net/bugs/1987446 15:00 that first, agree with the owning team that they will own it 15:01 same bug #1987446 15:01 didrocks: that sounds like a very useful addition. Would you mind creating a PR to update the template accordingly, so it can be discussed next week? 15:01 sigh. I thought I was clear to luis that he needs to find someone to own these packages. 15:02 slyon: will do! 15:02 thanks! 15:02 bug #1980662 (lintian vs *-perl) needs some work on two packages and sec-review on the other two, thanks joalif and didrocks for the reviews! 15:02 Bug 1980662 in lintian (Ubuntu) "[MIR] lib*-perl for lintian 2.115" [Undecided, Confirmed] https://launchpad.net/bugs/1980662 15:02 nothing to do for us on those. 15:03 #topic MIR related Security Review Queue 15:03 Mission: Check on progress, do deadlines seem doable? 15:03 #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:03 sarnold: 15:03 the good news is that we worked through far more of our backlog than I thought possible, thanks to the team for pitching in! 15:04 the bad news is that the rest of the team has some very high priority work that cannot be delayed further, so it'll return to just me for a bit, and I'm not yet over covid, so might not be as productive as usual (heh) 15:04 good luck :/ 15:04 mdevctl is in progress, nullboot is a hot potato, and these new lib perl packages don't feel like the usual lintian "oh yeah that's fine" faire :( 15:05 I'll see what I can do to keep making progress ;) but it won't be like the last two weeks, that's for sure 15:06 yes I saw a lot of security review in the last weeks, which is very nice. But I'm aware of (some of) the current "hot" security topics, which of course need to take priority 15:07 #topic Any other business? 15:07 yes 15:07 nothing from me 15:07 ddstreet has found greener pastures; do we need to find someone to replace his inputs? 15:07 not from me 15:07 luna__: thanks for your interest and contribution to the MIR process 15:07 no problem, had some spare time today 15:07 sarnold: joalif was ddstreet's replacement, AFAIK 15:08 slyon: aha! 15:08 * sarnold falls over 15:08 yup 15:08 I've read the backlog and I think the libqrtr-glib requirement is a bit unfortunate. If we don't have the hardware nor budget to buy some it means we can't enable support for our users 15:08 it's lucky that the kernel doesn't go through MIR review with the current rules 15:08 NAK NAK NAK NAK 15:08 we would have lot of hardware support missing in Ubuntu :p 15:08 :D 15:08 "please come back with a more secure kernel kthxbye" 15:09 joke aside, I don't really know how to resolve it at this point, I can ask to expense so laptop for testing but I've an idea how that's going to end up 15:09 seb128: the test plan really could have been "I have a buddy with a laptop who promised to test every single update when we need it", I think 15:10 .. assuming your buddy is that willing? 15:10 I didn't find anyone owning that hardware though 15:10 The kernel is a special case, indeed. but we try to apply the new and improved rules as strictly as possible, at least for any new promotions 15:10 just a few random users who complain about Ubuntu not supporting things that works in fedora 15:10 it's frustrating to not be able to have an answer :/ 15:11 slyon, I think hardware is sort of a special case 15:11 how not supporting the hardware at all is a win for anyone? 15:11 its not 15:11 if we don't do any testing, we might end up with a broken system, which might be worse than a known missing hardware support 15:11 which is also true for the kernel... 15:12 it's an inconsistent policy 15:13 I agree there's an inconsistency and we should bring it up for discussion, maybe during the next engineering sprint 15:13 slyon, I think it's inconsistent also with the initial position we took for Ubuntu 15:13 we always said hardware support was important and we wanted to enable as much hardware as possible, at the extend to allowing binary drivers 15:14 anyway, I made my point, I don't feel like I will have more traction on the topic unless I decide to escalade to the TB? 15:14 * luna__ agress with seb128 15:14 nvidia is also a problem :( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1853977 15:14 Launchpad bug 1853977 in nvidia-graphics-drivers-340 (Ubuntu) "nvidia-340 dpkg: error: version '-' has bad syntax: revision number is empty" [Undecided, Confirmed] 15:14 yes. I can see both sides of this. But I don't feel senior enough to make a call about this right now... 15:14 I'm not asking for a call to be made today 15:15 maybe before escalating it to the TB, we might loop in c_paelzer into the discussion, once he returns from vacation (next week AFAIK) 15:15 k, I will wait for him to be back before raising to TB 15:15 thanks 15:15 thanks! 15:15 the more I think about it, the more I think the QA team should be owner of this testing requirements 15:15 they are the one identifying gaps, and ultimately, being reponsible of the distro 15:16 if we have one, I agree :) 15:16 didrocks, it's easier for software than for hardware where budget is often a blocker as you know :/ 15:16 so we should also loop in bdmurray and paride 15:16 but yes, included QA makes sense 15:16 seb128: oh yeah, I know… remember on pitti’s day and how he tried to mock edge packages? but for that, we need staffing… 15:17 I've also tried to reach to oem but they aren't enabling models with that hardware atm 15:17 maybe we should restrict the hw requirements on certified hw? 15:17 this is another opportunity 15:17 didrocks: seb128 +1 15:17 and then, it’s up to have a testsuite running in the oem lab 15:18 didrocks, slyon, so the decision is that I should rollback the modemmanager depends to unblock proposed at this point I guess? 15:18 but how do we know which hardware is available in the cert lab? And what if that set of hardware changes? 15:19 Wiki page, Libreoffice Spreadsheet? :D 15:20 seb128: If you want it now, then that's unfortunately the way to go, I guess. If you can wait 1-2 more weeks, we might be able to continue that discussion with more team members and possibly come up with a solution (or exception) 15:20 https://wiki.canonical.com/PES/Infrastructure/TestFlingerDevices ? :) 15:20 sweet! ^ 15:20 granted, it isn't at the granularity of "what modems are on these devices" 15:20 so my Wiki page idea was not all that dumb then 15:20 lspci, lsusb, lshw on everything ;) 15:21 slyon, I think we can wrap that topic for today and try again when Christian isback 15:22 sorry for delaying the end of meeting 15:22 its all fine 15:22 seb128: okay. thanks for your input! 15:22 #endmeeting