Hi all!
The kernel-module discussion on fedora-extras list was quite successful and we have a kernel-module scheme now where nobody complained loudly (at least until now). Two examples that are based on the latest results from the discussion are found in extras-cvs in the packages lirc-kmod and thinkpad-kmod.
What we don't have yet: Support for the that kernel-module scheme in the buildsystem. What's needed? Roughly this:
- we need to get the kernel-verrel to the spec-file/rpmbuild somehow - we need to get the kernel-variants to the spec-file/rpmbuild somehow
Example: To rebuild lirc-kmod for the kernel 2.6.15-1.1831_FC4 and 2.6.15-1.1831_FC4smp on i686 one would run this command with the current scheme:
$ rpmbuild --rebuild lirc-kmod-0.8.0-2.2.6.15_1.1831_FC4.src.rpm --define 'kver 2.6.15-1.1831_FC4' --define 'kvariants "" smp ' --target i686
So guys, how to we teach that the buildsystem? Do we handle that in mock? Or in plague? As a yum-plugin? I don't know plague and mock to much, so any help/suggestions appreciated!
/me looks at the command and wonders why we use "kver" for kversion -- we either should use "kver" and "kvars" or "kversion" and "kvariants"
On 2/13/06, Thorsten Leemhuis fedora@leemhuis.info wrote:
- we need to get the kernel-verrel to the spec-file/rpmbuild somehow
- we need to get the kernel-variants to the spec-file/rpmbuild somehow
Example: To rebuild lirc-kmod for the kernel 2.6.15-1.1831_FC4 and 2.6.15-1.1831_FC4smp on i686 one would run this command with the current scheme:
$ rpmbuild --rebuild lirc-kmod-0.8.0-2.2.6.15_1.1831_FC4.src.rpm --define 'kver 2.6.15-1.1831_FC4' --define 'kvariants "" smp ' --target i686
So guys, how to we teach that the buildsystem? Do we handle that in mock? Or in plague? As a yum-plugin? I don't know plague and mock to much, so any help/suggestions appreciated!
One thing that leaps to mind -- and this may be a bit simplistic, or covered over in fedora-extras, I'll readily admit -- but how about embedding kver and kvariants in the spec file itself? This would require no tweaks to the buildsys (it would seem to me), and if %kver is part of the release tag, it wouldn't involve tweaking that as well.
+ no tweaks to plague needed + everything to do this is in place already - every time a new kernel is released, the spec would have to be tweaked and a rebuild job submitted. - every time a new version of the kernel module is released, see above
-Chris
On Mon, 2006-02-13 at 14:00 -0500, Chris Weyl wrote:
- every time a new kernel is released, the spec would have to be
tweaked and a rebuild job submitted.
- every time a new version of the kernel module is released, see above
We'd like to have the buildsys trigger builds of modules automatically when a new kernel gets built though, so these two minuses are pretty large...
If this is the scheme, we'll need some changes in:
1) Mock: allow passing of values to the rpmbuild command 2) Plague: figure out what variables to pass to mock based on a specific kernel, and also auto-rebuild kernel modules when the kernel changes
So we can't do this without changes to plague & mock.
Dan
On Mon, 2006-02-13 at 15:19 -0500, Dan Williams wrote:
On Mon, 2006-02-13 at 14:00 -0500, Chris Weyl wrote:
- every time a new kernel is released, the spec would have to be
tweaked and a rebuild job submitted.
- every time a new version of the kernel module is released, see above
We'd like to have the buildsys trigger builds of modules automatically when a new kernel gets built though, so these two minuses are pretty large...
At the same time, not doing this means that we break the assumption that you can do cvs co -r $(simple_transform_of_nvr) module
Jeremy
buildsys@lists.fedoraproject.org
-
Chris Weyl -
Dan Williams -
Jeremy Katz -
Thorsten Leemhuis