Every few days all of my dependencies stop working, and I need to run
export PATH="$HOME/.node_modules_global/bin:$PATH"
in order to restore all of my commands. I'm pretty new to using npm, is this normal? If not, is there a way I can make it so this doesn't happen?
Thanks in advance
Related
I am working on a team task. When instructed by a piece of documentation to run grunt fix scss I did so, and I received the following message:
jit-grunt: Plugin for the "fix" task not found. If you have installed
the plugin already, please setting the static mapping. See
https://github.com/shootaroo/jit-grunt#static-mappings
Warning: Task "fix" failed. Use --force to continue.
The problem is that I have no idea whether the plugin they mention is installed. What command would I need to run in order to install this plugin?
The problem was that I was running grunt fix scss rather than grunt fix-scss (with a hyphen).
Once I did the latter, I got more meaningful output.
I made a mistake and removed the init script beanstalkd from /etc/init.d. Does somebody know how it can be recreated ?
When I type
sudo apt-get autoremove beanstalkd
and then re-install it. The script is still not there.
I hope someone can help.
Best regards,
If you wanted to create it automatically, you'll probably have to entirely remove and purge the package from the system.
A lot easier is to find a copy of the package and then manually copy it back into place, running the appropriate scripts to recreate any links to it to ensure it's autostarted on boot.
I followed the instructions in GStreamer Plugin Writer's Guide (1.7.1.1):
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html
in order to build a new gstreamer plugin. Basically I ran make_element and then edited Makefile.am as described. Amazingly make and make install worked and I ended up with:
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.la
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.so
As I understand it, gst-inspect should find this plugin automatically. The guide says that /usr/local/lib/gstreamer-1.0 needs to be added to GST_PLUGIN_PATH in order for plugins in this directory to be found. Another document states that this directory is searched automatically. I tried with and without the environment variable, but no luck.
Now I should say that I have just started to use gstreamer and I am suffering from total information overload. I have read so many documents, yet I don't even know whether I am building a gstreamer1.0 or a gstreamer0.10 plugin (I think the guide is for gstreamer1.0, since the guide's version is 1.7.1.1 but can't be sure).
Can anybody give me a clue here ?
There are many possible reasons that can cause this issue.
First, check if your plugin is blacklisted by command gst-inspect-1.0 -b.
If your plugin show up here, that means it is really blacklisted.
In that case, delete directory ~/.cache/ and then run gst-inpect-1.0 again.
This will force GStreamer to re-scan plugins list. If the reason of blacklist is not solved yet, gst-inpect will probably print out the reason here for you.
Another possible reason (but unlikely happens) is setting GST_REGISTRY_UPDATE as no, which will force GStreamer NOT to rescan the plugin directory, thus not found new plugin
P/s: The guide is for GStreamer 1.0
If you've tried removing your plugin from the blacklist and it still doesn't show up, try this:
export GST_PLUGIN_PATH=/usr/local/lib/gstreamer-1.0
/usr/local/lib/gstreamer-1.0 is the default directory used by make in case of plugins. If you have defined a different directory, use it.
Then run gst-inspect-1.0 and you'll find the newly compiled and installed plugin.
You'll be required to perform the export every time in the shell whether you either create a static pipeline with gst-launch-1.0 or run code of your own. I couldn't find any alternative to make it permanent other than making entry of this in .bashrc file. If you have one, please suggest via comments.
If you run ./configure --help in the gst-plugin directory you will see the following:
By default, make install' will install all the files in
/usr/local/bin', /usr/local/lib' etc. You can specify
an installation prefix other than/usr/local' using --prefix',
for instance--prefix=$HOME'.
If you do after the original installation:sudo updatedb && locate libgst[NAME_OF_YOUR_PLUGIN].so you should see where the library holding your plugin is located (in my case it is under /usr/local/lib/gstreamer-1.0/ as described by the configure help above).
Now on my machine, the GStreamer "official" plugins are installed under: /usr/lib/i386-linux-gnu/gstreamer-1.0/ . This is where the new created plugin library should be stored.
To store the plugin at the right place, run configure with the following parameter:
./configure --libdir=/usr/lib/i386-linux-gnu followed by make && sudo make install
It is important to override with --libdir and NOT --prefix! The usage of --prefix will stick a /lib that we don't want to have under /usr/lib/i386-linux-gnu.The plugin will not be found by gst-inspect-1.0 if /lib is added to the path.
Extra note :
Even if the plugin is at the proper location, you may still see GStreamer blacklisting it when you run gst-inspect-1.0. One of the cause of the blacklisting could be the shared library/ies required by your plugin not installed or not found on your platform. The ldd command can help figuring out the dependencies your plugin may have. Just run ldd [YOUR_GSTREAMER_LIBRARY].so
After updating to ember-cli 0.2.5 (same think with 0.2.4; 0.2.3 was ok), when i make a change to a file and save it, it keeps reloading my app at least 3 times for each save i do. Server's console shows file added... file added... file added... for all my app files each time, but my tmp folder is always empty. Also is seems that for each reload it tries to create a folder inside tmp folder, but it quickly removes it every time. The only file inside tmp folder is .metadata_never_index. Does this have to do with caching? Any help? I'm on yosemite.
I had this problem with watchman 3.1.0 (which is the version that Homebrew installs) so I upgraded to 3.1.1 and it seems to have been resolved.
You'll need to install it from source, but it's easy:
$ brew uninstall watchman
Then just
$ git clone https://github.com/facebook/watchman.git
$ cd watchman
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
Fingers crossed it seems to have worked so far (thank goodness, as it was driving me CRAZY).
For anyone else that has the same problem, i reinstall node and watchman and now everything seems to work fine.
UPDATE I
It seems that the problem still exists. I have to mension that i'm using sublime text 3. When i restart sublime it seems ok, but after a save it starts reloading again and again. Anyone can help here?
UPDATE II
Removed watchman, falling back to NodeWatcher and all seems ok. But time to time i need to restart sublime text in order to boot up the ember-cli server. That seems to be a known issue...
I'm building an RPM that needs to run a number of scripts to configure it after it's been installed to complete the installation. I have to run the scripts in the %post section because the configuration is dependent upon the type of host. All this is fairly easy and well, but every time I run into a bug with the %post section, I have to rebuild the entire package which takes about 20 minutes. Is there a way to skip recompiling everything and just build a new package with just the changes from %post?
If your spec file doesn't create a random build directory and won't delete that build tree afterwards, the more time consuming compiling can be omitted by make. I.e. Similar to not using the --clean option in rpmbuild.
You can then also use the --short-circuit flag to rpmbuild to skip the first stages in building.
Is the script doing something different when run manually vs. run from the RPM install? You can make a test RPM that has no %post, then manually run the script under test (as root). Do this on every host type that needs to be tested until you think you got it. Then add it as the %post and give it a try.