[Buildroot] kernel patch not applied

[Buildroot] kernel patch not applied

[David Claffey]

I have a custom kernel patch I want applied when building the 2.6 kernel.  I
created a device under target/devices with a directory kernel-patches and
BR2_BOARD_PATH set correctly.  However, the patch is never applied apparently
because all patches are assumed to be minor kernel version patches.

In the case when DOWNLOAD_LINUX26_VERSION equals LINUX26_VERSION no patches,
including custom kernel patches, are applied. My current fix below will change
the directory name if minor kernel patches are applied, but still allow patches
in $(BR2_BOARD_PATH)/kernel-patches to be applied.

Could this cause problem elsewhere in the build?

Index: target/linux26.mk
===================================================================
--- target/linux26.mk     (revision 18593)
+++ target/linux26.mk     (working copy)
@@ -74,11 +74,11 @@
        mv -f $(BUILD_DIR)/linux-$(DOWNLOAD_LINUX26_VERSION) $(LINUX26_DIR)
 endif
        touch $@
+endif # ($(LINUX26_VERSION),$(LINUX_HEADERS_VERSION))

 $(LINUX26_DIR)/.patched: $(LINUX26_DIR)/.unpacked
        toolchain/patch-kernel.sh $(LINUX26_DIR) $(LINUX26_PATCH_DIR)
        touch $@
-endif # ($(LINUX26_VERSION),$(LINUX_HEADERS_VERSION))

 $(LINUX26_DIR)/.configured:  $(LINUX26_DIR)/.patched  $(LINUX26_KCONFIG)
        cp -dpf $(LINUX26_KCONFIG) $(LINUX26_DIR)/.config

[Buildroot] kernel patch not applied

[David Claffey]

This actually causes an override of the .patched target in
toolchain/kernel-headers/kernel-headers-new.makefile.

Suggestions?

David Claffey wrote:
> I have a custom kernel patch I want applied when building the 2.6 kernel.  I
> created a device under target/devices with a directory kernel-patches and
> BR2_BOARD_PATH set correctly.  However, the patch is never applied apparently
> because all patches are assumed to be minor kernel version patches.
> 
> In the case when DOWNLOAD_LINUX26_VERSION equals LINUX26_VERSION no patches,
> including custom kernel patches, are applied. My current fix below will change
> the directory name if minor kernel patches are applied, but still allow patches
> in $(BR2_BOARD_PATH)/kernel-patches to be applied.
> 
> Could this cause problem elsewhere in the build?
> 
> Index: target/linux26.mk
> ===================================================================
> --- target/linux26.mk     (revision 18593)
> +++ target/linux26.mk     (working copy)
> @@ -74,11 +74,11 @@
>         mv -f $(BUILD_DIR)/linux-$(DOWNLOAD_LINUX26_VERSION) $(LINUX26_DIR)
>  endif
>         touch $@
> +endif # ($(LINUX26_VERSION),$(LINUX_HEADERS_VERSION))
> 
>  $(LINUX26_DIR)/.patched: $(LINUX26_DIR)/.unpacked
>         toolchain/patch-kernel.sh $(LINUX26_DIR) $(LINUX26_PATCH_DIR)
>         touch $@
> -endif # ($(LINUX26_VERSION),$(LINUX_HEADERS_VERSION))
> 
>  $(LINUX26_DIR)/.configured:  $(LINUX26_DIR)/.patched  $(LINUX26_KCONFIG)
>         cp -dpf $(LINUX26_KCONFIG) $(LINUX26_DIR)/.config
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
> 

[Buildroot] kernel patch not applied

[Hans-Christian Egtvedt]

> This actually causes an override of the .patched target in
> toolchain/kernel-headers/kernel-headers-new.makefile.
> 
> Suggestions?

I just bumped into the same issue myself.

in toolchain/kernel-headers/kernel-headers-new.makefile

I had to change

$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX_HEADERS_UNPACK_DIR)/.unpacked
        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
toolchain/kernel-headers \
                linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}
ifeq ($(BR2_PACKAGE_OPENSWAN),y)
        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
                linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}
endif
        touch $@


to

$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX_HEADERS_UNPACK_DIR)/.unpacked
        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
toolchain/kernel-headers \
                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
