Instal of python3-matplotlib.x86_64 fails on almalinux-9.3

Support
1

Hi. I’m exploring almalinux-9.3 workstation as a possible alternative to ubuntu.

The basic install of almalinux-9.3 and settings went well on my x86_64 test laptop…

I’m now installing typical security and science/programming oriented add-on packages. E.g. the following dnf installs completed successfully:

dnf install epel-release -y
dnf update -y
dnf install clamav clamav-update
groupadd clamav
useradd -g clamav -s /bin/false -c “Clam Antivirus” clamav
freshclam

dnf -y install gfortran
dnf -y install python3-numpy.x86_64
dnf -y install texlive

But an attempt to install the standard python3 graphics package matplotlib failed
with the following error indications.

dnf install -y python3-matplotlib.x86_64
Last metadata expiration check: 1:17:10 ago on Sun 21 Jan 2024 02:35:24 PM PST.
Error:
Problem: conflicting requests

  • nothing provides libqhull_r.so.7()(64bit) needed by
    python3-matplotlib-3.4.3-4.el9.x86_64 from epel

Attempts to install libqhull_r.so.7 also failed.

Thanks for suggestions on how to get matplotlib installed under almalinux-9.3

2

You need to enable the crb repository.

1 Like
3

Many thanks, steve. Enabling the crb repo allowed matplotlib to be installed. Using this repo also allowed the following installs to succeed:

dnf -y enablerepo=crb install octave
dnf -y enablerepo=crb install blender
dnf -y enablerepo=crb install gdl

The repo organization of packages is often confusing for some of us. Following some other online suggestions relating to this problem, I tried enabling the powertools repo for installing matplotlib, but that didn’t help. The crb repo solved the problem.

I suppose it might be useful if package managers such as dnf would suggest an appropriate repo when dnf fails to use currently enabled repos for an installation request.

Thanks again. Very helpful.
-bill

4

Alma’s wiki describes some of the repos: Repositories | AlmaLinux Wiki

RHEL 8 and 9 do have CodeReady Linux Builder (CRB) repository. Its apparent idea is to provide tools for building (RPM) packages. As such, CRB should not be necessary on “production system” and is disabled by default. Alas, some packages, particularly in EPEL (which is “third party”) get dependency on CRB packages, rather than having the functionality in them.

The “CodeReady Linux Builder” is a Red Hat’s trademark – a name that cannot be used by other distros. CentOS Linux 8 did work around that by choosing name powertools. That is why guides for CentOS 8, AlmaLinux 8, etc, do mention powertools. By release of RHEL 9 lawyers figured out that name like “crb” is ok too. That is why AlmaLinux 9 (and Rocky Linux 9, etc) do have crb rather than powertools.

5

A followup problem related to using matplotlib on almalinux-9.3 workstation is that the matplotlib basemap toolkit (for geographical map plotting) appears to be unavailable, or perhaps it is just hiding in yet another non-enabled by default repo.

On ubuntu-22.04-LTS, we simply do:

sudo apt install python3-mpltoolkits.basemap
sudo apt install python-mpltoolkits.basemap-data

Similarly on fedora-20:

sudo yum -y install python-basemap

And back on the old scientific-linux-7:

sudo yum -y install python-basemap

Are the typical matplotlib toolkits not available as simple package installations on almalinux-9.3?

Thanks.

6

EPEL 7 has (according to yum list \*basemap\* ):

python-basemap-1.0.7-6.el7
python-basemap-data-1.0.7-6.el7
python-basemap-examples-1.0.7-6.el7

EPEL 8 (and recent Fefora) do have python3-basemap RPM resource python3-basemap

It is clear that EPEL has built the basemap for RHEL 7 and 8 (just like it builds matplotlib for them and RHEL 9).

You should ask EPEL to build the python3-basemap to EPEL 9. See https://docs.fedoraproject.org/en-US/epel/epel-package-request/

7

You could try to rebuild the most recent Fedora 37 src.rpm from source (rpmbuild --rebuild) in the meantime, but getting it in EPEL is definitely the better longterm solution.

https://koji.fedoraproject.org/koji/buildinfo?buildID=2275828

Looks like python-basemap-data has since been deprecated.