Patchwork Problem with apply-patches.sh

login
register
mail settings
Submitter ludovic.desroches@atmel.com
Date April 16, 2012, 4 p.m.
Message ID <4F8C4224.6040500@atmel.com>
Download mbox | patch
Permalink /patch/152912/
State Not Applicable
Headers show

Comments

ludovic.desroches@atmel.com - April 16, 2012, 4 p.m.
Hi

Le 04/16/2012 04:40 PM, Will Newton a écrit :
> Hi all,
>
> I noticed that in some cases apply-patches.sh will misbehave if you
> have a file matching the glob '*.patch' in the top-level directory.
> For example the patching of binutils fails in this case. The problem
> is at the line:
>
>      support/scripts/apply-patches.sh $(@D)
> $($(PKG)_DIR_PREFIX)/$(RAWNAME)/$(NAMEVER) \*.patch \*.patch.$(ARCH)
> || exit 1;
>
> in package/Makefile.package.in. The glob gets expanded prematurely (to
> e.g. myfile.patch) and then the expanded glob is passed to
> apply-patches.sh which will fail to find any patches matching the
> glob. I've had a go at trying to stop this happening but with no
> success so far. Can anyone think of any creative ways to suppress this
> expansion?
>
> Thanks,

I see what you mean but I can't reproduce your issue:



 >>> binutils 2.21.1 Extracting
bzcat /home/ldesroches/workspace/buildroot/dl/binutils-2.21.1.tar.bz2 | 
tar --strip-components=1 -C 
/home/ldesroches/workspace/buildroot/output/build/binutils-2.21.1  -xf -
 >>> binutils 2.21.1 Patching package//binutils
=====================
binutils*.patch binutils*.patch.arm
=====================
*.patch *.patch.arm

On my side the expansion is done only into apply-patches.sh but you are 
right it is done too early


I am going to send a patch to correct this.


Thanks to report this bug.


Regards

Ludovic
Will Newton - April 16, 2012, 4:09 p.m.
On Mon, Apr 16, 2012 at 5:00 PM, Ludovic Desroches
<ludovic.desroches@atmel.com> wrote:
> Hi
>
> Le 04/16/2012 04:40 PM, Will Newton a écrit :
>
>> Hi all,
>>
>> I noticed that in some cases apply-patches.sh will misbehave if you
>> have a file matching the glob '*.patch' in the top-level directory.
>> For example the patching of binutils fails in this case. The problem
>> is at the line:
>>
>>     support/scripts/apply-patches.sh $(@D)
>> $($(PKG)_DIR_PREFIX)/$(RAWNAME)/$(NAMEVER) \*.patch \*.patch.$(ARCH)
>> || exit 1;
>>
>> in package/Makefile.package.in. The glob gets expanded prematurely (to
>> e.g. myfile.patch) and then the expanded glob is passed to
>> apply-patches.sh which will fail to find any patches matching the
>> glob. I've had a go at trying to stop this happening but with no
>> success so far. Can anyone think of any creative ways to suppress this
>> expansion?
>>
>> Thanks,
>
>
> I see what you mean but I can't reproduce your issue:

Hi Ludovic, thanks for the quick response!

Did you have a dummy patch file in the top-level? e.g.:

# cd buildroot
# touch mypatch.patch
# make