ifeq ($(BR2_PACKAGE_OPENSWAN),y)
        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
endif
        touch $@

-- 
With kind regards,

Hans-Christian Egtvedt, siv.ing. (M.Sc.)
Applications Engineer - AVR32 System Solutions - Atmel Norway

[Buildroot] kernel patch not applied

[Bernhard Fischer]

On Fri, May 11, 2007 at 04:31:49PM +0200, Hans-Christian Egtvedt wrote:
>> This actually causes an override of the .patched target in
>> toolchain/kernel-headers/kernel-headers-new.makefile.
>> 
>> Suggestions?
>
>I just bumped into the same issue myself.
>
>in toolchain/kernel-headers/kernel-headers-new.makefile
>
>I had to change
>
>$(LINUX_HEADERS_UNPACK_DIR)/.patched:
>$(LINUX_HEADERS_UNPACK_DIR)/.unpacked
>        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
>toolchain/kernel-headers \
>                linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}
>ifeq ($(BR2_PACKAGE_OPENSWAN),y)
>        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
>                linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}
>endif
>        touch $@
>
>
>to
>
>$(LINUX_HEADERS_UNPACK_DIR)/.patched:
>$(LINUX_HEADERS_UNPACK_DIR)/.unpacked
>        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
>toolchain/kernel-headers \
>                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
>ifeq ($(BR2_PACKAGE_OPENSWAN),y)
>        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
>                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*

which means that your shell just doesn't expand ba{r,z}

We use patterns also to specify targets we intend to strip, so either
use a different shell or fix all occurances, i'd say.

[Buildroot] kernel patch not applied

[David Claffey]

The braces expansion issue is different.

kernel-headers-new.makefile and linux26.mk .patched targets overlap.

$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX26_DIR)/.patched:

The kernel-headers target pulls in linux-$(LINUX_HEADERS_VERSION)-* patches,
while the linux26.mk is explicitly pulling in any patches placed in the
$(BR2_BOARD_PATH)/kernel-patches directory.

The latter does not occur because the kernel-headers rule satisfies the
dependency early on.

Bernhard Fischer wrote:
> On Fri, May 11, 2007 at 04:31:49PM +0200, Hans-Christian Egtvedt wrote:
>>> This actually causes an override of the .patched target in
>>> toolchain/kernel-headers/kernel-headers-new.makefile.
>>>
>>> Suggestions?
>> I just bumped into the same issue myself.
>>
>> in toolchain/kernel-headers/kernel-headers-new.makefile
>>
>> I had to change
>>
>> $(LINUX_HEADERS_UNPACK_DIR)/.patched:
>> $(LINUX_HEADERS_UNPACK_DIR)/.unpacked
>>        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
>> toolchain/kernel-headers \
>>                linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}
>> ifeq ($(BR2_PACKAGE_OPENSWAN),y)
>>        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
>>                linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}
>> endif
>>        touch $@
>>
>>
>> to
>>
>> $(LINUX_HEADERS_UNPACK_DIR)/.patched:
>> $(LINUX_HEADERS_UNPACK_DIR)/.unpacked
>>        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
>> toolchain/kernel-headers \
>>                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
>> ifeq ($(BR2_PACKAGE_OPENSWAN),y)
>>        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
>>                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
> 
> which means that your shell just doesn't expand ba{r,z}
> 
> We use patterns also to specify targets we intend to strip, so either
> use a different shell or fix all occurances, i'd say.
> 

[Buildroot] kernel patch not applied

[Bernhard Fischer]

On Fri, May 11, 2007 at 12:29:53PM -0400, David Claffey wrote:
>The braces expansion issue is different.
>
>kernel-headers-new.makefile and linux26.mk .patched targets overlap.
>
>$(LINUX_HEADERS_UNPACK_DIR)/.patched:
>$(LINUX26_DIR)/.patched:
>
>The kernel-headers target pulls in linux-$(LINUX_HEADERS_VERSION)-* patches,
>while the linux26.mk is explicitly pulling in any patches placed in the
>$(BR2_BOARD_PATH)/kernel-patches directory.
>
>The latter does not occur because the kernel-headers rule satisfies the
>dependency early on.

