-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Sealey wrote:
Hi,
We're working on creating a new kernel flavor here so we can maintain a few patches against the standard -default kernel without trashing peoples' installations (i.e. while you can't have -default and -genesi at the same time because of the cleanup in post-install, at least if it stops working or there's a weird bug, you can still go back to -default without forcing packages, and there would be no package conflicts if someone added our repo, and it had a higher version of -default..)
However I've stumbled across some real weirdness in kernel-source.src - which I then gather builds kernel-source.ppc which then can be used somehow to build kernel-genesi.ppc and .src. For instance, every kernel-$flavor.spec seems to be built from the same source somewhere, with identical changelogs and 99% identical code (the difference being the swapping of the flavor in many places, but that's it). So far I have just hacked up a kernel-genesi.spec myself which is building fine now, but I wondered, where do these files get generated and how can I make my kernel build take part in this process to build an automated spec file?
Yes, they are definitely generated from the same source. We have a kernel-binary.spec.in in the repository that is processed by replacing things like @FLAVOR@ with a real value. There's really no way to add a new flavor to that process since it happens as part of the repository being tarred up into the source RPM. One of my goals is to eliminate as much of that processing as possible. Much of the magic is in scripts that are only part of our repository[1], and that's... suboptimal. In the past month or so I've put some effort into making it easier to do what you're looking to do. The first set of patches remove almost all of the @VAR@ processing in favor of using RPM variables. The result is that you'll be able to add a new flavor by simply changing the %build_flavor variable definition in the beginning of the file and adding a kernel configuration file. Ideally, I'd just like to have a kernel-binary.spec where you do - --define "build_flavor $flavor" on the rpmbuild command line but I'm not sure how we'd go about automating the creation of all the different flavors. For now, you'll have to continue what you're doing. Look for the v2.6.28-staging flavor in the KOTD archive, and you should be able to use the spec files from there once I add those changes in.
Modifying config.conf, series.conf, adding patches is something I've been doing for a while so that has never been a problem to make a custom kernel-default, I would just like to move away from it. Is there any special documentation or a cheat sheet for how to make a new kernel flavor? What was the process to create kernel-ps3, for example, a few versions ago, and how does it get maintained with the rest?
It gets generated from kernel-binary.spec.in, just like everything else. [1] It's not that there's anything particularly sensitive in there, just that we only have so many hours in the day and it's generally better spent fixing bugs. :) - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkllLVEACgkQLPWxlyuTD7KY3QCfQGpd3I061lOOmI1wbIxlooNw YpAAn1+WkNcAGGZjtr0XUeOn4gfX2v6O =IwoP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org