For me that causes the patch patterns passed to apply-patches.sh to
look like: mypatch.patch *.patch.arm. The arch specific glob in this
case does not match anything so it remains unexpanded.
ludovic.desroches@atmel.com - April 16, 2012, 4:23 p.m.
Le 04/16/2012 06:09 PM, Will Newton a écrit :
> On Mon, Apr 16, 2012 at 5:00 PM, Ludovic Desroches
> <ludovic.desroches@atmel.com>  wrote:
>> Hi
>>
>> Le 04/16/2012 04:40 PM, Will Newton a écrit :
>>
>>> Hi all,
>>>
>>> I noticed that in some cases apply-patches.sh will misbehave if you
>>> have a file matching the glob '*.patch' in the top-level directory.
>>> For example the patching of binutils fails in this case. The problem
>>> is at the line:
>>>
>>>      support/scripts/apply-patches.sh $(@D)
>>> $($(PKG)_DIR_PREFIX)/$(RAWNAME)/$(NAMEVER) \*.patch \*.patch.$(ARCH)
>>> || exit 1;
>>>
>>> in package/Makefile.package.in. The glob gets expanded prematurely (to
>>> e.g. myfile.patch) and then the expanded glob is passed to
>>> apply-patches.sh which will fail to find any patches matching the
>>> glob. I've had a go at trying to stop this happening but with no
>>> success so far. Can anyone think of any creative ways to suppress this
>>> expansion?
>>>
>>> Thanks,
>>
>>
>> I see what you mean but I can't reproduce your issue:
>
> Hi Ludovic, thanks for the quick response!
>
> Did you have a dummy patch file in the top-level? e.g.:
>
> # cd buildroot
> # touch mypatch.patch
> # make
>

Yes I did this, I have created an empty patch file.

> For me that causes the patch patterns passed to apply-patches.sh to
> look like: mypatch.patch *.patch.arm. The arch specific glob in this
> case does not match anything so it remains unexpanded.
>

I agree but I had no error. I didn't do the whole build so maybe I will 
encounter an issue later due to the "no-patched" binutils.


Regards

Ludovic
Will Newton - April 16, 2012, 4:27 p.m.
On Mon, Apr 16, 2012 at 5:23 PM, Ludovic Desroches
<ludovic.desroches@atmel.com> wrote:
> Le 04/16/2012 06:09 PM, Will Newton a écrit :
>
>> On Mon, Apr 16, 2012 at 5:00 PM, Ludovic Desroches
>> <ludovic.desroches@atmel.com>  wrote:
>>>
>>> Hi
>>>
>>> Le 04/16/2012 04:40 PM, Will Newton a écrit :
>>>
>>>> Hi all,
>>>>
>>>> I noticed that in some cases apply-patches.sh will misbehave if you
>>>> have a file matching the glob '*.patch' in the top-level directory.
>>>> For example the patching of binutils fails in this case. The problem
>>>> is at the line:
>>>>
>>>>     support/scripts/apply-patches.sh $(@D)
>>>> $($(PKG)_DIR_PREFIX)/$(RAWNAME)/$(NAMEVER) \*.patch \*.patch.$(ARCH)
>>>> || exit 1;
>>>>
>>>> in package/Makefile.package.in. The glob gets expanded prematurely (to
>>>> e.g. myfile.patch) and then the expanded glob is passed to
>>>> apply-patches.sh which will fail to find any patches matching the
>>>> glob. I've had a go at trying to stop this happening but with no
>>>> success so far. Can anyone think of any creative ways to suppress this
>>>> expansion?
>>>>
>>>> Thanks,
>>>
>>>
>>>
>>> I see what you mean but I can't reproduce your issue:
>>
>>
>> Hi Ludovic, thanks for the quick response!
>>
>> Did you have a dummy patch file in the top-level? e.g.:
>>
>> # cd buildroot
>> # touch mypatch.patch
>> # make
>>
>
> Yes I did this, I have created an empty patch file.
>
>
>> For me that causes the patch patterns passed to apply-patches.sh to
>> look like: mypatch.patch *.patch.arm. The arch specific glob in this
>> case does not match anything so it remains unexpanded.
>>
>
> I agree but I had no error. I didn't do the whole build so maybe I will
> encounter an issue later due to the "no-patched" binutils.

I don't think it will cause an obvious issue for most people - I
happen to have a patched binutils so that if the patch is missing
things go wrong quite obviously. I put an echo in the top of
apply-patches.sh and I was quite clearly seeing the glob had been
expanded by the time it was run (whilst building host-binutils).