Thanks for the explanation. I think that we want to apply _any_ patches
even for the kernel-headers, since a later applied patch could render
parts of the headers to be incorrect ?). Can you please try to apply
$(BR2_BOARD_PATH)/kernel-patches/linux-$(LINUX_HEADERS_VERSION)*.patch*
in kernel-headers-new.makefile and after successful verification send
the patch to me? TIA

?) Suppose i have a patch that removes the VT layer. This patch would
lead to inconsistency if applied after the headers are installed.

[Buildroot] kernel patch not applied

[David Claffey]

> Can you please try to apply
> $(BR2_BOARD_PATH)/kernel-patches/linux-$(LINUX_HEADERS_VERSION)*.patch*
> in kernel-headers-new.makefile and after successful verification send
> the patch to me? TIA

Finally got a chance to do a fresh build. This simple patch now pulls in custom
device-specific kernel patches at kernel-header build time, as you suggested.
However, it differs from target/linux26.mk where the patch files are not
filtered by "linux-$(LINUX_HEADERS_VERSION)*".  Not sure if this will affect
other builds.

--- toolchain/kernel-headers/kernel-headers-new.makefile        (revision 18607)
+++ toolchain/kernel-headers/kernel-headers-new.makefile        (working copy)
@@ -30,6 +30,7 @@
 $(LINUX_HEADERS_UNPACK_DIR)/.patched: $(LINUX_HEADERS_UNPACK_DIR)/.unpacked
        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
toolchain/kernel-headers \
                linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}
+       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
$(BR2_BOARD_PATH)/kernel-patches linux-$(LINUX_HEADERS_VERSION)*.patch{,.gz,.bz2}
 ifeq ($(BR2_PACKAGE_OPENSWAN),y)
        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
                linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}

[Buildroot] kernel patch not applied

[Hans-Christian Egtvedt]

On Fri, 2007-05-11 at 17:40 +0200, Bernhard Fischer wrote:
> On Fri, May 11, 2007 at 04:31:49PM +0200, Hans-Christian Egtvedt wrote:

<cut>

> >$(LINUX_HEADERS_UNPACK_DIR)/.patched:
> >$(LINUX_HEADERS_UNPACK_DIR)/.unpacked
> >        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
> >toolchain/kernel-headers \
> >                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
> >ifeq ($(BR2_PACKAGE_OPENSWAN),y)
> >        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
> >                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
> 
> which means that your shell just doesn't expand ba{r,z}

Weird, I tried zsh, bash and sh. I am building on Ubuntu 7.04.

> We use patterns also to specify targets we intend to strip, so either
> use a different shell or fix all occurances, i'd say.

Which shell on which distribution works?

-- 
Best regards
Hans-Christian Egtvedt

[Buildroot] kernel patch not applied

[Bernhard Fischer]

On Mon, May 14, 2007 at 07:21:25AM +0200, Hans-Christian Egtvedt wrote:
>On Fri, 2007-05-11 at 17:40 +0200, Bernhard Fischer wrote:
>> On Fri, May 11, 2007 at 04:31:49PM +0200, Hans-Christian Egtvedt wrote:
>
><cut>
>
>> >$(LINUX_HEADERS_UNPACK_DIR)/.patched:
>> >$(LINUX_HEADERS_UNPACK_DIR)/.unpacked
>> >        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
>> >toolchain/kernel-headers \
>> >                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
>> >ifeq ($(BR2_PACKAGE_OPENSWAN),y)
>> >        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
>> >                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
>> 
>> which means that your shell just doesn't expand ba{r,z}
>
>Weird, I tried zsh, bash and sh. I am building on Ubuntu 7.04.

IIRC ubuntu defaults to dash as sh, so make sure that
a) SHELL points to /bin/bash (ash may work too)
or,
b) symlink sh to be bash

a) is of course the preferred solution, didn't look if there are direct
references to /bin/sh instead of $SHELL in the makefiles, though.
>
>> We use patterns also to specify targets we intend to strip, so either
>> use a different shell or fix all occurances, i'd say.
>
>Which shell on which distribution works?

[Buildroot] Matchbox Support

[Christopher Reder]

