i have a directory with some .php files in it...do i need to install symfony in that directory so that i can run symfony commands from that directory?? i tried: pear channel-discover pear.symfony-project.com
and got:
Channel "pear.symfony-project.com" is already initialized
the i tried: pear install symfony/symfony
and got:
WARNING: configuration download directory "/build/buildd/php5-5.3.2/pear-build-download" is not writeable. Change download_dir config variable to a writeable dir to avoid this warning
Cannot install, php_dir for channel "pear.symfony-project.com" is not writeable by the current user
how do i fix this please? must i run it as sudo??
thanks
If I remember well, Symfony is "system-wide" if installed through PEAR (like you are trying to do).
Now it is recommended by the manual to do a "standalone" install through SVN. See http://www.symfony-project.org/gentle-introduction/1_4/en/03-Running-Symfony
As well, the sandbox will bring a "standalone" installation of Symfony (you will have to be in the project root directory to be able to run the symfony commands)
EDIT
Example of quick install using SVN:
mkdir /path/to/symfony
cd /path/to/symfony
svn checkout http://svn.symfony-project.com/tags/RELEASE_1_4_0 .
but it should be better to follow the manual and configure the external SVN sources.
I run servers where I have applications that use different versions of symfony simultaneously. I found it much easier to deal with the SVN checkout than the PEAR insteall.
So what I've done is do an SVN checkout of each revision that I need
into it's own folder. In my case i check them out to
/usr/share/symfony/(version)
Then I configure the ProjectConfiguration.class.php to reference whatever version is needed, using the line:
require_once '/usr/share/symfony/1.x.x/lib/autoload/sfCoreAutoload.class.php';
If I need to switch to a different symfony version, I can just change that config.
That is, assuming all my code is compatible with that version
Related
I'm trying to deploy an asp.net core 3.1 API on cloud foundry. I don't have admin rights, i just have developer rights. Is there a way to specify the URL of these libraries (libc6-dev, libgdiplus and libx11-dev) (maybe git or some official repository) so that i can execute the manifest.yml file during deployment and install these dependencies? Also to mention, i cannot turn on support for docker file on cloud foundry, as i get a message (insufficient rights)
I would suggest you give the apt-buildpack a try. You can give it additional Ubuntu package names, and it will install those for you.
You do that through an apt.yml file. Check out this post for instructions.
It's important to understand that the apt-buildpack will install these packages into a non-standard location. Since it also runs as a non-root user, it cannot install them into standard locations.
To work around this limitation, it sets variables like $PATH and $LD_LIBRARY_PATH to point to the locations where it has installed items. Most build tools will pick up these env variables and be able to locate what you install.
It's not perfect though, and some tools require additional env variables to be set. If you still get errors when building, look at your build tools and check if there are ways you can point to where apt-buildpack is installing stuff. The path it writes to can vary based on your buildpack order, but if you print out $PATH you can see the location. It's often /home/vcap/deps/0/... but the index can change based on your buildpack order.
I have cloned and built the waf script using:
./waf-light configure
Then to build my project (provided by Gomspace) I need to add waf and the eclipse.py to my path. So far I haven't found better than this setenv script:
WAFROOT=~/git/waf/
export PYTHONPATH=$WAFROOT/waflib/extras/:$PYTHONPATH
export PATH=~/git/waf/:$PATH
Called with:
source setenv
This is somehow a pretty ugly solution. Is there a more elegant way to install waf?
You don't install waf. The command you found correctly builds waf: /waf-light configure build Then for each project you create, you put the built waf script into that projects root directory. I can't find a reference, but this is the way in which waf:s primary author Thomas Nagy wants the tool to be used. Projects that repackage waf to make the tool installable aren't "officially sanctioned."
There are advantages and disadvantages with non-installation:
Disadvantages:
You have to add the semi-binary 100kb large waf file to your repository.
Because the file contains binary code, people can have legal objections to distributing it.
Advantages:
It doesn't matter if new versions of waf break the old API.
Users don't need to install waf before compiling the project -- having Python on the system is enough.
Fedora (at least Fedora 22) has a yum package for waf, so you could see that it's possible to do a system install of waf, albeit with a hack.
After you run something like python3 ./waf-light configure build, you'll get a file called waf that's actually a Python script with some binary data at the end. If you put it into /usr/bin and run it as non-root, you'll get an error because it fails to create a directory in /usr/bin. If you run it as root, you'll get the new directory and /usr/bin/waf runs normally.
Here's the trick that I learned from examining the find_lib() function in the waf Python script.
Copy the waf to /usr/bin/waf
As root, run /usr/bin/waf. Notice that it creates a directory. You'll see something like /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18
mv that directory to /usr/lib, dropping the . in the directory name, e.g. mv /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18 /usr/lib/waf-2.0.19-b2f63c807a4215294bf6005410c74c18
If you want to use waf with Python3, repeat Steps 2-3 running the Python script /usr/bin/waf under Python3. Under Python3, the directory names will start with .waf3-/waf3- instead instead of .waf-/waf-.
(Optional) Remove the binary data at the end of /usr/bin/waf.
Now, non-root should be able to just use /usr/bin/waf.
That said, here's something to consider, like what another answer said: I believe waf's author intended waf to be embedded in projects so that each project can use its own version of waf without fear that a project will fail to build when there are newer versions of waf. Thus, the one-global-version use case seems to be not officially supported.
GitLab was installed by following instructions at https://about.gitlab.com/downloads/ on Ubuntu Server 14.04 but I can't find the install directory. It's commonly said to be in /home/git/ or /home/gitlab/ but neither exist.
I need to find the install directory so I can setup SMTP (RE https://gist.github.com/petermanser/6117494) and migrate existing repositories into GitLab.
Does anyone know where GitLab would be installed on Ubuntu Server 14.04 if not /home/git/ or /home/gitlab/?
Config files are in etc/gitlab
Data is stored in /var/opt/gitlab
Thanks to Bjorn for finding the locations and Pavel S for providing cat /etc/passwd | grep git for finding the home directory of a given user!
To find a user's home directory do
$ cd ~git
you will be in that users directory.
:D
There is a Directory structure section in the official README.md file of Omnibus-GitLab repo:
Omnibus-gitlab uses four different directories.
/opt/gitlab holds application code for GitLab and its dependencies.
/var/opt/gitlab holds application data and configuration files that
gitlab-ctl reconfigure writes to.
/var/log/gitlab contains all log data generated by components of
omnibus-gitlab.
/etc/gitlab holds configuration files for omnibus-gitlab. These are
the only files that you should ever have to edit manually.
But, if you install the GitLab alone from source (rarely, but useful for unsupported systems like *BSD). Then the GitLab installation location will be different, and it is described in this official doc.
I was reading a blog post about installing git, and it says it will be installed in /usr/bin/git
When I check my version using $ which git, terminal shows /usr/local/bin/git. Same result when I checked for Ruby. Does it make different where Git, Ruby or Rails are installed? Can I change that if it's possible?
Normally, it should not matter. But, usually, /usr/local/bin is ahead of /usr/bin in the PATH environment variable. So, in future, if another version of the same software, lets say git, is installed into /usr/local/bin, that will take precedence over the one installed in /usr/bin. You can of course manipulate your PATH environment variable to suite your needs.
run this command to see if multiple versions of git have been installed
which -a git
It does not matter as long as all of them are accessible in your PATH for commands.
Is your concern about where the actual repositories will be located - the place where GIT repositories are located is not necessarily the same place where GIT itself is installed.
You probably could change it. It might not be worth it.
It will probably be easier just to leave it and remember.
This is sorta like windows install path. Default will be "Program Files" but it often can be changed.
Note that different versions of Windows have differently named program files. This can be an example of such differences also.
Finally it could be that your ruby installed GIT, and that is the path that Ruby chose.
As long as /usr/local/bin/git is in your PATH you should not notice any differences.
I have just installed TPTP's latest version (4.6.1) and am using Eclipse build 20090621-0832 on Windows 7 (User Control enabled).
I'm trying to profile an application but am getting the following error under the Monitor tab:
IWAT0435E An error occurred when connecting to the host.
Anyone know how to resolve this?
For Windows, this may be related to a missing reference to the Integrated Agent Controller (IAC)
The Integrated Agent Controller (IAC) is a new feature in TPTP workbench which allows users to profile a Java application locally and to run a TPTP Test locally without needing the standalone Agent Controller on the local machine.
Profiling on a remote machine or running a TPTP test on a remote machine would still need the Agent Controller on that remote machine.
The biggest benefit of the Integrated Agent Controller is that it simplifies the usage of TPTP functionality in the local scenario by removing the dependency on the local standalone Agent Controller. There is no need to install and configure the local standalone Agent Controller when using the Profiling and Logging perspective and Test perspective locally.
However, that local agent might not be referenced correctly in one of the TPTP config files, either because:
it is already referenced in the workspace (incorrectly)
See workspace\.metadata\.plugins\org.eclipse.tptp.platform.iac.administrator\config\ serviceconfig.xml
or because the IAC service is not started automatically:
Check the connection with the localhost (via Window->preferences->Agent Controller->hosts->Test connection).
See this thread (and its follow up) for a working setup.
This thread might also be relevant.
For those On Linux:
It may be related to gcc version or libstdc++xx-glibcy.y version, as mentioned in bug 244213 or bug 240677
This blog post relates what kind of workaround is possible in his case. May be it could help here.
Extract:
A workaround for this is described in this blog post.
It's pretty straight forward: get a deb file libstdc++2.10-glibc2.2_2.95.4-27_i386.deb and install it with sudo dpkg ....
(update Dec. 2010: gcc before 3.x is no longer available.
You can try with, for instance, (gcc-3.3) libstdc++5_3.3.6-20_i386.deb, replacing all reference to a .deb by this one:
sudo dpkg --install libstdc++5_3.3.6-20_i386.deb
Or if you are running on 64 bits:
sudo dpkg --force-architecture --install libstdc++5_3.3.6-20_i386.deb
Not tested though.)
The problem is now that the workaround involves root actions.
First, one hasn't always the required root permissions to do so.
More importantly however, I don't like installing external debs and other stuff as root because it can interfere with the packaging system, pollute system directories and break things in ugly, or worse, unrecoverable ways.
I always install third party stuff (with which I mean things that are not available through the standard packaging system) in my home directory under ~/usr.
For example, I build autotools-managed software with the option --prefix=~/usr, so things end up in ~/usr/bin, ~/usr/lib, ~/usr/share, etcetera.
I managed to install the deb file described above also in ~/usr as follows.
First, I extracted the deb file to a temporary directory to get an idea of its contents:
dpkg -x libstdc++2.10-glibc2.2_2.95.4-27_i386.deb tmp/
This resulted in the following file tree:
tmp/
`-- usr
|-- lib
| |-- libstdc++-3-libc6.2-2-2.10.0.so
| `-- libstdc++-libc6.2-2.so.3 -> libstdc++-3-libc6.2-2-2.10.0.so
`-- share
`-- doc
`-- libstdc++2.10-glibc2.2
|-- README.Bugs.gz
|-- README.Debian
|-- changelog.Debian.gz
`-- copyright
So I just had to move the shared libraries libstdc++*.so to ~/usr/lib, or alternatively, extract the deb file directly int my home directory:
dpkg -x libstdc++2.10-glibc2.2_2.95.4-27_i386.deb ~/
One important missing piece of the puzzle is to make sure these shared libraries can be found at run time (or compile time in case you want to compile against them).
The trick is to set the LD_LIBRARY_PATH and LD_RUN_PATH environment variables, typically in your ~/.bashrc or ~/.profile startup scripts:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/usr/lib
export LD_LIBRARY_PATH
LD_RUN_PATH=$LD_RUN_PATH:~/usr/lib
export LD_RUN_PATH
And Eclipse TPTP profiling lived happily ever after. I hope.
I found that IAC was disabled by default.
Try Windows/Preferences/Agent Controller/Integrated Agent Controller/Activate the Integrated Agent Controller on demand - enabled