"Cloning" a program from a CentOS 7 machine to another - centos

I am in need of working with a specific version of the text editor Lyx, the 1.3.3, on a CentOS 7 environment. I found the .rpm package and some sort of source code, but as it's a very old software, many library are obsolete and cannot be found when installing from the rpm file and for some reasons no c++ compiler I used seems to be good to compile the source code.
Now my question: I do have a CentOS virtual machine with this specific version of Lyx installed properly. Is there a way to "clone" or somehow copy it into my CentOS main partition? Or, if this is too barbaric, how can I extract/install from the VM CentOS the libraries I need?
I apologize if my question doesn't make much sense, I am by no means an expert of Linux distros and I might have some misconceptions brought over from Windows.

Related

`Haskell` extension for `VSCode` not working on `Linux`

I installed ghcup and:
Stack 2.9.1
HLS 1.8.0
cabal 3.6.2
GHC 9.2.5
All of them are the recommended versions(I verified it using ghcup tui). Then I installed the Haskell extension in VSCode. Unfortunately, it doesn't work. I get syntax highlighting (from the Haskell Syntax Highlighting extension, which seems to be automatically installed alongside the Haskell extension) but there is no Intellisense, no code completion, no error detection and no interactive mode (-->>> evaluation). I experimented with different folders and haskell files. The filetype is correct, because every time I open a .hs file, the Haskell extension checks for updates. I even installed Codium, because I suspected a fault in VSCode, but it was the same there as well.
The hsl language server doesn't seem to be working in Neovim, either. I uninstalled ghcup (ghcup nuke) and reinstalled again. The result is exactly the same. I prepended the PATH and chose vanilla and non-vanilla Stack integration in either installations.
Am I doing something wrong?
OS: Linux Mint on Ubuntu 20.04.1, kernel 5.15.0-56.
After around 10 tries, I managed to fix the problem. It turned out I had three problems:
I had only 12 GB free on my Linux partition, but it seems more are needed. I realised it, when it turned out some haskell-language-server files were missing. I enlarged my Linux partition (something I should have done months ago). The new installation installed all files
The Haskell Language Server HLS was not added to the PATH. I solved it by putting this snippet in ~/.ghcup/config.yaml:
"haskell.serverEnvironment": {
"PATH": "${HOME}/.ghcup/bin:$PATH"
}
The server was now discovered by the Haskell VS Code extension but crashed 5 times and gave up on trying. Restarting it manually didn't help. I opened the logs: View->Output->Haskell and saw the error:
haskell-language-server-wrapper: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by haskell-language-server-wrapper)
It turns out, my Linux Mint distribution uses GLIBC_2.31, not 2.32. This is a very important library, which most applications on the system use. If you are a newbie, it is strongly advised that you DO NOT update it manually.
Instead, what I did, was install a version of the HLS, which used GLIBC_2.31. This problem occured in September and was "fixed" but apparently not very well. There are two options:
download the HLS deb10 version manually (didn't work for me):
ghcup install hls -u https://downloads.haskell.org/~hls/haskell-language-server-1.8.0.0/h
download using ghcup tui HLS version 1.7.0.0 (or whatever newest, which uses your glibc version) and a GHC, which supports that particular version of the HLS (in my case 9.0.2).
I think it's a good idea to preemptively reinstall the extension, in case it used the PATH to configure the HLS, so that its settings are restored to default. It takes up to 20 seconds to initialize the server, so be patient. You can see what's happening in the Output window and verify there are no more errors.
I hope this helps.

How to install pybluez in a Python virtual environment?

I'm wondering how to install pybluez library in a Python virtual environment (Linux Ubuntu / Pop! OS).
The problem is simple: there's no bluetooth.h header in the virtual environment, so it fails during installation.
In real environment there's a series of libraries to install to do the work, but I'm unable to do the same in a virtual environment.
You will need to have the bluetooth.h file and the bluez development files available on the system at all (headers and system libraries are never in virtualenvs anyway).
On Ubuntu, apt install libbluetooth-dev should probably do the trick.
I want to ask to myself cause the problem was really singular and I think that someone else could be involved: the problem is that PyCharm IDE was installed through flatpack. So (I don't know the details cause I'm not an expert about this package format) the program run in a sort of vm and it's unable to recognize libraries under the "real" system. Imho this kind of software (ide I mean) should be inatalled directly with a "classic".deb package to avoid problems like this.

Trouble installing SUMO 0.30.0 in Ubuntu 16.04 from source code

I need to install SUMO 0.30.0 to be used with the VEINS_INET subproject in veins 4.6. I have tried following the instructions here and suggestions from forums but haven't had any luck being able to install sumo. I run ./configure (trying various tool/library options) then run sudo make but all I get is target marouter failed or nothing to be done for 'install-exec-am' 'install-data-am'.
Does anyone know how to install sumo-0.30.0 from source and/or make the veins_inet subproject work with the latest version of sumo-0.32.0?
Don't run sudo make.
Don't run sudo make.
Your problem is probably related to a dependency/packaging change in 16.04, which is explicitly pointed out in the veins tutorial:
Note that Ubuntu 16.04 no longer includes libproj0; this can be worked around by temporarily adding the packet repository of, e.g., Ubuntu Vivid when installing this package.
Short answer: Unfortunately this means that long-term, you're going to either have to package SUMO yourself, use the versions someone else compiled (see this launchpad for example) or rely on an old version.
Long answer:
In general, I would recommend building SUMO from source by building its' dependencies from source, since I've encountered this problem on various distributions. In particular, the fox, proj and gdal libraries tend to be packaged in different versions, and along with changes in the SUMO source code. I currently use this script (with the package versions downloaded) to compile SUMO -- but this is for 0.30.0, and it breaks if any of the referenced source packages are moved (which happens quite often). My general recommendation would be to either use a completely isolated version of SUMO (i.e., compiling by hand as much as possible) or relying on a pre-packaged version (see above), as long as that version is recent enough to work with VEINS.

GDB Compile/configure options for centos7

Our codebase is triggering this bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=13669
Therefore I need to compile GDB with the workaround hack, Unfortunately, I can't seem to find a list of configure options, or some kind of "enable all" flag.
I am using the CentOS 7 distro. The gdb included is version "Red Hat Enterprise Linux 7.6.1-100.el7" It seems to be installed to /usr/bin/gdb
The features I need is python pretty printing, as well as anything else eclipse might need under the hood.
This is my last attempt, but it still doesn't seem to have what i need.:
CC=gcc ./configure --with-python=yes --with-zlib
Specifically, eclipse still can't display pretty printed values.
Also, is there any way to overwrite the package installed version so that it "inherits" the configuration?
---edit---
Also, is there a good way to turn this into a yum installable package? Once i get this to work i need to distribute it to about 50 developer machines.
FYI the issue has been fixed: https://sourceware.org/ml/gdb-patches/2017-10/msg00836.html

Eclipse not recognising express/node

I have been using Linux for less than 24 hours, so please, if there is anymore information I should provide, do be quite specific about how to get that information.
I've been trying to install Node.js, express.js and eclipse. As you can see, ubuntu does recognise both node.js and express as installed on my system (I think!) and I got the Nodeclipse-extension for eclipse, but still Eclipse doesn't seem to recognise either node.js or express (see my image below). I also want to add that the time occurrence of the error, I was trying to build a Node.js Express Project.
At this point, how do I go about debugging the situation? The folder location shown in the image does not fully exist. I can only go as far as [...]/bin/ - I have been looking at error messages similar to mine, and it seems like people are getting such errors because they're lacking an installation, however, from my screenshot provided, I would think everything is installed as needed.
I am using a native 64-bit windows laptop with Linux (Ubuntu) installed through a virtualbox. Ubuntu is 14.04 LTS and just 32-bit, as I don't have spare 2 gb ram to give the 64-bit version. Sadness.
I'd appreciate any help!
In Eclipse Windows -> Preferences -> Nodeclipse
check what is configured for Node and Express
Read more on http://www.nodeclipse.org/
I found a solution, which worked for me:
WINDOWS:
I did double installations of the needed modules. They were both located in C:/Users/X/AppData/Roaming, in the Eclipse directories and finally in C:/Program Files/nodejs. When I deleted all the node_modules, besides critical ones for nodejs to function and then ran Eclipse with Nodeclipse, it seemed to function and Eclipse automaticly defined folders in its own subdirectory, in which Express were located.
UBUNTU:
Delete all node_modules files and run Eclipse with Nodeclipse. See the windows explanation for a more detailed overview. Same problem and solution seemed to be present for both systems. Do note that the file directories are of course not completely interchangeable. You'll need to locate your instances of node_module.