I would like for a RHEL6 build machine to construct a RHEL5 compatible rpm using the maven rpm build plugin. I see how to modify the arch (amd64 vs i386) and os.name (linux vs. ...) but not RHEL5 vs. RHEL5.
Your best bet is to create a chroot (or perhaps run a VM or docker image, or use mock) that contains RHEL5 on the RHEL6 host, and use that for building packages.
There are specific ways to configure rpm to use ZLIB rather than XZ, and use MD5 rather than SHA256, as well as to change labeling of RHEL6 vs RHEL5.
There is no one magic switch to achieve building RHEL5 on RHEL6 (without using mock etc isolation) because RHEL5 and RHEL6 are distinct operating systems with different API's and versions which will block success for all but trivial packages.
Related
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.
I installed CentOS 7.6 then installed all things QEMU on my machine. I have a SPARC image I need to bringing up in a VM. I've been using qemu-system-sparc.
$ qemu-system-sparc -m 256 -hda solaris_v2-qemu_v2.2.0.disk -nographic -bios ./openbios-sparc32
This is on a box on which I have Fedora-30 installed.
Can I use qemu-sparc to bring up my Solaris image: solaris_v2-qemu_v2.2.0.disk ?
If so, how?
BTW, qemu-sparc come with (on CentOS 7.6):
$ sudo yum install qemu*
PS> I've tried to install qemu-system-sparc on my CentOS box but ended up in a never-ending whack-a-mole game of dependencies.
After a great deal of web searches, I found this:
QEMU as an userspace emulator
QEMU usually comes in two flavors: qemu-system-* are system emulators
(able to run entire operating systems as seen in the previous
section), while qemu-* are userspace emulators (only able to run
userspace applications).
QEMU as an userspace emulator is thus able to directly execute a SPARC
application, by emulating the syscalls that the application requests.
Among the greatest features of this approach are:
The output of application is directly displayed in the terminal,
Arguments to applications are directly given through the command line,
QEMU returns the return code of applications, etc. QEMU really just
acts as a wrapper around the application, as time or nice do.
The only complicated thing you have to do in this approach is to
compile a cross-toolchain for SPARC, so SPARC programs can be compiled
on the host computer. Such a cross-toolchain can be generated by using
the fabulous crosstool-ng.
So the answer appears to be: no, you CANNOT use qemu-sparc to run your image in a VM.
You need the qemu-system-sparc, wich will "emulate" a sparc system.
qemu-sparc will only emulate the CPU and syscalls, thus a SPARC compiled program (that you can extract from your disk image if needed) will run on non-sparc hosts, while most syscalls be "translated" by qemu into your host syscalls, thus a SPARC program can run on said host. file io, kernel stuff, it mostly get translated and run on your host. Handy for debugging or reverse engineering.
Try:
yum install qemu-kvm
The dependencies are required ofcourse. Not very usefull in your case but you could also compile qemu yourself, maybe the dependencies overlap:
git glib2-devel libfdt-devel pixman-devel zlib-devel
I have used pp PAR::Packer to build a standalone exe file to run on a Windows machine.
Can somebody explain how to build a Perl script with all the dependent packages from this Windows machine to create a standalone file to be run on a Linux machine?
Generating a binary that runs on a Linux machine starting from a Windows machine is not possible.
You use the pp (from PAR-Packer) command probably quite in the same way as you did in Windows
pp -S -M Some::Module -M Some::Other::Module -o youBinary.bin Script1.pl Script2.pl ScriptN.pl
Things to note:
The -M flag might be necessary because sometimes the automatic finding of dependencies may not work (some of them are loaded dynamically at runtime so it's a bit trial and error until you get the good combination). Take special care when you see warnings like these when executing pp:
Use of runtime loader module Module::Runtime detected. Results of static scanning may be incomplete.
Use of runtime loader module Module::Implementation detected. Results of static scanning may be incomplete.
The posibility to pack several scripts into one binary. You can them create different symbolic links to that binary to execute the different scripts.
When a single input program is specified, the resulting executable will behave identically as that program. However, when multiple programs are packaged, the produced executable will run the one that has the same basename as $0 (i.e. the filename used to invoke it). If nothing matches, it dies with the error "Can't open perl script "$0"
Very convenient from time to time.
Be aware also of creating the binary on a machine with an "older" libc. If you do this on a bleeding edge linux, you will need a bleeding edge linux to run it too, making it less portable.
Note that even if your perl was built with a shared library, the 'Stand-alone executable' above will not need a separate perl5x.dll or libperl.so to function correctly. But even in this case, the underlying system libraries such as libc must be compatible between the host and target machines.
Enjoy your standalone Perl binary.
EDIT
Generating a binary that runs on a Linux machine starting from a Windows machine is not possible.
The Perl Packager scripts says that it can create executable that runs in same OS. Can I use it to create Win32 binary with linux machine? Or what should I use to create Win32 executable binary on linux from my script?
It is not possible to create stand-alone binaries for different platform than what you are currently running on. This is a generally hard problem since you would have to cross-compile all XS modules and perl itself. Not nice.
For example, if you would like to develop an application on Linux and ship it for both Linux/x86 and Win32/x86, it works well to set up a Virtual Machine with a Windows (XP or 2000 or whatever) and a Perl installation. On that machine, use PAR/pp to package your application for Win32.
On what platforms can I run PAR? On what platforms will the resulting executable run?
Win32 (95/98/ME/NT4/2K/XP), FreeBSD, Linux, AIX, Solaris, Darwin and Cygwin.
The resulting executable will run on any platforms that supports the binary format of the generating platform.
Is it possible to set the path where the berkshelf plugin puts the cookbooks it installs? (As in the .berkshelf folder)
I am running Windows 7.
I am currently trying to install a mysql server using an opscode cookbook to a vm and here at work they have the %HOMEDRIVE% system variable set to a network drive. So when .berkshelf starts at the beginning of the Vagrantfile, it pushes the cookbooks to the network drive and it causes it to be slow and well, its not where it should be. Is there a fix to this?
VirtualBox did this as well, but I fixed it by altering the settings. I tried looking for some sort of equivalent settings for berkshelf, but the closest I got was for the standard berkshelf (thats not a vagrant plugin), it appears you can set this environment variable:
ENV['BERKSHELF_PATH']
Found here:
http://www.rubydoc.info/github/RiotGames/berkshelf/Berkshelf#berkshelf_path-class_method
I need to be able to have the cookbooks it reads from the berksfile store to my laptops local drive instead, as in my scenario I cannot have the mobility of the VM limited to the building because of files that are stored on the network.
Any incite would be much appreciated.
Perhaps its better to use the actual berkshelf over the vagrant plugin?
Thanks.
If you want to have the portability - a full chef-repo ready for chef-solo runs, better off using standalone berkshelf instead of the vagrant-berkshelf plugin - which is NOT that flexibly.
For complex cookbooks, I prefer to use standalone berkshelf as it allows me to do berks install --path chef/cookbooks to copy all cookbooks required from ~/.berkshelf/cookbooks, then I can just tar the whole thing and transfer to other machines for the same chef-solo run. some people use capistrano automate the tar and scp/rsync over the network. I just use rysnc/scp;-)
HTH
I have an application that I deploy on both Linux (Red Hat) and Unix (Solaris). My application installs itself using the built in Perl, and from then creates its own local Perl (new user).
I would like to know what is the best way to deploy Curses::UI? Currently I install other modules by just copying them to my local perl lib folder, but these are pure Perl modules that don't depend on C libraries (.so shared objects, XS, etc.).
Also will I have to compile libncurses for each platform beforehand?
NOTE: The computer doesnt have network connectivity, hence I cant use the CPAN module.
You should use a CPAN client (CPAN.pm, CPANPLUS) to deploy modules such as Curses::UI from CPAN. Usually you need development libs to compile XS modules. For Curses::UI the Ubuntu package is called libncurses-dev. Other Linux distributions probably have an ncurses devel package under the same or similar name.
You said you have a local Perl lib. A very good way to have a local lib is the module of the same name - local::lib. Its documentation will tell you how to easily install modules into your local::lib using a CPAN client.
For the CPAN modules that need to be built, try looking at carton. It has a bundle command that will bundle all your cpan modules together so they can be installed/built on the target machines without any network involved.
As for libcurses, I'd probably lean toward having a custom installer to build it on the target machine if it's not already installed. That or make your software refuse to be installed unless that library is found. Unfortunately I don't know of a good way to build dependent C libraries locally other than doing a custom build script.