For the record my make is 3.81 and bash is 4.1.2.
ludovic.desroches@atmel.com - April 16, 2012, 4:42 p.m.
Le 04/16/2012 06:27 PM, Will Newton a écrit :
> On Mon, Apr 16, 2012 at 5:23 PM, Ludovic Desroches
> <ludovic.desroches@atmel.com>  wrote:
>> Le 04/16/2012 06:09 PM, Will Newton a écrit :
>>
>>> On Mon, Apr 16, 2012 at 5:00 PM, Ludovic Desroches
>>> <ludovic.desroches@atmel.com>    wrote:
>>>>
>>>> Hi
>>>>
>>>> Le 04/16/2012 04:40 PM, Will Newton a écrit :
>>>>
>>>>> Hi all,
>>>>>
>>>>> I noticed that in some cases apply-patches.sh will misbehave if you
>>>>> have a file matching the glob '*.patch' in the top-level directory.
>>>>> For example the patching of binutils fails in this case. The problem
>>>>> is at the line:
>>>>>
>>>>>      support/scripts/apply-patches.sh $(@D)
>>>>> $($(PKG)_DIR_PREFIX)/$(RAWNAME)/$(NAMEVER) \*.patch \*.patch.$(ARCH)
>>>>> || exit 1;
>>>>>
>>>>> in package/Makefile.package.in. The glob gets expanded prematurely (to
>>>>> e.g. myfile.patch) and then the expanded glob is passed to
>>>>> apply-patches.sh which will fail to find any patches matching the
>>>>> glob. I've had a go at trying to stop this happening but with no
>>>>> success so far. Can anyone think of any creative ways to suppress this
>>>>> expansion?
>>>>>
>>>>> Thanks,
>>>>
>>>>
>>>>
>>>> I see what you mean but I can't reproduce your issue:
>>>
>>>
>>> Hi Ludovic, thanks for the quick response!
>>>
>>> Did you have a dummy patch file in the top-level? e.g.:
>>>
>>> # cd buildroot
>>> # touch mypatch.patch
>>> # make
>>>
>>
>> Yes I did this, I have created an empty patch file.
>>
>>
>>> For me that causes the patch patterns passed to apply-patches.sh to
>>> look like: mypatch.patch *.patch.arm. The arch specific glob in this
>>> case does not match anything so it remains unexpanded.
>>>
>>
>> I agree but I had no error. I didn't do the whole build so maybe I will
>> encounter an issue later due to the "no-patched" binutils.
>
> I don't think it will cause an obvious issue for most people - I
> happen to have a patched binutils so that if the patch is missing
> things go wrong quite obviously. I put an echo in the top of
> apply-patches.sh and I was quite clearly seeing the glob had been
> expanded by the time it was run (whilst building host-binutils).

Still true with the patch I sent?

For me the glob was expanded here: scan_patchdir $patchdir $patchpattern

Without the patch:

 >>> binutils 2.21.1 Extracting
bzcat /home/ldesroches/workspace/buildroot/dl/binutils-2.21.1.tar.bz2 | 
tar --strip-components=1 -C 
/home/ldesroches/workspace/buildroot/output/build/binutils-2.21.1  -xf -
 >>> binutils 2.21.1 Patching package//binutils
 >>> binutils 2.21.1  Updating config.sub and config.guess
for file in config.guess config.sub; do for i in $(find 
/home/ldesroches/workspace/buildroot/output/build/binutils-2.21.1 -name 
$file); do cp support/gnuconfig/$file $i; done; done
 >>> binutils 2.21.1 Patching libtool



With the patch:

 >>> binutils 2.21.1 Extracting
bzcat /home/ldesroches/workspace/buildroot/dl/binutils-2.21.1.tar.bz2 | 
tar --strip-components=1 -C 
/home/ldesroches/workspace/buildroot/output/build/binutils-2.21.1  -xf -
 >>> binutils 2.21.1 Patching package//binutils

Applying 110-arm-eabi-conf.patch using patch:
patching file configure
Hunk #1 succeeded at 3180 with fuzz 2 (offset 935 lines).
patching file configure.ac
Hunk #1 succeeded at 652 with fuzz 2 (offset 130 lines).

Applying 120-sh-conf.patch using patch:
patching file configure
Hunk #1 succeeded at 3148 (offset 867 lines).
Hunk #2 succeeded at 3487 (offset 881 lines).
patching file configure.ac
Hunk #1 succeeded at 620 (offset 90 lines).
Hunk #2 succeeded at 959 (offset 104 lines).

