I've just installed Paraview on Kubuntu 16.04 largely following these instructions: http://www.paraview.org/Wiki/ParaView:Build_And_Install.
I ran make install and it finished successfully, but for the life of me, I can't launch Paraview. If I try to open it from the KLauncher (the 'starrt menu' of Kubuntu), nothing happens at all.
So, I tried running it from the terminal. Running sudo find / -name "paraview" tells me that the executable is stored at the location /usr/local/bin/. So, I cd into the directory and run paraview. All I get is the following:
Aborted (core dumped)
So, I run sudo paraview and I get this:
Bus::open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext: no connection to ibus-daemon
Aborted (core dumped)
As suggested at this link - https://github.com/dashpay/dash/issues/20 - I run sudo apt-get install ibus and ibus-daemon -d and then run sudo paraview again. Now, I get this:
Aborted (core dumped)
Then, I find out that GUI applications must be run with kdesudo, not sudo...so, I give it a shot and I run into even more errors:
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No such file or directory
QFileSystemWatcher: failed to add paths: /root/.config/ibus/bus
Bus::open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext: no connection to ibus-daemon
Somehow, this time there's no Aborted (core dumped), but Paraview doesn't open up anywhere either.
Edit:
I had installed paraview via apt before, but then removed it afterwards because it was crashing when trying to use certain menus. Also, I thought it would make sense to install the newest version (5.2), as the apt repo installs version 5.01.
As advised by Utkarsh, you can download the latest Paraview binaries at:
https://www.paraview.org/download/
Then, you can untar the downloaded archive and directly run Paraview (bin/paraview). Also, You don't need to be root to install and run it.
More generally, Paraview has a lot of dependencies and its build process may be long and difficult. Unless you have a good reason to build Paraview from scratch, it is way more easier to use the pre-built binaries.
Related
I trying to get set up with Variant Effect Predictor (VEP) on the command line. I'm following the setup tutorial but I'm encountering some errors around dependencies. I'm also quite new to the command line so if anyone is able to break down the solution too then I'd be very grateful. Thanks!
Tutorial: https://www.ensembl.org/info/docs/tools/vep/script/vep_tutorial.html
VEP requirements: http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
I also have Perl v5.32.1.
What I've done:
I installed dependencies (listed in the requirements page) with the following commands:
- sudo -s cpanm DBI
- sudo -s cpanm Archive::Zip
- sudo -s cpanm DBD::mysql
For DBD:mysql, I got the follwoing message:
--> Working on DBD::mysql
Fetching http://www.cpan.org/authors/id/D/DV/DVEEDEN/DBD-mysql-4.050.tar.gz ... OK
Configuring DBD-mysql-4.050 ... N/A
! Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
Trying it out anyway, I ran perl INSTALL.pl (from the tutorial page) and got the message below. I would like VEP to run in online mode too if possible.
`WARNING: DBD::mysql module not found. VEP can only run in offline (--offline) mode without DBD::mysql installed
http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
Hello! This installer is configured to install v104 of the Ensembl API for use by the VEP.
It will not affect any existing installations of the Ensembl API that you may have.
It will also download and install cache files from Ensembl's FTP server.
Checking for installed versions of the Ensembl API...done
Setting up directories
Destination directory ./Bio already exists.
Do you want to overwrite it (if updating VEP this is probably OK) (y/n)? y
- fetching BioPerl
- unpacking ./Bio/tmp/release-1-6-924.zip
ERROR: Unable to unpack file ./Bio/tmp/release-1-6-924.zip without Archive::Extract or tar/unzip/gzip`
You show us this error:
Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
So looking in there will give you more clues about what the problems are. Without that, we can only guess.
But we can make educated guesses. The DBD::mysql distribution comes with a file called DBD::mysql::INSTALL which will talk you through some of the problems you'll find while installing this module.
It's important to note that DBD::mysql is a wrapper around MySQL's client libraries. They are written in C, so you'll need a C compiler installed in order to build DBD::mysql. You'll also need the client libraries and the development versions of the client libraries (for the C header files that you'll need to compile the module). On Ubuntu, those packages are called "libmysqlclient" and "libmysqlclient-dev". If you don't have a C compiler, then you'll want to install "gcc" too.
But this is all getting a bit complicated. There's another, simpler, approach. If you're using the system version of Perl (the version that was installed as part of the operating system and probably lives in /usr/bin/perl) then I'd recommend using the pre-build Ubuntu version of the package, which you can install by running:
$ sudo apt-get install libdbd-mysql-perl
Installing that version uses the OS's own package manager, and the package manager knows which other packages are needed in order for it to work - so it will install those as well.
People will probably complain that you're better off installing the modules from CPAN as it gives you more flexibility and allows you to use more up-to-date packages than the versions from your OS repos. And they're right. But, honestly, if you're a non-Perl programmer who just wants to get an application up and running, this is by far the simplest approach.
(But, as I said above, this is all guesswork as you haven't shared the most important errors with us.)
enter image description here
While building my code in getting error : can't locate GTK2.pm #INC (you may need to install gtk2 module)
So I tried to build perl-gtk2 source code on RHEL 8.1. I'm using perl 5.26 version. After building perl script Makefile.pl, I'm running MAKE and it's not getting build successfully. Some of the .pod files are not getting generated.
As shown by your image (and please don't post images of text - copy the actual text into your question) the error message talked about "Gtk.pm", not "GTK.pm". Attention to detail is very important for programmers :-)
There's no need to build anything. The required module is already available in the standard RHEL package repositories.
$ sudo yum install perl-Gtk2
After conscientiously following the install instructions on Linux from swift.org, I encounter an issue where it is not possible to compile anything on a Ubuntu 18.04 machine. The REPL seems to work but during compilation (when calling swift build) the following error appears:
/usr/bin/ld: cannot find -lstdc++
There are more details in the full bug report [SR-9093]. I don't know at all what to do to solve this issue, there are similar problems already mentioned in other bug reports, for instance on this really old one [SR-35].
What should I do?
Thank you
I am assuming that you had already installed the libstdc++ successfully and you have set the permissions properly. But I really doubt that it was installed correctly but it was installed with corruption of some sort. The corruption occurred because you didn't install libstdc++ via a package manager. Result was some form of weirdness in the package manager database which effected the overall functioning system. Exactly why adding something to a folder should change anything at all. I don't know why this happens, unless the folder is hot i.e symbolically linked to a program which doesn't have any tolerance for hacks like simply copying a file into the folder. So for now try to install the libstdc++ again. Below is the link to the file to again download the correct program and this is compatible with amd64.
http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/libstdc++6_5.4.0-6ubuntu1~16.04.10_amd64.deb
And below are some link to help
https://ubuntuforums.org/showthread.php?t=1425470
https://ubuntuforums.org/showthread.php?t=808045
https://ubuntuforums.org/showthread.php?t=808045
https://packages.ubuntu.com/search?keywords=libstdc%2B%2B
https://packages.ubuntu.com/xenial/amd64/libstdc++6
Install libstdc++
sudo apt install libstdc++6
It seems possible that the apt install did not run the ldconfig program, which should be run to add the library to the list of those which ld.so knows about.
It looks like you can do it manually:
sudo ldconfig
IMPORTANT CAVEAT: I don't have Ubuntu and haven't been able to test this. And it's a sudo command. Run at your own risk, YMMV, etc.
If this does not work, it's possible that a file called /etc/ld.so.conf is not set up to search the directory where libstdc++ ended up. I wouldn't dare try to describe how to fix that.
sudo apt install -f
The command above should install any missing dependencies.
I install Cygnus from RPM repository like this and now i dont know how continue.
I try continue whit this section and i got the following error:
bash: APACHE_FLUME_HOME/bin/cygnus-flume-ng: No such file or directory
I am really confused about documentation, because i restart 3 times at start when i try to use docker image, the image got so much errors.
You need java, maven and Flume correctly installed before starting.
export APACHE_FLUME_HOME_BIN=/usr/local/flume to your shell
I recommend following the install from source, which guide you through all the steps.
For docker start with the cygnus-common Dockerfile which uses centos6 as base.
I have a relatively big project that has many dependencies, and I would like to distribute this project around, but installing these dependencies where a bit of a pain, and takes a very long time (pip install takes quite some time). So I was wondering if it was possible to migrate a whole virtualenv to another machine and have it running.
I tried copying the whole virtualenv, but whenever I try running something, this virtualenv still uses the path of my old machine. For instance when I run
source activate
pserve development.ini
I get
bash: ../bin/pserve: /home/sshum/backend/bin/python: bad interpreter: No such file or directory
This is my old directory. So is there a way to have virtualenv reconfigure this path with a new path?
I tried sed -i 's/sshum/dev1/g' * in the bin directory and it solved that issue. However, I'm getting a different issue now, my guess is that this sed changed something.
I've confirmed that I have libssl-dev installed but when I run python I get:
E: Unable to locate package libssl.so.1.0.0
E: Couldn't find any package by regex 'libssl.so.1.0.0'
But when I run aptitude search libssl and I see:
i A libssl-dev - SSL development libraries, header files and documentation
I also tried virtualenv --relocatable backend but no go.
Export virtualenvironment
from within the virtual environment:
pip freeze > requirements.txt
as example, here is for myproject virtual environment:
once in the new machine & environment, copy the requirements.txt into the new project folder in the new machine and run the terminal command:
sudo pip install -r requirements.txt
then you should have all the packages previously available in the old virtual environment.
When you create a new virtualenv it is configured for the computer it is running on. I even think that it is configured for that specific directory it is created in. So I think you should always create a fresh virtualenv when you move you code. What might work is copying the lib/Pythonx.x/site-packages in your virtualenv directory, but I don't think that is a particularly good solution.
What may be a better solution is using the pip download cache. This will at least speed up the download part of pip install. Have a look at this thread: How do I install from a local cache with pip?
The clean way seems to be with virtualenv --relocatable.
Alternatively, you can do it manually by editing the VIRTUAL_ENV path in bin/activate to reflect the changes. If you choose to do so, you must also edit the first line (#) of bin/pserve which indicates the interpreter path.