I am getting an error while installing the features.
error executing command: error restarting bundles
Initially, it worked fine for some of the features but then it suddenly started throwing this error.
Any suggestion on this would be appreciated.
if you clean karaf, you can resolve the issue, by running the following command, you can clean the karaf.
./karaf clean
When OpenDaylight moved to karaf 4 there were problems identified with
installing features in the karaf shell one after the other. I think
you are hitting that problem.
you can try listing out all the features you want in the featuresBoot
variable of the etc/org.apache.karaf.features.cfg file.
You may also have some success trying to install on the karaf shell with
the following flag --no-auto-refresh, like this:
feature:install --no-auto-refresh odl-l2switch-switch
Also, as sridhar reddy noted, if you use "karaf clean" to start karaf it will
wipe the data/ folder (and more) so that old loaded features will not come
back in on startup and you will start "clean".
I am trying to install Bugzilla on centos. Everything in the terminal went fine. But when I try to access Bugzilla through my browser, it is returning the error as shown below.
This XML file does not appear to have any style information associated with it.
The document tree is shown below.
<D:error><C:error/><m:human-readable errcode="2">
Could not open the requested SVN filesystem
</m:human-readable></D:error>"
Can any one help me to solve this issue?
Thanks in advance
The above error rises when there is port conflict between SVN and other applications.
We need to configure virtual host inorde3r to avoid port conflict between svn and other applications.
I have: gstreamer-sdk, gstreamer-ffmpeg, gstreamer-plugins-good, bad, and ugly. I googled everywhere for this error and have found nothing relevant. I'm going a little nuts trying to figure out this error:
Error received from element decodebin20: Your GStreamer installation is missing a plug-in.
Debugging information: gstdecodebin2.c(3576): gst_decode_bin_expose (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20:
no suitable plugins found
It throws when I run my gstreamer program. Any ideas on why?
You may not be missing any plugins at all.
This error can be a result of just an unlinked pipeline.
Playbin2(decodebin2) got some changes that made it unable to automatically link up some pipelines that formally worked, for example transcoding a decoder to an encoder. In my case, explicitly adding the ffdec_h264 that it used to add automatically fixed it.
Relying on the Playbin2 can be very frustrating when it does not work. Using the setup below, you can create a .png diagram of the pipeline in various phases of construction. It's very helpful in finding why it isn't linking up.
export GST_DEBUG_DUMP_DOT_DIR=~/gstdump
for f in $GST_DEBUG_DUMP_DOT_DIR/*.dot ; do dot -T png $f >$f.png; done
This tool also lets you learn from it how to link up pipelines, and replace them with explicit ones that are easier to debug and less likely to break.
In Fedora, I resolved this issue removing gstreamer1-vaapi.x86_64:
sudo yum remove gstreamer1-vaapi.x86_64
uridecodebin is part of the "base" plugin set, so make sure you have gstreamer-plugins-base.
Another thing to look into is your LD_LIBRARY_PATH and GST_PLUGIN_PATH. If they point to a different GStreamer installation, it could cause problems like this. Also, if you didn't install GStreamer with a package manager, you may need to set your LD_LIBRARY_PATH to point to it (or better yet, install it with a package manager).
Pleas try to use gst-inspect command to find out if environment is correctly setup.
use gst-launch -v playbin2 uri = "your_uri_here" to find more information to trace this issue.
I've been beating my head against this for hours.
I've come back to do some work in PHPStorm after not having used it in a couple of weeks, and for some reason the debug doesn't work any more. It used to work, but now it doesn't and I have no idea what is going on.
I'm running on Windows, using IIS, PHP version 5.3.8. The XDebug is installed, and I've set the configuration in PHP.ini as per the usual instructions.
When I run phpinfo() everything looks normal (ie. XDebug is there).
I've rechecked various settings, downloaded a slightly newer version of XDebug than I was using (Xdebug v2.2.1), but nothing seems to kick it into life.
Can someone please give me some clues as to what I can look at next?
UPDATE:
I've spent a few more hours beating my head against this, and don't seem to have gotten much further. XDebug is installed and loaded, according to phpinfo(). I turned on logging, but it doesn't really tell me much except that XDebug is indeed connecting...
Log opened at 2013-02-17 04:13:07
I: Connecting to configured address/port: localhost:9000.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" fileuri="file:///C:/web/dbg/index.php" language="PHP" protocol_version="1.0" appid="6912" idekey="PHPSTORM"><engine version="2.2.1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2012 by Derick Rethans]]></copyright></init>
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" status="stopping" reason="ok"></response>
Log closed at 2013-02-17 04:13:07
So it seems that the problem is on the PHPStorm side, but I cannot see where. I tried creating a very simple project, but could not get that to debug either.
Don't you hate it when you spend hours wrestling with something, then in desperation try something simple, and it works?
I decided to try a different port, 9001 instead of the default 9000, and it WORKED!
I now realise that I recently installed Twonky (for video streaming to my TV), and when I checked the settings, there it was... port 9000.
Had the same issue this afternoon - found this question along with several other SO questions so I thought I'd post the solution that fixed it for me.
I was missing a mapping to the file system. Which is odd because I've seen PHPStorm prompt me when they've been missing previously.
Hopefully this helps someone in the future :)
Had the same problem after updating to El Capitan. First hint to that I used is Run -> Web Server Debug Validation.
This tool from PHPStorm gave me a hint about xdebug.remote_host I'm using v-hosts and it was complaining localhost being not the correct value there. So I updated xdebug setting with xdebug.remote_connect_back=On and it worked!
Apparently if you try to debug on newer versions of xdebug you have to include this line to your xdebug-php.ini settings
xdebug.mode=debug
I had same problem and I resolved it by deleting all the watches, and then reboot phpStorm
I resolved by by myself also, cause PHP-Storm and PHP-FPM are listening same port... just kill all php-fpm port.
Had the same problem. For me I was using port 9010 for xdebug. Problem turned out to be Logitech's GHub software I recently installed for a new mouse listens on port 9010! You can use this to see what is listening on a given port on Macs:
lsof -nP -iTCP:9010 | grep LISTEN
Newer versions of PHPStorm have Debugger validation. The official PHPStorm Blog has a writeup on this feature which might help you figure it out.
One snafu for me when I set up a box with php-fpm configured is that php-fpm runs on port 9000 by default also, so I had to change the configured port in php.ini and PHPStorm's preferences to something like 9001.
For what it's worth, my current php.ini setup for xdebug:
[xdebug]
zend_extension="/the/path/to/xdebug.so"
xdebug.file_link_format="txmt://open?url=file://%f&line=%l"
xdebug.remote_enable=1
xdebug.remote_autostart=On
xdebug.remote_port=9001
xdebug.profiler_enable_trigger=1
xdebug.max_nesting_level=250
I had the same problem! I finally realized that all my configurations were correct, but on the browser side, I hadn't enabled debugging with the Chrome Browser. Each browser has their own way of enabling the debugging to start working.
I had the same issue and I tried all the solutions I could find in SO and in other sites (checked that both phpStorm and Xdebug are on the same ports, checked that I had the server mapping on the file system, reinstalled Xdebug, etc.) but eventually the problem was in the fact that we run the site on an internal server, and someone from IT changed my computer's IP address to an address which is filtered out of the allowed addresses that can be connected to that server. That's why phpStorm started to ignore the breakpoints from Xdebug.
Hopefully, this will help someone in the future and save him many hours.
Found that if xdebug log file is not writable then it could be not working. Always better to set xdebug.remote_log and make it writable.
I have been trying to install Ushahidi platform for weeks but without any luck. I recently started over using Ushahidi latest release ushahidi-Ushahidi_Web-2.0.1-140-g0991172.zip and extracted it to folder ushahidi under my root.
I am using godaddy Linux server. I have tried both the manual and wizard to setup Ushahidi. In all cases, after installation, I get the same error when I try to access admin page. The error reads:
No input file specified.
I have tried tried installing using the wizard and the manual process. My PHP version is as required.
Any help will be appreciated. I need it to work so I can move on and customize it. Very disappointing such a good open source tool has poor installation guides!
Thanks.
Sting
there are a few things that can trip up following the installation.
Make sure that:
mod_rewrite is turned on in apache "a2enmod rewrite"
AllowOverride All is set in your apache config for your site (/etc/apache2/sites-available/default)
your .htaccess file points to the correct webroot