With the help of this documentation http://info2.magento.com/rs/magentosoftware/images/Installing-a-Patch-for-Magento-Community-Edition.pdf
i tried to patch on my magento site. but it gives me error as follows
[~/public_html/my_proj]# sh PATCH_SUPEE-7405_CE_1.9.2.3_v1.1-2016-02-23-07-46-32.sh
Checking if patch can be applied/reverted successfully...
ERROR: Patch can't be applied/reverted successfully.
patching file app/code/core/Mage/Adminhtml/Helper/Sales.php
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file app/code/core/Mage/Adminhtml/Helper/Sales.php.rej
patching file app/code/core/Mage/Core/Model/Config.php
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file app/code/core/Mage/Core/Model/Config.php.rej
patching file app/code/core/Mage/Sales/Model/Quote/Item.php
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file app/code/core/Mage/Sales/Model/Quote/Item.php.rej
patching file lib/Varien/File/Uploader.php
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file lib/Varien/File/Uploader.php.rej
Open the files for which you the error message and the rejected files.
For eg:
app/code/core/Mage/Core/Model/Config.php.rej.
In the patch file PATCH_SUPEE-7405_CE_1.9.2.3_v1.1-2016-02-23-07-46-32.sh they have mentioned what is the changes done to this file. Just check it out.
Related
I am working on kernel patchset rather than git stuffs. eg: this patch:1
I download this series of patch and run follow command to patch to kernel-next.
"patch -p1 < ../xxx.patch".
I get some rej files after apply patch.
Does this mean I have to cheery-pick other patch or I have to need fix those reject file one by one.
one of reject file look like
thanks!!
From the patch man page:
If patch cannot find a place to install that hunk of the patch, it
puts the hunk out to a reject file, which normally is the name of the
output file plus a .rej suffix, or # if .rej would generate a file
name that is too long (if even appending the single character # makes
the file name too long, then # replaces the file name's last
character).
The rejected hunk comes out in unified or context diff format. If the
input was a normal diff, many of the contexts are simply null. The
line numbers on the hunks in the reject file may be different than in
the patch file: they reflect the approximate location patch thinks the
failed hunks belong in the new file rather than the old one.
So essentially your patches failed to apply cleanly. Fix the lines shown in the .rej files in the original file that it failed for.
echo "this is test file" > test.txt
echo "this is testy file" > testy.txt
echo "this is test file" > test1.txt #note the extra space
diff test.txt testy.txt > diff.patch
cat diff.patch
1c1
< this is test file
---
> this is testy file
patch -p1 test1.txt diff.patch #trying to patch test1.txt with the diff
patching file test1.txt
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file test1.txt.rej
cat test1.txt.rej
***************
*** 1
- this is test file
--- 1 -----
+ this is testy file
So, in this (dumb example) case, the test1.txt.rej indicates that test1.txt needs to be fixed. You need to manually merge the changes from drm_dp_helper.c.rej file to the file that the patch program failed to apply the changes to i.e. drm_dp_helper.c, which guessing from the failed hunk in the patch is essentially deleting a bunch of arrays etc. I'm guessing your version of drm_dp_helper.c isn't at the same change version with the original patch author's base file and might have had some changes which are leading to the patch application failure.
I'm learning how to use patch, and have encountered strange behaviour when patching two directories:
original_directory contains one file (file1) containing three lines.
updated_directory contains two files: file1 with two extra lines, and an additional file2 (containing seven lines).
I issued diff -Nur original_directory/ updated_directory/ > original_directory.patch. However, when I perform the patch (patch -p0 < original_directory.patch), I get the following output:
patching file updated_directory/file1
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file updated_directory/file1.rej
The next patch would create the file updated_directory/file2,
which already exists! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored
However, when I issue cd original_directory/; patch -p1 < ../original_directory.patch everything works just fine!
I'm sure that patch -p0 < original_directory.patch worked just the other day...
This behaviour is expected and usual. You patch file probably looks something like:
diff -Nur original_directory/file1 updated_directory/file1
--- original_directory/file1 2018-09-26 15:00:33.929223318 +0900
+++ updated_directory/file2 2018-09-26 15:00:41.555279201 +0900
...
...
diff -Nur original_directory/file2 updated_directory/file2
--- original_directory/file2 1970-01-01 09:00:00.000000000 +0900
+++ updated_directory/file2 2018-09-26 15:00:49.325037178 +0900
...
...
With -p1, the first component of the paths of changed files are removed, so the patch sees instructions to make changes to file2 and file1 in the current directory.
With -p0, no path components are removed from the paths, so patch sees instructions to make changes to updated_directory/file2 and updated_directory/file1, but those files already have the required changes.
I am creating a svn diff patch, however it seems the image files are not getting included. The patch contain similar lines for each image file, as shown below:
Index: crimgeoprofile/code/jquery/css/ui-lightness/images/animated-overlay.gif
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: crimgeoprofile/code/jquery/css/ui-lightness/images/animated-overlay.gif
===================================================================
--- crimgeoprofile/code/jquery/css/ui-lightness/images/animated-overlay.gif (revision 1510040)
+++ crimgeoprofile/code/jquery/css/ui-lightness/images/animated-overlay.gif (working copy)
I am using the following command to create a patch:
svn diff > test.diff
Any suggestions on how I can include image files will be appreciated.
SVN does not support to include binary files in diffs. As a side note: git does support binary files. The resulting patch file looks like this:
diff --git a/bin/windows/SDL_mixer.dll b/bin/windows/SDL_mixer.dll
new file mode 100644
index 0000000000000000000000000000000000000000..f48ee2da696f92b66940b91b52aa53c2
GIT binary patch
literal 160256
zcmd?S4SZD9)i*kmOyYopCrYBxf<%o9l`2uFL_&=TgA|RT7>j7Ev^CX7sg%wregu+E
z26K8G$kPW}+uD|hZFwrKv_*(YAs#UMf~XNJW(<Ug6wVlm;iDl0WbXgJ_BoSD06*UQ
z-h1DBFF(yWXYaMwUVE*z*Is+=k13j2?MQYw94`DHi#Z&%c=BJq{Qc}d<;Xr~#Ovoc
zRu6jXl3M4jZ(VZNLl6HbYtG!qzCU-??5yw3`oRw#^JRVK!K}IdA7nlJgRDunPtThD
So technically it is possible, it just doesn't work with svn. So if you desperately need a patch file including binaries, consider checking out svn using git. It's easy: git svn clone http://path/to/svn. Also works similar with svn://.... You can then create a git diff, and apply that diff to any target. The target does not need to be a git repository. git apply my.patch
With Suversion 1.9 you can use --git flag for include binary content to patch file, for example:
svn diff https://storage/svn/project/trunk --git -c 42 > patch-42.diff
Subversion 1.8 already have --git flag, but ignore binary content with it.
Unfortunately, svn diff does not handle binary data.
Check some of the answers from: subversion diff including new files
In particular: https://stackoverflow.com/a/2255846/9822
The Image files are getting included in your diff as indicated by the lines with --- and +++ but they are included as whole files in the patch - this is due in part the the problem of how to meaningfully display changes in binary data such as images in a text only format - unless you would like pages of hex differences, (such as fc -b a.gif b.gif would produce).
So you are told that the files have changed and it is up to you to decide how you would like to compare them - for image files one of the best comparisons of the significant differences is the human eye - you would not expect a revision control system to be able to tell you "This was a picture of a bald man frowning but now it is a pretty redhead cheerleader smiling" would you?
I have a patch file for some software (Magento) and want to apply it to my current project.
The patch file contains also references to files in the var/packages folder which I do not want (I deleted this folder in my installation).
When applying this patch file (patch -p1 < the.patch), I get lots of warnings like:
The next patch would delete the file var/package/Foo_Bar.1.7.0.0.xml,
which does not exist! Assume -R? [n] ^C
Is there any way to tell the patch command to just ignore patches for this folder?
You can use the “filterdiff” utility – http://man.cx/filterdiff – from http://packages.debian.org/patchutils to do that.
Otherwise, just pressing Enter a lot will also help ;-)
You can use filterdiff from the patchutils package.
-x *PATTERN*, --exclude=*PATTERN*
Exclude files matching PATTERN. All other lines in the input are displayed.
So for your example
filterdiff -p1 -x 'var/packages/*' < the.patch | patch -p1
Alternatively you can manually edit the patch to remove the unwanted files, but this make take some time if it's very large.
Occasionally, we receive ZIP files from our suppliers that are seemingly corrupted. Attempting to list the contents of a ZIP will trigger an error like this:
$>unzip -qql JABL_VER_20120808_165910.zip
unzip: cannot find or open JABL_VER_20120808_165910.zip, JABL_VER_20120808_165910.zip.zip or JABL_VER_20120808_165910.zip.ZIP.
I did a quick read of the unzip man page and coded that snippet to trap the above error
EXIT=`echo $?`
case $EXIT in
> 0-1) echo "Unzip Complete.";;
> *) echo "Unzip Failed.";;
> esac
$>Unzip Failed.
It seems to work. However, there are cases like this one where the error is different:
$>unzip -qql JABL_VER_20120808_175915.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of JABL_VER_20120808_175915.zip or
JABL_VER_20120808_175915.zip.zip, and cannot find JABL_VER_20120808_175915.zip.ZIP, period.
Is there a "surefire" way to trap errors like these?
PS: Not sure if matters but the ZIP files are generated on MS Windows ; We use Red Hat.
exit code 1 isn't good either,
1 one or more warning errors were encountered, but processing completed successfully anyway. This includes zipfiles
where one or more files was skipped due to unsupported compression method or encryption with an unknown password.
you should try
unzip -t zipfilename
and only accept exit code 0
why do you have so many errors? ftp'd file in text mode?