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.
Related
This is my first time publishing Scala library into maven central. I follow this tutorial from Scala docs. After I prepare everything, I want to publish my library in SBT shell with command publishSigned, then I get the error about "gpg: signing failed: inappropriate ioctl for device". I did google and try to find the solutions, Here is some sources I find from StackOverflow and ArchLinux. I try to add $ export GPG_TTY=$(tty) into my ~/.bash_profile , but It does not work for me. It looks like sbt shell does not able to get gpg credentials in anyway.
How do I fix it? Thanks for any help.
I fixed this by downloading GPG Suite, and then typing passphrase manually
From this article https://asquera.de/blog/2018-10-01/webassembly-and-wasm-bindgen/ I found we can run wasm-bindgen target/wasm32-unknown-unknown/release/qr_wasm.wasm --out-dir ./dist --no-modules --no-typescript to create wasm and js files without running wasm-pack build (it would install wasm-bindgen regardless if I have previously installed one, making it a bit slow) which seems more flexible to me but when I ran wasm-bindgen xxx it says: zsh: command not found: wasm-bindgen
I googled it but no one seems to have encountered this issue. I also have cargo install wasm-bindgen and wasm-bindgen-cli in my project.
Make sure $HOME/.cargo/bin is in your PATH.
If not:
export PATH="$PATH:$HOME/.cargo/bin"
or edit your .bashrc or some other way
I got here from google with the same problem.
My fix was cargo install wasm-bindgen-cli, per here: https://docs.rs/crate/wasm-bindgen/0.2.8
I installed wasm-bindgen using cargo install wasm-bindgen-cli command, however I wasn't able to execute it.
On Arch, I fixed it with yay -S wasm-bindgen-bin
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
I'm new to collectd and Riemann. Im essentially trying to direct collectd logs to a riemann server instance. I understand that I need write_riemann plugin installed. I tried compiling the source files for write_riemann available online, but it includes a file called "riemann.pb-c.h", which is no where to be found. Please help!
Download the binary. After running the build script, while running the configure script include "--enable-write_riemann", this should install it. I had a lot of dependencies missing on CentOS, which threw a lot of errors. Once they were installed, write_riemann plugin was compiled and installed. Another issue you might face while installing the dependency is not able to find the right packages for protobuf-c.I was using yum package installer. Go to sudo vi /etc/yum.repos.d/epel.repo and change enabled from 0 to 1. After this, the protobuf-c processor was recognised while running the configure script. This solved my issue. Hope it does yours too!
I have jenkins 1.532.1.
When I want to install the EnvInject Plugin, it shows a warning:
This plugin makes it possible to have an isolated environment for your
jobs. Warning: This plugin is built for Jenkins 1.445 or newer. It may
or may not work in your Jenkins.
I go ahead and install it. It says successful but then I can see that it is not installed.
I've already tried restarting jenkins.
Does anyone know whether this plugin was discontinued or whether I will have to downgrade jenkins or any other suggestions?
I got it.
Downloaded the latest jenkins.war and replaced the current one with it.
On ubuntu, here are the steps:
sudo /usr/local/etc/rc.d/jenkins stop
cp jenkins.war /usr/share/jenkins/
sudo /usr/local/etc/rc.d/jenkins start