=== Kuraokami is now known as IchabodCrane [14:31] hiho MIR people [14:31] o/ [14:31] one few more semi-calm weeks before 23.04 starts :-) [14:31] #startmeeting Weekly Main Inclusion Requests status [14:31] Meeting started at 14:31:50 UTC. The chair is cpaelzer. 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:32] hey cpaelzer [14:32] #topic current component mismatches [14:32] Mission: Identify required actions and spread the load among the teams [14:32] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:32] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:32] nothing new in there [14:32] as I said, the last few calm weeks :-) [14:32] o/ [14:32] wb slyon [14:32] #topic New MIRs [14:32] Mission: ensure to assign all incoming reviews for fast processing [14:32] #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:33] good morning [14:33] oh my [14:33] so much for calm [14:33] but hey I've wanred about that a few weeks ago [14:34] haha that's plenty of ruby MIRs [14:34] * didrocks removes his hand from the alarm button then [14:34] to be fair [14:34] it is a lot of very small usually easy packages [14:34] o/~ to be faaiir o/~ [14:34] instead of a single super massive one [14:34] hehe [14:34] ok let us talk about the non-pcs one first [14:34] https://bugs.launchpad.net/ubuntu/+source/libgit2/+bug/1990655 [14:34] -ubottu:#ubuntu-meeting- Launchpad bug 1990655 in libgit2 (Ubuntu) "MIR: libgit2, http-parser" [Undecided, Confirmed] [14:35] I haven’t noticed that slyon answered, the status is wrong though [14:35] that is the other known "there will be more" case by schopin [14:35] I need to have a reread and asses on libgit2, I will do that [14:35] (tomorrow probably) [14:35] ok, so I'll re-assign it to you for now didrocks [14:36] and depending on the outcome it goes to ack/nack/security next [14:36] yep [14:36] now around PCS [14:37] this was all meant to be doen in 22.10 but the dependency tree exploded on us [14:37] as you can see [14:37] I've asked to at least provide it very early for 23.04 because the item will move there [14:37] let us first distribute the "easy" ones - which are the 14 ruby-* cases [14:38] how about round robin them between the four of us being joalif didrocks slyon and myself ? [14:38] yup [14:38] that would be 3 or 4 of them for each of us [14:38] yeah, please note I have another pending, failing to trying to get one assigned and no time for review [14:38] but at least, for those, before 23.04 opens, that should be doable [14:38] yep [14:38] yes, though I might not be able to get all of them reviewed by next week. [14:39] hehe [14:39] that is totally fine [14:41] ok that set is done [14:41] you can reload the list now that the view is clearer [14:41] wow :) [14:41] we have pcs itself, two python* and "thin" [14:42] I guess in complecity this is (descending) pcs > tornado (but easier as it was in main before) > thin > dacite [14:42] this is again 4 [14:42] one each? [14:42] any preference? [14:43] since I'm the manager of the team driving it I'd prefer not to do pcs itslef for political reasons [14:43] other thna that I'm happy on any of them [14:43] OK, maybe something in the middle for me thin or tornado [14:43] ok tornado it will be [14:43] * didrocks picks randomly a python one, let’s take python3-dacite [14:44] joalif: are you ok to take PCS itself or does that make you cursing my name for the rest of the day? [14:44] LOL [14:44] cpaelzer: that's ok :) [14:44] to be clear - on this barrage no one expects a return of all next week [14:44] aim for 1-2 per week and we should be good [14:45] sounds good to me, let’s hope we don’t get the cargo stuff at the same time :) [14:46] we knew both will come [14:46] and one had to be earlier [14:46] if cargo comes next week it will just enqueue and still be ok [14:46] at the intended 1-2 per week that will still be very early in the 23.04 cycle [14:46] yes [14:46] and then sarnold knows his queue early on and can call for addition reviewers on security [14:46] #topic Incomplete bugs / questions [14:46] 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] libgit (we talked) and tuned (old) [14:47] nothing to discuss here IMHO [14:47] yeah, tuned still has no response… [14:47] oh well 27th Sept ?? [14:47] yeah that was you incompleting it [14:47] ok [14:47] #topic MIR related Security Review Queue [14:47] Mission: Check on progress, do deadlines seem doable? [14:47] #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 [14:48] no surprises here [14:48] sarnold: now that the plan for 23.04 slowly gets real - how about those smartcard things there? [14:48] will they be back on the roadmap? [14:48] I don't think much was done in the last week; mark is workingo n putting together a fuzz test harness for editorconfig-core [14:49] was that after you tried to say no [14:49] cpaelzer: heh, that's a good question; I think we have a meeting on our agenda with desktop team to see if that's still desired [14:49] and then realized it is already in the archive (bundled) [14:49] sarnold: is that a breakout session on one of the sprints? [14:49] cpaelzer: it should eb, yeah, thanks for the reminder, I'll doublecheck it :) [14:50] sarnold: while checking (I couldn't find it) could you ask for my name to be added to the invitee list please? [14:50] it's not great for editorconfig to be bundled into one program, but at least that limits the scope of flaws to whoever runs that one program, not all the dozen editors that use it [14:50] will do! [14:50] thanks [14:50] and that is an interesting insight into potential benefits of bundled sources :-) [14:50] yes :) [14:50] oh we forgot [14:50] Internal link [14:51] - ensure your teams items are prioritized among each other as you'd expect [14:51] - ensure community requests do not get stomped by teams calling for favors too much [14:51] #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 [14:51] well I forgot [14:51] now we [14:52] ncie confusion [14:52] smartcard has a pcscd [14:52] yes :( [14:52] and we now entered pcs and pscd for HA [14:52] not to be mistaken for pcscd [14:52] arr [14:52] anyway, next agenda entry [14:52] #topic Any other business? [14:52] nothing here [14:52] none from me, except thanking you for spreading the pcs load [14:52] I have one [14:53] didrocks: did you already have a chance to look into bug #1991508 [14:53] -ubottu:#ubuntu-meeting- Bug 1991508 in licheerv-rtl8723ds-dkms (Ubuntu) "MIR licheerv-rtl8723ds-dkms" [Undecided, New] https://launchpad.net/bugs/1991508 [14:53] so, I have not yet fully check for https://bugs.launchpad.net/bugs/1991508 [14:53] slyon: this is what I told before, I haven’t the time to start it [14:53] however, this is another case of new hardware support [14:53] I was asked by Foundations to push for this as it seems to be required to build usable LiceeRV 22.10 images for the release [14:53] with no test [14:54] slyon: well, TBH, that request should have got scheduled way before FF :) [14:54] so, there is no testplan either [14:54] (I find that a lot of MIRs are too easily filled without fulfilling any test requirement) [14:54] I feel that at least, someone has access to the hardware somewhere [14:54] and there should be a written testplan [14:54] It ends in the usual "this should at least be a compromise - what testing could you offer" sitation [14:54] I think the hardware is available at my team mates... but it would require a manual test plan, right? [14:54] what do people think? [14:55] yes a manual test plan and proof that it is executable (e.g. a sample log) is much better than [14:55] yeah, and I am a little bit unhappy TBH that it’s the 3rd MIR in a row where the testing requirement is simply discared [14:55] (not only Foundation, but cross team) [14:56] I’m wonder how we can emphasize "If you don’t say what’s your plan on this, this is not even something we are considering" [14:56] yep, but each time we got at least something out of insisting which is better than just doing nothing [14:56] ack on that didrocks [14:56] people should try to comply without us rejecting it first to force it [14:56] yeah, it’s just that maybe the test is no clear enough? Should we use bold/scary message on the template? :p [14:56] ack on that, indeed [14:57] didrocks: I'm happy to make it more scary, but I do not have great words for it in cache atm [14:57] there is a comment in the description, "we commit to install and test this package for each new kernel that would be released, which is enough to make sure it still works" [14:57] whoever gets to it is welcomed to throw a PR at https://github.com/canonical/ubuntu-mir [14:57] sarnold: right, but this is not a testplan, written down [14:57] ahh [14:57] and what if the person writing this has this somewhere on his head and leave? [14:57] hence writing is better :) [14:58] didrocks: do you see any chance this licheeRV MIR could be resolved ahread of release if a testplan is provided in a timely manner? [14:58] (i.e. today/tomorrow?) [14:58] I mean what ar ewe trying to do here a) keep ubuntu great and b) ensure teams are not digging their own grave - I think it is helpful (and not mean) to be more explicit what/why a test plan is expected [14:58] slyon: as you are in touch with whoever is pushing this to write the testplan? I still hope to be able to review it in parallel before EOW [14:58] I can’t commit for today/tomorrow unfortunately, as I’m already max out [14:58] didrocks: slyon: is this looking like it also needs a round of security? [14:59] doesn’t look like it (from the description) [14:59] it is a kernel module after all right? [14:59] right [14:59] EOW should be fine, I guess. I'm in touch with Alex and Heinrich and will ask them to provide a testplan ASAP [14:59] ok, I'm sure you'll make the right call didrocks [14:59] and slyon will get the team crunching on completing this to be acceptable [14:59] kernel module, I will have to look how scary the code is [14:59] ok [14:59] any other - other topics? [14:59] slyon: sounds good, thanks! [14:59] ok, thank you! [14:59] i have one [14:59] i'm reviewing libssh2 [15:00] I'm slightly disctracted by other meetings now- but go joalif [15:00] https://bugs.launchpad.net/ubuntu/+source/libssh2/+bug/1991650 [15:00] -ubottu:#ubuntu-meeting- Launchpad bug 1991650 in libssh2 (Ubuntu) "MIR: libssh2" [High, New] [15:00] my other (parallel) meeting just ended :) [15:00] what is the question there joalif? [15:00] libssh with same functionality in main, however chopin's argument "Regarding the feature duplication between libssh1 and libssh2, the Rust bindings for the latter are well-maintained and see substantial usage, whereas the former are barely used..Given that FFI bindings are one of the trickiest area of Rust in terms of unsafe code, I believe it safer not to try and port cargo to libssh1." [15:00] sounds ok to me [15:01] what do you think ? [15:01] to me that is a reasonable explanation why duplication is needed, although it makes me sad that we have to have two [15:01] let me check why the deps I knew have changed ... [15:01] I'm not sure they're as 'duplicate' as their names would sound, https://www.libssh2.org/libssh2-vs-libssh.html [15:02] oh they are not "the same" [15:02] puzzling [15:02] They're similar enough that I thought justification was warranted :) [15:03] yup, btw great work on MIR bug schopin [15:03] good instinct :) [15:04] what is holding libssh in main? [15:05] maybe they could switch to libssh2 as well? [15:05] oh I see, curl and cryptosetup and a few - hmm maybe not [15:05] curl actually links against libssh2 by default upstream [15:05] I'm leaning to "it was tried to not duplicate too much => ok" [15:06] schopin: I was only looking at revdeps [15:06] maybe once libssh2 is in we could do a check which could/would check [15:06] qemu would be ok to change IIRC [15:06] you say curl as well [15:06] libvirt would be ssh2 compat as well [15:07] I'll put that as a roadmap idea for next cycle :) [15:14] thanks schopin [15:14] and by that and no other comment [15:14] let us close this meeting for today [15:14] thank you all! [15:14] thanks cpaelzer, all :) [15:14] #endmeeting [15:14] Meeting ended at 15:14:32 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-10-11-14.31.moin.txt [15:14] thanks cpaelzer , all:) [15:16] thanks! [15:22] thanks! o/ [18:52] o/ [18:58] o/ [19:00] o/ [19:01] o/ [19:01] cyphermox waved as well! [19:01] yeah, I did [19:03] Great! Hello! [19:03] Who's chairing? [19:04] Does anyone have any actual progress to report? AIUI, everything on the agenda is still in progress. [19:05] I will chair [19:05] vorlon would be double-booked, AIUI? [19:05] I believe he can't make it today [19:05] Based on his email earlier [19:05] yep [19:06] Yeah, I sadly don't have much to report on my end, as I only recently got back from my vacations [19:06] #startmeeting Ubuntu Technical Board [19:06] Meeting started at 19:06:23 UTC. The chair is cyphermox. Information about MeetBot at https://wiki.ubuntu.com/meetingology [19:06] Available commands: action, commands, idea, info, link, nick [19:06] #topic Action review [19:07] guess this is all still in motion, as rbasak mentioned? [19:07] Ubuntu Unity is done I think [19:07] The rest is in progress or pending I think [19:08] Same with the third party repository policy [19:08] yeah I'm looking at the last agenda, seems right [19:09] should I just continue and we make this meeting short? [19:09] fwiw, I had re-pinged the CC for the elections [19:11] okay [19:11] #topic Definition of our third party repository policy. See https://docs.google.com/document/d/1apUKR4gtOrfPGCWmtoebaQUhoy-fG8Cyo3VKJyhnpD0/edit [19:12] Still in progress [19:12] #link https://docs.google.com/document/d/1apUKR4gtOrfPGCWmtoebaQUhoy-fG8Cyo3VKJyhnpD0/edit# [19:12] I am speaking to people and have been gathering feedback. [19:12] rbasak: thanks! [19:12] fwiw, it just threw me an "access denied" [19:12] nah nevermind [19:12] it was a misclick [19:13] #topic Scan the mailing list archive for anything we missed (standing item) [19:14] the schedule for elections is already adequately covered, I think? [19:14] and then there's Steve's request to switch the schedule back [19:15] Are we all agreed on Steve's proposed new schedule? [19:15] tbh, I'm really *really* bad with the meeting being every two weeks, because I often am double-booked or not in a position to be on IRC, but it's on my to fix myself harder [19:15] I already provided my +1 on the ML. [19:15] I'm okay with the schedule change [19:15] +1 on the schedule change from me [19:15] who would update the fridge? [19:15] Only Steve can update the fridge AIUI, since he created the original calendar item. [19:15] I asked him to do it in my reply. [19:16] perfect [19:16] Although maybe he could click "Guests can modify event" [19:16] well, it works as long as the fridge does accurately represent the real schedule [19:17] fyi, I won't be able to make it to the Summit after all; I don't know who will be, but I thought it would be good to have a short presentation on the Technical Board, assuming it's not too late to schedule that already [19:17] #topic Check up on community bugs (standing item) [19:20] Nothing in LP [19:20] #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) [19:20] who is next? [19:22] Maybe leave sil2100 for next time and put me down as backup? [19:22] ok [19:22] It's not like there are many of us! [19:22] otherwise I was going to say I would do it, and put you as backup [19:22] +1! [19:22] haha :) [19:23] #topic AOB [19:26] anything? [19:27] Nothing from me thanks [19:28] great! [19:28] #endmeeting [19:28] Meeting ended at 19:28:24 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-10-11-19.06.moin.txt [19:28] thanks everyone! [19:31] Thank you for chairing! [19:52] o/