Applying 300-001_ld_makefile_patch.patch using patch:
patching file ld/Makefile.am
Hunk #1 succeeded at 37 (offset 19 lines).
patching file ld/Makefile.in
Hunk #1 succeeded at 365 (offset 78 lines).

Applying 300-012_check_ldrunpath_length.patch using patch:
patching file ld/emultempl/elf32.em
Hunk #1 succeeded at 1272 (offset 2 lines).
Hunk #2 succeeded at 1501 (offset 2 lines).
 >>> binutils 2.21.1  Updating config.sub and config.guess
for file in config.guess config.sub; do for i in $(find 
/home/ldesroches/workspace/buildroot/output/build/binutils-2.21.1 -name 
$file); do cp support/gnuconfig/$file $i; done; done
 >>> binutils 2.21.1 Patching libtool

> For the record my make is 3.81 and bash is 4.1.2.
>


Regards

Ludovic
Will Newton - April 16, 2012, 4:54 p.m.
On Mon, Apr 16, 2012 at 5:42 PM, Ludovic Desroches
<ludovic.desroches@atmel.com> wrote:
> Le 04/16/2012 06:27 PM, Will Newton a écrit :
>
>> On Mon, Apr 16, 2012 at 5:23 PM, Ludovic Desroches
>> <ludovic.desroches@atmel.com>  wrote:
>>>
>>> Le 04/16/2012 06:09 PM, Will Newton a écrit :
>>>
>>>> On Mon, Apr 16, 2012 at 5:00 PM, Ludovic Desroches
>>>> <ludovic.desroches@atmel.com>    wrote:
>>>>>
>>>>>
>>>>> Hi
>>>>>
>>>>> Le 04/16/2012 04:40 PM, Will Newton a écrit :
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I noticed that in some cases apply-patches.sh will misbehave if you
>>>>>> have a file matching the glob '*.patch' in the top-level directory.
>>>>>> For example the patching of binutils fails in this case. The problem
>>>>>> is at the line:
>>>>>>
>>>>>>     support/scripts/apply-patches.sh $(@D)
>>>>>> $($(PKG)_DIR_PREFIX)/$(RAWNAME)/$(NAMEVER) \*.patch \*.patch.$(ARCH)
>>>>>> || exit 1;
>>>>>>
>>>>>> in package/Makefile.package.in. The glob gets expanded prematurely (to
>>>>>> e.g. myfile.patch) and then the expanded glob is passed to
>>>>>> apply-patches.sh which will fail to find any patches matching the
>>>>>> glob. I've had a go at trying to stop this happening but with no
>>>>>> success so far. Can anyone think of any creative ways to suppress this
>>>>>> expansion?
>>>>>>
>>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I see what you mean but I can't reproduce your issue:
>>>>
>>>>
>>>>
>>>> Hi Ludovic, thanks for the quick response!
>>>>
>>>> Did you have a dummy patch file in the top-level? e.g.:
>>>>
>>>> # cd buildroot
>>>> # touch mypatch.patch
>>>> # make
>>>>
>>>
>>> Yes I did this, I have created an empty patch file.
>>>
>>>
>>>> For me that causes the patch patterns passed to apply-patches.sh to
>>>> look like: mypatch.patch *.patch.arm. The arch specific glob in this
>>>> case does not match anything so it remains unexpanded.
>>>>
>>>
>>> I agree but I had no error. I didn't do the whole build so maybe I will
>>> encounter an issue later due to the "no-patched" binutils.
>>
>>
>> I don't think it will cause an obvious issue for most people - I
>> happen to have a patched binutils so that if the patch is missing
>> things go wrong quite obviously. I put an echo in the top of
>> apply-patches.sh and I was quite clearly seeing the glob had been
>> expanded by the time it was run (whilst building host-binutils).
>
>
> Still true with the patch I sent?
>
> For me the glob was expanded here: scan_patchdir $patchdir $patchpattern

Ah yes, of course it was my echo that was expanding the glob! ;-)

