On 01/06/2011 12:45 PM, Jarod Wilson wrote: > On Thu, Jan 06, 2011 at 12:33:40PM -0800, JD wrote: >> On 01/06/2011 07:18 AM, Jarod Wilson wrote: >>> On Thu, Jan 06, 2011 at 12:15:51AM -0500, Don Zickus wrote: >>>> On Wed, Jan 05, 2011 at 11:47:41PM -0500, Jarod Wilson wrote: >>>>>> So, what do I do? I simply prep from source >>>>>> (rpmbuild -bp kernel.spec) >>>>>> and then cd to ~/rpmbuild/BUILD/kernel-2.6.35.10-74/linux-2.6.35.i686, >>>>>> copy my current kernel's config file to .config, run >>>>>> make oldconfig and >>>>>> male all >>>>>> and that does it. >>>>>> The new config file inherits my enabled drivers selections. >>>>>> From the kernel spec: >>>>> # Dynamically generate kernel .config files from config-* files >>>>> make -f %{SOURCE20} VERSION=%{version} configs >>>>> >>>>> And Source20 is Makefile.config, from which with a bit of effort, you can >>>>> determine the order in which the various config-* files are smashed >>>>> together to form the end result .config files. >>>>> >>>>> I think this topic actually came up once in the past, and an idea to add >>>>> an extra layer similar to the 'if rhel' clause in the spec was kicked >>>>> around, but never came to fruition. In theory, that file would, if >>>>> present, apply additional Kconfig changes from an additional overrides >>>>> file. It could be an empty file by default, but obviously named or >>>>> documented, so that anyone rebuilding could simply put their assorted >>>>> additional config options in there, and they'd always be applied over the >>>>> top of the stock config options. >>>> Ha! I can't believe the rhel stuff I added is still there. >>> I dunno if it got used for RHEL6 initially or not... I'd be inclined to >>> rip it out, and we can add something similar back next time we've got >>> another RHEL major release on the horizon... Maybe that gives away too >>> many secrets though. :) >>> >>>> We could probably mimic the old linux-kernel-test.patch which was a stub >>>> patch to allow developers to quickly test their patches without mucking >>>> with the spec file, but instead for config files (like the %rhel thing). >>> I think this would suffice: >>> >>> # This file is empty in stock builds, but can be populated with local >>> # config option overrides for custom local builds >>> Source1000: config-local >>> >>> >>> Then, in %prep, in a loop similar to the if rhel one: >>> >>> ./merge.pl %{SOURCE1000} $i.tmp> $i >>> >>> >>> Since the file is empty in stock configs, the above in that case would >>> simply be a no-op. If its populated by someone doing a local rebuild, then >>> their config options get overlayed on top of the stock ones. >>> >> Hi Jarod, >> Do you even need the for loop? Since you are dealing with just one >> local config file? >> Or is the purpose of putting it in the loop to superimpose the >> local configs on top >> of the vanilla configs for all the kernel.*-config files? > Yes, the idea is to overlay the changes on every flavor of kernel. In the > standard released kernel rpmbuild for x86_64, you get kernel and > kernel-debug, and we want the changes stacked on top of both of them. The > for loop also makes sure its arch-agnostic. > OK, I understand. Would this loop in the spec file do it? . . for i in %{all_arch_configs} do mv $i $i.tmp ./merge.pl %{Source1000} $i.tmp > $i rm $i.tmp done Thanx, JD _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel