I want to revert what is done via the command blackfire php:install. Does disabling the module then removing the php/x.x/cli/conf.d/99-blackfire.ini is enough ?
Related
Is there a way to suppress this annoying warning that appears each time I run the bash after sourcing ros2 in ~/.bashrc without using Connext?
[connext_cmake_module] Warning:
The location at which Connext was found when the workspace was built
[[/opt/rti.com/rti_connext_dds-5.3.1]]
does not point to a valid directory, and the NDDSHOME environment variable has not been set.
Support for Connext will not be available.
All this warning is saying is that Connext has been built with support for for another RMW implementation that isn't the default. If you're not actively trying to use connext_dds you can safely ignore the error. If you want to actually use this, or a non-default, RMW it is done by setting the environmental variable $RMW_IMPLEMENTATION and can be changed by doing one of the following:
export RMW_IMPLEMENTATION=rmw_fastrtps_cpp
export RMW_IMPLEMENTATION=rmw_opensplice_cpp
export RMW_IMPLEMENTATION=rmw_connext_cpp
The default for the newest distro(foxy) is Fast-RTPS.
If you don't use Connext DDS anymore you can just run
sudo apt purge ros-foxy-rmw-connext-cpp
sudo apt purge ros-foxy-connext-cmake-module
I'm attempting to learn how to create a Laravel Docker image by following a tutorial on DigitalOcean using WSL. Following the instructions on the Docker Hub page, however, yields an error:
❯ docker run --rm --interactive --tty -v $(pwd):/app composer install
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 94 installs, 0 updates, 0 removals
- Installing voku/portable-ascii (1.4.10): Failed to download voku/portable-ascii from dist: Could not delete /app/vendor/voku/portable-ascii/src/voku/helper:
Now trying to download from source
- Installing voku/portable-ascii (1.4.10):
[RuntimeException]
Could not delete /app/vendor/voku/portable-ascii/src/voku/helper:
install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--] [<packages>]...
How can I diagnose what I'm doing wrong?
It turns out that the underlying problem had nothing to do with Docker at all. In fact, Composer was trying to tell me what the problem was all along, but I dismissed it as just a symptom of a deeper issue:
[RuntimeException]
Could not delete /app/vendor/voku/portable-ascii/src/voku/helper:
This message was the crux of it all. I noticed that the directory mentioned, [...]/helper, was empty, so I tried to remove it by hand with rmdir. Instead, I got a No such file or directory error message. I attempted many other was to kill this directory, the entire project directory with rm -rf ~/laravel-app from the home folder, etc. Nothing worked.
Some digging around on the internet suggested that it could be an NTFS corruption if I was running into this issue on Windows. Since I am, indeed, attempting this on WSL (Windows Subsystem for Linux), I gave their suggested fix a try: running chkdsk /F in CMD/PowerShell. A reboot was necessary to complete this task, but after getting everything back up and trying those first few tutorial steps again, I was able to get composer to install the Laravel dependencies without a hitch.
Bottom line: If you run into this sort of issue on WSL, please try running chkdsk /F and reboot. You might just have a similar file system corruption.
We have two possibilities for this error:
1 - You did not execute the command inside the directory :
cd ~/laravel-app
2 - I'm sure there is an internal proxy that is blocking the download of packages.
I am using mosquitto as one of my project tool. After i successfully compile (make binary) mosquitto via source code and try to run mosquitto_sub/pub, its shows that
./mosquitto_sub: /usr/lib/i386-linux-gnu/libmosquitto.so.1: version `MOSQ_1.5' not found (required by ./mosquitto_sub)
while Mosquitto and Mosquitto_psswd is able is run without any problem. Besides, my mosquitto version is 1.5.
I have no idea about this problem.
Any Help appreciated .
It sounds like you have an earlier version of mosquitto installed and it's libraries are on the system path.
Make sure you have uninstalled any earlier versions of mosquitto installed on the machine.
Also make sure you have run make install as root in your build directory to copy the libraries to the correct locations
I had a similar issue building on rpi model B+ using GNU make 4.2.1 and cc (Raspbian 8.3.0-6+rpi1) 8.3.0
Error reported: ./mosquitto_sub: /usr/lib/i386-linux-gnu/libmosquitto.so.1: version `MOSQ_1.6' not found (required by ./mosquitto_sub)
Note: I left the existing distribution in place so that I could leverage off the systemd mosquitto.service that gets installed with the debian packages mosquitto and mosquitto-clients.
Resolution:
mkdir proj
git clone https://github.com/eclipse/mosquitto.conf
cd mosquitto
# my build failed on master branch, so I picked a tag that worked for me
git checkout -b 1.6.9 tags/1.6.9
make WITH_WEBSOCKETS=yes WITH_DOCS=yes WITH_SRV=yes
# overwrite the existing binaries
sudo make install
sudo ldconfig
# verify that the newly installed binaries have overwritten the originals.
mosquitto --help|grep -w 'mosquitto version'
mosquitto_pub --help|grep -w 'mosquitto_pub version'
mosquitto_sub --help|grep -w 'mosquitto_sub version'
I have a server written in Erlang, compiled with Rebar, and I make a release with Relx. Starts nicely with
/root/rel/share3/bin/share3 start
The next step is to start when the server boots.
I have tried different approaches, the last one is using the /etc/init.d/skeleton where I changed the following
NAME=share3
DAEMON=/root/rel/share3/bin/share3
DAEMON_ARGS="$1"
After that, I run update-rc.d, but I have not gotten it too work. (Ubuntu 14.04)
The service runs until the machine reboots, and I need to login and start it again.
For Windows, it is really elegant, since it can create the Windows service.
Ubuntu uses upstart as init system, so you could try something like that:
description "Start my awesome service"
start on runlevel [2345]
stop on runlevel [!2345]
respawn
exec /root/rel/share3/bin/share3
You have to place this script in /etc/init/ directory with '.conf' extension like '/etc/init/share3.coinf'. To start it invoke sudo start share3.
At last, I solved it!
I have told to relx to place the result at /home/mattias/rel. The script from relx is /home/mattias/rel/share3/bin/share3
Replace the row
SCRIPT_DIR="$(dirname "$0")"
by (you need to fix the path /home/mattias/rel)
HOME=/home/mattias
export HOME
SCRIPT_DIR="/home/mattias/rel/share3/bin"
Copy the file to /etc/init.d/share3 using
sudo cp ~/rel/share3/bin/share3 /etc/init.d/
Test that it works using
/etc/init.d/share3 start
and
/etc/init.d/share3 stop
In order to make it start at boot, install sysv-rc-conf
sudo apt-get install sysv-rc-conf
Enable boot at start using
sudo sysv-rc-conf share3 on
and disable
sudo sysv-rc-conf share3 off
Alternatives are welcome.
I am trying to contribute more with couchdb code, but I have really no idea how it is done the right way.
I have cloned the source from apache git repository and built it with
./configure
make && sudo make install
Then I wanted to change a file from the source called couch_httpd_show.erl
Do I need to run make && sudo make install again for every change I make to the source code and want to see how it behaves?
I am sure there's a more practical way to do it, because this approach is a bit time and patience consuming right?
Yes, there is a shortcut.
./configure
make dev
./utils/run
This builds and runs CouchDB entirely in the current directory. Instead of running as a background daemon, CouchDB will run in the foreground and output log messages to the terminal. It uses some local directories to store stuff: ./tmp/log for logs, ./tmp/lib for databases, and (if I remember correctly) ./etc/couch/local_dev.ini for configuration.
If you run this instead:
./utils/run -i
then you will also have an interactive Erlang prompt, which you can use to help debug.
When I work on CouchDB, I run this in the shell:
make dev && ./utils/run -i
After I change some code, I press ^C, up-arrow, return.
When I joined Couchio, I was responsible for production CouchDB deployments. I asked Chris Anderson for advice about something and he said, "Sorry, ask Jan. I've been just using utils/run for years!"
You can rebuild that one file and drop the output beam in place and restart.
erlc <file.erl>
& then copy the .beam file into place. To restart couchdb use either init:restart(). in the erlang shell or POST /_restart to CouchDB.
Although you might want to consider using the commandline erlang & javascript test suite also to ensure you didn't break anything.