[Buildroot] [patch] kernel-headers: lzma causing issues

[Buildroot] [patch] kernel-headers: lzma causing issues

[Brad House]

The lzma patches really should be optional, so I've attached a patch
which does exactly that.

I find myself having to remove the lzma patches because my build system
doesn't natively have lzma.  I tried to compensate for this by
installing the latest lzma from gentoo's package tree, and apparently,
it accepts different flags than the one these patches expect, so my
kernel build still fails.  Finally, I used the lzma from this buildroot
and compiled it by hand, and it _mostly_ worked.  Regardless, it seems
silly to make this a requirement.  Personally, I gzip my initramfs,
and that's enough compression for me...

Please apply this patch and create a toolchain/kernel-headers/lzma
directory and move the linux-*lzma*.patch files to that directory.
I'm sure I can't be the only person who's had to simply delete those
patches from my tree.

Thanks.
-Brad
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kernel-headers-lzma-optional.diff
Url: http://busybox.net/lists/buildroot/attachments/20070814/3c555d82/attachment.diff 

[Buildroot] [patch] kernel-headers: lzma causing issues

[Ulf Samuelsson]

tis 2007-08-14 klockan 20:57 -0400 skrev Brad House:
> The lzma patches really should be optional, so I've attached a patch
> which does exactly that.
> 
> I find myself having to remove the lzma patches because my build system
> doesn't natively have lzma.  I tried to compensate for this by
> installing the latest lzma from gentoo's package tree, and apparently,
> it accepts different flags than the one these patches expect, so my
> kernel build still fails.  Finally, I used the lzma from this buildroot
> and compiled it by hand, and it _mostly_ worked.  Regardless, it seems
> silly to make this a requirement.  Personally, I gzip my initramfs,
> and that's enough compression for me...
> 
> Please apply this patch and create a toolchain/kernel-headers/lzma
> directory and move the linux-*lzma*.patch files to that directory.
> I'm sure I can't be the only person who's had to simply delete those
> patches from my tree.
> 

<snip>

>  
> +config BR2_KERNEL_HEADERS_LZMA
> +	bool "use lzma initramfs kernel patches"
> +	default y
> +	help
> +	  Apply patches which allow for lzma compressed
> +	  initramfs filesystems.  This requires the lzma
> +	  program in your development environment.	
> +

Since it also breaks unless you have lzma causing headache, 
I think the default should be to not use the lzma patch...

I am working on a new scheme where the target/linux and
toolchain/kernel-headers are integrated, but this
needs a lot more testing and will (as agreed with Bernhard
be reviewed before applied, but it seems reasonable
to do this as an intermediate fix.

BR
Ulf Samuelsson

[Buildroot] [patch] kernel-headers: lzma causing issues

[Brad House]

>> +config BR2_KERNEL_HEADERS_LZMA
>> +	bool "use lzma initramfs kernel patches"
>> +	default y
>> +	help
>> +	  Apply patches which allow for lzma compressed
>> +	  initramfs filesystems.  This requires the lzma
>> +	  program in your development environment.	
>> +
> 
> Since it also breaks unless you have lzma causing headache, 
> I think the default should be to not use the lzma patch...

ok, yeah, I'd agree with that ... I was just maintaining
compatibility for those who are using it by defaulting to y.

> I am working on a new scheme where the target/linux and
> toolchain/kernel-headers are integrated, but this
> needs a lot more testing and will (as agreed with Bernhard
> be reviewed before applied, but it seems reasonable
> to do this as an intermediate fix.

Ah, yeah, it would definitely make sense for those to be
integrated. It took me a minute to realize the kernel
headers version is what determined which release of the
kernel got built ;)

Thanks.
-Brad

[Buildroot] [patch] kernel-headers: lzma causing issues

[Ulf Samuelsson]

ons 2007-08-15 klockan 07:51 -0400 skrev Brad House:
> >> +config BR2_KERNEL_HEADERS_LZMA
> >> +	bool "use lzma initramfs kernel patches"
> >> +	default y
> >> +	help
> >> +	  Apply patches which allow for lzma compressed
> >> +	  initramfs filesystems.  This requires the lzma
> >> +	  program in your development environment.	
> >> +
> > 
> > Since it also breaks unless you have lzma causing headache, 
> > I think the default should be to not use the lzma patch...
> 
> ok, yeah, I'd agree with that ... I was just maintaining
> compatibility for those who are using it by defaulting to y.
> 
> > I am working on a new scheme where the target/linux and
> > toolchain/kernel-headers are integrated, but this
> > needs a lot more testing and will (as agreed with Bernhard
> > be reviewed before applied, but it seems reasonable
> > to do this as an intermediate fix.
> 
> Ah, yeah, it would definitely make sense for those to be
> integrated. It took me a minute to realize the kernel
> headers version is what determined which release of the
> kernel got built ;)

In the stuff I am working on you can choose one out of three strategies.
"tested" version (equivalent with the current kernel headers)
"std" version linux-2.6.x and (with linux-2.6.y.z option)
"experimental" version (latest stable, latest git or mm patch)

The current kernel headers will be applied automatically to 
the tested version, and can be choosen for the other versions.
You can also add board specific patches (Before kernel headers
are generated)

You can also add up to three patches located anywhere...
Ideally that should be downloadable patches.

You also have choices for which version (vmlinux, zImage, uImage,
bzImage) or freetext entry for linux target.

You can choose how to configure linux:

cp $(LINUX26_KCONFIG) .config ; make oldconfig
make <board>_defconfig
make ARCH=$(ARCH) xconfig

The Kernel headers will be built in $(STAGING_DIR) (or maybe
$(TOOL_BUILD_DIR)) but the kernel will also be extracted 
in $(PROJECT_BUILD_DIR) and built from there.
 
Best Regards
Ulf Samuelsson