Yes, I just tried your patch and it fixes the problem for me. Thanks!
ludovic.desroches@atmel.com - April 16, 2012, 4:58 p.m.
Le 04/16/2012 06:54 PM, Will Newton a écrit :
> On Mon, Apr 16, 2012 at 5:42 PM, Ludovic Desroches
> <ludovic.desroches@atmel.com>  wrote:
>> Le 04/16/2012 06:27 PM, Will Newton a écrit :
>>
>>> On Mon, Apr 16, 2012 at 5:23 PM, Ludovic Desroches
>>> <ludovic.desroches@atmel.com>    wrote:
>>>>
>>>> Le 04/16/2012 06:09 PM, Will Newton a écrit :
>>>>
>>>>> On Mon, Apr 16, 2012 at 5:00 PM, Ludovic Desroches
>>>>> <ludovic.desroches@atmel.com>      wrote:
>>>>>>
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Le 04/16/2012 04:40 PM, Will Newton a écrit :
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I noticed that in some cases apply-patches.sh will misbehave if you
>>>>>>> have a file matching the glob '*.patch' in the top-level directory.
>>>>>>> For example the patching of binutils fails in this case. The problem
>>>>>>> is at the line:
>>>>>>>
>>>>>>>      support/scripts/apply-patches.sh $(@D)
>>>>>>> $($(PKG)_DIR_PREFIX)/$(RAWNAME)/$(NAMEVER) \*.patch \*.patch.$(ARCH)
>>>>>>> || exit 1;
>>>>>>>
>>>>>>> in package/Makefile.package.in. The glob gets expanded prematurely (to
>>>>>>> e.g. myfile.patch) and then the expanded glob is passed to
>>>>>>> apply-patches.sh which will fail to find any patches matching the
>>>>>>> glob. I've had a go at trying to stop this happening but with no
>>>>>>> success so far. Can anyone think of any creative ways to suppress this
>>>>>>> expansion?
>>>>>>>
>>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I see what you mean but I can't reproduce your issue:
>>>>>
>>>>>
>>>>>
>>>>> Hi Ludovic, thanks for the quick response!
>>>>>
>>>>> Did you have a dummy patch file in the top-level? e.g.:
>>>>>
>>>>> # cd buildroot
>>>>> # touch mypatch.patch
>>>>> # make
>>>>>
>>>>
>>>> Yes I did this, I have created an empty patch file.
>>>>
>>>>
>>>>> For me that causes the patch patterns passed to apply-patches.sh to
>>>>> look like: mypatch.patch *.patch.arm. The arch specific glob in this
>>>>> case does not match anything so it remains unexpanded.
>>>>>
>>>>
>>>> I agree but I had no error. I didn't do the whole build so maybe I will
>>>> encounter an issue later due to the "no-patched" binutils.
>>>
>>>
>>> I don't think it will cause an obvious issue for most people - I
>>> happen to have a patched binutils so that if the patch is missing
>>> things go wrong quite obviously. I put an echo in the top of
>>> apply-patches.sh and I was quite clearly seeing the glob had been
>>> expanded by the time it was run (whilst building host-binutils).
>>
>>
>> Still true with the patch I sent?
>>
>> For me the glob was expanded here: scan_patchdir $patchdir $patchpattern
>
> Ah yes, of course it was my echo that was expanding the glob! ;-)
>

Yes, use echo "$myvar" to avoid expansion.

> Yes, I just tried your patch and it fixes the problem for me. Thanks!
>

Ok good news.


Regards

Ludovic

Patch

diff --git a/support/scripts/apply-patches.sh 
b/support/scripts/apply-patches.sh
index e4b98bc..787a297 100755
--- a/support/scripts/apply-patches.sh
+++ b/support/scripts/apply-patches.sh
@@ -11,6 +11,10 @@  patchdir=${2-../kernel-patches}
  shift 2
  patchpattern=${@-*}

+echo "====================="
+echo "$patchpattern"
+
  if [ ! -d "${builddir}" ] ; then
      echo "Aborting.  '${builddir}' is not a directory."
      exit 1