Hello all.  I am using buildroot for a project with an ARM at91rm9200 and it
is working nicely after getting some assistance building.  It is building a
file system with busybox and tiny-x and I'd like to incorporate a desktop
like matchbox in with it.  I read that there were a few people incorporating
it into the build but I could not find it in there.  Can someone let me know
if it is in there or if they have a patch to add it in?



Thanks in advance!
Christopher Reder

[Buildroot] Matchbox Support

[Assen Stoyanov]

Hello All,

I am 99% ready with the port of matchbox project. Incl.:
- Matchbox Window Manager
- Matchbox Startup Notification
- Matchbox Desktop
- Matchbox Virtual Keyboard

Also other thinks that are 100% done are:

1) lilo 22.8 (x86 boot loader)
2) tslib 1.0 (touchscreen lib and utils)
3) X11R7 libs (libX11.so)
3.1) libICE.so - Inter Client Exchange library
3.2) libXdmcp.so - X Display Manager Control Protocol library
3.3) libXfixes.so - X Fixes extension library
3.4) libXfont.so - X font libary (used by the X server)
3.5) libXext.so - X Extension library
3.6) libXtst.so - X Test Extensions library
3.7) libXdamage.so - X Damage library
3.8) libXcomposite.so - X Composite library
3.9) libXres.so - X Resources library
3.10) libXrender.so - X Render extension library
3.11) libXrandr.so - X Resize and Rotate extension library
3.12) libXcursor.so - Client-side cursor loading library
3.13) libXft.so - X FreeType library. Client-side fonts with FreeType
3.14) libSM.so - X Session Management library.
3.15) libxkbfile.so - X KBFile utils library.
3.16) libXt.so - X Toolkit library.
3.17) libXmu.so - X Xmu/Xmuu library.
3.18) libXpm.so - X Pixmap library.
3.19) libXaw.so - X Athena Extensions.
4) X11R7 Kdrive (TinyX) Servers (incl. tslib support)

TODOs (this week):
- refactor cairo;
- refactor glib/gtk;
- add jikes java compiler in toolchain;
- add JamVM (java virtual machine)
- add GNU Classpath 0.95 with (optional) GTK/Cairo peers for full awt/swing 
support.

My question is - what is the best way to submit all these changes to the 
buildroot repository?

Best Regards,
Assen Stoyanov

----- Original Message ----- 
From: "Christopher Reder" <creder@digitalcpt.com>
To: <buildroot@uclibc.org>
Sent: Monday, May 14, 2007 15:41
Subject: [Buildroot] Matchbox Support


> Hello all.  I am using buildroot for a project with an ARM at91rm9200 and 
> it
> is working nicely after getting some assistance building.  It is building 
> a
> file system with busybox and tiny-x and I'd like to incorporate a desktop
> like matchbox in with it.  I read that there were a few people 
> incorporating
> it into the build but I could not find it in there.  Can someone let me 
> know
> if it is in there or if they have a patch to add it in?
>
>
>
> Thanks in advance!
> Christopher Reder
>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.467 / Virus Database: 269.7.0/804 - Release Date: 5/14/2007 
> 4:46 PM
>
> 



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.467 / Virus Database: 269.7.0/804 - Release Date: 5/14/2007 4:46 PM

[Buildroot] Matchbox Support

[Peter Korsgaard]

>>>>> "AS" == Assen Stoyanov <softa@ttechgroup.com> writes:

Hi,

AS> Hello All, I am 99% ready with the port of matchbox
AS> project. Incl.: - Matchbox Window Manager - Matchbox Startup
AS> Notification - Matchbox Desktop - Matchbox Virtual Keyboard

AS> Also other thinks that are 100% done are:

Cool!

AS> My question is - what is the best way to submit all these changes
AS> to the buildroot repository?

Send patches to the bug tracker or this ml.

-- 
Bye, Peter Korsgaard

[Buildroot] kernel patch not applied

[Hans-Christian Egtvedt]

On Mon, 2007-05-14 at 09:11 +0200, Bernhard Fischer wrote:
> On Mon, May 14, 2007 at 07:21:25AM +0200, Hans-Christian Egtvedt wrote:
> >On Fri, 2007-05-11 at 17:40 +0200, Bernhard Fischer wrote:
> >> On Fri, May 11, 2007 at 04:31:49PM +0200, Hans-Christian Egtvedt wrote:

<cut>

> >Weird, I tried zsh, bash and sh. I am building on Ubuntu 7.04.
> 
> IIRC ubuntu defaults to dash as sh, so make sure that
> a) SHELL points to /bin/bash (ash may work too)
> or,

Aha, setting SHELL to /bin/bash makes this work, thanks.

Perhaps the top level Makefile should modify SHELL for you?

<cut solution with symlink>

-- 
Mvh
Hans-Christian Egtvedt

[Buildroot] kernel patch not applied

[Bernhard Fischer]

On Mon, May 14, 2007 at 05:25:53PM +0200, Hans-Christian Egtvedt wrote:

>> >Weird, I tried zsh, bash and sh. I am building on Ubuntu 7.04.
>> 
>> IIRC ubuntu defaults to dash as sh, so make sure that
>> a) SHELL points to /bin/bash (ash may work too)
>> or,
>
>Aha, setting SHELL to /bin/bash makes this work, thanks.
>
>Perhaps the top level Makefile should modify SHELL for you?

The user is supposed to set the environment he wants to use.
This includes but is not limited to SHELL, HOSTCXX, HOSTCC, MAKE etc,
etc.

[Buildroot] kernel patch not applied

[Hans-Christian Egtvedt]

On Mon, 2007-05-14 at 17:34 +0200, Bernhard Fischer wrote:
> On Mon, May 14, 2007 at 05:25:53PM +0200, Hans-Christian Egtvedt wrote:

<cut>

> >Aha, setting SHELL to /bin/bash makes this work, thanks.
> >
> >Perhaps the top level Makefile should modify SHELL for you?
> 
> The user is supposed to set the environment he wants to use.
> This includes but is not limited to SHELL, HOSTCXX, HOSTCC, MAKE etc,
> etc.

I understand HOST..., MAKE, etc. But since some of the scripts really
depend on you using the bash shell, then I think it should be either
forced or at least given a warning when starting to build.

Will keep the noise a bit down on this email list if people know why
some parts of the build process fails :)

-- 
Mvh
Hans-Christian Egtvedt

[Buildroot] kernel patch not applied

[Bernhard Fischer]

On Tue, May 15, 2007 at 09:47:27AM +0200, Hans-Christian Egtvedt wrote:
>On Mon, 2007-05-14 at 17:34 +0200, Bernhard Fischer wrote:
>> On Mon, May 14, 2007 at 05:25:53PM +0200, Hans-Christian Egtvedt wrote:
>
><cut>
>
>> >Aha, setting SHELL to /bin/bash makes this work, thanks.
>> >
>> >Perhaps the top level Makefile should modify SHELL for you?
>> 
>> The user is supposed to set the environment he wants to use.
>> This includes but is not limited to SHELL, HOSTCXX, HOSTCC, MAKE etc,
>> etc.
>
>I understand HOST..., MAKE, etc. But since some of the scripts really
>depend on you using the bash shell, then I think it should be either
>forced or at least given a warning when starting to build.
>
>Will keep the noise a bit down on this email list if people know why
>some parts of the build process fails :)

I don't think depending on bash is desirable. The scripts should also
work at least with ash, imo. Short of that, $(wildcard ) comes to mind,
which would fix this proper in the realm of make (patches welcome).

[Buildroot] Whats happened to Eric?

[Ulf Samuelsson]

He does not answer mails...

Best Regards
Ulf Samuelsson

[Buildroot] Whats happened to Eric?

[Erik Andersen]

On Tue May 15, 2007 at 12:35:25PM +0200, Ulf Samuelsson wrote:
> He does not answer mails...

Erik is buried in a huge project for his work.  While I do run a
small consulting business doing embedded Linux stuff, mainly for
the fun and diversion it affords me, my main job is doing
computer forensics work, which has at best only a peripheral
relationship with embedded Linux.  With my main job taking up
most of my time, between work and family (I'm happily married
with 4 young kids) I have had almost no surplus time for my usual
leisure time work on uClibc, buildroot, for the past few months.
I remain hundreds of emails behind most of the time of late...
Sortof sucks, but that is the way it is.

