15:04:43 <pjgeorg> #startmeeting Kmods SIG
15:04:43 <centbot> Meeting started Mon Jul 26 15:04:43 2021 UTC.  The chair is pjgeorg. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:43 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:05:00 <pjgeorg> #chair pjgeorg billings
15:05:00 <centbot> Current chairs: billings pjgeorg
15:05:31 <pjgeorg> #topic Open issues
15:05:40 <pjgeorg> Probably best to start with the open issues.
15:05:53 <billings> I've built a kmod-kafs package for centos 8 stream
15:06:10 <billings> but I've not done anything but put it in the test build tags
15:06:59 <pjgeorg> I have seen it. Looks good.
15:07:24 <billings> I'm not thrilled with how I managed to get it to build, I'm afraid that I couldn't use the mechanism in the example spec
15:07:46 <billings> but perhaps that will be an issue for other kmods so hopefully it helps.
15:10:19 <billings> so, I've buit in kmods8s-packages-main-candidate, but I had to modify that tag to allow kmod-kafs to be included
15:10:31 <billings> I'm not sure how you'd like for me to proceed
15:10:48 <pjgeorg> What changes have been required?
15:11:11 <billings> "cbs add-pkg --owner jsbillings kmods8s-packages-main-candidate kmod-kafs"
15:11:25 <pjgeorg> Ok. Seems fine.
15:11:54 <billings> Ok, just wanted to make sure I wasn't stepping on anyone's toes, I don't know who maitains those tags, the kmod or some koji master
15:12:02 <billings> er, the kmod SIG or. ..
15:12:19 <pjgeorg> I do not know as koji is new to me anyway.
15:12:34 <billings> same.  But it looked like the right thing to do. :)
15:13:14 <pjgeorg> Anyway, as you already started building the first package it probably time we get centos-release-kods done.
15:13:26 * billings nods
15:13:40 <pjgeorg> The package should be ready and is available on pagure.
15:13:50 <billings> then I can add my package to kmods8s-packages-main-testing and then eventually to kmods8s-packages-main-release
15:14:20 <pjgeorg> Have you had a chance to have a look at the centos-release-kmods repository I pushed?
15:14:26 <billings> I'd like to also build for s9s (my package would most likely be significantly better there, since the kernel is much newer)
15:14:43 <billings> in pagure?  I think that looks right, it's based on the template I think
15:15:04 <pjgeorg> c9s is still not available, we'll have to wait. There's nothing we can do.
15:15:11 <billings> I'm not sure how one generates the GPG keys
15:15:44 <pjgeorg> I just copied one of the available centos-release-* packages and modified it.
15:15:53 <pjgeorg> The GPG key has been generated for us. Nothing we do.
15:16:02 <billings> Excellent, that's what I hoped it did. :)
15:16:17 <pjgeorg> Then I'll request a centos-release-kmods repository to be created on git.centos.org
15:16:18 <billings> (I don't want to be stuck holding those keys)
15:16:34 <pjgeorg> #action pjgeorg Request centos-release-kmods repository on git.centos.org
15:16:54 <billings> It looks like a lot of the 9stream development happens in gitlab
15:17:07 <pjgeorg> I guess I'll then also need to open an issue on centos-infra requesting to build and push centos-release-kmods.
15:17:18 <pjgeorg> #action pjgeorg Request build and push centos-release-kmods
15:17:23 <billings> thanks
15:17:56 <pjgeorg> Yes, 9stream development happens in gitlab. But I haven't seen any information yet how SIGs will be handled for 9stream. gitlab as well or still git.centos.org?
15:18:31 <pjgeorg> The last two actions should then close issue #3
15:18:49 <billings> Excellent
15:18:52 <pjgeorg> Which means we only have #4 left: kmod package structure.
15:19:45 <pjgeorg> jcpunk had some good ideas about auto-detected the latest kernel to allow easy rebuilds for new kernel releases.
15:20:00 <jcpunk> hopefully those prove useful
15:20:12 <pjgeorg> Yes, they already did.
15:20:15 <jcpunk> :)
15:20:37 <pjgeorg> Have you had time to look at this PR to detect latest kernel? https://pagure.io/kmod-wireguard/pull-request/3
15:21:27 <pjgeorg> It's a little bit different to what you did. But I think it implements your idea "Set a minimum supported kernel version, but build for the latest available"
15:21:36 <jcpunk> I think that looks great :)
15:22:16 <billings> it would be fantastic if we could have the build targets we use populate the latest kernel version in a --define
15:22:33 <billings> I know that's a problem I deal with when building some out-of-tree kmods
15:23:03 <pjgeorg> That'd be an alternative to the approach in https://pagure.io/kmod-wireguard/pull-request/3. However I'm not sure one can do that.
15:23:28 <jcpunk> In theory we can get a custom package added to the buildroot by default.  If we added one that just ran the rpm query and set the macro would that work?
15:24:26 <billings> Maybe.
15:24:38 <pjgeorg> Not sure. Probably something to talk with centos-infra about?
15:24:48 <jcpunk> probably
15:24:53 <billings> I jump through a lot of hoops, in my spec I do: %{expand:%(sh %{SOURCE13})} and then %source13 is https://github.com/jsbillings/openafs/blob/master/find-installed-kversion.sh
15:25:04 <jcpunk> also https://bugzilla.redhat.com/show_bug.cgi?id=1982421
15:25:49 <billings> but I've discovered that the metadata in /usr/include/linux/version.h doesn't work anymore for c8 vs rhel8.
15:25:55 <jcpunk> :(
15:26:16 <billings> the %dist is el8_4 in RHEL8 but el8 in c8s
15:26:32 <pjgeorg> Does the way I use in https://pagure.io/kmod-wireguard/pull-request/3 not work for you?
15:26:35 <billings> so doing a rpm query seems to be the best.
15:26:49 <billings> kernel-devel has to be installed
15:26:55 <billings> and it isn't by default
15:27:19 <billings> the RPM spec is evaluated *before* the BuildRequires are
15:27:47 <billings> that's why I used kernel-headers, which I believe is in most build chroots
15:27:57 <pjgeorg> Yes, that'S why I need to do this weird stuff 30-43.
15:28:14 <pjgeorg> in line 30-43.
15:28:22 <billings> but in I see
15:28:28 <billings> er, I see
15:29:23 <pjgeorg> I only tested it in mock so far. But I guess CBS is similar.
15:29:24 <billings> so the spec is evaluated multiple times, once before the buildrequires and once after
15:29:35 <billings> fun
15:29:56 <pjgeorg> Yes. It indeed is. Took me some time to figure out how to solve it.
15:31:26 <pjgeorg> After doing this I also applied some of these ideas to the kmod-isci package I already push to pagure/centos-sig-kmods some time ago.
15:32:04 <pjgeorg> Instead of using the CentOS Stream kernel source code I now use upstream source code.
15:32:41 <billings> why "| grep -v kernel-devel"
15:32:44 <billings> in the command
15:32:44 <pjgeorg> To store this source code in a repository I now simply use two different branches: c8s (source-git) and c8s-sig-kmods (dist-git).
15:32:52 <billings> you're only running rpm --qf version-release
15:32:59 <billings> there should never be a kernel-devel output
15:33:18 <billings> "rpm --query kernel-devel --queryformat '%%{VERSION}-%%{RELEASE}\\\n' | grep -v kernel-devel;"
15:33:19 <pjgeorg> In case no kernel-devel is installed. It will say something like No package kernel-devel installed
15:33:26 <billings> ah
15:33:43 <pjgeorg> Sadly you can not silence this error message.
15:34:06 <pjgeorg> (and it's on stdout, not stderr)
15:34:23 <billings> I'd probably use the whole message just so slow people like me understand
15:34:59 <pjgeorg> I can change that.
15:36:37 <pjgeorg> The changes to kmod-isci I've been talking about can be found here: https://pagure.io/kmod-isci
15:37:22 <pjgeorg> This package can currently be built for any CentOS Stream 9 kernel ever released without any changes :)
15:37:31 <pjgeorg> Stream 8 of course
15:37:38 <billings> hmmm
15:38:02 <billings> if the system doesn't have kernel-devel 4.18.0-315.el8, the sed line will return no output
15:38:13 <billings> is that likely?
15:38:40 <pjgeorg> Do you mean not installed or not available?
15:38:42 <billings> I tested this on a RHEL8 system
15:39:01 <billings> https://paste.centos.org/view/783f88c5
15:39:22 <billings> er, sorry for the duplicate sort -V
15:40:36 <pjgeorg> In case kernel-devel 4.18.0-315.el8 (or any newer kernel) is not available it should not return any output.
15:41:03 <pjgeorg> In this case line 39 will then say BuildRequires:    kernel-devel >= 4.18.0-315.el8
15:41:13 <pjgeorg> This BuildRequires is not fulfilled.
15:42:40 <pjgeorg> In case you want to build for an older kernel than kernel_version_min you have to manually specify --define kernel_version....
15:43:18 <billings> well, we can move on, any issues I have I can add to the pagure
15:44:47 <pjgeorg> Ok. You might also have a look at the new kmod-isci (https://pagure.io/kmod-isci) later as well. This might also be a good approach or your kmod-kafs package.
15:45:24 <billings> the kernel-version-min-latest-spec branch?
15:46:16 <pjgeorg> Yes, and the way https://pagure.io/kmod-isci/ is structured in general.
15:47:03 <billings> Yeah, I'm basically using the same disk structure
15:47:39 <billings> obviously, as I mentioned earlier, the way it does %build won't work for kmod-kafs
15:48:17 <pjgeorg> I think you are talking about this kmod-isci https://pagure.io/centos-sig-kmods/kmod-isci ?
15:48:53 <pjgeorg> Own git repository for source code vs. extracting the source code from CentOS Stream kernel.
15:49:08 <billings> ah
15:49:15 <billings> https://pagure.io/kmod-isci/tree/kernel-version-min-latest-spec is what I was looking at
15:49:30 <billings> https://pagure.io/kmod-isci/tree/c8s must be what you're talking about
15:50:30 <pjgeorg> Yes. c8s is the branch that contains the source code. c8s-sig-kmods contains the packaging stuff (kernel-version-min-latest-spec is branched off c8s-sig-kmods).
15:50:50 <billings> I looked at the spec in both
15:50:55 <billings> neither works for kmod-kafs.
15:51:06 <billings> unless the source is different
15:51:18 <pjgeorg> Ah, you mean cause of the preprocessor defines?
15:51:28 <billings> yes
15:52:00 <billings> I've got a hard stop at noon, so if there are any other issues we should move on
15:52:08 <billings> er, in 9 minutes
15:52:14 <billings> sorry, timezones. :)
15:52:31 <pjgeorg> Ok. Just short points.
15:52:51 <billings> we can discuss more in -devel later
15:53:15 <pjgeorg> First, I suggest that we do all development on pagure.io/centos-sig-kmods and only push to git.centos.org to release stuff.
15:53:36 <billings> is that something that other SIGs do?
15:53:45 <pjgeorg> This is cause PR workflow is not working in git.centos.org https://pagure.io/centos-infra/issue/228
15:53:54 <billings> ah
15:54:10 <pjgeorg> Some SIGs do it like this, others use external resources. I think there is no common approach.
15:54:24 <billings> Ok, then I agree with your decision.
15:54:35 <pjgeorg> jcpunk ?
15:54:52 <jcpunk> works for me
15:55:07 <pjgeorg> #agreed Development for all packages done on pagure.io/centos-sig-kmods, push to git.centos.org for release only.
15:56:00 <pjgeorg> As we have almost no time left: I'll create issues on pagure for the following topics later:
15:56:17 <pjgeorg> Issue to gather a list of packages we want on git.centos.org
15:57:01 <pjgeorg> And one about what we want to present at the next CentOS Dojo.
15:57:01 <billings> We should have something about a potential talk at CentOS Dojo
15:57:09 <billings> you read my mind
15:57:12 <billings> :)
15:57:35 <pjgeorg> So to end just one action to myself that I remember documenting all the processes we tried to establish
15:57:42 <pjgeorg> #action pjgeorg Document process of adding, building, publishing, etc. kmods
15:57:56 <pjgeorg> Anything else for today?
15:59:00 <billings> None for me
15:59:20 <pjgeorg> And one short heads-up: I'll push few more kmods to pagure later I have ready locally.
15:59:34 <pjgeorg> Ok. Then we are done. Thanks for attending!
15:59:57 <pjgeorg> #endmeeting