I am trying to patch a Magento 1.7.0.2 with the
PATCH_SUPEE-6788_CE_1.7.0.2_v1-2015-10-27-12-00-16.sh
I have solved several line ending problems and missing .htaccess.sample ...
But these file cannot be patched:
patching file app/code/core/Mage/Core/Controller/Varien/Router/Admin.php
Hunk #1 FAILED at 131.
1 out of 1 hunk FAILED -- saving rejects to file
app/code/core/Mage/Core/Controller/Varien/Router/Admin.php.rej
patching file lib/Varien/Data/Collection/Db.php
Hunk #1 FAILED at 410.
Hunk #2 FAILED at 474.
2 out of 2 hunks FAILED -- saving rejects to file
lib/Varien/Data/Collection/Db.php.rej
I downloaded a fresh Magento 1.7.0.2 copy (from https://www.magentocommerce.com/download)
and tried to apply the patch on it but also
failed.
Checked the lines mentioned on CLI (like FAILED at 131)
but I did not found anything suspicious.
Also it did not write any .rej files
Any advise ?
Thanks
step 1: Backup the site
step 2: apply all previous patches for your site version
step 3: apply the latest patch
step 4: you should get an error - download Magento 1.7.0.2 and upload the files it says it fails.
e.g. upload the db.php file to the correct directory. (first download your site's version of that file as a backup)
step 5: reapply the patch - it should work.
Related
First time eveer runing mftf I installed with composer with in a m2 2.3.5 and when I run the build I get this message:
mftf build:project
mftf files removed from filesystem.
codeception.yml applied to /var/www/html/dev/tests/acceptance/codeception.yml
functional.suite.yml configuration successfully applied.
functional.suite.yml applied to /var/www/html/dev/tests/acceptance/tests/functional.suite.yml
command.php copied to /var/www/html/dev/tests/acceptance/utils/command.php
.credentials.example successfully applied.
.env configuration successfully applied.
In Configuration.php line 212:
Output path is not defined by key "paths: output"
In BuildProjectCommand.php line 105:
The codecept build command failed unexpectedly. Please see the above output for more details.
Any ideas what can be ?
I'm trying to deploy a Java 11 Maven project in App Engine(Standard), using mvn appengine:deploy command.
It was successful until last week.
This week after Google cloud sdk got updated to 288.0.0 the deployment is failing with below error.
i tried reverting Cloud SDK version but still the issue persists.
Project Id is of format- google.com:abc-xyz
Cloud Build Log Snippet below:
....
Finished Step #2 - "detector"
Starting Step #3 - "analyzer"
Step #3 - "analyzer": Already have image (with digest): us.gcr.io/gae-runtimes/buildpacks/java11/builder:java11_20200223_11_0_RC00
Step #3 - "analyzer": ERROR: failed to access previous image: could not parse reference: us.gcr.io/**google.com:abc-xyz**/app-engine-tmp/ttl-7d/default/buildpack-app:latest
Finished Step #3 - "analyzer"
ERROR
ERROR: build step 3 "us.gcr.io/gae-runtimes/buildpacks/java11/builder:java11_20200223_11_0_RC00" failed: step exited with non-zero status: 1
-Thanks
Your error appears to be a result of the project ID google.com:${ID}
The causes an error for Container Registry because it wants e.g.
[us.]gcr.io/${PROJECT}/${IMAGE}...
but it's getting
[us.]gcr.io/google.com:${PROJECT}..
IIRC google.com: is a defunct method of specifying projects. You should just use ${PROJECT} without any domain prefixing.
Hmmm... you said that the project is in production and this used to work. I think this is possibly (effectively) a breaking change for you. I'll Google it but, using domain prefixes (google.com:) used to be a thing in GCP and perhaps this is now formally deprecated. Guess (!?).
i updated a project from TYPO3 7.6 to ^8 by following the official guide. latest steps were the composer update. i removed extensions/packages not compatible with ^8 and updated the ones available for ^8. im able to reach the install tool, the TYPO3 admin backend and the frontend (with errors).
so i ended up at the step were i should use the upgrade wizards provided by the install tool. i completed a few wizards without any issues but then faces a pretty one - first i tried to run DatabaseRowsUpdateWizard within the install tool but that failed with a memory error - i tried the cli approach with
php -d memory_limit=-1 vendor/bin/typo3cms upgrade:wizard DatabaseRowsUpdateWizard
the processing worked but it ended up with following error:
[ Helhum\Typo3Console\Mvc\Cli\FailedSubProcessCommandException ]
#1485130941: Executing command "upgrade:subprocess" failed (exit code: "1")
thrown in file vendor/helhum/typo3-console/Classes/Install/Upgrade/UpgradeHandling.php
in line 284
the command initially failed is:
'/usr/bin/php7.2' 'vendor/bin/typo3cms' 'upgrade:subprocess' '--command' 'executeWizard' '--arguments' 'a:3:{i:0;s:24:"DatabaseRowsUpdateWizard";i:1;a:0:{}i:2;b:0;}'
and here is the subprocess exception:
[ Sub-process exception: TYPO3\CMS\Core\Resource\Exception\InvalidPathException ]
#1320286857: File ../disclaimer_de.html is not valid (".." and "//" is not allowed in path).
thrown in file typo3/sysext/core/Classes/Resource/Driver/AbstractHierarchicalFilesystemDriver.php
in line 71
im pretty much lost and dont know were to start to get this fixed - help is much appreciated
Issues like these usually stem from broken URLs in RTE fields as can be seen in the error output:
File ../disclaimer_de.html is not valid (".." and "//" is not allowed in path)
In this case you should manually prepare the database and run SQL statements which replace the broken/obsolete ../ prefix from all affected records. An example query:
UPDATE tt_content
SET bodytext = REPLACE(bodytext, 'href="../', 'href="')
WHERE bodytext LIKE '%href="../';
Notice that this query is very basic and can destroy your data, so make sure you run some SELECT statements first to make sure nothing breaks. Also keep a backup of your database at hand.
Sometime, custom or TER extension also have RTE such as tt_news where you might come across same issue. To fix that, you just need to run the same query with the according table.
I have a conflict between a number of install files.
I am getting the below error:
Transaction Summary
================================================================================
Install 612 Packages
Total size: 110 M Installed size: 403 M Downloading Packages: Running
transaction check Transaction check succeeded. Running transaction
test Error: Transaction check error: file /etc/iproute2/rt_protos
conflicts between attempted installs of
base-files-3.0.14-r89.nexbox_a95x_s905x and iproute2-4.14.1-r0.aarch64
file /etc/iproute2/rt_tables conflicts between attempted installs of
base-files-3.0.14-r89.nexbox_a95x_s905x and iproute2-4.14.1-r0.aarch64
file /etc/sysctl.conf conflicts between attempted installs of
base-files-3.0.14-r89.nexbox_a95x_s905x and procps-3.3.12-r0.aarch64
Error Summary
-------------
ERROR: amlogic-image-headless-sd-1.0-r0 do_rootfs: Function failed:
do_rootfs ERROR: Logfile of failure stored in:
/home/user/amlogic-bsp/build/tmp/work/nexbox_a95x_s905x-poky-linux/amlogic-image-headless-sd/1.0-r0/temp/log.do_rootfs.29264
ERROR: Task
(/home/user/amlogic-bsp/meta-meson/recipes-core/images/amlogic-image-headless-sd.bb:do_rootfs)
failed with exit code '1' NOTE: Tasks Summary: Attempted 3131 tasks of
which 3130 didn't need to be rerun and 1 failed.
I have seen somewhere that I should pin a file, but how do I do this? I can't find a tutorial or any reference to what that means.
I am also getting the below warning. Is this related?
WARNING: Layer meson should set LAYERSERIES_COMPAT_meson in its
conf/layer.conf file to list the core layer names it is compatible
with.
I'm new to OE coming over from OpenWRT.
For bitbake, I've added the layers for the packages below:
meta-openwrt:- OE/Yocto metadata layer for OpenWRT
superna9999/meta-meson:- Upstream Linux Amlogic Meson Yocto/OpenEmbedded Layer
And tried compiling the nexbox-a95x-s905x image
I think the problem is that /etc/iproute2/rt_protos is provided by base-files which is coming from meta-openwrt as well as from iproute2 package which is coming from other OE layers. its not clear for the image builder which one to use and hence the conflict
You can solve it via defining a iproute2_%.bbappend file in meta-openwrt where this file gets deleted from iproute2 package and preference is given to the one openwrt provides
do_install_append() {
rm -rf ${D}${sysconfdir}/iproute2/rt_protos
}
should help.
I am trying to deploy my application code with Chef, which is working for one node and failing on another. I cannot determine why it works for one node and not another when they have the exact same config, but I can at least try to debug the problem on the node that fails.
deploy_revision app_config['deploy_dir'] do
scm_provider Chef::Provider::Git
repo app_config['deploy_repo']
revision app_config['deploy_branch']
if secrets["deploy_key"]
git_ssh_wrapper "#{app_config['deploy_dir']}/git-ssh-wrapper" # For private Git repos
end
enable_submodules true
shallow_clone false
symlink_before_migrate({}) # Symlinks to add before running db migrations
purge_before_symlink [] # Directories to delete before adding symlinks
create_dirs_before_symlink [] # Directories to create before adding symlinks
# symlinks()
action :deploy
restart_command do
service "apache2" do action :restart; end
end
end
This is my recipe for deploying the code. Notice that I have tried disabling symlinking entirely, as Chef always jams its own defaults in. Even with this I get the error:
================================================================================
Error executing action `deploy` on resource 'deploy_revision[/var/www]'
================================================================================
Chef::Exceptions::FileNotFound
------------------------------
Cannot symlink /var/www/shared/config/database.yml to /var/www/releases/7404041cf8859a35de90ae72091bea1628391075/config/database.yml before migrate: No such file or directory - /var/www/shared/config/database.yml or /var/www/releases/7404041cf8859a35de90ae72091bea1628391075/config/database.yml
Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/kapture/recipes/api.rb
68:
69: deploy_revision app_config['deploy_dir'] do
70: scm_provider Chef::Provider::Git
71: repo app_config['deploy_repo']
72: revision app_config['deploy_branch']
73: if secrets["deploy_key"]
74: git_ssh_wrapper "#{app_config['deploy_dir']}/git-ssh-wrapper" # For private Git repos
75: end
76: enable_submodules true
Compiled Resource:
------------------
# Declared in /var/chef/cache/cookbooks/kapture/recipes/api.rb:69:in `from_file'
deploy_revision("/var/www") do
destination "/var/www/shared/cached-copy"
symlink_before_migrate {"config/database.yml"=>"config/database.yml"}
updated_by_last_action true
restart_command #<Proc:0x00007f40f366e5a0#/var/chef/cache/cookbooks/kapture/recipes/api.rb:82>
repository_cache "cached-copy"
retries 0
keep_releases 5
create_dirs_before_symlink ["tmp", "public", "config"]
updated true
provider Chef::Provider::Deploy::Revision
enable_submodules true
deploy_to "/var/www"
current_path "/var/www/current"
recipe_name "api"
revision "HEAD"
scm_provider Chef::Provider::Git
purge_before_symlink ["log", "tmp/pids", "public/system"]
git_ssh_wrapper "/var/www/git-ssh-wrapper"
remote "origin"
shared_path "/var/www/shared"
cookbook_name "kapture"
symlinks {"log"=>"log", "system"=>"public/system", "pids"=>"tmp/pids"}
action [:deploy]
repo "git#github.com:kapture/api.git"
retry_delay 2
end
[2012-09-24T15:42:07+00:00] ERROR: Running exception handlers
[2012-09-24T15:42:07+00:00] FATAL: Saving node information to /var/chef/cache/failed-run-data.json
[2012-09-24T15:42:07+00:00] ERROR: Exception handlers complete
[2012-09-24T15:42:07+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2012-09-24T15:42:07+00:00] FATAL: Chef::Exceptions::FileNotFound: deploy_revision[/var/www] (kapture::api line 69) had an error: Chef::Exceptions::FileNotFound: Cannot symlink /var/www/shared/config/database.yml to /var/www/releases/7404041cf8859a35de90ae72091bea1628391075/config/database.yml before migrate: No such file or directory - /var/www/shared/config/database.yml or /var/www/releases/7404041cf8859a35de90ae72091bea1628391075/config/database.yml
Here you can see it mention database.yml, tmp/, system/ and pids folders, all of which are defaults that Chef likes to set (see related bug)
Question 1
What are these symlinks for and how do I know if I even need any. What sort of things am I symlinking? I will be using migrations, so if they are useful for the migration then I'll need them working.
I have read the documentation many times and it just doesn't explain this is plain English - at least not that I have found.
Question 2
If I do not require them, how can I disable symlinking entirely? Following the examples in that bug report have not helped.
Clear out all the symlink attributes.
deploy_revision("/var/www") do
# ...
symlink_before_migrate.clear
create_dirs_before_symlink.clear
purge_before_symlink.clear
symlinks.clear
end
Make sure the deployment directory in shared has the proper directory structure (/var/www/shared/[log,pids,system,config]) and that all config files necessary for your application are in the config directory.
Your recipe for your application's cookbook should have an array of directory names to create (recursively) so that you won't run into this error again.
The symlinks are there so that while your application code will continue to evolve, you can share the log, pids, and system folder by symlinking shared/log to current/log and so on and so forth..
Chef happens to cache the directory structure - somehow, I haven't dug into that - with this troll application cookbook. It's something in the deploy resource I believe - I never use that - but you can fix it by deleting the directory structure it creates in /var/derp or whatever. Also ensure your tmp directory is setup.
A couple reasons this may be an issue:
File permissions are incorrect
The currently running chef user cannot access the file
You are using the application cookbook in a configuration for rails deploys and your application does not have the same directory structure.
It's definitely caused by Chef caching the state of the deploy somewhere, then reading that state out of it's cache - wherever that is - and then reusing that. I would look at either the application cookbook to see for any persistance, and if you fail at finding it there, look in the deploy resource from chef itself.