I am applying these two patched SUPEE-6282 and SUPEE-6285.
PATCH_SUPEE-6482_CE_1.9.2.0_v1-2015-08-03-06-51-10.sh
PATCH_SUPEE-6285_CE_1.8.1.0_v1-2015-07-07-09-06-30.sh
But my sever support show errors like-
patching file app/Mage.php Hunk #1 FAILED at 814. 1 out of 1 hunk
FAILED -- saving rejects to file app/Mage.php.rej
My server support say that this error is showing due to my custom programming. How can i fix it.
Thanks
This happen normal when you miss previous patches. Do you have the previous patches installed? If not, you will need to install them before SUPEE-6282
I suggest you to upgrade your magneto to 1.9 which contain all the patches.
Have a look https://community.magento.com/t5/Security-Patches/Security-Patch-SUPEE-6285-Error-Hunk-5-FAILED-at-1115/m-p/10156
For fix that, is need to copy the theme "modern" from magento-1.9.0.1 to your magento actual version.
In my case this were issue.
*can't find file to patch at input line 894
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
|diff --git app/design/frontend/default/modern/template/checkout/cart.phtml app/design/frontend/default/modern/template/checkout/cart.phtml
|index 43698c2..f4fe5ab 100644
|--- app/design/frontend/default/modern/template/checkout/cart.phtml
|+++ app/design/frontend/default/modern/template/checkout/cart.phtml
--------------------------*
On my case, just copy theme, solve the issue!
=)
Related
I spent all day trying to make Host sFlow 2.0.6-1 from sources (https://github.com/sflow/host-sflow/releases) for XenServer 7.0 using the XenServer DDK from this site: http://xenserver.org/overview-xenserver-open-source-virtualization/download.html
First I had to make 2 changes to the file hsflowd-xen.spec:
Changed line 3 to: "Version: 2.0.6" (it was still 2.0.1)
Changed line 20 to: "%setup -n hsflowd-2.0.6-1" (added the name because the default one was wrong).
Now my problem is that I dont have the xenstore.h file. After long searches I found that it's in the package libxen-dev (or libxen-devel) but I couldn't find it with its dependecies anywhere.
The four most probable solutions I think are :
1. (The lazy one) Get the iso file for Host sFlow already built for XenServer 7.0 (the official site stopped building at 6.5)
Set up a proper yum repository that will contain libxen-dev and its dependencies. I can't even connect to the official CentOS repositories because the files in /etc/yum.repos.d/ have a bad URL.
This is the content of /etc/centos-release: "XenServer DDK release 7.0.0-125770c (xenenterprise)"
Somehow manage to use 'xenstore.a' instead of 'xenstore.h'. I changed the code in src/Linux/mod_xen.c to include 'xenstore.a' instead of 'xenstore.h' but when I build it, it creates a new file with the old code and ignores my changes. I probably changed the wrong files because there are different copies of the whole code. I'm not even sure it would work though even if I did manage to include 'xenstore.a'.
Make xenstore from sources. I didn't try it because I only found old sources and I figured I'd miss the dependencies too.
PS: I'm n00b at CentOS and Makefiles in general so the solution might be obvious and I just don't know it.
With gratitude to lagange, I updated the host-sflow project with a XenServer 7 build. I also added a Docker recipe so you can replace all these steps with just "./docker_build_on xenserver". Please raise issues on https://github.com/sflow/host-sflow.
I finally succeeded in building it. That's what I had to do step by step:
Import the XenServer DDK 7.0.0 into XenCenter.
Extend xvda1 following these steps: https://support.citrix.com/article/CTX125405
Make these changes to hsflowd-xen.spec:
3rd line: Version: 2.0.6
20th line: %setup -n hsflowd-2.0.6-1
Add these two lines before %description:
%define debug_package %{nil}
%define _unpackaged_files_terminate_build 0
Change file /etc/yum.repos.d/CentOS-Base
Change all occurrences of "$releasever" to "7".
Change all occurrences of "$basearch" to "x86_64".
Change "enabled=0" to "enabled=1" for each repository.
Uncomment baseurl lines for each repository.
Mount the Development packages (binpkg.iso available on the xenserver.org download page) and add a file for it in /etc/yum.repos.d/
Mine looks like it:
[binpkg]
name=CitrixXenServer7
enabled=1
baseurl=file:///mnt/binpkg/
gpgcheck=0
Install the two following packages with Yum (dependencies should install correctly now):
xen-libs-devel.x86_64
xen-dom0-libs-devel.x86_64
Make the file and install it using this tutorial: https://raw.githubusercontent.com/sflow/host-sflow/v2.0.4/INSTALL.XenServer
I've created packages previously by using a Makefile, the command "dh_make --createorig", then adjusting files in the debian folder generated and finally using the debuild command to generate the .deb. That workflow is simple and works for me, but I was told to adjust it a little in a way that you could build the project from the sources without requiring the orig files and I'm unsure how to do it, but according to this (https://askubuntu.com/questions/17508/how-to-have-debian-packaging-generate-two-packages-given-an-upstream-source-arch) and this structure (http://bazaar.launchpad.net/~andrewsomething/imagination/debian/files) there must be a way. In my case I would have a folder with the sources and all of that and then a debian folder (generated with dh_make) but I'm unsure on how to avoid the debuild command to ask for the .orig files or if I should be using some other command for this.
Sorry for the superlong question, I think I provided all the relevant information, but I can clarify if anything is fuzzy.
The difference is in the version number in the file debian/changelog.
If you use 1.2.3-1 it implied Debian build 1 of an upstream package 1.2.3 --- for which the build programs (dpkg-buildpackage and whichever wrappers on top) --- assume an .orig.tar.gz to exists.
But if you use 1.2.3 it will consider the package 'Debian native' and the archive is just a .tar.gz and not an .orig.tar.gz.
Now the choice should not be driven by your convenience alone. If this has an upstream source, use the first scheme. If not, the second can be fine. In the packages I maintain I have both but way more of the former.
If you want to create a Debian directory directly in the source package (ie you're packaging your own work, rather than from an upstream release) you could use the --native option to dh_make
I think the question was asked differently, it was somewhat clear that the project was upstream and it's probably not a good reason to change its format to native.
Currently I package some upstream python project, this exact same question came to my mind. Why isn't there any dh_* hook to overwrite in order to generate this origin tarball on the fly so you do not get bothered by:
This package has a Debian revision number but there does not seem to be
an appropriate original tar file or .orig directory in the parent directory;
for a start, I added a makefile to the project:
# Makefile
VERSION:=$(shell dpkg-parsechangelog -S Version | sed -rne 's,([^-\+]+)+(\+dfsg)*.*,\1,p'i)
UPSTREAM_PACKAGE:=click_${VERSION}.orig.tar.gz
dpkg:
tar cafv ../${UPSTREAM_PACKAGE} . --exclude debian --exclude .git
debuild -uc -us
clean:
rm -f ../${UPSTREAM_PACKAGE}
debuild clean
so a simple make clean dpkg was all it needed to build the package.
Now I think the question remains if someone has some bright idea how to insert the tar operation within the debian/rules so I could just call debuild -uc -us and it magically creates the orig tarball I would be awsome :)
I am trying to add a patch to a Debian package (on an amd64 machine running Ubuntu 14.10 "Trusty").
While troubleshooting the issue, I've reduced the patch to one that adds a single file. (For the sake of context, this file modifies a fluxbox package so that it also creates a fluxbox-dbg file with debugging symbols.)
I created the patch by following these steps:
(Made sure I had all existing patches applied.)
quilt new add-dbg-package.patch
quilt add debian/rules.d/70-debug-symbols.mk
(Created that file with the contents I wanted.)
quilt refresh
The patch seems fine:
With all patches applied, the file exists and has the correct contents.
The patch contains a delta that adds the complete contents of the file, and nothing else.
No other patch references the file.
When I pop the new patch, the file is removed; when I push it again, it is recreated.
However, when I try to rebuild the package with debuild, I get this:
The next patch would create the file debian/rules.d/70-debug-symbols.mk, which already exists! Skipping patch.
1 out of 1 hunk ignored
dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
dpkg-source: info: if patch 'add-dbg-package.patch' is correctly applied by quilt, use 'quilt refresh' to update it
If I take its advice, quilt tells me that the patch is up-to-date (as it seems to be). quilt diff tells me that there are no changes.
As one thought: is it incorrect to add quilt patches for changes to Debian control files?
Can anyone help me understand what I've done to offend debuild?
You should not add quilt patches over /debian/ files. The patches are for the code only. Just change the debian/rules.d/70-debug-symbols.mk file and build the package.
The Debian/Ubuntu policy says:
The program quilt offers a basic method for recording modifications to the *upstream source* for Debian packaging.
While attempting to bootstrap Haskell on Windows without the Haskell Platform I ran into the following error
C:\git\Haskell\ghc\libraries\haskeline\dist-install\build/libHShaskeline-0.7.1.2.a: could not read symbols: Archive has no index; run ranlib to add one
Note that C:\git\Haskell\ghc is where I put the ghc git repo.
However whenever I looked at the file it appeared to be building correctly.
I have attempted completely clean rebuilds, and deleting the whole repo and regetting it, everything short of deleting anything related to this build and starting fresh.
I eventually figured out what was causing the issue, I realized it when I found the following notice on the Windows Platform notes for GHC.
However, the makefiles do use whatever ld and ar happen to be in your path.
This didn't seem right, and reading the configure script I noticed the following lines:
mingwbin="$hardtop/inplace/mingw/bin/"
LD="${mingwbin}ld.exe"
Note that mingwbin refers to the location that the tarballs are extracted to. Looking at the timestamps of the executables did not match up to the version that which ld returned (in /mingw/bin).
Given the note that meant that at some point /inplace/mingw/bin/ld.exe was being used while at another point /mingw/bin/ld.exe was being used, possibly causing the issue.
Running the following command before make resolved the issue.
export PATH=/c/git/Haskell/git/inplace/mingw/bin:$PATH
I need to apply a patch to the vim source code, but I am having trouble finding the source code for version 7.3.285. The source code from the main vim site builds version 7.3.154. When I do a google search for "vim 7.3.285 source" I get mostly .rpm files and always something about Mandriva. I managed to find a .scr.rpm file and unpacked it, but then the main vim folder it had was exactly the same as the one on the vim site. My guess is that I have use the patch folder to apply the patch to version 285. So I tried the following:
Download .src.rpm file here
unpack .src.rpm file like so rpm2cpio vim-7.3.285-1.src.rpm | cpio -idmv --no-absolute-filenames
apply the patches to the vim73 folder somewhat like so for i in 'seq 0 285'; do patch -p0 < ../vim-7.3-patches/7.3.$i; done
then I also applied the aforementioned patch in a similar way patch -p1 -i ../vim-7.3.285-breakindent.patch
finally I compiled vim: configure, make and sudo make install
However, and this is where it gets weird, if I issue the command vim, it claims to be running version 7.3.285. If however, I issue the command gvim it claims to be running version 7.3.154. It was my understanding that you compile vim and gvim gets compiled too. Does anyone have any idea what is going wrong? Is there a 7.3.285 source file I can download instead to test out?
to get the 7.3.285 source clone the mercurial repo and then do hg up v7-3-285
full instructions here