I'm using an OpenWRT environment for code development.
Now, OpenWRT build works by first fetching a package from remote repository, extract it and later apply local patches on top of that code.
What I've noticed is that in case the patch fails to apply, the build itself not always fail, and that creates problems from entire system perspective.
I'm looking for a way to define that in case a patch is fail to apply, the entire build will fail.
Thank you all in advance!
According to the documentation, the easiest way to spot build failures would be to run make V=s 2>&1 | tee build.log | grep -i '[^_-"a-z]error[^_-.a-z]'.
If you know you are having issues with a specific package, I would specifically build those packages via make package/<pkgname>/compile V=s and see where it is failing.
Also, I would try testing the image out in qemu before flashing a real device. That way you can verify your build.
Related
Can I get a tip for installing on rasp buster? Im hung up on the install directions to check the status of the rabbitMQ server. Traceback of bash console:
(volttron) pi#raspberry:~/Desktop/volttron $ echo 'export RABBITMQ_HOME=$HOME/rabbitmq_server/rabbitmq_server-3.7.7'|sudo tee --append ~/.bashrc
export RABBITMQ_HOME=$HOME/rabbitmq_server/rabbitmq_server-3.7.7
(volttron) pi#raspberry:~/Desktop/volttron $ source ~/.bashrc
pi#raspberry:~/Desktop/volttron $ RABBITMQ_HOME/sbin/rabbitmqctl status
bash: RABBITMQ_HOME/sbin/rabbitmqctl: No such file or directory
There are a few tracebacks earlier on the installation...
If it makes a difference or not here is the entire bash console process. The git gist link I just created the name install.py even though its just bash commands copied pasted per install directions...
`pi#raspberry:~/Desktop $ git clone https://github.com/VOLTTRON/volttron --branch releases/7.x`
It looks like there are a couple of different issues going on here:
The issue you quote above (RABBITMQ_HOME/sbin/rabbitmqctl: No such file or directory) is that your shell isn't finding the rabbitmqctl command. It looks like you added the RABBITMQ_HOME environment variable to your .bashrc, but used the string RABBITMQ_HOME instead of the variable expansion $RABBITMQ_HOME when you tried to run the command. Try running it as $RABBITMQ_HOME/sbin/rabbitmqctl status instead.
The rabbitmqctl status command will check the status of the rabbitmq application, but I don't think you've done anything to start it yet (that happens when you bootstrap the platform and/or start the platform configured to use the RMQ broker)
I think that the traces earlier in the installation process are problematic (appears to be the same error hit two different ways), but you just haven't run into them yet. I haven't seen any issues building gevent on the RPi 4 with buster (though it is pretty slow), but the ctypes error makes me wonder if there's an issue with the underlying c library it is trying to build on top of. I did notice that you're getting amd64 erlang packages, are you running Raspbian on an x86 processor? (if so this isn't a permutation we've tried and you may be hitting some package compatibility edge case we haven't seen)
One thing to try is to manually install cython into your virtualenvironment and then try running the bootstrap script again with the virtualenvironment activated. You could also try and pip install gevent==20.6.1 directly in that virtualenvironment (this is what the bootstrap script was doing at the failure point). VOLTTRON depends on gevent, so if that isn't installing the platform won't be able to run.
I am using gwan 7.12.6 on my Ubuntu Server 14.04.4 LTS and I start it with the command sudo service gwan test that is equivalent to the command sudo ./gwan (so not in deamon mode).
Then, all the servlets compile without any error, but kv_bench.c and auth_oauth.c.
When removing the undercore charater of these two servlets, gwan dies with the message:
To run G-WAN, you must fix the error(s) or remove this Servlet.
What is wrong with these two servlets (I'm not a C specialist) that are included with the standard gwan distribution?
The file extension of some C servlets begin with an underscore ("*._c") to disable them at startup.
This is done because these scripts rely on C libraries that may not be available on people's machine. This is mentioned in the servlet file, along with the library name that is required (#pragma link "...").
When you rename these servlets to activate them, these servlets compile but fail to link as the necessary dependencies are missing... hence the error message "To run G-WAN, you must fix the error(s) or remove this Servlet".
As the G-WAN PDF manual explains all this, I suggest you to have a look at it.
I would like to create an RPM package that applies a Puppet manifest on a server which does not contain Puppet, Facter and Hiera.
Also, and more importantly, I should be able to apply it WITHOUT being obliged to install neither of these tools (Puppet, Facter, Hiera) on the production server.
So basically, the package should run the following command without installing any of the required packages:
puppet apply install.pp --modulepath=./modules --hiera_config=./conf/hiera.yaml
How can I proceed to make such a package ? Is it a good idea to extract the 'binary' files the Puppet/Hiera/Facter RPMs to include them in another one ?
Thanks!
Installing the relevant packages and then removing them would be by far the fastest and safest way to do what you wish. Maybe you can convince your customer that the cost in time for any other solution is not worth the money.
Anyway, if packages are not an option, let's be innovative:
You do not have to install from packages, you can install puppet via ruby gems
In the same way, you can use source tarballs
Those two options might work, but are not innovative enough.
What about installing puppet 'locally' on a disk via the gems or the tarballs, and then mounting this disk via nfs?
While we are here, why not do the same but then mount using sshfs?
still with the idea of a having first a remote install, you could indeed repackage it via fpm (amazing tool, very strongly recommended). You still end up with a package, but a local one which will not require adding a repository, this might alleviate some of your client concerns.
building on this, if the issue is with repositories, not packages, you could download all required packages and install them manually
I guess that the summary of this answer is that the value of doing so is negative compared to using what you distribution provides.
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.
Recently I updated Wine (among other things) via port selfupdate from version 1.2 to version 1.4. After that it takes roughly a minute to start up, even simple things such as wine cmd or winecfg. CPU usage also spikes to about 140%.
I've tried completely removing and re-installing MacPorts (yes, I removed ~/.wine) and it's still as slow.
How do I get to the bottom of this?
On 2012-03-20 I updated fontconfig to 2.9.0_0; fontconfig is used by wine and other ports to find fonts. Unfortunately there was a problem where fontconfig did not create its cache files correctly, causing it to try to recreate them each time you use a program that uses fontconfig; this could take a minute or more, depending on your disk speed and how many fonts you have installed, since it's indexing all your fonts.
I updated fontconfig to 2.9.0_1 on 2012-03-27 with a patch to fix this so the usual "sudo port selfupdate" and "sudo port upgrade outdated" commands should fix this.