On older versions of Fedora, one could run the following command to install the rpm-python package:
$ sudo dnf install rpm-python
But now on Fedora 32, it gives the following error:
No match for argument: rpm-python Error: Unable to find a match:
rpm-python
Which package should one install now to get that same package or a similar one on their machine?
Fedora 31 has packages python2-rpm and python3-rpm. The package rpm-python does not exist for a long time. You can request installation of rpm-python, but DNF will actually install python2-rpm.
Fedora 32 moved to Python3 completely (there are some rare exceptions) and python2-rpm ceased to exists. There is only python3-rpm which has the same code. The same API. It is just for python3 only.
Related
I tried to install gfortran 10 from Fedora 31.
Follow https://fortran-lang.org/learn/os_setup/install_gfortran
sudo dnf install gcc-gfortran leads to gfortran 9
I tried to download from https://fedora.pkgs.org/33/fedora-x86_64/gcc-gfortran-10.2.1-3.fc33.x86_64.rpm.html
the download link file leads to Failed to install file, not supported from graphic interface :(
or bash: ./gcc-gfortran-10.2.1-9.fc33.x86_64.rpm: cannot execute binary file: Exec format error from terminal with root.
Is there any way to install gfortran-10 from Fedora?
Thanks!
You can of course always compile GCC from source, it is not that hard and the script for getting the prerequisites is included (./contrib/download_prerequisites).
The easiest way is to download one of the snapshots https://gcc.gnu.org/snapshots.html and follow the instructions. You do not even have to have admin rights, you can do it privately in your home directory.
Check whether there is a repository with additional GCC versions for your distro. For example, on my OpenSuSE, I have packages for GCC 7, 8, 9, 10 and 11. And they can be installed concurrently.
Regarding:
bash: ./gcc-gfortran-10.2.1-9.fc33.x86_64.rpm: cannot execute binary file: Exec format error
You cannot run a rpm file in bash, you have to install it using rpm -i or using your higher level package manager.
The file you downloaded is an RPM package, not an executable. You would normally install it with dnf install ./gcc-gfortran-10.2.1-9.fc33.x86_64.rpm from the command line. However, that package is for Fedora Linux 33, and you're running 31. Occasionally this works, but generally installing packages from new releases on older releases isn't supported.
If, for some reason you can't upgrade to Fedora Linux 33 for your whole system, one approach is to use the toolbox utility to make a containerized workspace using a F33 container image. Then, you can install the version of gfortran you want into that (with dnf install gcc-gfortran).
You could also use F34 (out tomorrow) but note that that has gcc 11.
I'm trying to build Python 3.8.3 using pyenv on Fedora 32: pyenv install 3.8.3. The error I'm getting is:
ERROR: The Python ssl extension was not compiled. Missing the OpenSSL lib?
BUILD FAILED (Fedora 32 using python-build 1.2.21-1-g943015eb)
I want to point out however, that I don't have sudo permissions on the machine. I went through the common build problems, but I'm unable to fix the issue I'm facing. In addition, the OpenSSL lib is installed on the machine, i.e., which openssl outputs /usr/bin/openssl.
Any pointers?
I'm trying to install Atom from the official RPM provided. libXss.so.1 is a dependency and tries to install the 32-bit version of glibc when I already have the 64-bit version. It then conflicts with the 2.23.1-7 older version of glibc that I already have.
So where do I go from here? I'm guessing that there is a bugfix somewhere in libXss. libXss tries to install i686 arch for all it's dependencies.
I'm using Fedora 24 x86_64
Terminal Output
sudo rpm -ivh atom.x86_64.rpm
error: Failed dependencies:
libXss.so.1 is needed by atom-1.13.0-0.1.x86_64
sudo dnf install libXss.so.1
Error: Transaction check error:
file /usr/share/doc/glibc/NEWS from install of glibc-2.23.1-11.fc24.i686 conflicts with file from package glibc-2.23.1-7.fc24.x86_64
sudo dnf install glibc-2.23.1-11.fc.24.x86_64
Package glibc-2.23.1-11.fc24.x86_64 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!
Secondary/Unimportant Question
Do I need glibc-2.23.1-7.fc24.x86_64 when I already have glibc-2.23.1-11.fc24.x86_64? I see that I have both installed yet I have no conflict problems.
edit
I gave up and decided to install from the copr repo
sudo dnf copr enable mosquito/atom
sudo dnf install atom
Error: Transaction check error:
file /usr/lib64/libkadm5clnt_mit.so.10.0 from install of libkadm5-1.14.4-4.fc24.x86_64 conflicts with file from package krb5-libs-1.14.1-6.fc24.x86_64
file /usr/lib64/libkadm5srv_mit.so.10.0 from install of libkadm5-1.14.4-4.fc24.x86_64 conflicts with file from package krb5-libs-1.14.1-6.fc24.x86_64
What is going on?
Can I bypass installing glibc.i686 as a dependency when I already have the x86_64 version?
Not if you need to install 32-bit software — you'll need the 32-bit libs for that. 64-bit libraries aren't supersets of the 32-bit ones.
I'm trying to install Atom from the official RPM provided. libXss.so.1 is a dependency and tries to install the 32-bit version of glibc when I already have the 64-bit version. It then conflicts with the 2.23.1-7 older version of glibc that I already have.
This is a frequent problem. Installing 32-bit versions of packages without updating to the latest versions of the main 64-bit packages is not supported. Upgrade first, then install.
Do I need glibc-2.23.1-7.fc24.x86_64 when I already have glibc-2.23.1-11.fc24.x86_64? I see that I have both installed yet I have no conflict problems.
This can happen if there's an interrupted upgrade transaction. You should be able to dnf remove glibc-2.23.1-7.fc24.x86_64 safely. If that gives you errors, time to stop and make sure nothing else is wrong. Or, you can really just ignore it — next time a new glibc update comes out, it should replace both.
I gave up and decided to install from the copr repo
The errors you see here are actually the same root problem as trying to install 32-bit packages without updating first. RPMs can share files, as long as they are completely identical. That's true in matched versions of the various kerberos packages, but not true if there's a mismatch, and the dependency information doesn't handle this. So, again upgrade to latest packages before installing new ones.
I am trying to compile some code in Fedora 21 using 'mpif90'.
First I install openmpi with 'yum':
[root#localhost Inversion]# yum install openmpi
Loaded plugins: langpacks
Package openmpi-1.8.3-2.fc21.x86_64 already installed and latest version
Nothing to do
But then when I compile using 'make' it doesn't work:
[root#localhost Inversion]# make all
mpif90 -O3 -c src/dispersion.f90
make: mpif90: Command not found
Makefile:18: recipe for target 'obj' failed
make: *** [obj] Error 127
As you can see I've downloaded openmpi package but it wont compile.
You cannot compile because you haven't loaded the necessary module.
You need to load the environmental module, this is how Fedora is handling openmpi when you install it using:
dnf install openmpi
(in Fedora 25)
Just follow the following steps:
In your terminal, do:
module avail
You should see an output something like this:
--------------------- /usr/share/Modules/modulefiles ----------------------
dot module-git module-info modules null use.own
---------------------------- /etc/modulefiles -----------------------------
mpi/openmpi-x86_64
Notice there is the mpi/openmpi-x86_64 module available for you to 'load'.
In your terminal, you just do:
module load mpi/openmpi-x86_64
Now you have access to all the mpi compilers like mpif90 and mpic++ etc. You can see that the compiler binaries are stored in: /usr/lib64/openmpi/bin:
$ which mpif90
and you see the output is:
/usr/lib64/openmpi/bin/mpif90
dnf whatprovides "*/mpif90"
tells you what package provides this binary. In Fedora, you can get it from openmpi-devel or mpich packages. So running
yum install openmpi-devel
should do the job for you.
I installed latest Octave on Ubuntu 14.04 machine. However, when I tried to run imread command, it showed the following error message:
octave:12> imread('newfile.png')
error: imread: invalid image file: /usr/lib/x86_64-linux-gnu/octave/3.8.1/oct/x86_64-pc-linux-gnu/__magick_read__.oct: failed to load: /usr/lib/x86_64-linux-gnu/octave/3.8.1/oct/x86_64-pc-linux-gnu/__magick_read__.oct: undefined symbol: _ZN6Magick5ColorC1Ehhh
error: called from:
error: /usr/share/octave/3.8.1/m/image/private/__imread__.m at line 181, column 7
error: /usr/share/octave/3.8.1/m/image/private/imageIO.m at line 66, column 26
error: /usr/share/octave/3.8.1/m/image/imread.m at line 107, column 30
Can someone please suggest how to solve it?
Thanks!
Following these steps worked for me [Author: Christoffer Cronström (hymyly)]:
Install the dev packages needed to build octave.
sudo apt-get build-dep octave
Get the official source package. Do this in a clean directory, because it will get polluted.
cd ~/some/suitable/directory
apt-get source octave
Build it. This took roughly an hour for me.
cd octave-3.8.2
dpkg-buildpackage
Either run it from the build directory:
./run-octave
...or most preferably install it over the official octave:
cd ..
sudo dpkg --install octave_3.8.2-4_amd64.deb
From: https://bugs.launchpad.net/ubuntu/+source/octave/+bug/1372202
How did you instal Octave? The error suggests that you're missing GraphicsMagick C++ interface (package libgraphicsmagick++3) but
if you installed Octave from Ubuntu's package manager you should not have had this problem; * if you compiled it yourself, Octave should have disabled imread completely and you'd have a very different error message.
So my guess is that you build it yourself, either with:
your own build of GraphicsMagick++ which are not being loaded anymore, you may need to add their path to the dynamic linker load path (either on /etc/ld.so.conf.d./graphicsmagick or define LD_LIBRARY_PATH);
the libraries from the package manager which you have since accidentally removed (since you did not install Octave from the repositories, your package manager will not know that libgraphicsmagick++ is installed for a reason).
Either way, the solution is easy. Install Octave from Ubuntu's package manager. One of the main reasons package managers exist is to avoid this type of problems, i.e., missing dependencies.