If you would like to obtain svn commit privs I would be happy to
get you setup, at which point you would be able to get your board
support work in place on your own.  I agree with having it
included in buildroot but I do not presently have the personal
bandwidth to shepherd it into place and it seems noone else has
done so either.  Sorry I've been so busy/absent/negligent,

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

[Buildroot] kernel patch not applied

[Julien Boibessot]

Hi,

It's quite a long time now, since first email, but I was faced to the
problem today, when updating my old buildroot to the latest svn one.

Bernhard Fischer a ?crit :
> On Mon, May 14, 2007 at 07:21:25AM +0200, Hans-Christian Egtvedt wrote:
>   
>> On Fri, 2007-05-11 at 17:40 +0200, Bernhard Fischer wrote:
>>     
>>> On Fri, May 11, 2007 at 04:31:49PM +0200, Hans-Christian Egtvedt wrote:
>>>       
>> <cut>
>>
>>     
>>>> $(LINUX_HEADERS_UNPACK_DIR)/.patched:
>>>> $(LINUX_HEADERS_UNPACK_DIR)/.unpacked
>>>>        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
>>>> toolchain/kernel-headers \
>>>>                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
>>>> ifeq ($(BR2_PACKAGE_OPENSWAN),y)
>>>>        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
>>>>                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
>>>>         
>>> which means that your shell just doesn't expand ba{r,z}
>>>       
>> Weird, I tried zsh, bash and sh. I am building on Ubuntu 7.04.
>>     
>
> IIRC ubuntu defaults to dash as sh, so make sure that
> a) SHELL points to /bin/bash (ash may work too)
> or,
> b) symlink sh to be bash
>
> a) is of course the preferred solution, didn't look if there are direct
> references to /bin/sh instead of $SHELL in the makefiles, though.
>   
I'm working on KUbuntu 7.10. (yes, I know it's bad :-) ).
a) doesn't work for me (even if my SHELL env is pointing to /bin/bash)

only b) or "make SHELL=/bin/bash" are working.


It's just a 2 cents feedback, so I'm not waiting for an answer ;-)

Regards,
Julien

[Buildroot] kernel patch not applied

[Bernhard Reutner-Fischer]

On Tue, Nov 04, 2008 at 07:19:32PM +0100, Julien Boibessot wrote:
>Hi,
>
>It's quite a long time now, since first email, but I was faced to the
>problem today, when updating my old buildroot to the latest svn one.
>
>Bernhard Fischer a ?crit :
>> On Mon, May 14, 2007 at 07:21:25AM +0200, Hans-Christian Egtvedt wrote:
>>   
>>> On Fri, 2007-05-11 at 17:40 +0200, Bernhard Fischer wrote:
>>>     
>>>> On Fri, May 11, 2007 at 04:31:49PM +0200, Hans-Christian Egtvedt wrote:
>>>>       
>>> <cut>
>>>
>>>     
>>>>> $(LINUX_HEADERS_UNPACK_DIR)/.patched:
>>>>> $(LINUX_HEADERS_UNPACK_DIR)/.unpacked
>>>>>        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
>>>>> toolchain/kernel-headers \
>>>>>                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
>>>>> ifeq ($(BR2_PACKAGE_OPENSWAN),y)
>>>>>        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
>>>>>                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
>>>>>         
>>>> which means that your shell just doesn't expand ba{r,z}
>>>>       
>>> Weird, I tried zsh, bash and sh. I am building on Ubuntu 7.04.
>>>     
>>
>> IIRC ubuntu defaults to dash as sh, so make sure that
>> a) SHELL points to /bin/bash (ash may work too)
>> or,
>> b) symlink sh to be bash
>>
>> a) is of course the preferred solution, didn't look if there are direct
>> references to /bin/sh instead of $SHELL in the makefiles, though.
>>   
>I'm working on KUbuntu 7.10. (yes, I know it's bad :-) ).
>a) doesn't work for me (even if my SHELL env is pointing to /bin/bash)
>
>only b) or "make SHELL=/bin/bash" are working.

yes. Note that there is also CONFIG_SHELL (which should be used in a
consistent manner everywhere) for $(shell ....) invocations.
>
>It's just a 2 cents feedback, so I'm not waiting for an answer ;-)

Thanks for the feedback, I could imagine that it proves helpful
for somebody.

cheers,