bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch file bash42-049 is broken


From: Deron Meranda
Subject: Re: Patch file bash42-049 is broken
Date: Sun, 28 Sep 2014 00:51:51 -0400

I was wondering if anybody was going to address the problem with 4.2 patch
49 ?

It is still corrupted on the FTP server.  There are a few lines that appear
to have been deleted out of the middle of the patch file.

Not only is there a critical line of code missing, but the the 'patch'
command will also fail when used with the --fuzz=0 option -- which is
something that rpmbuild (Fedora, etc) uses.

Thanks

On Sat, Sep 27, 2014 at 3:25 AM, Deron Meranda <deron.meranda@gmail.com>
wrote:

> I'm trying to patch Bash 4.2 with the latest patch 049.  It appears as if
> the patch file itself is corrupted.  The corresponding patch 026 for Bash
> 4.3 is fine.
>
> When running patch with mostly default arguments, it seems to work but has
> to use merge fuzzing, which it complains about...
>
> $ patch -p0 <../bash4.2-patches/bash42-049
> patching file parse.y
> Hunk #2 succeeded at 6062 with fuzz 2 (offset -2317 lines).
> patching file patchlevel.h
>
>
> However when patching with fuzzing disabled (--fuzz=0) the patch will
> completely fail.  It should be noted that Fedora Linux and perhaps other
> RPM-based distros always apply patches (when using the rpmbuild tool) with
> fuzzing set to zero intentionally to catch broken patch files.  The output
> then is:
>
> $ patch -p0 --fuzz=0 <../bash4.2-patches/bash42-049
> patching file parse.y
> Hunk #2 FAILED at 8379.
> 1 out of 2 hunks FAILED -- saving rejects to file parse.y.rej
> patching file patchlevel.h
>
>
> Here's the patch file checksum that I got from the FTP server. I also
> validated the GPG signature of the patch file, which was good.
>
> $ sha1sum bash42-049
> fce8e1026c0480321b3ee5a9ccef955955a4d5f3  bash42-049
>
>
> After some investigation and comparing it with 4.3 patch 26, it looks like
> the 49 patch file is missing a file name separator.  The patch chunk that
> is attempting to remove a blank line at the end of the file after the line,
>
>    #endif /* HANDLE_MULTIBYTE */
>
> should be trying to remove it from the file "y.tab.c", but is instead
> trying to modify the file "parse.y".
>
> I suspect there may be another patch chunk that is also missing from the
> middle of the patch file too.
>
>
> On an unrelated note, I have also tried to compare sources against the
> Savannah Git repository, and I noted that the repository has a couple small
> differences from the FTP files + patches.
>
> The Git repo has a blank file called "-i", probably an accident of some
> command line arguments.  The repo also has a few extra files not in the FTP
> version — though those differences may be intentional (?)   Comparing Bash
> 4.3 patchlevel 26 from the FTP version and Git commit
> 836a17be08ee0696b89367ab1aa27d0be87169ed:
>
> $ diff -q -r -x .git  bash-4.3.26  bash-git
> Only in bash-git: configure.in
> Only in bash-git/CWRU: audit-patch
> Only in bash-git/CWRU: mh-folder-comp
> Only in bash-git: -i
> Only in bash-git: MANIFEST.doc
> Only in bash-git/tests: cond-regexp.sub
>
>
>
> Thanks for your efforts these past few days.
>
>
> Deron
> --
> Deron Meranda
> http://deron.meranda.us/
>



-- 
Deron Meranda
http://deron.meranda.us/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]