2.6.35.10-74 compilation (and build) problems

[Jarod Wilson]

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.

-- 
Jarod Wilson
jarod at redhat.com