Problem with apply-patches.sh

Buildroot New Will Newton 3 participants 11 messages Apr 16, 2012

Share & tools

Will Newton

author

2012-04-16 14:40 UTC #0 lore raw

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,

Ludovic Desroches

2012-04-16 16:00 UTC #1 lore raw

Le 04/16/2012 04:40 PM, Will Newton a ?crit :

Quoted 11 lines

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;

Quoted 8 lines

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:

(quoted diff) +0 -0

b/support/scripts/apply-patches.sh
index e4b98bc..787a297 100755

support/scripts/apply-patches.sh +3 -0

@@ -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

Quoted 1 line

Quoted 1 line
Quoted 1 line
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 -

Quoted 1 line

Quoted 1 line
Quoted 1 line
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

ludovic.desroches at atmel.com

2012-04-16 16:02 UTC #2 lore raw

PATCH 1/1 apply-patches.sh: patch pattern was expanded prematurely

From: Ludovic Desroches <[email protected]>

The patch pattern was expanded before being into the patch directory so the expansion add incorrect files.

Signed-off-by Ludovic Desroches <[email protected]>

---
 support/scripts/apply-patches.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

support/scripts/apply-patches.sh +1 -1

index e4b98bc..f82be86 100755
@@ -87,7 +87,7 @@ function scan_patchdir {
     fi
 }
 
-scan_patchdir $patchdir $patchpattern
+scan_patchdir "$patchdir" "$patchpattern"
 
 # Check for rejects...
 if [ "`find $builddir/ '(' -name '*.rej' -o -name '.*.rej' ')' -print`" ] ; then

Signature · 1 line

1.7.5.4

Ludovic Desroches

2012-04-16 16:07 UTC #3 lore raw

PATCH 1/1 apply-patches.sh: patch pattern was expanded prematurely

Le 04/16/2012 06:02 PM, ludovic.desroches at atmel.com a ?crit :

Quoted 5 lines

From: Ludovic Desroches<[email protected]>
The patch pattern was expanded before being into the patch directory so the expansion add incorrect files.

sorry for the typo: the expansion can add incorrect files.

Regards

Ludovic

Peter Korsgaard

2012-04-16 21:19 UTC #4 lore raw

PATCH 1/1 apply-patches.sh: patch pattern was expanded prematurely

In reply to ludovic.desroches at atmel.com

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"ludovic" == ludovic desroches <[email protected]> writes:

ludovic> From: Ludovic Desroches <[email protected]> The ludovic> patch pattern was expanded before being into the patch ludovic> directory so the expansion add incorrect files.

Committed, thanks.

Signature · 1 line

Bye, Peter Korsgaard

Will Newton

author

2012-04-16 16:09 UTC #5 lore raw

In reply to Ludovic Desroches

Quoted 22 lines · Ludovic Desroches

Hi
Le 04/16/2012 04:40 PM, Will Newton a ?crit :
Quoted 18 lines
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?

Quoted 4 lines

Quoted 1 line
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

2012-04-16 16:23 UTC #6 lore raw

Le 04/16/2012 06:09 PM, Will Newton a ?crit :

Quoted 29 lines

Quoted 22 lines · Ludovic Desroches
Hi
Le 04/16/2012 04:40 PM, Will Newton a ?crit :
Quoted 18 lines
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?
Quoted 4 lines
Quoted 1 line
Thanks,
I see what you mean but I can't reproduce your issue:

Quoted 8 lines

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.

Quoted 4 lines

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

author

2012-04-16 16:27 UTC #7 lore raw

Quoted 46 lines · Ludovic Desroches

Le 04/16/2012 06:09 PM, Will Newton a ?crit :
Quoted 32 lines
Quoted 23 lines · On Mon, Apr 16, 2012 at 5:00 PM, Ludovic Desroches…
Hi
Le 04/16/2012 04:40 PM, Will Newton a ?crit :
Quoted 18 lines
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?
Quoted 5 lines
Quoted 1 line
Thanks,
I see what you mean but I can't reproduce your issue:
Quoted 8 lines
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.

Quoted 7 lines

Quoted 4 lines
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

2012-04-16 16:42 UTC #8 lore raw

Le 04/16/2012 06:27 PM, Will Newton a ?crit :

Quoted 53 lines

Quoted 51 lines · Ludovic Desroches
Le 04/16/2012 06:09 PM, Will Newton a ?crit :
Quoted 32 lines
Quoted 23 lines · Ludovic Desroches
Hi
Le 04/16/2012 04:40 PM, Will Newton a ?crit :
Quoted 18 lines
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?
Quoted 5 lines
Quoted 1 line
Thanks,
I see what you mean but I can't reproduce your issue:
Quoted 8 lines
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.
Quoted 4 lines
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.

Quoted 8 lines

Quoted 2 lines
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:

Quoted 1 line

Quoted 1 line
Quoted 1 line
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 -

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
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

Quoted 1 line

Quoted 1 line
Quoted 1 line
binutils 2.21.1 Patching libtool

With the patch:

Quoted 1 line

Quoted 1 line
Quoted 1 line
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 -

Quoted 1 line

Quoted 1 line
Quoted 1 line
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).

Quoted 1 line

Quoted 1 line
Quoted 1 line
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

Quoted 4 lines

Quoted 1 line
Quoted 1 line
binutils 2.21.1 Patching libtool
For the record my make is 3.81 and bash is 4.1.2.

Regards

Ludovic

Will Newton

author

2012-04-16 16:54 UTC #9 lore raw

Quoted 70 lines · Ludovic Desroches

Le 04/16/2012 06:27 PM, Will Newton a ?crit :
Quoted 61 lines
Quoted 50 lines · On Mon, Apr 16, 2012 at 5:23 PM, Ludovic Desroches…
Le 04/16/2012 06:09 PM, Will Newton a ?crit :
Quoted 35 lines
Quoted 24 lines · On Mon, Apr 16, 2012 at 5:00 PM, Ludovic Desroches…
Hi
Le 04/16/2012 04:40 PM, Will Newton a ?crit :
Quoted 18 lines
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?
Quoted 6 lines
Quoted 1 line
Thanks,
I see what you mean but I can't reproduce your issue:
Quoted 8 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 5 lines
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).

Quoted 3 lines

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

2012-04-16 16:58 UTC #10 lore raw

Le 04/16/2012 06:54 PM, Will Newton a ?crit :

Quoted 72 lines

Quoted 70 lines · Ludovic Desroches
Le 04/16/2012 06:27 PM, Will Newton a ?crit :
Quoted 66 lines
Quoted 50 lines · Ludovic Desroches
Le 04/16/2012 06:09 PM, Will Newton a ?crit :
Quoted 35 lines
Quoted 24 lines · Ludovic Desroches
Hi
Le 04/16/2012 04:40 PM, Will Newton a ?crit :
Quoted 18 lines
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?
Quoted 6 lines
Quoted 1 line
Thanks,
I see what you mean but I can't reproduce your issue:
Quoted 8 lines
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.
Quoted 7 lines
Quoted 4 lines
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).

Quoted 6 lines

Quoted 3 lines
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.

Quoted 2 lines

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

Ok good news.

Regards

Ludovic