Re: Errors when patching bash4.0

[Alex Reed]

On Jul 22, 4:09 pm, Bob Proulx <b...@proulx.com> wrote:
> Alex Reed wrote:
> > At least one "hunk" fails on every patch file.  What am I doing wrong?
>
> Hmm...  Works for me.  Here is a trace of the important bits.
>
>   $ wgetftp://ftp.gnu.org/pub/gnu/bash/bash-4.0.tar.gz
>   $ wgetftp://ftp.gnu.org/pub/gnu/bash/bash-4.0.tar.gz.sig
>
>   $ wgetftp://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/bash40-001
>   $ wgetftp://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/bash40-001.sig
>
>   $ gpg bash-4.0.tar.gz.sig
>   gpg: Signature made Mon 09 Mar 2009 08:32:40 AM MDT using DSA key ID 
> 64EA74AB
>   gpg: Good signature from "Chet Ramey <c...@cwru.edu>"
>   gpg: WARNING: This key is not certified with a trusted signature!
>   gpg:          There is no indication that the signature belongs to the 
> owner.
>   Primary key fingerprint: 7C01 35FB 088A AF6C 66C6  50B9 BB58 69F0 64EA 74AB
>
>   $ gpg bash40-001.sig
>   gpg: Signature made Mon 09 Mar 2009 08:32:40 AM MDT using DSA key ID 
> 64EA74AB
>   gpg: Good signature from "Chet Ramey <c...@cwru.edu>"
>   gpg: WARNING: This key is not certified with a trusted signature!
>   gpg:          There is no indication that the signature belongs to the 
> owner.
>   Primary key fingerprint: 7C01 35FB 088A AF6C 66C6  50B9 BB58 69F0 64EA 74AB
>
> The key point there with a good signature we know that the patches are
> not corrupted.  The signature step would detect this.  The key is the
> same key used on all of the patches.  The patches match those posted
> to the mailing list.  Those patches probably came from Chet.  :-)
>
>   $ tar xzf bash-4.0.tar.gz
>   $ cd bash-4.0
>   $ patch -p0 < ../bash40-001
>   patching file parse.y
>   patching file patchlevel.h
>
>   $ patch --version
>   patch 2.5.9
>
> Works for me.
>
>   $ sha1sum bash40-001 bash-4.0.tar.gz
>   dc47d547bec938afcd7b382816fec84077f3412f  bash40-001
>   2bbed30879f9f424c091a846a48111c27d0b2370  bash-4.0.tar.gz
>
> I would check that your downloaded patch files are not corrupted for
> some reason.  I would check that line endings are respected and for
> similar things that might confuse things.  I am not familiar with
> using lynx as a downloader although I am sure it is fine for the
> task.  But at a guess I would think that would be the place to start
> to look for problems.
>
> Bob

You make a good point in the last paragraph - lynx "should" work (but
doesn't).  Considering I was having to specify a maximum line-length,
lynx (I suppose) was still botching the files.  After using wget in
place of lynx (with the appropriate proxy flag changes) everything
patched a-okay.

Thanks!
-Alex