I've gotten the OpenERP source using the instructions.
I've moved the whole source directory somewhere else in my home.
Now, when I try to pull changes it throws errors:
shahar#shahar-desktop:~/src/openerp⟫ make pull
# update all trunk branch
for i in addons client oldweb web server; do [ -d $i ] && (cd $i && bzr pull && cd ..); done
bzr: ERROR: Not a branch: "/home/shahar/src/openerp/addons/.bzr/branches/origin/trunk/
/".
bzr: ERROR: Not a branch: "/home/shahar/src/openerp/client/.bzr/branches/origin/trunk/
/".
bzr: ERROR: Not a branch: "/home/shahar/src/openerp/web/.bzr/branches/origin/trunk/
/".
bzr: ERROR: Not a branch: "/home/shahar/src/openerp/server/.bzr/branches/origin/trunk/
/".
make: *** [pull] Error 3
2 shahar#shahar-desktop:~/src/openerp⟫
It isn't the make script that's at fault:
2 shahar#shahar-desktop:~/src/openerp⟫ cd server/
shahar#shahar-desktop:~/src/openerp/server⟫ bzr pull
bzr: ERROR: Not a branch: "/home/shahar/src/openerp/server/.bzr/branches/origin/trunk/
/".
3 shahar#shahar-desktop:~/src/openerp/server⟫
The paths that are printed above seem to be stemming from each repository's .bzr/branch/location file.
I've discovered this file when I tried to fix this issue by using grep -rI /home/shahar. And then I've changed the path within this file from what it was to what you see now. I thought that it could perhaps fix the issue but it didn't. I still got the same errors (with the new paths).
I couldn't find any info about moving bzr repositories in the whole of the interwebs with Google or in StackOverflow.
Thanks.
The installation script you used seems to use the bzr-colo plugin to manage colocated branches.
The bzr-colo manual indicates that because absolute pathnames are used to store references to branches, when a colocated workspace is moved on disk, the link from the checkout to the current branch gets broken.
This can theoretically be fixed by running bzr colo-fixup in the broken branch directory, however it does not seem work very often (in my experience).
In that case the manual recommends running this command to re-force a branch switch:
bzr switch --force .bzr/branches/<current branch name>
According to the output of your commands, this should be:
bzr switch --force .bzr/branches/origin/trunk
for you.
You do not even need to edit the .bzr/branch/location first, as it will be correct after the switch. This has always fixed the situation for me.
Related
I face to an issue with Brackets and Brackets Git that I didn't faced with two previous installations on my other Apple devices.
When I open a new empty folder in Brackets, automatically Brackets Git shows the following error message:
Error: fatal: neither this nor any of its parent directories is a git repository: .git
I'm not allow to Clone or Init the folder as the two commands don't appears.
I tried to open folders that I worked with previously and that are already on my GitHub account, all is work well. Brackets Git IU shows all the available commands.
So, I have a number of Wordpress sites managed with a Git repository, all of which are branches off of a central upstream Git repository. I recently applied a bunch of updates to the parent repo, but one of the child website repos had a plugin updated to a different version and now throws up about 400 rename/rename conflicts. All of these conflicts are in an upstream plugin directory that would be safe to just resolve in favor of the upstream branch.
I want to do the following:
Ensure the upstream version of the files 'wins' the merge conflict (e.g. what the --theirs flag does with checkout)
Produce a mergeable history (If it's not safe for a coworker to type "git pull origin master" with an old repo, it's not an option. I'm religiously opposed to rebasing.)
Not restructure my Git repository (My hosting provider, Pantheon, will not install Composer dependencies at deploy time. Upstream plugins have to be part of the repo.)
Not get a repetitive stress injury (Has to be a reasonably small number of commands because I have to resolve these kinds of messes once a month or so.)
If I just type "git checkout wp-content/plugins/** --theirs", I get hit in the face with about 400 errors, and Git refuses to checkout the files. They look like this:
....400 or so errors omitted...
error: path 'wp-content/plugins/wordpress-seo/js/dist/wp-seo-quick-edit-handler-710.min.js' does not have their version
error: path 'wp-content/plugins/wordpress-seo/js/dist/wp-seo-quick-edit-handler-720.min.js' does not have their version
error: path 'wp-content/plugins/wordpress-seo/js/dist/wp-seo-recalculate-710.min.js' does not have their version
error: path 'wp-content/plugins/wordpress-seo/js/dist/wp-seo-recalculate-720.min.js' does not have their version
I categorically refuse to type 400 git rm/git add commands with each individual path included. git checkout --force is not an option, as --theirs and --force are mutually incompatible (for some reason). My current solution is to open Git GUI and manually right-click -> Use Remote Version and then click Yes... 400 times. I don't have to type the path at least but this is still time consuming.
How do I efficiently resolve a large number of rename/rename conflicts in favor of the remote repository?
Do you want to just resolve the conflicted files in favour of the remote, or just take a whole tree as it is in the remote?
For the latter, you could do this:
Just accept the files as-is with conflicts. git add . or similar
Commit the merge.
rm -Rf path/in/question
git checkout origin/branch -- path/in/question
git commit --amend -a
For the former, it's probably something pretty similar
Just accept the files as-is with conflicts. git add . or similar
Commit the merge.
Find files with conflicts. e.g. grep -r -l '>>>>' path/in/question > /tmp/conflicts.txt
Delete the files with conflicts, check out the desired versions, and amend the commit in a similar means to the above.
(If there are files/paths with spaces in them, small adjustments to the above commands may be necessary. I've given the simpler versions for clarity.)
Problem Definition
I'm attempting to adapt these rosjava installation instructions so that I can include rosjava on a target image built by the BitBake build system. I'm using the jethro branch of Poky.
Implementation Attempt: Build From .deb with package_deb.bbclass
According to the installation instructions, all that really needs to be done to install rosjava is the following:
sudo apt-get install ros-indigo-rosjava
Which works perfectly fine on my build machine. I figured that if I can just point to a .deb and use the Poky metadata class package_deb, it would do all the heavy lifting for me, so I produced the following simple recipe adapted on this posting on the Yocto Project mailing list:
inherit package_deb
SRC_URI = "http://packages.ros.org/ros/ubuntu/pool/main/r/ros-indigo-rosjava/ros-indigo-rosjava_0.2.1-0trusty-20160207-031808-0800_amd64.deb"
SRC_URI[md5sum] = "2020ccc8b4a67dd918a9a2c426eece0b"
SRC_URI[sha256sum] = "ab9493fabe1285b0d21aab031348d0d733d116b0b2470bae90025709b303b649"
The relevant part of the errors I get during the above recipe's do_unpack are:
| no entry data.tar.gz in archive
|
| gzip: stdin: unexpected end of file
| tar: This does not look like a tar archive
| tar: Exiting with failure status due to previous errors
| DEBUG: Python function base_do_unpack finished
| DEBUG: Python function do_unpack finished
The following command produces the output below:
$ ar t python-rosdistro_0.4.5-1_all.deb
debian-binary
control.tar.gz
data.tar.xz
You can see here that there's a data.tar.xz, not data.tar.gz. What can I do to remedy this error and install from this particular .deb?
I've included package_deb in my PACKAGE_CLASSES variable and package-management in my IMAGE_FEATURES. I've tried other methods of installation which have all failed; I thought this method in particular would be very useful to know how to implement.
Update - 3/22
I'm attempting to circumvent the problems with the method above by doing my installation through a ROOTFS_POSTPROCESS_COMMAND which I've adapted from forum posts like this
install_rosjava() {
${STAGING_BINDIR_NATIVE}/dpkg \
--root=${IMAGE_ROOTFS}/ \
--admindir=${IMAGE_ROOTFS}/var/lib/dpkg/ \
-L /var/cache/apt/archives/ros-indigo-rosjava_0.2.1-0trusty-20160207-031808-0800_amd64.deb
}
ROOTFS_POSTPROCESS_COMMAND += " install_rosjava() ; "
However, this fails due to dpkg not being a command found within the ${STAGING_BINDIR_NATIVE} path. The Yocto Project Reference Manual states that:
STAGING_BINDIR_NATIVE Specifies the path to the /usr/bin subdirectory of the sysroot directory for the build host.
Taking a look inside this directory yields a lot of commands but not dpkg (The recipe depends on the dpkg package, and this command can be found in my target rootfs after the build is finished; I've also tried pointing to ${IMAGE_ROOTFS}/usr/bin/dpkg which yields the same results). From what I understand of the BitBake process, this command may be in another sysroot, but I must admit that this is where my understanding breaks down.
Can I adjust this method so that it works, or will I need to start from scratch on an installation from source?
Perhaps there's a different method entirely which I could consider?
If you really want to install their deb directly then your rootfs postprocess is one solution. It doesn't work because depending on dpkg will build you a dpkg for the target but you want a dpkg that will run on the host. Add a dependency on dpkg-native to your image.
Though personally I'd either inherit bin_package and extract the deb they provide then re-package it as a standard package in OE, or ideally write a proper recipe to build rosjava and submit it to meta-ros (https://github.com/bmwcarit/meta-ros).
package_deb is where the packaging machinery for deb packages is stored, it's not something you'd inherit in a recipe but should be listed in PACKAGE_CLASSES.
When you put a .deb in a SRC_URI the fetcher will try to unpack it so you can access the contents: the assumption is that you're going to repack the contents as a native Yocto recipe.
If that's what you want to do then first you'll need to fix the unpack logic (in bitbake/lib/bb/fetch2/__init__.py) to handle .debs with xz-compressed data. This is a bug in bitbake and a bug report and/or patch would be appreciated.
The alternative would be to use their deb directly but I don't recommend that as it's likely the dependencies don't match. The best long-term solution would be to build it from source directly instead of attempting to use a package for another distro.
I am trying to establish a proper Drupal development environment by using Aegir-up (Vagrant-based Aegir virtual machine). I will illustrate how I follow the following "Quick start" steps and fail:
Install dependencies, including drush-vagrant and drush-hosts:
C:\Users\Domas>drush dl drush-vagrant drush-hosts
Install location C:\Users\Domas/.drush/drush-vagrant already exists. Do you want to overwr
ite it? (y/n): y
Project drush-vagrant (7.x-2.0-beta6) downloaded to [success]
C:\Users\Domas/.drush/drush-vagrant.
Project drush-vagrant contains 0 modules: .
Install location C:\Users\Domas/.drush/drush-hosts already exists. Do you want to overwrit
e it? (y/n): y
Project drush-hosts (7.x-1.1) downloaded to C:\Users\Domas/.drush/drush-hosts. [success]
Project drush-hosts contains 0 modules: .
I don't know if "contains 0 modules" is significant. I attempt installing aegir-up:
C:\Users\Domas>drush dl aegir-up
Install location C:\Users\Domas/.drush/aegir-up already exists. Do you want to overwrite i
t? (y/n): y
Project aegir-up (7.x-2.0-alpha1) downloaded to C:\Users\Domas/.drush/aegir-up. [success]
Project aegir-up contains 0 modules: .
Lastly, I run vagrant-build to get a vagrant project going (I presume), this is where it fails:
C:\Users\Domas>drush vagrant-build --blueprint=aegir
The name of your project may be used in URLs, and so should only contain lower-case letter
s and numbers.
It may also contain hyphens (-) and dots (.), so long as they do not come at the beginning
or end of the name.
What would you like to call your project?: test
Would you like to generate entries in /etc/hosts for the VMs in your project? (y/n): y
You are about to:
* Create a new project called "test" at "C:\Users\Domas/vagrant/projects/test".
* Add entries for the FQDNs of the VMs to /etc/hosts. (You will be prompted for your sud
o password.)
* Generate Drush aliases for the project and VMs.
* Launch the project VMs immediately.
* Build the project using the "aegir" blueprint from the "aegirup" extension.
Do you want to proceed with initializing the project? (y/n): y
Copied the "aegir" blueprint directory to C:\Users\Domas/vagrant/projects/test. [ok]
'egrep' is not recognized as an internal or external command,
operable program or batch file.
symlink(): Cannot create symlink, error code(1314) vagrant.blueprints.inc:90 [warning]
Errors occurred when running "symlink()" in [error]
"vagrant_default_build_project_setup".
Drush command terminated abnormally due to an unrecoverable error. [error]
At first I thought, that simply Egrep was missing, I downloaded UnxUtils, added it to PATH and checked that Egrep runs from the command prompt, which it did. However, after redoing the aegir-up setup steps I still got the same errors.
I am not particularly familiar with any of these tools. I have VirtualBox, Vagrant, Drush and NFS server, Ruby, gem installed. Running on Win8. I have been searching for an answer the whole day. Could someone please shed some light on this?
Apparently, I needed to run these commands through an elevated shell (as in, right click on Command Prompt -> Run as Administrator). Cannot create symlink, error code(1314) was what I should have concentrated on. The commands ran. Other problems came up, namely – Windows path wasn't getting escaped properly; however, that is off question.
Edit: At the moment of posting this problem Aegir-up was not supported on Windows, simple enough. That's why I was having a multitude of problems trying to run it on them.
when running
phpunit
I get error
Warning: require(PHPUnit/Autoload.php): failed to open stream: No such file or directory in /usr/local/bin/phpunit on line 42
Fatal error: require(): Failed opening required 'PHPUnit/Autoload.php' (include_path='.:') in /usr/local/bin/phpunit on line 42
/usr/local/bin/phpunit displays the following on line 42:
require 'PHPUnit/Autoload.php';
any suggestions how to fix this?
Update (1):
I was missing php.ini in /etc/, so I symlinked it to read the MAMP php.ini. Now I get
php -r 'foreach (explode(":", get_include_path()) as $path) echo $path . PHP_EOL;'
.
/Applications/MAMP/bin/php/php5.3.6/lib/php
/usr/local/bin/pear
/usr/local/share/pear/PHPUnit
running
phpunit
is running but provides no output.
Any suggestions what to check next?
Update (2):
probably the root cause of this issue is related to question
MAMP PEAR configuration is pointing to local directories.
I hit a similar issue on MAC OSX Lion. I installed phpunit with the PEAR package manager, and when I try to run it I got the error as described by udo. I was able to resolve it with the following simple steps:
Get the latest php archive of pear curl http://pear.php.net/go-pear.phar > go-pear.php
Install the archive with sudo php -q go-pear.php
During installation, it detects if the include_path in your php.ini does not contain the PEAR PHP directory. You can choose to let it fix it for you automatically when given the option.
I ran into this problem when I was running phpunit.phar from my local directory, but also has PHPUnit installed as a composer dependency. Removing the PHPUnit composer dependency fixed my problem.
You must have the folder that contains the PHPUnit source files on your PHP include path. Also, PHPUnit/Autoload.php was added in 3.6, and it's possible you have an older 3.5.x source folder instead. Check the folders listed using
php -r 'foreach (explode(':', get_include_path()) as $path) echo $path . PHP_EOL;'
(or on Windows)
php -r"foreach (explode(':', get_include_path()) as $path) echo $path . PHP_EOL;"
and make sure one of them contains a PHPUnit folder with Autoload.php.
Update: Regarding your update, you probably want to remove /usr/local/share/pear/PHPUnit from the include path because you're including PHPUnit/Autoload.php which should be located in /usr/local/share/pear which is already in the include path.
To make sure PHPUnit is working first run phpunit --version so you can see the installed version. PHPUnit instantiates all of the test cases it plans to run before outputting anything. If any of your test cases cause a fatal error while loading, sometimes no output is shown at all. This is very frustrating. Start by creating the simplest test case possible that doesn't use any of your code.
class MyTest extends PHPUnit_Framework_TestCase {
function testThatItWorks() {
self::assertTrue(true);
}
}
Running this test should produce a single passing test. Try it and paste what you see in your question.
To add to the previous answers: double-check with php.ini file is being loaded and make sure you edit THAT file with additional paths. I used the following to check the loaded php.ini
php -r 'phpinfo();'
Which told me that the loaded php.ini file was /private/etc/php.ini
Then I used "which" to tell me where phpunit had been installed:
which phpunit
Then I added that path to the php.ini file, so it ended up looking like this:
;***** Added by go-pear
include_path=".:/Users/admin/pear/share/pear:/php/includes:/usr/bin:/usr/lib/php/"
Only after I had done all that did the "phpunit --version" and other commands work as expected.
It should be noted that most users who face the problem faced here must be running the command
$ phpunit
from the command prompt. when they get the above error. What Most of us fail to understand about the real issue is that the PHP used on the command prompt will mostly be very different from the one running things for you in your webserver. Personally i use lampp and even though i had correctly installed phpunit using pear successfully,i failed to realised this essential part for hours.
Remedy
- for anytime you need to run a PHP script that requires resources in the include_path, make sure that php.ini for the respective PHP binary your using is adequately furnished. case and point in my ubuntu 12.04 installation with xampp my two php binaries include
the command line one i.e php5-cli found in /etc/php5/cli/ directory
the xampp one i.e php that is used by apache to serve my pages found in /opt/lampp/etc/php.ini
Both the php.ini files must have your desirable and correct include_path declaration for you to correctly bootstrap any command line scripts and serverside(apache served scripts).
Back to our matter at hand after correctly configuring the php.ini remember to
Restart Apache so that the web server pick your changes
Restart you terminal/commandline session so that the cli prompt picks your changes
Common Mistakes that get you problems when Changing Files in Linux/*nix Systems
remember to run chwon to own the php.ini file or else you wont even manage to edit them
remember to run chmod and change the values to allow you to save your changes after which you can return everything (access control on file i.e chwon and chmod to the previous state) to the way they were and it should be ok after restarting the terminal and apache.
Good Luck
The remark of Howard Lo on Mac OSX is very useful with the remark of Sebastian Perez. Because the remark is not that nice formatted, it maybe overlooked. After the Mavericks update of OSX I ran for the second time to this issue, U decided to create this full Apple OSX solution for this problem. I have to say I have also installed MAMP-PRO with several different version of php, so I need to be very accurate.
Check if you have an php.ini installed into /private/etc. If not issue the command:
$ sudo cp /private/etc/php.ini.default /private/etc/php.ini
Get the latest php archive of pear
$ curl http://pear.php.net/go-pear.phar > go-pear.php
Install the archive with
$ sudo php -q go-pear.php
During installation, it detects if the include_path in your php.ini does not contain the PEAR PHP directory. You can choose to let it fix it for you automatically when given the option.
After these steps I had to install phpunit again using the following commands:
$ sudo pear channel-discover pear.phpunit.de
$ sudo pear channel-discover components.ez.no
$ sudo pear channel-discover pear.symfony-project.com
$ sudo pear install phpunit/PHPUnit
Many thanks to Howard Lo and Sebastian Perez.