-----BEGIN PGP SIGNED MESSAGE-----
Matt Sealey wrote:
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
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
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,
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
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.
 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. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org