15:00:00 <pjgeorg> #startmeeting Kmods SIG
15:00:00 <centbot> Meeting started Mon Oct  4 15:00:00 2021 UTC.  The chair is pjgeorg. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:00 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:10 <pjgeorg> #chair pjgeorg billings
15:00:10 <centbot> Current chairs: billings pjgeorg
15:00:51 <billings> Good day
15:01:06 <pjgeorg> Hi
15:01:19 <pjgeorg> #topic CentOS Dojo talk
15:02:05 <pjgeorg> I added 4 slides about packaging considerations.
15:03:49 <billings> Excellent, I was going to suggest you put what you discovered about the kabi kernels into slides
15:04:00 <billings> It'd be interesting if you could summarize which ones needed it
15:04:11 <billings> oh its there!
15:04:15 <billings> hah, in slide 8
15:04:49 <billings> One of the things we talked about early on was some way to kick off a rebuild when a new kernel release shows up, so we could see what succeeded and what failed
15:05:44 <billings> Or can we tell without even needing a rebuild?
15:06:06 <pjgeorg> We can tell whether a rebuild is required without rebuilding.
15:06:59 <billings> if we build the package to track the kabi
15:07:30 <pjgeorg> I currently track the kabi in a pagure project.
15:07:45 <billings> https://pagure.io/centos-sig-kmods/kabi ?
15:08:19 <pjgeorg> All this (generating the kabi repo and checks) is done using local scripts. I plan to move that stuff to some CentOS CI task. THat's something I'd like to mention in the talk.
15:08:21 <pjgeorg> Yes
15:10:05 <billings> Sounds good.
15:11:30 <pjgeorg> So that's for Open Issues/Tasks in the Agenda.
15:11:54 <billings> on slide 8, you might want to say "On average" and not "On Average"
15:12:25 <pjgeorg> Looking at Progress report: Probably enough to list available packages there and info that already available in -testing? (See quarterly report)
15:12:50 <billings> I have a new package I'm testing kmod-ksmbd
15:13:10 <billings> I think I have testing package, but I haven't switched it to the kabi-tracking spec
15:13:16 <billings> which is something I'd like to do
15:19:53 <pjgeorg> We can add it to the list of packages on slide 10
15:20:45 <billings> this is similar to the ntfs3 thing
15:20:51 <billings> and maybe kafs
15:21:02 <billings> stuff that is disabled in the RHEL kernel .config
15:21:18 <billings> or is that exFAT and Wireguard too?
15:23:25 <pjgeorg> exFAT and WireGuard are the same as well.
15:23:47 <billings> Yeah, I'm thinking a bullet point they could all be under
15:24:58 <billings> ntfs3 is in the kernel?
15:25:03 <billings> or will be in 5.15?
15:25:03 <pjgeorg> Yes, since 5.15
15:26:08 <billings> Ok, I like this slide, maybe we can list some examples under the "Rebuilds of kernel modules with Red Hat specific restrictions removed..."
15:26:20 <billings> Although this is getting verbose already
15:26:48 <pjgeorg> Probably too verbose then.
15:27:15 <billings> We could split it into two slides
15:27:49 <pjgeorg> Should we add a note that some of the packages listed under "Kernel modules disabled in the RHEL kernel config" have been added after RHEL 8 has been branched?
15:28:05 <billings> Oh, good point
15:28:05 <pjgeorg> Splitting into two slides is a good idea. We'll probably add even more there anyway.
15:28:31 <billings> Maybe keep the kernel modules disabled... bullet but move the examples into a new slide, that way you can add the note about being added after branched
15:34:29 <pjgeorg> I'd have moved the full list to a seperate slide, i.e. only keeping the first two bullet points on the current one.
15:35:14 <billings> Hmm, let me close and re-open the document
15:38:22 <billings> Great
15:40:21 <billings> sorry I added that to a slide where it didn't make sense
15:40:33 <billings> Maybe it needs to go in the list of packages line?
15:41:15 <pjgeorg> For now a just added a simply "... or added to upstream later" to that bullet point
15:41:45 <billings> That makes much more sense
15:44:34 <billings> do we want more testers?
15:44:57 <billings> or at least a test plan for each module?
15:45:11 <billings> I feel like that need to be an issue I submit
15:45:50 <billings> some modules can be tested in VMs but many of the hardware ones cannot
15:46:07 <pjgeorg> Not sure that's something we can cover within this SIG. We probably can only due basic testing, i.e. installing the RPM and loading the kmod.
15:46:53 <billings> Good point.
15:46:55 <pjgeorg> Shall we repeat the Signing and DD issue on slide 13?
15:47:12 <billings> yes, particularly since they'll probably show up in questions
15:49:11 <billings> I just copy/pasted, I don't know if any other comments are needed
15:49:54 <arrfab> pjgeorg: talking about DuD, we got a pointer in the issue you created in upstream koji
15:50:06 <arrfab> so basically : nothing really exists in koji
15:50:11 <pjgeorg> Maybe remove the sub bullet points, we already explained this before
15:50:34 <arrfab> if by "signing" you mean secureboot, don't think we had any momentum to fix it or even just a solution
15:50:50 <arrfab> I should revisit to see what the centos board/RH liaison told about it
15:51:01 <pjgeorg> arrfab: Yes, just got an email notification. I have to say that I do not like ddiskit at all.
15:51:04 <billings> I thought i saw something about it internally
15:51:14 <pjgeorg> Yes, talking about secureboot.
15:51:25 <billings> but I suspect we're going to have to just tell people to disable secure boot in the mean time
15:51:39 <arrfab> afaik, no solution at all at this stage
15:52:23 <arrfab> from jwboyer 's comment, it seems that centos SIG will never be granted right to build kernel/kmods with the centos key
15:53:47 <pjgeorg> I never expected to be allowed to sign using the centos key. We'd be happy with a SIG specific key.
15:53:58 <arrfab> we don't have hardware for that either
15:54:59 <billings> Doh, I have another meeting in 5 minutes
15:55:10 <billings> Do we need to discuss anything more?
15:55:34 <pjgeorg> I think we are good. I'll add few more stuff to the slides.
15:55:36 <arrfab> and btw, it would have to be presented as an initiative for CPE to be able to work on this, and as Q4 plans are fixed and secureboot wasn't even on the list, that will be for next year, but only if it goes to cpe-initiatives
15:56:11 <arrfab> pjgeorg: if you want to give that a try : https://pagure.io/cpe/initiatives-proposal/issues/
15:56:55 <pjgeorg> arrfab: Thanks. Didn't know about that process at all. I thought the issue https://pagure.io/centos-infra/issue/307 was sufficient. I'll have a look at it.
16:00:09 <pjgeorg> #endmeeting